文章

eBPF 与 Cilium K8s 实战

#linux#ebpf#cilium#kubernetes#cni

eBPF 与 Cilium K8s 实战

Cilium 架构

graph TD
    A[Pod] -->|流量| B[cilium-agent 每个节点]
    B -->|eBPF 程序| C[网卡 XDP/TC/socket]
    B --> D[cilium-operator 集群级]
    B --> E[Hubble 可观测]
    E --> F[Hubble Relay → UI/Prometheus]
    D --> G[CiliumNetworkPolicy / Egress]
  • cilium-agent：每个节点一个，编译并加载 eBPF 程序、管理 Endpoint 和策略。
  • cilium-operator：集群级，管理 ClusterPool IP、节点初始化等。
  • Hubble：基于 eBPF 的可观测性，零侵入采集流日志。

数据面三件事（深入）

1. 服务负载均衡（取代 kube-proxy）

传统 kube-proxy 用 iptables/nftables 规则做 DNAT；Cilium 用 eBPF 在更早期完成：

  • socket LB：在应用 connect()/sendmsg() 的 socket 层就把 VIP 改写成后端 Pod IP，连接根本不进 conntrack（见 eBPF 性能模型 的 conntrack 减负）。
  • TC/XDP：跨节点流量在 TC 层做封装/路由；XDP 可做 DSR（Direct Server Return）。
cilium bpf lb list        # 看 VIP:Port → 后端 映射（等价 kube-proxy 的 iptables 规则）
# SERVICE 10.96.0.1:443 => backend 10.244.1.5:443 (1)

2. 网络策略（NetworkPolicy / CiliumNetworkPolicy）

eBPF 实现 L3/L4，Cilium 还能做到 L7（应用层感知）：

  • L3/L4：基于 IP/端口（等同 K8s NetworkPolicy）
  • L7：HTTP/gRPC/Kafka/DNS/FQDN 感知
# 只允许访问 api 服务的 GET /health
apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata: { name: api-health, namespace: default }
spec:
  endpointSelector: { matchLabels: { app: frontend } }
  egress:
  - toEndpoints:
    - matchLabels: { app: api }
    toPorts:
    - ports: [{ port: "80", protocol: TCP }]
      rules:
        http: [{ method: "GET", path: "/health" }]

3. 可观测性（Hubble）

基于 eBPF 零侵入采集：谁访问了谁、哪个 TCP 重传、哪个 DNS 失败、哪个被策略丢弃。不需要 sidecar。

cilium hubble port-forward &
hubble observe --verdict DROPPED --last 100   # 看被策略丢的流量
hubble observe --protocol http                 # 看 HTTP 层流

kube-proxy replacement（KPR）深入

KPR = 用 eBPF 完全替代 kube-proxy 的 Service 转发。

维度iptables kube-proxyCilium KPR（eBPF）
转发位置网络栈 Netfiltersocket 层 + TC/XDP
conntrack每条连接都建条目大量连接不进 conntrack
负载均衡算法随机/round-robinMaglev 一致性哈希（节点扩缩容后端稳定）
规则爆炸Service/EP 多时 iptables 链爆炸无规则链，查 map
延迟中低

DSR 与 Maglev

  • DSR（Direct Server Return）：后端回包直接回客户端，不经过转发节点，降低延迟。
  • Maglev 哈希：一致性哈希，节点/后端变化时尽量不打散已有连接（这就是为什么 cilium config loadBalancer.algorithm 可调）。

conntrack 减负（量化）

KPR 下，节点 conntrack 条目可比 iptables 模式低一个数量级——直接缓解你 ../网络内核参数调优 里写的”conntrack 表打满丢包”问题。但 kubelet、CNI、跨节点 NAT 仍需 conntrack，不能设 0。

内核特性矩阵

能力最低内核推荐
Cilium 基础运行≥ 4.9≥ 5.10
完整 KPR / L7 策略≥ 5.10≥ 5.15
XDP 原生驱动加速取决于网卡驱动≥ 5.15
BPF LSM / CO-RE≥ 5.7+≥ 5.15

你 ../../k8s/特性详解/CNI 网络插件对比与排障 里”内核 ≥ 5.10 → Cilium，旧内核 → Calico”的选型，本质就是 eBPF 能力门槛。

安装与验证要点

# 1. 内核 ≥ 5.10，且 cgroup v2（见 [[../cgroup v2 详解]]）
stat -fc %T /sys/fs/cgroup/    # cgroup2fs

# 2. containerd 必须 SystemdCgroup=true
# /etc/containerd/config.toml
# [plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc.options]
#   SystemdCgroup = true

# 3. helm 安装（开启 KPR + Hubble）
helm install cilium cilium/cilium --version 1.15.x \
  --namespace kube-system \
  --set kubeProxyReplacement=true \
  --set kubeProxyReplacement=strict \
  --set hubble.relay.enabled=true \
  --set hubble.ui.enabled=true

# 4. 验证
cilium status --verbose
bpftool prog list | grep -i cilium     # 应有 cilium_ 前缀程序

常见排障命令（全集见 eBPF 排障实战）

cilium status                         # 健康
cilium endpoint list                  # Endpoint 与策略状态
cilium bpf lb list                    # Service 映射
cilium bpf ct list global            # conntrack
hubble observe --verdict DROPPED     # 丢包证据

关联知识

学习时间

阶段时间备注
Cilium 实战2026-07-16架构、数据面三件事、KPR(Maglev/DSR/conntrack 减负)、内核矩阵、安装验证、CiliumNetworkPolicy 示例