【eBPF 系列】eBPF + 容器：Cilium 的数据面为什么不再需要 iptables

你管理的 Kubernetes 集群有 5000 个 Service，每个 Service 后面平均挂 3 个 Endpoint。kube-proxy 忠实地把它们翻译成 iptables 规则——大约十万条。某天一个 Deployment 滚动更新，kube-proxy 调用 iptables-restore 全量刷新规则表，锁住 netfilter 整整 5 秒。这 5 秒里，所有新建连接全部卡住。

这不是假设场景，这是很多大规模集群的日常。

问题不在 kube-proxy 写得烂，而在 iptables 这个抽象本身就不是为这种规模设计的。Cilium 的回答很直接：把数据面从 iptables 规则链搬到 eBPF Map，用 O(1) 哈希查找替代 O(n) 逐条匹配，用原子 Map 更新替代全量 iptables-restore。

如果你还没接触过 eBPF 的基础概念，建议先读 eBPF：Linux 内核的隐藏武器。

一、kube-proxy 的 iptables 困境

它是怎么工作的

kube-proxy watch Kubernetes API，把每个 Service 翻译成 iptables 规则。一个 ClusterIP Service 的规则链大致长这样：

# 一个 Service（my-svc, 10.96.0.100:80）有 3 个 Endpoint
# kube-proxy 生成的 iptables 规则（简化）

# 入口：匹配目标为 Service VIP 的流量
-A KUBE-SERVICES -d 10.96.0.100/32 -p tcp --dport 80 \
  -j KUBE-SVC-XXXXXXXXXXXXXXXX

# Service 链：用 statistic 模块做概率负载均衡
-A KUBE-SVC-XXXXXXXXXXXXXXXX -m statistic --mode random \
  --probability 0.33333 -j KUBE-SEP-AAAA
-A KUBE-SVC-XXXXXXXXXXXXXXXX -m statistic --mode random \
  --probability 0.50000 -j KUBE-SEP-BBBB
-A KUBE-SVC-XXXXXXXXXXXXXXXX -j KUBE-SEP-CCCC

# Endpoint 链：做 DNAT，把 VIP 替换成真实 Pod IP
-A KUBE-SEP-AAAA -p tcp -j DNAT --to-destination 10.244.1.5:8080
-A KUBE-SEP-BBBB -p tcp -j DNAT --to-destination 10.244.2.12:8080
-A KUBE-SEP-CCCC -p tcp -j DNAT --to-destination 10.244.3.8:8080

看起来很直白。问题在于规模化之后发生的事情。

O(n) 匹配的性能灾难

iptables 的规则匹配是线性的。每个新连接的第一个包要从 KUBE-SERVICES 链头开始，逐条匹配，直到命中。5000 个 Service 意味着 5000 次比较——这还只是第一跳。加上 DNAT、SNAT、MASQUERADE 等规则，一个包可能要穿过上万条规则。

  第一个包的路径
  ┌──────────────┐
  │ PREROUTING  │
  │  ↓  │
  │ KUBE-SERVICES│ ← 5000+ 条规则逐条匹配
  │  ↓  │
  │ KUBE-SVC-xxx │ ← 概率匹配（3 条）
  │  ↓  │
  │ KUBE-SEP-xxx │ ← DNAT
  │  ↓  │
  │ POSTROUTING  │ ← SNAT/MASQUERADE
  └──────────────┘

后续包虽然走 conntrack 快速路径，但 nf_conntrack 本身也不便宜——它用的是全局哈希表加自旋锁，高并发下锁竞争严重。

iptables-restore 全量刷新

这才是真正的杀手。kube-proxy 不能单独插入或删除一条规则（iptables 命令虽然支持，但在并发场景下有 race condition）。它的策略是：

1. 导出全部规则
2. 在内存里修改
3. 用 iptables-restore 原子写回

写回期间，整个 netfilter 子系统加写锁。十万条规则的写回在普通节点上要 2-5 秒，这期间所有新连接阻塞。

