Istio 与 Cilium 服务网格

Envoy sidecar 数据面 · eBPF sidecarless 数据面 · xDS / mTLS · Hubble 可观测

场景问题

微服务多了以后，一堆横切需求要统一解决：服务间 mTLS 加密、灰度/金丝雀路由、重试/超时/熔断、流量镜像、全链路可观测。如果每个服务自己在代码里塞这些逻辑，语言各异、版本不一、改一次全量发版，维护地狱。

服务网格（Service Mesh） 的思路是：把这些能力从业务代码下沉到基础设施，业务无感知。但"下沉到哪里"有两条路线之争：

• Istio：给每个 Pod 塞一个 Envoy sidecar 代理，所有进出流量被劫持到 sidecar，由它执行策略。
• Cilium：用 eBPF 把能力做进内核数据面，不需要 sidecar（sidecarless）。

打个比方：Istio 给每个服务（Pod）配一个贴身保镖（Envoy sidecar）——所有进出的话都先过保镖的手（流量被劫持，做 mTLS 加密、灰度路由、重试熔断），功能最全最灵活。代价是每个员工都多养一个保镖，工资（额外内存/CPU）和"进出都多绕一道手"的延迟全是成本。Cilium 的 sidecarless 则像把安保能力直接做进大楼的门禁系统（eBPF 塞进内核）——不给每人配保镖，进出楼时门禁在底层自动处理，省了一大笔保镖开销、还少绕一道。类比失效边界：门禁（eBPF）胜在省钱、快，但受内核能力和 eBPF 程序的表达力所限——那些精细的七层花活（复杂流量镜像、丰富协议解析、逐请求策略）它玩不转，仍不如贴身保镖 Envoy 全面成熟。所以这是一场"成熟灵活（Istio）vs 性能省耗（Cilium）"之争，没有绝对赢家，按治理复杂度和规模选。

这两条路线在延迟、资源、可运维性上的取舍，正是本专题要讲清的。

实现方案

Istio：Envoy sidecar + istiod 控制面

• 数据面：每 Pod 注入一个 Envoy 容器（sidecar）。通过 iptables 规则（由 init 容器 istio-init 写入）把 Pod 的所有入/出流量重定向到 Envoy 端口，业务代码零改动。
• 控制面 istiod：把用户写的路由/策略 CRD 翻译成 Envoy 配置，通过 xDS 协议（LDS/RDS/CDS/EDS）动态下发给所有 sidecar。
• mTLS：istiod 签发工作负载证书，sidecar 之间自动 mTLS，业务明文、网络密文。

# Istio 灰度：90% 打 v1，10% 打 v2（金丝雀）
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: reviews
spec:
  hosts: [reviews]
  http:
    - route:
        - destination: { host: reviews, subset: v1 }
          weight: 90
        - destination: { host: reviews, subset: v2 }
          weight: 10
      retries:                      # 治理能力下沉到网格
        attempts: 3
        perTryTimeout: 2s
---
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: reviews
spec:
  host: reviews
  trafficPolicy:
    tls: { mode: ISTIO_MUTUAL }     # 自动 mTLS
  subsets:
    - name: v1
      labels: { version: v1 }
    - name: v2
      labels: { version: v2 }

Cilium：eBPF 数据面（无 sidecar）

• 每节点一个 Cilium agent，把 L3-L7 策略、负载均衡、加密编译成 eBPF 程序挂到内核挂载点（tc/XDP/socket）。
• 流量在内核态被直接处理与转发，不经过每 Pod 的用户态代理。可替代 kube-proxy 的 iptables（O(1) map 查找）。
• Hubble 基于 eBPF 事件提供 L3-L7 流量的实时可观测（谁访问谁、被哪条策略拒了），无需 sidecar 埋点。

# Cilium L7 策略：只允许 GET /public，其余拒绝（策略在内核 eBPF 执行）
apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: allow-public-get
spec:
  endpointSelector:
    matchLabels: { app: web }
  ingress:
    - fromEndpoints:
        - matchLabels: { app: frontend }
      toPorts:
        - ports:
            - { port: "80", protocol: TCP }
          rules:
            http:
              - method: "GET"
                path: "/public"

