1. 课程导论：Cilium CNI 概述、租户隔离网络的定义与重要性、升级场景的挑战与风险

1.1 Cilium CNI 概述

Cilium 是一个基于 eBPF（Extended Berkeley Packet Filter）的云原生网络、安全和可观测性解决方案。作为 Kubernetes 的 CNI（Container Network Interface）插件，Cilium 利用 Linux 内核的 eBPF 技术，在无需修改应用程序或容器镜像的前提下，为 Pod 和服务提供高性能的网络连接与安全策略。

Cilium 的核心优势在于其数据路径完全运行在内核态，绕过了传统的 iptables 或 IPVS 等用户态代理，从而显著降低了网络延迟和 CPU 开销。其关键特性包括：

• eBPF 数据路径：通过在内核中动态注入程序，实现高效的包转发、负载均衡和网络策略执行。
• 基于身份的安全策略：使用 Security Identity（安全身份）而非 IP 地址来定义网络策略，简化了策略管理并增强了安全性。
• 可编程性与可观测性：提供丰富的 Metrics、Tracing 和 Hubble 可观测性层，支持深度网络监控和故障排查。
• 多集群与多网络方案：支持 Cluster Mesh、Service Mesh 集成以及多种数据路径模式（如 VXLAN、Geneve、Direct Routing）。

1.2 租户隔离网络的定义与重要性

在多租户 Kubernetes 集群中，租户隔离网络是指通过 CNI 插件和网络策略，将不同租户（团队、项目、客户）的 Pod 流量、命名空间和网络资源进行逻辑或物理隔离的架构设计。其核心目标是确保一个租户的网络活动不会影响其他租户的安全性、性能或可用性。

租户隔离网络通常包含以下层次：

租户隔离网络的重要性体现在：

• 安全合规：满足 SOC2、PCI-DSS、GDPR 等法规对数据隔离和访问控制的要求。
• 故障域隔离：防止一个租户的流量突发或网络攻击扩散到其他租户。
• 资源公平性：通过带宽限制和 QoS 策略，避免“吵闹邻居”问题。
• 运维简化：清晰的网络边界使得故障排查和审计更加高效。

1.3 升级场景的挑战与风险

Cilium CNI 的升级并非简单的版本替换，尤其是在多租户隔离网络中，任何数据路径或策略引擎的变更都可能引发连锁反应。以下是升级过程中常见的挑战与风险：

1.3.1 数据路径中断风险

Cilium 升级通常涉及 eBPF 程序的重新加载、内核模块的更新以及数据路径的切换。如果升级过程中出现 eBPF 程序加载失败或与内核版本不兼容，可能导致 Pod 网络中断、DNS 解析失败或负载均衡失效。

1.3.2 安全策略兼容性风险

CiliumNetworkPolicy 的 API 版本或字段语义在不同版本间可能发生变化。例如，从 Cilium v1.11 升级到 v1.13 时，toFQDN 规则的匹配逻辑有所调整。如果未提前验证，可能导致策略失效或意外放行流量。

1.3.3 租户隔离边界失效风险

升级过程中，如果 Cilium Agent 重启或 Identity 分配机制出现短暂不一致，可能导致不同租户的 Pod 获得相同的 Security Identity，从而绕过隔离策略。这种风险在跨命名空间策略依赖 Identity 的场景下尤为突出。

1.3.4 回滚复杂度

一旦升级后发现问题，回滚并非简单的“安装旧版本”。eBPF 程序可能残留，内核状态可能不一致，导致回滚后网络仍然异常。需要制定详细的回滚预案，包括清理残留 eBPF 程序、重启节点等步骤。

1.4 升级场景架构概览

下图展示了 Cilium CNI 升级对租户隔离网络的核心影响路径：

1.5 升级风险矩阵

为了帮助运维团队快速评估升级风险，下表总结了不同升级场景下的关键风险等级：