K8s 网络模型：CNI 与 Service 网络

Kubernetes 网络模型四大要求

Kubernetes 网络模型的设计基于四个核心要求，理解它们是掌握 K8s 网络的基础。根据 Kubernetes 官方网络模型文档，这四个要求构成了集群网络通信的基石。

1. Pod 间通信（Pod-to-Pod）

K8s 要求所有 Pod 之间可以直接通过 IP 通信，无需 NAT（网络地址转换）。这意味着：

每个 Pod 拥有独立的 IP 地址
Pod 之间通信使用真实 Pod IP，不经过 NAT 转换
无论 Pod 调度到哪个 Node，Pod 间网络始终扁平可达

这是 K8s 网络模型最核心的设计决策。传统数据中心网络中，跨主机容器通信通常依赖端口映射或 NAT，而 K8s 选择了扁平网络模型，让每个 Pod 成为网络中平等的一等公民。

2. Node 与 Pod 通信（Node-to-Pod）

Node 上的进程（包括 kubelet、kube-proxy）必须能直接与该 Node 上任何 Pod 通信，同样不经过 NAT。这个要求保证了：

kubelet 可以执行健康检查（liveness/readiness probe）
节点上的监控 agent 能直接采集 Pod 指标
主机网络进程与 Pod 网络互通

3. Service 网络

Service 提供了一个稳定的虚拟 IP（ClusterIP），将流量负载均衡到后端 Pod。Service 网络是独立于 Pod 网络的虚拟地址段（默认 10.96.0.0/12），通过 kube-proxy 维护的 iptables/ipvs 规则实现流量转发。

4. NetworkPolicy 网络策略

K8s 内置的网络策略机制允许管理员定义 Pod 间的网络访问规则，实现微隔离（Microsegmentation）。默认情况下，K8s 允许所有 Pod 间流量，NetworkPolicy 则提供细粒度的白名单控制。

CNI 插件对比

CNI（Container Network Interface）是 CNCF 维护的容器网络标准，K8s 通过 CNI 插件实现 Pod 网络。以下对比三种主流 CNI 插件。

架构对比

特性	Calico	Flannel	Cilium
数据平面	iptables / eBPF	VXLAN / Host-GW	eBPF
网络策略	完整支持	不支持	完整支持 + L7
性能	高	中	极高
BGP 支持	原生支持	不支持	支持
可观测性	中等	弱	强（Hubble）
适用场景	中大规模生产	小规模/入门	大规模/高性能

Flannel：最简方案

Flannel 由 CoreOS 开发，是最早的 K8s CNI 插件之一。它的设计哲学是简单可靠：

# flannel 配置示例 (kube-flannel.yaml)
apiVersion: v1
kind: ConfigMap
metadata:
  name: kube-flannel-cfg
  namespace: kube-flannel
data:
  net-conf.json: |
    {
      "Network": "10.244.0.0/16",
      "Backend": {
        "Type": "vxlan",
        "DirectRouting": true
      }
    }

Flannel 支持 VXLAN 和 Host-GW 两种后端模式。VXLAN 通过 UDP 封装跨主机流量，兼容性好但性能略差；Host-GW 直接修改主机路由表，性能更好但要求二层网络互通。

Calico：生产首选

Calico 是生产环境使用最广泛的 CNI 之一，核心优势在于BGP 路由 + 强大网络策略：

# Calico IPPool 配置
apiVersion: projectcalico.org/v3
kind: IPPool
metadata:
  name: default-ipv4-ippool
spec:
  cidr: 10.244.0.0/16
  ipipMode: CrossSubnet    # 跨子网使用 IPIP 隧道
  vxlanMode: Never          # 不使用 VXLAN
  natOutgoing: true
  nodeSelector: all()

Calico 使用 BGP 协议在 Node 间交换路由信息，每个 Node 是一个 BGP 路由器。这种设计无需封装开销，性能接近原生网络。同时 Calico 提供比 K8s 原生 NetworkPolicy 更丰富的策略能力（GlobalNetworkPolicy、命名空间隔离等）。

Cilium：eBPF 驱动的未来

Cilium 基于 eBPF 技术，在内核态处理网络数据包，避免了 iptables 的规则遍历开销：

# Cilium 安装时启用 kube-proxy 替代
helm install cilium cilium/cilium \
  --namespace kube-system \
  --set kubeProxyReplacement=true \
  --set k8sServiceHost=10.0.0.1 \
  --set k8sServicePort=6443 \
  --set hubble.enabled=true \
  --set hubble.relay.enabled=true

Cilium 的 eBPF 数据平面具有两大核心优势：

性能：eBPF 在内核 socket 层完成负载均衡，无需进入 iptables 规则链
可观测性：Hubble 组件提供实时流量地图和 L7 协议可见性

选型建议

小集群/学习环境：Flannel，配置简单、资源占用低
中大型生产：Calico，BGP 路由 + 完善策略生态
高性能/大规模：Cilium，eBPF 数据平面 + Hubble 可观测性

Service 类型详解

Service 是 K8s 中暴露应用的抽象层，通过 Label Selector 将流量路由到后端 Pod。根据 K8s Service 文档，Service 分为四种类型。

ClusterIP（默认）

ClusterIP 在集群内部暴露服务，分配一个虚拟 IP，仅集群内可访问：

apiVersion: v1
kind: Service
metadata:
  name: web-app
spec:
  type: ClusterIP          # 默认类型
  selector:
    app: web-app
  ports:
  - port: 80               # Service 端口
    targetPort: 8080       # Pod 端口
    protocol: TCP

NodePort

NodePort 在每个 Node 上开放固定端口（默认 30000-32767），外部可通过 NodeIP:NodePort 访问：