# 测量 iptables-restore 的耗时
time iptables-save | wc -l
# 输出: 102,347 条规则

time iptables-restore < /path/to/rules.txt
# 真实耗时: 3.7s  ← 这 3.7 秒所有新连接卡住

IPVS 模式：好一点但不够好

kube-proxy 也支持 IPVS 模式（--proxy-mode=ipvs），用 ipvs 的哈希表做负载均衡，匹配复杂度降到 O(1)。但 IPVS 有自己的问题：

关键问题：IPVS 只解决了负载均衡这一环，SNAT、NodePort、NetworkPolicy 仍然要回到 iptables。你没有消灭复杂度，只是把它推到了另一个地方。

二、Cilium 架构概览

Cilium 的目标很明确：用 eBPF 程序完全替代 kube-proxy 和 iptables 在数据面的角色。

三个核心组件

┌─────────────────────────────────────────────────────┐
│  Kubernetes API Server  │
└────────────┬───────────────────────┬────────────────┘
  │  │
  ┌───────▼───────┐  ┌────────▼────────┐
  │ Cilium Operator│  │  Cilium Agent  │ ← 每个节点一个
  │ （全局资源管理）│  │ （本地数据面）  │
  └───────────────┘  └────────┬────────┘
  │
  ┌────────▼────────┐
  │  eBPF 程序  │
  │ tc / XDP / sock  │
  │  挂载到网络设备  │
  └─────────────────┘

• Cilium Agent（DaemonSet）：运行在每个节点，watch K8s API，编译并加载 eBPF 程序，维护 eBPF Map
• Cilium Operator（Deployment）：处理集群级资源，比如 IPAM 分配、CiliumNode 同步
• CNI Plugin：容器创建时被 kubelet 调用，配置 veth pair，触发 Agent 加载 eBPF 程序

eBPF 程序在数据面的位置

这是理解 Cilium 的关键。eBPF 程序挂载在三个位置：

1. tc ingress / egress：挂在每个 Pod 的 veth pair 和 host 网络设备上，处理所有 L3/L4 流量
2. XDP：挂在物理网卡上，处理 NodePort 和 LoadBalancer 的入站流量（最快路径）
3. socket-level（cgroup/connect、cgroup/sendmsg 等）：拦截 socket 系统调用，实现透明的 Service 地址转换

与 kube-proxy 的替代关系很清晰：启动 Cilium 时加上 --set kubeProxyReplacement=true，就可以完全移除 kube-proxy。

# 安装 Cilium 并替代 kube-proxy
helm install cilium cilium/cilium --version 1.16.0 \
  --namespace kube-system \
  --set kubeProxyReplacement=true \
  --set k8sServiceHost=${API_SERVER_IP} \
  --set k8sServicePort=${API_SERVER_PORT}

# 验证 kube-proxy 替代状态
cilium status | grep KubeProxyReplacement
# 输出: KubeProxyReplacement: True [eth0 (DR)]

# 确认没有 iptables 规则残留
iptables-save | grep KUBE | wc -l
# 输出: 0  ← 干净了

三、用 eBPF Map 替代 iptables 规则

这是 Cilium 性能优势的核心：把 iptables 的规则链替换成 eBPF Map 的哈希查找。

Service → Endpoint 映射

Cilium 用 BPF_MAP_TYPE_HASH 存储 Service 到 Endpoint 的映射。数据结构大致如下：

// Service 的 Key：VIP + Port + Protocol
struct lb4_key {
  __be32 address;  // Service ClusterIP，如 10.96.0.100
  __be16 dport;  // Service Port，如 80
  __u8  proto;  // TCP = 6, UDP = 17
  __u8  scope;  // 内部/外部
  __u32  backend_slot; // 0 = Service 元信息，>0 = 具体后端
};

