9. k8s-ReplicaSets介绍
k8s-ReplicaSets介绍
- 一、ReplicaSet 概述
- 1.1 定义与本质
- 1.2 与 ReplicationController（RC）的关系
- 二、ReplicaSet 工作机制
- 2.1 三大要素
- 2.2 自愈演示
- 三、ReplicaSet YAML 规范（完整注释）
- 四、ReplicaSet 操作指南
- 4.1 创建
- 4.2 查看
- 4.3 扩缩容
- 4.4 删除
- 五、ReplicaSet 的局限性
- 六、ReplicaSet 与 Deployment 的关系
- 6.1 设计哲学
- 6.2 能力对比
- 6.3 生产建议
- 七、ReplicaSet 的合理使用场景
- 八、故障排查
- 8.1 Pod 数量不符合预期
- 8.2 Pod 创建失败
- 8.3 无法扩缩容
- 九、总结
- 范例
一、ReplicaSet 概述
K8S官方推荐直接使用Deploymen，单独介绍RS，是为了让用户明白维持pod副本数量的原理。
1.1 定义与本质
ReplicaSet（RS） 是 Kubernetes 中用于确保指定数量 Pod 副本始终运行的控制器资源。
核心职责：
- 副本数维持：监控 Pod 数量，实际 ≠ 期望时自动创建/删除
- 自愈能力：Pod 故障、节点宕机时自动重建
- 水平扩缩：修改
replicas字段即可实现弹性伸缩
设计定位：
ReplicaSet → Pod 的“保险员”1.2 与 ReplicationController（RC）的关系
| 维度 | ReplicationController（RC） | ReplicaSet（RS） |
|---|---|---|
| 选择器支持 | 仅等式匹配（=、!=） | 集合匹配（In、NotIn、Exists） |
| 状态 | 已废弃（v1.2+） | 标准控制器 |
| 实际使用 | 不推荐 | 不直接使用（由 Deployment 管理） |
核心演进：ReplicaSet 完全替代 RC，提供更灵活的标签选择能力。
二、ReplicaSet 工作机制
2.1 三大要素
| 要素 | 作用 | 示例 |
|---|---|---|
| replicas | 期望运行的 Pod 副本数 | replicas: 3 |
| selector | 标签选择器，确定管理的 Pod 集合 | matchLabels: app: nginx |
| template | Pod 模板，用于创建新 Pod | 定义容器、镜像、端口等 |
工作流程：
- ReplicaSet 通过 selector 查询当前运行的 Pod
- 计算
实际数量与spec.replicas的差值 - 差值 > 0 → 根据 template 创建 Pod
- 差值 < 0 → 删除多余的 Pod
2.2 自愈演示
初始状态：
# 创建 3 个副本kubectl apply -f rs.yaml kubectl get pod NAME READY STATUS nginx-replicaset-abc011/1 Running nginx-replicaset-abc021/1 Running nginx-replicaset-abc031/1 Running手动删除一个 Pod：
kubectl delete pod nginx-replicaset-abc01自动重建（数秒内）：
kubectl get pod NAME READY STATUS nginx-replicaset-abc021/1 Running nginx-replicaset-abc031/1 Running nginx-replicaset-xyz991/1 Running# 新 Pod，名称不同结论：ReplicaSet 持续监控，始终维持期望副本数。
三、ReplicaSet YAML 规范（完整注释）
apiVersion:apps/v1# API 版本（apps 组，v1）kind:ReplicaSet# 资源类型metadata:name:nginx-replicaset# RS 名称labels:# RS 自身的标签app:nginxtier:frontendspec:# ---------- 副本数控制 ----------replicas:3# 【必填】期望的 Pod 副本数量# ---------- 选择器（核心） ----------selector:# 【必填】标签选择器matchLabels:# 等式匹配模式app:nginx# 必须与 template.metadata.labels 一致# matchExpressions: # 集合匹配模式（更灵活）# - key: app# operator: In # In, NotIn, Exists, DoesNotExist# values:# - nginx# ---------- Pod 模板 ----------template:# 【必填】Pod 生成模板metadata:labels:# 必须与 selector.matchLabels 匹配app:nginxspec:containers:-name:nginximage:nginx:latestimagePullPolicy:IfNotPresentports:-containerPort:80关键约束：
spec.selector必须匹配spec.template.metadata.labels- 不匹配时 API Server 拒绝创建
四、ReplicaSet 操作指南
4.1 创建
kubectl apply -f rs.yaml4.2 查看
# 查看 ReplicaSet 列表kubectl get rs# 查看详细信息（包含期望/当前/就绪副本数）kubectl get rs nginx-replicaset -o wide# 查看 RS 控制的 Podkubectl get pods -lapp=nginx4.3 扩缩容
方法一：直接编辑
kubectl edit rs nginx-replicaset# 修改 spec.replicas 字段方法二：命令式扩缩
kubectl scale rs nginx-replicaset --replicas=5方法三：声明式更新 YAML
# 修改 replicas 后重新 applykubectl apply -f rs.yaml4.4 删除
# 删除 ReplicaSet（同时删除其管理的 Pod）kubectl delete rs nginx-replicaset# 仅删除 RS，保留 Pod（孤儿 Pod）kubectl delete rs nginx-replicaset --cascade=orphan五、ReplicaSet 的局限性
| 限制 | 说明 | 生产影响 |
|---|---|---|
| 无滚动更新 | 修改 Pod template 不会自动更新已有 Pod | 需手动删除重建，造成停机 |
| 无版本回滚 | 不保留历史版本 | 无法快速回退故障版本 |
| 无暂停/恢复 | 不支持蓝绿、金丝雀发布 | 发布策略受限 |
| 无声明式更新 | 镜像升级需多步操作 | 运维效率低 |
根本原因：ReplicaSet 只关注副本数量，不关注 Pod 内容变更。
六、ReplicaSet 与 Deployment 的关系
6.1 设计哲学
Deployment（声明式部署） │ ├─ 管理 ReplicaSet v1（当前） ├─ 管理 ReplicaSet v2（新版本） └─ 保留 ReplicaSet v0（历史） ReplicaSet（副本控制） │ └─ 管理 Pod 实例6.2 能力对比
| 能力 | 直接使用 ReplicaSet | 使用 Deployment（推荐） |
|---|---|---|
| 副本数维持 | ✅ | ✅（通过 RS） |
| 自愈能力 | ✅ | ✅（通过 RS） |
| 水平扩缩 | ✅ | ✅（通过 RS） |
| 滚动更新 | ❌ 需手动 | ✅ 自动 |
| 版本回滚 | ❌ 需手动 | ✅rollout undo |
| 版本历史 | ❌ 无 | ✅ 保留历史 RS |
| 暂停/恢复 | ❌ 无 | ✅rollout pause/resume |
| 声明式配置 | ⚠️ 部分支持 | ✅ 完整支持 |
6.3 生产建议
✅ 推荐：
apiVersion:apps/v1kind:Deployment# 使用 Deploymentmetadata:name:nginx-deploymentspec:replicas:3selector:matchLabels:app:nginxtemplate:# Pod 模板metadata:labels:app:nginxspec:containers:-name:nginximage:nginx:1.25❌ 不推荐：
kind:ReplicaSet# 直接使用 ReplicaSet# ... 其他配置同上核心原则：
永远不要直接使用 ReplicaSet 管理业务 Pod——Deployment 提供了完整生命周期管理，ReplicaSet 是其内部实现细节。
七、ReplicaSet 的合理使用场景
尽管 Deployment 是标准方案，ReplicaSet 在以下特殊场景仍有价值：
| 场景 | 说明 |
|---|---|
| 学习与理解 | 深入理解控制器模式的工作原理 |
| 自定义控制器 | 开发 Operator 时，直接控制 ReplicaSet 而非 Deployment |
| 无需更新的静态负载 | 极少变更的稳定服务（理论上，仍推荐 Deployment） |
| 离线环境/边缘节点 | 极端简化场景，减少控制平面开销 |
仍建议：即使上述场景，优先使用 Deployment，仅将 ReplicaSet 作为内部实现。
八、故障排查
8.1 Pod 数量不符合预期
# 1. 查看 RS 状态kubectl describe rs<rs-name># 2. 检查标签匹配kubectl get pods --show-labels kubectl get rs<rs-name>-o yaml|grepselector# 3. 查看是否有其他控制器管理相同标签kubectl get deployment,rs,statefulset -lapp=nginx8.2 Pod 创建失败
# 查看 RS 事件kubectl describe rs<rs-name># 常见原因：# - 镜像不存在或拉取失败# - 资源不足（CPU/内存）# - PVC 绑定失败# - 节点污点不匹配8.3 无法扩缩容
# 检查资源配额kubectl describequota-n<namespace># 检查节点资源kubectltopnodes九、总结
| 维度 | 核心结论 |
|---|---|
| 定义 | 确保指定数量 Pod 始终运行的控制器 |
| 核心机制 | selector + replicas + template |
| 自愈能力 | ✅ Pod 故障自动重建 |
| 水平扩缩 | ✅ 修改 replicas 即时生效 |
| 滚动更新 | ❌ 不支持（Deployment 提供） |
| 版本回滚 | ❌ 不支持（Deployment 提供） |
| 生产定位 | Deployment 的内部实现，不直接使用 |
一句话总结：
ReplicaSet 是 Kubernetes 副本控制的核心实现，但 Deployment 是其标准生产接口——直接使用 ReplicaSet 如同驾驶无方向盘汽车，虽能前进却无法优雅转向。
范例
apiVersion:apps/v1# api版本kind:ReplicaSet# 产品类型metadata:name:nginx-replicasetlabels:app:nginxspec:replicas:3# 设置你想要维持的Pod副本数量selector:matchLabels:app:nginx# 定义选择器，用于确定哪些Pod属于此ReplicaSettemplate:# 这是创建新Pod时使用的模板metadata:labels:app:nginx# 确保Pod标签与选择器匹配spec:containers:-name:nginximage:nginx# 使用Nginx镜像imagePullPolicy:IfNotPresent#定义镜像下载策略ports:-containerPort:80# 容器监听的端口kubectl apply -f rs-test.yaml这个时候k8s按照我们的预期，创建了3个pod，如果因为意外或者其他原因，部分pod被删除，那么这个rs的控制器则会自动补齐对应的个数，这样他就通过这个方式来提高了我们的业务的高可用。始终按照我们的预期的方式运行。
kubectl get podkubectl delete pod nginx-replicaset-tj728kubectl get pod