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

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

Примечание.

Ранее компонент туннеля AKS был tunnel-front. Теперь он был перенесен в службу Konnectivity, вышестоящий компонент Kubernetes. Дополнительные сведения об этой миграции см. в заметках о выпуске и журнале изменений AKS.

Необходимые условия

• Azure CLI

Симптомы

Вы получаете сообщение об ошибке, которое напоминает следующие примеры о порту 10250:

Ошибка с сервера: Get "https://<aks-node-name>:10250/containerLogs/<namespace>/<pod-name>/<container-name>": dial tcp <aks-node-ip>:10250: i/o timeout

Ошибка от сервера: ошибка подключения к серверной части: dial tcp <aks-node-ip>:10250: i/o timeout

Ошибка с сервера: get "https://< aks-node-name>:10250/containerLogs/namespace</><pod-name>/<container-name>": http: сервер дал HTTP-ответ клиенту HTTPS

Сервер API Kubernetes использует порт 10250 для подключения к kubelet узла для получения журналов. Если порт 10250 заблокирован, журналы kubectl и другие функции будут работать только для модулей pod, выполняемых на узлах, в которых запланирован компонент туннеля. Дополнительные сведения см. в разделе "Порты и протоколы Kubernetes: рабочие узлы".

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

• Веб-перехватчики контроллера приема

• Возможность извлечения журнала (с помощью команды kubectl logs )

• Выполнение команды в контейнере или вход внутрь контейнера (с помощью команды kubectl exec)

• Переадресация одного или нескольких локальных портов pod (с помощью команды kubectl port-forward )

Причина 1. Группа безопасности сети (NSG) блокирует порт 10250

Примечание.

Эта причина применима к любым компонентам туннеля, которые могут быть в кластере AKS.

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

Если группа безопасности сети блокирует порт 10250 на уровне виртуальной сети, функции туннеля (такие как журналы и выполнение кода) будут работать только для модулей, запланированных на узлах, где расположены туннельные модули. Другие pod не будут работать, потому что их узлы не смогут достичь туннеля, а туннель распределен на других узлах. Чтобы проверить это состояние, можно проверить подключение с помощью команд netcat (nc) или telnet. Вы можете запустить команду az vmss run-command invoke, чтобы провести тест подключения и проверить, успешно ли выполняется, истекло ли время ожидания, или возникает другая проблема:

az vmss run-command invoke --resource-group <infra-or-MC-resource-group> \
    --name <virtual-machine-scale-set-name> \
    --command-id RunShellScript \
    --instance-id <instance-id> \
    --scripts "nc -v -w 2 <ip-of-node-that-schedules-the-tunnel-component> 10250" \
    --output tsv \
    --query 'value[0].message'

Решение 1. Добавление правила NSG для разрешения доступа к порту 10250

Если вы используете группу сетевой безопасности (NSG) и у вас есть определенные ограничения, убедитесь, что вы добавили правило безопасности, которое разрешает трафик для порта 10250 на уровне виртуальной сети. На следующем изображении портал Azure показан пример правила безопасности:

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

Примечание.

• Поле "Приоритет" должно быть настроено соответствующим образом. Например, если у вас есть правило, которое запрещает несколько портов (включая порт 10250), правило, отображаемое на изображении, должно иметь более низкий приоритет (более низкие числа имеют более высокий приоритет). Дополнительные сведения о приоритете см. в разделе "Правила безопасности".

• Если вы не видите изменений в поведении после применения этого решения, вы можете заново создать pod компонента туннеля. Удаление этих pods приводит к их повторному созданию.

Причина 2. Средство неусложненного брандмауэра (UFW) блокирует порт 10250

Примечание.

Это применимо к любому компоненту туннеля, имеющемуся в вашем кластере AKS.

Несложный брандмауэр (UFW) — это программа командной строки для управления брандмауэром netfilter . Узлы AKS используют Ubuntu. Поэтому UFW устанавливается на узлах AKS по умолчанию, но UFW отключен.

По умолчанию, если UFW включен, он блокирует доступ ко всем портам, включая порт 10250. В этом случае вряд ли можно использовать Secure Shell (SSH) для подключения к узлам кластера AKS для устранения неполадок. Это связано с тем, что UFW также может блокировать порт 22. Чтобы устранить неполадки, можно запустить команду az vmss run-command, чтобы выполнить команду ufw, которая проверяет, включена ли UFW:

az vmss run-command invoke --resource-group <infra-or-MC-resource-group> \
    --name <virtual-machine-scale-set-name> \
    --command-id RunShellScript \
    --instance-id <instance-id> \
    --scripts "ufw status" \
    --output tsv \
    --query 'value[0].message'

Что делать, если результаты указывают, что UFW включен, и он не открывает порт 10250? В этом случае функции туннеля (такие как журналы и выполнение кода) не будут работать для подов, распределённых на узлах с включённым UFW. Чтобы устранить проблему, примените одно из следующих решений на UFW.

