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

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

  • Статья

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

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

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

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

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

  • Средство nslookup командной строки (dnsutils) для проверки разрешения DNS.

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

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

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

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

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

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

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

  5. Трафик за пределами сети AKS через Брандмауэр Azure или прокси-сервер (общедоступный исходящий трафик).

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

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

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

Общедоступный исходящий трафик через Azure Load Balancer

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

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

Общедоступный исходящий трафик через Брандмауэр Azure или прокси-сервер

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

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

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

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

Рекомендации по устранению неполадок

Проверка устройства исходящего трафика

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

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

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

Проверка каждого прыжка в потоке трафика

После идентификации устройства исходящего трафика проверьте следующие факторы:

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

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

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

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

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

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

Проверка кодов ответов HTTP

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

Захват пакетов с клиента и сервера

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

Устранение неполадок контрольных списков

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

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

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

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

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

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

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

  7. Проверьте, блокирует ли группа безопасности сети трафик.

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

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

Примечание.

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

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

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

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

Примечание.

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

Пример процедуры проверки разрешения DNS модуля pod Linux

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

    kubectl run -it --rm aks-ssh --namespace <namespace> --image=debian:stable --overrides='{"spec": { "nodeSelector": {"kubernetes.io/os": "linux"}}}'

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

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

    # Update and install tool packages
apt-get update && apt-get install -y dnsutils curl

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

    $ nslookup microsoft.com # Microsoft.com is used as an example
Server:         <server>
Address:        <server IP address>#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

Иногда возникает проблема с самой конечной точкой, а не с DNS кластера. В таких случаях рассмотрите следующие проверки:

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

    curl -Ivm5 telnet://microsoft.com:443

  2. Проверьте код ответа HTTP:

    curl -Ivm5 https://microsoft.com

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

    curl -Ivm5 https://kubernetes.io

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

  1. Введите узел, в котором проблематичный модуль pod находится через модуль отладки. Дополнительные сведения о том, как это сделать, см. в разделе "Подключение к узлам кластера Служба 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. Проверьте файл resolv.conf, чтобы определить, добавляются ли ожидаемые серверы имен:

    cat /etc/resolv.conf
cat /run/systemd/resolve/resolv.conf
Пример процедуры проверки разрешения DNS модуля pod Windows

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

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

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

    kubectl exec -it dnsutil-win -- powershell

  3. Выполните командлет 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 получают правильный ответ от узла, но завершаются сбоем из модуля pod. В этом сценарии можно проверить сбои разрешения DNS из модуля pod, но не из рабочего узла. Если вы хотите проверить разрешение DNS для конечной точки в кластере, можно проверить состояние разрешения DNS в кластере.

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

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

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

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

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