3. Kubernetes 网络模型:Service、Ingress、NetworkPolicy 核心概念与流量路径

在蓝绿发布场景中,流量切换的可靠性直接取决于对 Kubernetes 网络模型的掌握深度。本章聚焦三大核心网络抽象——Service、Ingress 与 NetworkPolicy,并剖析从集群外到 Pod 的完整流量路径。理解这些概念是后续自动化排查网络故障的基础。

3.1 Service:稳定的访问入口与负载均衡

Pod 具有 ephemeral(临时)特性,IP 地址随生命周期变化。Service 通过标签选择器(Label Selector)绑定一组 Pod,提供稳定的虚拟 IP(ClusterIP)和 DNS 名称,实现请求的负载均衡与自动分发。

Service 类型 访问范围 典型用途 蓝绿发布中的角色
ClusterIP 集群内部 微服务间调用 蓝/绿 Service 分别指向不同版本 Pod
NodePort 集群外部(节点端口) 开发测试环境暴露服务 临时验证新版本
LoadBalancer 集群外部(云 LB) 生产环境对外暴露 结合 Ingress 做流量切换
ExternalName 集群外部(DNS CNAME) 引入外部服务 不直接参与蓝绿切换
排查要点:蓝绿发布故障常因 Service 的 selector 未匹配新版本 Pod 的 label 导致。使用 kubectl get endpoints <service-name> 检查 Endpoints 是否包含目标 Pod IP,是第一步诊断动作。

3.2 Ingress:集群入口网关与流量路由

Ingress 是 Kubernetes 的七层(HTTP/HTTPS)入口网关,负责将外部请求按域名、路径规则路由到集群内部的 Service。在蓝绿发布中,Ingress 常作为流量切分的“总开关”,通过修改后端 Service 引用实现平滑切换。

  • Ingress Controller:实际处理流量的组件(如 Nginx、Traefik、ALB),Ingress 资源只是配置规则。
  • 路由规则:基于 host(域名)和 path(路径)将请求分发到不同 Service。
  • 蓝绿切换方式:修改 Ingress 规则中的 backend.service.name,从 app-blue 切换为 app-green。
流量切换示例(Ingress 规则片段):
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: app-ingress
spec:
  rules:
  - host: myapp.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: app-green   # 切换时改为 app-blue
            port:
              number: 80

3.3 NetworkPolicy:微隔离与流量控制

NetworkPolicy 是 Kubernetes 原生的网络访问控制策略,基于标签选择器定义 Pod 之间、Pod 与外部之间的流量规则。在蓝绿发布中,错误的 NetworkPolicy 可能导致新版本 Pod 无法被 Service 健康检查探测,或无法访问依赖的后端服务。

策略方向 核心字段 常见故障场景
Ingress(入站) from + ports 新版本 Pod 未放通 Ingress Controller 的 IP 段,导致外部无法访问
Egress(出站) to + ports 新版本 Pod 无法访问数据库或配置中心,引发启动失败
默认拒绝 未匹配任何策略则拒绝 蓝绿发布后,新 Pod 因缺少显式放通策略而完全隔离
避坑指南:NetworkPolicy 是“白名单”机制,一旦在命名空间内创建任何 NetworkPolicy,未显式放通的流量都会被拒绝。蓝绿发布前,务必检查新版本 Pod 的标签是否被现有策略覆盖,否则会导致 readinessProbe 失败,Pod 无法进入 Ready 状态。

3.4 流量路径全景:从外部请求到 Pod

下图展示了蓝绿发布场景下,一次外部 HTTP 请求经过 Ingress → Service → Pod 的完整流量路径,以及 NetworkPolicy 在关键节点的作用位置。

蓝绿发布流量路径全景图 外部用户 DNS 解析 Ingress Controller Service (ClusterIP) NetworkPolicy (入站规则检查) 蓝版本 Pod (v1) label: version=blue 绿版本 Pod (v2) label: version=green kube-proxy (iptables/IPVS 转发) readinessProbe (健康检查探测) 图例说明: Ingress(入口网关) Service(服务抽象) NetworkPolicy(策略检查点) Pod(工作负载)

3.5 流量路径关键步骤详解

  1. DNS 解析:客户端请求域名(如 myapp.example.com),DNS 返回 Ingress Controller 的公网 IP 或 LoadBalancer IP。
  2. Ingress 路由:Ingress Controller 根据请求的 Host 和 Path,匹配 Ingress 资源规则,将请求转发到对应的 Service ClusterIP。
  3. Service 负载均衡:kube-proxy 通过 iptables 或 IPVS 规则,将请求 DNAT(目标网络地址转换)到后端 Pod 的 IP 和端口。
  4. NetworkPolicy 过滤:在 Pod 的网络命名空间入口处,内核 netfilter 检查入站流量是否匹配 NetworkPolicy 规则,不匹配则丢弃。
  5. 健康检查拦截:kubelet 定期执行 readinessProbe,若探测路径被 NetworkPolicy 拒绝,Pod 标记为 NotReady,Service 将其从 Endpoints 中移除。
故障排查命令速查表:
# 检查 Service 后端是否就绪
kubectl get endpoints <service-name>

# 查看 Ingress 规则详情
kubectl describe ingress <ingress-name>

# 查看 NetworkPolicy 规则
kubectl get networkpolicy -n <namespace>

# 模拟 Pod 网络连通性(需在 Pod 内执行)
kubectl exec -it <pod-name> -- curl -v http://<target-service>

# 查看 kube-proxy 转发规则(在节点上执行)
iptables -t nat -L KUBE-SERVICES -n

3.6 蓝绿发布网络故障典型场景

故障现象 可能原因 排查方向
新版本 Pod 无法接收流量 Service selector 未匹配新 Pod label 检查 kubectl get pods --show-labels 与 Service selector 是否一致
Ingress 切换后 502/503 新版本 Pod readinessProbe 失败 检查 Pod 日志与 NetworkPolicy 是否放通探测端口
部分用户仍访问旧版本 DNS 缓存或 Ingress Controller 会话保持 检查 Ingress annotation 中的 session-affinity 配置
新 Pod 无法连接数据库 NetworkPolicy Egress 规则未放通 查看 NetworkPolicy 的 to 字段是否包含数据库 CIDR 或标签
自动化排查思路:在流水线中集成网络验证步骤——部署新版本后,自动执行 kubectl run tmp-shell --image=busybox --rm -it -- wget -O- http://app-green:80/health,若返回非 200 则触发告警并回滚。此步骤可提前暴露 NetworkPolicy 或 Service 配置问题。