K3s + Cilium：Service Mesh 数据平面的“轻骑兵”实战手记

大家好，我是老张，过去三年在边缘 AI 推理平台和多租户 SaaS 产品里摸爬滚打，从裸金属 K8s 到 K3s 集群部署了 17+ 套环境。最近在给客户落地《2026 年企业级 K8s 轻量化部署方案》时，把 Istio+Envoy 换成了 K3s+Cilium，数据平面直接“瘦”掉 60% 内存 —— 但背后不是一键替换那么简单。今天就从 Service Mesh 数据平面演进 角度，聊聊 Cilium 的 eBPF 在三个关键能力上的真实表现，以及它还没完全翻过的那座山。

�� 连接追踪：eBPF 的“零拷贝旁路”有多香？

传统 iptables/Conntrack 在高并发短连接场景（比如 IoT 设备心跳）下，CPU 火焰图里全是 nf_conntrack_invert_tuple。而 Cilium 的 eBPF 连接追踪器 直接在内核 sk_buff 层做状态标记，不走 netfilter hook，延迟压到 5μs 以内（实测 Prometheus 抓取 2000+ Pod 指标时 CPU 仅涨 3%）。

关键配置片段（cilium-config.yaml）：

# 启用 eBPF 连接追踪（默认已开，但务必确认！）

bpf:

  masquerade: true

  monitorAggregation: medium

  # 关键！禁用传统 conntrack，避免双栈冲突

  kubeProxyReplacement: strict

⚠️ 重要提示：K3s 默认启用 kube-proxy，必须显式关闭并设置 --disable-network-policy 启动参数，否则 Cilium 的 eBPF 追踪会被绕过 —— 我踩了个坑，折腾了半天才发现 metrics 里 cilium_policy_denied_total 异常飙升。

��️ mTLS 卸载：内核态加密真的省资源吗？

Cilium 1.14+ 支持 eBPF TLS 卸载：证书校验、密钥协商、流量加解密全在内核完成。对比 Istio Envoy 的用户态 TLS，我们压测 10k QPS HTTP/2 流量时：

• Envoy Sidecar：平均 CPU 1.2vCPU，内存 380MB
• Cilium eBPF：CPU 0.35vCPU，内存 95MB（含整个 CNI DaemonSet）

但注意：它目前只支持服务间 mTLS（即 ClusterMesh 场景），不支持客户端证书双向认证（mTLS client auth） —— 如果你的 API 网关需要验终端用户证书，还得上 Envoy。

�� L7 策略执行：eBPF 能跑 HTTP 头匹配？

能！Cilium 用 eBPF HTTP 解析器（基于 libhttp2 的精简版）在内核解析 Host、Path、Authorization 等 header，策略生效快于用户态代理：

# ciliumnetworkpolicy.yaml

apiVersion: cilium.io/v2

kind: CiliumNetworkPolicy

metadata:

  name: api-rate-limit

spec:

  endpointSelector:

    matchLabels:

      app: payment-api

  ingress:

  - fromEndpoints:

    - matchLabels:

        app: frontend

    toPorts:

    - ports:

      - port: "8080"

        protocol: TCP

      rules:

        http:

        - method: "POST"

          path: "/v1/charge"

          # 内核态直接匹配，无上下文切换

          headers:

            - "X-Region: us-west"

�� 多集群服务发现：Cilium ClusterMesh 的“温柔一刀”

Cilium 的 ClusterMesh 通过 etcd/gRPC 同步服务信息，比 Istio 的 istiod 全量推送更轻量。但问题来了：

• ✅ 优势：跨集群 Service IP 不冲突（Cilium 自动分配 CIDR）、DNS 解析延迟 <50ms
• ❌ 局限性：

1. 无全局统一控制平面：每个集群需独立维护 NetworkPolicy，无法像 Istio 的 VirtualService 统一定义跨集群路由
2. 健康检查弱耦合：节点宕机后服务剔除依赖 etcd lease，TTL 默认 15s（Istio 是秒级）
3. 缺失多集群 mTLS 根 CA 联邦：你得自己用 cert-manager 同步 root CA，官方文档里埋着个 TODO

�� 个人经验：我们在金融客户场景试过 ClusterMesh + 自研 CA 同步脚本，结果因 etcd 网络抖动导致 3 个集群服务注册状态不一致 —— 最后改用 Cilium + K8s ExternalDNS + Consul 实现 DNS-based 多集群发现，反而更稳。

�� 资源开销对比：数字不说谎

（测试环境：K3s v1.30, 4c8g 节点，启用 Hubble UI）

�� 总结与讨论

说实话，Cilium 不是 Istio 的“平替”，而是 面向云原生基础设施层的重构：它把数据平面能力下沉到内核，换来极致性能，但代价是放弃部分应用层抽象（比如细粒度的流量镜像、复杂的故障注入）。

如果你的场景是：
✅ 边缘/嵌入式 K8s（资源敏感）
✅ 东西向通信为主、L7 策略需求较简单
✅ 愿意为性能接受一定的运维复杂度
—— 那 Cilium + K3s 真是降本增效的神组合。

但若你重度依赖 Istio 的可观测性生态或灰度发布能力……别硬刚，混合部署（Cilium 做网络底座 + Envoy 做特定服务网关）可能更务实。

最后抛个问题给大家：你们在生产环境用 Cilium ClusterMesh 做多集群了吗？遇到过哪些“文档没写但线上爆炸”的坑？欢迎评论区一起填坑 ��