Immutable Infrastructure
  • Русский

    • Устранение неполадок в кластерах рабочих нагрузок Huawei Cloud Stack

    Это руководство описывает сценарии устранения неполадок, специфичные для кластеров рабочих нагрузок Huawei Cloud Stack (HCS), управляемых через Cluster API.

    Если ваш кластер достигает Cluster.status.phase = Provisioned, но поток импорта не завершается, а узлы рабочих нагрузок остаются в состоянии NotReady, потому что отсутствует CNI, начните с независимого от провайдера руководства Устранение неполадок в кластере рабочих нагрузок, застрявшем в состоянии Provisioned. В этом руководстве описан общий диагностический поток (global controller импорта кластера, sentry ServiceAccount, инварианты clusters.platform.tkestack.io) для любого провайдера Immutable Infrastructure.

    Если вы уже завершили общий поток и при этом также наблюдаются симптомы ниже, см. специфичный для HCS сценарий на этой странице.

    Содержание

    Сценарий: kubeadm init никогда не завершается, потому что имя хоста указано неверноДиагностикаМеры по устранениюПрофилактикаСвязанные материалы

    Сценарий: kubeadm init никогда не завершается, потому что имя хоста указано неверно

    Симптомы — все проявляются одновременно:

    • Cluster.status.phase=Provisioned, HCSCluster.status.ready=true, ELB поднят.
    • HCSMachine.status.instanceState=ACTIVE с заполненным InternalIP, но Machine.status.nodeRef так и не устанавливается.
    • KubeadmControlPlane.status.initialized остается пустым, а status.readyReplicas=0 по истечении обычного окна инициализации, составляющего примерно 5–10 минут.
    • Логи контроллера cluster-api-provider-hcs (в cpaas-system) repeatedly выводят connect: connection refused при обращении к VIP ELB управляющей плоскости на порт 6443.
    • Значение HCSMachineConfigPool.spec.configs[].hostname, выбранное для узла, содержит точку (в стиле FQDN, например master-1.example.org).

    В выпусках cluster-api-provider-hcs ранее v1.0.1 значение HCSMachineConfigPool.spec.configs[].hostname с точкой рендерится в cloud-init как полная строка FQDN в поле hostname с prefer_fqdn_over_hostname: true. В результате на узле получается имя хоста POSIX, содержащее точки, с которым kubeadm init не справляется, поэтому kube-apiserver так и не запускается.

    Диагностика

    Если у вас есть доступ к узлу (консоль HCS, jump host или debug pod внутри кластера):

    # On the affected node
hostname
hostname -f
cat /etc/hosts
sudo cat /var/lib/cloud/instance/user-data.txt | head -40
sudo journalctl -u cloud-init -b 0 | grep -E "hostname|fqdn|update_etc_hosts"

    Признаки того, что вы столкнулись именно с этим сценарием:

    • hostname возвращает полную строку с точками, а не только короткое имя.
    • hostname -f возвращает Name or service not known или Temporary failure in name resolution.
    • В /etc/hosts нет строки вида <node-ip> <fqdn> <short>.
    • Пользовательские данные cloud-init на узле показывают prefer_fqdn_over_hostname: true и не задают manage_etc_hosts.

    Меры по устранению

    Обновите плагин cluster-api-provider-hcs до v1.0.1 или более поздней версии, затем выполните поочередную замену затронутых control plane и worker-узлов, чтобы новый cloud-init был выполнен на недавно загруженных VM. Пошаговая процедура описана в Настройка FQDN Hostname на существующих кластерах HCS.

    Ручные изменения файлов /etc/hostname и /etc/hosts на существующем узле с неизменяемой ОС не сохраняются: cloud-init заново формирует эти файлы при каждой загрузке, включая перезагрузки, вызванные transactional-update, обновлением ОС или systemctl reboot. Поддерживаемый путь миграции — поочередная замена узлов.

    Профилактика

    Повторный запуск создания кластера при уже установленном cluster-api-provider-hcs версии v1.0.1 или более поздней полностью исключает этот сценарий. Новые манифесты для HCS должны следовать разделу Поведение имени хоста на узле на странице создания кластера при выборе между FQDN и короткими именами хостов в HCSMachineConfigPool.

    Связанные материалы