mobile wallpaper 1mobile wallpaper 2mobile wallpaper 3mobile wallpaper 4
1942 字
6 分钟
Cilium 深入
2026-03-04

Cilium 是 eBPF 技术在云原生领域最成功的实践——它不仅替代了 kube-proxy 和 iptables,更重新定义了 Kubernetes 网络安全模型。从 Google、Apple、Meta 到字节跳动、阿里巴巴,Cilium 已成为大规模 Kubernetes 集群网络的事实标准。

这一章的主角是Cilium 的核心架构——理解它如何用 eBPF 构建高性能、可编程、身份驱动的网络方案。

一、Cilium 架构总览#

1.1 核心组件#

flowchart TB subgraph CiliumAgent["Cilium Agent(每个 Node)"] API["Cilium API"] KVSTORE["KV Store<br/>Cluster Mesh"] IDENTITY["Identity Manager<br/>身份管理"] POLICY["Policy Engine<br/>策略引擎"] PROXY["Envoy Proxy<br/>L7 策略"] end subgraph eBPF管线["eBPF 管线"] XDP["XDP 程序<br/>DDoS/LB"] TC_IN["TC ingress<br/>连接跟踪/NAT"] TC_OUT["TC egress<br/>SNAT/策略"] end subgraph Operator["Cilium Operator"] IPAM["IPAM<br/>IP 地址管理"] CG["Cilium Gateway<br/>Gateway API"] end subgraph Hubble["Hubble"] HSRV["Hubble Server"] HRELAY["Hubble Relay"] HUI["Hubble UI"] end K8S["Kubernetes API"] --> CiliumAgent CiliumAgent --> eBPF管线 CiliumAgent --> Hubble Operator --> K8S style eBPF管线 fill:#c8e6c9,stroke:#2e7d32 style Hubble fill:#bbdefb,stroke:#1565c0

1.2 Cilium 的 eBPF 管线#

Cilium 在每个 Node 上部署一组 eBPF 程序,形成完整的网络处理管线:

阶段eBPF 程序功能
XDPxdp.cDDoS 防护、NodePort 加速
TC ingressbpf_lxc.c连接跟踪、DNAT、策略检查
TC egressbpf_lxc.cSNAT、策略检查
Socketbpf_sock.cSocket 短路优化

二、身份安全模型#

2.1 传统 IP vs Cilium 身份#

传统网络安全基于 IP 地址——防火墙规则匹配源/目标 IP。但在 Kubernetes 中,Pod IP 是动态的,基于 IP 的安全规则不可靠。

Cilium 引入了**基于身份(Identity)**的安全模型:

flowchart TB subgraph 传统模型["传统模型(基于 IP)"] FW1["防火墙规则<br/>src=10.0.1.5 → ALLOW"] FW2["问题:Pod 重建后 IP 变化<br/>规则失效"] end subgraph 身份模型["Cilium 模型(基于身份)"] ID1["身份 = 标签组合<br/>app=frontend → Identity 10001"] ID2["eBPF 规则<br/>Identity 10001 → Identity 10002 → ALLOW"] ID3["优势:Pod 重建后身份不变<br/>规则始终有效"] end style 传统模型 fill:#ffcdd2,stroke:#c62828 style 身份模型 fill:#c8e6c9,stroke:#2e7d32

2.2 身份的工作原理#

  1. 身份分配:Cilium 根据 Pod 的标签(Labels)计算身份 ID
  2. 身份传播:身份信息通过 KV Store 在集群中传播
  3. eBPF 查找:eBPF 程序根据数据包的源/目标 IP 查找身份
  4. 策略匹配:基于身份匹配 NetworkPolicy 规则
# 查看 Cilium 身份
cilium identity list
# 输出示例:
# ID LABELS
# 1 reserved:host
# 2 reserved:world
# 10001 app=frontend,env=prod
# 10002 app=backend,env=prod
# 10003 app=database,env=prod