// Service 的 Value：后端数量 + 标志
struct lb4_service {
  union {
  __u32 backend_id;  // 当 backend_slot > 0 时，指向具体后端
  __u32 count;  // 当 backend_slot = 0 时，后端总数
  };
  __u16 rev_nat_index;  // 反向 NAT 索引
  __u16 flags;  // DSR、SessionAffinity 等标志
};

// 后端信息
struct lb4_backend {
  __be32 address;  // Pod 真实 IP，如 10.244.1.5
  __be16 port;  // Pod 真实端口，如 8080
  __u8  proto;
  __u8  flags;
};

查找过程需要三次哈希查找：(1) Service Map 以 slot=0 查询，获取 backend 数量；(2) Service Map 以 slot=N 查询，获取 backend_id；(3) Backend Map 以 backend_id 查询，获取实际 endpoint 地址。

// 伪代码：Cilium 的 Service 查找逻辑
static __always_inline int lb4_lookup_service(struct __sk_buff *skb) {
  struct lb4_key key = {
  .address = ip4->daddr,  // 目标 IP（Service VIP）
  .dport  = tcp->dest,  // 目标端口
  .proto  = ip4->protocol,
  };

  // 第一次查找：获取 Service 元信息（backend_slot = 0）
  key.backend_slot = 0;
  struct lb4_service *svc = map_lookup_elem(&cilium_lb4_services, &key);
  if (!svc)
  return TC_ACT_OK;  // 不是 Service 流量，放行

  // 选择后端（简单取模，实际用 Maglev 一致性哈希）
  __u32 slot = bpf_get_prandom_u32() % svc->count + 1;

  // 第二次查找：获取具体后端
  key.backend_slot = slot;
  struct lb4_service *backend_slot = map_lookup_elem(&cilium_lb4_services, &key);

  // 第三次查找：获取后端 IP 和端口
  struct lb4_backend *backend = map_lookup_elem(&cilium_lb4_backends,
  &backend_slot->backend_id);

  // 执行 DNAT：修改目标 IP 和端口
  // 从 10.96.0.100:80 → 10.244.1.5:8080
  skb_store_bytes(skb, /* ip dst offset */, &backend->address, 4, 0);
  skb_store_bytes(skb, /* tcp dst offset */, &backend->port, 2, 0);

  return TC_ACT_OK;
}

三次哈希查找，O(1) 完成。不管你有 5 个 Service 还是 50000 个，查找时间不变。

Conntrack：用 eBPF Map 替代 nf_conntrack

传统 Linux 用 nf_conntrack 做连接跟踪，它有几个问题：

• 全局哈希表 + 自旋锁，高并发下严重争用
• 表满了会丢包（nf_conntrack: table full, dropping packet）
• 和 iptables 耦合，每个包都要查

Cilium 用自己的 eBPF conntrack Map：

// Cilium 的连接跟踪条目
struct ct_entry {
  __u64 rx_packets;  // 接收包数
  __u64 rx_bytes;  // 接收字节
  __u64 tx_packets;  // 发送包数
  __u64 tx_bytes;  // 发送字节
  __u32 lifetime;  // 过期时间
  __u16 rx_closing  : 1;  // 收到 FIN
  __u16 tx_closing  : 1;  // 发送了 FIN
  __u16 nat46  : 1;  // NAT46 转换
  __u16 lb_loopback : 1;  // loopback hairpin
  __u16 seen_non_syn: 1;  // 看到非 SYN 包
  __u16 node_port  : 1;  // NodePort 流量
  __u32 rev_nat_index;  // 反向 NAT 索引
  __be32 backend_id;  // 后端 ID（用于 session affinity）
};

优势很明显：

Map 热更新：零中断

当一个新 Endpoint 上线时：

# 传统 kube-proxy：
# 1. 收到 Endpoint 变更事件
# 2. 重新生成全部 iptables 规则
# 3. iptables-restore 全量写入 ← 锁住 netfilter

# Cilium：
# 1. 收到 Endpoint 变更事件
# 2. 计算新的 Map 条目
# 3. bpf_map_update_elem() 原子更新单条 ← 零锁、零中断

