Kubernetes 网络的未来：趋势、挑战与架构师指南

本系列用二十九篇文章拆解了 Kubernetes 网络的每一个核心组件： 从Linux 内核网络栈到 eBPF 可编程数据面， 从CNI 规范到 跨云多集群互联。

站在 2026 年这个节点回望，Kubernetes 网络正处于一次范式级别的跃迁窗口。 iptables 链表即将退出历史舞台，eBPF 成为内核数据面的默认语言； NetworkPolicy 从「可选插件」变成「安全基线」； Gateway API 正在统一南北向与东西向流量模型； 而 AI 大模型训练集群的爆发式增长，更是对网络带宽、延迟和拓扑提出了前所未有的要求。

本文将从四大趋势出发，提供一份面向架构师的决策清单，并以一张知识图谱作为本系列的收尾。

一、趋势一：内核化 – iptables 到 eBPF 的不可逆迁移

1.1 iptables 的终局

iptables 自 Linux 2.4 时代服务至今已超过二十年。 在 Kubernetes 场景下，kube-proxy 通过 iptables 实现 Service 的 ClusterIP 负载均衡。 然而，其线性规则匹配的 O(n) 复杂度在大规模集群中已成为不可忽视的瓶颈。 我们在第九篇中详细分析过： 当 Service 数量超过 5000 时，iptables 规则链轻松突破十万条， 每次规则更新的全量替换导致数秒级的 CPU 尖峰。

# 查看当前 iptables 规则数量
iptables-save | wc -l
# 在大集群上，这个数字可能超过 100,000

内核社区已经明确了方向：

1.2 nftables：过渡方案还是长期选择？

nftables 相比 iptables 有三个结构性优势： 集合匹配（nft set 将规则匹配从 O(n) 降到 O(1)）； 原子替换（nft -f 支持事务性批量替换）； 统一框架（一套框架覆盖 IPv4/IPv6/ARP/bridge）。

# kube-proxy nftables 后端启用
# kube-proxy 配置
apiVersion: kubeproxy.config.k8s.io/v1alpha1
kind: KubeProxyConfiguration
mode: "nftables"

Kubernetes v1.29 开始，kube-proxy 正式支持 nftables 后端（alpha），v1.31 升级为 beta。 对于无法立即迁移到 Cilium eBPF 数据面的团队，nftables 是一个务实的过渡方案。

但需要注意：nftables 仍然是 netfilter 子系统的一部分， 数据路径仍要经过 PREROUTING/FORWARD/POSTROUTING 等 hook 点。 在第二十一篇中我们对比过， eBPF 可以在 TC 或 XDP 层直接短路转发，跳过整个 netfilter 栈，这是 nftables 无法做到的。

1.3 eBPF 数据面：可编程的未来

eBPF 的崛起彻底改变了内核网络编程的范式。 不再需要编写内核模块、不再需要重启内核，一段经过验证器校验的 BPF 字节码就可以挂载到任意 hook 点。 在第六篇和 第二十九篇中已有详细讨论。这里聚焦未来方向：

方向一：XDP 卸载到硬件

NIC Hardware --> XDP offload --> 直接转发 (延迟 < 1us，无需进入内核协议栈)

Netronome/Agilio 等智能网卡已支持 XDP offload， 将 BPF 程序直接运行在网卡固件上，Pod-to-Pod 转发可以完全绕过主机 CPU。

方向二：BPF Arena 与用户态协作

Linux 6.9 引入的 bpf_arena 机制允许 BPF 程序与用户态共享内存映射， 内核态数据面与用户态控制面之间的通信开销降到最低，实现零拷贝数据交换。

方向三：kube-proxy 的终结

Cilium 已经证明了完全替代 kube-proxy 的可行性。 社区正在讨论将 eBPF Service 实现纳入 Kubernetes 核心， 未来发行版可能原生内置 eBPF 数据面，kube-proxy 将成为可选的向后兼容组件。

