在 Kubernetes (K8s) 的世界里，网络是连接和驱动整个分布式系统的命脉，但其复杂性也常常令人望而生畏。容器网络接口（Container Network Interface, CNI）作为一套标准化的插件规范，为各类网络方案的接入提供了可能。然而，不同的 CNI 插件在实现跨节点通信时，采用了迥异的技术路径，其中，VXLAN (虚拟可扩展局域网) 技术凭借其对二层网络的虚拟化能力，成为解决跨节点Pod通信的核心方案之一。

本文将从厘清 CNI、VTEP 和 kube-proxy 这三大核心组件的精确分工与协作关系入手，深入剖析 VXLAN 技术如何作为网络桥梁，实现跨节点的 Pod 通信。同时，将从同节点Pod通讯、跨节点Pod直连、跨节点Service访问三个视角，完整呈现流量处理全流程；并针对 Flannel、Calico 和 Cilium 三大主流 CNI 插件，详细拆解 VXLAN 的实现逻辑、优化手段及技术替代方案，结合数据包旅程具象化流量分发细节。

第一章：核心组件角色定位：CNI、VTEP 与 kube-proxy 的精准分工

要理解 K8s 网络，首先必须明确几个核心组件的职责边界。它们各司其职，通过流量的间接联动，共同构成了 K8s 网络的完整工作流，无直接依赖却缺一不可。

核心关系概括：可以通俗地将三者关系理解为：CNI 负责“造路”（搭建Pod网络栈与连通通道），VTEP 负责“架桥”（跨节点Overlay隧道传输），而 kube-proxy 负责“指路”（Service流量负载分发）。

CNI (Container Network Interface)：网络规范的“管理者”与“实现驱动者”。它本身不是具体网络组件，而是 K8s 定义的一套标准接口，规定了容器运行时如何调用插件为 Pod 完成“网络创建”（分配IP、创建虚拟网卡eth0、配置路由与网桥）、“网络销毁”及“跨节点连通策略”。所有具体网络能力均由符合规范的 CNI 插件（如 Flannel、Calico）实现，K8s 仅通过 CNI 接口触发插件工作，不介入底层逻辑。

VTEP (VXLAN Tunnel Endpoint)：VXLAN 隧道的“执行者”与“端点载体”。VTEP 是 VXLAN 协议的物理或虚拟端点，在 K8s 中通常表现为节点上的虚拟网络设备（如 Flannel 的 flannel.1、Calico 的vxlan.calico）。其核心职责是对数据包执行 封装（Encapsulation）（跨节点发送时）与 解封装（Decapsulation）（接收时），将二层Pod流量封装为三层UDP包在物理网络传输。VTEP 由支持 VXLAN 模式的 CNI 插件创建、配置与维护，是 Overlay 网络的核心载体。

kube-proxy：服务发现的“指路者”与“负载均衡器”。作为 K8s 原生组件，它以 DaemonSet 形式运行在每个节点，核心任务是实现 Service 资源的服务发现与负载均衡。通过监听 APIServer 同步 Service/Endpoint 变化，在节点上维护 iptables 或 ipvs 规则，将发往 Service VIP 的流量转发至后端Pod IP。它不关心 Pod 间网络是否连通，仅负责上层流量的“方向指引”，与 CNI/VTEP 无代码依赖，仅在流量层面联动。

三者的职责与关系可通过下表清晰区分：

组件	核心职责	工作层级	存在形式	核心关系	故障影响范围
CNI	定义接口规范，驱动插件构建Pod网络栈与连通通道	接口/策略层	规范 + 插件进程（如 flanneld、calico-node）	管理者，创建并管理 VTEP	Pod无网络、跨节点通信中断
VTEP	VXLAN 报文封装/解封装，Overlay隧道传输	数据链路层/网络层	虚拟网络设备（如 flannel.1、vxlan.calico）	执行者，CNI插件的底层工具	跨节点Pod通信中断，本机Pod通信正常
kube-proxy	Service负载均衡、VIP到Pod IP转发	网络层/传输层	守护进程 + iptables/ipvs规则	独立协作者，流量层面联动	Service访问失效，Pod直连正常

关键结论：CNI 插件通过创建 VTEP 搭建跨节点Pod通信的底层隧道；kube-proxy 利用这条隧道实现 Service 流量分发。二者分工明确，故障域隔离——kube-proxy 故障不影响 Pod 直连，VTEP/CNI 故障不影响本机 Service 转发（如本机Pod访问Service）。

第二章：多视角流量处理全解析：Pod通信的完整旅程

