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

В этой статье описываются советы по устранению распространенных проблем, связанных с расширениями кластера, такими как GitOps (Flux версии 2) в Azure или Open Service Mesh (OSM).

Сведения об устранении неполадок с Kubernetes с поддержкой Azure Arc см. в статье "Устранение неполадок с Kubernetes с поддержкой Azure Arc".

GitOps (Flux версии 2)

Чтобы получить общие рекомендации по устранению неполадок в процессе использования ресурсов fluxConfigurations, выполните следующие команды Azure CLI с параметром --debug:

az provider show -n Microsoft.KubernetesConfiguration --debug
az k8s-configuration flux create <parameters> --debug

Ошибка настройки конфигурации чарта Helm

Возможно, появится сообщение об ошибке с надписью "Unable to render the Helm chart with the provided config settings and config protected settings : Recommendation Please check if the values provided to the config settings and the config protected settings are valid for this extension type : InnerError [template: azure-k8s-flux/templates/source-controller.yaml:100:24: executing "azure-k8s-flux/templates/source-controller.yaml" at <index (lookup "v1" "ConfigMap" "kube-system" "extension-manager-config").data "AZURE_TENANT_ID">: error calling index: index of untyped nil]".

Для разрешения этой проблемы:

• Если вы используете microsoft.flux версию 1.15.1 или более раннюю версию, обновите ее до версии 1.15.2 или более поздней.
• Если вы используете microsoft.flux версию 1.16.2 в регионах западная часть США, Центральная Франция, Южная Часть Великобритании или Западная Европа, выполните обновление до версии 1.16.3 или более поздней.

Ошибки пробного запуска веб-перехватчика

Flux может не выполниться и отобразить ошибку, аналогичную dry-run failed, error: admission webhook "<webhook>" does not support dry run. Чтобы устранить проблему, перейдите к разделу ValidatingWebhookConfiguration или MutatingWebhookConfiguration. В конфигурации задайте значение для sideEffectsNone или NoneOnDryRun.

Дополнительные сведения см. в разделе Как устранить ошибки «вебхук не поддерживает пробный запуск»?.

Ошибки при установке расширения microsoft.flux

Расширение microsoft.flux устанавливает контроллеры Flux и агенты Azure GitOps в кластере Kubernetes с поддержкой Azure Arc или кластере AKS. Если расширение еще не установлено в кластере и вы создаете ресурс конфигурации GitOps для кластера, расширение устанавливается автоматически.

Если во время установки возникает ошибка или расширение отображает состояние Failed, убедитесь, что в кластере нет политик, ограничивающих создание пространства имен flux-system или ресурсов в этом пространстве имен.

Для кластера AKS убедитесь, что флаг функции Microsoft.ContainerService/AKS-ExtensionManager включен в вашей подписке Azure.

az feature register --namespace Microsoft.ContainerService --name AKS-ExtensionManager

Затем выполните следующую команду, чтобы определить, существуют ли другие проблемы. Задайте параметр типа кластера (-t) connectedClusters для кластера с поддержкой Azure Arc или managedClusters для кластера AKS. Если расширение было установлено автоматически при создании конфигурации microsoft.flux GitOps, имя расширения — flux.

az k8s-extension show -g <RESOURCE_GROUP> -c <CLUSTER_NAME> -n flux -t <connectedClusters or managedClusters>

Выходные данные помогут определить проблему и как ее устранить. Возможные действия по исправлению:

• Удалите расширение принудительно, выполнив az k8s-extension delete --force -g <RESOURCE_GROUP> -c <CLUSTER_NAME> -n flux -t <managedClusters OR connectedClusters>.
• Удалите релиз Helm, выполнив команду helm uninstall flux -n flux-system.
• Удалите пространство имен flux-system из кластера, выполнив команду kubectl delete namespaces flux-system.

Затем можно создать новую конфигурацию Flux, которая автоматически устанавливает microsoft.flux расширение или установить расширение Flux вручную.

Ошибки при установке расширения microsoft.flux в кластере с управляемым удостоверением Microsoft Entra pod

