Kubernetes网络模型

介绍

Kubernetes网络模型是Kubernetes集群中实现容器间通信的核心架构，它定义了Pod、节点和服务之间的网络交互规则。与传统的网络环境不同，Kubernetes要求所有Pod无论运行在哪个节点上，都能直接相互通信，且无需网络地址转换（NAT）。这一模型基于以下基本原则：

• 每个Pod拥有唯一的IP地址（IP-per-Pod）。
• Pod内的所有容器共享网络命名空间，可通过`localhost`直接通信。
• Pod与Pod之间的通信不依赖显式映射（如NAT）。

核心组件

Kubernetes网络模型依赖以下关键组件实现其功能：

Pod网络

Pod网络是跨节点的扁平化网络，确保：

• Pod IP地址在集群内全局唯一。
• Pod间可直接通过IP通信，无需网关。

graph LR PodA[Pod A] -->|直接通信| PodB[Pod B] PodB -->|跨节点| PodC[Pod C]

Service网络

Service是抽象层，为动态变化的Pod提供稳定访问端点，支持：

• ClusterIP：集群内虚拟IP。
• NodePort：通过节点端口暴露服务。
• LoadBalancer：集成云提供商负载均衡器。

apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  selector:
    app: nginx
  ports:
    - protocol: TCP
      port: 80
      targetPort: 9376

CNI (Container Network Interface)

CNI是网络插件标准，负责：

• 分配Pod IP地址。
• 配置网络路由规则。

常见插件包括Calico、Flannel和Cilium。

通信流程详解

Pod-to-Pod通信

跨节点通信通常通过覆盖网络（Overlay）或路由表实现： 1. 数据包从Pod A发送到Pod B。 2. 节点内核根据路由表将包转发到目标节点。 3. 目标节点的CNI插件将包传递给Pod B。

sequenceDiagram participant PodA participant Node1 participant Node2 participant PodB PodA->>Node1: 发送数据包到Pod B Node1->>Node2: 通过VXLAN/路由转发 Node2->>PodB: 交付数据包

Pod-to-Service通信

通过kube-proxy和iptables/IPVS实现负载均衡：

• ClusterIP：虚拟IP由kube-proxy映射到后端Pod。
• 流量根据规则随机分发到健康的Pod。

$\text{选择概率}=\frac{1}{\text{健康Pod数量}}$

实际案例

案例1：多层级应用通信

一个三层Web应用（前端、后端、数据库）的通信： 1. 前端Pod通过Service名称访问后端。 2. 后端Service将请求负载均衡到多个Pod。 3. 数据库使用StatefulSet确保持久化存储。

# 查询Service的Endpoint
kubectl get endpoints my-service

输出示例：

NAME         ENDPOINTS                         AGE
my-service   10.244.1.2:9376,10.244.2.5:9376   5m

案例2：网络策略隔离

使用NetworkPolicy限制流量：

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-frontend
spec:
  podSelector:
    matchLabels:
      role: frontend
  ingress:
    - from:
        - podSelector:
            matchLabels:
              role: backend

常见问题

问题	解决方案
Pod无法跨节点通信	检查CNI插件安装和节点路由表
Service无法访问	验证kube-proxy和Endpoints状态
网络延迟高	考虑使用非覆盖网络方案（如BGP）

进阶主题

• Ingress控制器：管理外部访问的HTTP路由。
• 服务网格（Service Mesh）：如Istio实现高级流量管理。
• eBPF优化：替代iptables提升性能。