系列导航

本系列从 Pod 网络连通入手，逐步展开到 K8s 网络全景。

① 概念 → ② Flannel → ③ Calico → ④ 流量路径 → ⑤ Cilium → ⑥ 对比 → ⑦ 排障 ‖ ⑧ 开发 → ⑨ 多网卡 → ⑩ AI 演进

Cilium 的核心设计思想：用 eBPF 在 Linux 内核中编程网络数据路径——绕过传统的 iptables/ipvs，在内核态直接完成包的处理、转发、策略执行和可观测性数据采集。也意味着 kube-proxy 不再是必需品。

1. Cilium 架构

组件

Cilium Agent —— 每个节点上的 DaemonSet，监听 K8S API，将网络策略、服务端点转换为 eBPF 程序加载到内核。

eBPF Programs —— 编译后的字节码，挂载到 Linux 内核钩子点（XDP、TC Ingress/Egress、Socket），在数据包流经时执行。不经过用户态，不需要 iptables 规则遍历。

Hubble —— 基于 eBPF 的可观测层。每个节点运行 Hubble 实例，采集 eBPF 数据路径中产生的流日志、服务依赖关系、丢包事件。

Pod-Node 通信模型

Cilium 的 veth pair 对端直接挂在宿主机协议栈，每个 Pod 网卡在宿主机侧有一个对应接口（lxc_*）。Pod 流量进入宿主机后，TC（Traffic Control）挂载点上的 eBPF 程序接管，执行路由查找、策略检查、Service DNAT、封装/解封，全部在内核态完成。

与 Calico 的对比：

2. Cilium 后端模式

Cilium 四种后端，由简单到复杂：先看与已知 CNI 最相似的 Overlay（VXLAN → Geneve），再看 Cilium 独有的 Underlay（Direct Native → Direct Node）。

2.1 Overlay: VXLAN 模式

2.1.1 组件概念

Cilium VXLAN 与 Calico VXLAN 的相同点：veth pair 两端都不降级，宿主机侧保留完整网卡能力，不经过 cni0 网桥。

关键差异——Calico 需要三样独立机制：路由表、vxlan.calico VTEP 设备、FDB 表。Cilium 把它们全部收进 eBPF：

2.1.2 封装流程

S.Pod eth0 → veth pair → S.Host lxc_* 接口
  → TC Ingress hook: eBPF 程序接管
     1. 查 eBPF Tunnel Map：D.Pod IP → D.Host IP
     2. Service DNAT（如果是 Service 流量）
     3. 策略检查（L3/L4/L7）
     4. VXLAN 封装：外层 MAC + IP + UDP + VNI + 内层包
  → S.Host eth0 → 物理网络
  → D.Host eth0 → TC Ingress eBPF: 解 VXLAN 封装
  → D.Host lxc_* → veth → D.Pod eth0

完整的路由、封装、策略执行压缩到一个 eBPF 程序中。Calico VXLAN 的每一步对应一个独立的内核组件（路由表 / vxlan.calico / iptables），Cilium 全部统一在 eBPF Map + TC 钩子。

2.1.3 路由规则对比

Cilium 与 Calico 一样，veth 不降级 → 每个 Pod 一条 /32 路由。但路由不在宿主机主路由表中，而是在 eBPF Map 内：

1
2
3
4
5
6
7
8

# Cilium 宿主机路由表（只保留必要的系统路由）
[root@node1 ~]# ip route
10.244.1.0/24 dev cilium_host proto kernel scope link src 10.244.1.1
# Pod 级别路由不在 ip route 中，在 eBPF Map 里

# 查看 eBPF 隧道端点
cilium bpf tunnel list
# 10.244.2.5  → 192.168.1.2  (D.Pod IP → D.Host IP)

2.2 Overlay: Geneve 模式

2.2.1 组件概念

Geneve（Generic Network Virtualization Encapsulation）是 VXLAN 的演进协议。与 VXLAN 的固定报头不同，Geneve 支持 TLV（Type-Length-Value）扩展：

2.2.2 封装流程

流程与 VXLAN 完全相同，差异仅在 eBPF 程序的封装步骤——用 Geneve 头替换 VXLAN 头：

1
2

VXLAN 封装：| Outer MAC | Outer IP | UDP | VXLAN(8B fixed) | Inner L2 | Inner IP | Data |
Geneve 封装：| Outer MAC | Outer IP | UDP | Geneve(8B base + TLV) | Inner L2 | Inner IP | Data |

