Shengxu · Cloud Architecture & Devops
Shengxu · Cloud Architecture & Devops

Cilium 2026（续）：统一数据平面正在怎样改变 Kubernetes 的平台结构

Shengxu included in Kubernetes  DevOps  Observability  Security  AI
 About 1900 words 9 minutes 

在上一篇关于 Cilium 的文章中，我们探讨了 2026 年迁移潮背后的真实原因：它不再仅仅是“一个更快的 CNI”，而是将 Kubernetes 网络、安全、可观测与多集群能力，重新组织成了一套更统一的基础设施底座，并理清了它与 Istio 的分工协作边界。

如果说上一篇回答了“Cilium 到底能为我们带来什么”，那么这一篇我们将更进一步，聚焦于它的演进核心：统一数据平面（Unified Dataplane）。

本文将具体展开，Cilium 究竟是在如何改变平台系统的分层方式，重写那些原本由不同独立组件（如 iptables、Mesh Sidecar、独立监控 Agent 等）分别承担的能力边界，并通过多集群（ClusterMesh）和无 Sidecar 架构的实际案例，探讨其对生产环境的深远影响。

一、统一数据平面的重新成立

过去的 Kubernetes 平台通常由一组松耦合系统拼起来：

  • CNI 负责 Pod 网络接入
  • kube-proxy 负责 Service 转发
  • iptables 或 IPVS 负责部分流量规则
  • Service Mesh 负责 mTLS、L7 路由与服务治理
  • 流量观测依赖独立 agent、代理或 sidecar
  • 运行时安全再由另一类内核事件系统承担

这套结构并非不可用，但它天然意味着层次叠加、控制面分裂和数据路径拉长。每增加一层，都会带来额外 hop、更多资源开销、更复杂的故障面和更模糊的职责边界。

Cilium 的方向则不同。它并不是再加一层，而是尽可能把更多能力下压到统一的数据平面中：L3/L4 转发和负载均衡优先在 eBPF datapath 中完成，策略围绕 identity 而不是静态网络位置定义，观测尽量直接从流量路径获得，运行时安全则与网络语义共享上下文，而不是共享同一条转发路径。

flowchart TB
    A[Workloads / Services] --> B[Cilium eBPF Dataplane]

    B --> C[Pod Networking]
    B --> D[Service Load Balancing]
    B --> E[Identity-based Policy]
    B --> F[Multi-Cluster Connectivity]
    B --> G[Observability]
    B --> H[Runtime Security]
    B --> I[Service Mesh Capability]

    G --> G1[Hubble]
    H --> H1[Tetragon]
    F --> F1[ClusterMesh]
flowchart TB
    A[Workloads / Services] --> B[Cilium eBPF Dataplane]

    B --> C[Pod Networking]
    B --> D[Service Load Balancing]
    B --> E[Identity-based Policy]
    B --> F[Multi-Cluster Connectivity]
    B --> G[Observability]
    B --> H[Runtime Security]
    B --> I[Service Mesh Capability]

    G --> G1[Hubble]
    H --> H1[Tetragon]
    F --> F1[ClusterMesh]
flowchart TB
    A[Workloads / Services] --> B[Cilium eBPF Dataplane]

    B --> C[Pod Networking]
    B --> D[Service Load Balancing]
    B --> E[Identity-based Policy]
    B --> F[Multi-Cluster Connectivity]
    B --> G[Observability]
    B --> H[Runtime Security]
    B --> I[Service Mesh Capability]

    G --> G1[Hubble]
    H --> H1[Tetragon]
    F --> F1[ClusterMesh]

这张图表达的重点，不是 Cilium “功能覆盖更广”，而是这些能力开始共享同一套平台语义。平台团队不再只是管理网络组件，而是在管理一层同时影响路径、身份、策略、可见性和运行时行为的基础设施平面。

二、多集群能力正在从附加能力变成主问题

在多集群场景中，围绕 Cilium 的讨论重心更容易落到 ClusterMesh 上。

