云原生网络技术全景CNI、主流插件、kube-proxy、eBPF 与云厂商K8s网络架构

📚 本篇定位：本文是一篇独立的云原生网络技术科普，不预设任何特定方案优于其他。我们将系统讲解 CNI 标准、主流 CNI 插件（Flannel、Calico、Cilium、Weave、Antrea 等）、kube-proxy 工作原理、eBPF 技术背景，以及 AWS EKS 和阿里云 ACK 的托管网络架构与组件。适合希望全面了解云原生网络生态的读者。

1️⃣ CNI：容器网络接口标准

CNI（Container Network Interface） 是 CNCF（云原生计算基金会）下的一个项目，定义了一套容器网络配置的标准接口。它本身不是网络实现，而是 Kubernetes 与网络插件之间的协议规范。

1.1 为什么需要 CNI？

Kubernetes 只负责调度 Pod，不关心底层如何实现网络。CNI 的存在使得不同网络方案可以自由替换，而无需修改 Kubernetes 核心代码。任何实现 CNI 规范的插件，都可以无缝接入集群。

1.2 CNI 工作流程

当 kubelet 创建 Pod 时，会通过 CRI（容器运行时接口）调用 containerd 等运行时；运行时读取 CNI 配置文件，调用 CNI 二进制插件执行 ADD 操作，为 Pod 分配 IP、创建虚拟网卡、配置路由。Pod 删除时调用 DEL 释放资源。

kubelet → containerd → CNI 配置 → CNI 插件 (ADD/DEL) → Pod 网络就绪

1.3 CNI 规范的核心操作

• ADD：将容器加入网络，分配 IP 并连接网卡。

• DEL：从网络中移除容器，释放 IP 资源。

• CHECK：检查容器网络是否存在问题。

• VERSION：返回插件版本信息。

2️⃣ 主流 CNI 插件详解

下面按字母顺序介绍常见 CNI 插件，每种方案都有其设计哲学和适用场景，并无“绝对最好”。

2.1 Antrea

Antrea 是 VMware 开源的项目，基于 Open vSwitch（OVS）和 OpenFlow 实现高性能的 Kubernetes 网络。它支持 NetworkPolicy、流量加密、多网络接口等高级功能，特别适合已有 VMware 虚拟化基础设施的环境。

• 特点：利用 OVS 的流表能力，提供高效的转发和策略执行。

• 优势：与 VMware NSX 集成良好，支持 Windows 节点。

• 局限性：依赖 OVS，增加了一定的运维复杂度。

2.2 Calico

Calico 是 Tigera 公司开发的项目，采用 BGP（Border Gateway Protocol）路由协议实现三层网络转发，是生产环境中最主流的 CNI 选项之一。

• 工作原理：每个节点作为 BGP Peer，交换 Pod CIDR 路由信息，Pod 之间的流量直接通过原生 IP 包转发，无需封装（可选 IPIP 隧道用于跨子网）。

• 优势：性能高（接近物理网络），支持丰富的网络策略（L3/L4），BGP 模式可直连数据中心路由器。

• 局限性：对底层网络有要求（需支持 BGP 或允许 IPIP），配置相对复杂。

2.3 Cilium

Cilium 是 Isovalent 公司（已被 Cisco 收购）主导的开源项目，基于 eBPF 技术提供网络、安全和可观测性。近年来发展迅速，被多家云厂商和大型企业采用。

• 工作原理：利用 eBPF 在内核中动态加载程序，替代传统的 iptables 或 IPVS，实现 Service 转发、网络策略、负载均衡等功能，并通过 Hubble 提供深度流量观测。

• 优势：高性能，支持 L7 策略（如 HTTP 路径/方法限制），可替换 kube-proxy，内置可观测性。

• 局限性：要求内核版本较新（≥4.19），学习曲线较陡峭。

2.4 Flannel

Flannel 是 CoreOS（现 Red Hat）开发的早期 CNI 方案，以简单易用著称，适合入门和小规模集群。

• 工作原理：通过 VXLAN、host-gw、UDP 等后端模式，为每个节点分配子网，跨节点流量通过隧道或路由转发。

• 优势：配置简单，对网络基础设施要求低。

• 局限性：不支持网络策略（NetworkPolicy），功能较单一。

2.5 Kube-OVN

Kube-OVN 是基于 OVN/OVS（Open vSwitch）的企业级 Kubernetes 网络方案，主要贡献者为灵雀云等厂商。

• 特点：提供子网划分、固定 IP、VPC 多租户、网关、VIP 等高级网络功能。

• 适用场景：需要精细化网络管理（如金融、运营商）或从 OpenStack 迁移的用户。

2.6 Multus

Multus 比较特殊，它不是一个完整的数据平面 CNI，而是一个“CNI 的 CNI”，即多网络接口管理插件。它可以让 Pod 同时连接多个网络（如主网络 + SR-IOV + MACvLAN）。

2.7 Weave Net

Weave Net 由 Weaveworks 公司开发，特点是自带 DNS 和加密功能，节点间通过 Gossip 协议自动发现和同步拓扑。

• 优势：部署简单，自愈能力强，支持跨云集群。

• 局限性：大规模下性能和稳定性不如 Calico/Cilium，社区活跃度有所下降。

2.8 CNI 方案对比总览

3️⃣ kube-proxy 与 Service 转发

kube-proxy 是 Kubernetes 每个节点上运行的核心组件，负责实现 Service 的访问（ClusterIP、NodePort、LoadBalancer）。它并不是 CNI，而是独立于 CNI 之上的流量转发层。