# Cilium Helm 配置：替代 kube-proxy
kubeProxyReplacement: "true"
k8sServiceHost: "api-server.example.com"
k8sServicePort: "6443"

1.4 可编程数据面的新可能

当数据面变得可编程，网络功能的边界也随之扩展： L7 策略在内核执行（Cilium Envoy-less L7 policy 在 eBPF 中解析 HTTP header，无需 sidecar）； 自定义负载均衡（BPF struct_ops 自定义 TCP 拥塞控制和连接调度）； 实时遥测（BPF ringbuf 实现每包级别的流量指标采集，延迟仅数十纳秒）； 安全审计（LSM BPF hook 实现运行时安全策略，替代 seccomp/AppArmor 静态配置）。

二、趋势二：安全性前置 – 从可选到必选

2.1 NetworkPolicy：从可选变必选

在 Kubernetes 的早期，NetworkPolicy 是一个经常被忽略的 API。 很多团队在生产环境中运行了多年，Pod 之间完全没有任何网络隔离。 这种「默认全通」的模型在安全审计中越来越站不住脚。 2024 年以来，主流合规框架（CIS Benchmark、NIST 800-190、PCI-DSS v4） 都将 NetworkPolicy 列为必选安全控制。 每个 Namespace 必须有一条 default-deny 策略：

# 入站默认拒绝
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-ingress
  namespace: production
spec:
  podSelector: {}
  policyTypes:
  - Ingress

---
# 出站默认拒绝
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-egress
  namespace: production
spec:
  podSelector: {}
  policyTypes:
  - Egress

2.2 AdminNetworkPolicy：集群级策略

标准 NetworkPolicy 有一个设计缺陷：它是 namespace-scoped 的， 集群管理员无法定义跨 namespace 的全局策略。KEP-2091 引入了 AdminNetworkPolicy (ANP)：

apiVersion: policy.networking.k8s.io/v1alpha1
kind: AdminNetworkPolicy
metadata:
  name: cluster-deny-metadata
spec:
  priority: 10
  subject:
    namespaces:
      matchLabels:
        kubernetes.io/metadata.name: "*"
  egress:
  - name: deny-metadata-service
    action: Deny
    to:
    - networks:
      - 169.254.169.254/32
    ports:
    - portNumber:
        port: 80
        protocol: TCP

ANP 在标准 NetworkPolicy 之前评估，且无法被租户覆盖， 让集群管理员可以强制执行安全基线，例如： 阻止所有 Pod 访问云元数据服务（169.254.169.254）、 强制跨 namespace 通信走 mTLS、禁止特定 namespace 的出站互联网访问。

2.3 身份感知安全替代 IP-based

传统 NetworkPolicy 基于 IP 地址和端口进行过滤。 但在 Kubernetes 中，Pod IP 是临时的、动态分配的， 一个 IP 在前一秒属于 Pod A，下一秒可能被分配给 Pod B。 基于 IP 的策略本质上是不精确的。

Cilium 在第二十篇中 引入了身份感知安全模型：

Pod Label --> Cilium Identity (数字 ID) --> BPF Map 查找 --> 策略执行

这种模型的优势在于：策略与 IP 解耦，Pod 重建后 Label 不变，策略自动生效； Identity 在 BPF Map 中预计算，零延迟生效； ClusterMesh 同步 Identity，多集群策略无需维护 IP 白名单。

2.4 零信任 Kubernetes 网络落地

零信任（Zero Trust）不是一个产品，而是一个架构原则： 永不信任，始终验证。在 Kubernetes 网络中，这意味着：

# Cilium mTLS 自动化配置
apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: require-mtls
  namespace: production
spec:
  endpointSelector: {}
  ingress:
  - fromEndpoints:
    - matchLabels: {}
    authentication:
      mode: "required"

在第二十二篇中， 我们对比了 WireGuard、IPsec 和 mTLS 三种加密方案。 零信任场景下推荐 mTLS，因为它同时提供了身份验证和加密两个能力。

2.5 供应链安全与 SBOM

