Cilium在 2026 年到底能为我们带来什么

Shengxu included in Kubernetes DevOps Observability

2026-03-08 About 3100 words 15 minutes

Contents

——它到底带来了什么有意义的改变，以及该如何与 Istio 分工协作

到了 2026 年，很多团队讨论 Cilium，已经不是在问“它值不值得试试”，而是在问：“我们什么时候该迁过去？” 真正推动迁移的原因，通常不是单一的性能数字，而是 Cilium 把 Kubernetes 网络、安全、可观测性和多集群能力，重新组织成了一套更统一的基础设施底座。

一、这不是“换一个 CNI”，而是在换网络范式

如果只把 Cilium 理解成“一个更快的 CNI”，其实会低估它的意义。

在很多传统 Kubernetes 集群里，网络栈通常是这样拼起来的：

一个 CNI 负责 Pod 连通
kube-proxy 负责 Service 转发
iptables 或 IPVS 负责规则处理
NetworkPolicy 负责基础隔离
额外的日志、抓包、Service Mesh 再补上观测和治理
多集群互联往往还要叠一层 DNS、网关或服务同步系统

这些组件都能工作，但随着系统规模增大，问题会逐渐从“功能够不够”变成“整体还能不能维护”：

规则越来越多
Service 变化越来越频繁
网络路径越来越难解释
故障越来越难排查
安全策略越来越像在记 IP
多集群和多云越来越像外挂系统

Cilium 真正改变的，不是“网络能不能通”，而是以下四件事：

流量是怎么被处理的
安全边界是怎么被表达的
问题是怎么被观测和排查的
多集群和多云是怎么被统一起来的

换句话说，Cilium 不是只替换掉某一个组件，而是在试图把原本分散在多个层次的问题，尽量收敛到一个统一的数据平面里。

传统拼装栈 vs Cilium 统一底座

flowchart TB
    subgraph OLD["传统拼装式网络栈"]
        direction LR
        O1[CNI: Pod 连通]
        O2[kube-proxy: Service 转发]
        O3[iptables/IPVS: 规则处理]
        O4[NetworkPolicy: 基础隔离]
        O5[额外组件: 抓包/日志/Mesh]
        O6[多集群外挂: DNS/网关/同步]
        O1 --> O2 --> O3 --> O4 --> O5 --> O6
    end

    subgraph NEW["Cilium 统一底座"]
        direction LR
        N1[eBPF Datapath]
        N2[Service LB]
        N3[Identity Policy]
        N4[Hubble Observability]
        N5[ClusterMesh]
        N1 --> N2
        N1 --> N3
        N1 --> N4
        N1 --> N5
    end

    O6 -. 架构收敛/能力统一 .-> N1

flowchart TB
    subgraph OLD["传统拼装式网络栈"]
        direction LR
        O1[CNI: Pod 连通]
        O2[kube-proxy: Service 转发]
        O3[iptables/IPVS: 规则处理]
        O4[NetworkPolicy: 基础隔离]
        O5[额外组件: 抓包/日志/Mesh]
        O6[多集群外挂: DNS/网关/同步]
        O1 --> O2 --> O3 --> O4 --> O5 --> O6
    end

    subgraph NEW["Cilium 统一底座"]
        direction LR
        N1[eBPF Datapath]
        N2[Service LB]
        N3[Identity Policy]
        N4[Hubble Observability]
        N5[ClusterMesh]
        N1 --> N2
        N1 --> N3
        N1 --> N4
        N1 --> N5
    end

    O6 -. 架构收敛/能力统一 .-> N1

flowchart TB
    subgraph OLD["传统拼装式网络栈"]
        direction LR
        O1[CNI: Pod 连通]
        O2[kube-proxy: Service 转发]
        O3[iptables/IPVS: 规则处理]
        O4[NetworkPolicy: 基础隔离]
        O5[额外组件: 抓包/日志/Mesh]
        O6[多集群外挂: DNS/网关/同步]
        O1 --> O2 --> O3 --> O4 --> O5 --> O6
    end

    subgraph NEW["Cilium 统一底座"]
        direction LR
        N1[eBPF Datapath]
        N2[Service LB]
        N3[Identity Policy]
        N4[Hubble Observability]
        N5[ClusterMesh]
        N1 --> N2
        N1 --> N3
        N1 --> N4
        N1 --> N5
    end

    O6 -. 架构收敛/能力统一 .-> N1

二、Cilium 首先改变了 Kubernetes 的数据平面

Cilium 最关键的变化，是把 Kubernetes 的关键路径从传统规则链模型，推进到 eBPF 驱动的数据平面。

