K8s Spring Boot应用数据库宕机时readiness probe触发额外Pod创建问题

问题1：为什么会创建新的Pod？ #

首先纠正一个常见的认知错误：readinessProbe失败本身不会触发新Pod创建，也不会重启现有Pod，它的唯一作用是将Pod标记为NotReady状态，从Service的后端端点列表中移除，停止向该Pod转发流量，符合你最初的配置预期。
你看到新Pod创建，核心原因大概率是以下两种之一：

• 你的集群为该Deployment配置了HPA（水平Pod自动扩缩容）：数据库宕机后，应用线程大量阻塞在Hikari连接池的获取逻辑上，CPU、内存使用率或自定义QPS指标飙升，触发HPA的扩容规则，自动创建新Pod。
• livenessProbe实际已触发失败：虽然你配置liveness探针排除了db检查，但liveness探针的超时时间仅为5秒，数据库宕机后应用线程阻塞严重，无法在5秒内返回liveness接口的响应，连续失败达到阈值后kubelet会销毁原有容器，Deployment会自动创建新Pod来维持期望的副本数。

问题2：为什么恰好新增3个Pod，而非1个、2个、4个或其他数量？ #

新增数量和你配置的扩缩容规则直接相关：

• 如果你用了HPA：HPA会根据当前指标和目标阈值的比值计算期望副本数，计算公式为期望副本数 = ceil(当前副本数 * (当前指标值 / 目标指标值))，假设你原有副本数为2，当前CPU使用率是目标值的2.2倍，计算出来的期望副本数就是5，正好新增3个。同时HPA有默认的扩容步长限制，单次扩容的Pod数量不会超过配置的最大步长，也会影响最终的新增数量。
• 如果你没有配置HPA：那说明你的Deployment的期望副本数本来就是5，原有2个Pod是因为之前触发了缩容规则降到2，现在触发了扩容阈值恢复到5个副本，正好新增3个。

问题3：该现象是否与restartPolicy有关？ #

无关。
restartPolicy是Pod级别的配置，仅控制单个Pod内部的容器退出后，kubelet是否要重启该容器，不会触发新Pod的创建。你提供的Pod列表中所有Pod的RESTARTS字段都是0，说明没有发生过容器重启的操作，进一步验证了和restartPolicy没有关联。

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