eBPF 正在重写 Kubernetes 网络与安全：从 kube-proxy 替代到内核级零信任，一次把 Cilium 云原生实战讲透（2026 深度长文）

如果说过去十年 Kubernetes 的网络层是被 iptables 和 kube-proxy 勉强"缝"起来的，那么 2026 年的事实标准是：eBPF 已经把这条链路彻底重写了一遍。Cilium 不只是又一个 CNI 插件，它代表了一种新范式——把网络、安全、可观测性三件事统一收编到 Linux 内核里，用一段段沙箱程序替代用户态的那一大堆 iptables 规则、conntrack 表、sidecar 代理和日志采集 Agent。

这篇文章不堆概念，我们从"为什么 iptables 扛不住"讲起，把 eBPF 的执行模型拆开，逐层讲清 Cilium 的数据面/控制面架构，再上真实可运行的代码（NetworkPolicy、Tetragon 运行时策略、一段自己写的 eBPF 程序），最后落到生产环境的性能调优数字与取舍。读完你应该能回答三个问题：Cilium 凭什么取代 kube-proxy？基于身份的安全模型到底解决了什么？以及——它真的能在 1000 节点规模上把延迟打下来吗？

一、背景：为什么云原生把 iptables 逼到了墙角

传统 Kubernetes 网络的"三件套"是：CNI 插件负责 Pod 间互通、kube-proxy 用 iptables 规则实现 Service 负载均衡、NetworkPolicy 用 iptables 做 L3/L4 隔离。这套组合在几百个节点的时代工作得还行，但一旦进入微服务化、频繁发布的生产集群，三个结构性矛盾就开始放大：

1. IP 不再是稳定身份。 微服务架构下，Pod 的 IP 在每次发布、扩缩容、节点故障迁移时都在变。而 iptables 的匹配完全基于"源 IP + 目标 IP + 端口"。结果是：要维护成千上万条规则，且这些规则还要以秒级频率被 kube-proxy 重写。规则越多，每次全量刷新的代价越高——iptables-restore 是 O(n²) 的，节点规模上到几百、规则上到万级时，一次服务变更可能导致网络抖动数百毫秒。

2. conntrack 表成为隐形瓶颈。 为了做 NAT 和状态追踪，kube-proxy 的 iptables 模式依赖 Netfilter 的 conntrack 表。高并发短连接场景下，conntrack 表会被迅速打满，触发 nf_conntrack: table full。这是生产事故里非常经典的一类："连接数一高，新请求就超时，但 CPU 和内存都不满"。

3. L7 策略与安全可见性天然缺失。 你想按"只允许 GET /api/v1/orders"这种 HTTP 语义做访问控制？iptables 看不懂应用层。传统做法要么上服务网格（每个 Pod 注入 sidecar，资源开销 + 架构复杂度飙升），要么在应用里写鉴权（安全与业务耦合）。而"谁在什么时候访问了谁的哪个接口"这种基础可观测性，在没有 eBPF 之前基本只能靠应用自己打日志——一旦进程被攻陷，攻击者完全可以关掉日志、篡改监控。

eBPF 的出现，恰好给了这三类问题一个统一的答案：把逻辑从用户态搬进内核，但不用改内核源码、不用写内核模块。

二、核心概念：eBPF 到底是个什么

eBPF（extended Berkeley Packet Filter）是一种在 Linux 内核中运行沙箱程序的技术。你可以把它理解成"内核里的安全插件系统"：你写一段 C（或 Rust/Go 生成）的小程序，经过验证器（verifier）安全检查后，挂载到内核的特定钩子（hook）上，在内核上下文里高效执行。

2.1 一次执行的完整生命周期

  你写的 C 程序 (.c)
       │  clang -target bpf 编译成 ELF
       ▼
  eBPF 字节码 (ELF, 含 BTF 调试信息)
       │  加载器(libbpf / cilium/ebpf) 调用 bpf() 系统调用
       ▼
  内核 Verifier 校验  ── 不通过则拒绝加载(防止死循环/越界/泄露)
       │
       ▼
  挂载到 Hook：XDP / TC / kprobe / tracepoint / LSM / socket
       │
       ▼
  运行时通过 BPF Map 与用户态双向通信(读写共享数据)

几个关键点值得强调：

