replicas是deployment中必须置于spec顶层的期望副本数字段，决定服务容错性与资源利用率；错误放置将被忽略，仅启动1个pod；支持kubectl scale动态调整，但不支持回滚。
副本数不是随便填的数字，它直接决定服务是否扛得住故障、扩缩容是否平滑、资源是否浪费。设为 1 就等于单点运行，设得太高又可能压垮节点或触发调度失败。
replicas 字段必须写在 Deployment spec 顶层
很多人把 replicas 错放在 template 或容器配置里，Kubernetes 会静默忽略——Pod 看似跑起来了，但实际只启动 1 个，且无法通过 kubectl scale 调整。
正确位置只有这一处：
spec:
replicas: 3 # ✅ 必须在这里
selector:
matchLabels:
app: my-app
template:
metadata:
labels:
app: my-app
spec:
containers: [...] # ❌ replicas 不允许出现在这里
-
replicas是Deployment的期望状态字段，由控制器持续比对并补足 - 值可以是任意正整数，但
0是合法值（用于临时下线） - 若用
kubectl apply -f更新 YAML，修改replicas后会触发滚动扩缩（取决于strategy.type）
用 kubectl scale 动态调整副本数最常用
线上突发流量、压测扩容、维护缩容，基本都走这条命令。它绕过 YAML 文件，直改 API Server 中的 spec.replicas，生效快、无侵入。
常见写法：
$ kubectl scale deployment/my-app --replicas=5 $ kubectl scale deploy nginx-deploy --replicas=2
- 支持缩容到
0：kubectl scale deploy/my-app --replicas=0 - 可批量操作：
kubectl scale deploy -l environment=prod --replicas=4 - 不支持回滚：改完就生效，没“撤销”按钮，误操作只能再
scale回去 - 注意命名空间：默认在
default，跨 ns 需加-n my-ns
滚动更新时 replicas 变化受 strategy 控制
单纯改 replicas 不会触发滚动更新；但如果你同时改了镜像或环境变量再 apply，Kubernetes 就要按 strategy.rollingUpdate 规则来替换 Pod。这时 replicas 实际控制的是“最终目标副本数”，而中间过程由 maxSurge 和 maxUnavailable 约束。
-
maxSurge: 25%表示最多额外创建 25% 的 Pod（向上取整），比如从 4→5，允许多起 1 个 -
maxUnavailable: 25%表示更新过程中最多容忍 25% 的 Pod 不可用，比如 4 个副本，最多停 1 个 - 如果设
maxUnavailable: 0，更新期间所有旧 Pod 必须保持就绪，新 Pod 全部 ready 后才删旧 Pod——适合强一致性场景
副本数设置要考虑节点资源与亲和性
写死 replicas: 10 很危险。如果集群只剩 2 个空闲节点，每个最多调度 4 个该应用 Pod，那第 9 个 Pod 就会卡在 Pending 状态，永远起不来。
- 先查节点资源：
kubectl describe nodes | grep -A 10 "Allocatable:" - 看已有 Pod 分布：
kubectl get pods -o wide，避免全挤在同一台节点 - 配合
topologySpreadConstraints强制打散，比盲目堆副本更可靠 - 长期建议接入 HPA：
kubectl autoscale deploy/my-app --cpu-percent=70 --min=2 --max=10
真正难的不是写几行 YAML 或敲几个命令，而是把 replicas 当成一个需要持续观测和反馈的指标——它连着监控、连着容量规划、连着故障恢复 SLA。设完就不管，等于把高可用交给了运气。
