第275篇：Kubernetes 网络：CNI、Pod 网络与 Service

关键词：Kubernetes、CNI、Pod网络、Service、ClusterIP、NodePort、网络模型

一、引言

Kubernetes（K8s）作为容器编排的事实标准，其网络模型是整个平台的核心组件之一。Kubernetes定义了一套严格的网络模型要求，并通过CNI（Container Network Interface）插件机制实现灵活的网络方案。

理解Kubernetes网络模型、CNI插件的工作原理以及Service网络的设计，是部署和运维Kubernetes集群的前提。

二、核心概念

2.1 Kubernetes 网络模型

Kubernetes定义了以下网络模型要求：

2.2 CNI（Container Network Interface）

CNI是CNCF孵化的容器网络标准，定义了容器网络插件的接口规范：

CNI的核心接口：

CNI工作流程：

2.3 Pod 网络

Pod网络是Kubernetes的基本网络单元：

Pod网络的特点： - 同一Pod内的容器共享网络命名空间（相同的IP和端口空间） - 每个Pod通过veth pair连接到宿主机的网络命名空间 - Pod的IP地址由CNI插件分配和管理

Pod的IP分配方式：

2.4 Kubernetes Service

Service是Kubernetes中实现服务发现和负载均衡的抽象：

Service的类型：

Service的工作原理：

三、技术细节

3.1 kube-proxy 的三种模式

kube-proxy负责实现Service的负载均衡：

iptables模式： - kube-proxy监听Service和Endpoints的变化 - 生成iptables规则，将Service VIP的流量DNAT到后端Pod - 负载均衡算法为随机选择

IPVS模式： - 使用Linux IPVS模块实现负载均衡 - 支持rr（轮询）、lc（最少连接）、dh（目的哈希）等算法 - 性能优于iptables模式

3.2 Pod 间通信模型

3.3 Service 流量路径

ClusterIP Service流量路径： 1. Pod发送报文到Service的ClusterIP 2. kube-proxy的iptables/ipvs规则将ClusterIP DNAT到后端Pod IP 3. 报文转发到目标Pod

NodePort Service流量路径： 1. 外部客户端访问NodeIP:NodePort 2. kube-proxy将流量转发到Service的ClusterIP 3. 再转发到后端Pod

3.4 IPAM（IP地址管理）机制

CNI插件通过IPAM子插件管理Pod IP地址分配：

host-local IPAM配置示例：

{
  "cniVersion": "0.3.1",
  "name": "mynet",
  "type": "veth",
  "ipam": {
    "type": "host-local",
    "subnet": "10.244.0.0/16",
    "rangeStart": "10.244.1.128",
    "rangeEnd": "10.244.1.254",
    "routes": [
      { "dst": "0.0.0.0/0" }
    ],
    "gateway": "10.244.1.1"
  }
}

3.5 Multus：多网卡CNI

Kubernetes默认每个Pod只有一个网络接口。Multus CNI允许Pod附加多个网络接口：

apiVersion: "k8s.cni.cncf.io/v1"
kind: NetworkAttachmentDefinition
metadata:
  name: storage-network
spec:
  config: '{
    "cniVersion": "0.3.1",
    "type": "macvlan",
    "master": "eth1",
    "mode": "bridge",
    "ipam": {
      "type": "host-local",
      "subnet": "10.100.0.0/16",
      "rangeStart": "10.100.0.100",
      "rangeEnd": "10.100.0.200",
      "routes": [
        { "dst": "0.0.0.0/0" }
      ],
      "gateway": "10.100.0.1"
    }
  }'
---
# Pod使用多网卡
apiVersion: v1
kind: Pod
metadata:
  name: multi-net-pod
  annotations:
    k8s.v1.cni.cncf.io/networks: storage-network
spec:
  containers:
  - name: app
    image: myapp:latest
    # 默认网卡: eth0 (Pod网络)
    # 附加网卡: net1 (storage-network)

3.6 Pod 网络 Troubleshooting 流程

四、实战配置/案例分析

4.1 CNI 插件配置（以Calico为例）

# Calico CNI 配置
apiVersion: v1
kind: ConfigMap
metadata:
  name: calico-config
  namespace: kube-system
data:
  cni_network_config: |
    {
      "name": "k8s-pod-network",
      "cniVersion": "0.3.1",
      "type": "calico",
      "ipam": {
        "type": "calico-ipam",
        "subnet": "192.168.0.0/16"
      },
      "policy": {
        "type": "k8s"
      },
      "kubernetes": {
        "kubeconfig": "/etc/cni/net.d/calico-kubeconfig"
      }
    }
---
# Calico DaemonSet
apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: calico-node
  namespace: kube-system
spec:
  template:
    spec:
      containers:
      - name: calico-node
        image: calico/node:v3.26
        env:
        - name: CALICO_IPV4POOL_CIDR
          value: "192.168.0.0/16"
        - name: IP_AUTODETECTION_METHOD
          value: "interface=eth0"

4.2 Service 配置示例

# ClusterIP Service
apiVersion: v1
kind: Service
metadata:
  name: my-app-service
spec:
  type: ClusterIP
  selector:
    app: my-app
  ports:
  - port: 80
    targetPort: 8080
    protocol: TCP
---
# NodePort Service
apiVersion: v1
kind: Service
metadata:
  name: my-app-nodeport
spec:
  type: NodePort
  selector:
    app: my-app
  ports:
  - port: 80
    targetPort: 8080
    nodePort: 30080
---
# Headless Service (无ClusterIP)
apiVersion: v1
kind: Service
metadata:
  name: my-app-headless
spec:
  clusterIP: None
  selector:
    app: my-app
  ports:
  - port: 80
    targetPort: 8080

4.3 故障案例：Pod间网络不通

现象：跨节点的Pod无法通信，同节点Pod通信正常。

排查过程：

# 1. 检查Pod IP
kubectl get pods -o wide
# Pod-A: 192.168.1.5 (节点1)
# Pod-B: 192.168.2.5 (节点2)

# 2. 从Pod-A ping Pod-B
kubectl exec pod-a -- ping 192.168.2.5
# 请求超时

# 3. 检查节点路由
ip route show | grep 192.168
# 节点1缺少到192.168.2.0/24的路由

# 4. 检查CNI状态
kubectl get pods -n kube-system | grep calico
# calico-node在节点1的状态为CrashLoopBackOff

# 5. 检查calico日志
kubectl logs calico-node-xxx -n kube-system
# 错误: BGP peer connection failed, 节点间BGP会话未建立

根因：节点1上的calico-node Pod异常退出（CrashLoopBackOff），导致该节点的CNI路由和BGP会话失效，跨节点Pod无法通信。

解决： 1. 检查calico-node的资源限制和日志，修复crash原因 2. 临时重启calico-node Pod恢复网络 3. 监控CNI Pod的健康状态，设置告警

五、总结

思考

1. Kubernetes要求Pod扁平网络（所有Pod直接可达），这在物理上是如何实现的？CNI插件扮演什么角色？
2. kube-proxy的iptables模式和IPVS模式在负载均衡算法上有什么区别？哪种模式更适合大规模集群？
3. Headless Service（clusterIP: None）的用途是什么？什么场景下需要使用Headless Service？
4. Multus多网卡CNI如何解决Pod需要同时接入多个网络的需求？与VLAN子接口方案相比有什么优势？
5. Pod IP在Pod重启后是否会变化？如果业务依赖固定IP，应该如何设计？

下篇预告：第276篇：Flannel、Calico、Cilium 方案对比