2.3 NetworkPolicy 实现#

# Cilium NetworkPolicy(基于身份)
apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
name: frontend-to-backend
spec:
endpointSelector:
matchLabels:
app: backend
ingress:
- fromEndpoints:
- matchLabels:
app: frontend
toPorts:
- ports:
- port: "8080"
protocol: TCP

Cilium 将此策略编译为 eBPF 规则:

Identity 10001 (frontend) → Identity 10002 (backend) : TCP/8080 → ALLOW
其他 → Identity 10002 (backend) : DROP

2.4 L7 策略与 Envoy 集成#

L3/L4 策略仅能基于 IP 和端口做访问控制,但生产环境往往需要 HTTP 路径、gRPC 方法等应用层维度的精细策略。Cilium 通过嵌入 Envoy 代理实现 L7 策略:

flowchart TB PKT["入方向数据包"] --> TC_BPF["TC eBPF<br/>L3/L4 策略检查"] TC_BPF -->|"L7 策略命中"| ENVOY["Envoy 代理<br/>HTTP/gRPC 解析"] ENVOY -->|"路径/方法匹配"| POLICY["L7 策略引擎"] POLICY -->|"ALLOW"| APP["应用 Pod"] POLICY -->|"DENY"| DROP["丢弃"] style ENVOY fill:#fff9c4,stroke:#f9a825 style POLICY fill:#c8e6c9,stroke:#2e7d32

当 TC eBPF 程序检测到某个连接命中了 L7 策略,会通过 Socket 级重定向将流量导入 Envoy。Envoy 解析 HTTP/gRPC 协议后,根据 Cilium 下发的 L7 规则做路径匹配、方法过滤、Header 检查,最终决定放行或拒绝。整个过程对应用透明——应用代码无需任何修改。

2.5 身份分配详解#

Cilium 的身份 ID 是一个 32 位无符号整数,由标签组合的哈希值决定。分配算法的核心流程:

  1. 收集 Pod 的全部标签,按字典序排列
  2. 对排序后的标签字符串计算 SHA256 哈希
  3. 取哈希值的前 32 位作为身份 ID
  4. 若与已有身份冲突,递增重试
属性说明
身份范围1–65535(保留 1–255 给系统身份)
保留身份1=host, 2=world, 3=cluster, 4=health
冲突概率标签组合空间远大于 65536,实际冲突率低
传播方式通过 etcd/KV Store 在集群间同步
Warning

身份 ID 上限为 65535。在标签组合极多的大规模集群中(如多租户平台),可能面临身份耗尽。监控 cilium identity list | wc -l,当接近上限时需要合并标签策略以减少身份数量。

三、Cilium eBPF 管线详解#

3.1 数据包处理流程#

sequenceDiagram participant NIC as 网卡 participant XDP as XDP participant TC as TC ingress participant CT as 连接跟踪 participant POL as 策略引擎 participant NAT as NAT participant STACK as 协议栈 NIC->>XDP: 数据包到达 XDP->>XDP: DDoS 检查 XDP->>TC: XDP_PASS TC->>CT: 查找连接跟踪表 alt 已有连接 CT->>NAT: 直接转发 else 新连接 CT->>POL: 策略检查 POL->>POL: 身份查找 + 规则匹配 alt 允许 POL->>NAT: DNAT 到后端 NAT->>CT: 记录连接 else 拒绝 POL->>TC: DROP end end NAT->>STACK: 交给协议栈

3.2 连接跟踪表#

Cilium 维护自己的连接跟踪表(而非使用 Netfilter conntrack):

// Cilium 连接跟踪条目(简化)
struct ct_entry {
__u16 src_port;
__u16 dst_port;
__u32 src_ip;
__u32 dst_ip;
__u8 protocol;
__u8 state; // SYN_ESTABLISHED, ESTABLISHED, FIN, etc.
__u32 src_identity; // 源身份 ID
__u32 dst_identity; // 目标身份 ID
__u64 last_seen; // 最后活跃时间
__u32 backend_ip; // 后端 IP(DNAT)
__u16 backend_port; // 后端端口
};