很多人听到这里的第一反应是：“所以它更快。” 这当然常常成立，但更准确的说法应该是：

Cilium 改变的不是单纯的性能结果，而是性能问题出现的原因。

在传统 kube-proxy + iptables/IPVS 路径里，Service 转发通常依赖规则系统来完成。当 Service 多、Endpoint 变化频繁、节点多、连接密度高时，平台团队就会长期和这些问题打交道：

kube-proxy 同步规则
规则链膨胀
conntrack 压力
NAT 行为复杂
路径不够直观
更新成本越来越高

而在 Cilium 里，Service 负载均衡、后端选择、部分转发逻辑，可以更早在内核的数据路径中完成。

这意味着：

路径更短
更新更轻
规则更少
可视化更强
大规模时的性能曲线更稳定

也正因为如此，Cilium 的价值不只是“帮你跑得更快”，而是“帮你减少平台长期围绕 kube-proxy 和规则系统产生的维护负担”。

三、一个具体例子：Pod 访问 ClusterIP Service 时，Cilium 到底改了什么

假设有一个 checkout Pod，要访问 payments.default.svc.cluster.local。

在传统模型里，流量大致会经历下面这类逻辑：

应用访问 Service ClusterIP
包进入节点网络栈
kube-proxy 维护的规则决定该转发到哪个后端
iptables/IPVS 做 NAT 或转发
包再被送到某个后端 Pod

而在 Cilium 的 kube-proxy replacement 模式下，这个过程会更接近这样：

应用访问 Service ClusterIP
eBPF 程序在更早的位置捕获这次 Service 访问
直接查询 BPF map 中的 Service 与后端映射
选出 backend
将流量按更短路径送往后端 Pod

这里真正被改变的，不是“最终也能访问到后端”这个结果，而是中间那一长段传统规则链式处理路径被缩短了。

传统路径 vs Cilium 路径

flowchart LR
    A[checkout Pod] --> B[payments ClusterIP]

    subgraph T["传统 kube-proxy / iptables"]
        B --> C[kube-proxy rules]
        C --> D[iptables / IPVS]
        D --> E[selected backend Pod]
    end

    subgraph CILIUM["Cilium eBPF datapath"]
        B --> F[eBPF service lookup]
        F --> G[BPF Map]
        G --> H[selected backend Pod]
    end

flowchart LR
    A[checkout Pod] --> B[payments ClusterIP]

    subgraph T["传统 kube-proxy / iptables"]
        B --> C[kube-proxy rules]
        C --> D[iptables / IPVS]
        D --> E[selected backend Pod]
    end

    subgraph CILIUM["Cilium eBPF datapath"]
        B --> F[eBPF service lookup]
        F --> G[BPF Map]
        G --> H[selected backend Pod]
    end

flowchart LR
    A[checkout Pod] --> B[payments ClusterIP]

    subgraph T["传统 kube-proxy / iptables"]
        B --> C[kube-proxy rules]
        C --> D[iptables / IPVS]
        D --> E[selected backend Pod]
    end

    subgraph CILIUM["Cilium eBPF datapath"]
        B --> F[eBPF service lookup]
        F --> G[BPF Map]
        G --> H[selected backend Pod]
    end

一个很现实的工程含义

如果你的集群里只有几十个 Service，这件事的价值可能不明显。但如果你的集群有上千个 Service、频繁滚动发布、HPA/CA 持续扩缩容，那么“每次变更都要更新一大堆规则”这件事本身就会变成长期成本。

Cilium 的吸引力就在这里：

不是只帮你把一个请求提速
而是在减少整个平台围绕 Service 规则管理的维护负担
让网络数据路径更像“系统能力”，而不是“规则拼装结果”

配置示意：启用 kube-proxy replacement

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
# values.yaml
kubeProxyReplacement: true

routingMode: native

bpf:
  masquerade: true

socketLB:
  hostNamespaceOnly: true

这段配置背后的意义

这类配置不是为了“炫技”，而是说明 Cilium 的 Service 转发能力已经从传统 kube-proxy 规则链，前移到 eBPF 数据平面。也正因为它做得更早，所以一旦你和 Istio 等 L7 系统一起使用时，就必须清楚谁该在哪一层接管流量。

四、它改变了安全模型：从“按 IP 管理”到“按身份管理”

传统基础设施网络里，安全规则通常围绕这些对象展开：

IP
子网
端口
静态 ACL
边界防火墙

但 Kubernetes 的现实恰恰是：

IP 是会频繁变化的，而工作负载身份更稳定。

这意味着，如果还把安全边界主要建立在 IP 上，你迟早会遇到这些问题：

