Cilium网络策略与Serverless性能调优实战 - 第4节

4.1 Pod 网络模型与 Cilium 的 CNI 实现

Kubernetes 的 Pod 网络模型要求每个 Pod 拥有独立的 IP 地址，且所有 Pod 之间可以不通过 NAT 直接通信。Cilium 作为基于 eBPF 的 CNI 插件，在实现这一模型时绕过了传统 iptables 和网桥方案，直接在网络栈的内核层完成数据包转发。

4.1.1 传统 Pod 网络 vs Cilium eBPF 路径

4.1.2 Cilium 的 Pod 网络数据路径

当 Pod 发送数据包到同一节点或跨节点 Pod 时，Cilium 的数据路径如下：

1. 出站方向：Pod 的 veth 对端（cilium_host）触发 eBPF 程序（tc ingress）。
2. 策略检查：eBPF 程序查询 cilium_policy map，判断源/目的身份是否允许通信。
3. 封装/路由：跨节点时通过 VXLAN/Geneve 隧道或直接路由（Native Routing）转发。
4. 入站方向：目标节点 eBPF 程序解封装后，将数据包交付到目标 Pod 的 veth 端。

# 查看 Cilium 为 Pod 分配的 identity
kubectl exec -n kube-system cilium-xxxxx -- cilium endpoint list
# 输出示例：
# ENDPOINT   IDENTITY   LABELS                    IP             NODE
# 1234       167        k8s:app=frontend          10.0.1.5       node-1
# 5678       289        k8s:app=backend           10.0.2.8       node-2

4.2 Service 负载均衡：DSR 模式与 kube-proxy 替代

Cilium 提供了两种 Service 负载均衡模式：kube-proxy 替代模式和DSR（Direct Server Return）模式。两者都基于 eBPF 实现，但转发路径和性能特征不同。

4.2.1 kube-proxy 替代模式

Cilium 可以完全替代 kube-proxy，通过 eBPF 程序在节点网络接口上直接处理 Service 流量。相比 iptables 模式，它消除了 DNAT 规则链遍历和 conntrack 表竞争。

# 启用 Cilium 的 kube-proxy 替代
helm upgrade cilium cilium/cilium --namespace kube-system \
  --set kubeProxyReplacement=true \
  --set k8sServiceHost=192.168.1.100 \
  --set k8sServicePort=6443

# 验证 kube-proxy 已被替代
cilium status | grep "KubeProxyReplacement"
# 输出：KubeProxyReplacement:  Strict   [eth0 192.168.1.10]

4.2.2 DSR（Direct Server Return）模式

DSR 模式的核心思想是：入站流量经过负载均衡节点，但返回流量直接从后端 Pod 返回客户端，避免负载均衡节点成为瓶颈。Cilium 通过 eBPF 在数据链路层实现 DSR，无需修改 IP 头。

# 启用 Cilium DSR 模式
helm upgrade cilium cilium/cilium --namespace kube-system \
  --set kubeProxyReplacement=true \
  --set loadBalancer.mode=dsr \
  --set loadBalancer.dsrDispatch=ipip

# 查看 DSR 是否生效
cilium status | grep "DSR"
# 输出：DSR:  Enabled

4.3 eBPF 数据路径详解

Cilium 的核心竞争力在于其 eBPF 数据路径。理解 eBPF 程序在数据包处理流程中的挂载点和执行逻辑，是掌握 Cilium 网络性能优化的基础。

4.3.1 eBPF 挂载点：XDP 与 tc

Cilium 在两种内核钩子处挂载 eBPF 程序：

• XDP（eXpress Data Path）：在网络驱动层、SKB 分配之前执行，性能最高，适合 DDoS 防护和早期丢弃。
• tc（Traffic Control）：在协议栈处理之后、SKB 分配之后执行，功能更丰富，适合策略执行和转发。

4.3.2 eBPF 程序执行流程

以 Pod 访问 Service 为例，Cilium 的 eBPF 程序执行以下步骤：

1. XDP 程序（可选）：检查源/目的 MAC，如果是已知 Service IP，直接重定向到后端 Pod 的 MAC。
2. tc ingress 程序：解析 IP 头，查询 cilium_lb4_services_v2 map 获取后端列表。
3. 负载均衡选择：使用 Maglev 一致性哈希算法选择后端，查询 cilium_lb4_backends_v2 map 获取后端 IP。
4. 封装/转发：如果是跨节点，通过 VXLAN 封装；同节点直接修改 MAC 转发。
5. 策略检查：查询 cilium_policy map，验证源身份是否允许访问目标身份。

// 简化版 eBPF 程序：Service 负载均衡查找
// 完整代码见 cilium/bpf/lib/lb.h

static __always_inline int __lb4_lookup(struct __ctx_buff *ctx,
                                         struct ipv4_ct_tuple *tuple,
                                         struct lb4_service *svc,
                                         struct lb4_backend *backend,
                                         __u32 *cluster_id)
{
    // 1. 从数据包中提取 Service IP 和端口
    tuple->daddr = ip4->daddr;
    tuple->dport = bpf_ntohs(tcp->dest);

    // 2. 查询 Service map
    struct lb4_key key = {
        .address = tuple->daddr,
        .dport = tuple->dport,
    };
    svc = map_lookup_elem(&cilium_lb4_services_v2, &key);
    if (!svc)
        return CTX_ACT_OK;  // 非 Service 流量，直接放行

    // 3. Maglev 一致性哈希选择后端
    backend_id = maglev_lookup(svc, tuple->saddr, tuple->sport);
    backend = map_lookup_elem(&cilium_lb4_backends_v2, &backend_id);

    // 4. 修改目标 IP 为后端 Pod IP
    ctx_store_bytes(ctx, offsetof(struct iphdr, daddr),
                    &backend->address, 4, 0);
    return CTX_ACT_REDIRECT;
}

4.3.3 eBPF map 与数据共享

Cilium 使用多种 eBPF map 在 eBPF 程序与用户态守护进程之间共享数据：