Устранение проблем с платформой для кластеров Kubernetes с поддержкой Azure Arc

  • Статья

В этом документе приводятся руководства по устранению неполадок с подключением Kubernetes с поддержкой Azure Arc, разрешениями и агентами. Он также содержит руководства по устранению неполадок для Azure GitOps, которые можно использовать в кластерах Kubernetes с поддержкой Azure Arc или Служба Azure Kubernetes (AKS).

Сведения об устранении неполадок, связанных с расширениями, такими как GitOps (Flux версии 2), контейнер Azure Monitor Аналитика, Open Service Mesh, см. в статье "Устранение неполадок с расширением для кластеров Kubernetes с поддержкой Azure Arc".

Azure CLI

Перед использованием или az k8s-configuration командами az connectedk8s CLI убедитесь, что Azure CLI настроена для работы с правильной подпиской Azure.

az account set --subscription 'subscriptionId'
az account show

Агенты Azure Arc

Все агенты Kubernetes с поддержкой Azure Arc развертываются в виде модулей pod в azure-arc пространстве имен. Все объекты pod должны работать и успешно возвращать подтверждения работоспособности.

Сначала проверьте выпуск Диаграммы Azure Arc Helm:

$ helm --namespace default status azure-arc
NAME: azure-arc
LAST DEPLOYED: Fri Apr  3 11:13:10 2020
NAMESPACE: default
STATUS: deployed
REVISION: 5
TEST SUITE: None

Если выпуск Helm Chart не найден или отсутствует, повторите попытку подключения кластера к Azure Arc .

Если выпуск диаграммы Helm присутствует, STATUS: deployedпроверка состояние агентов с помощьюkubectl:

$ kubectl -n azure-arc get deployments,pods
NAME                                         READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/cluster-metadata-operator    1/1     1            1           3d19h
deployment.apps/clusterconnect-agent         1/1     1            1           3d19h
deployment.apps/clusteridentityoperator      1/1     1            1           3d19h
deployment.apps/config-agent                 1/1     1            1           3d19h
deployment.apps/controller-manager           1/1     1            1           3d19h
deployment.apps/extension-events-collector   1/1     1            1           3d19h
deployment.apps/extension-manager            1/1     1            1           3d19h
deployment.apps/flux-logs-agent              1/1     1            1           3d19h
deployment.apps/kube-aad-proxy               1/1     1            1           3d19h
deployment.apps/metrics-agent                1/1     1            1           3d19h
deployment.apps/resource-sync-agent          1/1     1            1           3d19h

NAME                                              READY   STATUS    RESTARTS        AGE
pod/cluster-metadata-operator-74747b975-9phtz     2/2     Running   0               3d19h
pod/clusterconnect-agent-cf4c7849c-88fmf          3/3     Running   0               3d19h
pod/clusteridentityoperator-79bdfd945f-pt2rv      2/2     Running   0               3d19h
pod/config-agent-67bcb94b7c-d67t8                 1/2     Running   0               3d19h
pod/controller-manager-559dd48b64-v6rmk           2/2     Running   0               3d19h
pod/extension-events-collector-85f4fbff69-55zmt   2/2     Running   0               3d19h
pod/extension-manager-7c7668446b-69gps            3/3     Running   0               3d19h
pod/flux-logs-agent-fc7c6c959-vgqvm               1/1     Running   0               3d19h
pod/kube-aad-proxy-84d668c44b-j457m               2/2     Running   0               3d19h
pod/metrics-agent-58fb8554df-5ll67                2/2     Running   0               3d19h
pod/resource-sync-agent-dbf5db848-c9lg8           2/2     Running   0               3d19h

Все объекты pod должны возвращать для параметра STATUS значение Running, а также значение 3/3 или 2/2 в столбце READY. Получите журналы и опишите объекты pod, которые возвращают Error или CrashLoopBackOff. Если некоторые объекты pod надолго остаются в состоянии Pending, это может быть вызвано нехваткой ресурсов в узлах кластера. Масштабирование кластера может получить эти модули pod для перехода в Running состояние.

Ошибка подготовки ресурсов или ошибка времени ожидания службы

Если вы видите эти ошибки, проверка состояние Azure, чтобы узнать, существуют ли активные события, влияющие на состояние службы Kubernetes с поддержкой Azure Arc. Если это так, дождитесь разрешения события службы, попробуйте снова подключиться после удаления существующего подключенного ресурса кластера. Если нет событий службы, и вы продолжаете сталкиваться с проблемами при подключении, откройте запрос в службу поддержки, чтобы мы могли изучить проблему.

