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

Статья
11/05/2024

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

Совет

Действия, описанные в этой блок-схеме, применяются ли вы с помощью Azure CLI или Azure PowerShell для подключения кластера. Однако для некоторых шагов требуется использование Azure CLI. Если вы еще не установили Azure CLI, перед началом работы обязательно сделайте это.

Подключения без прокси-сервера

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

Имеет ли удостоверение Azure достаточные разрешения?

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

Вы используете последнюю версию Azure CLI?

Убедитесь, что установлена последняя версия.

Если вы подключили кластер с помощью Azure PowerShell, убедитесь, что вы используете последнюю версию.

Является `connectedk8s` ли расширение последней версией?

Обновите расширение Azure CLI connectedk8s до последней версии, выполнив следующую команду:

az extension update --name connectedk8s

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

az extension add --name connectedk8s

Указывает ли kubeconfig на правильный кластер?

Выполните команду kubectl config get-contexts , чтобы подтвердить имя целевого контекста. Затем задайте контекст по умолчанию для правильного кластера, выполнив команду kubectl config use-context <target-cluster-name>.

Зарегистрированы ли все необходимые поставщики ресурсов?

Убедитесь, что поставщики ресурсов Microsoft.Kubernetes, Microsoft.KubernetesConfiguration и Microsoft.ExtendedLocation зарегистрированы.

Выполнены ли все требования к сети?

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

Выполняются ли все модули pod в `azure-arc` пространстве имен?

Если все работает правильно, все модули pod должны находиться в Running состоянии. Выполните команду kubectl get pods -n azure-arc , чтобы проверить, не является Runningли состояние модуля pod.

По-прежнему возникают проблемы?

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

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

az connectedk8s troubleshoot -g <myResourceGroup> -n <myK8sCluster>

При создании запроса на поддержку в разделе "Дополнительные сведения" используйте параметр отправки файла для отправки созданного файла журнала.

Подключения к прокси-серверу

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

Выполняет ли компьютер команды за прокси-сервером?

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

Например:

export HTTP_PROXY="http://<proxyIP>:<proxyPort>"
export HTTPS_PROXY="https://<proxyIP>:<proxyPort>"
export NO_PROXY="<cluster-apiserver-ip-address>:<proxyPort>"

Принимает ли прокси-сервер только доверенные сертификаты?

Не забудьте включить путь к файлу сертификата, в том числе --proxy-cert <path-to-cert-file> при выполнении az connectedk8s connect команды.

az connectedk8s connect --name <cluster-name> --resource-group <resource-group> --proxy-cert <path-to-cert-file>

Может ли прокси-сервер достичь необходимых сетевых конечных точек?

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

Используется ли прокси-сервер только по протоколу HTTP?

Если прокси-сервер использует только HTTP, для обоих параметров можно использовать proxy-http .

Если прокси-сервер настроен как с HTTP, так и с HTTPS, выполните az connectedk8s connect команду с --proxy-https указанными параметрами и --proxy-http параметрами. Убедитесь, что используется --proxy-http для прокси-сервера HTTP и --proxy-https для прокси-сервера HTTPS.

az connectedk8s connect --name <cluster-name> --resource-group <resource-group> --proxy-https https://<proxy-server-ip-address>:<port> --proxy-http http://<proxy-server-ip-address>:<port>

Требуется ли прокси-сервер пропускать диапазоны для обмена данными между службами?

Если требуется пропустить диапазоны, используйте --proxy-skip-range <excludedIP>,<excludedCIDR> команду az connectedk8s connect .

az connectedk8s connect --name <cluster-name> --resource-group <resource-group> --proxy-https https://<proxy-server-ip-address>:<port> --proxy-http http://<proxy-server-ip-address>:<port> --proxy-skip-range <excludedIP>,<excludedCIDR>

Выполняются ли все модули pod в `azure-arc` пространстве имен?

Проверка успешности разрешения DNS для конечной точки

В модуле pod можно запустить поиск DNS в конечную точку.

Что делать, если вы не можете запустить команду kubectl exec , чтобы подключиться к pod и установить пакет DNS Utils? В этой ситуации можно запустить тестовый модуль pod в том же пространстве имен, что и проблематичный модуль pod, а затем запустить тесты.

Примечание.

Если разрешение DNS или трафик исходящего трафика не позволяет устанавливать необходимые сетевые пакеты, можно использовать rishasi/ubuntu-netutil:1.0 образ Docker. На этом изображении уже установлены необходимые пакеты.

Ниже приведен пример процедуры проверки разрешения DNS:

Запустите тестовый модуль pod в том же пространстве имен, что и проблематичный модуль pod:
```
kubectl run -it --rm test-pod --namespace <namespace> --image=debian:stable
```
После запуска тестового модуля pod вы получите доступ к модулю pod.
Выполните следующие apt-get команды, чтобы установить другие пакеты инструментов:
```
apt-get update -y
apt-get install dnsutils -y
apt-get install curl -y
apt-get install netcat -y
```
После установки пакетов выполните команду nslookup , чтобы проверить разрешение DNS в конечной точке:
```
$ nslookup microsoft.com
Server:         10.0.0.10
Address:        10.0.0.10#53
...
...
Name:   microsoft.com
Address: 20.53.203.50
```
Попробуйте разрешение DNS с вышестоящего DNS-сервера напрямую. В этом примере используется Azure DNS:
```
$ nslookup microsoft.com 168.63.129.16
Server:         168.63.129.16
Address:        168.63.129.16#53
...
...
Address: 20.81.111.85
```

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

