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

Статья
11/19/2024

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

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

Azure CLI

Симптомы

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

Причина

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

Чтобы лучше понять текущий сбой в кластере, выполните команды 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
```
Проверьте выходные данные отладки и сообщения об ошибках, полученные из az resource update команды, в вспомогательном исполняемом файле CSE на GitHub.

Если какая-либо из ошибок связана с развертыванием csE kubelet, то вы проверили, что сценарий, описанный ниже, является причиной сбоя 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.
Проверьте сам узел, чтобы узнать, есть ли в узле другая NSG, блокирующая трафик.
Проверьте подсеть AKS на наличие назначенной таблицы маршрутизации. Если в таблице маршрутизации есть виртуальный модуль сети (NVA) или брандмауэр, убедитесь, что порт 443 доступен для исходящего трафика. Дополнительные сведения см. в разделе "Управление исходящим трафиком" для узлов кластера в AKS.

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

Тип набора	Действие
Группа доступности виртуальной машины	Удалите узел из портал Azure и API AKS с помощью команды kubectl delete node, а затем снова масштабируйте кластер.
Масштабируемый набор виртуальных машин	Повторное создание образа узла из портал Azure или удаление узла, а затем повторное масштабирование кластера. Чтобы удалить конкретный узел, используйте команду az aks nodepool delete-machines . Сначала он будет оцеплен и сбоем, а затем удаляет узел.

Тип набора

Действие

Группа доступности виртуальной машины

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

Масштабируемый набор виртуальных машин

Повторное создание образа узла из портал Azure или удаление узла, а затем повторное масштабирование кластера. Чтобы удалить конкретный узел, используйте команду az aks nodepool delete-machines . Сначала он будет оцеплен и сбоем, а затем удаляет узел.

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

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

Общие инструкции по устранению неполадок см. в разделе "Базовый" по устранению неполадок с ошибками node Not Ready.

Поделиться через