• Verifier 是安全性的根基。 任何 eBPF 程序加载前，内核都会静态分析：是否可能死循环（必须有界循环）、是否越界访问内存、是否泄漏内核指针。这就是为什么 eBPF 比内核模块安全得多——你没法写出一块能搞崩内核的 eBPF 程序，verifier 直接拒掉。
• BPF Map 是"内核态 ↔ 用户态"的桥梁。 Map 是键值存储（哈希表、数组、LRU、per-CPU 数组等），内核程序写、用户态程序读，反之亦然。Cilium 的所有端点身份、连接计数、策略状态，本质上都存在各种 Map 里。
• CO-RE（Compile Once - Run Everywhere）。 早期 eBPF 开发要针对每个内核版本重编，因为内核结构体字段偏移会变。CO-RE 配合 BTF（BPF Type Format）元数据，让一份编译产物能在不同内核版本上正确读取结构体字段，这是 eBPF 能大规模落地的关键。

2.2 挂载点：eBPF 能摸到的地方远比你想的多

Cilium 之所以强，正是因为它几乎把上面每一类 hook 都用上了：XDP 做入口加速、TC 做 Pod 策略、sockops 做 Service 负载均衡、LSM + kprobe 做 Tetragon 运行时安全。

三、架构分析：Cilium 是怎么把三件事统一起来的

Cilium 对自己的定位是 "API-aware Networking and Security"。它的架构可以拆成数据面、控制面、安全模型三层来看。

3.1 数据面：eBPF 程序的分工

在每个节点上，Cilium 通过 cilium-agent（以 DaemonSet 形式运行）往内核挂了一系列 eBPF 程序：

• bpf_lxc / bpf_host：挂在容器 veth 和主机网卡上，负责 Pod 流量的路由、策略 enforcement、SNAT/DNAT。
• bpf_sock（sockops + socket connect）：在 socket 层直接做 Service 负载均衡，把 ClusterIP 在连接建立前就改写成后端 Pod IP，完全绕开 Netfilter/conntrack。这是替代 kube-proxy 的核心。
• XDP 程序：在网卡入口处处理 NodePort、外部流量、DDoS 类大包的早期丢弃。
• CT（conntrack）Map：Cilium 自己维护的 eBPF conntrack，比内核 Netfilter 的更轻、可裁剪，且对 Service LB 场景可以做到"无状态转发"。

3.2 控制面：身份从哪来

Cilium 的控制面由 cilium-agent（每节点）和 cilium-operator（集群级）组成。最巧妙的设计是端点身份（Endpoint Identity）：

每个 Pod 不是用 IP 标识，而是被分配一个 32 位的数字身份（基于其 namespace + label 推导）。网络包在内核里携带这个身份，策略判断依据身份而非 IP。

身份到标签的映射，小规模用 Kubernetes CRD 存储，大规模用 etcd（KVStore）存储，避免 CRD 在万级端点时成为瓶颈。这意味着：Pod 重建、IP 变了，只要 label 没变，身份不变，策略无需任何重算——这正是云原生动态性最需要的特性。

3.3 网络模式：Overlay 还是 Native Routing

• Overlay（VXLAN / Geneve）：跨节点用隧道封装，简单、对底层网络无要求，适合公有云托管 K8s。
• Native Routing（原生路由）：Pod 用真实可路由的 IP，节点间靠节点路由或 BGP 通告。性能更好、便于和现有网络/防火墙集成，是大规模自建集群的首选。

3.4 安全：从 L3/L4 到 L7 的一条龙

CiliumNetworkPolicy（CNP）是 Kubernetes NetworkPolicy 的超集：

• L3：基于 Pod / namespace / CIDR 的隔离（和原生 NetworkPolicy 一致，但用身份匹配）。
• L4：基于端口和协议。
• L7：基于 HTTP 方法/路径、Kafka topic、DNS 名称做细粒度控制。L7 策略需要一个 Envoy 实例做应用层解析（Cilium 用 per-node 的 Envoy，而非 per-Pod sidecar，资源开销远低于传统服务网格）。

3.5 可观测性：Hubble

Hubble 是 Cilium 内置的可观测性层，它在 eBPF 层直接产生 flow 事件（谁→谁、哪个协议、哪个 HTTP 方法/路径、成功还是 5xx、延迟多少），自动附带 Kubernetes 元数据（Pod 名、namespace、label、service）。这些事件汇聚成服务依赖拓扑图、指标和审计日志。和传统方案比，它的零侵入是降维打击——不用改一行业务代码、不用注入 sidecar、不用应用打日志。