3.3 eBPF Map 结构#

Map类型用途
CT_MAPLRU_HASH连接跟踪表
LB_MAPHASHService 负载均衡
IDENTITY_MAPHASHIP → 身份映射
POLICY_MAPHASH身份 → 策略规则
METRICS_MAPPERCPU_ARRAY统计指标
TUNNEL_MAPHASH隧道端点映射
NODE_MAPHASH节点信息

3.4 Egress 数据路径#

出方向处理是 Cilium 管线中容易忽视的环节。当 Pod 发出的数据包离开节点时,TC egress 程序依次执行:

  1. 策略检查:基于源身份和目标身份匹配 egress 规则
  2. SNAT:将 Pod IP 替换为节点 IP(跨节点通信时)
  3. 连接跟踪记录:写入 egress 方向的 CT 条目,用于回程匹配
  4. Bandwidth Manager:应用 EDT 时间戳进行速率控制
// egress 方向简化处理逻辑
SEC("tc")
int tc_egress(struct __sk_buff *skb)
{
// 查找源身份
__u32 src_id = lookup_identity(skb->local_ip4);
__u32 dst_id = lookup_identity(skb->remote_ip4);
// egress 策略检查
if (!policy_allow(src_id, dst_id, skb->protocol))
return TC_ACT_SHOT;
// SNAT:Pod IP → Node IP
if (needs_snat(skb))
do_snat(skb);
return TC_ACT_OK;
}

3.5 Bandwidth Manager 与 EDT#

Cilium 的 Bandwidth Manager 使用 EDT(Earliest Departure Time)机制实现容器速率限制,比传统的 TBF(Token Bucket Filter)和 HTB 更高效:

传统方式在每个 qdisc 中排队数据包,EDT 则为每个数据包打上一个时间戳,表示”最早可发送时间”。网卡驱动在发送时检查时间戳,未到时间的包延迟发送。这种方式避免了 qdisc 排队带来的额外延迟和锁竞争。

# 启用 Bandwidth Manager
helm install cilium cilium/cilium \
--set bandwidthManager.enabled=true \
--set bandwidthManager.bbr=true
机制原理优势限制
TBF/HTB令牌桶排队成熟稳定多 qdisc 锁竞争
EDT时间戳调度无锁、低延迟需要 5.1+ 内核

四、Hubble:网络可观测性#

4.1 Hubble 架构#

flowchart TB subgraph 每个Node AGENT["Cilium Agent"] --> HSRV["Hubble Server<br/>eBPF 事件流"] end HSRV -->|"gRPC"| HRELAY["Hubble Relay<br/>聚合多节点"] HRELAY --> HUI["Hubble UI<br/>可视化"] HRELAY --> CLI["hubble CLI<br/>命令行"] HRELAY --> PROM["Prometheus<br/>指标"] style HSRV fill:#c8e6c9,stroke:#2e7d32 style HRELAY fill:#bbdefb,stroke:#1565c0 style HUI fill:#fff9c4,stroke:#f9a825

4.2 Hubble 事件类型#

事件来源信息
DROPTC eBPF丢弃原因、身份、策略
TRACETC eBPF数据包路径追踪
L7EnvoyHTTP/gRPC 请求/响应
DEBUG各组件调试信息

4.3 Hubble CLI 使用#

# 查看 Pod 间流量
hubble observe --since 1m
# 过滤特定 Pod 的流量
hubble observe --to-pod app=backend
# 查看 DROP 事件
hubble observe --type drop
# 查看特定身份的流量
hubble observe --from-identity 10001
# 输出 JSON 格式
hubble observe -o json

五、ClusterMesh:多集群网络#

5.1 ClusterMesh 架构#