Если вы пытаетесь установить расширение Flux в кластере с управляемой pod-идентичностью Microsoft Entra, в pod может возникнуть ошибка extension-agent. Выходные данные выглядят примерно так:

{"Message":"2021/12/02 10:24:56 Error: in getting auth header : error {adal: Refresh request failed. Status Code = '404'. Response body: no azure identity found for request clientID <REDACTED>\n}","LogType":"ConfigAgentTrace","LogLevel":"Information","Environment":"prod","Role":"ClusterConfigAgent","Location":"westeurope","ArmId":"/subscriptions/<REDACTED>/resourceGroups/<REDACTED>/providers/Microsoft.Kubernetes/managedclusters/<REDACTED>","CorrelationId":"","AgentName":"FluxConfigAgent","AgentVersion":"0.4.2","AgentTimestamp":"2021/12/02 10:24:56"}

Состояние расширения возвращается следующим образом Failed:

"{\"status\":\"Failed\",\"error\":{\"code\":\"ResourceOperationFailure\",\"message\":\"The resource operation completed with terminal provisioning state 'Failed'.\",\"details\":[{\"code\":\"ExtensionCreationFailed\",\"message\":\" error: Unable to get the status from the local CRD with the error : {Error : Retry for given duration didn't get any results with err {status not populated}}\"}]}}",

В этом случае extension-agent pod пытается получить свой токен из службы метаданных экземпляра Azure в кластере, но запрос токена перехватывается удостоверением pod. Чтобы устранить эту проблему, расширения.

Требования к ресурсам памяти и ЦП для установки расширения microsoft.flux

Контроллеры, установленные в кластере Kubernetes при установке расширения microsoft.flux, должны иметь достаточно ресурсов процессора и памяти для корректного размещения на узле кластера Kubernetes. Убедитесь, что кластер соответствует минимальным требованиям к памяти и ресурсам ЦП.

В следующей таблице перечислены минимальные и максимальные ограничения для потенциальных требований к ресурсам ЦП и памяти для этого сценария:

Если вы включили пользовательскую или встроенную политику Azure Policy Gatekeeper, которая ограничивает ресурсы для контейнеров в кластерах Kubernetes, убедитесь, что ресурсные ограничения политики больше, чем ограничения, указанные в предыдущей таблице, или flux-system пространство имен является частью excludedNamespaces параметра в назначении политики. Примером политики в этом сценарии является Kubernetes cluster containers CPU and memory resource limits should not exceed the specified limits.

Аналитика контейнеров Azure Monitor

В этом разделе приводятся сведения об устранении неполадок с аналитикой контейнеров в Azure Monitor для кластеров Kubernetes с поддержкой Azure Arc.

Включение привилегированного режима для канонического Charmed кластера Kubernetes

Azure Monitor Container Insights требует работы Kubernetes DaemonSet в привилегированном режиме. Чтобы успешно настроить мониторинг для кластера Canonical Charmed Kubernetes, выполните следующую команду:

juju config kubernetes-worker allow-privileged=true

Не удается установить поды AMA в Oracle Linux 9.x

Если вы попытаетесь установить агент Azure Monitor (AMA) в кластере Kubernetes на Oracle Linux (Red Hat Enterprise Linux (RHEL)) 9.x, pod'ы AMA и AMA-RS могут работать неправильно из-за addon-token-adapter контейнера в pod'е. При проверке журналов ama-logs-rs pod в addon-token-adapter container вы увидите выходные данные, аналогичные следующему примеру:

Command: kubectl -n kube-system logs ama-logs-rs-xxxxxxxxxx-xxxxx -c addon-token-adapter
 
Error displayed: error modifying iptable rules: error adding rules to custom chain: running [/sbin/iptables -t nat -N aad-metadata --wait]: exit status 3: modprobe: can't change directory to '/lib/modules': No such file or directory

iptables v1.8.9 (legacy): can't initialize iptables table `nat': Table does not exist (do you need to insmod?)

Perhaps iptables or your kernel needs to be upgraded.

Эта ошибка возникает, так как для установки расширения требуется iptable_nat модуль, но этот модуль не загружается автоматически в дистрибутивы Oracle Linux (RHEL) 9.x.