Pod 重建后 IP 变了，策略理解成本很高
多环境之间同一业务的地址表达完全不同
规则越来越像“记地址”而不是“表达业务关系”
扩缩容后安全策略和业务语义脱节

Cilium 把“身份”放到了更中心的位置。这使得安全表达更接近业务语义，例如：

哪个命名空间能访问哪个服务
哪类工作负载能访问数据库
哪些 Pod 允许访问外部域名
哪些流量只能走加密路径

IP 驱动策略 vs 身份驱动策略

flowchart LR
    subgraph IPModel["传统 IP 驱动"]
        direction TB
        I1[策略对象: IP/CIDR]
        I2[变更触发: Pod IP 漂移]
        I3[维护方式: 地址表更新]
        I4[风险: 规则与业务语义脱节]
        I1 --> I2 --> I3 --> I4
    end

    subgraph IdentityModel["Cilium 身份驱动"]
        direction TB
        C1[策略对象: Labels/Identity]
        C2[变更触发: 工作负载角色变化]
        C3[维护方式: 业务关系建模]
        C4[收益: 策略与语义一致]
        C1 --> C2 --> C3 --> C4
    end

    IPModel ~~~ IdentityModel

flowchart LR
    subgraph IPModel["传统 IP 驱动"]
        direction TB
        I1[策略对象: IP/CIDR]
        I2[变更触发: Pod IP 漂移]
        I3[维护方式: 地址表更新]
        I4[风险: 规则与业务语义脱节]
        I1 --> I2 --> I3 --> I4
    end

    subgraph IdentityModel["Cilium 身份驱动"]
        direction TB
        C1[策略对象: Labels/Identity]
        C2[变更触发: 工作负载角色变化]
        C3[维护方式: 业务关系建模]
        C4[收益: 策略与语义一致]
        C1 --> C2 --> C3 --> C4
    end

    IPModel ~~~ IdentityModel

flowchart LR
    subgraph IPModel["传统 IP 驱动"]
        direction TB
        I1[策略对象: IP/CIDR]
        I2[变更触发: Pod IP 漂移]
        I3[维护方式: 地址表更新]
        I4[风险: 规则与业务语义脱节]
        I1 --> I2 --> I3 --> I4
    end

    subgraph IdentityModel["Cilium 身份驱动"]
        direction TB
        C1[策略对象: Labels/Identity]
        C2[变更触发: 工作负载角色变化]
        C3[维护方式: 业务关系建模]
        C4[收益: 策略与语义一致]
        C1 --> C2 --> C3 --> C4
    end

    IPModel ~~~ IdentityModel

一个具体例子：payments 只能被 checkout 访问

假设你有如下目标：

checkout 服务可以访问 payments
frontend 不能直接访问 payments
payments 不能任意访问公网，只能访问指定支付网关

在传统思路里，你很容易把它写成一堆 IP、端口、CIDR 规则。而在 Cilium 里，更自然的写法是围绕“工作负载身份”和“标签”来表达。

CiliumNetworkPolicy 示例

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: payments-policy
  namespace: production
spec:
  endpointSelector:
    matchLabels:
      app: payments
  ingress:
    - fromEndpoints:
        - matchLabels:
            app: checkout
      toPorts:
        - ports:
            - port: "8443"
              protocol: TCP
  egress:
    - toFQDNs:
        - matchName: api.stripe.com
      toPorts:
        - ports:
            - port: "443"
              protocol: TCP

这段策略真正改变了什么

这段策略的重点，不只是“它能限制流量”，而是：

它表达的是业务关系，不是节点地址记忆题
它更适合 Kubernetes 这种动态环境
它让安全策略和工作负载身份保持一致
它让安全规则更像“系统设计”，而不是“地址表维护”

当系统规模上来之后，这种表达方式的价值会越来越大。

五、它改变了可观测性：Hubble 为什么不是“又一个监控工具”

很多团队真正开始喜欢 Cilium，不是因为第一天就感受到了性能，而是因为第二次故障排查时，突然发现问题变得更容易看清了。

过去一次“服务访问失败”，平台团队经常要跨很多系统去排查：

应用日志
sidecar 日志
kube-proxy 日志
iptables 规则
tcpdump
节点路由
DNS 记录
云厂商 VPC 日志
Prometheus 指标

这些工具都没错，但它们分散在不同层。问题在于：一次故障发生时，你首先需要知道“从哪一层开始查”。

Hubble 的价值，就是把网络层最关键的这些信息直接放在一起：

谁在访问谁
流量方向是什么
是否被策略拒绝
DNS 是否正常
流量有没有真正离开源 Pod
是被网络挡住，还是请求到了应用层才失败