安全性前置不仅是运行时策略，还包括供应链安全。 2024 年以来，CNCF 要求所有毕业项目提供 SBOM（Software Bill of Materials）， CNI 插件也不例外。

架构师需要关注的供应链安全检查点： CNI 二进制完整性校验、镜像签名验证（cosign / Notary）、 eBPF 程序来源审计、依赖库 CVE 扫描（Trivy / Grype）、运行时行为监控。 确保 /opt/cni/bin/ 下的二进制文件经过签名验证， Cilium 加载的 BPF 程序应可追溯到源码 commit。

三、趋势三：从南北向到多云化

3.1 Gateway API 统一南北向

Ingress API 已服务六年，但扩展性问题日益突出： Annotation 泛滥、缺乏角色分离、不支持 TCP/UDP/gRPC 路由。 第十八篇详细介绍了 Gateway API 的设计理念。 2024 年 Gateway API v1.0 GA，HTTPRoute 进入稳定通道，生态系统快速跟进：

# Gateway API 角色分离模型
# 1. 基础设施管理员：定义 GatewayClass
apiVersion: gateway.networking.k8s.io/v1
kind: GatewayClass
metadata:
  name: cilium
spec:
  controllerName: io.cilium/gateway-controller

---
# 2. 集群管理员：定义 Gateway
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: production-gw
  namespace: infra
spec:
  gatewayClassName: cilium
  listeners:
  - name: https
    port: 443
    protocol: HTTPS
    tls:
      mode: Terminate
      certificateRefs:
      - name: prod-cert

---
# 3. 应用开发者：定义 HTTPRoute
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: my-app
  namespace: app-team
spec:
  parentRefs:
  - name: production-gw
    namespace: infra
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /api/v2
    backendRefs:
    - name: api-v2
      port: 8080
      weight: 90
    - name: api-v3
      port: 8080
      weight: 10

Gateway API 的关键演进方向：

3.2 ClusterMesh 与 MCS API 统一东西向

当组织的 Kubernetes 基础设施从单集群扩展到多集群， 东西向（Pod-to-Pod 跨集群）通信成为新挑战。 第二十七篇和第二十八篇已有讨论。 目前社区有两条路径正在收敛：

路径一：CNI 原生方案 – ClusterMesh

Cilium ClusterMesh 通过共享 kvstore（etcd）同步 Service 和 Identity：

Cluster A                     Cluster B
 Pod --> Cilium Agent          Cilium Agent <-- Pod
          |                        |
          +-- kvstore (共享) ------+
          |                        |
     WireGuard Tunnel 加密互联

优势在于无需额外控制面组件，Identity-based 策略天然跨集群生效。

路径二：K8s 原生方案 – Multi-Cluster Services API

KEP-1645 定义了 ServiceExport/ServiceImport CRD， 让 Service 可以被导出到其他集群：

# Cluster A: 导出 Service
apiVersion: multicluster.x-k8s.io/v1alpha1
kind: ServiceExport
metadata:
  name: payment-service
  namespace: finance

---
# Cluster B: 自动导入，可通过 DNS 访问
# payment-service.finance.svc.clusterset.local

MCS API 的优势在于它是 SIG-Multicluster 的官方标准，不依赖特定 CNI 实现。 未来预期 ClusterMesh 等方案将与 MCS API 对齐，提供统一的多集群服务发现和路由语义。

3.3 Kubernetes 成为跨云统一网络平面

当多集群扩展到多云（AWS + GCP + Azure + 本地）， Kubernetes 的网络抽象能力使其天然适合充当跨云统一网络平面：

AWS EKS                 GCP GKE                 Azure AKS
  |                       |                       |
  +-- Pod CIDR: 10.1.0.0/16  10.2.0.0/16  10.3.0.0/16
  |                       |                       |
  +===== WireGuard / IPsec / 云厂商 VPN =====+
  |                       |                       |
  Gateway API (南北)  +  MCS API (东西)  +  Cilium Identity (安全)