K8s 中 Pod 通信分为三大核心场景，不同场景的流量路径、处理逻辑及组件参与度差异显著。本节结合 Flannel VXLAN 模式，从三个视角完整拆解流量旅程，明确 CNI、VTEP、kube-proxy 的协同逻辑。

场景设定

CNI 插件：Flannel（VXLAN 模式），VTEP 设备为 flannel.1，VNI=10001

底层物理网络（Underlay）：192.168.1.0/24，Node1 IP=192.168.1.10，Node2 IP=192.168.1.20

Pod 网络（Overlay）：10.244.0.0/16，Node1 对应子网 10.244.0.0/24，Node2 对应子网 10.244.1.0/24

Service 信息：demo-svc（VIP=10.96.100.10），标签选择器匹配 Pod-B，Endpoint 包含 Pod-B IP=10.244.1.2

核心设备地址：

Pod-A（Node1）：IP=10.244.0.2，MAC=0a:58:0a:f4:00:02
Pod-B（Node2）：IP=10.244.1.2，MAC=0a:58:0a:f4:01:02
VTEP1（Node1）：MAC=5e:f8:4f:12:00:01，关联 IP=192.168.1.10
VTEP2（Node2）：MAC=5e:f8:4f:12:00:02，关联 IP=192.168.1.20
cni0 网桥（Node1/Node2）：分别为本机Pod网关，MAC=52:54:00:12:34:01（Node1）、52:54:00:78:90:01（Node2）

视角一：同节点Pod通信（Pod-A与Pod-C，均在Node1）

同节点Pod通信无需VTEP与kube-proxy参与，仅依赖CNI创建的本地网络栈（eth0 + cni0网桥），属于纯二层转发，性能最优。

流量发起：Pod-A 访问同节点 Pod-C（IP=10.244.0.3，MAC=0a:58:0a:f4:00:03），通过本地ARP广播获取 Pod-C 的 MAC 地址，生成原始二层数据帧——源IP=10.244.0.2，源MAC=Pod-A MAC；目的IP=10.244.0.3，目的MAC=Pod-C MAC。

网桥转发：数据帧从 Pod-A 的 eth0 网卡发出，进入 Node1 的 cni0 网桥（Pod默认网关）。cni0 作为二层网桥，识别目的MAC为本地Pod，直接通过网桥转发至 Pod-C 的 eth0 网卡。

响应流程：Pod-C 接收后处理请求，响应数据包按原路径返回 Pod-A，全程无封装/解封装操作，仅依赖本地网桥转发。

核心特点：CNI插件提前配置了Pod的路由规则（本机Pod网段流量指向cni0），无需跨三层，无性能损耗。

视角二：跨节点Pod通信（Pod-A直连Pod-B，Pod IP访问）

跨节点Pod直连依赖CNI创建的VTEP隧道，核心是VXLAN封装/解封装，实现Overlay二层通信，Pod无感知底层物理网络。

数据包的八步旅程（补充ARP代理与地址转换细节）

ARP解析MAC（CNI代理兜底）：Pod-A 发起访问 Pod-B（10.244.1.2），发送ARP广播请求“10.244.1.2的MAC地址”。由于跨节点，ARP广播无法穿透物理网络，Flannel 的 VTEP1 作为 ARP 代理，通过 etcd 同步的Pod-B信息，向 Pod-A 返回 Pod-B 的 MAC 地址，Pod-A 将 IP-MAC 映射写入本地ARP缓存。

生成原始数据帧：Pod-A 构造二层数据帧——源IP=10.244.0.2，源MAC=Pod-A MAC；目的IP=10.244.1.2，目的MAC=Pod-B MAC，发送至本机网关 cni0。

cni0转发至VTEP1：cni0 网桥通过路由表识别目的IP（10.244.1.2）属于跨节点子网，将数据帧转发至 Node1 的 VTEP1（flannel.1），同时将帧的源MAC替换为 VTEP1 的 MAC（5e:f8:4f:12:00:01），目的MAC替换为 VTEP2 的 MAC（5e:f8:4f:12:00:02），为封装做准备。

VTEP1执行VXLAN封装：VTEP1 在内核空间对数据帧层层封装，最终生成嵌套UDP包，封装结构如下（从内到外）：