一个具体例子：checkout 调 payments 失败

假设 checkout 调 payments 出现超时。

你可以把排障拆成两层。

先看 Hubble

关注：

有没有从 checkout 发出的流
目标是不是 payments
verdict 是 FORWARDED 还是 DROPPED
有没有 DNS 请求失败
有没有 egress policy 拦截

再看 Istio / Kiali / Tracing

关注：

请求有没有进入 sidecar 或 Ambient data plane
有没有路由到错误版本
有没有 5xx
有没有超时、重试、熔断
链路上具体耗时在哪一跳

这样一来，问题就从“要看一堆工具”，变成了“先判定网络层，再判定 L7 层”。

故障排查决策流

flowchart TD
    A[checkout 调 payments 超时] --> B{Hubble 有 Flow 吗}
    B -- 否 --> C[优先查网络连通与 DNS]
    B -- 是 --> D{verdict 是否 DROPPED}
    D -- 是 --> E[查 Cilium 策略与 Identity]
    D -- 否 --> F{是否已进入 Istio 数据面}
    F -- 否 --> G[查 sidecar/ambient 接入与路由]
    F -- 是 --> H[查 L7 5xx/超时/重试/熔断]
    C --> Z[定位并修复]
    E --> Z
    G --> Z
    H --> Z

flowchart TD
    A[checkout 调 payments 超时] --> B{Hubble 有 Flow 吗}
    B -- 否 --> C[优先查网络连通与 DNS]
    B -- 是 --> D{verdict 是否 DROPPED}
    D -- 是 --> E[查 Cilium 策略与 Identity]
    D -- 否 --> F{是否已进入 Istio 数据面}
    F -- 否 --> G[查 sidecar/ambient 接入与路由]
    F -- 是 --> H[查 L7 5xx/超时/重试/熔断]
    C --> Z[定位并修复]
    E --> Z
    G --> Z
    H --> Z

flowchart TD
    A[checkout 调 payments 超时] --> B{Hubble 有 Flow 吗}
    B -- 否 --> C[优先查网络连通与 DNS]
    B -- 是 --> D{verdict 是否 DROPPED}
    D -- 是 --> E[查 Cilium 策略与 Identity]
    D -- 否 --> F{是否已进入 Istio 数据面}
    F -- 否 --> G[查 sidecar/ambient 接入与路由]
    F -- 是 --> H[查 L7 5xx/超时/重试/熔断]
    C --> Z[定位并修复]
    E --> Z
    G --> Z
    H --> Z

Cilium + Istio 的观测分层图

flowchart TD
    A[checkout Pod] --> B[payments Pod]

    subgraph Cilium["Cilium / Hubble"]
        C[eBPF datapath]
        D[Flow visibility]
        E[Policy verdict]
        F[DNS / L3 / L4]
    end

    subgraph Istio["Istio / Kiali / Tracing"]
        G[Envoy sidecar or ambient]
        H[L7 metrics]
        I[Tracing]
        J[Service graph]
    end

    A --> C
    B --> C
    C --> D
    C --> E
    C --> F

    A --> G
    B --> G
    G --> H
    G --> I
    G --> J

flowchart TD
    A[checkout Pod] --> B[payments Pod]

    subgraph Cilium["Cilium / Hubble"]
        C[eBPF datapath]
        D[Flow visibility]
        E[Policy verdict]
        F[DNS / L3 / L4]
    end

    subgraph Istio["Istio / Kiali / Tracing"]
        G[Envoy sidecar or ambient]
        H[L7 metrics]
        I[Tracing]
        J[Service graph]
    end

    A --> C
    B --> C
    C --> D
    C --> E
    C --> F

    A --> G
    B --> G
    G --> H
    G --> I
    G --> J

flowchart TD
    A[checkout Pod] --> B[payments Pod]

    subgraph Cilium["Cilium / Hubble"]
        C[eBPF datapath]
        D[Flow visibility]
        E[Policy verdict]
        F[DNS / L3 / L4]
    end

    subgraph Istio["Istio / Kiali / Tracing"]
        G[Envoy sidecar or ambient]
        H[L7 metrics]
        I[Tracing]
        J[Service graph]
    end

    A --> C
    B --> C
    C --> D
    C --> E
    C --> F

    A --> G
    B --> G
    G --> H
    G --> I
    G --> J

Hubble 启用示意

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
# values.yaml
hubble:
  enabled: true
  relay:
    enabled: true
  ui:
    enabled: true
  metrics:
    enableOpenMetrics: true
    enabled:
      - dns
      - drop
      - flow
      - tcp
      - policy

这件事真正解决了什么

