Устранение ошибок при развертывании расширений кластера AKS
В этой статье описывается устранение ошибок, возникающих при развертывании расширений кластера для Microsoft Служба Azure Kubernetes (AKS).
Ошибки при создании расширения
Ошибка: не удается получить ответ от агента вовремя
Эта ошибка возникает, если службы Azure не получают ответ от агента расширения кластера. Эта ситуация может произойти, так как кластер AKS не может установить подключение к Azure.
Причина 1. Агент расширения кластера и модули pod диспетчера не инициализированы
Агент расширения кластера и менеджер являются важными системными компонентами, ответственными за управление жизненным циклом приложений Kubernetes. Инициализация агента расширения кластера и модулей pod диспетчера может завершиться ошибкой из-за следующих проблем:
- Ограничения ресурсов
- Ограничения политики
- Запятнания узлов, например
NoSchedule
Решение 1. Убедитесь, что агент расширения кластера и модули pod диспетчера работают правильно.
Чтобы устранить эту проблему, убедитесь, что агент расширения кластера и модули pod диспетчера правильно запланированы и могут запускаться. Если модули pod застряли в непрочитанном состоянии, проверьте описание pod, выполнив следующую kubectl describe pod команду, чтобы получить дополнительные сведения о базовых проблемах (например, фрагменты, которые препятствуют планированию, недостаточному объему памяти или ограничениям политики):
kubectl describe pod -n kube-system extension-operator-{id}
Ниже приведен пример выходных данных команды:
kube-system extension-agent-55d4f4795f-sqx7q 2/2 Running 0 2d19h
kube-system extension-operator-56c8d5f96c-nvt7x 2/2 Running 0 2d19h
Для кластеров, подключенных к ARC, выполните следующую команду, чтобы проверить описание pod:
kubectl describe pod -n azure-arc extension-manager-{id}
Ниже приведен пример выходных данных команды:
NAMESPACE NAME READY STATUS RESTARTS AGE
azure-arc cluster-metadata-operator-744f8bfbd4-7pssr 0/2 ImagePullBackOff 0 6d19h
azure-arc clusterconnect-agent-7557d99d5c-rtgqh 0/3 ImagePullBackOff 0 6d19h
azure-arc clusteridentityoperator-9b8b88f97-nr8hf 0/2 ImagePullBackOff 0 6d19h
azure-arc config-agent-6d5fd59b8b-khw2d 0/2 ImagePullBackOff 0 6d19h
azure-arc controller-manager-5bc97f7db6-rt2zs 0/2 ImagePullBackOff 0 6d19h
azure-arc extension-events-collector-7596688867-sqzv2 0/2 ImagePullBackOff 0 6d19h
azure-arc extension-manager-86bbb949-6s59q 0/3 ImagePullBackOff 0 6d19h
azure-arc flux-logs-agent-5f55888db9-wnr4c 0/1 ImagePullBackOff 0 6d19h
azure-arc kube-aad-proxy-646c475dcc-92b86 0/2 ImagePullBackOff 0 6d19h
azure-arc logcollector-5cbc659bfb-9v96d 0/1 ImagePullBackOff 0 6d19h
azure-arc metrics-agent-5794866b46-j9949 0/2 ImagePullBackOff 0 6d19h
azure-arc resource-sync-agent-6cf4cf7486-flgwc 0/2 ImagePullBackOff 0 6d19h
Когда агент расширения кластера и модули pod диспетчера работают и работоспособны, они устанавливают связь со службами Azure для установки приложений Kubernetes и управления ими.
Причина 2. Проблема влияет на блок исходящего трафика или брандмауэр
Если агент расширения кластера и модули pod диспетчера работоспособны, и вы по-прежнему столкнулись с ошибкой "Не удается получить ответ от агента вовремя", вероятно, существует проблема с исходящим трафиком или брандмауэром. Эта проблема может заблокировать взаимодействие агента расширения кластера и модулей pod диспетчера с Azure.
Решение 2. Убедитесь, что выполнены предварительные требования к сети
Чтобы устранить эту проблему, убедитесь, что вы следуйте предварительным требованиям сети, описанным в правилах исходящей сети и полное доменное имя для кластеров Служба Azure Kubernetes (AKS).
Причина 3. Трафик не авторизован
Агент расширения безуспешно пытается вызвать <region>.dp.kubernetesconfiguration.azure.com конечные точки службы плоскости данных. Этот сбой создает запись "Код ошибки: 403, сообщение об этом трафике не авторизовано" в журналах pod агента расширения.
kubectl logs -n kube-system extension-agent-<pod-guid>
{ "Message": "2024/02/07 06:04:43 \"Errorcode: 403, Message This traffic is not authorized., Target /subscriptions/<subscription-id>/resourceGroups/<resource-group-name>/provider/managedclusters/clusters/<cluster-name>/configurations/getPendingConfigs\"", "LogType": "ConfigAgentTrace", "LogLevel": "Information", "Environment": "prod", "Role": "ClusterConfigAgent", "Location": "<region>, "ArmId": "/subscriptions/<subscription-id>/resourceGroups/<resource-group-name>/providers/Microsoft.ContainerService/managedclusters/<cluster-name>", "CorrelationId": "", "AgentName": "ConfigAgent", "AgentVersion": "1.14.5", "AgentTimestamp": "2024/02/07 06:04:43.672" }
{ "Message": "2024/02/07 06:04:43 Failed to GET configurations with err : {\u003cnil\u003e}", "LogType": "ConfigAgentTrace", "LogLevel": "Information", "Environment": "prod", "Role": "ClusterConfigAgent", "Location": "<region>", "ArmId": "/subscriptions/<subscription-id>/resourceGroups/<resource-group-name>/providers/Microsoft.ContainerService/managedclusters/<cluster-name>", "CorrelationId": "", "AgentName": "ConfigAgent", "AgentVersion": "1.14.5", "AgentTimestamp": "2024/02/07 06:04:43.672" }
Эта ошибка возникает, если существующий PrivateLinkScope существует в плоскости данных расширения для Kubernetes с поддержкой Azure Arc, а виртуальная сеть (или частный DNS-сервер) совместно используется между Kubernetes с поддержкой Azure Arc и управляемым кластером AKS. Эта конфигурация сети приводит к тому, что исходящий трафик AKS из плоскости данных расширения также направляется через тот же частный IP-адрес, а не через общедоступный IP-адрес.
Выполните следующую команду nslookup в кластере AKS, чтобы получить конкретный частный IP-адрес, на который разрешается конечная точка плоскости данных:
PS D:\> kubectl exec -it -n kube-system extension-agent-<pod-guid> -- nslookup <region>.dp.kubernetesconfiguration.azure.com
Non-authoritative answer:
<region>.dp.kubernetesconfiguration.azure.com canonical name = <region>.privatelink.dp.kubernetesconfiguration.azure.com
Name: <region>.privatelink.dp.kubernetesconfiguration.azure.com
Address: 10.224.1.184
При поиске частного IP-адреса в портал Azure результаты поиска указывают на точный ресурс: виртуальную сеть, частную зону DNS, частный DNS-сервер и т. д. Этот ресурс имеет частную конечную точку, настроенную для плоскости данных расширения для Kubernetes с поддержкой Azure Arc.
Решение 3.1. Создание отдельных виртуальных сетей
Чтобы устранить эту проблему, рекомендуется создать отдельные виртуальные сети для вычислений Kubernetes с поддержкой Azure Arc и AKS.
Решение 3.2. Создание переопределения CoreDNS
Если рекомендуемое решение невозможно в вашей ситуации, создайте переопределение CoreDNS для конечной точки плоскости расширений для перехода по общедоступной сети. Дополнительные сведения о настройке CoreDNS см. в разделе "Подключаемый модуль hosts" статьи "Настройка CoreDNS с помощью Служба Azure Kubernetes".
Чтобы создать переопределение CoreDNS, выполните следующие действия.
Найдите общедоступный IP-адрес конечной точки плоскости данных расширения, выполнив
nslookupкоманду. Убедитесь, что вы измените регион (например,eastus2euap) в зависимости от расположения кластера AKS:nslookup <region>.dp.kubernetesconfiguration.azure.com Non-authoritative answer: Name: clusterconfig<region>.<region>.cloudapp.azure.com Address: 20.39.12.229 Aliases: <region>.dp.kubernetesconfiguration.azure.com <region>.privatelink.dp.kubernetesconfiguration.azure.com <region>.dp.kubernetesconfiguration.trafficmanager.netСоздайте резервную копию существующей конфигурации coreDNS:
kubectl get configmap -n kube-system coredns-custom -o yaml > coredns.backup.yamlПереопределите сопоставление для региональной конечной
eastus2euapточки плоскости данных на общедоступный IP-адрес. Для этого создайте файл YAML с именем corednsms.yaml, а затем скопируйте следующую конфигурацию в новый файл. (Убедитесь, что вы обновляете адрес и имя узла с помощью значений среды.)apiVersion: v1 kind: ConfigMap metadata: name: coredns-custom # This is the name of the configuration map that you can overwrite with your changes. namespace: kube-system data: extensionsdp.override: | # You can select any name here, but it must have the .override file name extension. hosts { 20.39.12.229 <region>.dp.kubernetesconfiguration.azure.com fallthrough }Чтобы создать ConfigMap, выполните
kubectl applyкоманду, указав имя файла манифеста YAML:kubectl apply -f corednsms.yamlЧтобы перезагрузить ConfigMap и включить планировщик Kubernetes для перезапуска CoreDNS без простоя, выполните команду перезапуска развертывания kubectl:
kubectl -n kube-system rollout restart deployment corednsnslookupВыполните команду еще раз, чтобы убедиться, что конечная точка плоскости данных разрешает указанный общедоступный IP-адрес:kubectl exec -it -n kube-system extension-agent-55d4f4795f-nld9q -- nslookup [region].dp.kubernetesconfiguration.azure.com Name: <region>.dp.kubernetesconfiguration.azure.com Address: 20.39.12.229
Журналы pod агента расширения больше не должны регистрировать "Errorcode: 403, message This traffic not authorized" error entries. Вместо этого журналы должны содержать коды откликов "200".
kubectl logs -n kube-system extension-agent-{id}
{ "Message": "GET configurations returned response code {200}", "LogType": "ConfigAgentTrace", "LogLevel": "Information", "Environment": "prod", "Role": "ClusterConfigAgent", "Location": "<region>", "ArmId": "/subscriptions/<subscription-id>/resourceGroups/<resource-group-name>/providers/Microsoft.ContainerService/managedclusters/<cluster-name>", "CorrelationId": "", "AgentName": "ConfigAgent", "AgentVersion": "1.14.5" }
Ошибка. Модули pod расширения не могут быть запланированы, если все пулы узлов в кластере не заданы "CriticalAddonsOnly"
При возникновении этой ошибки в журнал агента расширения регистрируется следующая запись:
Ошибка модуля pod: 0/2 узла доступны: 2 узла были неустрачены испорчены {CriticalAddonsOnly: true}. preemption: 0/2 узла доступны: 2 preemption не полезно для планирования.
Причина
Эта ошибка возникает при попытке включения расширений (таких как распределенная среда выполнения приложений (DAPR)) в кластере AKS, который содержит CriticalAddonsOnly запятнаные пулы узлов. В этой ситуации модули pod расширения не запланированы на любом узле, так как для этих отметок нет толерации.
Чтобы просмотреть ситуацию с ошибкой, проверьте модули pod расширения, чтобы убедиться, что они застряли в состоянии ожидания:
kubectl get po -n {namespace-name} -l app.kubernetes.io/name={name}
NAME READY STATUS RESTARTS AGE
{podname} 0/2 Pending 0 2d6h
Описать модули pod, чтобы увидеть, что они не могут быть запланированы из-за неподдерживаемого оттенка:
kubectl describe po -n {namespace-name} {podname}
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Warning FailedScheduling 18s default-scheduler 0/2 nodes are available: 2 node(s) had untolerated taint {CriticalAddonsOnly: true}. preemption: 0/2 nodes are available: 2 Preemption is not helpful for scheduling.
Примечание.
Рекомендуется не устанавливать расширения на
CriticalAddOnsOnlyнеуправляемых пулах узлов, если это не требуется для рабочих нагрузок приложений.Рекомендуется не использовать запятую
CriticalAddOnsOnlyв кластерах пула узлов. Если вы используете этот фрагмент в кластере с одним пулом узлов, вы не можете запланировать модули pod приложений в кластере. Убедитесь, что хотя бы один пул узлов в кластере не имеет этого значения. Дополнительные сведения обCriticalAddonsOnlyиспользовании заметки см. в разделе "Управление пулами системных узлов" в Служба Azure Kubernetes (AKS).
Решение 1. Добавление пула узлов в кластер
Чтобы устранить эту проблему, добавьте еще один пул узлов, который не имеет недостатка CriticalAddonsOnly . Это действие приводит к планированию модулей pod расширения в новом пуле узлов.
Решение 2. Удалите "Критическое значениеAddonsOnly"
Если это возможно и практически, можно удалить CriticalAddonsOnly ненамеренно, чтобы установить расширение в кластере.
Ошибки Helm
Вы можете столкнуться со следующими ошибками, связанными с Helm:
- Истекло время ожидания готовности ресурса
- Не удалось скачать диаграмму Helm по URL-адресу репозитория
- Сбой отображения диаграммы Helm с заданными значениями
- Ресурс уже существует в кластере
- Операция уже выполняется для Helm
Ошибка: время ожидания готовности к ресурсу
Установка приложения Kubernetes завершается ошибкой и отображает следующие сообщения об ошибках:
сбой задания: BackoffLimitExceeded
Время ожидания выхода ресурса в готовое или завершенное состояние.
Причина
Эта проблема имеет следующие распространенные причины:
Ограничения ресурсов: неадекватная память или ресурсы ЦП в кластере могут препятствовать успешной инициализации модулей pod, заданий или других ресурсов Kubernetes. В конечном итоге эта ситуация приводит к истечении времени ожидания установки. Ограничения политики или ограничения узлов (например
NoSchedule, ) также могут блокировать инициализацию ресурсов.Несоответствия архитектуры. Попытка запланировать приложение на основе Linux на узле под управлением Windows (или наоборот) может вызвать сбои в инициализации ресурсов Kubernetes.
Неправильные параметры конфигурации: неправильные параметры конфигурации могут препятствовать запуску модулей pod.
Решение
Устранить проблему можно так:
Проверьте ресурсы. Убедитесь, что кластер Kubernetes имеет достаточные ресурсы, и что планирование pod разрешено на узлах (следует учитывать ограничения). Убедитесь, что ресурсы памяти и ЦП соответствуют требованиям.
Проверка событий. Проверьте события в пространстве имен Kubernetes, чтобы определить потенциальные проблемы, которые могут препятствовать pod, заданиям или другим ресурсам Kubernetes достичь готового состояния.
Проверьте диаграммы и конфигурации Helm: многие приложения Kubernetes используют диаграммы Helm для развертывания ресурсов в кластере. Для некоторых приложений может потребоваться ввод пользователей с помощью параметров конфигурации. Убедитесь, что все указанные значения конфигурации являются точными и соответствуют требованиям к установке.
Ошибка. Не удалось скачать диаграмму Helm из URL-адреса репозитория
Эта ошибка вызвана проблемами подключения, возникающими между кластером и брандмауэром, а также проблемами с блокировкой исходящего трафика. Чтобы устранить эту проблему, ознакомьтесь с правилами исходящей сети и полного доменного имени для кластеров Служба Azure Kubernetes (AKS).
Ошибка: сбой отрисовки диаграммы Helm с заданными значениями
Эта ошибка возникает, если приложения Kubernetes используют диаграммы Helm для развертывания ресурсов в кластере Kubernetes. Для этих приложений может потребоваться ввод пользователей, предоставляемый с помощью параметров конфигурации, передаваемых в качестве значений Helm во время установки. Если какие-либо из этих важных параметров конфигурации отсутствуют или неверны, диаграмма Helm может не отображаться.
Чтобы устранить эту проблему, ознакомьтесь с документацией по расширению или приложению, чтобы определить, были ли пропущены какие-либо обязательные значения или указаны неверные значения во время установки приложения. Эти рекомендации помогут устранить проблемы с отрисовкой диаграмм Helm, вызванные отсутствием или неточными значениями конфигурации.
Ошибка: ресурс уже существует в кластере
Эта ошибка возникает, если конфликт существует между ресурсами Kubernetes в кластере и ресурсами Kubernetes, которые приложение пытается установить. Обычно сообщение об ошибке указывает имя конфликтующего ресурса.
Если конфликтующий ресурс является важным и не может быть заменен, возможно, вы не сможете установить приложение. Если ресурс не является критическим и его можно удалить, удалите конфликтующий ресурс и повторите установку.
Ошибка: операция уже выполняется для Helm
Эта ошибка возникает, если операция уже выполняется для определенного выпуска. Чтобы устранить эту проблему, подождите 10 минут, а затем повторите операцию.
Свяжитесь с нами для получения помощи
Если у вас есть вопросы или вам нужна помощь, создайте запрос в службу поддержки или обратитесь за поддержкой сообщества Azure. Вы также можете отправить отзыв о продукте в сообщество отзывов Azure.