apiVersion: v1
kind: Service
metadata:
  name: web-app-nodeport
spec:
  type: NodePort
  selector:
    app: web-app
  ports:
  - port: 80
    targetPort: 8080
    nodePort: 30080        # 指定端口，不指定则随机分配

LoadBalancer

LoadBalancer 类型依赖云厂商的 LB 服务，自动创建外部负载均衡器：

apiVersion: v1
kind: Service
metadata:
  name: web-app-lb
spec:
  type: LoadBalancer
  selector:
    app: web-app
  ports:
  - port: 80
    targetPort: 8080
  externalTrafficPolicy: Local  # 保留客户端源 IP

在非云环境中，可使用 MetalLB 实现 LoadBalancer 类型的裸金属支持。

Headless Service

Headless Service 不分配 ClusterIP，DNS 查询直接返回 Pod IP 列表，适用于 StatefulSet：

apiVersion: v1
kind: Service
metadata:
  name: mysql-headless
spec:
  clusterIP: None          # Headless 标志
  selector:
    app: mysql
  ports:
  - port: 3306

Headless Service 的核心价值在于直接 Pod 寻址，每个 Pod 拥有独立的 DNS 名称（pod-name.service-name.namespace.svc.cluster.local），这是 StatefulSet 稳定网络标识的基础。

Ingress 控制器

Ingress 提供 HTTP/HTTPS 七层路由能力，是集群外部流量入口的核心组件。

NGINX Ingress Controller

NGINX Ingress 是最广泛使用的 Ingress 控制器，基于 NGINX 反向代理：

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: web-ingress
  annotations:
    nginx.ingress.kubernetes.io/ssl-redirect: "true"
    nginx.ingress.kubernetes.io/proxy-body-size: "100m"
    nginx.ingress.kubernetes.io/rate-limit: "100"
spec:
  ingressClassName: nginx
  tls:
  - hosts: ["api.sre.wang"]
    secretName: tls-secret
  rules:
  - host: api.sre.wang
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: web-app
            port:
              number: 80

Traefik

Traefik 是云原生的 Ingress 控制器，支持自动服务发现和动态配置：

apiVersion: traefik.containo.us/v1alpha1
kind: IngressRoute
metadata:
  name: web-ingress
spec:
  entryPoints:
  - websecure
  routes:
  - match: Host(`api.sre.wang`)
    kind: Rule
    services:
    - name: web-app
      port: 80
  tls:
    certResolver: letsencrypt

选型对比

特性	NGINX Ingress	Traefik
性能	高（NGINX C）	中高（Go）
配置方式	注解	CRD（更灵活）
动态加载	需 reload	热加载
Middleware	注解配置	CRD 定义
社区生态	最大	活跃
适用场景	传统 HTTP 服务	云原生/微服务

NetworkPolicy 网络策略

默认情况下，K8s 中所有 Pod 间网络流量都是开放的。NetworkPolicy 提供基于 Label 的细粒度访问控制。

命名空间隔离策略

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-ingress
  namespace: production
spec:
  podSelector: {}            # 匹配命名空间所有 Pod
  policyTypes:
  - Ingress
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          name: ingress-nginx  # 仅允许 ingress-nginx 命名空间访问

应用级策略

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: backend-access-policy
  namespace: production
spec:
  podSelector:
    matchLabels:
      app: backend            # 策略目标：backend Pod
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: frontend       # 仅允许 frontend Pod 访问
    - podSelector:
        matchLabels:
          app: monitoring      # 允许监控组件访问
    ports:
    - protocol: TCP
      port: 8080

关键注意事项

NetworkPolicy 是白名单模型：一旦 Pod 被策略选中，只有明确允许的流量才能通过
策略是叠加生效的：多个策略同时选中同一 Pod 时，取并集
NetworkPolicy 需要支持它的 CNI 插件才能生效，Flannel 默认不支持

总结

K8s 网络是一个分层体系：CNI 负责 Pod 网络连通性，Service 提供服务发现和负载均衡，Ingress 管理七层入口，NetworkPolicy 实现安全隔离。理解每一层的职责和选型依据，是构建可靠容器网络的基础。

生产环境推荐组合：Calico 或 Cilium（CNI）+ NGINX Ingress（七层入口）+ NetworkPolicy（安全隔离）。对于追求极致性能和可观测性的团队，Cilium + Hubble 是当前最佳选择。

参考资料与致谢

本文在撰写过程中参考了以下资料，感谢原作者的贡献：

Kubernetes 官方网络模型文档 — Kubernetes 官方，参考了Kubernetes 官方网络模型文档相关内容
Calico — Docs，参考了Calico相关内容
Cilium — Docs，参考了Cilium相关内容
K8s Service 文档 — Kubernetes 官方，参考了K8s Service 文档相关内容
MetalLB — Metallb，参考了MetalLB相关内容
NGINX Ingress — Kubernetes SIG，参考了NGINX Ingress相关内容
Traefik — Doc，参考了Traefik相关内容

Kubernetes 网络模型四大要求#

1. Pod 间通信（Pod-to-Pod）#

2. Node 与 Pod 通信（Node-to-Pod）#

3. Service 网络#

4. NetworkPolicy 网络策略#

CNI 插件对比#

架构对比#

Flannel：最简方案#

Calico：生产首选#

Cilium：eBPF 驱动的未来#

选型建议#

Service 类型详解#

ClusterIP（默认）#

NodePort#

LoadBalancer#

Headless Service#

Ingress 控制器#

NGINX Ingress Controller#

Traefik#

选型对比#

NetworkPolicy 网络策略#

命名空间隔离策略#

应用级策略#

关键注意事项#

总结#

参考资料与致谢#