2.1 基于 underlay 网络的 Pods 互通技术#

在 underlay 网络中，我们一般通过路由实现网络互通。Flannel 就提供了一种最朴素的 underlay 网络互通方案，hostgw（主机网关）。

hostgw 的原理非常直接：每台宿主机作为各自 Pod 网段的网关，集群中的其他节点通过静态路由知道如何到达该网段。例如，当 Node A 上的 Pod 要访问 Node B 上的 Pod 时，流量首先发送到 Node B 作为网关的地址，再由 Node B 的内核路由转发到对应的 Pod。这种方式简单高效，不需要额外的封装开销，性能接近物理网络。

hostgw 的局限性在于要求所有节点必须在同一个二层网络（VLAN）中，否则跨子网的路由将无法生效。节点之间的路由信息需要手动维护或通过其他机制同步，在大规模集群中管理成本较高。

Calico 通过 BGP 提供了一种全三层的 underlay 网络互通方案。Calico 为每个节点分配一个子网，并通过 BGP 协议将路由信息广播到集群中的其他节点。当 Pod 需要与另一个节点上的 Pod 通信时，流量通过主机路由表直接发送到目标节点，无需任何封装。

Calico 的 BGP 模式性能接近原生网络，因为数据包无需封装解封装。BGP 本身是成熟的分布式路由协议，天然适合大规模集群的动态拓扑。Calico 还能与数据中心现有的 BGP 基础设施直接集成，不需要在集群边界做额外的路由转换。但 BGP 模式要求底层网络支持 BGP 协议，跨子网通信需要额外配置 BGP Peer，这对不具备网络设备管理权限的租户来说是个门槛。

Terway 通过交换机级联的方式实现网络互通：首先创建一个虚拟交换机用于 192.168.0.0/16 网络段，然后在该交换机下接入 Node 专用网络交换机用于 192.168.0.0/19 网段，接入 Pods 专用网络交换机用于 192.168.32.0/19 网段。这样也能实现 Pods 网络的需求。为了让 Pod 可以访问 Service 时能经过宿主机的 network namespace 中的 iptables 规则，所以另外增加了一个 veth 网卡打通 Pod 和宿主机的网络，并将集群的 Service 网段指向到这个 veth 网卡上。

2.2 基于 overlay 网络的 Pods 互通技术#

在 overlay 网络中，只需 underlay 网络能三层互通，overlay 网络便可以基于这层基础网络实现任意类型的网络。

最朴素的依旧是 Flannel 提供的用户态 UDP 程序实现的 overlay 网络。

UDP overlay 的原理是将原始 IP 包封装在 UDP 包中进行传输。以 Flannel 的 UDP 后端为例，在发送端，内核将 Pod 的流量截获并转发到用户态的 flanneld 进程，该进程再将包封装成 UDP 消息发送到目标节点；在接收端，目标节点的 flanneld 接收 UDP 包，解封装后将原始 IP 包交给内核处理。

这种方式的优势在于兼容性强，只要网络能通 UDP 就能工作。但代价是性能损耗显著，每个包都需要经过用户态处理，涉及多次内存拷贝。在 Kubernetes 早期或低版本内核环境中，UDP 封装是唯一可用的选项，如今已不推荐在生产环境使用。

再者就是传统数据中心常用的 VXLAN overlay 网络（大多数网络插件都支持）。

VXLAN（Virtual Extensible LAN）是一种网络虚拟化技术，通过在三层网络上构建二层隧道来扩展 VLAN 的数量限制。相比 UDP 封装，VXLAN 由内核模块直接处理，效率高得多。VXLAN 使用 24 位的 VNI（VXLAN Network Identifier），理论上可支持 1600 万个虚拟网络，远超 VLAN 的 4094 个限制。

在 Kubernetes 中，VXLAN 通常采用「首节点封装」模式：源节点将 Pod 的流量封装成 VXLAN 包，通过三层网络发送到目标节点的目标 Pod。这一过程对 Pod 透明，Pod 以为自己直接在和同网段的其他 Pod 通信，实际上流量已经过隧道封装。

还有一种增强模式被称为 geneve，它结合了 VXLAN 的框架和灵活扩展头的能力，可以携带更多元数据，但目前实际使用较少。

2.3 CNI 的选择#

Calico、Flannel、Cilium 三大主流 CNI 插件的具体实现原理（Felix/Bird 的 BGP 互连、Flannel 的 VXLAN 数据路径、Cilium 的 eBPF 数据路径）在 CNI 深度解析 中逐个拆解，这里只从选型视角给一张决策表：

一句话选型：规模小且不用策略选 Flannel，规模中等要策略选 Calico，规模大且要可观测性选 Cilium。三者的取舍边界和数据路径细节见 CNI 深度解析。

3.1 Service 集群网络#

Service 集群网络通过 ClusterIP + Port 对 PodIP + Port 进行映射。

通过以下 YAML 可以创建一个 Service，它将：

• 创建一个名称为 my-service 的 Service
• 选择所有包含 MyApp 标签的 Pod
• 目标端口为 9376
• EndPoint 控制器会根据该 Service 的选择器自动生成 EndPoint 资源
• kube-proxy 会根据 EndPoint 资源从 ClusterIP 池获取一个 IP 用于映射到这些 Pod 上

1
apiVersion: v1
2
kind: Service
3
metadata:
4
  name: nginx-service
5
spec:
6
  ports:
7
    - port: 30080
8
      targetPort: 80
9
  selector:
10
    name: nginx-pod

3.2 Service 外部接入网络#

从互联网访问集群有如下类型的实现：

NodePort

在每个节点上通过设置 NAT iptables 规则，将本机地址与 Pod 地址做转换，实现 Pod 的外部访问。

1
apiVersion: v1
2
kind: Service
3
metadata:
4
  name: nginx-service
5
spec:
6
  type: NodePort
7
  ports:
8
    - port: 30080
9
      targetPort: 80
10
      nodePort: 30001
11
  selector:
12
    name: nginx-pod

LoadBalancer（可以由 MetalLB 提供实现）

LoadBalancer 在 NodePort 的基础上，由云厂商的外部负载均衡器（如 AWS ELB、阿里云 SLB）分配一个外部可达的 IP，将流量转发到节点上的 NodePort。在自建机房没有云厂商 LB 时，MetalLB 通过 L2 ARP 或 BGP 宣告这个外部 IP，实现同样的效果。

1
apiVersion: v1
2
kind: Service
3
metadata:
4
  name: svc-nc-2-loadbalancer
5
spec:
6
  type: LoadBalancer
7
  ports:
8
    - name: http
9
      port: 80
10
      protocol: TCP
11
      targetPort: http
12
    - name: https
13
      port: 443
14
      protocol: TCP
15
      targetPort: https
16
  selector:
17
    app.kubernetes.io/name: ingress-nginx
18
    app.kubernetes.io/instance: ingress-nginx
19
    app.kubernetes.io/component: controller

externalIPs

最简单的方法是可以为服务定义一个外部 IP 实现外网访问。但这个 IP 在 kube-proxy ipvs 模式中不能定义为节点 IP，否则会使节点到主节点之间的连接中断。

1
apiVersion: v1
2
kind: Service
3
metadata:
4
  name: svc-nc-2-external
5
spec:
6
  externalIPs:
7
    - 172.18.40.208
8
  ports:
9
    - port: 8000
10
      targetPort: 1500
11
      protocol: TCP
12
  selector:
13
    app: pod-nc-2