Kubernetes如何保障ReplicaSet的Pod数量及单副本Deployment的Pod上限？

1. ReplicaSet 如何保障 Pod 数量符合预期？ #

ReplicaSet 通过**调谐循环（Reconciliation Loop）**实现副本数的闭环控制：

• 持续对比 spec.replicas 定义的期望副本数，与集群中带对应标签的健康 Pod 数量（仅统计处于 Running 且就绪的 Pod）。
• 当实际数少于期望数：直接调用 Kubernetes API 创建新 Pod 对象，由调度器分配到可用节点启动。
• 当实际数多于期望数：向多余的 Pod 发送删除指令，优先剔除不健康或未就绪的 Pod。
• 联动健康检查：如果 Pod 触发 livenessProbe 失败被判定为不健康，ReplicaSet 会将其视为无效副本，自动启动重建流程。

2. 单副本 Deployment（基于 ReplicaSet）能否保障集群中最多存在 1 个 Pod？ #

常规场景下的保障 #

Deployment 对 ReplicaSet 进行版本化管理，确保始终只有一个活动的 ReplicaSet，且其 spec.replicas 设为 1：

• ReplicaSet 的调谐循环会严格监控 Pod 数量，一旦发现超过 1 个，立即删除多余的 Pod。
• 正常重建流程中，ReplicaSet 会先将旧 Pod 标记为 Terminating，确认其完全终止后再创建新 Pod，避免同时存在两个运行中的实例。

极端场景的风险与应对 #

你提到的节点心跳失联场景，确实存在出现双 Pod 的风险：

• 当节点与 Controller Manager 心跳中断超过 node-monitor-grace-period（默认 40 秒），Controller Manager 会标记节点为 NotReady，并触发 Pod 驱逐逻辑，创建新 Pod。但原节点上的 Pod 可能仍在正常运行（只是无法与集群通信），导致双实例并存。
• Kubernetes 无法彻底消除这种分布式一致性问题，但可通过以下方式降低影响：
  • 应用层幂等性：在业务代码中实现分布式锁、唯一请求标识等逻辑，确保即使多实例存在也不会引发业务冲突。
  • 使用 StatefulSet：StatefulSet 为单 Pod 提供稳定的网络标识，且重建时会等待旧 Pod 的相关资源（如 PVC）释放，但仍无法解决节点失联导致的旧 Pod 存活问题。
  • 配置 Pod 反亲和：通过 podAntiAffinity 确保同类型 Pod 不会被调度到同一节点，但无法避免跨节点的双实例问题。
  • 调整节点监控参数：缩短 node-monitor-grace-period 减少误判窗口，但会增加正常情况下的误驱逐概率。

内容的提问来源于stack exchange，提问作者Tinyden