Cilium : eBPF 重塑云原生基础设施

Step 1: Establishing the Context

为什么我们需要重新想象网络？

微服务王国的“隐形哨兵” (A Narrative)

想象一个名为“K8s”的繁荣王国，起初只有几个村庄（Pod）。守卫（iptables）拿着纸质名录，通过逐行查对来放行访客。随着王国扩张到数万个城镇，名录变成了几公里长，守卫查阅一次名录需要消耗整天时间，交通陷入瘫痪。

这时，Cilium 出现了。他给每个城镇分发了“魔法胸章”（Identity Label），并在每条道路的地面下安装了“隐形感应器”（eBPF 程序）。现在，哨兵无需查阅纸张，访客踏过感应器的瞬间，身份、意图、速度都被即时处理。

这就是 Cilium 给现代数据中心带来的变革：将性能开销降至冰点，将安全边界推至内核。

💡 Make it Clear: 核心隐喻对照表

纸质名录
iptables 规则链 (线性 $O(N)$ 搜索)

魔法胸章
Cilium Security Identity (16-bit 身份 ID)

隐形感应器
eBPF Hook 点 (JIT 编译，常数级性能)

行业基准认知 (The Official Baseline)

什么是 Cilium?

What is Cilium?

Cilium 是一个开源软件，用于透明地保护使用 Linux 容器管理平台（如 Docker 和 Kubernetes）部署的应用程序服务之间的网络连接。其核心是 eBPF 技术，允许在 Linux 内核中动态插入强大的安全可见性和控制逻辑。 Cilium is open source software for transparently securing the network connectivity between application services. At its foundation is eBPF, enabling the dynamic insertion of powerful security visibility and control logic within Linux itself.

什么是 Hubble?

What is Hubble?

Hubble 是一个完全分布式的网络和安全可观测性平台。它建立在 Cilium 和 eBPF 之上，以完全透明的方式深入了解服务以及网络基础设施的通信和行为。 Hubble is a fully distributed networking and security observability platform built on top of Cilium and eBPF to enable deep visibility into service communication and infrastructure behavior.

为什么选择它们?

Why Cilium & Hubble?

传统的 iptables 依赖 IP 地址过滤，但在动态微服务中，IP 频繁更迭。Cilium 基于服务身份 (Identity) 而非 IP 寻址，能够在不更改任何应用代码的情况下提供 L7 层级的深度隔离。 Traditional approaches (iptables) struggle with IP churn in microservices. Cilium uses Service Identity instead of IPs, providing L7 isolation without changing application code.

Step 2: Understanding the Shift

网络代际演进：我们为何在此？

从硬件围墙到软件定义，再到内核原生。理解 Cilium 的前提是理解其在历史维度中的位置。

第一代：Userspace

通过应用层代理转发。性能瓶颈极大。

第二代：Kernel (iptables)

利用内核规则链。随 Pod 增加 $O(N)$ 复杂度爆炸。

第三代：eBPF Native

Cilium 时代。绕过协议栈，$O(1)$ 查找，身份感知。

关键维度 (Key Metrics)	iptables (传统模型)	Cilium eBPF (现代标准)	架构意义 (Architectural Impact)
转发效率	低随规则线性衰减	极高常数级延迟	解耦规模与性能
安全基石	基于 IP (易变、脆弱)	基于身份标签 (Identity)	实现真正的零信任内核
可观测性	盲区仅包级统计	全透视 L7/DNS/身份关联	消除生产环境排障黑盒
网格形态	Sidecar (高 CPU/内存损耗)	Sidecar-less (内核原生代理)	极简架构，显著降本增效
物理网络整合	需复杂 Overlay 封装	原生支持 BGP/物理网集成	NEW 实现 DC 网络一体化

💡 架构师笔记： 这里不仅是性能的提升，更是**复杂度的释放**。在传统的 $O(N)$ 模型下，网络规模越大，系统越脆弱；而 eBPF 带来的 $O(1)$ 特性，让我们第一次在万级节点规模下获得了确定性的性能表现。

Step 2.5: The Foundation