一个 bpf_map_update_elem 调用耗时在微秒级，不影响任何正在处理的连接。

四、Service Mesh without Sidecar

Sidecar 模型的代价

传统 Service Mesh（如 Istio）给每个 Pod 注入一个 Envoy sidecar。架构很优雅，代价很实在：

  Pod
┌──────────────────────────────────┐
│  ┌──────────┐  ┌─────────────┐ │
│  │  App 容器 │───→│ Envoy Proxy │ │  ← 每个 Pod 一个
│  │  │←───│ (Sidecar)  │ │  ~50MB 内存
│  └──────────┘  └─────────────┘ │  ~2ms 额外延迟
└──────────────────────────────────┘

具体开销：

• 内存：每个 Envoy 实例占 50-100 MB，1000 个 Pod = 50-100 GB 纯 sidecar 内存
• 延迟：每跳增加 2-3ms（入站 Envoy + 出站 Envoy = 两次用户态代理）
• CPU：TLS 握手、协议解析都在用户态，CPU 开销显著
• 启动时间：Envoy 初始化和 xDS 配置拉取需要数秒，影响 Pod 启动速度

Cilium 的做法：内核层 L7 代理

Cilium Service Mesh 的核心思路是：能在内核做的事不要到用户态做。

  Cilium Service Mesh (无 Sidecar)
┌──────────────┐  ┌──────────────┐
│  Pod A  │  │  Pod B  │
│  ┌────────┐  │  │  ┌────────┐  │
│  │  App  │  │  │  │  App  │  │
│  └───┬────┘  │  │  └───▲────┘  │
└──────┼───────┘  └──────┼───────┘
  │ socket  │ socket
  ═════╪════════════════════════════════════╪═══════
  │  Linux Kernel  │
  │  │
  ▼  │
  eBPF: sockops/sk_msg  │
  socket-level redirect ──────────────────┘
  （跳过整个 TCP/IP 栈！）

关键技术点：

1. Socket-level redirect

当 Pod A 连接 Pod B 的 Service VIP 时，Cilium 的 cgroup/connect4 eBPF 程序拦截 connect() 系统调用：

// cgroup/connect4 程序：拦截 connect() 调用
SEC("cgroup/connect4")
int sock4_connect(struct bpf_sock_addr *ctx) {
  // ctx->user_ip4 = Service VIP (10.96.0.100)
  // ctx->user_port = Service Port (80)

  // 查找 Service Map，选择后端
  struct lb4_backend *backend = lb4_lookup_and_select(ctx);
  if (!backend)
  return 1;  // 不是 Service 流量，放行

  // 直接修改 connect() 的目标地址
  // 应用进程感知到的是 Service VIP
  // 实际建连的是 Pod IP
  ctx->user_ip4  = backend->address;  // → 10.244.1.5
  ctx->user_port = backend->port;  // → 8080

  return 1;
}

下面用更详细的伪代码展示 cgroup/connect4 内部的完整决策流程——包括地址族检查、协议过滤、Service 查找和 sockaddr 重写：

