2. Kubernetes 核心概念回顾：Pod、Service、Deployment、Ingress 与网络策略

在深入蓝绿发布与 CNI 网络故障恢复之前，必须对齐 Kubernetes 最核心的五个抽象层。这些概念构成了容器编排的骨架，也是后续自动化脚本与故障注入的目标对象。本节以“声明式期望状态”为线索，逐一拆解每个资源的作用域、生命周期与网络交互方式。

2.1 Pod：最小调度单元与网络边界

Pod 是 Kubernetes 中可创建和部署的最小计算单元，一个 Pod 封装一个或多个容器、共享存储（Volume）和唯一的网络命名空间（IP 地址、端口空间）。

• 网络模型：每个 Pod 拥有一个集群内唯一的 IP 地址（Cluster IP），Pod 内的容器通过 localhost 通信。
• 生命周期：Pod 是临时性的，其 IP 地址在重启或重建后会变化。因此上层 Service 必须通过标签选择器动态绑定 Pod。
• 就绪探针（Readiness Probe）：决定 Pod 是否加入 Service 的端点列表，是蓝绿发布中流量切换的关键控制点。

2.2 Service：稳定的网络入口与负载均衡

Service 为一组功能相同的 Pod 提供稳定的虚拟 IP（ClusterIP）和 DNS 名称，并将请求负载均衡到后端的 Pod 端点。

在蓝绿发布场景中，Service 的 selector 字段是流量切换的“开关”。通过更新 selector 指向新版本 Pod 的标签，即可实现零中断的流量迁移。

2.3 Deployment：声明式更新与回滚引擎

Deployment 管理 ReplicaSet，进而控制 Pod 的副本数量与更新策略。它提供了滚动更新、蓝绿发布、金丝雀发布等高级发布模式的基础能力。

• 更新策略：RollingUpdate（默认）与 Recreate。蓝绿发布通常将 Deployment 的更新策略设为 Recreate 或直接创建新 Deployment 来隔离两套环境。
• 就绪门控：Deployment 在更新时会等待新 Pod 通过就绪探针后，才终止旧 Pod。CNI 故障会导致新 Pod 就绪失败，从而阻塞整个发布流程。
• 回滚：通过 kubectl rollout undo 快速恢复到上一个 Revision，是故障恢复的兜底手段。

2.4 Ingress：七层路由与流量治理

Ingress 是 Kubernetes 的七层（HTTP/HTTPS）流量入口，负责将外部请求根据 Host、Path 规则路由到集群内部的 Service。它通常由 Ingress Controller（如 Nginx、Traefik）实现。

• 与 Service 的关系：Ingress 不直接连接 Pod，而是将流量转发到 Service 的 ClusterIP，再由 Service 分发到 Pod。
• 蓝绿发布中的应用：通过 Ingress 的 canary 注解（如 Nginx Ingress），可以实现基于权重或 Header 的金丝雀流量分发，作为蓝绿发布的补充验证手段。
• 故障影响：CNI 网络故障可能导致 Ingress Controller 无法访问后端 Pod，表现为 502/503 错误。自动化恢复需要检测 Ingress 的 upstream 健康状态。

2.5 网络策略（NetworkPolicy）：微隔离与故障域

NetworkPolicy 是 Kubernetes 原生的防火墙规则，通过标签选择器定义 Pod 之间、Pod 与外部端点之间的流量规则。它是 CNI 插件（如 Calico、Cilium）实现网络隔离的核心机制。

• 默认行为：未定义 NetworkPolicy 时，所有 Pod 可以互相通信（全通）。一旦应用了 NetworkPolicy，未显式允许的流量将被拒绝。
• 策略类型：Ingress（入站规则）和 Egress（出站规则）。
• 与蓝绿发布的关系：在蓝绿发布期间，新旧两套 Pod 可能同时运行。错误的 NetworkPolicy 可能阻断 Service 对新 Pod 的健康检查流量，导致发布失败。自动化恢复脚本需要具备临时放宽或诊断 NetworkPolicy 的能力。

2.6 核心概念关系总结