1. 课程导论：集群升级背景、镜像拉取瓶颈、CNI网络优化的重要性
1.1 集群升级背景：为什么升级成为高频操作
Kubernetes 版本迭代周期已缩短至约 3 个月一次 minor release。企业生产集群平均每 6–12 个月就需要完成一次版本升级，以获取安全补丁、新特性（如原地升级、拓扑感知路由）以及 API 兼容性支持。然而，集群升级并非简单的“kubeadm upgrade apply”，其背后涉及大量节点镜像的重新拉取与容器运行时重启，这一过程对底层 CNI 网络提出了严峻挑战。
| 升级场景 | 镜像拉取量（典型） | 网络压力特征 |
|---|---|---|
| 控制面升级（3 节点） | ~8–12 GB / 节点 | 并发拉取，短时带宽峰值 |
| 工作节点滚动升级（50 节点） | ~6–10 GB / 节点 | 持续数小时，跨节点流量叠加 |
| 大规模集群原地升级（200+ 节点） | ~4–8 GB / 节点 | 镜像仓库出口带宽瓶颈 + CNI 转发拥塞 |
关键洞察： 升级期间，每个节点需要拉取的新镜像总量通常在 4–12 GB 之间。对于 200 节点集群，总数据传输量可能超过 1.5 TB，且集中在数小时内完成，这对 CNI 网络的吞吐、连接跟踪表容量以及拥塞控制能力提出了极高要求。
1.2 镜像拉取瓶颈：从节点到仓库的链路分析
镜像拉取并非简单的 HTTP 下载，其瓶颈可能出现在以下四个层面：
- 镜像仓库出口带宽 — 自建 Harbor 或云厂商镜像仓库的出口带宽上限，通常为 1–10 Gbps，多节点并发时极易打满。
- 节点网络带宽与队列 — 节点网卡带宽（如 10G/25G）与内核网络栈的接收队列深度，直接影响单节点拉取速度。
- CNI 数据路径开销 — 每个镜像层数据包在节点内经过 veth pair、网桥、iptables/ebpf 规则、隧道封装（如 VXLAN、Geneve）时的额外延迟与 CPU 开销。
- 连接跟踪表（conntrack）溢出 — 大量并发 HTTP 连接导致 conntrack 表项占满，引发丢包与连接重置，严重拖慢拉取进度。
常见误区： 很多运维团队将镜像拉取慢归因于仓库带宽不足，却忽略了 CNI 数据路径中的隧道封装开销和 conntrack 表溢出问题。在 Calico VXLAN 或 Flannel VXLAN 模式下，隧道头部额外占用 50 字节，且每个数据包需要额外的封装/解封装 CPU 周期，当并发拉取达到数百个连接时，节点 CPU 软中断可能成为新的瓶颈。
1.3 CNI 网络优化的重要性：从“透明”到“关键路径”
在集群升级场景中，CNI 网络不再是“透明基础设施”，而是直接影响升级速度与成功率的关键路径组件。优化 CNI 网络可以带来以下收益：
- 缩短升级窗口： 镜像拉取时间减少 30%–50%，整体升级耗时从数小时压缩到 1 小时以内。
- 降低节点压力： 减少 CPU 软中断与 conntrack 表竞争，避免节点在升级期间因网络问题进入 NotReady 状态。
- 提升成功率： 避免因网络超时导致的镜像拉取失败，减少人工介入重试的次数。
1.4 课程核心内容预览
本课程将围绕“集群升级前后镜像拉取数据传输”这一场景，系统讲解 CNI 网络的优化方法。以下是课程核心模块：
| 模块 | 核心内容 | 预期收益 |
|---|---|---|
| CNI 数据路径分析 | veth pair、网桥、隧道封装、iptables/ebpf 转发路径 | 定位瓶颈节点 |
| 隧道协议优化 | VXLAN vs Geneve vs Direct Routing 对比与调优 | 减少封装开销 30%+ |
| conntrack 与连接管理 | conntrack 表大小调整、nf_conntrack 参数优化 | 避免连接重置 |
| 带宽与 QoS 策略 | TC 队列、带宽限制、优先级调度 | 保障关键流量 |
| 升级实战案例 | 200 节点集群升级全流程 CNI 优化方案 | 升级窗口缩短 50% |