Hubble 最有价值的地方，不是“图很好看”，而是它让以下问题变得更容易回答：

是不是网络没通？
是不是策略杀错了？
是不是 DNS 出问题？
是不是根本没到 Istio？
是不是流量已经到了 L7，才在应用治理层失败？

这类问题越多，你越会发现：

Cilium 的观测价值，本质上是缩短排障路径。

六、它改变了多集群与多云：从“外挂互联”到“网络底座原生理解跨集群”

很多团队最开始接触 Cilium，是因为单集群网络；但真正决定他们长期投入的，常常是多集群和多云。

假设你现在有这样的架构：

一部分业务在 EKS
一部分业务在 AKS
生产和灾备各自独立
某些基础服务希望跨集群共享
但你又不想搭一套额外的跨集群代理系统来维护

传统做法里，多集群互联常常意味着：

单独的服务发现同步
额外的网关
跨集群流量代理
独立的策略体系
复杂的 DNS 设计
故障时很难判断问题是在集群内还是集群间

Cilium ClusterMesh 的吸引力在于，它试图把多集群理解成“网络底座的延伸”，而不是“在集群外面再补一层系统”。

一个具体例子：同名 payments 服务同时运行在 EKS 和 AKS

你希望做到：

两边都有 payments 服务
本地优先访问本集群实例
故障时可以跨集群切换
策略和观测尽可能延续同一套模型

这时候，Cilium 的思路不是额外堆一个“跨集群业务层”，而是让底层网络和服务发现更自然地理解多集群。

ClusterMesh 示意图

flowchart LR
    subgraph EKS["Cluster A / EKS"]
        A1[Pods]
        A2[Cilium Agent]
        A3[ClusterMesh API]
        A4[payments svc]
    end

    subgraph AKS["Cluster B / AKS"]
        B1[Pods]
        B2[Cilium Agent]
        B3[ClusterMesh API]
        B4[payments svc]
    end

    A2 <-- state sync --> B3
    B2 <-- state sync --> A3
    A4 <-- global service --> B4
    A1 <-- pod-to-pod / svc-to-svc --> B1

flowchart LR
    subgraph EKS["Cluster A / EKS"]
        A1[Pods]
        A2[Cilium Agent]
        A3[ClusterMesh API]
        A4[payments svc]
    end

    subgraph AKS["Cluster B / AKS"]
        B1[Pods]
        B2[Cilium Agent]
        B3[ClusterMesh API]
        B4[payments svc]
    end

    A2 <-- state sync --> B3
    B2 <-- state sync --> A3
    A4 <-- global service --> B4
    A1 <-- pod-to-pod / svc-to-svc --> B1

flowchart LR
    subgraph EKS["Cluster A / EKS"]
        A1[Pods]
        A2[Cilium Agent]
        A3[ClusterMesh API]
        A4[payments svc]
    end

    subgraph AKS["Cluster B / AKS"]
        B1[Pods]
        B2[Cilium Agent]
        B3[ClusterMesh API]
        B4[payments svc]
    end

    A2 <-- state sync --> B3
    B2 <-- state sync --> A3
    A4 <-- global service --> B4
    A1 <-- pod-to-pod / svc-to-svc --> B1

本地优先与跨集群切换时序

sequenceDiagram
    participant Client as checkout Pod (EKS)
    participant Svc as payments.global Service
    participant Local as payments Pod (EKS)
    participant Remote as payments Pod (AKS)

    Client->>Svc: 发起请求
    Svc->>Local: 优先路由到本地后端
    Local-->>Client: 正常响应

    Note over Local: 本地故障/不可达
    Client->>Svc: 重试请求
    Svc->>Remote: 切换到跨集群后端
    Remote-->>Client: 返回响应

sequenceDiagram
    participant Client as checkout Pod (EKS)
    participant Svc as payments.global Service
    participant Local as payments Pod (EKS)
    participant Remote as payments Pod (AKS)

    Client->>Svc: 发起请求
    Svc->>Local: 优先路由到本地后端
    Local-->>Client: 正常响应

    Note over Local: 本地故障/不可达
    Client->>Svc: 重试请求
    Svc->>Remote: 切换到跨集群后端
    Remote-->>Client: 返回响应

sequenceDiagram
    participant Client as checkout Pod (EKS)
    participant Svc as payments.global Service
    participant Local as payments Pod (EKS)
    participant Remote as payments Pod (AKS)

    Client->>Svc: 发起请求
    Svc->>Local: 优先路由到本地后端
    Local-->>Client: 正常响应

    Note over Local: 本地故障/不可达
    Client->>Svc: 重试请求
    Svc->>Remote: 切换到跨集群后端
    Remote-->>Client: 返回响应

