Обзор сетей CNI для Azure Kubernetes Service (AKS)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Выбор CNI

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

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

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

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

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

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

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

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

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

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

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

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

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

• Платформа Azure может автоматически создавать и настраивать ресурсы виртуальной сети при создании кластера AKS. например, в системе наложенного виртуального сетевого интерфейса Azure CNI, подсетях узлов Azure CNI и 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 или диапазона адресов виртуальной сети кластера.
• В сценариях виртуальной сети BYO удостоверение кластера, используемое кластером AKS, должно обладать как минимум правами сетевого участника в подсети вашей виртуальной сети. Если вы хотите определить пользовательскую роль вместо использования встроенной роли участника сети, требуются следующие разрешения:
  • Microsoft.Network/virtualNetworks/subnets/join/action
  • Microsoft.Authorization/roleAssignments/write
  • Microsoft.Network/virtualNetworks/subnets/read (требуется только в том случае, если вы определяете собственные подсети и идентификаторы CIDR)
• Подсеть, назначенная пулу узлов AKS, не может быть делегированной подсетью.
• AKS не применяет группы безопасности сети (NSG) к своей подсети и не изменяет ни одну из групп безопасности сети, связанных с этой подсетью. Если вы предоставляете свою собственную подсеть и добавляете группы безопасности сети, связанные с этой подсетью, необходимо убедиться, что правила безопасности в группах безопасности сети разрешают трафик в пределах диапазона CIDR узла. Дополнительные сведения см. в разделе Группы безопасности сети.

Следующие шаги

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