Внимание

Прежде чем использовать это средство для внесения изменений, просмотрите политику поддержки AKS (особенно обслуживание узлов и доступ), чтобы предотвратить вход кластера в неподдерживаемый сценарий.

Примечание.

Если вы не видите никаких изменений в поведении после применения решения, вы можете заново создать podы компонентов туннеля. Удаление этих модулей pod приведет к повторному созданию этих модулей.

Решение 2a. Отключение неусложненного брандмауэра

Выполните следующую az vmss run-command invoke команду, чтобы отключить UFW:

az vmss run-command invoke --resource-group <infra-or-MC-resource-group> \
    --name <virtual-machine-scale-set-name> \
    --command-id RunShellScript \
    --instance-id <instance-id> \
    --scripts "ufw disable" \
    --output tsv \
    --query 'value[0].message'

Решение 2b. Настройка несложного брандмауэра для разрешения доступа к порту 10250

Чтобы принудительно разрешить доступ к порту 10250, выполните следующую az vmss run-command invoke команду:

az vmss run-command invoke --resource-group <infra-or-MC-resource-group> \
    --name <virtual-machine-scale-set-name> \
    --command-id RunShellScript \
    --instance-id <instance-id> \
    --scripts "ufw allow 10250" \
    --output tsv \
    --query 'value[0].message'

Причина 3. Инструмент iptables блокирует порт 10250

Примечание.

Это касается любого компонента туннеля, который у вас есть в кластере AKS.

Средство iptables позволяет системным администраторам настраивать правила фильтрации IP-пакетов брандмауэра Linux. Вы можете настроить правила iptables, чтобы блокировать связь через порт 10250.

Вы можете просмотреть правила для узлов, чтобы проверить, блокируется ли порт 10250 или удаляются связанные пакеты. Для этого выполните следующую iptables команду:

iptables --list --line-numbers

В выходных данных данные группируются в несколько цепочек, включая цепочку INPUT . Каждая цепочка содержит таблицу правил под следующими заголовками столбцов:

• num (номер правила)
• target
• prot (протокол)
• opt
• source
• destination

Содержит ли цепочка INPUT правило, где цель — DROP, протокол — tcp, и назначение — tcp dpt:10250? Если это так, iptables блокирует доступ к целевому порту 10250.

Решение 3. Удаление правила iptables, которое блокирует доступ к порту 10250

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

iptables --delete INPUT --jump DROP --protocol tcp --source <ip-number> --destination-port 10250

iptables --delete INPUT <input-rule-number>

Чтобы устранить ваш точный или потенциальный сценарий, рекомендуется проверить инструкцию по iptables, выполнив команду iptables --help.

Внимание

Прежде чем использовать это средство для внесения изменений, просмотрите политику поддержки AKS (особенно обслуживание узлов и доступ), чтобы предотвратить вход кластера в неподдерживаемый сценарий.

Причина 4. Исходящий порт 1194 или 9000 не открыт

Примечание.

Эта причина относится только к модулям tunnel-front pod и aks-link pod.

Существуют ли ограничения исходящего трафика, например из брандмауэра AKS? Если такие условия есть, для правильного функционирования tunnel-front pod требуется порт 9000. Аналогично, для Pod требуется порт 1194.

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

Решение 4. Открытие порта 9000

Хотя tunnel-front был перемещён в службу Konnectivity, некоторые кластеры AKS всё ещё используют tunnel-front, который завязан на порте 9000. Убедитесь, что виртуальное устройство или любое сетевое устройство или программное обеспечение разрешает доступ к порту 9000. Дополнительные сведения о необходимых правилах и зависимостях см. в статье "Глобальные правила сети Azure".

Причина 5. Исчерпание портов преобразования сетевых адресов источника (SNAT)

Примечание.

Это касается любого компонента туннеля, который имеется в вашем кластере AKS. Однако он не применяется к частным кластерам AKS. Исчерпание портов преобразования сетевых адресов источника (SNAT) может происходить только для общедоступного обмена данными. Для частных кластеров AKS сервер API находится в виртуальной сети ИЛИ подсети AKS.

Если происходит исчерпание портов SNAT (сбой портов SNAT), узлы не могут подключаться к серверу API. Контейнер туннеля находится на стороне сервера API. Поэтому подключение к туннелям не будет установлено.

Если ресурсы портов SNAT исчерпаны, исходящие потоки завершаются ошибкой до тех пор, пока существующие потоки не освободят некоторые порты SNAT. Azure Load Balancer освобождает порты SNAT при закрытии потока. В нем используется четырехминутное время ожидания простоя для возврата портов SNAT от неактивных потоков.

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

Метрики подсистемы балансировки нагрузки AKS

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

1. В портал Azure найдите и выберите службы Kubernetes.

2. В списке служб Kubernetes выберите имя кластера.

