【Cilium / eBPF】对照替代路径：Calico、kube-proxy、Envoy sidecar 与 Ambient

前 13 篇把东西向包从 identity 与 map 讲到可观测与五轴排障。接下来的问题不是「Cilium 功能全不全」，而是：什么时候这些 eBPF 数据面税不值得付——Calico 已给路由+策略、kube-proxy 仍拥有 Service、sidecar/Ambient 已承接 L7。

本文不做延迟排行榜。跨方案延迟比较需要固定节点网卡、内核、策略规则规模、加密与 L7 是否同开；单个数字比较是口径欺骗。本文从机制分歧出发：每条路径赢在哪个前提，前提崩了代价是什么。产品勾选见 k8s-network/12 Calico、k8s-network/13 Cilium；代理排除树见 Envoy 16、HAProxy 14。

本文是「Cilium / eBPF 数据面内核」系列第 14 篇（共 16 篇）。→ 系列目录

篇目	核心内容
第 13 篇 · 排障坐标系	五轴归因
第 14 篇 · 对照替代路径	Calico / kube-proxy / sidecar / Ambient
第 15 篇 · Gateway 边界	南北向与东西向分工

版本锚定：Cilium v1.20.0；对照结论是机制判断。Calico / Istio Ambient / Envoy 版本随各自发行说明；正文不绑某一云厂商托管 CNI 修订号。

一、对照维度的确定

四条路径的分歧不在「谁功能更多」，而在下列不变量：

本篇回答的是：东西向数据面选哪条机制路径。若问题其实是「边缘 L7 网关选谁」，应先走 network/60 与第 15 篇，再决定是否让 Cilium 兼任 Gateway。

flowchart TD
  need{"Need identity-centric\nL3/L4 in kernel?"}
  need -->|"No"| l7{"Need rich L7\nper request?"}
  l7 -->|"Yes"| mesh{"Per-pod isolation\nvs shared node hop?"}
  mesh -->|"per-pod"| side["Envoy sidecar"]
  mesh -->|"shared"| amb["Ambient / node proxy"]
  l7 -->|"No"| kp{"Only Service LB\non stable iptables/IPVS?"}
  kp -->|"Yes"| kproxy["kube-proxy"]
  kp -->|"No"| cal{"Need BGP/routed\nCNI model?"}
  cal -->|"Yes"| calico["Calico-class"]
  cal -->|"No"| other["Other CNI"]
  need -->|"Yes"| staff{"Can staff BPF\nmap/identity ops?"}
  staff -->|"No"| defer["Do not run Cilium yet"]
  staff -->|"Yes"| cil["Cilium eBPF datapath"]

二、对照 Calico

Calico 赢在的前提

• 团队已有 BGP / 路由域 运维语言，希望 Pod 网段像「真实子网」一样进数据中心织物。
  
• 策略与网络团队更熟悉 iptables/ipset 或 Calico 自己的策略对象，编制上尚未准备 Hubble/identity 方言。
  
• 需要与非 K8s 工作负载在同一路由域里互访的成熟故事（视部署模式）。

机制要点见 k8s-network/12：Calico 的历史主线是「路由协议 + 策略引擎」；eBPF 数据面是后来选项，不改变「路由一等公民」的骨架。Cilium 从设计上把 eBPF map 查找当默认转发与策略路径。

Cilium 赢在的前提

• 要以 identity 做策略一等键，并接受数字身份生命周期（第 2、7、13 篇）。
  
• 要 kube-proxy 替代 与统一可观测（Hubble）绑在同一数据面。
  
• 希望少依赖每节点 iptables 规则规模随 Service/策略增长的经典痛点（动机见 linux/ebpf-cilium 与本系列第 6 篇）。

经典反模式

把「Calico 与 Cilium 都支持 eBPF」读成同构。实现与失败模式仍可能差在：路由是否一等、identity 是否一等、Service 由谁拥有、观测字段叫什么。ADR 应写不变量，不写品牌同义词。

不做的事：不引用未标定的「Cilium 比 Calico 快多少」截图；不写托管 Calico/Cilium 控制台点击教程。

