2. Kubernetes 基础回顾：Pod、Deployment、Service、Ingress 核心资源，命名空间与标签选择器在发布中的作用
在深入 Velero 蓝绿发布与灾备切换之前，必须重新校准对 Kubernetes 核心资源模型的理解。本章聚焦于与发布流程直接相关的四个资源（Pod、Deployment、Service、Ingress），以及两个关键逻辑隔离机制（命名空间与标签选择器）。这些概念是后续构建回滚策略和故障切换脚本的基石。
2.1 核心工作负载与网络资源
2.1.1 Pod：最小调度单元
Pod 是 Kubernetes 中可创建和部署的最小计算单元。一个 Pod 可以包含一个或多个容器（通常为一个主容器加若干 sidecar）。在发布场景中，Pod 是蓝绿版本流量的最终承载者。
- 生命周期短暂：Pod 本身不提供自愈能力，其创建、销毁、重建由上层控制器（如 Deployment）管理。
- IP 不固定：Pod 重启或迁移后 IP 会变化，因此不能直接通过 Pod IP 对外暴露服务。
- 就绪探针（Readiness Probe）：决定 Pod 是否加入 Service 的端点列表，是蓝绿发布中流量切换的关键控制点。
2.1.2 Deployment：声明式更新与回滚引擎
Deployment 是 Kubernetes 中最常用的无状态工作负载控制器。它通过 ReplicaSet 管理 Pod 的副本数，并提供声明式更新、滚动更新和回滚能力。
| 特性 | 说明 | 发布中的用途 |
|---|---|---|
| 滚动更新（RollingUpdate） | 逐步替换旧版本 Pod，支持 maxSurge 和 maxUnavailable 参数 | 灰度发布、金丝雀发布 |
| 回滚（Rollback） | 通过 revisionHistoryLimit 保留历史版本，使用 kubectl rollout undo 快速回退 |
快速恢复至上一稳定版本 |
| 版本记录 | 每次更新 spec.template 都会生成新的 ReplicaSet 版本 | 配合 Velero 做版本级灾备恢复 |
spec.replicas 和 spec.strategy.rollingUpdate.maxSurge 决定了蓝绿两套环境同时运行的 Pod 数量上限，直接影响资源预留和成本。
2.1.3 Service：稳定的流量入口与负载均衡
Service 为一组功能相同的 Pod 提供稳定的虚拟 IP（ClusterIP）和 DNS 名称。它通过标签选择器（Selector）动态关联后端 Pod。
- ClusterIP：集群内部访问，用于微服务间调用。
- NodePort：在每个节点上开放端口，外部可通过节点 IP 访问。
- LoadBalancer：对接云厂商负载均衡器，提供公网入口。
在蓝绿发布中，Service 的 Selector 是流量切换的“开关”。通过修改 Selector 中的标签值（如 version: blue → version: green），可以实现瞬间流量切换。
2.1.4 Ingress：七层路由与域名管理
Ingress 提供基于 HTTP/HTTPS 的七层路由能力，将外部请求转发到集群内部的 Service。它通常需要配合 Ingress Controller（如 Nginx Ingress、Traefik）使用。
| Ingress 功能 | 发布场景应用 |
|---|---|
| 基于 Host/Path 路由 | 将不同域名或路径指向不同版本的 Service |
| 权重路由（部分 Controller 支持） | 实现金丝雀发布，按百分比分配流量到蓝绿版本 |
| TLS 终止 | 统一管理证书，避免在每个 Service 层重复配置 |
nginx.ingress.kubernetes.io/canary 注解。如果使用 Service Selector 切换，则 Ingress 配置无需变更，只需更新 Service 的标签选择器即可。
2.2 命名空间：多环境隔离与资源边界
命名空间（Namespace）是 Kubernetes 中实现多租户隔离的逻辑分区。在发布流程中，命名空间是蓝绿环境隔离的第一道防线。
| 隔离维度 | 说明 | 发布中的典型用法 |
|---|---|---|
| 资源命名 | 不同命名空间下允许同名资源共存 | 同一套 YAML 部署到不同命名空间实现环境隔离 |
| 网络策略 | 通过 NetworkPolicy 控制跨命名空间通信 | 蓝绿环境之间默认隔离，仅允许必要的服务调用 |
| 资源配额 | 通过 ResourceQuota 限制命名空间的总资源消耗 | 为蓝绿环境分别设置资源上限，避免互相抢占 |
| RBAC 权限 | 不同团队或角色只能操作特定命名空间 | 发布操作员仅拥有目标命名空间的写权限 |
2.3 标签选择器：发布流程的“粘合剂”
标签（Label）是 Kubernetes 中附加到资源上的键值对，标签选择器（Selector）则用于筛选具有特定标签的资源。在发布流程中，标签选择器是连接 Service、Deployment、Pod 以及监控系统的核心机制。
2.3.1 标签设计原则
- 标识性标签：
app、version、environment用于区分应用、版本和环境。 - 发布专用标签：
release: stable、release: canary用于蓝绿或金丝雀发布。 - 避免频繁变更：标签的增删改会导致 Service 端点重新计算，可能引起短暂流量中断。
2.3.2 蓝绿发布中的标签切换
以下是一个典型的蓝绿发布标签切换流程：
- 初始状态：Service Selector 为
app=myapp, version=blue，所有流量进入蓝色版本。 - 部署绿色版本：Deployment 创建 Pod，标签为
app=myapp, version=green。 - 验证绿色版本：通过内部 Service 或临时 Ingress 规则验证。
- 切换流量：修改 Service Selector 为
app=myapp, version=green，流量瞬间切换到绿色版本。 - 回滚（如需）：将 Selector 改回
version=blue，流量切回蓝色版本。
# 查看当前 Service 的标签选择器
kubectl get svc myapp-service -o jsonpath='{.spec.selector}'
# 修改 Service 的标签选择器（切换流量到绿色版本）
kubectl patch svc myapp-service -p '{"spec":{"selector":{"app":"myapp","version":"green"}}}'
# 回滚到蓝色版本
kubectl patch svc myapp-service -p '{"spec":{"selector":{"app":"myapp","version":"blue"}}}'2.4 本章小结
- Pod 是发布的最小单元，其就绪探针决定流量是否接入。
- Deployment 提供声明式更新和回滚能力，是版本管理的核心。
- Service 通过标签选择器实现流量切换，是蓝绿发布的“开关”。
- Ingress 提供七层路由，支持更精细的流量分发策略。
- 命名空间 提供环境隔离，但网络隔离需额外配置 NetworkPolicy。
- 标签选择器 是连接所有资源的“粘合剂”，其设计直接影响发布流程的灵活性和可靠性。