sidecar 流量劫持的开销

sidecar 模式里，一次 A→B 调用要经过 App A → Envoy A → Envoy B → App B，每次进出 sidecar 都是一次 iptables 重定向 + socket 收发 + 用户态代理处理——"反复横跳"，多两跳代理与多份内存/CPU。

控制面 / 数据面职责矩阵

面试深水区最常追问的落点是"某组件到底做什么、挂了会怎样、能不能没有"。下表把两家的关键组件平铺展开，"能不能没有" 列取值 必须 / 可弱依赖 / 可选 三态。

Istio 侧

Cilium 侧

边界总结：

• Istio istiod 是集群级 SPOF——单点故障会让新 Pod 起不来（webhook 内置在 istiod 里）、配置冻结、证书轮换倒计时；但已建连接不受影响。
• Cilium 的 SPOF 分层——Cilium Agent 是节点级 SPOF（挂了本节点新 Pod 配不了网），Operator 是集群级弱依赖（挂了短时 OK）；已建连接不受影响。
• 两家的共通规律：控制面挂 ≠ 数据面断；数据面（Envoy 内存里的 xDS 快照 / 内核里的 eBPF 程序）在稳态下自成一体，控制面只在"变更"和"证书轮换"两个窗口成为必要条件。

istiod 可用性推理：挂了集群就断吗？

回答方式是分三层递进，把"断没断"从二值升级到"什么时候开始断、断在哪一层"。

① 已建 mTLS 连接：全程绿灯

Envoy 启动时通过 xDS 从 istiod 拉到 LDS/RDS/CDS/EDS，配置存在 Envoy 内存里；istiod 稳态下不在数据面 hot path 上——业务流量走 Envoy 出/入、Envoy ↔ Envoy 走 mTLS，全程绕过 istiod。所以 istiod 挂掉的瞬间，已建连接继续转发。

② 新连接 / 新 Pod 注入：分层黄灯

• 已存在 Pod 的新连接：走 Envoy 缓存路由（旧配置），照常建立。
• 新增/修改 VS/DR/PeerAuth：无人下发给 Envoy → 变更冻结（旧配置继续生效）。
• 新 Pod 创建：sidecar-injector webhook 内置在 istiod 里，webhook 不可达 → admission 阶段失败 → Pod 直接起不来（若 sidecar.istio.io/inject=true 且 webhook 配置为 FailurePolicy: Fail）。这是 istiod 挂掉最早显现的症状。

③ 证书轮换：绿转红倒计时

Istio 默认 workload 证书 TTL 与提前轮换窗口取决于 WORKLOAD_CERT_TTL 配置（1.18+ 可通过 mesh-config 调整；不写死数字，以配置为准）。Envoy 通过 SDS 从 istiod 拉证书；istiod 挂掉 → SDS 拉不到 → 证书到期后mTLS 握手失败 → 东西向断。这是 istiod 挂掉的最终红灯。

结论行：istiod 短时挂 ≠ 集群断网，但会进入配置冻结 + 证书轮换倒计时。绿→黄→红的分界点分别是"变更请求到来时"和"证书 TTL 到期时"。

Cilium 控制面故障对照

对照 istiod 的三层推理，Cilium 侧最容易被追问的是"Agent / Operator 分别挂了会怎样"。

① Cilium Agent 挂了：per-node 关键组件

Cilium Agent 是每节点一个 DaemonSet 实例。挂了之后：

• 该节点 eBPF 程序仍驻留内核——已建连接继续转发、已加载的 NetworkPolicy 继续生效；这是 eBPF 相对 sidecar 的架构级韧性（sidecar 挂了本 Pod 直接断）。
• 该节点新 Pod 无法完成 CNI ADD——网络配置停滞，Pod 起不来。
• NetworkPolicy 变更不生效——变更需要 Agent 重编译 eBPF 并 bpf() 更新 map。
• identity 分配失败——新工作负载拿不到 identity，被判为不可信。

② Cilium Operator 挂了：集群级弱依赖

• 短时挂 OK——Operator 不在数据面路径上，也不在单节点 CNI 路径上。
• 长时间挂——IPAM 池耗尽（新 Pod 无 IP 可分）；identity 分配失败（依赖模式）；CRD 状态未更新（IPPool、CiliumIdentity 等）。

