2. K8s核心概念回顾：Deployment、Service、Ingress、Namespace在发布中的作用

在深入蓝绿发布与灾备自动化故障切换之前，必须厘清 Kubernetes 中四个核心资源在发布流程中的职责。它们共同构成了流量接入、副本管理、环境隔离与路由控制的基础设施。

2.1 四类资源的职责矩阵

2.2 Deployment：版本管理的执行者

Deployment 是发布动作的直接载体。在蓝绿发布中，我们同时维护两个 Deployment：app-blue 和 app-green，各自携带不同的标签（如 version: blue 与 version: green）。

• 副本集（ReplicaSet）：每个 Deployment 对应一个 ReplicaSet，控制 Pod 数量与镜像版本。
• 更新策略：蓝绿发布不使用默认的 RollingUpdate，而是手动切换 Service 的 Selector。
• 回滚能力：保留历史版本记录，通过 kubectl rollout undo 快速恢复。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: app-blue
  labels:
    app: myapp
    version: blue
spec:
  replicas: 5
  selector:
    matchLabels:
      app: myapp
      version: blue
  template:
    metadata:
      labels:
        app: myapp
        version: blue
    spec:
      containers:
      - name: app
        image: myapp:1.0.0
        ports:
        - containerPort: 8080

2.3 Service：流量切换的枢纽

Service 是蓝绿发布中流量切换的核心操作点。通过修改 Service 的 spec.selector，可以将流量瞬间从蓝版本 Pod 全部导向绿版本 Pod。

• ClusterIP 模式：内部服务间调用通过 Service DNS 完成切换。
• NodePort / LoadBalancer：外部流量入口，切换后即时生效。
• 无感切换：由于 Service 是四层转发，Pod IP 变化对客户端透明。

2.4 Ingress：七层精细化路由

Ingress 在蓝绿发布中承担更灵活的流量分配能力，尤其适用于金丝雀发布或按比例灰度场景。

• 权重路由：通过多个 Ingress 规则或 Service 权重，将 10% 流量导向绿版本。
• Header 路由：根据请求 Header（如 X-Canary: true）将特定用户导向新版本。
• 域名隔离：蓝绿版本分别绑定不同域名，用于预发布验证。

2.5 Namespace：环境隔离的边界

Namespace 在灾备与多环境发布中提供逻辑隔离。典型用法包括：

• 环境隔离：prod-blue、prod-green 两个 Namespace 分别部署完整蓝绿栈。
• 灾备隔离：主集群与灾备集群使用不同 Namespace 前缀，避免资源名冲突。
• 资源配额：通过 ResourceQuota 限制每个 Namespace 的 CPU/内存，防止灾备切换时资源争抢。

2.6 四者协作关系图

下图展示了蓝绿发布中 Deployment、Service、Ingress、Namespace 的协作流程：

2.7 发布切换流程总结

1. 部署绿版本：在相同 Namespace 下创建 app-green Deployment，镜像为 v2.0，副本数对齐蓝版本。
2. 验证就绪：确认绿版本所有 Pod 通过 Readiness Probe，Service 后端端点正常。
3. 切换 Service：修改 Service 的 selector 从 version: blue 改为 version: green，流量瞬间切换。
4. Ingress 配合：如需灰度，Ingress 按权重或 Header 将部分流量导向绿 Service。
5. 观察与回滚：监控错误率与延迟，异常时立即将 Service selector 切回蓝版本。
6. 清理旧版本：确认稳定后，删除蓝版本 Deployment 释放资源。