#Устранение неполадок кластера, застрявшего в состоянии Deleting

#Область применения

На этой странице рассматривается случай, когда рабочий кластер, созданный ACP, удаляется, все дочерние ресурсы (специфичные для провайдера 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 on Immutable Infrastructure (baremetal Provider)
• Кластеры, созданные через путь SSH UPI и управляемые cluster-manager

Доказательства из прямого наблюдения получены из DCS; остальные провайдеры используют тот же путь control plane для global-кластера.

Не входит в область применения:

• Специфичный для провайдера Machine CR, такой как DCSMachine, застрявший в Deleting, при этом IaaS VM все еще существует — см. Устранение неполадок DCSMachine, застрявшего в Deleting.
• Рабочий кластер, который был импортирован (onboarded как Third-party Cluster) и так и не достиг состояния ready — см. Устранение неполадок рабочего кластера, застрявшего в Provisioned.

#Симптомы

В Cluster CR наблюдается приведенный ниже шаблон.

Финализатор capi.cpaas.io/imported (а также метка capi.cpaas.io/alauda-cluster: imported, если она присутствует) сам по себе не означает, что кластер был импортирован — кластеры, созданные ACP, тоже содержат их. Чтобы различить эти два случая, используйте строку infrastructureRef / controlPlaneRef выше.

#Диагностика

Выполните два приведенных ниже проверки на кластере global, чтобы подтвердить этот шаблон.

Подтвердите, что финализатор capi.cpaas.io/imported по-прежнему присутствует:

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

Подтвердите, что кластер создан ACP. У кластера, созданного ACP, заданы и spec.infrastructureRef, и spec.controlPlaneRef; у Third-party Cluster (onboarded by import) не задано ни одно из них:

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

Если оба значения не пустые (например, infrastructureRef=DCSCluster controlPlaneRef=KubeadmControlPlane), значит кластер создан ACP, и к нему применимо обходное решение на этой странице. Если оба значения пустые, кластер был onboarded как Third-party Cluster; эта страница к нему не относится, и описанное ниже обходное решение использовать нельзя.

#Почему это происходит

Финализатор capi.cpaas.io/imported в Cluster CR управляется контроллером платформы на кластере global. Для кластера, onboarded как Third-party Cluster, этот финализатор освобождается в рамках очистки на стороне платформы при удалении кластера.

Кластер, созданный ACP, использует тот же финализатор. Когда такой кластер удаляется, его дочерние ресурсы и IaaS VM удаляются корректно, но финализатор capi.cpaas.io/imported на верхнеуровневом Cluster CR не освобождается — поэтому CR остается в состоянии Deleting.

Это поведение на уровне платформы, а не ошибка какого-либо провайдера IaaS, и оно не влияет на импортированные кластеры (Third-party). Точная обработка находится в стадии исследования командой платформы.

#Обходное решение

Перед очисткой финализатора убедитесь, что от Cluster CR больше ничего не зависит — все дочерние ресурсы и все IaaS VM должны быть уже удалены.

Шаг 1 — Убедитесь, что все специфичные для провайдера Machine CR в namespace удалены:

# 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-платформе. Используйте соответствующий для провайдера способ проверки:

• DCS: перечислите VM через портал DCS или API DCS и убедитесь, что не осталось ни одной VM этого кластера. См. Создание кластеров на Huawei DCS для соответствующих полей кластера.
• HCS: перечислите VM в портале HCS и убедитесь, что не осталось ни одной.
• vSphere: перечислите VM в vCenter в папке кластера и убедитесь, что не осталось ни одной.
• Bare-metal: убедитесь, что деprovisioning машин завершен в инвентаре bare-metal.

Шаг 3 — Только после того, как Шаг 1 и Шаг 2 оба подтвердят отсутствие оставшихся ресурсов, очистите финализаторы Cluster CR:

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

Cluster CR исчезает немедленно. Поскольку все дочерние ресурсы и все IaaS VM уже были удалены до этого шага, удаление верхнеуровневого финализатора не может оставить сироту — оно лишь очищает маркер, для которого больше нет reconciler, способного его освободить.

#Почему бы просто не подождать?

Финализатор не освобождается по таймеру, и для кластера, созданного ACP, он не освобождается обычным путем очистки на стороне платформы. Ожидание не меняет состояние — были зафиксированы наблюдения более чем за девять часов без какого-либо прогресса. Примените обходное решение после того, как Шаг 1 и Шаг 2 будут подтверждены.

#Постоянное исправление

Исправление должно быть реализовано в control plane кластера global: финализатор capi.cpaas.io/imported должен освобождаться для кластера, созданного ACP, после удаления его дочерних ресурсов. Это отслеживается вне данного набора документации; дата выпуска здесь не зафиксирована. До выхода исправления описанное выше обходное решение остается поддерживаемым способом восстановления.

#См. также

• Устранение неполадок DCSMachine, застрявшего в Deleting — зависание удаления на уровне узла; другая область применения.
• Устранение неполадок рабочего кластера, застрявшего в Provisioned — описывает реальные проблемы при запуске Third-party Cluster; другая область применения.