3. Kubernetes 网络模型:Pod网络、Service网络、Ingress与网络策略

Kubernetes 网络模型是容器编排的基石,它定义了集群内所有组件如何通信。理解 Pod 网络、Service 网络、Ingress 以及网络策略,是进行容器网络运维和蓝绿发布流量切换的前提。本章将深入剖析这四层网络模型的核心原理与配置实践。

3.1 Pod 网络:扁平化与 IP 唯一性

Kubernetes 对 Pod 网络提出了三个核心要求,这也是所有 CNI(容器网络接口)插件必须遵循的规范:

  • 每个 Pod 拥有独立的 IP 地址:集群内的所有 Pod 都在一个扁平的、无 NAT(网络地址转换)的共享网络地址空间中。
  • Pod 之间可以直接通信:无需显式配置路由或端口映射,Pod 可以通过对方的 IP 直接访问。
  • Node 与 Pod 之间可以直接通信:宿主机节点可以直接访问集群内的任意 Pod。

这种模型消除了传统 Docker 网络中的端口映射和地址转换开销,极大地简化了应用架构。常见的 CNI 插件包括 Calico、Flannel、Cilium 等,它们通过 Overlay 隧道(如 VXLAN)或纯三层路由(如 BGP)来实现跨节点的 Pod 通信。

运维提示: 在蓝绿发布场景中,新版本 Pod 启动后,其 IP 地址会立即被集群内的其他服务(如 Service)感知。CNI 插件的性能直接影响 Pod 启动速度和流量切换的 RTO(恢复时间目标)。
Pod 网络扁平化通信模型 Pod 网络扁平化通信模型 Node 1 (10.0.1.0/24) Pod A IP: 10.0.1.2 Pod B IP: 10.0.1.3 直接通信 Node 2 (10.0.2.0/24) Pod C IP: 10.0.2.2 跨节点通信 (VXLAN/BGP) 核心原则:每个 Pod 拥有唯一 IP,Pod 间可直接通信,无需 NAT

3.2 Service 网络:稳定的访问入口

Pod 是动态的,会因扩缩容、故障重启等原因导致 IP 地址变化。Service 为后端 Pod 提供了一个稳定的虚拟 IP(ClusterIP)和 DNS 名称,实现了服务发现与负载均衡。

Service 的核心机制是 kube-proxy,它通过 iptables、IPVS 或 eBPF 等模式,在集群的每个节点上维护转发规则,将发往 Service IP 的流量负载均衡到后端的 Pod 集合。

Service 类型 访问范围 典型应用场景
ClusterIP 集群内部 微服务间内部调用,默认类型
NodePort 集群外部 开发调试、非生产环境对外暴露
LoadBalancer 集群外部 云环境生产流量接入
ExternalName 集群外部 将集群外服务映射为集群内 DNS
蓝绿发布关键点: 在蓝绿发布中,通常通过修改 Service 的 selector 字段,将流量从旧版本 Pod(蓝)瞬间切换到新版本 Pod(绿)。这个操作是原子性的,且无需重建 Service。

3.3 Ingress:七层流量路由与域名管理

Service 工作在四层(TCP/UDP),而 Ingress 工作在七层(HTTP/HTTPS),提供了基于域名、URL 路径的精细化流量路由能力。Ingress 是集群流量的统一入口,通常与 Ingress Controller(如 Nginx、Traefik、HAProxy)配合使用。

一个典型的 Ingress 资源定义如下:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-app-ingress
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  ingressClassName: nginx
  rules:
  - host: app.example.com
    http:
      paths:
      - path: /api
        pathType: Prefix
        backend:
          service:
            name: api-service
            port:
              number: 80
      - path: /web
        pathType: Prefix
        backend:
          service:
            name: web-service
            port:
              number: 80

在蓝绿发布中,Ingress 可以配合 金丝雀发布 或 流量权重 注解(如 nginx.ingress.kubernetes.io/canary-weight),实现灰度流量切换,逐步将一定比例的流量导向新版本,降低发布风险。

Ingress 七层流量路由架构 Ingress 七层流量路由架构 用户 Ingress Controller (Nginx / Traefik) 路由规则:app.example.com/api -> api-service:80 | app.example.com/web -> web-service:80 api-service ClusterIP: 10.0.0.10 web-service ClusterIP: 10.0.0.20 Pod Pod Pod Pod

3.4 网络策略:零信任安全模型

默认情况下,Kubernetes 集群内的所有 Pod 可以自由通信。网络策略(NetworkPolicy)是一种以应用为中心的安全机制,用于控制 Pod 组之间的流量访问,实现微隔离。

网络策略通过标签选择器来定义哪些 Pod 可以访问目标 Pod,以及允许访问哪些端口。它分为 入站(Ingress) 和 出站(Egress) 规则。

注意: 网络策略需要 CNI 插件的支持(如 Calico、Cilium)。如果使用 Flannel 且未启用网络策略支持,定义的 NetworkPolicy 将不会生效。

以下是一个典型的网络策略示例,它只允许前端 Pod 访问后端 Pod 的 8080 端口:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: backend-allow-frontend
spec:
  podSelector:
    matchLabels:
      app: backend
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: frontend
    ports:
    - protocol: TCP
      port: 8080

在蓝绿发布中,网络策略可以确保新版本 Pod 在正式接入流量前,只有测试或监控组件可以访问,从而避免未经授权的流量进入,保障发布过程的安全性。

3.5 四层网络模型总结

下表总结了 Kubernetes 四层网络模型的核心职责与运维关注点:

网络层 核心职责 运维关注点
Pod 网络 提供扁平化、IP 唯一的通信平面 CNI 插件性能、IP 地址规划、跨节点通信延迟
Service 网络 提供稳定的虚拟 IP 和负载均衡 kube-proxy 模式选择、会话保持、端点更新延迟
Ingress 七层流量路由、域名管理、TLS 终止 Ingress Controller 高可用、金丝雀权重、证书管理
网络策略 实现微隔离与零信任安全 策略粒度、CNI 兼容性、审计与监控