3.6 运行时安全：Tetragon

Tetragon 把 eBPF 的探针从"网络"扩展到了"进程与系统调用"：它能在内核里直接观测进程执行、文件访问、特权提升、网络 syscall，并就地执行策略——比如发现某个容器里冒出了不该有的 apt 或 nc，可以直接 kill 掉对应的进程，而不是等用户态 Agent 上报后再处理（那时候攻击者可能已经跑了）。

四、代码实战：从装好到写出第一段策略与 eBPF

4.1 安装（Helm，开启 kube-proxy 替换 + Hubble）

helm repo add cilium https://helm.cilium.io/
helm repo update

helm install cilium cilium/cilium --version 1.17 \
  --namespace kube-system \
  --set kubeProxyReplacement=true \
  --set k8sServiceHost=YOUR_API_SERVER_IP \
  --set k8sServicePort=6443 \
  --set hubble.relay.enabled=true \
  --set hubble.ui.enabled=true \
  --set hubble.metrics.enabled="{dns,drop,flow,tcp,http}" \
  --set envoy.enabled=true

kubeProxyReplacement=true 是最关键的一行：它让 Cilium 的 eBPF 程序接管 Service 负载均衡，你可以把 kube-proxy 这个 DaemonSet 直接删掉。

验证 Service 负载均衡确实走的是 eBPF 而非 iptables：

# 应该看不到 kube-proxy 进程
kubectl get pods -n kube-system | grep kube-proxy   # 空

# 查看 Cilium 的 sockops LB 是否生效
cilium status --verbose | grep -i "KubeProxyReplacement"
# 输出应包含 Socket LB: Enabled

# 看一眼 Cilium 加载了哪些 eBPF 程序
cilium bpf lb list        # 列出 Service 转发条目
cilium bpf ct list global # 看 eBPF 自维护的 conntrack

4.2 L3/L4 网络策略：用身份隔离

假设我们有三个服务：frontend、cart、checkout，要求只有 frontend 能访问 cart 的 80 端口：

apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: cart-allow-frontend
  namespace: shop
spec:
  endpointSelector:
    matchLabels:
      app: cart
  ingress:
    - fromEndpoints:
        - matchLabels:
            app: frontend
      toPorts:
        - ports:
            - port: "80"
              protocol: TCP

注意 fromEndpoints.matchLabels.app: frontend 是按**身份（label）**匹配的，而不是按 Pod IP。即使 frontend 的 Pod 全部重建、IP 大变，这条策略依然精确生效，无需任何重算。

4.3 L7 HTTP 策略：按接口粒度收口

更进一步，只允许 frontend 调用 cart 的 POST /api/v1/items，其他路径一律拒绝：

apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: cart-l7
  namespace: shop
spec:
  endpointSelector:
    matchLabels:
      app: cart
  ingress:
    - fromEndpoints:
        - matchLabels:
            app: frontend
      toPorts:
        - ports:
            - port: "80"
              protocol: TCP
          rules:
            http:
              - method: "POST"
                path: "/api/v1/items"

这条策略会由节点上的 Envoy 在应用层解析 HTTP 后执行。当 frontend 误调 GET /internal/debug 时，连接会被 Cilium 直接 RST，并在 Hubble 里留下一条 verdict=DROP 的 flow 事件——无需应用侧任何改动。

4.4 运行时安全：Tetragon TracingPolicy

下面这条策略监控所有容器里的进程执行，一旦检测到 package manager（apt/yum/apk）或常见提权工具（如 chmod +s、nc 反弹 shell）被运行，立即记录并 kill 进程：

apiVersion: cilium.io/v1alpha1
kind: TracingPolicy
metadata:
  name: "detect-suspicious-exec"
spec:
  podSelector:
    matchLabels: {}
  kprobes:
    - call: "sys_execve"
      syscall: true
      args:
        - index: 0
          type: "string"
          label: "proc"
      selectors:
        - matchArgs:
            - index: 0
              operator: "In"
              values:
                - "/usr/bin/apt"
                - "/usr/bin/yum"
                - "/sbin/apk"
                - "/usr/bin/nc"
                - "/bin/nc"
          matchActions:
            - action: Sigkill
              rateLimit: 3