ClusterMesh 的基本思路，是把多集群更倾向于建模为网络与身份平面的延展，而不是主要围绕代理与入口层拼装能力。多个集群运行 Cilium 之后，服务、端点和身份可以在集群间建立同步与关联，跨集群通信尽量保持原生网络语义，而不是默认经过多层 gateway 与代理链。

这与传统多集群 Service Mesh 方案形成了稳定对照。后者通常通过 east-west gateway、service mirror、mTLS tunnel 和代理链路去桥接不同集群，更强调 L7 服务治理和代理控制面；ClusterMesh 则更像一张扩展到多集群范围的 L3/L4 网络与身份平面。

flowchart LR
    subgraph S1["ClusterMesh"]
        A1[Pod A] --> A2[eBPF Datapath]
        A2 --> B2[eBPF Datapath]
        B2 --> B1[Pod B]
    end

    subgraph S2["Traditional Multi-Cluster Mesh"]
        C1[Pod A] --> C2[Proxy / Tunnel]
        C2 --> C3[East-West Gateway]
        C3 --> D3[East-West Gateway]
        D3 --> D2[Proxy / Tunnel]
        D2 --> D1[Pod B]
    end

    S1 ~~~ S2
flowchart LR
    subgraph S1["ClusterMesh"]
        A1[Pod A] --> A2[eBPF Datapath]
        A2 --> B2[eBPF Datapath]
        B2 --> B1[Pod B]
    end

    subgraph S2["Traditional Multi-Cluster Mesh"]
        C1[Pod A] --> C2[Proxy / Tunnel]
        C2 --> C3[East-West Gateway]
        C3 --> D3[East-West Gateway]
        D3 --> D2[Proxy / Tunnel]
        D2 --> D1[Pod B]
    end

    S1 ~~~ S2
flowchart LR
    subgraph S1["ClusterMesh"]
        A1[Pod A] --> A2[eBPF Datapath]
        A2 --> B2[eBPF Datapath]
        B2 --> B1[Pod B]
    end

    subgraph S2["Traditional Multi-Cluster Mesh"]
        C1[Pod A] --> C2[Proxy / Tunnel]
        C2 --> C3[East-West Gateway]
        C3 --> D3[East-West Gateway]
        D3 --> D2[Proxy / Tunnel]
        D2 --> D1[Pod B]
    end

    S1 ~~~ S2

这种差异并不只是实现风格不同，而是复杂度位置不同。传统多集群 mesh 把复杂度集中在 gateway、代理和 L7 控制面；ClusterMesh 则把复杂度集中在 CIDR 规划、路由、加密、身份同步和底层网络设计。

因此，多集群不是一个“网络通了就结束”的问题。真正的难点在于，平台是否愿意把跨集群通信重新建模为一张统一的网络与身份平面。如果答案是肯定的，ClusterMesh 的价值才会真正成立。

三、Cilium 1.19 在 2026 年的意义

到 2026 年 3 月，Cilium 1.19 更适合被理解为当前主线版本所释放出的平台化信号。

1.19 的关键词包括：Network Policy 增强、Multi Pool IPAM 稳定版、IPv6 深度支持，以及与透明加密、ztunnel 兼容性、多集群升级注意事项等相关的变化。换句话说，这是一个把网络策略、IPAM、IPv6 与运维可控性同时往前推进的版本。

从平台视角看，1.19 的价值在于它进一步强化了这样一种趋势：Cilium 不再只是单集群里的数据路径优化器，而是在向更完整的平台运行层迈进。多集群服务安装、更保守的策略语义、升级指引、IPv6 能力推进和更稳定的 IPAM，都在说明它正在从“能用”转向“适合长期运行”。

四、平台现实：当 Cilium 成为托管平台的“默认基石”

在 2026 年讨论 Cilium，如果只看开源社区和技术路线，很容易高估实验性，低估平台现实。值得注意的事实是，它已经进入托管 Kubernetes 平台的底层设计。

OVHcloud 的案例具有代表性。在 OVHcloud MKS Standard 计划中，Cilium 已经是默认 CNI，并且这一体系运行在 20 个公有云区域、数千个生产集群和数万节点的规模上。

