Траблшутинг создания кластера

Кластер зависает в состоянии Provisioning #

• Проверьте логи CAPI-провайдера и машин в кластере управления;
• Убедитесь, что провайдер может создавать ВМ или подключаться к хостам;
• Проверьте квоты и лимиты в среде провайдера и сопоставьте их с требованиями к ресурсам клиентского кластера.

Ошибка при создании ВМ #

Ожидаемая последовательность создания узлов из шаблона и связь шаблонов с кластером описаны на странице Создание узлов при развертывании клиентского кластера.

• Проверьте шаблон ВМ и его доступность;
• Проверьте права учётной записи провайдера.

См. раздел «Траблшутинг провайдеров».

Узлы не переходят в Ready #

• Подключитесь к узлу по SSH и проверьте состояние kubelet, containerd;
• Проверьте сетевое подключение между узлами и к API-серверу;
• Просмотрите логи bootstrap-провайдера.

Клиентский кластер завис на инициализации ControlPlane #

Если в дашборде развертывания кластера процесс создания клиентского кластера остановился на этапе инициализации ControlPlane-узлов и есть ошибки вида:

• Control plane components: Waiting for Cluster control plane to be initialized
• EtcdMemberHealthy: Waiting for Cluster control plane to be initialized
• InfrastructureReady: Ошибка установки ProviderID для узла

— Проверьте статус ресурса ClusterConfig этого кластера.

ClusterConfig — кастомный ресурс API-группы cluster.shturval.tech, в котором хранится конфигурация и статус инициализации кластера. Если в нём есть ошибки или conditions не в состоянии True, ControlPlane не сможет завершить инициализацию.

Где найти ClusterConfig #

kubectl -n <ИМЯ-КЛАСТЕРА> get clusterconfig <ИМЯ-КЛАСТЕРА> -o yaml

На что смотреть в статусе ClusterConfig #

• Conditions: все ли условия в состоянии True; если есть False — в сообщении будет указана причина.
• Status / Ready: готов ли ресурс.

Если в ClusterConfig есть ошибочные условия или статус не Ready — это и есть первопричина того, почему ControlPlane-узлы не инициализируются, а все зависимые проверки (NodeHealthy, EtcdMemberHealthy и т.д.) остаются в Waiting.

Нет свободных IP в пуле #

• Добавьте адреса в пул или создайте новый пул;
• Освободите неиспользуемые адреса из удалённых кластеров.

VIP для API-сервера или Ingress уже занят #

При создании кластера платформа проверяет доступность адресов, которые вы указали для KubeAPI и Ingress. Если адрес уже используется в сети, развёртывание может завершиться ошибкой на этапе создания кластера.

Как проверить #

Проверку выполняйте из той же сетевой зоны, откуда платформа разворачивает клиентский кластер: подключитесь по SSH к узлу кластера управления, на котором запущен под shturval-backend, и проверьте нужные порты.

nc <IP-АДРЕС-KUBEAPI> 6443 -v -w 5

curl -k https://<IP-АДРЕС-KUBEAPI>:6443

nc <VIP-АДРЕС-INGRESS> 443 -v -w 5

curl -k https://<VIP-АДРЕС-INGRESS>:443

Если в ответе есть Connection refused или Forbidden, адрес уже отвечает в сети и его нельзя использовать как свободный VIP для нового кластера. Освободите адрес, выберите другой VIP или расширьте пул IP-адресов, затем повторите создание кластера.

Ошибка из-за сети или пересечения подсетей #

• См. Проверка пересечения подсетей при создании кластера — узловая сеть, Pod/Service CIDR, VIP и пул IP.