3. В области меню кластера найдите заголовок "Параметры ", а затем выберите "Свойства".

4. Выберите имя, указанное в группе ресурсов инфраструктуры.

5. Выберите подсистему балансировки нагрузки Kubernetes .

6. В области меню подсистемы балансировки нагрузки найдите заголовок "Мониторинг " и выберите "Метрики".

7. Для типа метрики выберите число подключений SNAT.

8. Выберите Применить разделение.

9. Задайте для параметра "Разделить по состоянию подключения".

Диагностика службы

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

1. В портал Azure найдите и выберите службы Kubernetes.

2. В списке служб Kubernetes выберите имя кластера.

3. В области меню кластера выберите " Диагностика и решение проблем".

4. Выберите "Проблемы с подключением".

5. В разделе "Подключение SNAT" и "Выделение портов" выберите "Просмотр сведений".

6. При необходимости нажмите кнопку "Диапазон времени" для настройки интервала времени.

Решение 5a. Убедитесь, что приложение использует пул подключений

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

Решение 5b. Настройка выделенных исходящих портов

Если все в приложении в порядке, необходимо настроить выделенные исходящие порты. Дополнительные сведения о выделении исходящих портов см. в разделе "Настройка выделенных исходящих портов".

Решение 5c. Использование шлюза преобразования управляемых сетевых адресов (NAT) при создании кластера

Вы можете настроить новый кластер для использования шлюза преобразования сетевых адресов (NAT) для исходящих подключений. Дополнительные сведения см. в статье "Создание кластера AKS с помощью управляемого шлюза NAT".

Причина 6. Проблемы с производительностью агентов Konnectivity при росте кластера

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

Примечание.

Эта причина относится только к модулям Konnectivity-agent pod.

Решение 6. Пропорциональное автомасштабирование кластера для агента Konnectivity

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

Почему это изменение было сделано Ранее агент Konnectivity имел фиксированное число реплик, которое могло создать узкие места по мере роста кластера. Реализуя пропорциональное автомасштабирование кластера, мы предоставляем возможность динамически настраивать количество реплик на основе правил масштабирования узлов, чтобы обеспечить оптимальную производительность и использование ресурсов.

Как работает пропорциональный автомасштабировщик кластера Пропорциональный автомасштабировщик кластера использует лестничную конфигурацию для определения количества реплик агента Konnectivity в зависимости от размера кластера. Конфигурация ladder определена в configmap konnectivity-agent-autoscaler в пространстве имен kube-system. Ниже приведен пример конфигурации лестницы:

nodesToReplicas": [
    [1, 2],
    [100, 3],
    [250, 4],
    [500, 5],
    [1000, 6],
    [5000, 10]
]

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

Как использовать пропорциональное автомасштабирование кластера? Значения по умолчанию можно переопределить, обновив конфигурацию конфигурации агента-agent-autoscaler в пространстве имен kube-system. Ниже приведен пример команды для обновления конфигурации:

kubectl edit configmap <pod-name> -n kube-system

Эта команда открывает карту конфигурации в редакторе, чтобы можно было внести необходимые изменения.

Что необходимо проверить

Необходимо отслеживать удаление памяти (OOM) на узлах, так как неправильное настройка пропорционального автомасштабирования кластера может привести к недостаточному выделению памяти для агентов Konnectivity. Эта ошибка конфигурации возникает по следующим ключевым причинам:

Высокая загрузка памяти: По мере роста кластера использование памяти агентов Konnectivity может значительно увеличиться. Это увеличение может происходить особенно во время пиковых нагрузок или при обработке большого количества подключений. Если конфигурация пропорционального автомасштабирования кластера не масштабирует реплики соответствующим образом, агенты могут выйти из памяти.

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

Вариативность размера кластера и рабочей нагрузки: ЦП и память, необходимые агентами Konnectivity, могут значительно отличаться в зависимости от размера кластера и рабочей нагрузки. Если конфигурация лестницы пропорционального автомасштабирования кластера не корректно настроена и адаптивно изменяется в соответствии с шаблонами использования кластера, это может привести к переполнению памяти и завершению процессов из-за нехватки памяти.

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

1. Проверьте наличие OOM-наказаний на узлах: Используйте следующую команду для проверки OOM-наказаний на ваших узлах.

kubectl get events --all-namespaces | grep -i 'oomkill'

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

kubectl top nodes

3. Просмотрите запросы и ограничения ресурсов pod: убедитесь, что модули pod агента Konnectivity имеют соответствующие запросы ресурсов и ограничения, чтобы предотвратить убийство OOM:

kubectl get pod <pod-name> -n kube-system -o yaml | grep -A5 "resources:"

4. Настройте запросы и ограничения ресурсов: при необходимости настройте запросы ресурсов и ограничения для модулей pod агента Konnectivity, изменив развертывание:

kubectl edit deployment konnectivity-agent -n kube-system

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

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

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

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