内层：原始二层帧（含Pod-A→Pod-B的IP/MAC）
VXLAN头：VNI=10001（标识所属Overlay网络），标志位=0x08（表示携带VNI）
UDP头：源端口=随机高端口（如35678），目的端口=4789（VXLAN标准端口，VTEP监听端口）
外层IP头：源IP=Node1物理IP（192.168.1.10），目的IP=Node2物理IP（192.168.1.20）
外层MAC头：源MAC=Node1物理网卡MAC（00:0c:29:12:34:56），目的MAC=物理网关MAC（如192.168.1.1的MAC，用于底层路由）

底层物理网络传输：封装后的UDP包对底层网络而言是普通IP包，物理交换机/路由器仅解析外层IP头（192.168.1.10→192.168.1.20），按三层路由协议转发至 Node2 物理网卡。

Node2接收并转发至VTEP2：Node2 物理网卡接收数据包后，内核识别目的UDP端口=4789，将其转发至 VTEP2（flannel.1）。

VTEP2执行VXLAN解封装：VTEP2 按封装反向流程解包：① 剥离外层IP头与UDP头；② 校验VXLAN头VNI=10001（匹配则继续，不匹配则丢弃，实现隔离）；③ 剥离VXLAN头，还原原始二层帧（Pod-A→Pod-B的IP/MAC不变）。

cni0转发至Pod-B：还原后的帧被发送至 Node2 的 cni0 网桥，网桥识别目的MAC为Pod-B MAC，将帧转发至 Pod-B 的 eth0 网卡，通信完成。响应流量按反向流程执行，由VTEP2封装、VTEP1解封装。

视角三：跨节点Pod通信（Pod-A通过Service名称访问Pod-B）

此场景是生产主流模式，需 kube-proxy（Service转发）、CNI（网络栈）、VTEP（隧道传输）协同工作，核心是“DNS解析→VIP转发→VXLAN隧道”的全链路联动。

数据包的十步旅程（衔接Service与VXLAN流程）

Service域名解析：Pod-A 访问 Service 域名（demo-svc.default.svc.cluster.local），向 CoreDNS（VIP=10.96.0.10，K8s内置DNS）发送解析请求。CoreDNS 查询 APIServer 获 Service VIP=10.96.100.10，返回给 Pod-A，Pod-A 缓存域名-VIP映射。

发起Service请求：Pod-A 向 VIP=10.96.100.10 发送请求，数据包源IP=10.244.0.2，目的IP=10.96.100.10，源MAC=Pod-A MAC，目的MAC=cni0 MAC（网关），发送至 cni0 网桥。

kube-proxy规则匹配与DNAT转换：数据包触发 Node1 的 iptables 规则（kube-proxy 维护）：

`KUBE-SVC-xxx` 规则匹配目的IP=10.96.100.10的流量；
按负载均衡策略（如随机）选择 `KUBE-SEP-xxx` 规则（对应 Pod-B IP=10.244.1.2）；
执行 DNAT 转换，将数据包目的IP从 VIP（10.96.100.10）修改为 Pod-B 实际IP（10.244.1.2），源IP保持不变。

ARP解析Pod-B MAC：转换后数据包目的IP=10.244.1.2，Pod-A 发送ARP广播，由 VTEP1 代理响应 Pod-B MAC，流程同视角二第1步。

生成目标Pod数据帧：Pod-A 构造帧（源IP=10.244.0.2，目的IP=10.244.1.2；源MAC=Pod-A MAC，目的MAC=Pod-B MAC），发送至 cni0。

cni0转发至VTEP1：cni0 识别跨节点IP，转发至 VTEP1，并替换帧的源/目的MAC为 VTEP1/VTEP2 MAC，流程同视角二第3步。

VTEP1封装与底层传输：VTEP1 执行VXLAN封装，生成UDP包，通过物理网络转发至 Node2，流程同视角二第4-5步。

VTEP2解封装：VTEP2 解封装还原原始帧，流程同视角二第7步。

cni0转发至Pod-B：Node2 的 cni0 将帧转发至 Pod-B，流程同视角二第8步。

响应流量反向转发：Pod-B 响应数据包按原路径返回，Node2 的 kube-proxy 执行 SNAT 转换（将源IP从 Pod-B IP 改为 Service VIP），确保 Pod-A 接收的响应来自 VIP，实现 Service 透明性。

核心特点：kube-proxy 仅负责“VIP→Pod IP”的一次转发（DNAT/SNAT），后续流量完全由 CNI+VTEP 处理，二者职责边界清晰，互不干扰。

第三章：主流CNI插件深度解析：VXLAN的实现、优化与替代

三大主流CNI插件（Flannel、Calico、Cilium）对VXLAN的定位、实现方式及优化方向差异显著，本质是“通用性”“性能”“功能”三者的权衡。以下从架构设计、VXLAN实现细节、核心优势及适用场景展开分析。