TLV 扩展示例——Cilium 利用 Geneve TLV 在多租户场景传递策略 ID：

1
2
3

# 查看 Geneve 隧道端点
cilium bpf tunnel list
# 10.244.2.5  → 192.168.1.2  geneve  (携带 security-id=42)

2.3 Underlay: Direct Native 模式

2.3.1 组件概念

Direct Native 是 Cilium 性能最高的模式。节点 L2 互通时，Pod 流量不经过任何隧道——eBPF 在 TC 钩子完成路由查表后直接封装 L2 头发出。

2.3.2 主要流程

S.Pod eth0 → veth pair → S.Host lxc_* 接口
  → TC Ingress eBPF:
     1. 查 eBPF Map 确定 D.Pod 所在节点 IP
     2. Service DNAT
     3. 策略检查
     4. 封装 L2 头（目标 MAC = D.Host MAC）
  → S.Host eth0 → 物理网络
  → D.Host eth0 → TC Ingress eBPF → lxc_* → D.Pod

2.4 Underlay: Direct Node 模式

2.4.1 组件概念

Direct Node 去掉了 L2 互通的前提——Pod 子网路由由外部组件（Calico BIRD、BGP 路由器、手动 ip route）维护，Cilium 只负责 eBPF 层面的转发和策略。

1
2
3

# 示例：Calico BIRD 维护路由，Cilium eBPF 处理转发
[root@node1 ~]# ip route
10.244.2.0/24 via 192.168.1.2 dev eth0  # 由 BIRD 写入

3. eBPF 替换 kube-proxy

这是 Cilium 区别于其他 CNI 的核心能力。传统方案中 kube-proxy 监控 Service/Endpoint 变化，写入 iptables 规则或 IPVS 表完成 Service 到 Pod 的 DNAT。Cilium 直接将 Service → Endpoint 映射写入 eBPF Map，由 TC 钩子上的 eBPF 程序完成 DNAT。

1
2

传统：Pod → eth0 → iptables 链匹配（遍历）→ DNAT → 后端 Pod
Cilium：Pod → eth0 → TC eBPF（O(1) Map 查找）→ DNAT → 后端 Pod

两者对比：

适用场景： Service 数量 >1000 的集群从 iptables 迁移到 Cilium eBPF 后，Service 变更引起的连接中断和延迟尖峰现象消失。

4. 网络策略

Cilium 支持三层策略粒度：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21

# CiliumNetworkPolicy 示例：L7 策略
apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: api-policy
spec:
  endpointSelector:
    matchLabels:
      app: backend
  ingress:
  - fromEndpoints:
    - matchLabels:
        app: frontend
    toPorts:
    - ports:
      - port: "8080"
        protocol: TCP
      rules:
        http:
        - method: "GET"
          path: "/api/v1/.*"

对于 L7 策略，eBPF 将匹配的流量通过套接字重定向到本节点 Envoy 代理，Envoy 做协议解析和策略比对后回注。这比传统 iptables + Service Mesh sidecar 方案少了一跳网络转发。

5. Hubble 可观测性

Hubble 是 Cilium 的原生可观测层，数据来源是 eBPF 程序在数据路径上埋的监控点。

开箱能力：

• 服务依赖图 —— 自动生成 namespace/service 之间的调用关系拓扑
• 流日志 —— 每条连接的五元组 + L7 协议信息（HTTP method/path/status code）
• 丢包原因 —— eBPF 在策略拒绝、路由失败时记录精确的丢包原因
• 网络性能 —— TCP 握手延迟、重传次数

1
2
3
4
5

# 查看服务依赖
hubble observe --namespace default

# 查看指定 Pod 的 HTTP 流量
hubble observe --from-pod frontend-xxx -t l7

与传统 tcpdump 的区别：Hubble 的数据直接来自内核 eBPF Map，不需要抓包，无性能损耗。每个节点每分钟可处理百万级事件。

6. 总结

Cilium 适合对网络性能、可观测性和 L7 策略有需求的生产环境。eBPF 是 K8S 网络的未来方向，但不适合低内核版本的存量集群——升级内核是新部署的成本。

参考链接

• Cilium 官方文档
• eBPF - 什么是 eBPF
• Cilium 替换 kube-proxy
• Hubble 可观测性