Устаревшие сетевые интерфейсы контейнеров AKS (CNI)

Это важно

В 31 марта 2028 сеть Kubenet для Azure Kubernetes Service (AKS) будет прекращена.

Чтобы избежать сбоев в работе служб, вам необходимоперейти на наложение интерфейса Azure Container Networking Interface (CNI)до этой даты, когда больше не будут поддерживаться рабочие нагрузки на kubenet для AKS.

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

Предварительные условия

Для Azure подсети узла CNI требуются следующие предварительные требования:

• Виртуальная сеть для кластера AKS должна разрешать исходящее подключение к Интернету.

• Кластеры AKS не могут использовать 169.254.0.0/16, 172.30.0.0/16172.31.0.0/16или 192.0.2.0/24 для диапазона адресов службы Kubernetes, диапазона адресов pod или диапазона адресов виртуальной сети кластера.

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

  • Microsoft.Network/virtualNetworks/subnets/join/action
  • Microsoft.Network/virtualNetworks/subnets/read
  • Microsoft.Authorization/roleAssignments/write

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

• AKS не применяет группы безопасности сети (NSG) к своей подсети и не изменяет ни одну из групп безопасности сети, связанных с этой подсетью. Если вы предоставляете собственную подсеть и добавляете группы безопасности, связанные с этой подсетью, убедитесь, что правила безопасности в группах безопасности разрешают трафик в пределах диапазона CIDR узла. Дополнительные сведения см. в разделе Группы безопасности сети.

подсеть узла CNI Azure

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

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

Параметры развертывания

При создании кластера AKS можно настроить следующие параметры для Azure сети CNI:

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

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

Плагин Azure сети: Если используется плагин Azure сети, внутренняя служба LoadBalancer с "externalTrafficPolicy=Local" недоступна из виртуальных машин с IP-адресом в кластере CIDR, который не принадлежит кластеру AKS.

Диапазон адресов службы Kubernetes. Этот параметр представляет собой набор виртуальных IP-адресов, которые Kubernetes назначает службам в вашем кластере. Можно использовать любой диапазон частных адресов, который отвечает следующим требованиям:

Примечание.

Начиная с Kubernetes 1.33, можно расширить диапазон IP-адресов службы после создания кластера с помощью ServiceCIDR ресурса Kubernetes. Дополнительные сведения см. в разделе "Расширение диапазонов IP-адресов службы " в документации по Kubernetes. В кластерах, работающих с более ранними версиями, диапазон адресов службы не может быть обновлен после создания кластера.

• Не должно находиться в диапазоне IP-адресов виртуальной сети кластера.
• Не должны перекрываться с другими виртуальными сетями, с которыми одноранговая сеть виртуальной сети кластера.
• Не должно перекрываться ни с одним локальным IP-адресом.
• Не должно находиться в пределах диапазонов169.254.0.0/16, 172.30.0.0/16172.31.0.0/16или192.0.2.0/24.

Хотя можно указать диапазон адресов службы в той же виртуальной сети, как и кластер, но мы не рекомендуем этого делать. Перекрывающиеся диапазоны IP-адресов могут привести к непредсказуемому поведению. Дополнительные сведения см. в разделе Часто задаваемые вопросы. Дополнительные сведения о службах Kubernetes см. в этой документации.

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

• Azure CNI. Этот же базовый диапазон /24 может поддерживать только максимум 8 узлов в кластере. Это число узлов может поддерживать только до 240 модулей pod, при этом по умолчанию не более 30 модулей pod на узел.

Примечание.

В этих максимальных значениях не учитываются операции обновления или масштабирования. На практике невозможно запустить максимальное количество узлов, поддерживаемых диапазоном IP-адресов подсети. Необходимо оставить некоторые IP-адреса доступными для операций масштабирования или обновления.

Пиринг виртуальных сетей и подключения ExpressRoute

Для обеспечения локального подключения можно использовать пиринг виртуальных сетей Azure или подключения ExpressRoute с Azure CNI. Тщательно спланируйте IP-адреса, чтобы предотвратить перекрывающиеся и неправильные маршрутизации трафика. Например, многие локальные сети используют диапазон адресов 10.0.0.0/8 , объявленный через подключение ExpressRoute. Мы рекомендуем создавать кластеры AKS в подсетях виртуальной сети Azure за пределами этого диапазона адресов, например 172.16.0.0/16.

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

