Обзор сетевого наложения Azure CNI в службе Azure Kubernetes (AKS)

Azure CNI Overlay — это сетевая модель для Azure Kubernetes Service (AKS), которая обеспечивает эффективное управление IP-адресами и высокопроизводительное взаимодействие pod. В этой статье представлен обзор Azure CNI Overlay, включая его архитектуру, планирование IP-адресов и различия с традиционной моделью сетевой связи kubenet.

Как работает сеть наложения CNI Azure

Модель сетевого интерфейса контейнера (CNI) неструктурированного Azure назначает IP-адрес виртуальной сети каждому модулю pod. Azure подсеть pod CNI назначает IP-адреса pod из отдельной подсети, зарезервированной для модулей pod. Azure подсеть узла CNI (устаревшая версия) назначает IP-адреса pod из подсети узла. Эти неструктурированные параметры сети требуют планирования IP-адресов виртуальной сети и могут привести к нехватке адресов, что приводит к трудностям масштабирования кластеров по мере роста требований приложения.

В сети наложения только узлы кластера Kubernetes получают IP-адреса из подсетей. Поды получают IP-адреса из частного диапазона бесклассовой междоменной маршрутизации (CIDR), предоставленного при создании кластера. Каждому узлу выделяется адресное пространство /24, вырезанное из одного и того же диапазона CIDR. Дополнительные узлы, созданные при горизонтальном масштабировании кластера, автоматически получают /24 адресные пространства из того же CIDR. Azure CNI назначает IP-адреса модулям pod из этого пространства /24.

Отдельный домен маршрутизации создается в сетевом стеке Azure для частного пространства CIDR pod. Этот домен создает оверлейную сеть для прямого обмена данными между подами. Нет необходимости подготавливать пользовательские маршруты в подсети кластера или использовать метод инкапсуляции для туннелирования трафика между модулями pod, что обеспечивает производительность подключения между модулями pod в паре с виртуальными машинами в виртуальной сети. Рабочие нагрузки, выполняемые в модулях pod, даже не знают, что происходит обработка сетевых адресов.

Обмен данными с конечными точками за пределами кластера, такими как локальные и пиринговые виртуальные сети, использует IP-адрес узла через преобразование сетевых адресов (NAT). Azure CNI преобразует исходный IP-адрес (наложенный IP-адрес pod) трафика на основной IP-адрес виртуальной машины узла. Эта функция позволяет сетевому стеку Azure направлять трафик в место назначения.

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

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

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

Различия между kubenet и Azure CNI Overlay

Как и в Azure CNI Overlay, kubenet назначает IP-адреса подам из адресного пространства, которое логически отличается от виртуальной сети, но имеет ограничения по масштабируемости и другие недостатки. В следующей таблице представлено подробное сравнение kubenet и Azure CNI Overlay.

Максимальные значения узлов и модулей pod для каждого узла являются независимыми ограничениями. Не умножайте их, чтобы определить поддерживаемую статистическую емкость pod кластера. При планировании масштабирования кластера ознакомьтесь с квотами и ограничениями службы AKS ирекомендациями по масштабируемости больших кластеров. Уровень управления, поведение рабочей нагрузки и другие ограничения служб влияют на достижимый масштаб.

Azure CNI Powered cilium предоставляет плоскость данных eBPF со встроенным применением политики сети Cilium. В плоскости данных Azure iptables можно использовать Calico или NPM Azure, но Azure NPM больше не поддерживается на Windows узлах с 30 сентября 2026 г. и поддержка на узлах Linux заканчивается 30 сентября 2028 г. Текущие рекомендации и рекомендации по миграции см. в разделе "Параметры политики сети" в AKS.

Планирование IP-адресов

В следующих разделах приведены инструкции по планированию IP-адресного пространства для Azure CNI Overlay.

Узлы кластера

При настройке кластера CNI Overlay AKS Azure убедитесь, что подсети виртуальной сети достаточно места для дальнейшего масштабирования. Вы можете назначить каждому пулу узлов отдельную подсеть. Подсеть /24 содержит 256 IP-адресов. Azure резервирует первые четыре и последние IP-адреса, оставляя 251 доступные адреса. При размере подсети также резервируйте адресное пространство для операций обновления и масштабирования и других ресурсов в подсети.

Подшипники

Размер /24, который назначает Azure CNI Overlay, фиксированный и не может быть увеличен или уменьшен. На узле можно запустить до 250 подов. При планировании адресного пространства pod убедитесь, что частный CIDR достаточно велик, чтобы предоставить /24 адресные пространства для новых узлов для поддержки будущего расширения кластера.

При планировании пространства IP-адресов для модулей pod следует учитывать следующие факторы:

• Одно и то же пространство POD CIDR можно использовать в нескольких независимых кластерах AKS в одной виртуальной сети.
• Диапазон CIDR для pod не должен перекрываться с диапазоном подсети кластера.
• Пространство CIDR pod не должно перекрываться напрямую подключенными сетями, такими как пиринг виртуальных сетей, Azure ExpressRoute или VPN. Если источник IP-адреса внешнего трафика попадает в диапазон pod CIDR, для взаимодействия с кластером он должен быть преобразован через SNAT в неперекрывающийся IP-адрес.
• В Azure кластерах наложения CNI только с узлами Linux можно развернуть CIDR pod до более крупного непрерывного супермножества, содержащего исходный диапазон. Сжатие или замена диапазона не поддерживается. Расширение также не поддерживается для сценариев Windows или гибридных узлов, IPv6 pod CIDR или нескольких блоков CIDR pod.

Диапазон адресов службы Kubernetes

Размер CIDR адреса службы зависит от количества создаваемых служб кластера. Он должен быть меньше /12. Этот диапазон не должен перекрываться с диапазоном CIDR pod, диапазоном подсети кластера и диапазоном IP-адресов, используемым в одноранговых виртуальных сетях и локальных сетях.

IP-адрес службы Kubernetes для DNS

IP-адрес для DNS находится в диапазоне адресов службы Kubernetes, который использует кластерное обнаружение сервисов. Не используйте первый IP-адрес в диапазоне адресов, так как этот адрес используется для kubernetes.default.svc.cluster.local адреса.

Группы безопасности сети

Трафик pod-to-pod с Azure CNI Overlay не инкапсулируется, и применяются правила подсети группы безопасности сети (NSG). Если группа безопасности сети подсети содержит правила запрета, которые влияют на трафик CIDR pod, убедитесь, что были соблюдены следующие правила, чтобы обеспечить правильную функциональность кластера (помимо выполнения всех требований к исходящему трафику AKS):

Трафик из pod в любое место за пределами блока CIDR pod использует SNAT для назначения исходного IP-адреса IP-адресу узла, на котором выполняется pod.

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

Максимальное число pod на каждом узле

Можно настроить максимальное количество модулей pod на узел при создании кластера или добавлении нового пула узлов.

Значение максимального количества pod на узел, настраиваемое во время создания пула, применяется только к узлам в этом пуле.

Для контейнеров Windows Server максимальное рекомендуемое значение составляет 110 модулей pod на узел. Это рекомендуемое операционное значение меньше настраиваемого Azure наложения CNI не более 250 модулей pod на узел. Дополнительные сведения см. в статье о квотах и ограничениях службы AKS.

Выбор сетевой модели

Используйте наложение сети, когда:

• Вы хотите масштабировать до большого количества подов, но ограничены пространством IP-адресов в виртуальной сети.
• Большая часть обмена данными между объектами pod происходит в пределах кластера.
• Вам не требуются расширенные возможности AKS, такие как виртуальные узлы.

Используйте неструктурированные сети, когда:

• У вас есть имеющееся IP-адресное пространство.
• Большая часть обмена данными подов происходит с ресурсами за пределами кластера.
• Ресурсы за пределами кластера должны напрямую достигать подов.
• Вам требуются расширенные возможности AKS, такие как виртуальные узлы.

Azure CNI предоставляет Azure наложение CNI для наложения сети и Azure подсеть pod pod CNI или Azure подсеть узла CNI (устаревшая версия) для неструктурированных сетей. Подробное сравнение этих параметров управления IP-адресами см. в разделе "Планирование сети pod для AKS".

Ограничения с оверлеем Azure CNI

Наложение Azure CNI имеет следующие ограничения:

• Группы доступности виртуальных машин не поддерживаются.
• Виртуальные машины серии DCsv2 нельзя использовать в пулах узлов. Чтобы удовлетворить требования к конфиденциальным вычислениям, рекомендуется использовать конфиденциальные виртуальные машины серии DCasv5 или DCadsv5 .
• Если вы используете собственную подсеть для развертывания кластера, имена подсети, виртуальной сети и группы ресурсов, содержащей виртуальную сеть, должны быть 63 символами или меньше. Эти имена используются в качестве меток в рабочих узлах AKS, поэтому они подчиняются правилам синтаксиса Kubernetes для меток.

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

Чтобы начать работу с Azure CNI Overlay в AKS, ознакомьтесь со следующими статьями:

• Настройка наложения сети Azure CNI в Azure Kubernetes Service (AKS)
• Расширение пространства под CIDR в кластерах Azure Kubernetes Service (AKS) оверлея Azure CNI