1. 课程导论：Cilium CNI 升级背景、租户隔离蓝图概念、通信机制验证的重要性
1.1 升级背景：为什么是 Cilium CNI？
Kubernetes 网络模型在云原生演进中经历了从 Flannel/Calico 到 Cilium 的范式转移。Cilium 基于 eBPF（extended Berkeley Packet Filter）技术，将数据面从 iptables 规则匹配升级为内核态可编程包处理，带来了数量级的性能提升和安全粒度的飞跃。
本次升级的核心驱动力来自三个维度：
| 维度 | 传统 CNI 痛点 | Cilium 解决方案 |
|---|---|---|
| 性能 | iptables 规则链随 Pod 数量线性膨胀，延迟抖动大 | eBPF 哈希表直通，O(1) 查表，PPS 提升 3-5 倍 |
| 安全 | NetworkPolicy 依赖 iptables 逐跳匹配，不支持 L7 协议 | 基于身份的安全标识 + L3-L7 全栈策略，支持 HTTP/gRPC/Kafka |
| 可观测性 | 需额外部署 sidecar 或 DaemonSet 采集流量 | eBPF 原生 Hubble 可观测性，零侵入获取流日志与指标 |
关键数据： 在 500 节点集群中，Cilium 的 eBPF 转发路径比 iptables 模式减少 70% 的 CPU 开销，连接建立延迟降低至微秒级。
1.2 租户隔离蓝图：从网络隔离到安全边界
在多租户 Kubernetes 集群中，租户隔离不再是简单的“不同 Namespace 不通”。租户隔离蓝图是一套分层、可组合的隔离架构，包含以下层级：
- 网络层隔离： 基于 VXLAN/Geneve 的 Overlay 网络，确保租户流量在数据面天然隔离。
- 身份层隔离： CiliumEndpoint + 安全标识（Security Identity），将 Pod 标签映射为数字身份，策略基于身份而非 IP。
- 策略层隔离： CiliumNetworkPolicy 支持租户级入站/出站规则，可精确到端口、协议、HTTP 方法。
- 审计层隔离： Hubble 流日志按租户标签聚合，支持租户自服务审计。
1.3 通信机制验证的重要性
CNI 升级不是简单的组件替换，它直接改写集群的数据面转发路径。如果升级后租户隔离蓝图中的某一层出现漏洞，可能导致：
- 越权访问： 租户 A 的 Pod 可以访问租户 B 的数据库。
- 策略逃逸： 本应被拒绝的 HTTP 请求被错误放行。
- 审计盲区： Hubble 流日志丢失或标签错乱，无法追溯安全事件。
通信机制验证的核心目标，是在升级前后对以下三个关键路径进行对比测试：
| 验证路径 | 验证内容 | 预期结果 |
|---|---|---|
| 同租户通信 | Pod → Service → Pod 的连通性与延迟 | 升级后延迟不高于升级前 5% |
| 跨租户通信 | 租户 A Pod → 租户 B Pod 的阻断验证 | 100% 阻断，无漏放 |
| 策略命中审计 | Hubble 流日志中策略命中记录与预期一致 | 每条流日志包含正确的租户标签和策略 ID |
实践建议： 在升级前使用 Cilium Connectivity Test 套件建立基线，升级后重新运行并对比结果。重点关注
--include-unsafe-tests 模式下的跨 Namespace 策略验证。
1.4 课程目标与学习路径
本课程将带领学员完成从理论到实践的完整闭环：
- 理解 Cilium 升级对数据面的影响： eBPF 程序热更新、Identity 迁移、策略重编译。
- 掌握租户隔离蓝图的验证方法： 使用 Cilium Connectivity Test、Hubble CLI、Prometheus 指标进行多维度验证。
- 构建自动化验证流水线： 将验证步骤集成到 CI/CD，实现升级前自动阻断。
- 处理升级中的异常场景： 策略丢失、身份冲突、Hubble 流日志中断等故障排查。
重要提示： 本课程所有验证步骤均在非生产环境执行。生产环境升级前必须完成完整的回归测试，并准备回滚方案。