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 是成熟的分布式路由协议，适合大规模集群
• 灵活：支持与数据中心现有 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 的选择#

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 仅多了一步，即通过 ipvs 使单独分配的 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