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

Базовое устранение неполадок исходящих подключений из кластера AKS

  • Статья

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

Предварительные требования

  • Средство Kubernetes kubectl или аналогичное средство для подключения к кластеру. Чтобы установить kubectl с помощью Azure CLI, выполните команду az aks install-cli .

  • Средство командной строки apt-get для обработки пакетов.

  • Средство URL-адреса клиента (cURL) или аналогичное средство командной строки.

  • Средство командной строки узла для поиска DNS.

  • Средство командной строки Netcat (nc) для tcp-подключений.

  • Средство командной строки traceroute для печати трассировки пакетов маршрутизации на сетевой узел.

Сценарии для исходящего трафика в Служба Azure Kubernetes

В любом сетевом сценарии при устранении неполадок следует учитывать следующие факторы:

  • Источник и назначение для запроса.

  • Переход между источником и назначением.

  • Поток запросов и ответов.

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

    • Брандмауэр
    • Группа безопасности сети (NSG)
    • Политика сети

При проверка каждого компонента получите и проанализируйте коды http-ответов. Эти коды полезны для определения характера проблемы. Коды особенно полезны в сценариях, в которых приложение отвечает на HTTP-запросы.

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

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

Трафик, исходящий из кластера AKS, будь то из pod или рабочего узла, считается исходящим трафиком из кластера. Что делать, если в исходящем потоке для кластера AKS возникла проблема? Прежде чем устранять неполадки, сначала ознакомьтесь с характером потока "запрос-ответ".

Исходящий трафик из кластера AKS можно классифицировать в следующих категориях:

  1. Трафик к pod или службе в том же кластере (внутренний трафик)

  2. Трафик к устройству или конечной точке в той же виртуальной сети или другой виртуальной сети (которая использует пиринг между виртуальными сетями)

  3. Трафик в локальную среду через VPN-подключение или подключение Azure ExpressRoute

  4. Трафик за пределами сети AKS (общедоступный исходящий трафик)

В этом документе рассматриваются основные действия по устранению неполадок, влияющих на исходящее подключение:

  • В кластере
  • В виртуальных сетях
  • Во внешний мир (общественный трафик)

При устранении неполадок исходящего трафика в AKS также важно знать, что такое устройство исходящего трафика (то есть устройство, через которое проходит трафик). Здесь устройство исходящего трафика может быть одним из следующих компонентов:

  • Azure Load Balancer
  • Брандмауэр Azure или настраиваемый брандмауэр
  • Шлюз преобразования сетевых адресов (NAT)
  • Прокси-сервер

Поток также может отличаться в зависимости от назначения. Например, внутренний трафик (то есть в кластере) не проходит через устройство исходящего трафика. Внутренний трафик будет использовать только сеть кластера.

Внутренний трафик

Базовый поток запросов для внутреннего трафика из кластера AKS будет похож на поток, показанный на следующей схеме.

Схема базового потока запросов для внутреннего трафика из кластера Microsoft Служба Azure Kubernetes (AKS).

Внешний трафик через Azure Load Balancer

Если трафик предназначен для назначения в Интернете, методом по умолчанию является отправка трафика через Azure Load Balancer.

Схема потока запросов для внешнего интернет-трафика через Azure Load Balancer из кластера Microsoft Служба Azure Kubernetes (AKS).

Внешний трафик через Брандмауэр Azure или прокси-сервер

В некоторых случаях исходящий трафик должен быть отфильтрован, и для этого может потребоваться Брандмауэр Azure.

Схема потока запросов для внешнего интернет-трафика через Брандмауэр Azure из кластера Microsoft Служба Azure Kubernetes (AKS).

Вместо брандмауэра пользователю может потребоваться добавить прокси-сервер. Кроме того, пользователю может потребоваться настроить шлюз NAT для исходящего трафика. Базовый поток остается таким же, как показано на схеме.

Важно понимать характер потока исходящего трафика для кластера, чтобы продолжить устранение неполадок.

Контрольный список для устранения неполадок

Чтобы устранить основные неполадки исходящего трафика из кластера AKS, выполните следующие действия.

  1. Убедитесь, что разрешение системы доменных имен (DNS) для конечной точки работает правильно.

  2. Убедитесь, что вы можете получить доступ к конечной точке через IP-адрес.

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

  4. Убедитесь, что конечная точка работает.

  5. Проверьте, может ли кластер достичь любой другой внешней конечной точки.

  6. Проверьте, блокирует ли политика сети трафик.

  7. Проверьте, блокирует ли NSG трафик.

  8. Проверьте, блокирует ли трафик брандмауэр или прокси-сервер.

  9. Проверьте, имеет ли субъект-служба AKS или управляемое удостоверение необходимые разрешения службы AKS для внесения сетевых изменений в ресурсы Azure.

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

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

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

Примечание.

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

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

  1. Запустите тестовый модуль pod в том же пространстве имен, что и проблемный pod:

    kubectl run -it --rm aks-ssh --namespace <namespace> --image=debian:stable

    После запуска тестового модуля pod вы получите доступ к объекту pod.

  2. Выполните следующие apt-get команды, чтобы установить другие пакеты инструментов:

    apt-get update -y
apt-get install dnsutils -y
apt-get install curl -y
apt-get install netcat -y

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

    $ nslookup microsoft.com
Server:         10.0.0.10
Address:        10.0.0.10#53
...
...
Name:   microsoft.com
Address: 20.53.203.50

  4. Попробуйте разрешение 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

  5. 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

  6. Запустите тестовый модуль 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"

  7. Выполните команду kubectl exec , чтобы подключиться к pod с помощью PowerShell:

    kubectl exec -it dnsutil-win powershell

  8. Выполните командлет 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 в узле. Выполните следующие действия:

  1. Подключитесь к узлам кластера Служба Azure Kubernetes (AKS) для обслуживания или устранения неполадок.

  2. Проверьте разрешение DNS для конечной точки:

    $ nslookup  microsoft.com
Server:         168.63.129.16
Address:        168.63.129.16#53

Non-authoritative answer:
Name:   microsoft.com
Address: 20.112.52.29
Name:   microsoft.com
Address: 20.81.111.85
Name:   microsoft.com
Address: 20.84.181.62
Name:   microsoft.com
Address: 20.103.85.33
Name:   microsoft.com
Address: 20.53.203.50

  3. Проверьте файл resolve.conf , чтобы определить, добавлены ли ожидаемые серверы имен:

    cat /etc/resolv.conf
cat /run/systemd/resolve/resolv.conf

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

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

Проверьте, может ли кластер получить доступ к конечной точке через сеть.

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

  1. Проверьте маршрут к конечной точке, чтобы определить, существует ли время ожидания для конкретной операции:

    kubectl run -it --rm aks-ssh --namespace <namespace> --image=debian:stable
apt-get install -y traceroute && apt-get install netcat -y
traceroute -T microsoft.com -m 50 -p 443

  2. Проверьте, открыт ли нужный порт на удаленном узле:

    nc -z -v microsoft.com 443

  3. Проверьте код http-ответа:

    curl -Iv https://microsoft.com

  4. Проверьте, можно ли подключиться к любой другой конечной точке:

    curl -Iv https://kubernetes.io

Заявление об отказе от ответственности за контактные данные сторонней организации

Корпорация Майкрософт предоставляет сторонние контактные данные, чтобы помочь вам найти дополнительные сведения по этой теме. Эти данные могут быть изменены без предварительного уведомления. Корпорация Майкрософт не гарантирует точность контактной информации сторонних поставщиков.

Свяжитесь с нами для получения помощи

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