高性能 CNI：重塑 Kubernetes 的动脉系统

CNI 不仅仅是分配一个 IP，它是决定整个集群吞吐量、延迟与扩展性的物理根基。

标准定义 (What)

什么是 CNI？

CNI (Container Network Interface) 是 K8s 网络的一套标准协议。它将“如何创建网络”与“如何运行容器”解耦。

Kubelet 发现新 Pod

调用 Cilium CNI 插件二进制

Cilium 为其创建 NetNS 并绑定 Veth 对

通过 BPF 程序注入网络访问策略

痛点剖析 (Why)

为什么 K8s 需要 Cilium CNI？

传统 CNI（如 Flannel/iptables）在万级 Pod 规模下会面临“规模之墙”：规则链线性搜索导致的 CPU 剧烈抖动。

💡 对比： 传统方案是在软件层层封装（Overlay），而 Cilium 是直接在内核态构建“直通电梯”，将查找复杂度从 $O(N)$ 降至 $O(1)$。

安装逻辑 (How)

它是如何安装与工作的？

Cilium 以 DaemonSet 形式运行在每个节点。通过 Helm 安装时，它会接管节点的 CNI 配置目录（/etc/cni/net.d）。

# 查看 CNI 配置文件
$ cat /etc/cni/net.d/05-cilium.conflist
{ "type": "cilium-cni", "enable-debug": true }

Cilium 如何实现“极致性能”？

1. Native Routing (原生路由模式)

完全抛弃 VXLAN 封装损耗。Cilium 直接利用主机的路由表进行 Pod 流量转发，适用于 BGP 物理网或云环境路由模式。

2. XDP 加速 (eXpress Data Path)

在网卡驱动层直接截获报文。对于 Load Balancer 流量，Cilium 能在 CPU 还没感知到报文前，就通过 XDP 完成转发。

3. EDT 带宽管理 (Earliest Departure Time)

传统的 HTB 限速会导致严重的 CPU 锁竞争。Cilium 引入 eBPF EDT 限速，能大幅降低万兆网卡下的长尾延迟。

9.6 Gbps TCP 吞吐量 (接近线速)

-35% P99 延迟降低

Unlimited Service 扩展规模

* 数据参考自 Cilium 官方 2021 CNI Benchmark。

吞吐量对比 (Throughput)

网络方案	MTU 1500 (Gbps)	CPU 消耗
Cilium (Direct Routing)	9.62	极低
Calico (IPIP)	8.45	中
Flannel (VXLAN)	7.41	高

* 源自 Cilium 2021 官方基准测试：封装损耗是性能损耗的元凶。

为什么 Cilium 更快？(The How)

1. Bypass Iptables: 传统 CNI 报文需要经过数千条 Netfilter 规则，Cilium 直接在内核 sockmap 层重定向报文。

2. CPU 局部性优化: eBPF 程序运行在处理中断的同一 CPU 核心上，最大化 L1/L2 缓存命中率。

3. 零内存拷贝: 报文在 Pod 间传递时，尽量保持在同一内存地址空间。

[ Pod 网络诞生记 ]

1. 宣告： Kubelet 发现新容器启动，发出 CNI ADD 指令。
2. 分配： Cilium IPAM 瞬间锁定可用 IP，并关联全局唯一的 Security Identity。
3. 注入： eBPF 字节码被即时编译（JIT）并挂载到该 Pod 的网卡入口，安全策略自此“长”在了硬件边缘。

Step 3: The Big Picture

内核级协作：控制平面与数据平面的交响乐

理解 Cilium 的关键在于区分“谁在下令（用户态）”与“谁在执行（内核态）”。这种解耦是高性能与安全的基础。

用户空间 (User Space) - 控制平面 (The Brain)

Cilium Agent

（Watcher, Compiler, BPF Loader）负责策略监听、eBPF 程序编译及加载。

Cilium Operator

（KVStore Sync, Identity Allocator）处理身份分配等全局集群任务。

Hubble

（Flow Observer, UI）从数据平面提取流信息，提供逻辑化的可视化视图。

协作机制：Agent 编译 ELF 对象并加载至内核，通过 Maps 实时同步状态