企业用户面对 Cilium 时，不再总是“是否采用”的问题，而更可能是“底层已经是 Cilium，我该如何围绕它设计策略、隔离、观测和升级模型”。Cilium 在这里不再只是高级选项，而开始成为平台假设的一部分。

五、Sidecarless Service Mesh 的边界

2026 年 Service Mesh 正在重新审视 per-pod sidecar 的成本，而 Cilium 与 Istio Ambient 代表了两条不同路线。

1. Cilium 的 sidecarless 结构

Cilium 的 sidecarless 并不意味着所有能力都在内核里完成。更准确的描述是：

  • L3/L4 转发、基础策略和可见性优先由 eBPF datapath 完成
  • 一旦进入 HTTP 头处理、L7 策略、gRPC 负载均衡或 TLS 终止场景，流量会被引导到每节点共享的 Envoy（利用 Envoy Go 扩展或 eBPF 注入）
  • 换言之，Sidecarless 的本质是消除“每个 Pod 强制注入 Sidecar”的架构冗余，而非彻底摒弃代理机制。
flowchart LR
    A[App A] --> B[eBPF datapath]
    B --> C{L7 policy / advanced traffic logic?}
    C -- No --> D[eBPF forwarding]
    C -- Yes --> E[Per-node shared Envoy]
    D --> F[eBPF datapath]
    E --> F
    F --> G[App B]
flowchart LR
    A[App A] --> B[eBPF datapath]
    B --> C{L7 policy / advanced traffic logic?}
    C -- No --> D[eBPF forwarding]
    C -- Yes --> E[Per-node shared Envoy]
    D --> F[eBPF datapath]
    E --> F
    F --> G[App B]
flowchart LR
    A[App A] --> B[eBPF datapath]
    B --> C{L7 policy / advanced traffic logic?}
    C -- No --> D[eBPF forwarding]
    C -- Yes --> E[Per-node shared Envoy]
    D --> F[eBPF datapath]
    E --> F
    F --> G[App B]

2. Ambient 的结构

Istio Ambient 的 ztunnel 是 per-node proxy，与 istio-cni 协同工作，在节点侧承接 mTLS、认证、L4 授权和遥测，而不会默认去解析工作负载的 HTTP 头。更完整的 L7 能力仍然落在 Waypoint 代理上。两者都在远离传统 sidecar 模式，但并没有走向同一套结构：