// 伪代码：Cilium cgroup/connect4 的完整 socket redirect 流程
SEC("cgroup/connect4")
int sock4_connect_full(struct bpf_sock_addr *ctx)
{
  // ── 第一步：地址族检查 ──
  // cgroup/connect4 只处理 IPv4，IPv6 由 cgroup/connect6 处理
  if (ctx->family != AF_INET)
  return 1;  // 放行，不是 IPv4

  // ── 第二步：协议过滤 ──
  // 只处理 TCP 和 UDP（Service 负载均衡的对象）
  // ICMP、RAW socket 等直接放行
  __u8 protocol = ctx->protocol;
  if (protocol != IPPROTO_TCP && protocol != IPPROTO_UDP)
  return 1;

  // ── 第三步：构造 Service lookup key ──
  struct lb4_key svc_key = {};
  svc_key.address = ctx->user_ip4;  // 目标 IP（可能是 ClusterIP）
  svc_key.dport  = ctx->user_port;  // 目标端口
  svc_key.proto  = protocol;
  svc_key.scope  = LB_LOOKUP_SCOPE_INT;  // 集群内部
  svc_key.backend_slot = 0;  // slot=0 查 Service 元信息

  // ── 第四步：查 Service Map ──
  struct lb4_service *svc = map_lookup_elem(&cilium_lb4_services, &svc_key);
  if (!svc) {
  // 目标地址不是 Service VIP → 直接放行
  // 普通的 Pod-to-Pod 通信走这条路径
  return 1;
  }

  // ── 第五步：选择后端 Pod ──
  // Cilium 支持多种负载均衡算法：
  //  - Random（默认）
  //  - Maglev 一致性哈希（推荐生产使用）
  //  - Session Affinity（基于 client IP 的会话保持）
  __u32 backend_count = svc->count;
  __u32 slot;

  if (svc->flags & SVC_FLAG_AFFINITY) {
  // Session Affinity：用 client IP 哈希选择固定后端
  slot = hash(ctx->user_ip4) % backend_count + 1;
  } else {
  // Random 或 Maglev
  slot = bpf_get_prandom_u32() % backend_count + 1;
  }

  // ── 第六步：查后端信息 ──
  svc_key.backend_slot = slot;
  struct lb4_service *be_slot = map_lookup_elem(&cilium_lb4_services, &svc_key);
  if (!be_slot)
  return 1;  // 防御性检查

  struct lb4_backend *backend = map_lookup_elem(&cilium_lb4_backends,
  &be_slot->backend_id);
  if (!backend)
  return 1;

  // ── 第七步：重写 sockaddr ──
  // 这是核心：修改 connect() 系统调用的目标地址
  // 应用层看到的是 Service VIP (10.96.0.100:80)
  // 实际 TCP 连接的目标是 Pod IP (10.244.1.5:8080)
  ctx->user_ip4  = backend->address;
  ctx->user_port = backend->port;

  // ── 第八步：记录 NAT 信息（用于反向查找） ──
  // 当 Pod B 回复时，需要把源地址从 Pod IP 改回 Service VIP
  // 这样应用层感知不到后端切换
  struct ct_state ct = {
  .rev_nat_index = svc->rev_nat_index,
  .backend_id  = be_slot->backend_id,
  };
  ct_create4(&cilium_ct4_global, &ct, ctx);

  return 1;  // 1 = 允许 connect() 继续（用修改后的地址）
}

为什么这比 iptables DNAT 更快？ iptables DNAT 在 PREROUTING 链工作——这时包已经进入了内核协议栈，经过了 sk_buff 分配、IP 层解析等。而 cgroup/connect4 在 socket 系统调用层工作——connect() 还没发出第一个 SYN 包，地址就已经被改好了。没有 sk_buff、没有 netfilter、没有 conntrack lookup，因为”连接”还不存在。

这比 iptables DNAT 更早介入——在 socket 层就完成了地址转换，根本不需要经过 netfilter。

2. 同节点 Pod 通信跳过 TCP/IP 栈

如果 Pod A 和 Pod B 在同一节点，Cilium 用 sockops + sk_msg 程序实现 socket 之间的直接转发：

// sockops 程序：在 TCP 事件时更新 socket map
SEC("sockops")
int bpf_sockops(struct bpf_sock_ops *skops) {
  // 连接建立时，把 socket 记录到 Map
  if (skops->op == BPF_SOCK_OPS_ACTIVE_ESTABLISHED_CB ||
  skops->op == BPF_SOCK_OPS_PASSIVE_ESTABLISHED_CB) {
  // 把 (src_ip, src_port, dst_ip, dst_port) → socket
  // 写入 SOCKMAP
  sock_hash_update(skops, &cilium_sock_map, &key, BPF_NOEXIST);
  }
  return 0;
}