Чтобы устранить эту проблему, необходимо явно загрузить iptables_nat модуль на каждом узле в кластере. modprobe Используйте командуsudo modprobe iptables_nat. Войдите на каждую систему и вручную добавьте модуль iptable_nat, затем заново повторите установку AMA.

Open Service Mesh с поддержкой Azure Arc

В этом разделе показаны команды, которые можно использовать для проверки и устранения неполадок при развертывании компонентов расширения Open Service Mesh (OSM) в кластере.

Проверка развертывания контроллера OSM

kubectl get deployment -n arc-osm-system --selector app=osm-controller

Если контроллер OSM работоспособен, вы увидите следующие выходные данные:

NAME             READY   UP-TO-DATE   AVAILABLE   AGE
osm-controller   1/1     1            1           59m

Проверка модулей pod контроллера OSM

kubectl get pods -n arc-osm-system --selector app=osm-controller

Если контроллер OSM работоспособен, выходные данные, похожие на следующий пример, отображаются:

NAME                            READY   STATUS    RESTARTS   AGE
osm-controller-b5bd66db-wglzl   0/1     Evicted   0          61m
osm-controller-b5bd66db-wvl9w   1/1     Running   0          31m

Несмотря на то, что один контроллер имеет состояние в одной точке, другой контроллер имеет Evicted состояние READY1/1 и Running с 0 перезапусками. READY Если состояние отличается от 1/1состояния, сетка службы находится в неисправном состоянии. Если READY это 0/1так, контейнер плоскости управления завершается сбоем.

Используйте следующую команду для проверки журналов контроллера:

kubectl logs -n arc-osm-system -l app=osm-controller

READY Если состояние больше, чем 1 после боковой косой черты (/), устанавливаются боковики. Контроллер OSM обычно работает некорректно при присоединении сайдкаров.

Проверка службы контроллера OSM

Чтобы проверить службу контроллера OSM, выполните следующую команду:

kubectl get service -n arc-osm-system osm-controller

Если контроллер OSM работоспособен, выходные данные, похожие на следующий пример, отображаются:

NAME             TYPE        CLUSTER-IP    EXTERNAL-IP   PORT(S)              AGE
osm-controller   ClusterIP   10.0.31.254   <none>        15128/TCP,9092/TCP   67m

Проверка конечных точек контроллера OSM

kubectl get endpoints -n arc-osm-system osm-controller

Если контроллер OSM работоспособен, выходные данные, похожие на следующий пример, отображаются:

NAME             ENDPOINTS                              AGE
osm-controller   10.240.1.115:9092,10.240.1.115:15128   69m

Если в кластере нет ENDPOINTS, которым присвоено значение osm-controller, то плоскость управления недоступна. Это неработоспособное состояние означает, что модуль pod контроллера произошел сбой или что он никогда не был развернут правильно.

Проверка развертывания инжектора OSM

kubectl get deployments -n arc-osm-system osm-injector

Если инектор OSM работоспособен, выходные данные, похожие на следующий пример, отображаются:

NAME           READY   UP-TO-DATE   AVAILABLE   AGE
osm-injector   1/1     1            1           73m

Проверьте капсулу внедрения OSM

kubectl get pod -n arc-osm-system --selector app=osm-injector

Если инектор OSM работоспособен, выходные данные, похожие на следующий пример, отображаются:

NAME                            READY   STATUS    RESTARTS   AGE
osm-injector-5986c57765-vlsdk   1/1     Running   0          73m

Состояние READY должно быть 1/1. Любое другое значение указывает на неработоспособный модуль инжектора OSM.

Проверьте службу инжектора OSM

kubectl get service -n arc-osm-system osm-injector

Если инектор OSM работоспособен, выходные данные, похожие на следующий пример, отображаются:

NAME           TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)    AGE
osm-injector   ClusterIP   10.0.39.54   <none>        9090/TCP   75m

Убедитесь, что IP-адрес, указанный для службы osm-injector, соответствует 9090. Значение для EXTERNAL-IP не должно быть указано.

Проверка конечных точек инектора OSM