实现跨云网络的关键技术栈： 确保不同集群的 Pod/Service CIDR 不重叠； WireGuard 跨云隧道或利用云厂商 VPN/Interconnect； MCS API 统一域名解析 *.svc.clusterset.local； Cilium Identity 跨集群同步，安全策略全局生效； Gateway API + Locality-aware routing 实现就近访问。

四、趋势四：AI 工作负载对网络的新需求

4.1 问题的规模

一次大模型训练任务的网络需求与传统微服务截然不同：

当数千张 GPU 参与分布式训练时，每次梯度同步（AllReduce）的通信量与模型参数量成正比。 一个 175B 参数的 GPT 模型，单次 AllReduce 需传输约 350GB 梯度数据。 网络成为瓶颈时，GPU 昂贵的计算时间将白白浪费在等待上。

4.2 GPU-to-GPU 通信：RDMA、RoCE v2、GPUDirect

传统 TCP/IP 网络栈对 AI 训练来说太慢了——每个包要经过 socket 层、TCP 协议处理、 IP 路由、驱动队列，延迟在数十微秒到毫秒级。AI 训练需要微秒级、零拷贝的 GPU 间直连通信。

RDMA（Remote Direct Memory Access）

RDMA 允许一台机器直接读写远程机器的内存，完全绕过双方的 CPU 和内核协议栈：

传统 TCP/IP:  GPU->CPU->内核->NIC->网络->NIC->内核->CPU->GPU  延迟 ~100us
RDMA:         GPU Memory->NIC(RDMA)->网络->NIC(RDMA)->GPU Mem  延迟 ~2us

RoCE v2（RDMA over Converged Ethernet v2）

RoCE v2 在标准以太网上实现 RDMA，使用 UDP/IP 封装 RDMA 包，可穿越标准 L3 网络。 但对网络质量极为敏感，需配合 PFC 和 ECN 实现无损以太网：

# 配置 PFC (以 mlx5 网卡为例)
mlnx_qos -i eth0 --pfc 0,0,0,1,0,0,0,0
# 启用 ECN
sysctl -w net.ipv4.tcp_ecn=1
# 配置 DSCP 标记
tc filter add dev eth0 protocol ip parent ffff: \
  flower ip_proto udp dst_port 4791 \
  action skbedit priority 3

GPUDirect RDMA

GPUDirect RDMA 更进一步，允许网卡直接访问 GPU 显存，跳过主机内存的中间拷贝：

无 GPUDirect:  GPU Mem -> Host Mem (拷贝1) -> NIC -> 网络 -> NIC -> Host Mem (拷贝2) -> GPU Mem
GPUDirect:     GPU Mem -> NIC (DMA直连) -> 网络 -> NIC (DMA直连) -> GPU Mem  (带宽提升 2x+)

4.3 Kubernetes 中的 RDMA 网络

在 Kubernetes 中使用 RDMA 需要特殊的网络配置：

# 1. 使用 Multus CNI 配置多网络接口
apiVersion: k8s.cni.cncf.io/v1
kind: NetworkAttachmentDefinition
metadata:
  name: rdma-net
  namespace: ai-training
  annotations:
    k8s.v1.cni.cncf.io/resourceName: rdma/rdma_shared_device_a
spec:
  config: |
    {
      "cniVersion": "0.3.1",
      "type": "host-device",
      "device": "eth1",
      "ipam": {
        "type": "whereabouts",
        "range": "192.168.100.0/24"
      }
    }

---
# 2. Pod 请求 RDMA 设备资源
apiVersion: v1
kind: Pod
metadata:
  name: training-worker-0
  namespace: ai-training
  annotations:
    k8s.v1.cni.cncf.io/networks: rdma-net
spec:
  containers:
  - name: trainer
    image: nvcr.io/nvidia/pytorch:24.03-py3
    resources:
      limits:
        nvidia.com/gpu: 8
        rdma/rdma_shared_device_a: 1

关键组件：Multus CNI（多网络接口管理）、SR-IOV Device Plugin（网卡虚拟化）、 RDMA Shared Device Plugin（RDMA 设备资源管理）、Whereabouts IPAM（固定 IP 分配）。