// sk_msg 程序：拦截 sendmsg，直接转发到对端 socket
SEC("sk_msg")
int bpf_sk_msg_verdict(struct sk_msg_md *msg) {
  // 查找对端 socket
  // 如果找到，直接把数据从 A 的发送缓冲区拷贝到 B 的接收缓冲区
  // 完全跳过 TCP/IP 栈、netfilter、tc 等所有中间层
  return msg_redirect_hash(msg, &cilium_sock_map, &peer_key, BPF_F_INGRESS);
}

数据从 Pod A 的 socket 直接到 Pod B 的 socket，跳过了整个 TCP/IP 栈。没有 sk_buff 分配，没有协议栈遍历，没有 netfilter hook。

3. mTLS 在 Node 级别做

传统方案每个 Pod 的 sidecar 独立做 TLS 握手。Cilium 把 mTLS 下沉到节点级别的 Envoy 代理（每节点一个，而非每 Pod 一个），或者用 WireGuard 做节点间加密：

# 使用 WireGuard 做节点间透明加密
helm install cilium cilium/cilium \
  --set encryption.enabled=true \
  --set encryption.type=wireguard

# 验证加密状态
cilium encrypt status
# 输出:
# Encryption: Wireguard
# Keys in use: 1
# Interfaces: cilium_wg0

性能对比

下面是 Cilium（eBPF kube-proxy 替代）、kube-proxy（iptables 模式）、kube-proxy（IPVS 模式）在不同 Service 规模下的性能对比。数据来源于 Cilium 官方 benchmark、Isovalent 的对比测试以及社区复现的公开结果。测试环境：8 核 / 32GB 节点，100 并发客户端。

几个关键观察：

1. Cilium 的延迟几乎不随 Service 数量增长——这就是 O(1) 哈希查找 vs O(n) 线性匹配的本质差异。从 100 到 50,000 个 Service，P99 延迟只从 0.35ms 增长到 0.48ms。
2. iptables 在 10K+ Service 时崩溃式恶化——P99 延迟从亚毫秒跳到两位数毫秒，CPU 占用飙升。这还没算 iptables-restore 全量刷新时的秒级卡顿。
3. IPVS 在负载均衡方面接近 Cilium——IPVS 用的也是哈希表，查找本身是 O(1)。但 IPVS 的 SNAT/NodePort 仍然依赖 iptables，所以在完整路径上不如 Cilium 干净。
4. Cilium 的内存占用更高——eBPF Map 需要预分配空间，加上 Cilium Agent 的内存。但这是用内存换延迟和 CPU 的合理 tradeoff。

注意：以上数字是新建连接（首包）的延迟。已建立连接的后续包都走 conntrack 快速路径，三种方案差距较小。但 conntrack 本身的实现也不同——Cilium 用 per-CPU eBPF Map（无锁），nf_conntrack 用全局哈希表+自旋锁——在高并发场景下这个差距同样显著。

还有一个经常被忽略的维度：规则更新延迟。

数据来源：Cilium 官方 benchmark 和 Isovalent 的对比测试，实际数字因配置而异。

关于 eBPF 与 io_uring 的结合如何进一步提升网络性能，可以参考 eBPF + io_uring：Linux 高性能网络栈的终极形态。

五、Cilium 的 eBPF 程序拆解

Cilium 的 eBPF 代码库在 bpf/ 目录下，核心程序按功能分文件：

bpf_lxc.c —— 容器网络入口/出口

这是最核心的程序，挂载在每个 Pod 的 veth pair 的 tc hook 上：

// bpf_lxc.c 的核心入口点
SEC("tc")
int cil_from_container(struct __sk_buff *skb) {
  // 从容器发出的流量
  // 1. 提取 IP/TCP/UDP 头
  // 2. 查 NetworkPolicy（eBPF Map）
  // 3. 查 Service Map → 做 DNAT
  // 4. 确定下一跳（同节点 redirect / overlay encap / 直接路由）
  // 5. 写 conntrack 条目
  return handle_xgress(skb, SRC_CONTAINER);
}

