📚 课程目录第3章 Kubernetes核心概念

3. Kubernetes 核心概念：Deployment、Service、Ingress、Namespace 在蓝绿发布中的作用

蓝绿发布的核心在于流量瞬时切换与版本快速回滚。Kubernetes 的四个核心抽象——Deployment、Service、Ingress、Namespace——分别承担了副本管理、流量分发、外部接入和环境隔离的关键职责。理解它们之间的协作关系，是构建自动化回滚与 CNI 防护验证的基础。

3.1 四者职责与蓝绿映射

K8s 资源	API 版本（稳定）	蓝绿发布中的核心职责	回滚关键属性
Deployment	apps/v1	管理 Pod 副本集，支持蓝/绿两套独立版本	`.spec.revisionHistoryLimit`、`rollback-to`
Service	v1	通过 `selector` 将流量定向到蓝或绿版本	`selector` 标签切换
Ingress	networking.k8s.io/v1	提供七层路由，实现灰度权重或全量切换	后端 Service 名称变更
Namespace	v1	逻辑隔离蓝绿环境，避免资源冲突	命名空间级网络策略

关键认知：蓝绿发布不是 Deployment 的滚动更新（RollingUpdate），而是两套完整 Deployment 并存，通过 Service/Ingress 的标签选择器做瞬时切换。回滚时只需将 Service 的 selector 指回旧版本，无需重新部署。

3.2 Deployment：双版本副本集管理

在蓝绿发布中，蓝色（Blue）和绿色（Green）各对应一个独立的 Deployment。两个 Deployment 的 spec.selector.matchLabels 必须不同，以避免资源冲突。

# blue-deployment.yaml
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
---
# green-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: app-green
  labels:
    app: myapp
    version: green
spec:
  replicas: 5
  selector:
    matchLabels:
      app: myapp
      version: green
  template:
    metadata:
      labels:
        app: myapp
        version: green
    spec:
      containers:
      - name: app
        image: myapp:2.0.0
        ports:
        - containerPort: 8080

回滚要点：Deployment 的 .spec.revisionHistoryLimit 默认保留 10 个历史版本。蓝绿场景下，建议保留至少 2 个版本（蓝+绿），以便快速 kubectl rollout undo。但更推荐通过 Service 切换实现秒级回滚，而非重建 Deployment。

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

Service 是蓝绿发布中最核心的流量控制点。通过修改 spec.selector 中的标签，可以在不重启 Pod 的情况下，将流量从蓝色版本瞬间切换到绿色版本（或反向回滚）。

# service.yaml — 初始指向蓝色版本
apiVersion: v1
kind: Service
metadata:
  name: app-service
spec:
  selector:
    app: myapp
    version: blue    # 切换时只需将 blue 改为 green
  ports:
  - protocol: TCP
    port: 80
    targetPort: 8080

切换命令（秒级生效）：

kubectl patch service app-service -p '{"spec":{"selector":{"version":"green"}}}'

避坑：Service 的 selector 变更后，已有长连接不会立即断开。如果应用依赖 WebSocket 或 gRPC 长连接，需要配合 preStop 钩子或 terminationGracePeriodSeconds 优雅排空旧连接。CNI 防护验证中，我们会用 NetworkPolicy 强制阻断旧版本入流量，确保连接排空。

3.4 Ingress：七层路由与灰度权重

Ingress 在蓝绿发布中提供更精细的流量控制能力：

全量切换：修改 Ingress 的 backend.service.name，指向新版本 Service。
灰度发布：通过 nginx.ingress.kubernetes.io/canary 注解，实现 10%、50% 等权重灰度。
Header 路由：基于 canary-by-header 将特定用户（如内部测试人员）导向绿色版本。

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

回滚场景：当 Ingress 灰度发现异常时，只需将 canary-weight 设为 0 或删除 canary Ingress 资源，流量立即全部回到蓝色版本。整个过程无需重建 Pod，是网络自动化回滚的典型实现。

3.5 Namespace：环境隔离与网络策略边界

Namespace 在蓝绿发布中提供逻辑隔离，避免两套版本的服务名、ConfigMap、Secret 冲突。推荐两种模式：

模式	Namespace 设计	适用场景	CNI 防护要点
同 Namespace	蓝绿 Deployment 共存于 `production`	小规模、快速切换	NetworkPolicy 隔离不同版本 Pod
异 Namespace	蓝色在 `prod-blue`，绿色在 `prod-green`	大规模、严格隔离	跨 Namespace 网络策略 + 服务发现控制

CNI 防护验证关联：在异 Namespace 模式下，CNI 插件（如 Calico、Cilium）可以通过 NetworkPolicy 实现微隔离——只允许 Ingress/Service 所在 Namespace 访问绿色版本，阻断其他来源。这是自动化回滚中“切断旧版本流量”的关键手段。

3.6 四者协作流程（SVG 架构图）

下图展示了蓝绿发布中 Deployment、Service、Ingress、Namespace 的完整协作关系：

3.7 自动化回滚中的资源操作清单

当 CNI 防护验证检测到异常（如新版本 Pod 网络连通性失败、延迟飙升），自动化回滚按以下顺序执行：

Ingress 灰度归零：删除 canary Ingress 或设置 weight=0，停止新流量进入绿色版本。
Service 切换回蓝色：kubectl patch service app-service -p '{"spec":{"selector":{"version":"blue"}}}'。
NetworkPolicy 阻断绿色：应用 NetworkPolicy 拒绝所有入站流量到 version=green 的 Pod。
绿色 Deployment 缩容（可选）：将 app-green 的 replicas 设为 0，释放资源。

验证要点：回滚后必须验证 Service 的 Endpoints 列表中只包含蓝色 Pod 的 IP，且 Ingress 后端 Service 的 spec.selector 已正确指向蓝色版本。CNI 防护验证会持续监控 NetworkPolicy 是否生效，确保绿色 Pod 被完全隔离。