内核空间 (Kernel Space) - 数据平面 (The Muscle)

eBPF Datapath Execution Engine (JIT Compiled - 接近原生硬件性能)

BPF Maps (The Brain in Kernel)

连接控制面与数据面的 KV 存储（IPCache, Policy, LB Maps）。
实现 $O(1)$ 查找的核心：从线性搜索进化为字典检索。

Endpoint States

存储每个 Pod 的 Identity 身份信息。
安全策略判定的“唯一真理”：在内核中直接核对身份胸章。

💡 为什么这很重要？ 在传统架构中，控制逻辑和数据处理混在一起，导致规则更新时性能剧烈波动。而在 Cilium 架构中，用户态 Agent 只负责“写书”（编译 Map），而 内核态 eBPF 只负责“读书”（执行 Map）。这种彻底的读写分离，确保了即便在大规模高并发下，安全策略的下发也不会导致网络抖动。

Strategic Evolution

核心价值：从基准到战略演进

基于黄金圈法则，我们不仅关注基础能力，更关注 Cilium 如何引领下一代基础设施的演进路径。

1. 为什么必须改变? (Why)

传统模型正在撞上“规模之墙”：

🚀 突破 $O(N)$ 性能瓶颈： 解决 iptables 规则爆炸导致的转发延迟和 CPU 抖动。
🛡️ 弃用脆弱的 IP 策略： 云原生 Pod IP 瞬息万变，安全不能基于“易逝的门牌号”。
🔍 消除可观测性盲区： 传统工具无法解析容器间的逻辑身份和 L7 语义（如 gRPC 路径）。

💡 Landmark： Cilium 将网络查找复杂度从线性 $O(N)$ 降至常数级 $O(1)$。

2. 我们如何重塑内核? (How)

通过 eBPF 实现内核态的“硬加速”：

🧠 内核原生可编程性： 直接在 XDP/TC 钩子层处理报文，绕过协议栈冗余路径。
🏷️ 16位身份 ID 映射： 将复杂的 Labels 哈希为 16-bit 整数，在 BPF Map 中极速查找。
🔗 Socket 层级重定向： 利用 sockmap 实现本地 Pod 通信的“短路机制”。
💡 底层逻辑： 就像在两个相邻房间打通了一扇暗门，数据直接从 A 传到 B，再也不用走出房间去挤外面的长走廊（复杂的网络协议栈）。

🛡️ XDP: 大门口的门卫

在网卡驱动层直接处理。坏人刚到大门口就踢出去，保护内核不受 DDoS 冲击。

🛂 TC: 玄关的安检

在进入协议栈前的玄关处。检查行李（报文内容），执行复杂的安全策略。

3. 最终交付了什么? (What)

统一的网络、安全与观测平面：

🏎️ 高性能 CNI： 完美替代 kube-proxy，支持 BGP 物理网集成与带宽调度。
🕸️ 无代理服务网格： 无需 Sidecar 即可实现 L7 路由、TLS 卸载与金丝雀发布。
🛂 全局流量治理底座： 跨集群的 ClusterMesh 与符合 Gateway API 标准的入口控制。

内核地标：身份标识（Identity）的深度解构

1. 身份分配： Cilium Operator 扫描 Pod 标签，将 app=payment 等集合哈希为一个唯一的 16位整数 ID。

2. 报文标记： 该 ID 会被注入 VXLAN 头部或在内核上下文中传递。安全策略不再与不稳定的 IP 绑定。

3. $O(1)$ 策略判定： 接收端内核直接将 Source ID 作为 Key，在 BPF Policy Map 中执行哈希查找。

4. 价值体现： 无论集群有 100 个还是 10,000 个 Pod，安全判定的延迟始终如一，彻底解决了“规则爆炸”问题。

官方 L7 过滤规范示例： Official L7 Filtering Specs:

HTTP 限制： 仅允许 GET /public/.*，拒绝所有其他动作。
Kafka 限制： 允许 service1 发送至 topic1，禁止其他所有 Kafka 消息。
HTTP Limit: Allow GET /public/.*, deny everything else.
Kafka Limit: Allow service1 to produce on topic1, reject others.