一、Flannel：VXLAN为核心，追求极致简单与兼容性

Flannel 是 K8s 最基础、最广泛使用的 CNI 插件，设计哲学是“开箱即用、无侵入性”，VXLAN 模式是其默认且最核心的 Overlay 方案，完全依赖内核原生能力实现。

1. 核心架构与VXLAN实现细节

组件构成：由flanneld 守护进程（每个节点运行）、etcd（存储集群网络元数据）、内核 VXLAN 模块、虚拟设备（flannel.1 VTEP + cni0 网桥）组成。

VTEP创建与配置：flanneld 启动时，为每个节点创建 flannel.1 虚拟网卡（VTEP），并通过 etcd 同步全集群 VTEP 信息（VTEP IP=节点物理IP、VTEP MAC、VNI、Pod子网映射）。同时配置路由规则：将跨节点Pod网段（如10.244.1.0/24）的流量指向 flannel.1。

封装/解封装机制：完全依赖 Linux 内核原生 VXLAN 模块，封装操作在内核态完成，无用户态开销，但路径固定（需经过完整内核网络协议栈）。ARP代理由 flanneld 进程实现，通过监听 etcd 同步Pod IP-MAC映射，为跨节点ARP请求提供响应。

网络隔离能力：仅支持基于 VNI 的粗粒度隔离（不同VNI的Overlay网络无法互通），无网络策略功能，无法实现Pod级别的访问控制。

2. 优势与局限

优势：部署简单（单进程+etcd），兼容性极强（对底层网络无特殊要求，支持公有云/私有云），维护成本低，适合小规模集群或测试环境。

局限：性能中等（内核原生VXLAN有固定封装开销），功能单一（仅提供网络连通性，无策略、无监控），不支持L7流量处理，大规模集群（千级以上节点）性能易瓶颈。

3. 适用场景

小规模K8s集群、测试环境、对网络功能无复杂需求，追求部署效率的场景。

二、Calico：三层路由为核心，VXLAN作为兼容性补充

Calico 是企业级主流 CNI 插件，核心设计是“纯三层网络架构”，通过 BGP 协议实现Pod路由，VXLAN 仅作为 BGP 不可用场景的备选方案，其核心竞争力是强大的网络策略与高性能路由。

1. 核心架构与VXLAN实现细节

组件构成：由calico-node 守护进程、Felix（网络策略执行器）、BIRD（BGP客户端）、etcd（存储网络配置）、虚拟设备（VXLAN模式下为 vxlan.calico VTEP）组成。

两种核心模式对比：

BGP模式（首选）：无VXLAN参与，Calico 通过 BIRD 客户端在节点间交换 Pod 子网路由信息，数据包直接按三层路由转发（无封装/解封装），性能接近物理网络。适合支持BGP的环境（如数据中心、裸金属集群）。
VXLAN模式（备选）：针对不支持BGP的环境（如公有云VPC），Calico 创建 vxlan.calico VTEP 设备，利用内核原生VXLAN模块实现Overlay通信。与Flannel不同，Calico 的 VXLAN 模式仍保留网络策略能力——Felix 通过编程 iptables/eBPF 规则，在 VTEP 封装/解封装前后执行访问控制。

VXLAN优化点：支持“直接路由”（Direct Routing）优化，同一子网内Pod通信无需VXLAN封装，跨子网才触发隧道传输；VTEP信息通过etcd同步，ARP代理由 Felix 实现，比 Flannel 更稳定。

网络策略能力：支持L3/L4网络策略（基于IP、端口、标签），可实现Pod间、命名空间间的精细化访问控制，是企业级安全需求的核心选择。

2. 优势与局限

优势：性能优异（BGP模式无封装开销），网络策略强大，架构灵活（支持BGP/VXLAN/IPIP多种模式），稳定性高，适合大规模企业级集群。

局限：部署与维护复杂度高于Flannel（需配置BGP或VXLAN参数），VXLAN模式性能与Flannel相当，无L7策略能力。

3. 适用场景

中大规模企业级集群、对网络性能与安全策略有高要求的场景、混合云环境（BGP+VXLAN模式适配）。

三、Cilium：eBPF重构网络，超越VXLAN的极致体验

Cilium 是云原生网络的革新者，以 eBPF（扩展伯克利数据包过滤器）为核心技术，重新定义了 VXLAN 的实现方式，同时提供了超越隧道技术的高性能、高功能维度能力。

1. 核心架构与VXLAN实现细节