SEC("tc")
int cil_to_container(struct __sk_buff *skb) {
  // 进入容器的流量
  // 1. 查 conntrack（确认是已建立连接的回复包）
  // 2. 查 NetworkPolicy
  // 3. 做反向 NAT（revDNAT）
  // 4. 投递到容器
  return handle_xgress(skb, DST_CONTAINER);
}

bpf_host.c —— Host 网络

处理进出 Host 网络命名空间的流量：

// bpf_host.c
SEC("tc")
int cil_to_host(struct __sk_buff *skb) {
  // 流量目标是 Host 自身
  // 处理 HostFirewall 策略
  // 处理发给 localhost 的 Service 流量
}

SEC("tc")
int cil_from_host(struct __sk_buff *skb) {
  // Host 发出的流量
  // 可能是 kubelet、kube-apiserver 等访问 Service
}

bpf_overlay.c —— VXLAN/Geneve Overlay

当 Cilium 工作在 overlay 模式时，处理封装/解封装：

// bpf_overlay.c
SEC("tc")
int cil_from_overlay(struct __sk_buff *skb) {
  // 从 VXLAN/Geneve 隧道收到的流量
  // 1. 解封装
  // 2. 查目标 Endpoint
  // 3. redirect 到目标 Pod 的 veth
}

SEC("tc")
int cil_to_overlay(struct __sk_buff *skb) {
  // 需要发送到远端节点的流量
  // 1. 查远端节点信息（IP、tunnel key）
  // 2. 封装成 VXLAN/Geneve
  // 3. 发出
}

核心数据结构全景

// Cilium eBPF Map 全景（简化）
// ──────────────────────────────────────────────────
// Map 名称  Key  Value
// ──────────────────────────────────────────────────
// cilium_lb4_services  lb4_key  lb4_service
//  → Service VIP → 后端列表
//
// cilium_lb4_backends  backend_id  lb4_backend
//  → 后端 ID → Pod IP:Port
//
// cilium_ct4_global  ct_tuple  ct_entry
//  → 连接五元组 → 连接跟踪状态
//
// cilium_ipcache  ip_addr  remote_ep_info
//  → IP → 所属 Endpoint 的身份信息
//
// cilium_policy  endpoint_id+port  policy_entry
//  → Endpoint + 端口 → 策略允许/拒绝
//
// cilium_endpoints  endpoint_key  endpoint_info
//  → Endpoint Key → 本地 Endpoint 信息（ifindex 等）

可以用 bpftool 实际查看这些 Map：

# 列出所有 Cilium 相关的 eBPF Map
bpftool map list | grep cilium

# 查看 Service Map 的内容
bpftool map dump pinned /sys/fs/bpf/tc/globals/cilium_lb4_services_v2

# 查看 conntrack 表
bpftool map dump pinned /sys/fs/bpf/tc/globals/cilium_ct4_global

# 查看一个 Endpoint 上挂载的 eBPF 程序
tc filter show dev lxc_health egress
# 输出:
# filter protocol all pref 1 bpf chain 0
# filter protocol all pref 1 bpf chain 0 handle 0x1
#  bpf_lxc.o:[cil_from_container] direct-action ...

六、局限和选型建议

Cilium 不是银弹。在决定用它之前，你需要清楚这些限制。

内核版本要求

内核版本  Cilium 支持程度
─────────────────────────────────────
< 4.19  否 不支持
4.19 - 5.3  基本功能（kube-proxy 替代）
5.4 - 5.9  大部分功能（Host Reachable Services 需要 5.7+）
≥ 5.10  全功能（推荐）
≥ 6.1  最佳性能（BIG TCP、bpf_loop 等）

很多企业还在跑 CentOS 7（kernel 3.10）或 RHEL 8（kernel 4.18）。这直接把 Cilium 排除在外。

调试困难度上升

iptables 虽然慢，但可观测性极好：