Global Service 示例

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
apiVersion: v1
kind: Service
metadata:
  name: payments
  namespace: production
  annotations:
    service.cilium.io/global: "true"
    service.cilium.io/affinity: "local"
spec:
  selector:
    app: payments
  ports:
    - port: 443
      targetPort: 8443

这类能力真正有吸引力的地方

不是“多了一个 annotation”，而是你把“多集群流量”从额外外挂系统，变成了网络底座自己能理解的能力。

对于平台团队来说，这种统一感非常重要：

策略模型更一致
服务发现更自然
多云拓扑更容易被解释
故障边界更清晰

七、为什么越来越多团队主动迁移到 Cilium

如果只看表面，会觉得大家迁移 Cilium 是为了更快。但真实世界里，迁移动机通常是下面这些因素叠加。

1. 他们想摆脱 kube-proxy 与规则系统的长期负担

一开始 kube-proxy 没什么问题，iptables 也够用。但集群规模大了之后，规则管理本身会变成平台成本。

Cilium 的吸引力，往往不是“它跑分更高”，而是：

Service 路径更可控
规则更新负担下降
高变更环境更适合
平台不必长期围绕 kube-proxy 做补丁式维护

2. 他们想缩短排障路径

很多平台团队真正喜欢 Hubble，不是因为它多了多少指标，而是因为它减少了“无效排查”。

过去一次故障可能要找三四个团队：

平台团队看网络
安全团队看策略
应用团队看日志
Mesh 团队看 sidecar

而 Cilium 的价值之一，是让网络层问题先被更快地定性。这会显著降低“先怀疑谁”的沟通成本。

3. 他们想让网络、安全和观测更统一

当一个平台进入成熟期，最痛的往往不是某个点不够强，而是同类能力分散在多套系统里。

Cilium 很有吸引力的一点就是：

网络与策略共享同一条数据路径
观测直接建立在数据平面之上
多集群能力也不再完全依赖外挂方案

4. 他们的基础设施已经进入平台化阶段

当团队开始管理：

多集群
多环境
多云
混合工作负载
更严格的合规要求

这时候，单点优化已经不够了。他们需要的是一个可以长期承载平台演进的底座，而不是再多一套拼装组件。

八、采用 Cilium 的真实成本：它不是没有代价，而是代价变了

讨论 Cilium 时，一个常见误区是只看到它的收益，却忽略了它把复杂度从旧世界搬到了新世界。

传统网络栈的复杂度，更多体现在：

kube-proxy
iptables
IPVS
旁路抓包
额外安全组件
多套观测系统

而 Cilium 的复杂度，更多体现在：

Linux Kernel 能力
eBPF 数据平面理解
Identity 治理
BPF Maps 资源管理
新的排障心智模型

所以更准确的说法不是“Cilium 更简单”，而是：

它用更统一的架构，替换了更分散的复杂性。

复杂度迁移图

flowchart LR
    subgraph OldCost["旧世界复杂度"]
        O1[kube-proxy 规则同步]
        O2[iptables/IPVS 规则链]
        O3[旁路抓包与多工具排障]
        O4[多套系统边界不清]
    end

    subgraph NewCost["新世界复杂度"]
        N1[Kernel 基线能力]
        N2[eBPF 数据路径理解]
        N3[Identity/Label 治理]
        N4[BPF Maps 资源管理]
    end

    O1 --> N2
    O2 --> N4
    O3 --> N2
    O4 --> N3

flowchart LR
    subgraph OldCost["旧世界复杂度"]
        O1[kube-proxy 规则同步]
        O2[iptables/IPVS 规则链]
        O3[旁路抓包与多工具排障]
        O4[多套系统边界不清]
    end

    subgraph NewCost["新世界复杂度"]
        N1[Kernel 基线能力]
        N2[eBPF 数据路径理解]
        N3[Identity/Label 治理]
        N4[BPF Maps 资源管理]
    end

    O1 --> N2
    O2 --> N4
    O3 --> N2
    O4 --> N3

flowchart LR
    subgraph OldCost["旧世界复杂度"]
        O1[kube-proxy 规则同步]
        O2[iptables/IPVS 规则链]
        O3[旁路抓包与多工具排障]
        O4[多套系统边界不清]
    end

    subgraph NewCost["新世界复杂度"]
        N1[Kernel 基线能力]
        N2[eBPF 数据路径理解]
        N3[Identity/Label 治理]
        N4[BPF Maps 资源管理]
    end

    O1 --> N2
    O2 --> N4
    O3 --> N2
    O4 --> N3