对比结论表：

记忆锚点：istiod = 集群级 SPOF；Cilium Agent = 节点级 SPOF；Cilium Operator = 集群级弱依赖。数据面（Envoy 内存 / 内核 eBPF）在稳态下都不依赖控制面存活，这是两家共通的"控制面挂 ≠ 数据面断"原则。

架构演进主线

两家的演进不是版本号的堆砌，而是每一步"数据面 / 控制面"各自变了什么——理解演进方向，才能理解今天的形态。

Istio 演进 3 阶段

Cilium 演进 3 阶段

殊途同归：两条路线的收敛

Istio 从 sidecar 走向 Ztunnel + waypoint、Cilium 从 CNI 走向 eBPF + per-node Envoy——两条路线都朝"节点级 L4 + 按需 L7 waypoint"收敛。共同的驱动力：

• 资源放大痛：per-Pod sidecar 意味着每个 Pod 多几十 MB Envoy，10K Pod 集群多几百 GB 内存。
• 运维耦合痛：sidecar 生命周期与 Pod 绑定，Envoy 升级要滚动重启全部 Pod，启动/退出顺序坑一堆。
• 零信任的最小面：只有 L4 + mTLS 是所有工作负载必需的；L7 治理是部分服务的诉求，按需注入更合理。

关键流转细节图

以下 5 张时序/流转图分散补充上文提到的关键路径，每张聚焦一条流。

xDS 推送时序：从 kubectl apply 到 Envoy 生效

要点：xDS 是推送式（istiod 主动 push），不是 Envoy 轮询；LDS/RDS/CDS/EDS 四类资源按依赖顺序推送；Envoy 用ACK/NACK 反馈是否接受。

Sidecar 注入 + iptables 劫持：Pod 是怎么被劫持的

要点：istio-init 写的是 iptables REDIRECT（不是 DNAT）——保留原始目的地址供 Envoy 从 SO_ORIGINAL_DST 读取，用于路由决策；出流量走 15001，入流量走 15006。

Sidecar 流量劫持 · netfilter 五链视图 · 深水区

上一张时序图讲的是"Pod 生命周期里 iptables 什么时候被写入"；这一张聚焦在流量真正进入 Pod 网络命名空间后，netfilter 五链上的走向——面试深水区问"3 倍 socket 开销、3 次内核/用户切换"具体走到哪几个 hook 点时，这张图是标准答案。

读图口径：

• 入向 (Inbound)：外部包 → PREROUTING → 跳到 ISTIO_INBOUND → 命中业务端口 → REDIRECT --to-port 15006 → Envoy 收；然后 Envoy 通过 SO_ORIGINAL_DST 读原目的地址、做完策略后再从 OUTPUT 出（进本地环回）投递给业务容器。
• 出向 (Outbound)：业务包 OUTPUT → 跳到 ISTIO_OUTPUT → 按 owner uid 过滤（业务进程 uid → 走 ISTIO_REDIRECT；Envoy 自己的 uid → RETURN 避免死循环）→ REDIRECT --to-port 15001 → Envoy 处理后再走 TCP 出网卡。
• owner uid 是防死循环的关键：如果不按 uid 过滤，Envoy 转出的包会再次被 OUTPUT 拦回 Envoy 自己，形成无限循环——所以 istio-init 会用 -m owner --uid-owner 1337（默认 Envoy uid=1337）显式 RETURN。

"3 倍 socket 开销"落到这张图：一次 A→B 调用，A 侧走 业务→OUTPUT(→ISTIO_OUTPUT→REDIRECT)→Envoy→OUTPUT→网卡 一次 socket 拆装；B 侧走 网卡→PREROUTING(→ISTIO_INBOUND→REDIRECT)→Envoy→OUTPUT→业务 又一次 socket 拆装。每次 REDIRECT 都是一次完整的 TCP/IP 协议栈遍历 + 用户/内核切换——这是 sidecar 相对 sidecarless（Cilium eBPF 内核态直转）的核心成本项。