Ошибка превышения утверждений

Если вы получаете утверждение о превышении, убедитесь, что субъект-служба не является частью более 200 групп Microsoft Entra. Если это так, необходимо создать и использовать другой субъект-службу, который не является членом более 200 групп, или удалить исходный субъект-службу из некоторых ее групп и повторить попытку.

Утверждение избыточного трафика также может возникать, если вы настроили исходящую прокси-среду без разрешения конечной точки https://<region>.obo.arc.azure.com:8084/ для исходящего трафика.

Если ни из этих действий нет, откройте запрос на поддержку, чтобы мы могли изучить проблему.

Проблемы при подключении кластеров Kubernetes к Azure Arc

Подключение кластеры в Azure Arc требуют доступа к подписке Azure и cluster-admin доступу к целевому кластеру. Если вы не можете связаться с кластером или у вас недостаточно разрешений, подключение кластера к Azure Arc завершится ошибкой. Убедитесь, что вы выполнили все необходимые условия для подключения кластера.

Совет

Визуальное руководство по устранению неполадок с подключением см. в статье "Диагностика проблем с подключением для кластеров Kubernetes с поддержкой Arc".

Проблемы с разрешением DNS.

Чтобы устранить проблемы с разрешением DNS в кластере, ознакомьтесь с решением проблем с отладкой DNS .

Проблемы с исходящим сетевым подключением

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

Если возникают проблемы с подключением, а кластер находится за исходящим прокси-сервером, убедитесь, что вы передали параметры прокси-сервера во время подключения кластера и правильно настроен прокси-сервер. Дополнительные сведения см. в разделе Подключение с использованием исходящего прокси-сервера.

Вы можете увидеть ошибку, аналогичную следующей:

An exception has occurred while trying to execute the cluster diagnostic checks in the cluster. Exception: Unable to pull cluster-diagnostic-checks helm chart from the registry 'mcr.microsoft.com/azurearck8s/helmchart/stable/clusterdiagnosticchecks:0.1.2': Error: failed to do request: Head "https://mcr.microsoft.com/v2/azurearck8s/helmchart/stable/clusterdiagnosticchecks/manifests/0.1.2": dial tcp xx.xx.xx.219:443: i/o timeout

Эта ошибка возникает, когда https://k8connecthelm.azureedge.net конечная точка заблокирована. Убедитесь, что сеть обеспечивает подключение к этой конечной точке и соответствует всем другим требованиям к сети.

Не удалось получить сертификат MSI

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

Недостаточно разрешений для кластера

Если предоставленный файл kubeconfig не имеет достаточных разрешений для установки агентов Azure Arc, команда Azure CLI возвращает ошибку: Error: list: failed to list: secrets is forbidden: User "myuser" cannot list resource "secrets" in API group "" at the cluster scope

Чтобы устранить эту проблему, убедитесь, что пользователь, подключающий кластер к Azure Arc, назначена cluster-admin роль.

Не удается подключить кластер OpenShift к Azure Arc

Если az connectedk8s connect время ожидания и сбой при подключении кластера OpenShift к Azure Arc:

  1. Убедитесь, что кластер OpenShift соответствует предварительным требованиям версии: 4.5.41+ или 4.6.35+ или 4.7.18+.

  2. Перед выполнением az connectedk8s connnectвыполните следующую команду в кластере:

    oc adm policy add-scc-to-user privileged system:serviceaccount:azure-arc:azure-arc-kube-aad-proxy-sa

Время ожидания установки

Подключение кластер Kubernetes с поддержкой Azure Arc Kubernetes требует установки агентов Azure Arc в кластере. Если для работы с кластером используется медленное подключение к Интернету, извлечение образа контейнера для агентов может занять больше времени, чем настроенный период ожидания в Azure CLI.

Ошибка времени ожидания Helm

Может появить сообщение об ошибке Unable to install helm release: Error: UPGRADE Failed: time out waiting for the condition. Чтобы решить эту проблему, выполните следующие шаги.

  1. Выполните следующую команду:

    kubectl get pods -n azure-arc

  2. Проверьте, отображаются crashloopbackoffли clusterconnect-agent модули pod или config-agent не все контейнеры:

    NAME                                        READY   STATUS             RESTARTS   AGE