kubectl get endpoints -n arc-osm-system osm-injector

Если инектор OSM работоспособен, выходные данные, похожие на следующий пример, отображаются:

NAME           ENDPOINTS           AGE
osm-injector   10.240.1.172:9090   75m

Чтобы OSM работал нормально, требуется хотя бы одна конечная точка для osm-injector. IP-адрес конечных точек внедрения OSM может варьироваться, но значение порта 9090 должно оставаться неизменным.

Проверка веб-хуков: проверка и изменение

Проверьте валидность веб-перехватчика, выполнив следующую команду:

kubectl get ValidatingWebhookConfiguration --selector app=osm-controller

Если Проверяющий веб-перехватчик работоспособен, отображаются выходные данные, похожие на следующий пример:

NAME                     WEBHOOKS   AGE
osm-validator-mesh-osm   1          81m

Проверьте мутирующий веб-перехватчик, выполнив следующую команду:

kubectl get MutatingWebhookConfiguration --selector app=osm-injector

Если веб-перехватчик Mutating работоспособен, появляются результаты, похожие на следующий пример:

NAME                  WEBHOOKS   AGE
arc-osm-webhook-osm   1          102m

Проверьте службу и пакет центра сертификации (пакет ЦС) проверяющего веб-перехватчика с помощью следующей команды:

kubectl get ValidatingWebhookConfiguration osm-validator-mesh-osm -o json | jq '.webhooks[0].clientConfig.service'

Хорошо настроенный веб-перехватчик Validating имеет выходные данные, как в этом примере:

{
  "name": "osm-config-validator",
  "namespace": "arc-osm-system",
  "path": "/validate",
  "port": 9093
}

Проверьте наличие службы и пакета ЦС для мутирующего веб-перехватчика с помощью следующей команды:

kubectl get MutatingWebhookConfiguration arc-osm-webhook-osm -o json | jq '.webhooks[0].clientConfig.service'

Хорошо настроенный мутационный веб-хук выдаёт результат, аналогичный этому примеру:

{
  "name": "osm-injector",
  "namespace": "arc-osm-system",
  "path": "/mutate-pod-creation",
  "port": 9090
}

Проверьте, предоставил ли контроллер OSM пакету сертификатов удостоверяющего центра валидирующий (или мутирующий) веб-перехватчик с помощью следующей команды:

kubectl get ValidatingWebhookConfiguration osm-validator-mesh-osm -o json | jq -r '.webhooks[0].clientConfig.caBundle' | wc -c

kubectl get MutatingWebhookConfiguration arc-osm-webhook-osm -o json | jq -r '.webhooks[0].clientConfig.caBundle' | wc -c

Пример результата:

1845

Число в выходных данных указывает количество байтов или размер пакета сертификатов удостоверяющего центра. Если выходные данные пусты, 0 или число менее 1000, пакет ЦС не подготовлен правильно. Без правильного пакета удостоверяющего центра (ЦС) ValidatingWebhook выдает ошибку.

Проверьте ресурс osm-mesh-config

Проверьте наличие ресурса:

kubectl get meshconfig osm-mesh-config -n arc-osm-system

Проверьте значение параметра OSM meshconfig :

kubectl get meshconfig osm-mesh-config -n arc-osm-system -o yaml

Найдите выходные данные, похожие на этот пример:

apiVersion: config.openservicemesh.io/v1alpha1
kind: MeshConfig
metadata:
  creationTimestamp: "0000-00-00A00:00:00A"
  generation: 1
  name: osm-mesh-config
  namespace: arc-osm-system
  resourceVersion: "2494"
  uid: 6c4d67f3-c241-4aeb-bf4f-b029b08faa31
