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 在关键节点的作用位置。
3.5 流量路径关键步骤详解
- DNS 解析:客户端请求域名(如
myapp.example.com),DNS 返回 Ingress Controller 的公网 IP 或 LoadBalancer IP。 - Ingress 路由:Ingress Controller 根据请求的 Host 和 Path,匹配 Ingress 资源规则,将请求转发到对应的 Service ClusterIP。
- Service 负载均衡:kube-proxy 通过 iptables 或 IPVS 规则,将请求 DNAT(目标网络地址转换)到后端 Pod 的 IP 和端口。
- NetworkPolicy 过滤:在 Pod 的网络命名空间入口处,内核 netfilter 检查入站流量是否匹配 NetworkPolicy 规则,不匹配则丢弃。
- 健康检查拦截: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 配置问题。