cluster-metadata-operator-664bc5f4d-chgkl   2/2     Running            0          4m14s
clusterconnect-agent-7cb8b565c7-wklsh       2/3     CrashLoopBackOff   0          1m15s
clusteridentityoperator-76d645d8bf-5qx5c    2/2     Running            0          4m15s
config-agent-65d5df564f-lffqm               1/2     CrashLoopBackOff   0          1m14s

  3. azure-identity-certificate Если оно отсутствует, управляемое удостоверение, назначаемое системой, не было установлено.

    kubectl get secret -n azure-arc -o yaml | grep name:

    name: azure-identity-certificate

    Чтобы устранить эту проблему, попробуйте удалить развертывание Arc, выполнив az connectedk8s delete команду и переустановив ее. Если проблема продолжается, это может быть проблема с параметрами прокси-сервера. В этом случае попробуйте подключить кластер к Azure Arc через прокси-сервер , чтобы подключить кластер к Arc через прокси-сервер. Кроме того, убедитесь, что выполнены все необходимые компоненты сети.

  4. clusterconnect-agent Если выполняются и config-agent модули pod, но модуль kube-aad-proxy pod отсутствует, проверка политики безопасности pod. В этом модуле используется azure-arc-kube-aad-proxy-sa учетная запись службы, у которой нет разрешений администратора, но требуется разрешение на подключение пути узла.

  5. Если модуль kube-aad-proxy pod зависает в ContainerCreating состоянии, проверка, был ли скачан сертификат kube-aad-proxy в кластер.

    kubectl get secret -n azure-arc -o yaml | grep name:

    name: kube-aad-proxy-certificate

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

Ошибка модуля CryptoHash

При попытке подключить кластеры Kubernetes к платформе Azure Arc локальная среда (например, консоль клиента) может вернуть следующее сообщение об ошибке:

Cannot load native module 'Crypto.Hash._MD5'

Иногда зависимые модули не могут успешно скачать при добавлении расширений connectedk8s и k8s-configuration с помощью Azure CLI или Azure PowerShell. Чтобы устранить эту проблему, удалите вручную и добавьте расширения в локальную среду.

Чтобы удалить расширения, используйте следующую команду:

az extension remove --name connectedk8s
az extension remove --name k8s-configuration

Чтобы добавить расширения, используйте следующую команду:

az extension add --name connectedk8s
az extension add --name k8s-configuration

Проблемы с подключением к кластеру

Если кластер находится за исходящим прокси-сервером или брандмауэром, убедитесь, что для этого включены *.servicebus.windows.netподключения websocket, которые требуются специально для функции кластера Подключение. Кроме того, убедитесь, что вы используете последнюю версию connectedk8s расширения Azure CLI, если у вас возникли проблемы с подключением к кластеру.

clusterconnect-agent Если отсутствуют и kube-aad-proxy модули pod, функция подключения кластера, скорее всего, отключена в кластере. Если это так, az connectedk8s proxy не удается установить сеанс с кластером, и может появиться сообщение об ошибке. Cannot connect to the hybrid connection because no agent is connected in the target arc resource.

Чтобы устранить эту ошибку, включите функцию подключения кластера в кластере:

az connectedk8s enable-features --features cluster-connect -n $CLUSTER_NAME -g $RESOURCE_GROUP

Дополнительные сведения см. в статье "Использование подключения кластера для безопасного подключения к кластерам Kubernetes с поддержкой Azure Arc".

Включение настраиваемых расположений с помощью субъекта-службы

При подключении кластера к Azure Arc или включении пользовательских расположений в существующем кластере может возникнуть следующее предупреждение:

Unable to fetch oid of 'custom-locations' app. Proceeding without enabling the feature. Insufficient privileges to complete the operation.

Это предупреждение возникает при использовании субъекта-службы для входа в Azure, а субъект-служба не имеет необходимых разрешений. Чтобы избежать этой ошибки, выполните следующие действия.

  1. Войдите в Azure CLI с помощью учетной записи пользователя. Получение идентификатора объекта приложения Microsoft Entra, используемого службой Azure Arc:

    az ad sp show --id bc313c14-388c-4e7d-a58e-70017303ee3b --query objectId -o tsv

  2. Войдите в Azure CLI с помощью субъекта-службы. <objectId> Используйте значение из предыдущего шага, чтобы включить пользовательские расположения в кластере:

    • Чтобы включить пользовательские расположения при подключении кластера к Arc, выполните команду az connectedk8s connect -n <cluster-name> -g <resource-group-name> --custom-locations-oid <objectId>
    • Чтобы включить пользовательские расположения в существующем кластере Kubernetes с поддержкой Azure Arc, выполните команду az connectedk8s enable-features -n <cluster-name> -g <resource-group-name> --custom-locations-oid <objectId> --features cluster-connect custom-locations

Следующие шаги