模板哈希从哪来
Deployment 会给每份 Pod 模板算出一个哈希值，写进 ReplicaSet 与 Pod 的 pod-template-hash 标签，ReplicaSet 的名称也由它拼接而成。模板只要有变化（镜像、环境变量、资源声明等任何字段），哈希就会改变，Deployment 随之创建新的 ReplicaSet，并按滚动策略逐步替换旧副本。因此从 Pod 名称和标签就能判断它属于哪一次发布。
基本信息
| 适用对象 | Deployment 及其管理下的 ReplicaSet 与 Pod |
|---|---|
| 标签键 | pod-template-hash |
| 命名规律 | Pod 名 = Deployment 名 + 模板哈希 + 随机后缀 |
| 相关字段 | spec.revisionHistoryLimit 控制保留多少个旧 ReplicaSet |
| 查看方式 | kubectl get rs -l app=web、kubectl get pods --show-labels |
典型使用场景
- 发布排障：确认当前 Pod 属于哪一次发布，区分新旧版本副本
- 滚动观察：跟踪新旧 ReplicaSet 的副本数变化判断发布进度
- 镜像核对：确认 Pod 名里的哈希与期望的模板是否一致
- 归档清理：结合 revisionHistoryLimit 管理历史 ReplicaSet
- 回滚前后对比：回滚后哈希应回到上一版本对应的值
识别与核对
识别与核对
kubectl get rs -l app=web -o custom-columns='RS:.metadata.name,DESIRED:.spec.replicas,IMAGE:.spec.template.spec.containers[0].image'
kubectl get pods -l app=web --show-labels | grep pod-template-hash
kubectl get pod web-7d9c8b6f5c-abcde -o jsonpath='{.metadata.labels.pod-template-hash}'
kubectl rollout status deploy/web # 发布进度比逐个看 Pod 高效
kubectl rollout history deploy/web # 版本历史（annotation 变更也可作为线索）常见现象与含义
| 现象 | 含义 | 处理方向 |
|---|---|---|
| 出现新的 ReplicaSet | Pod 模板发生了变化 | 跟踪滚动进度与就绪副本数 |
| 旧 ReplicaSet 仍有副本 | 滚动未完成或卡在探针、PDB | 查就绪探针、预算与节点容量 |
| 手动删掉某个 ReplicaSet | Deployment 会立即重建它 | 清理历史版本应调 revisionHistoryLimit |
| Pod 名哈希与当前版本不符 | 属于上一次发布 | 等滚动完成或执行回滚 |
直接删除带 pod-template-hash 标签的 Pod，会被同一个 ReplicaSet 重建，镜像不会变；想更换版本必须改模板或执行回滚，而不是删 Pod。
回滚会把 Deployment 切回旧版本对应的模板，哈希随之回到那个值，旧 ReplicaSet 因此需要保留足够的 revisionHistoryLimit 才能被切回。
只改了不影响 Pod 模板的字段（例如副本数、扩缩容策略），哈希不会变化，也不会产生新的 ReplicaSet：判断某次变更是否触发了发布，看是否出现新的 ReplicaSet 比看 Deployment 的更新时间更可靠。