1. 内核版本不只是门槛

Cilium 的很多核心能力，都和较新的 Linux Kernel 能力直接相关。

这意味着，在老旧 OS、老旧企业镜像、受限托管节点环境里，Cilium 的收益可能无法完整释放。有时候你以为自己是在“迁移 CNI”，其实是在推动一次底层节点基线升级。

2. Cilium 不是没有状态，而是把状态放进了新的位置

传统系统里你盯的是规则链。 Cilium 里你要开始盯：

BPF Maps
Identity 数量
labels 设计
map 使用率
控制面同步成本

如果标签体系很乱，身份模型就会变得昂贵；如果集群规模很大，BPF Maps 也会成为真正需要监控和调优的资源。

3. 调试方式会变化

以前你习惯：

看 iptables
看 kube-proxy
tcpdump
查路由

现在你还要开始理解：

流量在哪个 hook 被接住
哪条流量是否走了 socket 级路径
哪个 verdict 是被哪一层策略打出来的
某个问题是不是 map、identity 或内核能力带来的

这并不意味着每个人都要变成内核工程师，但确实意味着平台团队需要建立新的排障思维。

九、但 Cilium 并不适合所有场景

正因为 Cilium 改变得比较深，它也不是任何环境里的默认最优解。

1. 你的集群很小，需求很简单

如果只是小规模集群、少量 Service、简单策略、低观测要求，那么 Cilium 的很多能力可能暂时还不值得。

这时轻量方案的性价比会更高。

2. 你的团队还没准备好接受新的平台能力模型

Cilium 的收益很大一部分来自“统一”，但统一也意味着团队要愿意承担更强的平台责任。

如果你现在的组织状态更适合“先稳定跑起来”，而不是“重构网络底座”，那就不一定要立刻全面迁移。

3. 你的重点在复杂 L7 治理

Cilium 在 L3/L4 和基础设施层能力上非常强。但如果你的重点是：

大规模 mTLS
复杂 HTTP/gRPC 路由
细粒度 L7 鉴权
流量灰度
熔断和重试策略
更成熟的服务网格控制平面

那么 Istio 仍然会更强。

十、2026 年，Cilium 与 Istio 最好的关系不是替代，而是分工

到了 2026 年，更成熟的看法已经不是“Cilium 和 Istio 二选一”，而是它们分别解决不同层的问题。

Cilium 更适合负责什么

CNI 与节点间网络
kube-proxy replacement
L3/L4 网络策略
底层流量加密
网络层可观测性
服务依赖的网络视角

Istio 更适合负责什么

mTLS
L7 路由治理
灰度发布
重试、熔断、故障注入
应用层 tracing
服务网格控制平面

两者一起时的最佳分工图

flowchart TD
    subgraph Infra["基础设施层"]
        A[Cilium CNI]
        B[eBPF datapath]
        C[Hubble]
        D[L3/L4 policy]
    end

    subgraph AppMesh["应用治理层"]
        E[Istio data plane]
        F[mTLS]
        G[L7 routing]
        H[Tracing / Kiali]
    end

    A --> B
    B --> C
    B --> D
    B --> E
    E --> F
    E --> G
    E --> H

flowchart TD
    subgraph Infra["基础设施层"]
        A[Cilium CNI]
        B[eBPF datapath]
        C[Hubble]
        D[L3/L4 policy]
    end

    subgraph AppMesh["应用治理层"]
        E[Istio data plane]
        F[mTLS]
        G[L7 routing]
        H[Tracing / Kiali]
    end

    A --> B
    B --> C
    B --> D
    B --> E
    E --> F
    E --> G
    E --> H

flowchart TD
    subgraph Infra["基础设施层"]
        A[Cilium CNI]
        B[eBPF datapath]
        C[Hubble]
        D[L3/L4 policy]
    end

    subgraph AppMesh["应用治理层"]
        E[Istio data plane]
        F[mTLS]
        G[L7 routing]
        H[Tracing / Kiali]
    end

    A --> B
    B --> C
    B --> D
    B --> E
    E --> F
    E --> G
    E --> H

一个很实用的理解方式

Cilium 解决的是：包如何高效、安全、可见地到达
Istio 解决的是：请求如何被可信地治理、编排和审计

这不是重叠，而是天然分层。

十一、一个更符合 2026 年现实的最佳实践

如果你是一个中大型平台团队，一个非常现实而稳妥的组合通常是：

用 Cilium 作为 CNI
按需启用 kube-proxy replacement
用 Hubble 做网络层观测与策略排障
用 Istio 做 mTLS 与 L7 治理
用统一的 Prometheus/Grafana 聚合指标
用 Kiali/Tracing 负责应用层链路理解
排障时固定顺序：先网络，再策略，再 L7，再应用