💡 深度类比：登机牌 (Identity) vs 座位号 (IP)
传统网络像看座位号：乘客（Pod）经常换座位，空乘（防火墙）必须时刻盯着谁坐在哪，非常混乱。
Cilium 像看登机牌：无论你坐在哪个位置（IP），你的登机牌（Identity）上印着的“头等舱”或“经济舱”权限是固定的。内核只认牌子，不认座位，效率提升 90% 以上。

[ 架构师视角 ]
这是从“包过滤”到“逻辑治理”的跨越。IP 是临时的座位号，Identity 才是永久的身份证。

CiliumNetworkPolicy: Zero Trust Example identity-aware.yaml

                apiVersion: "cilium.io/v2"
                kind: CiliumNetworkPolicy
                metadata:
                  name: "secure-payment-access"
                spec:
                  endpointSelector:
                    matchLabels:
                      app: payment-db
                  ingress:
                  - fromEndpoints:
                    - matchLabels:
                        app: payment-service # 逻辑标签
                        env: prod
                    toPorts:
                    - ports:
                      - port: "6379"
                        protocol: TCP

内核执行逻辑：

1. Cilium 将 app: payment-service 映射为 ID: 1042

2. 当请求到达网卡时，eBPF 在 Maps 中核对：
SourceID: 1042 -> Port: 6379 -> [ALLOW]

3. 结论： 无需查看 IP，即便 Pod 漂移到新节点，策略依然瞬间生效。

架构分水岭：彻底告别 Kube-proxy

为什么 OpenAI 和 Netflix 选择删除 Kube-proxy？这是从线性搜索到常数级查找的范式转移。

Service 转发延迟

$O(1)$

基于 eBPF Hash Map 查找

技术内幕 (Inside the Kernel):

1. 绕过协议栈： 报文通过 XDP/TC 钩子在进入协议栈前完成 DNAT。
2. 消除规则爆炸： 传统 iptables 随 Service 增加呈 $O(N)$ 复杂度；Cilium 始终保持常数级性能。
3. 纯净部署： 手册实战证明：通过 --skip-phases=addon/kube-proxy 即可获得最简内核路径。

Step 5: Beyond Pod Networking

基础设施集成：由内核定义的中枢

Cilium 不仅处理 Pod 间通信，它正在成为数据中心的网络控制中枢。

🚦

Gateway API 1.2+ v1.2+

完全超越传统 Ingress。支持复杂的跨集群权重分配与全自动 A/B 测试。

流量分割：支持多集群流量按比例平滑切分。
身份感知：在 L7 层实现基于逻辑身份的精细化治理。

📡

BGP 物理对等与原生路由

建立简单的平面 L3 网络。IP 分配采用 Host-scope 分配器，无需跨主机协调。

Overlay (VXLAN/Geneve):
跨主机虚拟网络，对底层基础设施无特殊要求，适用于大多数云环境。 Virtual network spanning hosts. Minimal infrastructure requirements.

Native Routing:
直接使用 Linux 路由表。适用于公有云路由或运行 BGP 守护程序的物理环境。 Uses host routing table. Best for cloud routers or physical BGP environments.

集群跨度：扁平 L3 连接
L3 Connectivity: Flat Network

⚖️

分布式负载均衡

实现几乎无限的扩展。在 Linux 内核套接字层执行高效的服务到后端转换。

✅ 支持 Maglev 一致性哈希，确保负载分配极其均匀且稳定。
✅ 支持 DSR (直接服务器返回)，消除 LB 节点的转发性能瓶颈。 ✅ Supports Maglev and DSR to maximize performance and scalability.

Tech: Maglev / XDP / DSR
Replaces: kube-proxy

🚀

Bandwidth Manager

采用基于 eBPF 的 EDT (最早出发时间) 限速，替代传统的 HTB 或 TBF 模型。

Implements eBPF EDT-based rate-limiting, replacing legacy HTB or TBF models.

显著减少应用传输的尾部延迟。
避免多队列网卡下的锁定竞争。
Significantly reduces transmission tail latencies.

