Интерфейс контейнерной сети Azure (CNI) оверлейная сеть

При использовании Azure CNI Overlay, узлы кластера развертываются в подсети Azure Виртуальной Сети (VNet). Модули pod получают IP-адреса из частного CIDR, логически отличного от виртуальной сети, в которой размещены узлы. Трафик pod и узла в кластере использует оверлейную сеть. Преобразование сетевых адресов (NAT) использует IP-адрес узла для доступа к ресурсам за пределами кластера. Это решение экономит значительное количество IP-адресов виртуальной сети и позволяет масштабировать кластер до больших размеров. Дополнительное преимущество заключается в том, что вы можете повторно использовать частный CIDR в разных кластерах AKS, что расширяет IP-пространство, доступное для контейнерных приложений в Службе Azure Kubernetes (AKS).

Общие сведения о сети оверлей

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

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

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

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

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

Различия между kubenet и оверлейной сетью Azure CNI

В следующей таблице приведено подробное сравнение kubenet и Azure CNI Overlay.

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

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

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

/24 Подсеть может вмещать до 251 узла, так как первые три IP-адреса зарезервированы для задач управления.

Pods

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

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

• Убедитесь, что частный CIDR достаточно большой, чтобы обеспечить /24 адресные пространства новым узлам для поддержки будущего расширения кластера.
• Один и тот же диапазон CIDR для pod можно использовать в нескольких независимых кластерах AKS в одной виртуальной сети.
• Диапазон CIDR для pod не должен перекрываться с диапазоном подсети кластера.
• Пространство CIDR pod не должно перекрываться напрямую подключенными сетями (например, пиринг виртуальных сетей, ExpressRoute или VPN). Если внешний трафик имеет исходные IP-адреса в диапазоне podCIDR, он должен передаваться в не перекрывающийся IP-адрес через SNAT для взаимодействия с кластером.

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

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

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

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

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

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

• Трафик от CIDR узла к CIDR узлу на всех портах и протоколах
• Трафик от CIDR узла к CIDR pod на всех портах и всех протоколах (необходимый для маршрутизации трафика службы)
• Трафик из CIDR pod в CIDR pod по всем портам и протоколам (необходимый для трафика между подами и от подов к сервисам, включая DNS-запросы)

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

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

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

Максимальное количество объектов pod на узел можно настроить во время создания кластера или при добавлении нового пула узлов. Значение по умолчанию и максимальное значение для наложения Azure CNI равно 250., а минимальное значение — 10. Максимальное число pod'ов на узелок, указанное во время создания пула узлов, применяется только к узлам в этом пуле.

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

Azure CNI предлагает два варианта IP-адресации для модулей pod: традиционная конфигурация, которая назначает IP-адреса виртуальной сети модулям pod и сети Overlay. При выборе варианта для кластера AKS учитывается баланс гибкости и потребностей в расширенной конфигурации. Следующие рекомендации помогут определить, когда каждая сетевая модель может быть наиболее подходящей.

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

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

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

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

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

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

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