2. K8s 核心概念回顾：Pod、Deployment、Service、Ingress、ConfigMap、Secret 基础

在深入回滚策略之前，必须统一团队对 Kubernetes 核心原语的理解。回滚操作本质上是对这些原语声明状态的恢复或修正。以下六个概念构成了绝大多数工作负载与配置管理的基石。

2.1 核心对象速览表

2.2 Pod：最小调度单元

Pod 是 K8s 中可创建和部署的最小计算单元，包含一个或多个容器（共享网络栈和存储卷）。Pod 本身不具备自愈能力，通常由上层控制器（如 Deployment）管理。

• 生命周期： Pending → Running → Succeeded / Failed
• 重启策略： Always、OnFailure、Never
• 与回滚的关系： 回滚不直接操作 Pod，而是通过更新控制器（Deployment）的 PodTemplate 触发 Pod 重建。

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

Deployment 是 K8s 中最常用的工作负载控制器，它管理 ReplicaSet，并提供声明式更新、扩缩容和版本回滚能力。回滚的本质是让 Deployment 的 PodTemplate 恢复到历史版本，并驱动 ReplicaSet 进行 Pod 替换。

# 查看 Deployment 更新历史
kubectl rollout history deployment/nginx-deployment

# 回滚到上一个版本
kubectl rollout undo deployment/nginx-deployment

# 回滚到指定版本（revision=3）
kubectl rollout undo deployment/nginx-deployment --to-revision=3

2.4 Service：稳定的网络访问抽象

Service 为一组功能相同的 Pod 提供稳定的网络访问入口（ClusterIP、NodePort、LoadBalancer）。它通过标签选择器动态关联 Pod，不关心 Pod 的版本。

• 与回滚的关系： Service 本身无版本历史。回滚 Deployment 时，Service 的选择器通常不变，因此流量会自动切换到新版本的 Pod。
• 风险点： 如果回滚导致 Pod 标签变化，需确保 Service 的选择器能匹配到目标 Pod。

2.5 Ingress：七层流量路由

Ingress 将外部 HTTP/HTTPS 流量路由到集群内的 Service。它支持基于域名、路径的转发规则，以及 TLS 终止。

• 与回滚的关系： Ingress 规则变更（如修改后端 Service 名称）需要手动或通过流水线回滚。建议将 Ingress 清单纳入 Git 版本控制。
• 典型场景： 蓝绿部署或金丝雀发布时，Ingress 可能指向不同的 Service，回滚时需要切换 Ingress 的后端引用。

2.6 ConfigMap 与 Secret：配置与敏感数据管理

这两个对象将配置数据与容器镜像解耦，使得同一镜像可以在不同环境（开发、测试、生产）使用不同的配置。

2.7 核心对象关系图

下图展示了 Deployment、ReplicaSet、Pod、Service、Ingress 之间的层级与流量关系，这是理解回滚影响范围的基础。

2.8 回滚视角的关键总结

• Deployment 是回滚的第一公民： 它内置了版本历史管理和 rollout undo 命令。
• Service 与 Ingress 是稳定的路由层： 回滚时通常无需修改，但需确保标签选择器兼容。
• ConfigMap 与 Secret 是回滚的盲区： 它们没有版本历史，必须通过 Git 或 CI/CD 流水线的制品版本化来保证一致性。
• Pod 是回滚的最终执行对象： 回滚操作最终体现为 Pod 的销毁与重建。