云效 appstack部署单失败，一直卡着不动，怎么解决？

如果你的云效 AppStack 部署单一直卡着不动，并且没有在 k8s 集群中创建资源，可能存在以下几种情况：

1. 部署单配置错误。请检查你的部署单配置是否正确，包括应用名称、镜像地址、端口映射等参数是否正确设置。
2. 网络问题。请检查你的 k8s 集群的网络是否正常，是否存在网络故障或访问限制等问题。
3. 资源不足。请检查你的 k8s 集群的资源是否充足，例如 CPU、内存、存储等资源是否满足部署需要。
4. 其他异常情况。如果以上方法都无法解决问题，可能存在其他异常情况导致部署失败。你可以联系云效的技术支持获取帮助，他们可以帮助你进一步排查问题并提供解决方案。

为了解决这个问题，你可以尝试以下几种方法：

1. 重新创建部署单。如果你确定部署单的配置没有问题，可以尝试重新创建部署单并等待一段时间观察是否能够成功部署。
2. 检查日志信息。你可以在云效的控制台中查看部署单的日志信息，以了解具体的部署过程和出错原因。根据日志信息进行相应的处理和调整。
3. 调整资源配置。如果你的 k8s 集群资源不足，可以考虑增加资源或者调整部署单的配置，以减少对资源的占用。

针对云效appstack部署单失败一直卡着不动的问题，可以尝试以下解决方法：

1. 检查日志：在云效控制台中查看该部署单的日志，找到具体的错误信息。根据错误信息可以进一步定位问题所在。

2. 检查资源限制：确认k8s集群中是否有足够的资源来创建所需的资源对象。如果资源不足，可能会导致部署失败。可以通过命令行工具或者云效控制台的资源管理功能来查看和调整资源限制。

3. 检查网络配置：确保k8s集群的网络配置正确，包括Pod之间的通信、服务访问等。如果网络配置有问题，也可能导致部署失败。

4. 检查依赖关系：确认部署单中的依赖关系是否正确设置。如果某个服务或组件无法正常启动，可能会影响到后续的部署步骤。

5. 重新部署：如果以上方法都无法解决问题，可以尝试重新部署该部署单。在重新部署之前，可以先删除之前的资源对象，确保没有残留的旧资源影响新的部署过程。

您是不是把之前的deploy版本删除了？您在本地执行一下这个：

下列命令假定待发布的工作负载类型为 deployment，预期的名字为 demo-deploy，所处的命名空间为 demo-namespace.

kubectl get rollout demo-deploy -n demo-namespace -o=yaml
根据前一步获取的 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 复本，以避免不必要的资源开销或业务流量导入。
您看一下获取到的yaml里的 deploy名字是什么，补偿后的版本将是 spec 属性中的 targetRevisionName 版本
您可以创建一个同名同配置的0副本的deploy。
如果没办法从其他渠道获取被删除的 deployment 细节，可以通过下面的命令获取基线数据：
kubectl get controllerrevision demo-deploy-v180 -n demo-namespace -o=yaml
kubectl get controllerrevision demo-deploy-v179 -n demo-namespace -o=yaml

ControllerRevision 对象中，包含了曾经发布的工作负载信息，可供参考。
如果需要手工操纵分批发布，请修改 spec 属性下的 batchPartition 字段。请注意，batchPartition 对应分批发布批次计划中的下标，从 0（而不是从 1）开始。此回答整理自钉群“云效交付域答疑群”