GitLab CI部署K8s时，如何仅等待部分副本完成滚动发布？

问题背景 #

我们通过GitLab CI流水线部署应用到Kubernetes，执行的部署命令如下：

kubectl set image deployment/our-app-name new-image:new-tag
kubectl rollout status deployment/our-app-name

默认情况下，kubectl rollout status会等待全部5个新副本启动就绪、旧副本销毁完成，偶尔会因耗时过长触发超时，错误信息为：

error: deployment "our-app-name" exceeded its progress deadline

不想通过-timeout参数强制延长超时时间，希望优化为：仅等待2-3个新副本启动就绪、确认应用可正常部署后，就让流水线标记为成功，剩余副本的滚动更新由Kubernetes自行完成。

解决方案 #

方案1：精准等待指定数量的新副本就绪 #

通过kubectl wait结合Pod模板哈希，精准等待新版本的指定数量Pod就绪，满足条件后立即结束流水线，无需等待全部副本更新完成。

执行命令替换原有的kubectl rollout status：

# 触发应用镜像更新
kubectl set image deployment/our-app-name new-image:new-tag

# 获取新版本Pod的模板哈希（Kubernetes自动生成，用于区分不同版本的Pod）
NEW_POD_HASH=$(kubectl get deployment our-app-name -o jsonpath='{.status.updateRevision}')

# 等待至少2个新版本Pod进入就绪状态（可根据需求调整--count参数为3），超时时间设为5分钟（可按需调整）
kubectl wait --for=condition=ready pod -l pod-template-hash=$NEW_POD_HASH --timeout=5m --count=2

该方案的优势：无需修改Deployment的全局配置，仅在CI流水线中调整命令即可灵活控制等待的副本数量，流水线成功后，Kubernetes会自动完成剩余副本的滚动更新。

方案2：调整Deployment滚动更新策略（全局配置） #

如果希望从Deployment层面优化滚动更新的推进速度，可修改其滚动更新参数，减少整体更新的等待压力：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: our-app-name
spec:
  strategy:
    rollingUpdate:
      maxSurge: 2        # 允许滚动更新时额外创建最多2个副本，加快新版本Pod的启动速度
      maxUnavailable: 0  # 不允许旧副本不可用（可根据业务容忍度调整为1或2）
    type: RollingUpdate
  progressDeadlineSeconds: 300  # 可选：延长进度截止时间，避免过早触发超时

修改后重新应用Deployment配置即可生效，该方案会影响所有后续的滚动更新操作。

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