Подсеть CNI для подов Azure: часто задаваемые вопросы

• Можно ли развернуть виртуальные машины в подсети моего кластера?

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

• Какой исходный IP-адрес видят внешние системы для трафика, исходящего из пода с поддержкой Azure CNI?

  Системы в той же виртуальной сети, что и кластер AKS, определяют IP-адрес pod в качестве исходного адреса для любого трафика, передаваемого из этого pod. Системы вне виртуальной сети, в которой размещен кластер AKS, определяют IP-адрес узла в качестве исходного адреса для любого трафика, передаваемого из pod. Но для динамическое выделение IP-адресов Azure CNI независимо от того, находится ли подключение внутри одной виртуальной сети или между виртуальными сетями, IP-адрес pod всегда является исходным адресом для любого трафика из pod. Это связано с тем, что Azure CNI для динамического выделения IP-адресов реализует инфраструктуру Microsoft Azure сети контейнеров, которая обеспечивает комплексный интерфейс. Поэтому он исключает использование ip-masq-agent, которое по-прежнему используется в традиционной реализации Azure CNI.

• Можно ли настроить сетевые политики для каждого пода?

  Да, политика сети Kubernetes доступна в AKS. Чтобы приступить к работе, ознакомьтесь со статьей Защита трафика между подами с использованием политик сети в AKS.

• Можно ли настроить максимальное число pod'ов, развертываемых на узле?

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

• Можно ли развернуть виртуальные машины в подсети моего кластера?

  Да. Но для Azure CNI для динамического выделения IP-адресов нельзя развернуть виртуальные машины в подсети pod.

• Какие исходные IP-адреса видят внешние системы для трафика, который исходит из pod с поддержкой Azure CNI?

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

  Но для Azure CNI для динамического выделения IP-адресов независимо от того, что подключение находится внутри одной виртуальной сети или между виртуальными сетями, IP-адрес pod всегда является исходным адресом для любого трафика из pod. Это связано с тем, что Azure CNI для динамического выделения IP-адресов реализует сетевую инфраструктуру Microsoft Azure для контейнеров, которая обеспечивает комплексный опыт. Таким образом, это исключает использование ip-masq-agent, которое по-прежнему используется традиционными Azure CNI.

• Можно ли использовать другую подсеть в виртуальной сети кластера для диапазона адресов службы Kubernetes?

  Не рекомендуется, но эта конфигурация возможна. Диапазон адресов службы — это набор виртуальных IP-адресов, которые Kubernetes присваивает внутренним службам в кластере. Сетевые службы Azure не могут видеть диапазон IP-адресов сервисов кластера Kubernetes. Отсутствие видимости диапазона адресов службы кластера может привести к проблемам. Позже можно создать новую подсеть в виртуальной сети кластера, которая пересекается с диапазоном адресов для служб. При возникновении такого пересекания Kubernetes может присвоить службе IP-адрес, который уже используется другим ресурсом в подсети, что приводит к непредсказуемому поведению или сбоям. Убедившись, что диапазон адресов используется за пределами виртуальной сети кластера, можно избежать такого риска пересечений. Да, при развертывании кластера с помощью Azure CLI или шаблона Resource Manager. См. раздел Максимальное количество подов на узел.

• Можно ли использовать другую подсеть в виртуальной сети кластера для диапазона адресов службы Kubernetes?

  Не рекомендуется, но эта конфигурация возможна. Диапазон адресов службы — это набор виртуальных IP-адресов, которые Kubernetes присваивает внутренним службам в кластере. Сетевые службы Azure не видят диапазон IP-адресов службы кластера Kubernetes. Отсутствие видимости диапазона адресов службы кластера может привести к проблемам. Позже можно создать новую подсеть в виртуальной сети кластера, которая пересекается с диапазоном адресов для служб. При возникновении такого пересекания Kubernetes может присвоить службе IP-адрес, который уже используется другим ресурсом в подсети, что приводит к непредсказуемому поведению или сбоям. Убедившись, что диапазон адресов используется за пределами виртуальной сети кластера, можно избежать такого риска пересечений.