ReplicaSet 是什么
ReplicaSet 的职责只有两件事：通过标签选择器认领一批 Pod，并让它们的数量始终等于 spec.replicas。它不做版本管理、不记录发布历史、也不支持回滚。日常运维中几乎不会直接创建它——Deployment 会为每次模板变更创建新的 ReplicaSet，并在新旧之间按策略调整副本数，因此理解 ReplicaSet 是看懂发布过程的前提。
基本信息
| 核心字段 | spec.replicas、spec.selector、spec.template |
|---|---|
| 选择器 | 必须与模板标签匹配，创建后不可修改 |
| 管理者 | 通常由 Deployment 创建并控制，名字带模板哈希后缀 |
| 保留策略 | 旧 ReplicaSet 缩容到 0 但保留，受 revisionHistoryLimit 约束 |
| 直接操作 | 不推荐，对账循环会覆盖手工改动 |
典型使用场景
- 看懂发布过程：新旧两个 ReplicaSet 的副本数此消彼长，就是滚动的实质
- 定位 Pod 归属：Pod 名里的哈希前缀对应某个 ReplicaSet，可追溯到某次发布
- 排查副本异常：副本数与就绪数不一致时先看是哪个 ReplicaSet 在负责
- 清理遗留对象：升级工具或手工操作常留下无主的 ReplicaSet，需要定期盘点
- 理解回滚：rollout undo 实际是把目标 ReplicaSet 的副本数重新拉起
查看与说明
查看与说明
kubectl get rs -n prod # 每个 Deployment 的新旧 RS 都在这里
kubectl get rs -n prod -o wide # 看 DESIRED、CURRENT、READY 三列
kubectl describe rs web-7d9c8b6f5c -n prod # 看它认领了哪些 Pod
kubectl get pod web-7d9c8b6f5c-x2k9d -o jsonpath='{.metadata.ownerReferences[0].name}'
kubectl rollout history deploy/web # 从 Deployment 视角看版本与 RS 的对应三层对象分工
| 对象 | 职责 | 常见运维动作 |
|---|---|---|
| Deployment | 版本管理、发布策略、回滚、副本数声明 | 改镜像、改副本、rollout undo |
| ReplicaSet | 维持 Pod 数量与标签集合 | 一般不直接操作，只用于观察 |
| Pod | 实际运行单元 | 不直接编辑，用控制器管理生命周期 |
get rs 逐列读法
| 列 | 含义 | 异常表现 |
|---|---|---|
| DESIRED | 期望副本数 | 旧 RS 应为 0，长期非 0 说明更新卡住 |
| CURRENT | 已在 API 中创建的副本数 | 小于 DESIRED 说明创建受限 |
| READY | 就绪副本数 | 长期小于 DESIRED 时看 Pod 事件 |
| AGE | 存在时长 | 新 RS 很新而旧 RS 仍非 0，是回滚或发布未完成的信号 |
对 ReplicaSet 直接 scale 不会持久：Deployment 的对账循环会立刻把数量改回模板声明值。需要调整副本数请改 Deployment，若确实要绕过控制器，得先确认它不再被任何 Deployment 管理。
ReplicaSet 的 selector 创建后不可修改，标签写错只能删掉重建。这也是为什么修标签类问题通常走重建对象，而不是原地 patch。