1. 课程导论与场景设定

1.1 集群升级背景：为什么升级是治理的起点

Kubernetes 集群的生命周期中，版本升级是最频繁、风险最高的操作之一。根据 CNCF 年度调查，超过 70% 的生产集群每年至少经历一次 major/minor 版本升级。升级不仅带来新特性与安全补丁，更可能破坏已有的网络连通性、策略绑定与租户隔离边界。

在大型多租户平台中，升级引发的网络故障往往呈现“隐蔽性”和“延迟暴露”特征——升级过程中控制面正常，但租户工作负载在数小时甚至数天后才出现间歇性断连。这类故障的根因通常涉及 CNI 插件版本兼容性、NetworkPolicy 规则迁移、Service 负载均衡器重建等多个层面。

1.2 租户隔离蓝图：定义与关键组件

租户隔离蓝图（Tenant Isolation Blueprint）是一套将网络隔离、策略绑定、命名空间拓扑与资源配额统一建模的治理框架。它确保每个租户的工作负载在共享集群中拥有独立的网络域、可预测的连通性边界以及可审计的策略执行点。

一个完整的租户隔离蓝图包含以下核心组件：

1.3 典型故障场景：升级后租户网络不通

本课程聚焦的故障场景具有以下特征：

• 触发条件： 集群从 Kubernetes v1.24 升级至 v1.27，CNI 插件从 Calico v3.22 升级至 v3.26。
• 故障表现： 租户 A 的 Pod 无法访问同命名空间的 Service，但跨命名空间访问正常；租户 B 的 Pod 无法访问外部 DNS，但集群内通信正常。
• 故障范围： 并非所有租户都受影响，仅部分租户出现“部分协议不通”或“间歇性超时”。
• 排查难点： 控制面组件日志无报错，CNI 插件状态显示正常，NetworkPolicy 规则在 API Server 中完整存在。

下图展示了升级前后租户隔离蓝图的状态变化与故障触发点：

1.4 故障排查的挑战与课程目标

此类故障的排查难点在于：

1. 表象与根因分离： 租户报告“网络不通”，但集群监控显示所有组件健康。故障可能源于 CNI 插件升级后的 IPAM 数据迁移错误，而非网络策略本身。
2. 多组件耦合： 一次升级涉及 kube-apiserver、kube-controller-manager、kube-proxy、CNI DaemonSet、CoreDNS 等多个组件的版本变更，任何一个组件的兼容性问题都可能表现为网络故障。
3. 租户隔离的“软边界”： 租户隔离蓝图依赖标签、命名空间、NetworkPolicy 等逻辑边界，升级后这些边界的语义可能发生变化，但不会直接报错。

本课程将围绕以下目标展开：

• 建立升级后租户网络故障的系统化排查框架，从租户隔离蓝图的角度逐层定位根因。
• 提供可复现的故障场景与对应的诊断命令、日志分析方法和修复策略。
• 总结升级前的预防性检查清单，降低租户网络故障的发生概率。

1.5 课程路线图：从故障定位到治理闭环

本课程共 30 章，按以下阶段组织：