组件构成：由 cilium-agent 守护进程、eBPF程序（内核态运行）、Hubble（可观察性组件）、虚拟设备（VXLAN模式下为 cilium_vxlan VTEP）组成，无需依赖 etcd（可使用K8s API存储配置）。

eBPF驱动的VXLAN实现：Cilium 不依赖内核原生VXLAN模块，而是通过加载自定义 eBPF 程序到网络设备驱动层（如网卡、cni0网桥），直接在内核态完成 VXLAN 封装/解封装，绕过传统内核网络协议栈的冗余路径，效率远超 Flannel/Calico 的内核VXLAN实现。

超越VXLAN的原生路由：在支持的环境中，Cilium 通过 eBPF 程序直接操作内核路由表、邻居表，实现“eBPF原生路由”（无需BGP、无需VXLAN），性能比 Calico BGP模式更优，同时支持动态路由调整。

功能扩展能力：

L7策略：eBPF 可解析HTTP、gRPC、Kafka等L7协议，实现基于请求路径、方法、服务名的精细化访问控制；
可观察性：通过 Hubble 实时采集 eBPF 层面的流量数据，提供延迟、丢包、协议详情等指标，无需额外抓包工具；
服务网格集成：可替代 Istio 实现部分服务网格能力（如流量治理、安全加密），性能更优。

2. 优势与局限

优势：性能极致（eBPF优化VXLAN/原生路由），支持L3-L7全维度网络策略，可观察性强，架构简洁（无额外BGP客户端），适合云原生高性能、高安全需求场景。

局限：对内核版本有要求（需Linux 4.19+，推荐5.4+），部分高级功能需特定内核配置，学习成本高于传统CNI插件。

3. 适用场景

大规模云原生集群、对性能与可观察性有极致要求的场景、微服务架构（需L7策略）、服务网格替代场景。

三大CNI插件核心特性对比（强化VXLAN相关差异）

特性	Flannel	Calico	Cilium
VXLAN定位	核心依赖（唯一Overlay方案）	备选方案（兼容非BGP环境）	优化方案（eBPF加速，可替代）
VXLAN实现方式	Linux内核原生VXLAN模块	Linux内核原生VXLAN模块	eBPF程序直接处理（内核态加速）
ARP代理实现	flanneld进程	Felix组件	eBPF程序（内核态响应）
替代VXLAN的方案	无（仅支持VXLAN/Host-GW）	BGP模式（无封装，高性能）	eBPF原生路由（性能最优）
网络策略能力	无	L3/L4（IP、端口、标签）	L3-L7（含HTTP、gRPC等协议）
可观察性	弱（需额外抓包）	中等（依赖日志/监控工具）	强（Hubble实时采集eBPF数据）
性能（VXLAN模式）	中等（内核协议栈开销）	中等（内核协议栈开销+策略开销）	高（eBPF绕开冗余协议栈）
适用集群规模	小规模（百级节点）	中大规模（千级节点）	大规模（千级以上节点）

结论

K8s 网络的核心逻辑是“组件分工协作、技术按需选型”，通过本次深度剖析，可得出以下核心结论：

组件协同是基础：CNI、VTEP、kube-proxy 构成“底层通路+上层指引”的协作体系，CNI 搭建 Pod 网络与 VTEP 隧道，kube-proxy 实现 Service 流量分发，故障域隔离，确保网络稳定性。

多视角流量路径清晰：同节点Pod通信依赖本地网桥，跨节点直连依赖VXLAN隧道，Service访问需kube-proxy+VXLAN协同，不同场景的流量处理逻辑决定了性能与组件参与度，是排查网络问题的核心依据。

VXLAN的定位随插件迭代演进：Flannel 将VXLAN作为核心依赖，追求简单兼容；Calico 将其作为备选方案，核心立足三层路由；Cilium 用eBPF重构VXLAN实现，并提供超越隧道技术的原生路由能力，代表了云原生网络的发展方向。

选型需匹配业务场景：小规模测试选Flannel，企业级安全需求选中Calico，大规模高性能场景选Cilium。理解各插件的VXLAN实现差异、性能瓶颈与功能边界，是实现K8s网络高效、稳定运行的关键。

从传统内核依赖到eBPF革新，K8s CNI插件的演进本质是“性能、功能、易用性”的持续平衡，而VXLAN作为过渡性核心技术，既解决了跨节点通信的通用性问题，也在技术迭代中不断被优化和超越，为云原生网络提供了灵活的实现路径。

MongoDB 总结

Golang map

Catalog

Last update: 2025-02-25