三、对照 kube-proxy（iptables / IPVS）

kube-proxy 不是 CNI，但常被拿来与 Cilium KPR 对打。机制问题应写成：谁拥有 Service 的包改写与负载均衡。

kube-proxy 赢在的前提

• 集群规模与规则复杂度仍在团队已验证的 iptables/IPVS 舒适区。
  
• CNI 只做连通，Service 与策略由既有 runbook 覆盖，不想一次切换两套方言。
  
• 合规或平台标准强制保留 kube-proxy（少见但真实）。

KPR 赢在的前提

• Service 与策略变更频繁，iptables 更新窗口与链长已成为事故因子。
  
• 希望 Service 与 identity 策略共用观测与排障轴（第 12–13 篇）。
  
• 接受 KPR 与 NodePort/externalTraffic/DSR 组合的路径矩阵（第 6 篇）。

双轨警告：半开 KPR、半留 kube-proxy，或云 LB 与 KPR 责任不清时，轴四黑洞会以「玄学」出现。排除树上应单列：Service 所有权唯一。

迁移税（机制，非菜谱）

从 kube-proxy 迁到 KPR 不是改一个 Helm 布尔值就结束。至少要预算：

1. 路径矩阵重测：ClusterIP、NodePort、LoadBalancer、externalTrafficPolicy=Local、是否 DSR——第 6 篇矩阵在目标内核与网卡驱动上各跑一遍连通与回程。
   
2. 观测切换：iptables 计数 runbook 作废；Hubble / bpf lb 进值班手册。
   
3. 回滚条件：写明「何时允许重新拉起 kube-proxy」——例如某类外部流量在验收中失败且无法在一周内定位。

没有这三项，KPR 切换会变成不可逆的信仰迁移。

四、对照 Envoy sidecar

Envoy sidecar 优化的是每工作负载一跳用户态代理：L7 路由、重试预算、Filter 链、与 xDS 控制面经济学。Cilium 默认优化的是内核 L3/L4 + identity；L7 是可选边界（第 10 篇）。

sidecar 赢在的前提

• 每服务差异化 HTTP 策略与爆炸半径隔离是硬需求（Envoy 16 排除树）。
  
• 组织已有可持续的 xDS 控制面（或托管等价物）。
  
• L3/L4 identity 不够表达（方法级授权、协议转换、复杂重试）。

Cilium 赢在的前提（相对 sidecar）

• 主路径只要 L3/L4 身份与路径，不想付每 Pod 内存与跳数税。
  
• 平台希望东西向默认停在 CNI 数据面，仅对少数服务加 L7。
  
• 编制够 map/identity，但不够人均维护一份 sidecar 配置扇出。

Envoy 16 已写：「只要 L4 身份与路径 → 优先问 eBPF/CNI」。本篇回收这片叶子：叶子的机制内容由本系列交付，不在 Envoy 终章重写。

常见假对立

「Cilium 与 sidecar 互斥」在机制上不成立。合法组合包括：CNI/策略用 Cilium，少数支付/风控服务保留 sidecar 做 L7 鉴权；或边缘 Envoy Gateway + 东西向 Cilium。假对立来自采购话术把「服务网格」与「CNI」捆成单选题。ADR 应写成哪些服务必须 L7 跳，而不是「全网要么全 sidecar 要么全 eBPF」。

反过来，用 sidecar「顺便」替代 NetworkPolicy，会把 L3/L4 拒绝语义藏进 HTTP 过滤器——排障时 Hubble 可能显示 FORWARDED，而业务看到 403。那是坐标错位，不是 Cilium 不够强。

五、对照 Ambient（共享 L4/L7 跳）

Ambient 类架构把网格税从「每 Pod sidecar」挪到「节点共享 L4（ztunnel 等）+ 按需 L7 waypoint」。数据面内核仍可能是用户态代理组件，只是部署形态变了。Cilium 亦有自己的 mesh/L7 边界（第 10 篇）与 ztunnel 相关演进（v1.20 发行说明含 ztunnel 身份与指标——属网格边界，本系列不展开实现百科）。