3.1 工作原理（iptables 模式）

• kube-proxy 监听 API Server 中 Service 和 Endpoint（或 EndpointSlice）的变化。

• 在节点上生成大量 iptables 规则（如 KUBE-SERVICES、KUBE-SVC-*、KUBE-SEP-*）。

• 当访问 Service ClusterIP 时，iptables 随机或轮询地 DNAT 到后端 Pod IP。

3.2 ipvs 模式

为解决 iptables 规则数量过大时的性能问题，kube-proxy 也支持 IPVS 模式，使用内核的 IPVS 模块（哈希表）提高转发效率，适合数千服务级别的集群。

3.3 新趋势：eBPF 替代 kube-proxy

Cilium 等方案支持 kubeProxyReplacement，完全移除 kube-proxy，由 eBPF 程序在内核中直接处理 Service 转发，理论上性能更高、延迟更稳定。但这并非“必须”，很多生产集群仍使用 kube-proxy 并运行良好。

4️⃣ eBPF 技术简介

eBPF（extended Berkeley Packet Filter） 是 Linux 内核的一项革命性技术，允许在内核中安全运行用户提供的沙箱程序。最早用于网络包过滤，现已扩展到追踪、安全、观测等领域。

• 原理：编写受限的 C 程序 → 编译为字节码 → 内核验证器检查安全性 → JIT 编译为本地指令 → 挂载到内核事件点（如网卡 XDP、tc、kprobe、tracepoint）。

• 优势：无需修改内核源码即可扩展功能，性能极高，避免用户态与内核态切换开销。

• 应用：Cilium、Falco（安全监控）、tcpdump（过滤）、云原生网络加速。

eBPF 的出现使得传统基于 iptables 的网络方案有了强大的替代选项，但目前仍需要较新的内核版本（一般要求 4.19+，推荐 5.10+）。

5️⃣ 公有云托管 Kubernetes 网络架构

各大云厂商提供托管 Kubernetes 服务，控制平面由云厂商管理，用户负责工作节点。网络组件通常深度集成云基础设施，以发挥云原生优势。

5.1 AWS EKS（Elastic Kubernetes Service）

默认 CNI：Amazon VPC CNI

• 原理：每个 Pod 获得一个 VPC 内的私有 IP（从节点所在子网分配），Pod 直接接入 VPC 网络，无需 Overlay。

• 组件：aws-node DaemonSet（包含 CNI 二进制和 ipamd）。

• 优势：Pod IP 可直接与 AWS 安全组、网络 ACL、流日志集成，无性能封装损耗。

• 限制：默认不支持网络策略，可通过安装 Calico（EKS 支持 add-on）或启用 VPC CNI 的 eBPF 网络策略模式实现。

• 其他选项：EKS 支持 Calico、Cilium 作为替代 CNI（尤其混合节点场景）。

EKS 整体架构组件：

• 控制平面：托管 API Server、etcd、Scheduler、Controller Manager。

• 数据平面：EC2 工作节点 + VPC CNI + kube-proxy + CoreDNS。

• 可选 add-on：AWS Load Balancer Controller（创建 ALB/NLB）、EBS CSI 驱动、Calico 网络策略等。

5.2 阿里云 ACK（Alibaba Container Service for Kubernetes）

默认 CNI：Terway

• 原理：基于阿里云弹性网卡（ENI）为 Pod 分配 VPC 原生 IP，支持独占 ENI（高性能）、共享 ENI（高密度）和 IPVLAN 等模式。

• 优势：Pod 网络与 VPC 无缝集成，可直接使用阿里云安全组、路由表、负载均衡。

• 网络策略：Terway 支持 NetworkPolicy（早期集成 Calico Felix，最新版本可通过 eBPF 或 Cilium 支持 L7 策略）。

• 备选方案：Flannel（VXLAN Overlay），适用于对网络策略无要求的中小规模集群。

ACK 整体架构组件：

• 控制平面：托管 Kubernetes 组件，支持大规模集群（数千节点）。

• 数据平面：ECS 工作节点 + Terway/Flannel + kube-proxy + CoreDNS。

• 特色能力：节点池、自动伸缩、GPU 调度、服务网格 ASM、容器镜像服务 ACR 等。

🧠 为什么云厂商要自研 CNI？
AWS VPC CNI 和阿里云 Terway 都是深度绑定各自 VPC 网络体系，能够提供 Pod 与云资源（安全组、负载均衡、流日志）的无缝集成。这是通用 CNI 插件（如 Calico）无法直接做到的。自研方案通常性能和运维体系更优，但用户也可根据需求选择第三方插件（如 Cilium）作为替代。

6️⃣ 总结：如何选择适合的网络方案？

没有“一剑封喉”的方案，选择应基于实际需求：

• 学习/测试环境：Flannel（简单）或 Weave（快速上手）。

• 生产环境，注重性能与策略：Calico（成熟稳定）。

• 追求可观测性、L7 策略、eBPF 技术红利：Cilium。

• 与 VMware 基础设施紧密整合：Antrea。

• 需要固定 IP、VPC 多租户等高级网络特性：Kube-OVN。

• 公有云托管服务：优先使用云厂商默认 CNI（VPC CNI 或 Terway），它们通常提供最优的云原生体验。若默认方案无法满足特定需求，再评估引入第三方 CNI 的可行性。

理解每种方案的设计哲学和边界，才能在具体场景中做出合理决策。希望本文能帮助您构建完整的云原生网络知识体系。