2. Kubernetes 基础回顾：Pod、Deployment、Service、ConfigMap、Secret 核心概念
在深入 Operator 回滚机制之前，必须牢固掌握 Kubernetes 的五个核心原语。它们是所有工作负载和自动化流程的基石。本章将逐一拆解每个资源的设计意图、生命周期与关键属性，为后续构建 Operator 和设计回滚策略打下坚实基础。
2.1 Pod：最小的调度与运行单元
Pod 是 Kubernetes 中可创建和部署的最小计算单元。一个 Pod 封装一个或多个容器（通常为一个主容器和若干辅助 Sidecar 容器），共享存储卷（Volume）、网络 IP 和端口空间。
- 共享网络：Pod 内所有容器共享同一个网络命名空间，可通过
localhost互相通信。 - 共享存储：通过挂载卷（Volume）实现容器间数据交换或持久化。
- 生命周期短暂：Pod 被设计为“有生死的”，不会自愈；一旦被删除或节点故障，不会自动重建。
- 状态机：Pending → Running → Succeeded/Failed，以及 CrashLoopBackOff 等异常状态。
Operator 视角：Operator 通常通过控制 Pod 的标签选择器、就绪探针（ReadinessProbe）和终止生命周期钩子（PreStop Hook）来实现优雅回滚与流量切换。
2.2 Deployment：声明式更新与回滚引擎
Deployment 是 Kubernetes 中最常用的工作负载控制器，它通过 ReplicaSet 管理 Pod 的副本数，并提供声明式更新、滚动升级和快速回滚能力。
| 特性 | 说明 | Operator 回滚关联 |
|---|---|---|
| 滚动更新 | 逐步替换旧 Pod，支持 maxSurge / maxUnavailable 控制速率 | 回滚时反向执行滚动策略，保证服务不中断 |
| Revision 历史 | 每次更新自动生成新 Revision，保留旧版本模板 | Operator 通过 rollback-to 指定 Revision 实现回滚 |
| 回滚命令 | kubectl rollout undo deployment/xxx --to-revision=N |
Operator 内部调用相同 API 或直接更新 ReplicaSet 模板 |
| 暂停/恢复 | kubectl rollout pause 暂停更新，用于金丝雀发布 |
回滚前可暂停当前发布，避免冲突 |
关键字段：
spec.replicas（副本数）、spec.strategy（更新策略）、spec.revisionHistoryLimit（保留历史版本数，默认 10）。Operator 回滚时需确保历史版本未被清理。
2.3 Service：稳定的网络访问抽象
Service 为一组动态变化的 Pod 提供固定的虚拟 IP（ClusterIP）和 DNS 名称，实现服务发现与负载均衡。Pod 的 IP 会随重建变化，但 Service 的端点始终可用。
- ClusterIP：集群内部访问，默认类型。
- NodePort：在每个节点上开放静态端口，外部可通过
NodeIP:NodePort访问。 - LoadBalancer：云厂商提供外部负载均衡器，自动分配公网 IP。
- Headless Service：不分配 ClusterIP，直接返回 Pod IP 列表，用于 StatefulSet。
回滚陷阱：回滚 Deployment 时，Service 的标签选择器（Selector）通常保持不变，因此流量会自动切换到回滚后的新 Pod。但如果回滚涉及 Service 端口或协议变更，必须同步更新 Service 配置，否则会导致流量中断。
2.4 ConfigMap 与 Secret：配置与敏感数据管理
ConfigMap 和 Secret 用于将配置数据与容器镜像解耦，使同一镜像可在不同环境（开发、测试、生产）下复用。
| 特性 | ConfigMap | Secret |
|---|---|---|
| 数据格式 | 明文键值对或文件内容 | Base64 编码（etcd 中可加密） |
| 典型用途 | 配置文件、环境变量、命令行参数 | 密码、、TLS 证书 |
| 挂载方式 | 环境变量或 Volume 挂载 | 环境变量或 Volume 挂载（自动 Base64 解码） |
| 更新生效 | Volume 挂载自动热更新（需应用监听） | Volume 挂载自动热更新；环境变量方式需重启 Pod |
| 回滚影响 | 回滚 Deployment 时，旧 Revision 引用旧 ConfigMap 名称 | Secret 名称变更可能导致 Pod 无法启动 |
最佳实践：在 Operator 回滚场景中，建议将 ConfigMap/Secret 的名称或版本信息编码到 Deployment 的 annotation 中，回滚时一并恢复对应的配置版本，避免配置与代码版本不匹配。
2.5 核心概念对比总结
| 资源 | 作用层级 | 是否自愈 | 回滚方式 | Operator 关注点 |
|---|---|---|---|---|
| Pod | 工作负载实例 | 否 | 由上层控制器重建 | 生命周期钩子、就绪探针 |
| Deployment | 控制器 | 是 | rollout undo 或 Revision 切换 |
Revision 历史、暂停策略 |
| Service | 网络抽象 | 是 | 通常无需回滚，Selector 不变 | 端口/协议变更需同步 |
| ConfigMap | 配置数据 | 否 | 恢复旧版本名称或内容 | 版本命名、热更新机制 |
| Secret | 敏感数据 | 否 | 恢复旧版本名称或内容 | 加密存储、轮换策略 |
Operator 回滚核心原则：回滚不仅仅是恢复 Deployment 的 Pod 模板，还必须保证关联的 ConfigMap、Secret、Service 以及存储卷（PVC）处于一致的状态。任何资源版本的不匹配都可能导致回滚后的应用无法正常启动或提供服务。