示例：Cilium + Istio 的组合思路

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
# Cilium values.yaml（示意）
kubeProxyReplacement: true

hubble:
  enabled: true
  relay:
    enabled: true
  ui:
    enabled: true

socketLB:
  hostNamespaceOnly: true

1
2
3
4
5
6
7
8
# Istio 侧（示意原则）
meshConfig:
  enableTracing: true

values:
  pilot:
    env:
      EXTERNAL_ISTIOD: false

这套组合最重要的不是“所有功能都打开”，而是要明确：

网络由谁先接管
哪些路径应该保留给 Istio
观测链路如何分层
排障顺序如何标准化

十二、迁移到 Cilium 前，团队应该先回答的四个问题

1. 我们的节点内核和基础镜像，是否真的能支持想启用的 Cilium 特性？

如果不能，你获得的可能只是“装上了”，而不是“真正吃到收益”。

2. 我们是否能接受一次性的节点镜像或内核升级成本？

很多迁移项目真正卡住的，不是技术本身，而是基础设施基线。

3. 我们现在的 labels 设计，是否足够干净，能支撑 Identity 驱动的策略模型？

如果标签体系混乱，Cilium 的身份模型可能会带来额外负担。

4. 我们的运维体系，是否已经准备好围绕 Hubble、BPF Maps、Identity 和内核能力来排障？

如果没有准备好，那么更合适的方式通常不是“一步到位全面替换”，而是“先试点，再迁移”。

迁移决策树（先试点再推广）

flowchart TD
    A[开始评估 Cilium 迁移] --> B{内核/镜像基线满足吗}
    B -- 否 --> C[先升级节点基线]
    B -- 是 --> D{标签体系可支撑 Identity 吗}
    D -- 否 --> E[先治理 Labels 规范]
    D -- 是 --> F{运维团队具备 Hubble/BPF 排障能力吗}
    F -- 否 --> G[先做培训与演练]
    F -- 是 --> H[选择一个业务域做试点]
    C --> H
    E --> H
    G --> H
    H --> I{试点稳定并达成目标吗}
    I -- 否 --> J[回滚或缩小范围继续优化]
    I -- 是 --> K[分批迁移到更多集群]

flowchart TD
    A[开始评估 Cilium 迁移] --> B{内核/镜像基线满足吗}
    B -- 否 --> C[先升级节点基线]
    B -- 是 --> D{标签体系可支撑 Identity 吗}
    D -- 否 --> E[先治理 Labels 规范]
    D -- 是 --> F{运维团队具备 Hubble/BPF 排障能力吗}
    F -- 否 --> G[先做培训与演练]
    F -- 是 --> H[选择一个业务域做试点]
    C --> H
    E --> H
    G --> H
    H --> I{试点稳定并达成目标吗}
    I -- 否 --> J[回滚或缩小范围继续优化]
    I -- 是 --> K[分批迁移到更多集群]

flowchart TD
    A[开始评估 Cilium 迁移] --> B{内核/镜像基线满足吗}
    B -- 否 --> C[先升级节点基线]
    B -- 是 --> D{标签体系可支撑 Identity 吗}
    D -- 否 --> E[先治理 Labels 规范]
    D -- 是 --> F{运维团队具备 Hubble/BPF 排障能力吗}
    F -- 否 --> G[先做培训与演练]
    F -- 是 --> H[选择一个业务域做试点]
    C --> H
    E --> H
    G --> H
    H --> I{试点稳定并达成目标吗}
    I -- 否 --> J[回滚或缩小范围继续优化]
    I -- 是 --> K[分批迁移到更多集群]

结语：Cilium 真正改变的，不只是性能，而是云原生网络的组织方式

为什么越来越多团队在 2026 年迁移到 Cilium？

更准确的回答并不是“因为它更快”，虽然它通常确实更快。更深层的原因是，它把过去散落在 kube-proxy、iptables、策略系统、抓包系统、多集群互联和安全组件里的复杂性，往一个统一的数据平面重新收拢了。

这就是 Cilium 带来的真正改变：

它不是单独优化了 Kubernetes 网络里的某一个环节，而是让网络、安全、观测和跨集群能力开始共享同一套底层逻辑。

对很多平台团队来说，这种“统一”本身，往往比一张 benchmark 图更有价值。

如果要用一句话概括 2026 年 Cilium 的意义，那大概是：

它让 Kubernetes 网络从一套越来越难维护的拼装系统，逐步变成了一个可编程、可观测、可治理的基础设施底座。