【Cilium / eBPF】对照替代路径：Calico、kube-proxy、Envoy sidecar 与 Ambient
内容提要
本文对比Cilium eBPF与Calico、kube-proxy、Envoy sidecar及Ambient四条数据面路径，强调选型应基于机制而非功能清单。Cilium适合以identity为核心、需统一观测的场景；Calico适合已有BGP运维体系；kube-proxy适合规则简单集群；sidecar/Ambient适合需L7策略。指出混合部署可行，但需明确流量分层与排障坐标，避免投机性迁移。
延伸解读
机制对比优于性能对比
文章强调，跨方案延迟比较需固定节点网卡、内核、策略规模等条件，单一数字易成口径欺骗。选型应基于机制分歧：每条路径赢在特定前提，前提崩了代价不同。例如，Calico 适合已有 BGP 运维体系，Cilium 适合以 identity 为核心、需统一观测的场景。读者应关注机制不变量，而非功能清单或性能海报。
混合部署的可行性与代价
文章指出，Cilium 与 sidecar、Ambient 等并非互斥，合法组合包括边缘 Envoy Gateway + 东西向 Cilium，或少数服务保留 sidecar 做 L7 鉴权。但混合部署需明确流量分层与排障坐标，建议在变更单中增加「流量先进层」枚举，如 bpf-policy、envoy-sidecar 等，否则事故复盘时难以定位问题。
迁移税与回滚条件
从 kube-proxy 迁到 KPR 并非简单改配置，需重测路径矩阵（ClusterIP、NodePort、externalTrafficPolicy 等）、切换观测工具（iptables 计数到 Hubble），并明确回滚条件，如外部流量验收失败且无法一周内定位时重新启用 kube-proxy。否则切换可能变成不可逆的信仰迁移。
组织约束常被忽视
文章提醒，机制选对但组织约束可能判负：网络与平台分属两队且无共同 Hubble 权限，会放大排障流程；安全团队只认 iptables 审计脚本，identity 策略无法过合规；已有 Envoy 控制面编制但无 BPF 编制，强行上 Cilium 全功能会失效。排除树应诚实记录这些约束，否则 ADR 通过却无法执行。
Q&A
Cilium eBPF 与 Calico 在数据面机制上的核心区别是什么？
Cilium 以 eBPF map 查找为默认转发与策略路径，以数字 identity 为策略一等键；Calico 以路由（如 BGP）为一等公民，策略通过 iptables 或 eBPF 实现，identity 不是核心。
在什么情况下应该选择 kube-proxy 而不是 Cilium 的 KPR？
当集群规模与规则复杂度仍在 iptables/IPVS 舒适区，且团队已有成熟的 kube-proxy 运维 runbook，或合规要求强制保留 kube-proxy 时，应选择 kube-proxy。
从 kube-proxy 迁移到 Cilium KPR 需要做哪些准备？
需要重测路径矩阵（ClusterIP、NodePort、LoadBalancer、externalTrafficPolicy=Local、DSR），切换观测工具（从 iptables 计数到 Hubble/bpf lb），并明确回滚条件（如外部流量验收失败且无法一周内定位时重新启用 kube-proxy）。
Envoy sidecar 和 Cilium eBPF 各自适合什么场景？
Envoy sidecar 适合需要每服务差异化 L7 策略（如 HTTP 路由、JWT 鉴权）且组织已有 xDS 控制面的场景；Cilium eBPF 适合主路径只需 L3/L4 身份与路径、不想承担每 Pod 内存和跳数税的场景。
Cilium 和 Envoy sidecar 是否可以同时使用？
可以。合法组合包括：CNI/策略用 Cilium，少数服务保留 sidecar 做 L7 鉴权；或边缘用 Envoy Gateway，东西向用 Cilium。二者并非互斥。
Ambient 架构与 Cilium 默认数据面在机制上有何不同？
Ambient 将网格税从每 Pod sidecar 移到节点共享 L4 代理（如 ztunnel）和按需 L7 waypoint，身份基于证书/SPIFFE；Cilium 默认使用 BPF 程序，无强制每 Pod 代理，身份基于数字 identity，且 CNI 与策略同栈。
在混合部署（如边缘 Envoy + 东西向 Cilium + 少数 sidecar）时，排障上有什么建议？
需要在变更单中明确“流量先进层”枚举（如 bpf-policy、envoy-gateway、envoy-sidecar、ambient-l4），事故复盘时若填不出这一行，说明值班地图未接上排除树。
组织层面有哪些因素可能导致即使机制上选对了 Cilium 也无法落地？
例如网络与平台团队分属两队且无共同 Hubble 权限，安全团队只认 iptables 审计脚本，已有 Envoy 控制面编制但无 BPF 编制，或采购绑定某一托管 CNI。这些约束会阻碍 Cilium 的深排障、合规或自主管理。
