Базовое устранение неполадок при создании кластера AKS
В этой статье описаны основные методы устранения неполадок, которые следует использовать, если не удается создать или развернуть кластер Microsoft Служба Azure Kubernetes (AKS).
Предварительные требования
Azure CLI (версия 2.0.59 или более поздняя версия).
Средство Kubernetes kubectl . Чтобы установить kubectl с помощью Azure CLI, выполните команду az aks install-cli .
Просмотр ошибок из Azure CLI
При создании кластеров с помощью Azure CLI ошибки записываются как выходные данные в случае сбоя операции. Вот как команда, входные данные пользователя и выходные данные операции могут отображаться в консоли Bash:
$ az aks create --resource-group myResourceGroup \
> --name MyManagedCluster \
> --load-balancer-sku standard \
> --vnet-subnet-id /subscriptions/01234567-89ab-cdef-0123-456789abcdef/resourceGroups/myResourceGroup/providers/Microsoft.Network/virtualNetworks/aks_demo_vnet/subnets/AKS
It is highly recommended to use USER assigned identity (option --assign-identity) when you want to bring you own subnet, which will have no latency for the role assignment to take effect. When you SYSTEM assigned identity, azure-cli will grant Network Contributor role to the system assigned identity after the cluster is created, and the role assignment will take some time to take effect, see https://learn.microsoft.com/azure/aks/use-managed-identity, proceed to create cluster with system assigned identity? (y/N): y
(ControlPlaneAddOnsNotReady) Pods not in Running status: konnectivity-agent-67f7f5554f-nsw2g,konnectivity-agent-8686cb54fd-xlsgk,metrics-server-6bc97b47f7-dfhbr,coredns-845757d86-7xjqb,coredns-autoscaler-5f85dc856b-mxkrj
Code: ControlPlaneAddOnsNotReady
Message: Pods not in Running status: konnectivity-agent-67f7f5554f-nsw2g,konnectivity-agent-8686cb54fd-xlsgk,metrics-server-6bc97b47f7-dfhbr,coredns-845757d86-7xjqb,coredns-autoscaler-5f85dc856b-mxkrj
Эти ошибки часто содержат подробное описание того, что пошло не так при создании кластера, и содержат ссылки на статьи, содержащие дополнительные сведения. Кроме того, вы можете использовать наши статьи по устранению неполадок в качестве справки на основе ошибки, возникающей при операции Azure CLI.
Просмотр сведений об ошибке в портал Azure
Чтобы просмотреть сведения об ошибках в портал Azure, изучите журнал действий Azure. Чтобы найти список журналов действий в портал Azure, выполните поиск по журналу действий. Или выберите Уведомления (значок колокольчика), а затем выберите Дополнительные события в журнале действий.
Список журналов на странице Журнал действий содержит строку, в которой значение столбца Имя операции называется Создание или обновление управляемого кластера. Для соответствующего события, инициированного значением столбца, задается имя рабочей или учебной учетной записи. Если операция выполнена успешно, в столбце Состояниеотображается значение Принято. Вы также увидите записи о субоперации для создания компонентов кластера, например следующие имена операций:
- Создание или обновление таблицы маршрутов
- Создание или обновление группы безопасности сети
- Обновление создания удостоверения, назначаемого пользователем
- Создание или обновление Load Balancer
- Создание или обновление общедоступного IP-адреса
- Создание назначения ролей
- Обновление группы ресурсов
В этих записях субоперации для параметра Состояниезадано значение Успешно, а для поля Событие, инициированное с помощью , задано значение AzureContainerService.
Что делать, если произошла ошибка? В этом случае в поле Состояние операции создания или обновления управляемого кластераотображается сбой. В отличие от операций по созданию компонентов кластера, здесь необходимо развернуть запись неудачной операции, чтобы просмотреть записи субоперации. Типичными именами субоперации являются действия политики, такие как действие политики аудита и действие политики auditIfNotExists. Некоторые из субопераций будут по-прежнему показывать, что они были успешными.
Для дальнейшего изучения можно выбрать одну из неудачных субопераций. Откроется боковая панель, где можно просмотреть дополнительные сведения о субоперации. Вы можете устранять неполадки со значениями для таких полей, как Сводка, JSON и Журнал изменений. Поле JSON содержит выходной текст для ошибки в формате JSON и обычно предоставляет наиболее полезные сведения.
Просмотр аналитики кластера
Был ли кластер создан в портал Azure и отображается ли он там? Если это верно, вы можете создать аналитику кластера, которая поможет устранить неполадки. Чтобы получить доступ к этой функции, выполните следующие действия.
В портал Azure найдите и выберите Службы Kubernetes.
Выберите имя кластера AKS.
В области навигации на странице кластера AKS выберите Диагностика и решение проблем.
На странице Диагностика и решение проблем выберите ссылку Аналитика кластера . Средство аналитики кластера анализирует кластер, а затем предоставляет список его результатов в разделе Наблюдения и решения на странице Аналитика кластера .
Выберите один из результатов, чтобы просмотреть дополнительные сведения о проблеме и ее возможных решениях.
Просмотр ресурсов в портал Azure
В портал Azure может потребоваться просмотреть ресурсы, созданные при создании кластера. Как правило, эти ресурсы находятся в группе ресурсов, которая начинается с MC_. Группа ресурсов управляемого кластера может иметь такое имя, как MC_MyResourceGroup_MyManagedCluster_<location-code>. Однако имя может отличаться, если вы создали кластер с помощью настраиваемой группы ресурсов кластера.
Чтобы найти группу ресурсов, найдите и выберите Группы ресурсов в портал Azure, а затем выберите группу ресурсов, в которой был создан кластер. Список ресурсов отображается на странице Обзор группы ресурсов.
Предупреждение
Рекомендуется не изменять ресурсы в группе ресурсов MC_ . Это действие может привести к нежелательным последствиям для кластера AKS.
Чтобы проверить состояние масштабируемого набора виртуальных машин, можно выбрать имя масштабируемого набора в списке ресурсов для группы ресурсов. У него может быть имя , похожее на aks-nodepool1-12345678-vmss, и у него будет значение Typeв масштабируемом наборе виртуальных машин. Состояние масштабируемого набора отображается в верхней части страницы обзор пула узлов, а дополнительные сведения — в заголовке Essentials. Если развертывание завершилось неудачно, отображается состояние Сбой.
Для всех ресурсов можно просмотреть сведения, чтобы лучше понять, почему развертывание завершилось сбоем. Для масштабируемого набора можно выбрать текст Состояние сбоя , чтобы просмотреть сведения о сбое. Сведения находятся в строке, содержащей столбцы Состояние, Уровень и Код . В следующем примере показана строка значений столбцов.
Столбец | Пример значения |
---|---|
Состояние | Сбой подготовки |
Level | Ошибка |
Код | ProvisioningState/failed/VMExtensionProvisioningError |
Выберите строку, чтобы увидеть поле Сообщение . Он содержит еще больше сведений об этом сбое. Например, поле Сообщение для строки примера начинается со следующего текста:
Виртуальная машина сообщила о сбое при обработке расширения "vmssCSE". Сообщение об ошибке: "Не удалось выполнить команду: команда завершилась с состоянием выхода=50 [stdout] [stderr] 0 0 0 --:
Вооружившись этой информацией, можно сделать вывод о том, что виртуальные машины в масштабируемом наборе завершили сбой и создали состояние выхода 50.
Примечание.
Если развертывание кластера не достигло точки создания этих ресурсов, возможно, вы не сможете просмотреть группу ресурсов управляемого кластера в портал Azure.
Использование команд Kubectl
Чтобы устранить ошибки в кластере, введите команды kubectl, чтобы получить сведения о ресурсах, развернутых в кластере. Чтобы использовать kubectl, сначала войдите в кластер AKS:
az aks get-credentials --resource-group MyResourceGroup --name MyManagedCluster
В зависимости от типа сбоя и времени его возникновения вы не сможете войти в кластер для получения дополнительных сведений. Но в целом, если кластер был создан и отображается в портал Azure, вы сможете войти в систему и выполнить команды kubectl.
Просмотр узлов кластера (kubectl get nodes)
Чтобы получить дополнительные сведения об определении состояния узлов, просмотрите узлы кластера, введя команду kubectl get nodes. В этом примере узлы не отправляют отчеты в кластере:
$ kubectl get nodes
No resources found
Просмотр модулей pod в системном пространстве имен (kubectl get pod)
Просмотр модулей pod в пространстве имен kube-system также является хорошим способом устранения проблемы. Этот метод позволяет просматривать состояние системных модулей pod Kubernetes. В этом примере мы вводим kubectl get pods
команду :
$ kubectl get pods -n kube-system
NAME READY STATUS RESTARTS AGE
coredns-845757d86-7xjqb 0/1 Pending 0 78m
coredns-autoscaler-5f85dc856b-mxkrj 0/1 Pending 0 77m
konnectivity-agent-67f7f5554f-nsw2g 0/1 Pending 0 77m
konnectivity-agent-8686cb54fd-xlsgk 0/1 Pending 0 65m
metrics-server-6bc97b47f7-dfhbr 0/1 Pending 0 77m
Описание состояния pod (kubectl describe pod)
Описывая состояние модулей pod, можно просмотреть сведения о конфигурации и событиях, произошедших в них. Выполните команду kubectl describe pod:
$ kubectl describe pod coredns-845757d86-7xjqb -n kube-system
Name: coredns-845757d86-7xjqb
Namespace: kube-system
Priority: 2000001000
Priority Class Name: system-node-critical
Node: <none>
Labels: k8s-app=kube-dns
kubernetes.io/cluster-service=true
pod-template-hash=845757d86
version=v20
...
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Warning FailedScheduling 24m (x1 over 25m) default-scheduler no nodes available to schedule pods
Warning FailedScheduling 29m (x57 over 84m) default-scheduler no nodes available to schedule pods
В выходных данных команды видно, что модуль pod не может развернуться на узле, так как узлы недоступны.
Свяжитесь с нами для получения помощи
Если у вас есть вопросы или вам нужна помощь, создайте запрос в службу поддержки или обратитесь за поддержкой сообщества Azure. Вы также можете отправить отзыв о продукте в сообщество отзывов Azure.