action: Sigkill 是 Tetragon 的杀手锏：策略在内核 eBPF 里直接对违规进程发信号，不依赖任何用户态 Agent 的上报链路。即使攻击者拿到了容器权限、杀掉了所有用户态监控，内核里的 eBPF 程序依旧生效。

4.5 自己写一段 eBPF：用 Go + cilium/ebpf 统计入站包

理解 Cilium 的最好方式，是自己写一个最小 eBPF 程序。下面用 github.com/cilium/ebpf 这个 Go 库，加载一段 XDP 程序，统计每张网卡的入站包数。

eBPF 端（drop_cnt.c）：

#include <linux/bpf.h>
#include <bpf/bpf_helpers.h>

// 用 per-CPU 数组避免多核写入竞争
struct {
    __uint(type, BPF_MAP_TYPE_PERCPU_ARRAY);
    __uint(max_entries, 1);
    __type(key, __u32);
    __type(value, __u64);
} pkt_count SEC(".maps");

SEC("xdp")
int count_packets(struct xdp_md *ctx) {
    __u32 key = 0;
    __u64 *count = bpf_map_lookup_elem(&pkt_count, &key);
    if (count) __sync_fetch_and_add(count, 1);
    return XDP_PASS;  // 放行，只计数不丢包
}

char _license[] SEC("license") = "GPL";

Go 加载端（main.go）：

package main

import (
    "fmt"
    "log"
    "time"

    "github.com/cilium/ebpf"
    "github.com/cilium/ebpf/link"
    "github.com/cilium/ebpf/rlimit"
)

func main() {
    // 放开 eBPF 所需的内存锁限制（开发环境）
    if err := rlimit.RemoveMemlock(); err != nil {
        log.Fatal(err)
    }

    // 加载编译好的 ELF（用 clang -target bpf 编译 drop_cnt.c 得到）
    spec, err := ebpf.LoadCollectionSpec("drop_cnt.o")
    if err != nil {
        log.Fatal(err)
    }
    coll, err := ebpf.NewCollection(spec)
    if err != nil {
        log.Fatal(err)
    }
    defer coll.Close()

    // 挂到网卡 lo（生产里换成真实网卡名）
    iface, _ := net.InterfaceByName("lo")
    l, err := link.AttachXDP(link.XDPOptions{
        Interface: iface.Index,
        Program:   coll.Programs["count_packets"],
    })
    if err != nil {
        log.Fatal(err)
    }
    defer l.Close()

    // 每秒读一次计数
    var key uint32 = 0
    for {
        var vals []uint64
        coll.Maps["pkt_count"].Lookup(&key, &vals)
        var total uint64
        for _, v := range vals { total += v } // per-CPU 数组要累加
        fmt.Printf("入站包总数: %d\n", total)
        time.Sleep(time.Second)
    }
}

这段 30 行的程序，正是 Cilium 数据面能力的"最小可运行切片"：编译→校验→挂载 XDP→用 Map 回传计数。你对 eBPF 的理解，从读文档变成"真的跑起来"，往往就差这一步。

4.6 用 Hubble 看真相

# 实时观察命名空间里的 flow
hubble observe -n shop --follow

# 只看被拒绝的流量（排障网络策略的利器）
hubble observe -n shop --verdict DROPPED --protocol http

# 看服务依赖拓扑
hubble topology service --namespace shop

五、性能优化：eBPF 到底快在哪，以及怎么调

很多人对 Cilium 的印象是"功能多"，但它在大规模下的性能优势同样硬核。核心来自三点：

5.1 去掉 conntrack 的 Service 转发

kube-proxy 的 iptables 模式，每条 Service 转发都要走 Netfilter conntrack，建连路径长、表易满。Cilium 的 socket 层 LB（sockops）在 connect() 系统调用返回前就把 ClusterIP 改写成后端 Pod IP，数据面完全不经过 Netfilter，也就没有 conntrack 表膨胀的问题。对于短连接（HTTP/1.1、gRPC 短流）密集型服务，建连延迟通常能降一个数量级。

5.2 DSR（Direct Server Return）减少一跳 NAT

默认模式下，NodePort 流量到节点 A，会被 DNAT 到节点 B 上的 Pod，回包再绕回节点 A。Cilium 支持 DSR 模式：在 XDP 层直接改写目的 MAC 为后端 Pod 所在节点的 MAC，回包从后端节点直发客户端，省掉一轮跨节点 NAT。在跨可用区场景下，DSR 能显著降低 p99 延迟：

