Обзор сети CNI Служба Azure Kubernetes (AKS)

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

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

Сетевые модели в AKS

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

AKS использует две основные сетевые модели: наложение сети и плоскую сеть.

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

Наложение сетей

Наложение сети — это наиболее распространенная сетевая модель, используемая в Kubernetes. В сетях наложения модули pod получают IP-адрес из частного, логически отделяя CIDR от подсети виртуальной сети Azure, в которой развертываются узлы AKS. Это позволяет упростить и часто лучше масштабируемость, чем модель плоской сети.

В сетях наложения модули pod могут напрямую взаимодействовать друг с другом. Трафик, покидающий кластер, — исходный сетевой адрес, преобразованный (SNAT-d) на IP-адрес узла, и входящий IP-трафик pod направляется через определенную службу, например подсистему балансировки нагрузки. Это означает, что IP-адрес pod скрыт за IP-адресом узла. Этот подход сокращает количество IP-адресов виртуальной сети, необходимых для кластеров.

Служба Azure Kubernetes предоставляет следующие подключаемые модули CNI для наложения сети:

• Azure CNI Overlay — рекомендуемый подключаемый модуль CNI для большинства сценариев.
• kubenet, устаревшая модель наложения CNI.

Неструктурированные сети

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

Служба Azure Kubernetes предоставляет два подключаемых модуля CNI для неструктурированных сетей. Эта статья не содержит подробных сведений о каждом параметре подключаемого модуля. Дополнительные сведения см. в связанной документации:

• Подсеть Pod Pod Azure CNI— рекомендуемый подключаемый модуль CNI для сценариев с неструктурированными сетями.
• Подсеть узла CNI Azure, устаревшая модель сети CNI обычно рекомендует использовать только в том случае, если для кластера требуется управляемая виртуальная сеть.

Выбор CNI

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

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

Две основные сетевые модели в AKS — наложение и плоские сети.

• Наложение сетей:

  • Экономия пространства IP-адресов виртуальной сети с помощью логически отдельных диапазонов CIDR для модулей pod.
  • Максимальная поддержка масштабирования кластера.
  • Простое управление IP-адресами.

• Неструктурированные сети:

  • Модули Pod получают полное подключение к виртуальной сети и могут быть напрямую доступны через частный IP-адрес из подключенных сетей.
  • Требует большого, не фрагментированного IP-адреса виртуальной сети.

Сравнение вариантов использования

При выборе сетевой модели рассмотрите варианты использования для каждого подключаемого модуля CNI и тип используемой сетевой модели:

Подключаемый модуль CNI	Сетевая модель	Основные моменты вариантов использования
Наложение Azure CNI	Наложение	— Лучше всего подходит для сохранения IP-адресов виртуальной сети. — максимальное количество узлов, поддерживаемое API Server + 250 модулей pod на узел — упрощенная конфигурация -Нет прямого доступа к IP-адресу внешнего pod
Подсеть Pod Pod Azure CNI (предварительная версия)	Фиксированная	— прямой доступ к внешнему модулем pod — режимы эффективного использования IP-адресов виртуальной сети или поддержки масштабируемого кластера
Kubenet (устаревшая версия)	Наложение	— Приоритеты сохранения IP-адресов — ограниченное масштабирование — ручное управление маршрутами
Подсеть узла CNI Azure (устаревшая версия)	Фиксированная	— прямой доступ к внешнему модулем pod — упрощенная конфигурация — ограниченное масштабирование — неэффективное использование IP-адресов виртуальной сети

Сравнение возможностей

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

Функция	Наложение Azure CNI	Подсеть Pod Pod Azure CNI	Подсеть узла CNI Azure (устаревшая версия)	Kubenet
Развертывание кластера в существующей или новой виртуальной сети	Поддерживается	Поддерживаемые	Поддерживается	Поддерживается— UDR вручную
Подключение pod-VM с виртуальной машиной в одной или одноранговой виртуальной сети	Модуль Pod, инициированный	Оба способа	Оба способа	Модуль Pod, инициированный
Локальный доступ через VPN/Express Route	Модуль Pod, инициированный	Оба способа	Оба способа	Модуль Pod, инициированный
Доступ к конечным точкам службы	Поддерживается	Поддерживаемые	Поддерживаемые	Поддерживается
Предоставление служб с помощью подсистемы балансировки нагрузки	Поддерживается	Поддерживаемые	Поддерживаемые	Поддерживается
Предоставление служб с помощью шлюза приложений	Сейчас не поддерживаются:	Поддерживается	Поддерживаемые	Поддерживается
Предоставление служб с помощью контроллера входящего трафика	Поддерживается	Поддерживаемые	Поддерживаемые	Поддерживается
пулы узлов Windows;	Поддерживается	Поддерживаемые	Поддерживается	Не поддерживается
Azure DNS по умолчанию и частные зоны	Поддерживается	Поддерживаемые	Поддерживаемые	Поддерживается
Общий доступ к подсети виртуальной сети в нескольких кластерах	Поддерживается	Поддерживаемые	Поддерживается	Не поддерживается

Область поддержки между сетевыми моделями

В зависимости от используемого CNI ресурсы виртуальной сети кластера можно развернуть одним из следующих способов:

• Платформа Azure может автоматически создавать и настраивать ресурсы виртуальной сети при создании кластера AKS. например, в наложении Azure CNI, подсети узла CNI Azure и Kubenet.
• Вы можете вручную создать и настроить ресурсы виртуальной сети и присоединить их к этим ресурсам при создании кластера AKS.

Хотя поддерживаются такие возможности, как конечные точки службы или определяемые пользователем ресурсы, политики поддержки ДЛЯ AKS определяют, какие изменения можно внести. Например:

• Если вы вручную создаете ресурсы виртуальной сети для кластера AKS, вы получите поддержку при настройке собственных UDRs или служебных конечных точек.
• Если платформа Azure автоматически создает ресурсы виртуальной сети для кластера AKS, то невозможно будет вручную изменить ресурсы, управляемые AKS, чтобы настроить собственные UDR и служебные конечные точки.

Необходимые компоненты

При планировании конфигурации сети для AKS следует учитывать несколько требований и рекомендаций.

• Виртуальная сеть для кластера AKS должна разрешать исходящее подключение к Интернету.
• Кластеры AKS не могут использовать 169.254.0.0/16, 172.30.0.0/16172.31.0.0/16или 192.0.2.0/24 для диапазона адресов службы Kubernetes, диапазона адресов pod или диапазона адресов виртуальной сети кластера.
• В сценариях CNI BYO удостоверение кластера, используемое кластером AKS, должно иметь по крайней мере разрешения участника сети в подсети в виртуальной сети. Если вы хотите определить пользовательскую роль вместо использования встроенной роли участника сети, требуются следующие разрешения:
  • Microsoft.Network/virtualNetworks/subnets/join/action
  • Microsoft.Network/virtualNetworks/subnets/read
  • Microsoft.Authorization/roleAssignments/write
• Подсеть, назначенная пулу узлов AKS, не может быть делегированной подсетью.
• AKS не применяет группы безопасности сети (NSG) к своей подсети и не изменяет ни одну из групп безопасности сети, связанных с этой подсетью. Если вы предоставляете свою собственную подсеть и добавляете группы безопасности сети, связанные с этой подсетью, необходимо убедиться, что правила безопасности в группах безопасности сети разрешают трафик в пределах диапазона CIDR узла. Дополнительные сведения см. в разделе Группы безопасности сети.

Next Steps

• Наложение Azure CNI
• Подсеть Pod Pod Azure CNI
• Устаревшие параметры CNI
• Планирование IP-адресов для кластеров