Устранение неполадок при сбое узла, не готового к работе, вызванного ошибками CSE

  • Статья

Эта статья поможет устранить неполадки в сценариях, когда кластер Microsoft Служба Azure Kubernetes (AKS) не находится в Succeeded состоянии и узел AKS не готов в пуле узлов из-за ошибок расширения пользовательских сценариев (CSE).

Предварительные требования

Симптомы

Из-за ошибок CSE узел кластера AKS не готов в пуле узлов, и кластер AKS не находится в Succeeded состоянии .

Причина

Развертывание расширения узла завершается сбоем и возвращает несколько кодов ошибок при подготовке kubelet и других компонентов. Это наиболее распространенная причина ошибок. Чтобы убедиться, что развертывание расширения узла завершается сбоем при подготовке kubelet, выполните следующие действия.

  1. Чтобы лучше понять текущий сбой в кластере, выполните команды az aks show и az resource update , чтобы настроить отладку:

    clusterResourceId=$(az aks show \
    --resource-group <resource-group-name> --name <cluster-name> --output tsv --query id)
az resource update --debug --verbose --ids $clusterResourceId

  2. Проверьте выходные данные отладки и сообщения об ошибках, полученные от az resource update команды, в списке ошибок в исполняемом файле вспомогательного компонента CSE на сайте GitHub.

Если какая-либо из ошибок связана с развертыванием kubelet cse, то вы убедились, что описанный здесь сценарий является причиной сбоя Node Not Ready.

Как правило, коды выхода определяют конкретную проблему, которая вызывает сбой. Например, вы увидите такие сообщения, как "Не удается связаться с сервером API" или "Не удается подключиться к Интернету". Кроме того, коды выхода могут оповещать вас об истечении времени ожидания сети API или об ошибке узла, который требует замены.

Решение 1. Убедитесь, что пользовательский DNS-сервер настроен правильно

Настройте личный dns-сервер, чтобы он правильно разрешал имена. Настройте сервер в соответствии со следующими требованиями:

  • Если вы используете пользовательские DNS-серверы, убедитесь, что они работоспособны и доступны по сети.

  • Убедитесь, что пользовательские DNS-серверы имеют необходимые условные серверы пересылки на IP-адрес Azure DNS (или на этот адрес).

  • Убедитесь, что частная зона DNS AKS связана с пользовательскими виртуальными сетями DNS, если они размещены в Azure.

  • Не используйте IP-адрес Azure DNS с IP-адресами настраиваемого DNS-сервера. Делать это не рекомендуется.

  • Избегайте использования IP-адресов вместо DNS-сервера в параметрах DNS. Команды Azure CLI можно использовать для проверка в этой ситуации в масштабируемом наборе виртуальных машин или группе доступности.

    • Для узлов масштабируемого набора виртуальных машин используйте команду az vmss run-command invoke :

      az vmss run-command invoke \
    --resource-group <resource-group-name> \
    --name <vm-scale-set-name> \
    --command-id RunShellScript \
    --instance-id 0 \
    --output tsv \
    --query "value[0].message" \
    --scripts "telnet <dns-ip-address> 53"
az vmss run-command invoke \
    --resource-group <resource-group-name> \
    --name <vm-scale-set-name> \
    --instance-id 0 \
    --command-id RunShellScript \
    --output tsv \
    --query "value[0].message" \
    --scripts "nslookup <api-fqdn> <dns-ip-address>"

    • Для узлов группы доступности виртуальных машин используйте команду az vm run-command invoke :

      az vm run-command invoke \
    --resource-group <resource-group-name> \
    --name <vm-availability-set-name> \
    --command-id RunShellScript \
    --output tsv \
    --query "value[0].message" \
    --scripts "telnet <dns-ip-address> 53"
az vm run-command invoke \
    --resource-group <resource-group-name> \
    --name <vm-availability-set-name> \
    --command-id RunShellScript \
    --output tsv \
    --query "value[0].message" \
    --scripts "nslookup <api-fqdn> <dns-ip-address>"

Дополнительные сведения см. в статье Разрешение имен для ресурсов в виртуальных сетях Azure и концентраторе и с помощью пользовательской службы DNS.

Решение 2. Исправление тайм-аутов сети API

Убедитесь, что сервер API доступен и не подвержен задержкам. Для этого выполните следующие действия:

  • Проверьте подсеть AKS, чтобы узнать, блокирует ли назначенная группа безопасности сети (NSG) исходящий трафик через порт 443 на сервер API.

  • Проверьте сам узел, чтобы узнать, есть ли у узла другая группа безопасности сети, которая блокирует трафик.

  • Проверьте подсеть AKS на наличие любой назначенной таблицы маршрутов. Если таблица маршрутов имеет виртуальный сетевой (модуль) (NVA) или брандмауэр, убедитесь, что порт 443 доступен для исходящего трафика. Дополнительные сведения см. в разделе Управление исходящим трафиком для узлов кластера в AKS.

  • Если DNS успешно разрешает имена и API доступен, но csE узла завершился сбоем из-за истечения времени ожидания API, выполните соответствующее действие, как показано в следующей таблице.

    Задать тип Действие
    Группа доступности виртуальных машин Удалите узел из портал Azure и API AKS с помощью команды kubectl delete node, а затем снова масштабируйте кластер.
    Масштабируемый набор виртуальных машин Создайте повторное создание образа узла или удалите его, а затем снова масштабируйте кластер.

  • Если запросы регулируются сервером API AKS, выполните обновление до более высокого уровня служб. Дополнительные сведения см. в разделе Соглашение об уровне обслуживания по времени безотказной работы AKS.

Дополнительная информация