K8s滚动更新时新Pod创建耗时过长问题咨询

Deployment从1.2.19版本滚动更新至1.2.20版本时，首个新Pod创建完成后，后续新Pod创建存在长时间延迟。已配置minReadySeconds: 10，但实际需要等待约1分钟才会开始创建第二个Pod，相关配置参考：

这个延迟和minReadySeconds配置不冲突，本质是对Kubernetes滚动更新的推进逻辑存在认知偏差：

• minReadySeconds的计时起点不是Pod进入Running状态的时间，而是Pod的就绪探针（Readiness Probe）连续探测成功、进入Ready状态的时间。只有等minReadySeconds计时结束，Pod被标记为Available后，Deployment控制器才会继续创建下一个新Pod。
• 1分钟左右的总延迟是默认配置叠加服务启动耗时的典型表现：
  • 未显式配置就绪探针参数时，Kubernetes默认探测周期periodSeconds=10s、连续失败阈值failureThreshold=3，仅探针判定环节最坏就会产生30s的等待时长。
  • 多数服务启动后需要完成配置加载、依赖连接建立等初始化操作，从容器进程启动（进入Running状态）到真正能响应健康检查，本身就需要10-20s不等的耗时。
  • 上述耗时叠加10s的minReadySeconds等待，总时长刚好落在1分钟左右的区间。

按以下步骤调整即可：

1. 先确认实际耗时分布
   执行命令查看首个新Pod的事件流，定位就绪探针的实际成功时间点：

kubectl describe pod <首个滚动生成的新Pod名> -n <业务命名空间>

重点核对Events区块中，Pod进入Running状态的时间、最后一次就绪探针探测失败的时间、第一次探针探测成功的时间，确认各环节耗时。
2. 优化就绪探针配置
根据服务实际启动速度，调整探针参数，减少无意义的探测等待，参考配置：

readinessProbe:
  httpGet:
    path: /your-health-check-path  # 替换为业务实际的健康检查接口
    port: your-service-port        # 替换为业务实际监听端口
  initialDelaySeconds: 5  # 服务启动后5秒发起第一次探测，按实际启动速度调整
  periodSeconds: 5        # 探测间隔调整为5秒
  failureThreshold: 2     # 连续2次失败即判定为未就绪

3. 验证滚动更新节奏
   调整配置后重新触发滚动更新，正常流程下的时间线为：Pod启动→通过就绪探针进入Ready状态→等待10s minReadySeconds→标记为Available→立即创建下一个新Pod，不会再出现额外的长延迟。

注意：不要为了加快滚动更新把minReadySeconds设为0，该参数的作用是给服务留足启动后的稳定观察窗口，避免刚就绪就接流量导致进程崩溃，引发滚动更新故障。

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