📚 课程目录第3章 K8s集群基础架构

3. K8s核心资源适配：Service、Ingress、Deployment在蓝绿发布中的角色

蓝绿发布在Kubernetes中的落地，本质上是利用原生资源对象对流量和副本进行精细化管理。Service负责流量切换，Ingress负责外部网关路由，Deployment负责副本组管理与版本回滚。三者协同工作，才能实现零停机、可观测、可回滚的蓝绿发布流程。

3.1 资源角色总览

K8s资源	蓝绿发布中的核心职责	关键字段/机制	回滚影响
Service	流量切换：通过selector标签在蓝/绿两组Pod间切换	`spec.selector`、`spec.ports`	修改selector即可瞬间切回旧版本，无需重建资源
Ingress	外部流量路由：按权重或路径分发至不同Service	`spec.rules`、`spec.defaultBackend`	支持灰度权重回滚，通过调整backend权重实现
Deployment	副本组管理：维护蓝/绿两套独立版本的工作负载	`spec.replicas`、`spec.template`、`revisionHistoryLimit`	利用`kubectl rollout undo`快速回退至历史版本

设计原则：蓝绿发布中，Service和Ingress负责“流量面”，Deployment负责“数据面”。流量面应保持轻量、可快速切换；数据面应保留历史版本，支持快速回滚。

3.2 Service：流量切换的“开关”

Service通过标签选择器（selector）将流量路由至后端Pod。在蓝绿发布中，通常维护两个Deployment（blue和green），Service的selector指向当前活跃版本。

3.2.1 切换流程

初始状态：Service selector指向 version: blue，所有流量进入蓝环境。
发布新版本：创建green Deployment，Pod标签为 version: green。
验证：通过内部ClusterIP或临时Service验证green版本健康。
切换：修改Service selector为 version: green，流量瞬间切换。
回滚：将selector改回 version: blue，流量立即切回旧版本。

# 切换前：Service指向蓝版本
apiVersion: v1
kind: Service
metadata:
  name: my-app-svc
spec:
  selector:
    app: my-app
    version: blue    # 当前活跃版本
  ports:
    - port: 80
      targetPort: 8080

# 切换后：修改selector为绿版本
# kubectl patch svc my-app-svc -p '{"spec":{"selector":{"version":"green"}}}'

  关键指标：Service切换时间通常在毫秒级，但需注意kube-proxy的iptables/ipvs规则同步延迟（通常<1s）。建议在切换前预热新Pod的连接池。

3.3 Ingress：外部流量的“智能网关”

Ingress提供七层路由能力，支持基于权重、Header、Cookie的流量分发。在蓝绿发布中，Ingress可用于灰度发布和渐进式切换。

3.3.1 权重路由模式

通过Ingress Controller（如Nginx、Traefik）的annotation实现蓝绿权重分配，适合金丝雀发布场景。

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-app-ingress
  annotations:
    nginx.ingress.kubernetes.io/canary: "true"
    nginx.ingress.kubernetes.io/canary-weight: "10"  # 10%流量到绿版本
spec:
  rules:
    - host: app.example.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: my-app-svc-green  # 绿版本Service
                port:
                  number: 80

3.3.2 全量切换与回滚

全量切换：移除canary annotation，将主Ingress的backend指向绿版本Service。
回滚：将主Ingress的backend改回蓝版本Service，或调整canary-weight为0。

注意：Ingress Controller的配置热更新可能有秒级延迟。在自动化回滚脚本中，应等待Ingress状态同步后再进行健康检查，避免误判。

3.4 Deployment：版本副本的“容器组”

Deployment负责管理Pod副本的声明式更新和回滚。在蓝绿发布中，需要同时维护两个Deployment对象，分别对应蓝版本和绿版本。

3.4.1 版本管理策略

策略	描述	适用场景
双Deployment并行	蓝、绿各一个Deployment，独立管理replicas和版本	标准蓝绿发布，版本隔离性强
单Deployment + revision	利用Deployment的revisionHistory，通过rollout切换	快速回滚，但蓝绿同时运行需额外处理
StatefulSet + 分区	对有状态服务，通过分区滚动更新实现蓝绿	数据库、缓存等有状态服务

3.4.2 回滚操作示例

# 查看Deployment历史版本
kubectl rollout history deployment/my-app-blue

# 回滚到上一个版本
kubectl rollout undo deployment/my-app-blue

# 回滚到指定版本
kubectl rollout undo deployment/my-app-blue --to-revision=3

# 暂停rollout（用于蓝绿验证）
kubectl rollout pause deployment/my-app-green

最佳实践：设置 spec.revisionHistoryLimit: 10 保留最近10个版本。蓝绿发布中，建议保留至少2个完整版本的Deployment YAML，以便在极端情况下手动重建。

3.5 三资源协同流程（SVG架构图）

3.6 适配清单与避坑指南

资源	必须配置项	常见问题	解决方案
Service	明确的selector标签、sessionAffinity（如需保持会话）	切换后连接中断（长连接场景）	使用Headless Service + 客户端重连机制
Ingress	canary annotation、健康检查路径	权重切换后流量倾斜不均	确保Ingress Controller版本支持一致性哈希
Deployment	revisionHistoryLimit、progressDeadlineSeconds	回滚时Pod启动慢导致服务降级	设置合理的readinessProbe和initialDelaySeconds

  自动化回滚触发条件：当Service切换后，监控系统检测到5xx错误率超过1%或P99延迟上升50%时，自动化脚本应执行：

将Service selector恢复至旧版本标签。

将Ingress权重恢复至旧版本100%。

触发Deployment回滚至上一revision。

发送告警通知并记录回滚事件。

3.7 三资源状态转换图（SVG状态机）

3.8 总结：三资源适配要点

Service 是流量切换的核心，修改selector即可实现秒级切换和回滚。
Ingress 提供灰度权重和外部路由能力，适合渐进式发布。
Deployment 负责版本副本管理，保留历史revision支持快速回滚。
三资源需配合健康检查、监控指标和自动化脚本，才能形成完整的蓝绿发布闭环。