#排查卡在删除中的集群

#范围

本页面介绍以下情况：一个由 ACP 构建的业务集群正在被删除，所有子资源（特定于 provider 的 Machine CR 以及它们所代表的 IaaS VM）均已删除，但顶层 Cluster CR 仍无限期保留在 Phase: Deleting 中。

本页面适用于任何由 ACP 构建的业务集群，与底层 IaaS 无关：

• Huawei DCS（DCS Provider）
• Huawei Cloud Stack（HCS Provider）
• VMware vSphere（vSphere Provider）
• 裸金属（Bare Metal Provider）
• 通过 SSH UPI 路径创建并由 cluster-manager 管理的集群

直接观察到的证据来自 DCS；其他 provider 共享相同的 global-集群控制平面路径。

不在范围内：

• 特定于 provider 的 Machine CR（例如 DCSMachine）卡在 Deleting 中，而 IaaS VM 仍然存在 — 请参阅排查卡在删除中的 DCSMachine。
• 已导入（作为 Third-party Cluster 接入）但从未达到就绪状态的业务集群 — 请参阅排查卡在 Provisioned 中的业务集群。

#症状

Cluster CR 显示以下模式。

capi.cpaas.io/imported finalizer（以及 capi.cpaas.io/alauda-cluster: imported 标签，如果存在）本身并不意味着该集群已被导入 — 由 ACP 构建的集群也会携带这些内容。请使用上方的 infrastructureRef / controlPlaneRef 行来区分两者。

#诊断

在 global 集群上运行以下两项检查，以确认该模式。

确认 capi.cpaas.io/imported finalizer 仍然存在：

kubectl get cluster <name> -n <ns> -o yaml | grep -A 2 finalizers

确认该集群由 ACP 构建。由 ACP 构建的集群会同时设置 spec.infrastructureRef 和 spec.controlPlaneRef；Third-party Cluster（通过导入接入）则两者均未设置：

kubectl get cluster <name> -n <ns> \
  -o jsonpath='infrastructureRef={.spec.infrastructureRef.kind} controlPlaneRef={.spec.controlPlaneRef.kind}{"\n"}'

如果两个值均非空（例如 infrastructureRef=DCSCluster controlPlaneRef=KubeadmControlPlane），则该集群由 ACP 构建，适用本页中的临时解决方法。如果两个值均为空，则该集群是作为 Third-party Cluster 接入的；本页不适用，且不得使用下方的临时解决方法。

#原因

Cluster CR 上的 capi.cpaas.io/imported finalizer 由 global 集群上的平台 controller 管理。对于作为 Third-party Cluster 接入的集群，移除集群时，该 finalizer 会作为平台侧清理的一部分被释放。

由 ACP 构建的集群也带有相同的 finalizer。删除由 ACP 构建的集群时，其子资源和 IaaS VM 都会被正确移除，但顶层 Cluster CR 上的 capi.cpaas.io/imported finalizer 不会被释放，因此该 CR 会一直处于 Deleting 状态。

这是平台级行为，并非任何 IaaS provider 的故障，也不会影响已导入的（Third-party）集群。平台团队正在调查具体的处理方式。

#临时解决方法

清除 finalizer 之前，请确认没有任何内容依赖 Cluster CR 的持续存在 — 每个子资源和每个 IaaS VM 都必须已经删除。

步骤 1 — 确认命名空间中的所有特定于 provider 的 Machine CR 均已删除：

# Replace dcsmachines with the resource for your provider (hcsmachines, vspheremachines, ...).
kubectl get dcsmachines,hcsmachines,vspheremachines -n <ns>

# Also confirm the higher-level CAPI resources are gone:
kubectl get machines,machinedeployments,kubeadmcontrolplanes,dcsclusters,hcsclusters,vsphereclusters -n <ns>

每条命令对于此集群都必须返回无资源。

步骤 2 — 确认集群的 VM 已从 IaaS 平台中删除。 使用特定于 provider 的验证方法：

• DCS：通过 DCS 门户或 DCS API 列出 VM，并确认集群的 VM 均已不存在。相关集群字段请参阅在 Huawei DCS 上创建集群。
• HCS：在 HCS 门户中列出 VM，并确认均已不存在。
• vSphere：在 vCenter 中集群文件夹下列出 VM，并确认均已不存在。
• 裸金属：确认裸金属清单中的机器取消配置已完成。

步骤 3 — 只有在步骤 1 和步骤 2 均确认没有剩余资源后，才能清除 Cluster CR 的 finalizer：

kubectl patch cluster <name> -n <ns> --type=merge \
  -p '{"metadata":{"finalizers":null}}'

Cluster CR 会立即消失。由于每个子资源和每个 IaaS VM 在此步骤之前都已删除，移除顶层 finalizer 不会遗留孤立资源 — 它只会清除一个已没有任何愿意释放它的 reconciler 的标记。

#为什么不能只是等待？

finalizer 不会在计时器到期后释放；对于由 ACP 构建的集群，正常的平台清理路径也不会释放它。等待不会改变状态 — 已记录有持续九小时或更长时间仍无进展的情况。确认步骤 1 和步骤 2 完成后，请立即应用上述变通方法。

#永久修复

修复应位于 global-cluster 控制平面中：对于由 ACP 构建的集群，一旦其子资源已删除，就必须释放 capi.cpaas.io/imported finalizer。此问题的跟踪在本文档集之外；此处不承诺发布日期。在修复发布之前，上述变通方法是受支持的恢复路径。

#另请参阅

• 排查删除卡住的 DCSMachine — 节点级删除停滞；范围不同。
• 排查卡在 Provisioned 状态的业务集群 — 涵盖真正的 Third-party Cluster 启动问题；范围不同。