云效这个问题怎么解决？

请顺序执行以下的排查步骤，示例中假定待发布的工作负载类型为 deployment，预期的名字为 demo-deploy，所处的命名空间为 demo-namespace.

4.1检查 Rollout 辅助对象是否成功创建

由于 Rollout 辅助对象会使用预期名，故可直接获取：
kubectl get rollout demo-deploy -n demo-namespace -o=yaml
如果没有发现 Rollout 对象生成，由技术支持人员协助排查。

4.2 确认是否存在基线版本缺失

根据前一步获取的 Rollout yaml，判断是否有基线版本缺失：
spec:
componentName: demo-deploy
rolloutPlan:
batchPartition: 0
rolloutBatches:

- replicas: 1
rolloutStrategy: IncreaseFirst
targetSize: 1

targetRevisionName: demo-deploy-v181
status:
LastSourceRevision: demo-deploy-v179
batchRollingState: batchInitializing
conditions:
...
currentBatch: 0
lastTargetRevision: demo-deploy-v180
rollingState: rolloutAbandoning
rolloutTargetSize: 1
targetGeneration: da4e412e71377443
upgradedReadyReplicas: 0
upgradedReplicas: 0

请关注 status 属性下的 LastSourceRevision 和 lastTargetRevision 两个字段，它们应该对应存在的 Deployment 名字；如果 rollingState 处于 rolloutAbandoning 且 LastSourceRevision 和 lastTargetRevision 对应的 Deployment 遭删除，则发布可能如上面所示地停滞。

如果确认 Deployment 确实遭删除，可以通过回补 Deployment 完成发布补偿，补偿后的版本将是 spec 属性中的 targetRevisionName 版本，通常是最近一次指定发布的工作负载版本。回补的 Deployment 建议设置为 0 复本，以避免不必要的资源开销或业务流量导入。

如果没办法从其他渠道获取被删除的 deployment 细节，可以通过下面的命令获取基线数据：
kubectl get controllerrevision demo-deploy-v180 -n demo-namespace -o=yaml
kubectl get controllerrevision demo-deploy-v179 -n demo-namespace -o=yaml
RevisionS
ControllerRevision 对象中，包含了曾经发布的工作负载信息，可供参考。
如果需要手工操纵分批发布，请修改 spec 属性下的 batchPartition 字段。请注意，batchPartition 对应分批发布批次计划中的下标，从 0（而不是从 1）开始。此回答整理自钉群“云效交付域答疑群”