为什么 REDIRECT 而不是 DNAT：REDIRECT 是 DNAT 的特化，专用于"改到本机某端口"，且保留原始目的地址在 socket 元数据里（SO_ORIGINAL_DST）供上层 Envoy 读取。用 DNAT 则原目的地址会被覆盖，Envoy 拿不到"业务原本想访问的服务"，路由决策无从做起。

mTLS 握手时序：证书从哪来、SAN 怎么验

要点：证书不落盘（走 SDS 从 istiod 内存取），SAN 用 SPIFFE 格式 spiffe://<trust-domain>/ns/<ns>/sa/<service-account>，验证的是工作负载身份而非 Pod IP。

Cilium eBPF hook 点：内核在哪几处被挂了钩

要点：XDP 是最早的挂载点（丢包/负载均衡开销最小，但 metadata 有限）；tc ingress/egress 是主战场（NetworkPolicy、L4 LB、Encryption 都在这层）；socket/cgroup 处理同节点 hairpin（同节点两个 Pod 直接在 socket 层被 Cilium 短路，绕开 TCP/IP 栈往返）。

Cilium 控制面下发路径：从 CNP 到 eBPF map

要点：Cilium Agent 是节点本地组件，直接调用 bpf() syscall 更新内核 eBPF map；Operator 只做集群级协调（IPAM、identity），不在单节点策略下发路径上——这是 Cilium 控制面低耦合的关键。

为什么这么做

• 为什么把能力下沉到网格：mTLS/灰度/重试/可观测是跨服务共性，下沉后业务零改动、统一策略、集中运维，改治理不改业务代码。
• 为什么 eBPF 能省掉 sidecar 反复横跳：eBPF 程序运行在内核态，流量到达内核时就地做策略与转发，不必上送到每个 Pod 的用户态代理再下来。省掉 sidecar 的 iptables 劫持、额外 socket、用户态拷贝与代理进程本身的内存/CPU。

为什么别的选择不行

沉淀结论

记忆口诀

Istio：Envoy sidecar / istiod 控制面 / xDS 下发 / 功能全但横跳
Cilium：eBPF 无 sidecar / 内核态直转 / Hubble 可观测 / 省资源但依赖内核
取舍：成熟通用治理 vs 内核态高性能

相关专题：eBPF 原理与落地 · CNI 与 K8s 网络插件 · 中心化 vs 去中心化网格 · 自研 Mesh × K8s · 自研 Mesh 数据面深水区

内容来源

综合整理。参考方向：Istio 官方文档（架构、istiod 合体演进、Envoy sidecar、xDS 协议 LDS/RDS/CDS/EDS、VirtualService/DestinationRule、mTLS + SDS + SPIFFE、iptables REDIRECT 注入、ISTIO_INBOUND / ISTIO_OUTPUT / ISTIO_REDIRECT 自定义链与 owner uid 防死循环、Ambient Mesh / Ztunnel / waypoint）、Cilium 官方文档（eBPF 数据面挂载点 XDP/tc/socket、sidecarless、CiliumNetworkPolicy、Agent + Operator 分工、替代 kube-proxy、Hubble、Service Mesh + Gateway API + Cluster Mesh）、Envoy xDS 协议说明、eBPF 内核挂载点原理、Linux netfilter 五链模型。

自测：合上资料能说清楚吗？

Istio 是怎么在业务代码零改动的前提下，把所有进出流量劫持到 Envoy sidecar 的？

istiod 是怎么把用户写的路由/策略配置生效到成百上千个 sidecar 上的？

同样做服务网格，Istio sidecar 和 Cilium eBPF 在延迟与资源上的核心差异是什么？

既然 eBPF sidecarless 又快又省，为什么 Istio 仍被大量采用？

游戏里的帧内多跳低延迟通信，能直接套用 Istio/Cilium 这类 Mesh 吗？

istiod 挂了以后集群会不会立刻断网？分层说清"什么继续能用、什么先坏、什么最后坏"。

Istio 从 1.0 多进程走到 1.5 istiod 再到 1.18+ Ambient，每一步"数据面/控制面"各自变了什么？

Cilium Agent 和 Cilium Operator 各自挂了会怎样？和 istiod 挂了的影响面对比一下。