4.4 拓扑感知调度

在大规模 GPU 集群中，网络拓扑直接影响训练效率。 同一 NVSwitch 域内的 GPU 间通信走 NVLink（900 GB/s）， 同一机架内走 RoCE（400 Gbps）， 跨机架走 Spine 交换机（可能拥塞）。

Kubernetes 的拓扑感知调度需要结合多个机制：

# TopologySpreadConstraints 确保 Pod 分布感知网络拓扑
apiVersion: apps/v1
kind: Deployment
metadata:
  name: training-workers
spec:
  replicas: 64
  template:
    spec:
      topologySpreadConstraints:
      - maxSkew: 1
        topologyKey: topology.kubernetes.io/zone
        whenUnsatisfiable: DoNotSchedule
      - maxSkew: 2
        topologyKey: network.kubernetes.io/rack
        whenUnsatisfiable: ScheduleAnyway
      nodeSelector:
        nvidia.com/gpu.product: "A100-SXM4-80GB"
        network.kubernetes.io/rdma: "true"

前沿方向包括： JobSet API（SIG-Apps 正在开发，原生支持多 Pod 训练任务的拓扑约束）、 DRA（KEP-3063，GPU 和 RDMA 设备动态分配和拓扑感知）、 网络拓扑 CRD（社区提案，将物理网络拓扑暴露为 K8s 资源）。

4.5 推理服务的低延迟优化

AI 推理场景的网络需求与训练不同，更关注的是延迟和吞吐的平衡：

# Gateway API 推理服务路由配置
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: inference-route
spec:
  parentRefs:
  - name: ai-gateway
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /v1/inference
    backendRefs:
    - name: inference-svc
      port: 8080
    timeouts:
      request: "500ms"
      backendRequest: "200ms"

五、架构师检查清单

以下是本系列三十篇内容提炼的架构师七步检查清单， 建议 Day-0 完成前两步，Day-1 完成中间三步，Day-2 持续优化后两步。

Step 1: CNI 选型（P0 – Day-0）

这是所有网络决策的起点。一旦选定 CNI，后续的数据面、安全策略、多集群方案都将受其影响。

决策框架：

内核版本 >= 5.10?
  |-- 是 --> 需要 L7 策略 / 可观测性?
  |            |-- 是 --> Cilium (eBPF 数据面)
  |            |-- 否 --> 需要 BGP 路由?
  |                        |-- 是 --> Calico (BGP 模式)
  |                        |-- 否 --> Cilium 或 Calico (VXLAN)
  |-- 否 --> 小规模集群?
               |-- 是 --> Flannel (简单可靠)
               |-- 否 --> Calico (iptables 模式)

详见第十四篇：CNI 选型指南。

Step 2: MTU 调优（P0 – Day-0）

MTU 配置错误是 Kubernetes 网络问题的第一大隐性杀手， 会导致分片、丢包、性能断崖。

计算公式：

Pod MTU = 物理网络 MTU - Overlay 开销

Overlay 开销参考值:
  VXLAN:      50 bytes (8 VXLAN + 8 UDP + 20 IP + 14 Ethernet)
  Geneve:     50 bytes (可变，基础与 VXLAN 相同)
  WireGuard:  60 bytes (40 WG + 8 UDP + 12 reserved)
  IPsec ESP:  50-73 bytes (取决于算法)
  Native:     0 bytes (无 Overlay)

示例:
  物理 MTU 1500 + VXLAN --> Pod MTU = 1450
  物理 MTU 9000 + VXLAN --> Pod MTU = 8950 (推荐)
  物理 MTU 1500 + Native --> Pod MTU = 1500

详见第二十三篇：MTU 调优。

Step 3: 加密策略（P0 – Day-1）

需要传输加密?
  |-- 否 --> 仅物理安全区域内的可信网络
  |-- 是 --> 选择加密方案:
               |-- WireGuard: 性能好，配置简单，推荐默认选项
               |-- IPsec: 合规要求需要 FIPS 140-2 认证
               |-- mTLS: 需要同时验证身份（零信任场景）

