1. 课程导论与目标
1.1 集群升级背景
在 Kubernetes 集群的生命周期管理中，版本升级是最常见且风险最高的运维操作之一。无论是控制面组件（kube-apiserver、kube-controller-manager、kube-scheduler）的更新，还是节点操作系统内核的轮换，每一次升级都可能引入 API 兼容性变化、资源对象行为变更或网络策略的隐性破坏。
根据 CNCF 年度调查报告，超过 70% 的生产集群每年至少经历一次主要版本升级。而在这些升级过程中，Ingress 控制器作为南北向流量的统一入口，往往成为故障的“第一响应者”——流量中断、证书失效、路由规则不生效等问题频繁出现。
关键数据： 某头部互联网公司统计显示，集群升级期间 45% 的线上故障与 Ingress 控制器配置或版本兼容性直接相关。
1.2 Ingress 控制器在升级中的角色
Ingress 控制器在集群升级中承担着三重核心角色：
| 角色 | 说明 | 升级风险点 |
|---|---|---|
| 流量网关 | 所有外部请求进入集群的第一道关卡，负责 TLS 终止、路由分发、限流熔断 | 升级期间流量中断、证书加载失败、路由规则不匹配 |
| API 转换层 | 将 Ingress 资源（networking.k8s.io/v1）转换为反向代理配置（Nginx/Envoy/Haproxy） | API 版本废弃（如 extensions/v1beta1）、字段语义变更 |
| 可观测性锚点 | 提供访问日志、请求延迟、错误码分布等关键指标 | 升级后日志格式变化、指标标签丢失、链路追踪上下文断裂 |
升级过程中，Ingress 控制器需要同时处理新旧版本控制面的混合状态。例如，当集群从 v1.24 升级到 v1.25 时，kube-apiserver 可能已经更新，但部分节点上的 kubelet 仍为旧版本。此时 Ingress 控制器必须正确解析来自新 API 的 Ingress 资源，同时兼容旧节点上的 Pod 网络连通性。
1.3 调试与链路追踪的重要性
传统的“查看日志 + 手动 curl”调试方式在集群升级场景中面临三大挑战：
- 故障定位困难：升级引发的流量异常可能由控制面、数据面、网络插件或证书链中任意环节导致，日志分散在多个组件中。
- 影响范围模糊：部分 Ingress 规则失效而其他规则正常，需要精确区分是全局性问题还是特定路由问题。
- 回滚决策滞后：缺乏端到端的请求追踪能力，无法快速判断升级是否对业务流量产生了实质性影响。
引入链路追踪（Distributed Tracing）后，运维团队可以：
- 追踪单个请求从客户端 → Ingress 控制器 → 后端 Service → Pod 的完整路径
- 识别升级后新增的延迟抖动或错误码突变
- 对比升级前后的 Trace 数据，量化兼容性影响
最佳实践： 在集群升级前，至少提前 2 周启用 Ingress 控制器的链路追踪采样（采样率建议 1%~5%），建立基线数据。升级期间将采样率临时提升至 10%~20%，以便快速捕获异常。
1.4 升级场景中的 Ingress 控制器架构
下图展示了集群升级过程中 Ingress 控制器与各组件的交互关系，以及链路追踪数据的采集路径：
1.5 课程目标与学习路径
通过本课程，你将掌握以下核心能力：
| 模块 | 核心能力 | 实践产出 |
|---|---|---|
| 调试基础 | 使用 kubectl、curl、tcpdump 等工具定位 Ingress 控制器故障 | 升级故障排查清单 |
| 链路追踪集成 | 在 Ingress 控制器中集成 OpenTelemetry，配置采样策略 | Jaeger 追踪看板 |
| 升级前基线 | 采集升级前的流量指标与 Trace 数据，建立对比基准 | 基线报告模板 |
| 升级中实时监控 | 通过 Prometheus + Grafana 实时观察 Ingress 控制器状态 | 升级监控大盘 |
| 升级后验证 | 对比升级前后的 Trace 数据，验证兼容性与性能 | 升级验收报告 |
前置要求： 本课程假设你已具备 Kubernetes 集群管理基础（Pod、Service、Ingress 资源操作），并熟悉基本的 Linux 网络调试命令。建议提前准备一个测试集群（版本 ≥ 1.22）用于实验。