📊

监控与排障专家

丢包不再只有 IP。提供带有完整元数据（标签、身份）的事件监控。

More than just IPs. Provides event monitoring with full metadata (Labels, Identities).

🛠️ 集成 Prometheus 导出核心指标，配合 Hubble 渲染全局拓扑图。

🔐

透明加密与 DNS 治理

基于身份的 DNS 过滤可精准识别哪些服务解析了特定域名。

安全价值：

支持 CIDR 范围对外部服务的访问控制。
内核态 IPsec/WireGuard 保护跨节点流量。
CIDR-based security and kernel-level encryption.

🛡️

Tetragon 运行时安全

利用 eBPF 程序的可编程性，在不更改代码的情况下实现动态、低开销的可视化逻辑。

🌐

Global ClusterMesh

不再局限于本地互联，2025 版支持 255 个以上集群的网格拓扑，构建全球统一控制平面。

$ cilium clustermesh status --max-clusters 255

Step 6: The Economics of Architecture

SRE 经济学：Sidecar-less 与流量治理 ROI

技术选型最终是一本经济账。消除 Sidecar 后的资源利用率提升与网关整合是其商业吸引力的核心。

平均云账单节省 (Avg. Savings)

32% +

基于 1000 节点规模测算

为什么能省钱？(Economic Breakdown)

内存冗余消除： 每个 Envoy 占用 ~50MB。10,000 Pod = 500GB 浪费。Cilium 仅需微量 Node-level 内存。
CPU 指令缩减： 报文不再频繁穿越 User/Kernel 边界。通过 eBPF 减少上下文切换损耗。
网关整合： Cilium Gateway API 替代了 F5/Nginx 南北向网关，进一步削减了 15% 的基础设施硬件成本。
🌱 绿色计算： 通过内核级流量压缩与路径优化，同等吞吐量下降低了 18% 的节点能耗，助力企业实现可持续性 IT 目标。
⚡ 运维提效： 平均故障自愈时间 (MTTR) 缩短 40%，Hubble 提供的 L7 流量指纹让 SRE 告别了“盲目抓包”的时代。

行业实战：为何全球巨头纷纷转向 Cilium？

从 OpenAI 的 AI 算力底座到 Google 的全云选型，验证了其在大规模生产环境下的稳定性。

OpenAI: 支撑 AI 训练的神经系统

在训练 GPT 等大模型时，上万个 GPU 节点需要频繁进行全梯度同步（All-Reduce）。哪怕网络增加 1 毫秒的延迟，都会导致数百万美元的算力浪费。

极致带宽： 利用 eBPF 优化训练网络吞吐，支持 RoCE/RDMA 加速。
拓扑透视： Hubble 提供了模型训练任务的精确流量拓扑。

架构师点评： 对于 OpenAI 来说，Cilium 是一个性能放大器，确保了极其昂贵的 GPU 算力不被网络阻塞。

Microsoft: Azure 的终极选型

Microsoft 意识到大规模 VNET 的性能与可观测性是核心竞争力。Azure CNI Powered by Cilium 成功实现了性能与原生体验的融合。

原生执行： 性能比传统桥接模式提升 30%。
透明分析： 客户无需 Sidecar 即可看到详尽流量视图。

架构师点评： 公有云巨头的选择证明了 Cilium 已经成为下一代云网络的标准。

Google Cloud: GKE Dataplane V2

Google 将 Cilium 作为 GKE 的默认数据平面，不仅是为了性能，更是为了 FIPS 合规与透明加密。

安全共识： 验证了 eBPF 在多租户环境下的硬隔离能力。

架构师点评： 当所有云巨头都采用同一内核技术时，生态兼容性就是最大的架构红利。

Hubble UI: 每一个流的“身份指纹”

传统的 TCPDump 只能看到 IP 地址，而 Hubble 能够看到 Identity（身份）。这是价值落地的最后一步：让抽象的网络流变得“可感、可知、可审计”。