Ambient 赢在的前提

• 需要网格身份与逐步加 L7，但要砍 sidecar 内存税。
  
• 平台接受「CNI 连通 + 网格策略」双栈 runbook。

仍选 Cilium 主路径的前提

• L7/网格不是主需求；identity NetworkPolicy 足够。
  
• 不想同时训练两套故障域；优先单一 Hubble/BPF 方言。

本系列不裁决「Istio Ambient vs Cilium Mesh」产品胜负；只要求选型者能指出延迟与失败落在 BPF map 还是用户态代理。胜负用机制句子写进 ADR，不用压测海报。

六、与 HAProxy / Envoy 排除树的接缝

HAProxy 14 与 Envoy 16 在「只要 L3/L4」处指向 eBPF。接缝规则：

混合并不犯规：边缘 Envoy/HAProxy，东西向 Cilium，少数服务 sidecar。代价是多套排障坐标——第 13 篇清单要标明流量先进了哪一层。

实务上建议在变更单加一行「流量先进层」枚举：bpf-policy / bpf-service / encrypt / envoy-gateway / envoy-sidecar / ambient-l4。事故复盘若填不出这一行，说明值班地图还没接上排除树。

组织层排除（常被营销跳过）

机制叶选对了，组织叶仍可能判负：

排除树要诚实写这些约束；否则 ADR 会上通过、生产上无人能执行第 13 篇。

七、谱系、争论与开放问题

谱系

「内核可编程数据面 vs 用户态代理 vs 经典 netfilter」是系统社区长期分叉：XDP/eBPF 论文证明内核快路径可编程（Höiland-Jørgensen et al., CoNEXT 2018）；Service mesh 文献证明 L7 策略需要用户态语义。Cilium 站在前者主场，并把身份策略工程化；Envoy/Ambient 站在后者主场。Calico 站在路由+策略传统，eBPF 为选项。选型是站队分叉，不是填功能清单。

争论：「CNI 足够」vs「必须网格」

A 侧：多数东西向故障是 L3/L4 与身份；网格税常大于收益。
B 侧：无网格则缺统一 mTLS、流量拆分与 L7 鉴权。
可检验提法：列出必须 L7 的服务比例；若小于阈值且无证书统一需求，先停在 Cilium/Calico 叶。把「以后要做零信任」写成必须立刻全量网格，通常会在编制与排障坐标尚未就绪时引入双栈税——排除树上应记为投机性迁入。

开放问题

1. Ambient + Cilium 双栈时的单一责任界面：故障时先查 ztunnel 还是 Hubble？需要可执行的分层 runbook，而非「两个都看」。
   
2. Calico eBPF 模式与 Cilium 在 identity 模型上的长期差异是否收敛：跟版本漂移；ADR 应钉「当前不变量」，避免「将来会一样」。
   
3. 混合路径下的变更门禁：边缘 Envoy + 东西向 Cilium + 少数 sidecar 时，一次发布如何证明「流量先进层」枚举仍正确？需要自动化探测而非口头约定。

参考资料

官方 / 规范（A 级）

• Cilium v1.20 Concepts：Networking、Identity、KubeProxyReplacement、Service Mesh
• Kubernetes：kube-proxy、NetworkPolicy、EndpointSlice
• 对照发行说明：Istio Ambient / Envoy 版本随其文档；不在此钉死

站内对照

• k8s-network/12 Calico
• k8s-network/13 Cilium
• Envoy 16 选型收束
• HAProxy 14 选型收束
• 第 10 篇 · L7 与 Mesh 边界
• 第 16 篇 · 选型收束

论文谱系

• Höiland-Jørgensen, T. et al. (2018). The eXpress Data Path. CoNEXT ’18
• McCanne, S. & Jacobson, V. (1993). The BSD Packet Filter. USENIX Winter ’93

实验台账

• 本篇无跨方案 benchmark；选型依据为机制排除。

→ 上一篇：排障坐标系 · 系列目录 · 下一篇：Gateway 边界