flowchart LR
    A[App A] --> B["ztunnel
(Per-node L4 / mTLS)"]
    B --> C{"Require L7
Processing?"}
    C -- No --> D["ztunnel
(Remote L4 / mTLS)"]
    C -- Yes --> E["Waypoint Proxy
(L7 Logic)"]
    E --> D
    D --> F[App B]
flowchart LR
    A[App A] --> B["ztunnel
(Per-node L4 / mTLS)"]
    B --> C{"Require L7
Processing?"}
    C -- No --> D["ztunnel
(Remote L4 / mTLS)"]
    C -- Yes --> E["Waypoint Proxy
(L7 Logic)"]
    E --> D
    D --> F[App B]
flowchart LR
    A[App A] --> B["ztunnel
(Per-node L4 / mTLS)"]
    B --> C{"Require L7
Processing?"}
    C -- No --> D["ztunnel
(Remote L4 / mTLS)"]
    C -- Yes --> E["Waypoint Proxy
(L7 Logic)"]
    E --> D
    D --> F[App B]
  • Cilium 更强调在统一数据平面里优先完成更多 L3/L4 逻辑，再用 shared proxy 处理必要的 L7
  • Ambient 更强调保留 Istio 的治理模型，同时把 proxy 从 per-pod 收敛到节点层（ztunnel）和服务的逻辑层（waypoint）

六、统一技术栈，不等于同一条转发路径

谈 Hubble 与 Tetragon 时，需要区分“统一上下文”与“同一条 datapath”。两者虽然都依赖底层的 eBPF 技术，但利用的是截然不同的内核 hook 点与事件模型。这就好比一个是路口的监控探头，另一个是装在房间里的行为记录仪：

  • Hubble（聚焦网络与流量维度）：它的探针主要挂载在网络栈（如 XDP 或 TC 层）上。它的核心视角是为你展现**“网络数据平面上正在发生什么”**：是谁（哪个 Identity）连了谁？流量是被 NetworkPolicy 阻断了还是放行了？业务侧 L3/L4 甚至 L7（如 HTTP 或 DNS）的延迟与微服务依赖拓扑是怎样的？

  • Tetragon（聚焦操作系统运行时行为）：它挂载在内核更深处的系统调用（syscall）、kprobes 和 tracepoints 上。当一个网络连接建立前，Tetragon 就能看到：“产生这个网络行为背后的执行动机是什么”。比如：是容器里的哪一个具名进程发起了对外请求？在发起请求前，这个进程有没有异常读取过 /etc/shadow 这类敏感文件？有没有发生可疑的权限提升（如 sudo/setuid）或违规的底层 Shell 派生？

当这两者在同一个技术栈里跑起来时，它们的威力在于上下文的完美闭合。比如：当监控到一次疑似恶意的网络外联，你立刻能通过 Hubble 在流量层切断它，同时通过 Tetragon 一秒追溯到发起这次连接的是哪个具体进程（PID）、以及它在执行了哪条越权命令后产生了这次外联，进而直接 Kill 掉该源头进程。

这种跨越了“网络空间”与“操作系统运行时”的联合感知，使得零信任不再仅仅是一份只能拦截 IP 的静态 Allow-list（白名单），而开始真正演变成一个可运行、可验证、并且能够做到从源头自动收敛阻断闭环的动态防御体系。

Cilium 与 Istio 的防线互补：特工与外交官

在建立起了这套底层的统一感知后，很多人会自然地拿 Cilium 去对标 Istio。两者在 L7 可观测性和 mTLS 加密上确实存在重合，但底层逻辑、防御深度与职责边界却有本质的不同。

打个比方：如果把 Istio 比作精细运作的**“外交官”（专注于微服务间重试、熔断、Header 路由等复杂的应用层协议治理**），那么 Cilium 体系（连同 Hubble + Tetragon）就更像是掌控底层的**“全能特工”**（它不仅监控基础设施边缘的全部物理和网络流量，还实时追踪着操作系统房间内每一个进程的敏感动作）。

Istio 的视角是“以应用为中心”的，它只能看到“经过了 Envoy 代理”的业务调用；而 Cilium 的视角是“以网络和内核平面为中心”的，它不仅掌控连通性，更填补了从“网络行为”追溯到“系统内部行为”的安全鸿沟。

注：关于两者的核心差异（如观测视角深度、Tetragon 独门的安全拦截能力、以及微服务流量治理的细粒度等），由于涉及不同架构的互补设计，此处不再展开，我们将在下一篇文章中单独详细剖析。

七、生产环境重点：平面退化

进入生产环境后，Cilium 最常见的问题是“平面在退化，但对象还活着”。这类退化往往表现在 BPF map 使用率上升、conntrack 压力增大或 identity 产生异常 deny。

因此，监控方式应采用三层结构：

flowchart LR
    A["ClusterMesh / Mesh
Production Monitoring"] --> B[Control Plane]
    A --> C[Dataplane]
    A --> D[End-to-End Experience]

    B --> B1[Remote cluster status]
    B --> B2[Global services]
    B --> B3[Endpoint / identity sync]

    C --> C1[Drop reasons]
    C --> C2[Conntrack]
    C --> C3[BPF map pressure]
    C --> C4[Agent / proxy resource]

    D --> D1[p95 / p99 latency]
    D --> D2[DNS errors]
    D --> D3[HTTP error rate]
    D --> D4[Path quality / RTT]
flowchart LR
    A["ClusterMesh / Mesh
Production Monitoring"] --> B[Control Plane]
    A --> C[Dataplane]
    A --> D[End-to-End Experience]

    B --> B1[Remote cluster status]
    B --> B2[Global services]
    B --> B3[Endpoint / identity sync]

    C --> C1[Drop reasons]
    C --> C2[Conntrack]
    C --> C3[BPF map pressure]
    C --> C4[Agent / proxy resource]

    D --> D1[p95 / p99 latency]
    D --> D2[DNS errors]
    D --> D3[HTTP error rate]
    D --> D4[Path quality / RTT]
flowchart LR
    A["ClusterMesh / Mesh
Production Monitoring"] --> B[Control Plane]
    A --> C[Dataplane]
    A --> D[End-to-End Experience]

    B --> B1[Remote cluster status]
    B --> B2[Global services]
    B --> B3[Endpoint / identity sync]

    C --> C1[Drop reasons]
    C --> C2[Conntrack]
    C --> C3[BPF map pressure]
    C --> C4[Agent / proxy resource]

    D --> D1[p95 / p99 latency]
    D --> D2[DNS errors]
    D --> D3[HTTP error rate]
    D --> D4[Path quality / RTT]

以上三层监控覆盖了从集群宏观状态到微观网络连通性的完整链路：

  • 控制面（Control Plane）：主要盯防同步机制的稳定性。核心指标包括远程集群（Remote cluster）状态、全局服务（Global services）的健康度，以及 Endpoint 与 Identity 信息的同步质量。
  • 数据面（Dataplane）：深入底层网络引擎的使用限度。必须关注具体的丢包原因分布（Drop reasons）、连接跟踪表（Conntrack）容量、各类 eBPF Map 的压力，以及 Agent 的资源开销。
  • 端到端体验（End-to-End Experience）：从业务最终感受倒推网络质量。主要依赖 p95/p99 尾部延迟、DNS 错误率、HTTP 协议层错误率，以及底层的 RTT 链路质量。

告警规则应围绕动态基线

固定阈值（如“丢包数大于 100 就报警”）在多集群或 Service Mesh 场景下往往缺乏实际意义。因为在这种动态环境中，微服务的 HPA 自动扩缩容十分频繁，流量在集群间发生调度切换也是常态。单纯因为业务晚高峰带来的整体流量膨胀，就会轻易触发固定阈值的误报，最终只会被团队屏蔽，导致“狼来了效应”（报警疲劳）。

更合理的告警应当围绕“状态突变”与“历史偏离度”来定义：

  • 关注比率而非绝对值：与其报警“出现了 50 个网络拒绝请求”，不如报警“网络丢包率（Drop Rate）或策略拒绝率较上一个周期跃升了 5%”。
  • 基于动态基线的突变检测：利用 Prometheus 的 predict_linear 函数，或通过历史时间的移动平均线设定波动带。只有当当前的连接调度延迟（Latency）、BPF Map 压力或并发数发生大幅度脱离常态基线的偏离时，才触发真实验证。

换句话说，在统一数据平面的监控体系里，告警关注的重点不再是“数值有没有超限”，而是“系统的行为曲线是否脱离了健康常态”。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

groups:
- name: cilium-datapath-alerts
  rules:
  - alert: CiliumDropRateAnomaly
    expr: rate(cilium_drop_count_total[5m]) > 10
    for: 5m
    labels:
      severity: warning
    annotations:
      note: "占位阈值；建议替换为基于环境基线的动态异常检测（如 predict_linear）。"

  - alert: ClusterMeshConnectionDown
    expr: cilium_clustermesh_remote_cluster_status == 0
    for: 5m
    labels:
      severity: critical

  - alert: HubbleRequestLatencyP99High
    expr: |
      histogram_quantile(
        0.99,
        sum by (le, source_workload, destination_workload) (
          rate(http_request_duration_seconds_bucket[5m])
        )
      ) > 0.2
    for: 10m
    labels:
      severity: warning
    annotations:
      note: "依赖 Hubble metrics 的 labelsContext 配置以暴露工作负载标签。"

八、调优：建立容量模型

Cilium 的生产调优取决于对流量形态、连接规模和网络条件的理解。下面是一段针对多集群生产环境的配置示例：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38

cluster:
  name: prod-ap-southeast-1
  id: 1

kubeProxyReplacement: true
routingMode: native
autoDirectNodeRoutes: true

ipv6:
  enabled: true

bpf:
  mapDynamicSizeRatio: 0.0025
  ctGlobalTCPMax: 1048576
  ctGlobalAnyMax: 524288
  lbMapMax: 65536
  policyMapMax: 65536

socketLB:
  enabled: true
  hostNamespaceOnly: true # 避免在 Socket 层直接短路负载均衡以保证与代理体系的兼容性

encryption:
  wireguard:
    enabled: true

hubble:
  enabled: true
  relay:
    enabled: true
  metrics:
    enabled:
      - dns
      - drop
      - tcp
      - flow
      - icmp
      - httpV2:labelsContext=source_namespace,source_workload,destination_namespace,destination_workload

这段配置背后的核心调优逻辑在于：

  1. 彻底替换 kube-proxy 与避免封包（Native Routing）：kubeProxyReplacement: true 结合 routingMode: native 意味着我们完全剥离了基于 iptables 的转发链，并将网络路由直接交由底层的 VPC 网络承载。这避免了封包解包（如 VXLAN）的开销，是发挥 eBPF 性能优势的基础前提。
  2. eBPF 容量防爆（Capacity Planning）：如果在高并发或多集群环境下遇到神秘的“偶发丢包”，罪魁祸首往往是 BPF Map 满了。这里我们把 ctGlobalTCPMax（连接跟踪表最大容量）顶到了 100 多万，并配合 mapDynamicSizeRatio 根据节点物理内存动态伸缩，防止大规模流量引发的平面退化。
  3. SocketLB 与 Service Mesh 的兼容折中：socketLB 能够在 Socket 层对同节点的流量直接短路加速。但加上 hostNamespaceOnly: true 后，它会刻意“放过”普通 Pod 间的流量加速。这主要是为了防止底层网络层面的过早短路导致流量“绕过”了上层 Istio Sidecar 或 ztunnel 的流量劫持点，以此换取两套体系的兼容性。
  4. 高信噪比的可观测性（Hubble Metrics）：提取 HTTP 指标时加入了 labelsContext=...。在多集群的零信任环境中，只看 IP 是毫无意义的。该参数让 Hubble 强制按 source 和 destination 的真实业务名称进行聚合，这是你配置“动态基线告警”所必须依赖的基石数据。

成本模型：内核常驻内存的“隐形账本”

很多人只看见消除大量 Sidecar 为业务层暴降的内存开销（比如一台跑了 100 个 Pod 的节点能省下 2GB），却往往忽略了这本由 eBPF Map 记下的“隐形账本”：它在内核空间中占用的是纯粹的物理常驻内存（Locked Memory）。每一个底层 TCP 连接如果都消耗 64 到 128 字节，那么 100 万上限的全局连接跟踪表就会吃掉上百 MB 的内核内存。但在数万个身份和海量流量的超大规模网格计算中，这实际上实现了把内存消耗率从“随着 Pod 数量的线性激增”逆转为了“随全局连接池与策略规模的平缓长尾增长”——这是一笔回报丰厚的投资，但需要利用精确的模型对真实容量与物理成本时刻保持理性掌控。

九、零信任与跨云：能力边界

最后，在将 Cilium 推向大规模甚至跨云应用时，我们需要客观明确两个关键的“能力边界”：

1. 跨云场景：软件可以减少 hop，但无法战胜物理学

在多云互通时，Cilium 的 ClusterMesh 能够省去传统跨云代理网关的多次周转（减少额外 hop），让跨云网络更像“局域网层直连”。但它并不能当做治疗“糟糕的云间专线”或“跨海高延迟”的魔法。物理距离和公网链路抖动带来的限制依然存在，架构师依然需要把那些对延迟极度敏感的微服务内聚在同一个地域。

2. 零信任落地：用“业务身份（Identity）”取代“IP 地址（网络位置）”

在传统安全运维里，很多团队习惯基于 IP 地址段开防火墙白名单。但 Kubernetes 的痛点在于：Pod 的 IP 是时刻在变的（扩缩容、重启、节点漂移）。如果我们还在试图记忆和控制海量且时刻移动的 IP，安全规则会很快变成一笔理不清的烂帐。

因此，Cilium 零信任设计的核心“实际意义”就在于：把安全的执行依据，从“不稳定的 IP 地址”切换到了“明确的业务标签身份（Identity）”：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17

apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: frontend-to-backend
spec:
  endpointSelector:
    matchLabels:
      app: backend     # 目标是谁：集群里所有打了 backend 标签的 Pod
  ingress:
  - fromEndpoints:
    - matchLabels:
        app: frontend  # 允许谁来连（条件1）：拥有 frontend 标签
        env: prod      # 允许谁来连（条件2）：并且环境声明也是 prod
    toPorts:
    - ports:
      - port: "8080"
        protocol: TCP

这段 YAML 配置在生产环境里的“实际意义”是什么？ 无论这两个服务今天在哪个新扩容出来的节点、分配了什么乱七八糟的 IP，或者明天因为容灾切换被调度到了另一个远程集群，这套安全规则永远生效，且完全不用修改网络配置。

只要发起连接的那个容器，不具备 app=frontend 且 env=prod 的精确平台标签，就算它碰巧与曾经的合法应用共用了一个 IP 网段（例如 IP 回收复用），甚至就算黑客在集群某台机器上伪造了源 IP，它的 TCP 连接请求也会在最底层的内核网卡级（eBPF 层）被瞬间掐断。

这就是在云原生时代“零信任”该有的面貌：我不信任你的 IP 位置，我只认平台强制验证分配给你的通信身份。

十、降级与兜底：当 eBPF 触碰物理极限

不过，我们必须承认 eBPF 并非万能。当老旧内核能力不足或策略复杂度导致 BPF 指令数超过内核校验器限制（Verifier Limit）时，平台需要有一套清晰的“优雅降级”逻辑：应当剥离出“核心连通性”（必须通过 CNI 兜底保证）和“高级附加侦听”（允许在异常时保持静默审计）。为了应对指令溢出，很多复杂的 L7 逻辑正在通过内核级别的 Tail Calls 解耦成小段调用；若依然失败，系统会聪明地切断非关键流量侧的遥测染色，以此在绝境中优先死保数据面的基础转发带宽不死。

十一、AI 浪潮下的基础设施：从 CNI 到高性能数据通道

2026 年是 AI 训练集群算力全面爆发的一年。当计算任务的核心从 CPU 向 GPU 不断倾斜，传统的 TCP/IP 协议栈彻底成为性能瓶颈。在这个极速场景里，Cilium 的使命再次发生了质变：

  • 对 RDMA 与 RoCE v2 的原生透传：在超大规模 AI 模型训练时，GPU 节点间必须通过 RDMA 进行极低延迟的大数据交互，这就意味着绝对不容许 eBPF 中途拦截。Cilium 通过 Device Pass-through 与 SR-IOV 技术的深度组合，达到了“仅在控制面进行身份验证感知，在底层数据面实现完全硬件旁路透传”的非侵入式架构。
  • 为大模型而生的精细化 NetQoS：面对 AI All-reduce 通信环节极易产生的瞬时洪峰，Cilium 利用下沉至底层网卡的 EDT（Earliest Departure Time）机制对流量做极精确的优先级排列和调度限速。它能确保极其关键的训练大流量绝对不被底层节点上那些微不足道的辅助进程挤占而产生任何不确定的网损抖动。

在这类极速计算底座里，“平时不干预，出事能阻断”的高效旁路协同架构正在构筑起全套 AI 服务层的基石。

结语

当我们将这份讨论，从单点的“跑分性能优劣”，一步步引向“海量资源开销的精算”、“极致的架构物理退化边界”乃至“向顶级 AI GPU 集群冲锋的数据直通道”时，你会发现 2026 的 Cilium：已经从过去一个用于连通性设计的网络组件，硬核地升格为了一个更加可预知、可彻底量化并全盘抽象整个网络数据面和 OS 运行内核的云时代操作系统底层核心。

如果要准备拥抱这样的一套庞大基建，首要任务已绝不仅仅是把安装文档或简单的排错跑通那么浮于表面。如何结合那些深度的监测预估算与退级模型规划，建立起一套真正能吃透系统深水区的现代平台工程思想，才是打赢这场底层架构大迁徙的唯一决胜之钥！

Updated on 2026-03-21 
CC BY-NC-SA 4.0
CiliumEBPFKubernetesService MeshClusterMesh
Back | Home

Contents