安全可见性收益：100%

                    // Hubble Flow JSON 观测

                    {

                      "source": { "pod_name": "xwing", "identity": 36770 },

                      "destination": { "pod_name": "deathstar", "identity": 15153 },

                      "verdict": "FORWARDED",

                      "summary": "TCP Flags: SYN",

                      "l7": { "http": { "method": "POST", "url": "/v1/request-landing" } }

                    }

Hubble 能够回答的实战问题：

Questions Hubble Can Answer:

Q: 网络不通，是 DNS 还是 L4 故障？

Q: Network failing? DNS or L4 issue?

A: Hubble 实时监测 DNS 解析成功率及 TCP 重传率。

A: Monitors DNS success and TCP retransmission.

Q: 哪个 Kafka Topic 生产速度变慢了？

Q: Which Kafka Topic is slowing down?

A: L7 解析器直接透视 Kafka API 流量。

A: L7 parsers provide direct visibility into Kafka API.

Hubble：洞察力的四个维度

Hubble: Four Dimensions of Insight

1. 服务依赖与拓扑

1. Service Dependencies

哪些服务在通信？频率如何？服务依赖图的实时形态是怎样的？

Which services are communicating? What does the real-time dependency graph look like?

2. 网络监控与告警

2. Network Monitoring

通信是否失败？是 DNS 问题、L4(TCP) 还是 L7(HTTP) 问题？

Is communication failing? Is it a DNS, Layer 4, or Layer 7 problem?

3. 应用性能监控

3. Application Monitoring

HTTP 4xx/5xx 响应率是多少？服务间延迟的 P95/P99 表现如何？

What is the 4xx/5xx rate? What is the P95/P99 latency between services?

4. 安全可观测性

4. Security Observability

哪些连接被策略拦截了？有哪些异常的外部域名解析？

Which connections were blocked? What services accessed external domains?

落地路径与专家级排障指南

如何平滑地开启 Cilium 之旅，以及在“黑盒”面前保持冷静的工具箱。

兼容性矩阵 (Compatibility)

• 内核版本：推荐 5.10+ (实现最优 eBPF 性能)
• 平台支持：AWS, Azure, GCP, On-premise
• 模式：支持完全替换 kube-proxy (推荐模式)

迁移路径 (Migration Path)

1. 开启 kube-proxy 替换测试，验证控制平面稳定性
2. 灰度 Namespace 开启 L7 策略，进行流量画像
3. 部署 Tetragon 强化安全审计与运行时防护

SRE 核心建议 (Best Practices)

• 始终开启 Hubble 链路追踪以获得全栈可见性
• 优先使用 Identity 身份策略，而非 IP 策略
• 启用 WireGuard 加密保护集群间流量

[ 专家级内核排障工具箱 ]

L3/L4 流观测

使用 hubble observe。
监控 IP 路径、端口冲突及 Packet Drop 原因。

内核函数追踪

使用 pwru。
追踪报文在内核协议栈中每一跳的函数足迹。

状态一致性检查

使用 cilium-dbg bpf。
直接映射内核 BPF Map，验证数据面同步状态。

1. 网络全路径追踪 (Trace Every Packet):

$ pwru --output-tuple '10.0.1.5:443'

# 基于 eBPF 追踪报文在内核中的每一层函数处理

2. 实时内核监视器 (Live Monitor):

$ cilium monitor -v --type drop

# 实时捕获内核态丢包原因（如 Policy 拦截或 Checksum 错误）

3. 状态快照 (State Inspection):

$ cilium-dbg bpf endpoint list

# 直接查看内核 BPF Map 中的 Identity 映射与策略状态

[ SRE 深度进阶：内核 NAT 映射审计 ]

当 Pod 访问外部网络时，Cilium 执行原生的 eBPF Masquerade：

# kubectl exec -n kube-system cilium-2vrgj -- cilium bpf nat list
TCP OUT 172.16.3.155:35834 -> 147.182.252.2:443 XLATE_SRC 10.75.59.73:35834

💡 调试技巧： 如果外部设备无法收到回包，首先通过 cilium monitor -v --type drop 确认内核是否因为 Checksum 错误丢弃了报文。

十年征程：从 CNI 到基础设施操作系统