flowchart TB subgraph Cluster1["集群 A"] C1A["Cilium Agent"] --> KV1["etcd"] C1B["Cilium Agent"] --> KV1 end subgraph Cluster2["集群 B"] C2A["Cilium Agent"] --> KV2["etcd"] C2B["Cilium Agent"] --> KV2 end KV1 <-->|"身份传播<br/>跨集群路由"| KV2 C1A <-->|"隧道/VXLAN"| C2A style Cluster1 fill:#e3f2fd,stroke:#1565c0 style Cluster2 fill:#e8f5e9,stroke:#2e7d32

5.2 ClusterMesh 的能力#

能力说明
跨集群 Pod 通信Pod 可以直接访问其他集群的 Service
跨集群 NetworkPolicy策略可以引用其他集群的身份
全局 ServiceService 可以跨集群负载均衡
身份全局一致同一标签在不同集群有相同身份 ID

5.3 ClusterMesh 部署#

# 启用 ClusterMesh
cilium clustermesh enable
# 连接两个集群
cilium clustermesh connect --destination-context cluster-b
# 验证连接
cilium clustermesh status
cilium clustermesh vm list

5.4 ClusterMesh 限制与调试#

ClusterMesh 在实际部署中存在一些限制,需要提前了解:

限制说明
跨集群延迟隧道封装增加 ~0.5–2ms 延迟,取决于物理距离
最大集群数官方测试至 255 个集群,生产建议 ≤ 10
etcd 认证跨集群 etcd 访问需要配置 TLS 证书
身份冲突不同集群的标签策略必须协调,避免身份 ID 碰撞

调试 ClusterMesh 连接问题的常用命令:

# 检查跨集群连通性
cilium clustermesh connectivity status
# 查看远程集群的身份同步
cilium identity list --cluster
# 检查 etcd 连接状态
cilium clustermesh status --verbose

六、Cilium 替代 kube-proxy#

6.1 替代模式#

模式说明
disabled不替代,保留 kube-proxy
partial部分 Service 由 eBPF 处理
strict完全替代,移除 kube-proxy

6.2 完全替代的配置#

# Helm 安装 Cilium,完全替代 kube-proxy
helm install cilium cilium/cilium \
--set kubeProxyReplacement=strict \
--set hubble.enabled=true \
--set hubble.relay.enabled=true \
--set hubble.ui.enabled=true \
--namespace kube-system
Warning

完全替代 kube-proxy(strict 模式)需要内核 5.10+ 和 BTF 支持。在生产环境部署前,务必在测试环境验证所有 Service 类型(ClusterIP、NodePort、LoadBalancer、ExternalName)的功能。

七、动手实践#

7.1 部署 Cilium#

# 使用 Helm 部署 Cilium
helm repo add cilium https://helm.cilium.io/
helm install cilium cilium/cilium \
--set kubeProxyReplacement=partial \
--set hubble.enabled=true \
--namespace kube-system
# 验证 Cilium 状态
cilium status
cilium connectivity test

7.2 使用 Hubble 可观测性#

# 启用 Hubble
cilium hubble port-forward&
# 查看实时流量
hubble observe --since 1m
# 查看 DROP 事件
hubble observe --type drop
# 查看 DNS 查询
hubble observe --type l7 --verdict ERROR

7.3 Cilium NetworkPolicy#

# 创建 CiliumNetworkPolicy
kubectl apply -f - <<EOF
apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
name: l7-rule
spec:
endpointSelector:
matchLabels:
app: backend
ingress:
- fromEndpoints:
- matchLabels:
app: frontend
toPorts:
- ports:
- port: "80"
protocol: TCP
rules:
http:
- method: GET
path: "/api/.*"
EOF
# 验证策略
cilium policy get

7.4 故障排查#

Cilium 集群的常见问题排查流程:

# 1. 检查 Cilium Agent 状态
cilium status
# 2. 查看 eBPF 程序加载情况
cilium bpf lb list # Service 负载均衡规则
cilium bpf ct list global # 全局连接跟踪表
cilium bpf tunnel list # 隧道映射
# 3. 导出连接跟踪表
cilium bpf ct dump global
# 4. 查看身份映射
cilium bpf identity list

7.5 cilium bpf 调试命令参考#

命令用途
cilium bpf lb list列出 Service 负载均衡规则
cilium bpf ct list global查看连接跟踪表
cilium bpf ct dump global导出完整连接跟踪数据
cilium bpf tunnel list查看隧道端点映射
cilium bpf identity list查看 IP → 身份映射
cilium bpf policy list查看已加载的策略规则
cilium bpf endpoint list查看端点信息
cilium bpf ipcache list查看 IP 缓存(含身份和节点信息)

八、本章小结#

上一章建立了eBPF 可观测性工具的认知框架。

主题关键要点
身份安全模型基于标签的身份替代 IP 地址,Pod 重建后策略不变;L7 策略通过 Envoy 集成实现
身份分配SHA256 哈希生成,上限 65535,大规模集群需监控耗尽风险
eBPF 管线XDP → TC ingress → 连接跟踪 → 策略 → NAT → 协议栈 → TC egress
Egress 路径策略检查 → SNAT → CT 记录 → EDT 速率控制
Bandwidth ManagerEDT 时间戳调度替代传统令牌桶,无锁低延迟
Hubble实时网络可观测性,可视化 Pod 间流量
ClusterMesh多集群网络,全局身份和跨集群 Service,注意延迟和规模限制
kube-proxy 替代eBPF Map 查找替代 iptables 线性匹配
故障排查cilium bpf 系列命令是调试的核心工具

支持与分享

如果这篇文章对你有帮助,欢迎支持作者或分享给更多人

Cilium 深入
https://blog.souloss.com/posts/ebpf/cilium-deep-dive/
作者
Souloss
发布于
2026-03-04
许可协议
CC BY-NC-SA 4.0

部分信息可能已经过时

相关文章 智能推荐
1
eBPF 网络全景
eBPF eBPF 正在重新定义 Linux 网络栈——从连接跟踪、NAT 到 kube-proxy 替代,从 Socket Filter 到 Sk_msg 重定向,eBPF 提供了比 iptables/netfilter 更高性能、更灵活的网络方案。本章从宏观视角展示 eBPF 网络的全景,详解连接跟踪、NAT、kube-proxy 替代、Socket 层 eBPF,并对比 eBPF 与传统网络方案的架构差异。
2
eBPF 可观测性
eBPF eBPF 最大的应用场景是可观测性——零侵入、低开销、内核级的全链路追踪。本章详解三大可观测性工具链——bpftrace(一行命令追踪内核)、BCC(Python 前端 + 丰富工具集)、Beyla(零侵入应用性能监控),并通过实战展示性能分析、分布式追踪、应用性能监控的完整工作流。
3
eBPF Hook 点:kprobe/tracepoint/uprobe
eBPF eBPF 程序的价值在于它能挂载到内核的各种检查点——Hook 点。本章详解三大 Hook 机制——kprobe(动态内核函数追踪)、tracepoint(静态追踪点)、uprobe(用户态函数追踪),以及 USDT 静态用户态追踪点,并通过实战代码展示每种 Hook 的使用方式与适用场景。
4
eBPF 与内存管理
eBPF eBPF 程序的内存使用是生产部署中的关键考量——Map 占用多少内存?eBPF 程序的栈空间有多大?容器环境中的 eBPF 内存如何计费?本章详解 eBPF 的内存模型、Map 内存开销计算、容器内存追踪、eBPF-mm 子系统,以及内存限制下的优化策略。
5
eBPF 生产部署
eBPF eBPF 生产部署实践——性能开销分析、调试技巧、版本兼容、内核版本要求与升级策略。