详见第二十二篇：传输加密。

Step 4: NetworkPolicy 基线（P0 – Day-1）

最小基线：每个 Namespace 创建 default-deny-ingress 和 default-deny-egress； 使用 ANP 阻断云元数据服务访问； DNS 出站放行（UDP/TCP 53 到 kube-dns）；按应用最小权限开放端口。

# 基线策略模板：允许 DNS + 阻断其余出站
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-dns-only
spec:
  podSelector: {}
  policyTypes:
  - Egress
  egress:
  - to:
    - namespaceSelector:
        matchLabels:
          kubernetes.io/metadata.name: kube-system
    ports:
    - protocol: UDP
      port: 53
    - protocol: TCP
      port: 53

详见第十九篇：NetworkPolicy。

Step 5: DNS 优化（P1 – Day-1）

DNS 是 Kubernetes 中最容易被低估的性能瓶颈——默认配置下， 每次 DNS 查询会产生 4~8 次实际请求（IPv4/IPv6 * search 域）。

# Pod DNS 配置优化
spec:
  dnsConfig:
    options:
    - name: ndots
      value: "2"
    - name: single-request-reopen
      value: ""
    searches:
    - default.svc.cluster.local
    - svc.cluster.local

• NodeLocal DNSCache：在每个节点部署 DNS 缓存。
• autopath 插件：CoreDNS 服务端短路 search 域查询。
• ndots 调优：将默认的 ndots:5 降到 ndots:2。

详见第十五篇：CoreDNS。

Step 6: 可观测性（P1 – Day-2）

没有可观测性的网络等于盲飞。推荐的可观测性栈：

详见第二十五篇：可观测性和 第二十六篇：故障排查。

Step 7: 多集群规划（P2 – Day-2）

并非每个组织都需要多集群，但一旦需要，提前规划远好过事后改造：

关键检查项： CIDR 不重叠（提前为每个集群分配独立的 Pod/Service CIDR 段）； 互联方案（ClusterMesh 或 Submariner）； 服务发现（MCS API 或 DNS 代理转发）； 策略同步（跨集群 Identity 同步或集中式策略管理）； 故障域隔离（确保单集群故障不影响其他集群的控制面）。

详见第二十七篇：多集群和 第二十八篇：跨云互联。

六、本系列知识图谱与推荐深入方向

6.1 知识图谱

本系列三十篇文章构成了一张完整的 Kubernetes 网络知识图谱。 以下按主题域梳理它们的关联关系：

Linux 内核基础
  |-- 01. Linux 网络栈全景
  |-- 02. 虚拟网络设备 (veth/bridge/tun/tap)
  |-- 03. Netfilter 与 iptables
  |-- 04. 路由与隧道 (VXLAN/Geneve/WireGuard)
  |-- 05. BGP 基础
  |-- 06. eBPF 网络编程
  |
Kubernetes 核心网络
  |-- 07. K8s 网络模型 (三大规则)
  |-- 08. CNI 规范
  |-- 09. Service 与 kube-proxy
  |-- 10. 双栈 (IPv4/IPv6)
  |
CNI 实现对比
  |-- 11. Flannel
  |-- 12. Calico
  |-- 13. Cilium
  |-- 14. CNI 选型指南
  |
服务发现与流量治理
  |-- 15. CoreDNS
  |-- 16. Service 进阶 (Headless/ExternalName/Topology)
  |-- 17. Ingress 控制器
  |-- 18. Gateway API
  |
安全与策略
  |-- 19. NetworkPolicy
  |-- 20. Cilium 身份感知安全
  |-- 21. eBPF vs Netfilter 深度对比
  |-- 22. 传输加密 (WireGuard/IPsec/mTLS)
  |
性能与可观测
  |-- 23. MTU 调优
  |-- 24. DSR (Direct Server Return)
  |-- 25. 网络可观测性
  |-- 26. 网络故障排查
  |
