ReplicaSet

一个 Pod 挂了就真没了。想”永远保持 3 个副本、挂一个补一个”，就得有个管家。ReplicaSet（副本集）就是这个管家。

17-1 为什么需要副本管理

假设你手动起了 3 个 Pod 跑 Web 服务。其中一个节点宕机，那一个 Pod 就没了，剩下 2 个扛流量，迟早撑爆。而且你想扩容到 5 个，还得手动再建 2 个。

ReplicaSet 把这件事自动化：你告诉它”我要 3 个”，它负责让集群里始终有 3 个健康的副本。少了就补，多了就删。

17-2 ReplicaSet 的三件套

一个 ReplicaSet 由三块组成。

replicas：你想要几个副本。这是它的目标，控制器就是朝这个数靠拢。

selector：标签选择器。它用这组标签去”认领”Pod。只有标签对上的 Pod 才归它管。

template：Pod 模板。副本不够时，照这个模板新建 Pod。

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: frontend-rs
spec:
  replicas: 3
  selector:
    matchLabels:
      app: frontend
  template:
    metadata:
      labels:
        app: frontend
    spec:
      containers:
      - name: nginx
        image: nginx:1.27

17-3 标签选择器怎么认领 Pod

关键在 selector.matchLabels 和 template.metadata.labels 必须对得上。ReplicaSet 会去集群里找所有带 app: frontend 的 Pod，数一数。

数量少于 replicas？它用模板新建。多于 replicas？它删多余的。

kubectl get rs
kubectl get pods --show-labels

kubectl get rs 能看到当前副本数、期望数、就绪数。--show-labels 能确认 Pod 标签对不对得上。

17-4 自愈与扩缩

ReplicaSet 的核心能力就是自愈。节点挂了，上面的 Pod 变成 Unknown，ReplicaSet 发现总数不够，就在别的节点补一个新的。

扩缩容就一行命令：

kubectl scale rs frontend-rs --replicas=5

也可以直接编辑 YAML 里的 replicas 再 apply。控制器会调和到新目标。

17-5 注意：一般别直接用它

说到这你可能想，ReplicaSet 真好用，直接写它。其实日常更推荐用 Deployment（第 18 章）。

原因：ReplicaSet 只管”副本数不变”，不管”版本更新”。你换了镜像，它不会平滑地一个一个换，而是比较笨。Deployment 在 ReplicaSet 之上又管了”发布”这层，支持滚动更新、回滚。

kubectl delete rs frontend-rs

17-6 常见坑

一是标签对不上，ReplicaSet 认不出 Pod，于是一直新建，造成副本爆炸。

二是手改了某个 Pod 的标签，它立刻脱离 ReplicaSet 的管辖，ReplicaSet 又补一个，结果多出一个”野”Pod。

三是 matchLabels 写得太宽泛，把别的 Deployment 的 Pod 也认领了，两边抢着管，状态永远对不齐。

下一章看 Deployment，它是无状态应用的事实标准入口。