ReplicaSet是副本数量的“守门人”，Deployment是带版本管理能力的“部署管家”；前者只确保指定数量、标签匹配的Pod始终运行，执行“少补多删”，不关心版本与更新逻辑；后者通过管理多个ReplicaSet实现滚动更新、回滚、扩缩容等生产级能力。
直接说结论：ReplicaSet 是副本数量的“守门人”，Deployment 是带版本管理能力的“部署管家”。前者管“有多少个”，后者管“怎么换、换错了怎么办”。
ReplicaSet 的核心职责：稳住副本数
ReplicaSet 只做一件事：确保集群中始终运行着指定数量、标签匹配的 Pod。它不关心版本，也不管更新逻辑，只执行“少补多删”——比如定义 replicas: 3，一旦某个 Pod 挂了或被误删，它立刻按 template 拉起一个新 Pod 补位。
- 靠 selector.matchLabels 找到自己该管哪些 Pod（必须与 template 中的 labels 完全一致）
- 所有被它创建的 Pod，会在 metadata.ownerReferences 中自动写入该 ReplicaSet 的身份信息
- 它能接管“孤儿 Pod”：只要 Pod 标签匹配 selector 且没有 ownerReferences，就会被自动归属
Deployment 的真实角色：ReplicaSet 的调度器
Deployment 本身不直接创建或监控 Pod，它真正的工作是管理多个 ReplicaSet 实例。每次你修改镜像或配置触发更新，Deployment 就会创建一个新的 ReplicaSet，并逐步将流量从旧 ReplicaSet 迁移到新 ReplicaSet，同时保留旧 ReplicaSet 用于回滚。
Kubernetes Security Posture Scorecard
下载
评估 Kubernetes 集群安全态势，覆盖 RBAC、工作负载安全、网络策略、基础设施即代码（IaC）、运行时监控和密钥管理等 30 项控制项……
- 滚动更新时，旧 RS 的副本数递减，新 RS 的副本数递增，整个过程由 strategy.rollingUpdate 控制（如 maxSurge/maxUnavailable）
- 每个成功发布的版本都会生成一个独立的 ReplicaSet，并打上 deployment.kubernetes.io/revision 标签
- kubectl rollout history 查看到的其实是这些 ReplicaSet 的快照记录
为什么几乎不用直接写 ReplicaSet？
不是不能用，而是没必要——它缺乏生产必需的容错机制：
- 手动改镜像字段会强制重建全部 Pod，服务中断风险高
- 没有历史版本留存，出问题只能靠人工还原 YAML 和镜像标签
- 无法设置就绪探针（readinessProbe）来控制流量切换节奏
- 扩缩容只能靠改 replicas 字段再 apply，没法做灰度或分批次操作
选型建议：看你要不要“记住变化”
如果只是临时起几个测试 Pod，或者写底层工具链需要精细控制副本生命周期，ReplicaSet 有其简洁价值；但只要涉及上线、迭代、故障恢复，Deployment 就是唯一合理选择——它把更新变成可审计、可暂停、可逆转的操作，而不是一次高风险的手动替换。