多集群与前沿
  |-- 27. 多集群网络
  |-- 28. 跨云互联
  |-- 29. eBPF 演进
  |-- 30. 未来趋势与架构师指南 (本文)

6.2 按角色推荐的阅读路径

平台工程师 / SRE：07 –> 08 –> 09 –> 14 –> 23 –> 15 –> 25 –> 26 （K8s 模型 –> CNI 规范 –> Service –> CNI 选型 –> MTU –> DNS –> 可观测 –> 排查）

安全工程师：03 –> 19 –> 20 –> 22 –> 21 –> 06 （iptables –> NetworkPolicy –> Cilium 身份 –> 加密 –> eBPF 对比 –> eBPF 编程）

网络工程师：01 –> 02 –> 04 –> 05 –> 03 –> 06 –> 12 –> 13 （内核栈 –> 虚拟设备 –> 隧道 –> BGP –> Netfilter –> eBPF –> Calico –> Cilium）

AI 基础设施工程师：07 –> 13 –> 23 –> 24 –> 本文（趋势四） （K8s 模型 –> Cilium –> MTU –> DSR –> AI 网络）

6.3 推荐深入方向

本系列覆盖了 Kubernetes 网络的核心知识， 但技术的演进永不停歇。以下是值得持续关注的方向：

内核与数据面：Linux 内核 BPF 子系统 mailing list（bpf@vger.kernel.org）、 Cilium 官方博客与 CFP、nftables 在 kube-proxy 中的演进（KEP-3866）。

安全：SIG-Network-Policy 的 AdminNetworkPolicy 提案、 SPIFFE/SPIRE 在 K8s 中的集成、CNCF TAG-Security 供应链安全指南。

流量治理：Gateway API GEP（Gateway Enhancement Proposals）、 SIG-Multicluster 的 MCS API 演进、GAMMA initiative。

AI 网络：NVIDIA NCCL 与 UXL Foundation 通信库标准化、 Kubernetes DRA（KEP-3063）、Ultra Ethernet Consortium 下一代以太网规范。

社区参与：SIG-Network 双周会议（kubernetes/community/sig-network）、 SIG-Network-Policy 工作组、Cilium 社区 Slack（cilium.slack.com）。

七、结语

Kubernetes 网络正在经历一次深刻的范式转换。 四条主线同时推进：

1. 内核化：iptables 退场，eBPF 成为默认数据面语言，可编程内核网络成为新常态。
2. 安全前置：NetworkPolicy 从可选变必选，身份替代 IP，零信任从理念走向工程实践。
3. 多云统一：Gateway API 统一南北向，MCS API 统一东西向，K8s 成为跨云网络控制面。
4. AI 驱动：RDMA/RoCE v2/GPUDirect 重新定义了「网络性能」的含义，拓扑感知调度成为刚需。

对于架构师来说，最重要的不是追逐每一个新技术， 而是建立一套稳定的决策框架： 从 CNI 选型到 MTU 调优，从加密策略到 NetworkPolicy 基线， 从 DNS 优化到可观测性，从单集群到多集群规划。 这七步清单覆盖了 Day-0 到 Day-2 的完整生命周期。

本系列三十篇文章， 从 Linux 内核网络栈的第一个中断开始， 到 Kubernetes 网络的未来趋势结束， 试图为读者描绘一张完整的技术图景。

网络是分布式系统的血液循环系统。 理解它，才能真正驾驭 Kubernetes。

附录 A：快速参考 – 关键技术对比

数据面技术对比

加密方案对比

AI 网络技术对比

附录 B：术语表

附录 C：推荐阅读

• Kubernetes Network Model
• Gateway API 官方文档
• Cilium 官方文档
• SIG-Network KEPs
• SPIFFE/SPIRE 官方文档
• NVIDIA NCCL Developer Guide
• Ultra Ethernet Consortium
• Kubernetes SIG-Multicluster

• 上一篇：eBPF 演进
• 系列首篇：Linux 网络栈全景
• 相关：CNI 选型 | Gateway API | 多集群网络