kubectl rollout status完成判定条件及探针对部署耗时影响咨询

Deployment默认使用RollingUpdate滚动发布策略，判定发布完成需要满足以下全部环节：

• 新版本ReplicaSet（RS）创建完成，新RS调度的Pod副本数达到Deploymentspec.replicas字段配置的预期值
• 新RS下所有Pod的就绪探针连续检测成功，Pod状态更新为Ready，可用副本数符合预期要求
• 旧版本RS下的所有Pod副本完全终止、销毁，无运行中的旧版本残留
• Deployment状态更新为Progressing: True、Complete: True，且status.availableReplicas与预期副本数完全一致

发布过程中会严格遵循maxSurge（最大超发副本数）、maxUnavailable（最大不可用副本数）的配置阈值，不会超出限制推进发布流程。

两种探针都会直接或间接影响部署耗时，其中就绪探针对发布进度的影响是决定性的

• 就绪探针（readinessProbe）直接决定发布推进速度：滚动发布过程中，只有Pod通过就绪探针检测被标记为Ready，才会被计入可用副本，Deployment才会继续销毁旧副本、创建新副本。当前配置的initialDelaySeconds: 120意味着Pod启动后必须等待120秒才会开始第一次就绪检测，哪怕服务实际启动耗时远低于120秒，也需要等待满该时长才会开始检测，这是导致kubectl rollout status阻塞的核心原因之一。
• 存活探针（livenessProbe）间接影响部署耗时：如果Pod启动后，在就绪探针检测完成前存活探针检测失败，K8s会直接重启Pod，导致发布流程重试，拉长整体耗时。当前配置的存活探针初始延迟同样为120秒，正常启动场景下不会触发重启，但如果服务启动超过120秒端口仍未就绪，就会触发Pod重启，进一步阻塞发布。

优化参考：如果服务实际启动耗时远小于120秒，可适当调低initialDelaySeconds减少无意义等待；如果服务启动耗时波动较大，可新增startupProbe专门检测服务启动状态，启动成功后再执行就绪、存活探针，兼顾慢启动场景和运行时检测需求。

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