helm upgrade cilium cilium/cilium -n kube-system \
  --set loadBalancer.mode=dsr

5.3 一致性哈希让后端稳定

大规模 Service（如网关）希望"同一客户端总是落到同一后端"以减少连接重建。Cilium 内置 Maglev 一致性哈希（源自 Google），后端扩缩容时只有 1/N 的映射会变化，而不是全量重排：

helm upgrade cilium cilium/cilium -n kube-system \
  --set loadBalancer.algorithm=maglev

5.4 eBPF 程序自身的调优清单

• 开大 Map 容量：端点数万级时，调 bpf-map-dynamic-size-ratio（默认 0.0025，可提到 0.01）避免 Map 满导致新建连接被丢。
• 用 per-CPU Map 做计数：像上面的例子，多核写入用 PERCPU_ARRAY 避免缓存行颠簸（cache line bouncing）。
• 关掉不必要的 Hubble 指标：hubble.metrics 只开你真看的（如 http,dns,drop），全开会把 monitor 聚合层打满。
• MTU 对齐：Overlay 模式记得把 Pod MTU 调小（VXLAN 占 50 字节头），否则大包会被分片，吞吐骤降。
• 开启 bpf-lb-sock-hostns-only 等开关，把 socket LB 范围限制在需要的命名空间，减少内核 hook 的全局开销。

5.5 一组代表性的生产对照（千节点规模）

下面是在 ~1000 节点、数万 Pod 规模下，业界（Trip.com、Datadog 等公开分享）反复验证过的方向性结论，数字为量级参考而非精确基准：

结论很明确：Cilium 不是"用复杂度换功能"，而是用内核态的精确性同时换来了功能和性能。

六、总结与展望：eBPF 是云原生的"新操作系统抽象"

回看开头那三个问题：

1. Cilium 凭什么取代 kube-proxy？ 因为它把 Service 负载均衡下沉到 socket/XDP 层的 eBPF，绕开了 iptables 的 O(n²) 刷新和 conntrack 瓶颈，规则收敛从秒级降到毫秒级。
2. 基于身份的安全解决了什么？ 它把"IP 易变"这个云原生最大的网络难题消解掉了——策略锚定 label 推导出的数字身份，Pod 重建、IP 大变都无需重算，L3/L4/L7 策略因此第一次能稳定落地。
3. 能在大规模把延迟打下来吗？ 能，前提是吃透 DSR、Maglev、Map 容量、Hubble 指标范围这几处调优点。

展望未来，eBPF 正在成为云原生的"隐形操作系统层"：

• 无 sidecar 服务网格成为主流。 Istio ambient、Cilium Service Mesh 都把流量治理下沉到节点 eBPF，sidecar 模式逐步退场——资源开销和架构复杂度双降。
• 多集群互联用 ClusterMesh。 跨集群、跨云的 Pod 直接用身份互访，安全策略一处定义、处处生效。
• 运行时安全收编进同一平面。 Tetragon 证明：网络策略、进程监控、文件访问审计可以共用一套 eBPF 底座，安全团队终于能从"一堆各自为战的 Agent"里解脱。
• 可观测性走向零侵入。 Hubble + Pixie + Parca 这类 eBPF 工具，让"看见每一次调用"不再需要业务埋点。

如果你今天要新建一个生产级 Kubernetes 集群，我的建议很直接：把 Cilium 当成默认网络底座来设计，而不是等出了问题再迁移。它的学习曲线在前端（eBPF 模型、身份体系），但一旦跑顺，你会发现很多曾经要堆 sidecar、堆 Agent、堆 iptables 脚本才能解决的难题，在内核里一行 eBPF 就安静地解决了。

eBPF 不是银弹，但它确实正在重写我们理解云原生网络与安全的方式。而 Cilium，是这套新范式里最成熟、也最值得你投入时间的那一个。

参考与延伸：Cilium 官方文档（cilium.io）、eBPF 官方文档（ebpf.io）、Tetragon TracingPolicy 示例、cilium/ebpf Go 库、BPF Performance Tools（Brendan Gregg）。文中性能数字为公开生产分享的量级参考，具体落地请以你集群的真实基准测试为准。