$ host -a microsoft.com
Trying "microsoft.com.default.svc.cluster.local"
Trying "microsoft.com.svc.cluster.local"
Trying "microsoft.com.cluster.local"
Trying "microsoft.com.00idcnmrrm4edot5s2or1onxsc.bx.internal.cloudapp.net"
Trying "microsoft.com"
Trying "microsoft.com"
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 62884
;; flags: qr rd ra; QUERY: 1, ANSWER: 27, AUTHORITY: 0, ADDITIONAL: 5

;; QUESTION SECTION:
;microsoft.com.                 IN      ANY

;; ANSWER SECTION:
microsoft.com.          30      IN      NS      ns1-39.azure-dns.com.
...
...
ns4-39.azure-dns.info.  30      IN      A       13.107.206.39

Received 2121 bytes from 10.0.0.10#53 in 232 ms

Запустите тестовый модуль pod в пуле узлов Windows:

# For a Windows environment, use the Resolve-DnsName cmdlet.
kubectl run dnsutil-win --image='mcr.microsoft.com/windows/servercore:1809' --overrides='{"spec": { "nodeSelector": {"kubernetes.io/os": "windows"}}}' -- powershell "Start-Sleep -s 3600"

Выполните команду kubectl exec, чтобы подключиться к pod с помощью PowerShell:
```
kubectl exec -it dnsutil-win -- powershell
```

Выполните командлет Resolve-DnsName в PowerShell, чтобы проверить, работает ли разрешение DNS для конечной точки:

PS C:\> Resolve-DnsName www.microsoft.com 

Name                           Type   TTL   Section    NameHost
----                           ----   ---   -------    --------
www.microsoft.com              CNAME  20    Answer     www.microsoft.com-c-3.edgekey.net
www.microsoft.com-c-3.edgekey. CNAME  20    Answer     www.microsoft.com-c-3.edgekey.net.globalredir.akadns.net
net
www.microsoft.com-c-3.edgekey. CNAME  20    Answer     e13678.dscb.akamaiedge.net
net.globalredir.akadns.net

Name       : e13678.dscb.akamaiedge.net 
QueryType  : AAAA
TTL        : 20
Section    : Answer
IP6Address : 2600:1408:c400:484::356e   


Name       : e13678.dscb.akamaiedge.net 
QueryType  : AAAA
TTL        : 20
Section    : Answer
IP6Address : 2600:1408:c400:496::356e 


Name       : e13678.dscb.akamaiedge.net
QueryType  : A
TTL        : 12
Section    : Answer
IP4Address : 23.200.197.152

Если разрешение DNS не выполнено, проверьте конфигурацию DNS для кластера.

По-прежнему возникают проблемы?

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

az connectedk8s troubleshoot -g <myResourceGroup> -n <myK8sCluster>

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

Дополнительные советы по устранению неполадок с помощью Kubernetes с поддержкой Azure Arc.
Просмотрите процесс подключения существующего кластера Kubernetes к Azure Arc.

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

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

Подключения без прокси-сервера

Имеет ли удостоверение Azure достаточные разрешения?

Вы используете последнюю версию Azure CLI?

Является `connectedk8s` ли расширение последней версией?

Указывает ли kubeconfig на правильный кластер?

Зарегистрированы ли все необходимые поставщики ресурсов?

Выполнены ли все требования к сети?

Выполняются ли все модули pod в `azure-arc` пространстве имен?

По-прежнему возникают проблемы?

Подключения к прокси-серверу

Выполняет ли компьютер команды за прокси-сервером?

Принимает ли прокси-сервер только доверенные сертификаты?

Может ли прокси-сервер достичь необходимых сетевых конечных точек?

Используется ли прокси-сервер только по протоколу HTTP?

Требуется ли прокси-сервер пропускать диапазоны для обмена данными между службами?

Выполняются ли все модули pod в `azure-arc` пространстве имен?

Проверка успешности разрешения DNS для конечной точки

По-прежнему возникают проблемы?

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

Обратная связь

Дополнительные ресурсы

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

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

Подключения без прокси-сервера

Имеет ли удостоверение Azure достаточные разрешения?

Вы используете последнюю версию Azure CLI?

Является connectedk8s ли расширение последней версией?

Указывает ли kubeconfig на правильный кластер?

Зарегистрированы ли все необходимые поставщики ресурсов?

Выполнены ли все требования к сети?

Выполняются ли все модули pod в azure-arc пространстве имен?

По-прежнему возникают проблемы?

Подключения к прокси-серверу

Выполняет ли компьютер команды за прокси-сервером?

Принимает ли прокси-сервер только доверенные сертификаты?

Может ли прокси-сервер достичь необходимых сетевых конечных точек?

Используется ли прокси-сервер только по протоколу HTTP?

Требуется ли прокси-сервер пропускать диапазоны для обмена данными между службами?

Выполняются ли все модули pod в azure-arc пространстве имен?

Проверка успешности разрешения DNS для конечной точки

По-прежнему возникают проблемы?

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

Обратная связь

Дополнительные ресурсы

Является `connectedk8s` ли расширение последней версией?

Выполняются ли все модули pod в `azure-arc` пространстве имен?

Выполняются ли все модули pod в `azure-arc` пространстве имен?