# iptables 调试：简单直接
iptables -L -n -v  # 看规则和计数器
iptables -t nat -L -n -v  # 看 NAT 规则
conntrack -L  # 看连接跟踪表

# Cilium eBPF 调试：学习曲线陡峭
bpftool prog list  # 列出 eBPF 程序
bpftool map dump id <map_id>  # dump Map 内容（输出是二进制）
cilium bpf ct list global  # Cilium CLI 封装
cilium monitor  # 实时查看 eBPF 事件
hubble observe  # Hubble 可观测层（推荐）

iptables -L 人人会用，bpftool map dump 需要理解数据结构。Cilium 通过 Hubble 提供了更好的可视化，但底层调试仍然比 iptables 复杂。

与 NetworkPolicy 的兼容性

好消息：Cilium 完全支持 Kubernetes 原生 NetworkPolicy，还额外支持 CiliumNetworkPolicy（支持 L7 规则、FQDN 规则等）。

但有一个常见的坑：如果你从 Calico/Flannel 迁移过来，已有的 iptables-based NetworkPolicy 实现要小心验证。Cilium 的 NetworkPolicy 实现在语义上和其他 CNI 基本一致，但边缘场景可能有细微差异（比如对 except CIDR 的处理）。

选型决策树

你的集群有多少 Service？
├── < 500 → Calico / Flannel 够用，iptables 性能不是瓶颈
├── 500 - 2000 → 考虑 kube-proxy IPVS 模式
└── > 2000 → 强烈建议 Cilium
  │
  ├── 需要 Service Mesh？
  │  ├── 是 → Cilium + Hubble（省掉 Istio sidecar 的开销）
  │  └── 否 → Cilium 单独做 CNI + kube-proxy 替代
  │
  ├── 内核版本 >= 5.10？
  │  ├── 是 → 全功能 Cilium，推荐
  │  └── 否 → 升级内核或接受功能限制
  │
  └── 团队有 eBPF 调试能力？
  ├── 是 → 放心上
  └── 否 → 先培训，Hubble 能降低门槛但救不了所有场景

一句话总结：如果你的 iptables 规则已经超过万条且还在增长，Cilium 不是可选项，而是必选项。

结语

kube-proxy + iptables 是 Kubernetes 网络的”默认答案”，它在小规模下工作得很好。但当 Service 数量过千、Pod 数量过万，iptables 的 O(n) 匹配和全量刷新就变成了真正的瓶颈。

Cilium 的解法不是修补 iptables，而是换掉整个数据面：

• eBPF Map 哈希查找替代 iptables 规则链遍历——O(1) vs O(n)
• 原子 Map 更新替代 iptables-restore 全量刷新——微秒 vs 秒级
• socket-level redirect 替代 sidecar 代理——内核态直通 vs 用户态绕行
• Per-CPU conntrack Map 替代 nf_conntrack——无锁 vs 自旋锁

代价是更高的内核版本要求、更陡的学习曲线、更少的社区”人人都会”的工具链。但对于规模在增长的集群，这个代价是值得付的。

eBPF 正在重新定义 Linux 的数据面。Cilium 只是这场变革里最显眼的一个应用。更多关于 eBPF 的基础原理和实战案例，参见 eBPF：Linux 内核的隐藏武器。

参考

1. Cilium 官方文档 —— 架构、安装、配置的权威来源
2. Cilium 源码 bpf/ 目录 —— eBPF 程序的实际实现
3. Thomas Graf (2020). How to Make Linux Microservice-Aware with Cilium and eBPF. —— Cilium 创始人的架构演讲
4. Martynas Pumputis (2022). Kubernetes without kube-proxy. —— kube-proxy 替代的深度技术分析
5. eBPF：Linux 内核的隐藏武器 —— eBPF 基础概念和验证器限制
6. eBPF + io_uring：Linux 高性能网络栈的终极形态 —— eBPF 与 io_uring 的协作
7. Linux Kernel BPF Documentation —— 内核 BPF 子系统的官方文档