spec:
  certificate:
    certKeyBitSize: 2048
    serviceCertValidityDuration: 24h
  featureFlags:
    enableAsyncProxyServiceMapping: false
    enableEgressPolicy: true
    enableEnvoyActiveHealthChecks: false
    enableIngressBackendPolicy: true
    enableMulticlusterMode: false
    enableRetryPolicy: false
    enableSnapshotCacheMode: false
    enableWASMStats: true
  observability:
    enableDebugServer: false
    osmLogLevel: info
    tracing:
      enable: false
  sidecar:
    configResyncInterval: 0s
    enablePrivilegedInitContainer: false
    logLevel: error
    resources: {}
  traffic:
    enableEgress: false
    enablePermissiveTrafficPolicyMode: true
    inboundExternalAuthorization:
      enable: false
      failureModeAllow: false
      statPrefix: inboundExtAuthz
      timeout: 1s
    inboundPortExclusionList: []
    outboundIPRangeExclusionList: []
    outboundPortExclusionList: []
kind: List
metadata:
  resourceVersion: ""
  selfLink: ""

В следующей таблице перечислены osm-mesh-config значения ресурсов:

Проверка пространств имен

Вы можете использовать osm namespace add команду для присоединения пространств имен к определенной сетке служб. Когда пространство имен Kubernetes входит в сетку, выполните следующие действия, чтобы убедиться, что выполнены требования.

Просмотрите заметки bookbuyer пространства имен:

kubectl get namespace bookbuyer -o json | jq '.metadata.annotations'

Должны присутствовать следующие заметки:

{
  "openservicemesh.io/sidecar-injection": "enabled"
}

Просмотрите метки bookbuyer пространства имен:

kubectl get namespace bookbuyer -o json | jq '.metadata.labels'

Должны присутствовать следующие метки:

{
  "openservicemesh.io/monitored-by": "osm"
}

Если вы не используете интерфейс командной строки osm, вы можете вручную добавить эти аннотации в ваши пространства имен. Если пространство имен не аннотировано с "openservicemesh.io/sidecar-injection": "enabled", или если оно не помечено "openservicemesh.io/monitored-by": "osm", средство внедрения OSM не добавляет сайдкары Envoy.

Проверка идентификаторов SMI

Для интерфейса сетки службы OSM (SMI) проверьте наличие необходимых пользовательских определений ресурсов (CRD):

kubectl get crds

Убедитесь, что CRD соответствуют версиям, доступным в ветви выпуска. Чтобы убедиться, какие версии CRD используются, ознакомьтесь с поддерживаемыми версиями SMI и выберите свою версию в меню "Выпуски".

Получите версии установленных CRD, воспользовавшись следующей командой:

for x in $(kubectl get crds --no-headers | awk '{print $1}' | grep 'smi-spec.io'); do
    kubectl get crd $x -o json | jq -r '(.metadata.name, "----" , .spec.versions[].name, "\n")'
done

Если определений настраиваемых ресурсов (CRD) отсутствуют, используйте следующие команды для их установки в кластере. Замените версию в этих командах по мере необходимости (например, вместо версии 1.1.0 можно использовать release-v1.1).

kubectl apply -f https://raw.githubusercontent.com/openservicemesh/osm/release-v1.0/cmd/osm-bootstrap/crds/smi_http_route_group.yaml

kubectl apply -f https://raw.githubusercontent.com/openservicemesh/osm/release-v1.0/cmd/osm-bootstrap/crds/smi_tcp_route.yaml

kubectl apply -f https://raw.githubusercontent.com/openservicemesh/osm/release-v1.0/cmd/osm-bootstrap/crds/smi_traffic_access.yaml

kubectl apply -f https://raw.githubusercontent.com/openservicemesh/osm/release-v1.0/cmd/osm-bootstrap/crds/smi_traffic_split.yaml

Сведения о том, как изменяются версии CRD между выпусками, см. в заметках о выпуске OSM.

Устранение неполадок управления сертификатами

Сведения о выпуске и управлении сертификатами для прокси-серверов Envoy, работающих в модулях приложений pod, см. в документации OSM.

Обновите Envoy

При создании нового pod в пространстве имен, отслеживаемом надстройкой, OSM внедряет в него прокси-сайдкар Envoy. Если необходимо обновить версию Envoy, выполните действия, описанные в руководстве по обновлению в документации ПО OSM.

Связанный контент

• Дополнительные сведения о расширениях кластера.
• Ознакомьтесь с общими советами по устранению неполадок кластеров Kubernetes с поддержкой Arc.