Общие сведения о сети Azure CNI в Служба Azure Kubernetes (AKS)

По умолчанию кластеры AKS используют kubenet и создают виртуальную сеть и подсеть. При использовании kubenet узлы получают IP-адрес из подсети виртуальной сети. Затем настраивается преобразование сетевых адресов (NAT) на узлах, а модули получают IP-адрес, "скрытый" за IP-адресом узла. Такой подход уменьшает количество IP-адресов, которые необходимо зарезервировать в пространстве сети для модулей pod.

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

Примечание.

В этой статье рассматриваются только традиционные azure CNI. Для наложения Azure CNI виртуальные сети Azure CNI для динамического распределения IP-адресов и виртуальной сети 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 узла. Дополнительные сведения см. в разделе Группы безопасности сети.

Планирование назначения IP-адресов для кластера

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

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

Внимание

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

  • При обновлении кластера AKS в нем развертывается новый узел. Службы и рабочие нагрузки теперь выполняются на новом узле, а старый узел удаляется из кластера. Для выполнения этого процесса последовательного обновления требуется, чтобы был доступен как минимум один дополнительный блок IP-адресов. Количество узлов будет равно n + 1.

    • Это особенно важно при использовании пулов узлов Windows Server. Узлы Windows Server в AKS не применяются автоматически Обновл. Windows. Вместо этого вы выполняете обновление в пуле узлов. Во время этого обновления развертываются новые узлы на основе последнего образа базового узла Windows Server 2019 с исправлениями безопасности. Дополнительные сведения об обновлении пула узлов Windows Server см. в статье Обновление пула узлов.
  • При масштабировании кластера AKS в него развертывается новый узел. Службы и рабочие нагрузки теперь выполняются на новом узле. Диапазон IP-адресов должен учитывать, как можно увеличить число узлов и модулей pod, которые может поддерживать кластер. Также следует включить один дополнительный узел для операций обновления. Количество узлов будет равно n + number-of-additional-scaled-nodes-you-anticipate + 1.

Если вы ожидаете, что узлы будут запускать максимальное количество модулей pod, а также регулярно уничтожать и развертывать модули pod, следует также учитывать некоторые дополнительные IP-адреса на узел. Для удаления службы и освобождения IP-адреса для развертывания новой службы и получения адреса может потребоваться несколько секунд. Эти дополнительные IP-адреса рассматривают эту возможность.

План IP-адреса для кластера AKS содержит виртуальную сеть, по крайней мере одну подсеть для узлов и контейнеров pod, а также диапазон адресов службы Kubernetes.

Диапазон адресов / ресурс Azure Установления размера и ограничения
Виртуальная сеть Виртуальная сеть Azure может достигать размера /8, но ограничиваться 65 536 настроенными IP-адресами. Прежде чем настраивать диапазон адресов, учтите все требования к сети, в том числе взаимодействие со службами в других виртуальных сетях. Например, если настроить слишком большое адресное пространство, могут возникнуть проблемы с перекрывающимися другими адресными пространствами в сети.
Подсеть Подсеть должна быть достаточно большой, чтобы разместить узлы, контейнеры pod и все ресурсы Kubernetes и Azure, которые могут быть выделены в кластере. Например, если развертывается внутренний Azure Load Balancer, его внешние IP-адреса выделяются из подсети кластера, а не из публичных IP-адресов. При выборе размера подсети следует также учитывать операции обновления учетной записи и будущие потребности в масштабировании.

Используйте следующее уравнение для вычисления минимального размера подсети, включая дополнительный узел для операций обновления: пример для кластера узлов 50: (number of nodes + 1) + ((number of nodes + 1) * maximum pods per node that you configure)

(/21 или больше)

Пример для 50 узлов, который также включает подготовку к масштабированию дополнительных 10 узлов: (51) + (51 * 30 (default)) = 1,581(61) + (61 * 30 (default)) = 1,891 (/21 или больше).

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

Диапазон адресов службы Kubernetes Любой сетевой элемент в этой виртуальной сети не должен использовать этот диапазон. Адрес службы CIDR должен иметь размер меньше /12. Этот диапазон можно повторно использовать в разных кластерах AKS.
IP-адрес службы DNS Kubernetes IP-адрес в диапазоне адресов службы Kubernetes, используемый обнаружением службы кластера. Не используйте первый IP-адрес своего диапазона адресов. Первый адрес в диапазоне подсети используется для адреса kubernetes.default.svc.cluster.local.

Максимальное число контейнеров pod на узле

Максимальное число модулей pod на каждом узле в кластере AKS — 250. Максимальное количество контейнеров pod по умолчанию для каждого узла зависит от сети kubenet, Azure CNI и метода развертывания кластера.

Метод развертывания По умолчанию Kubenet По умолчанию Azure CNI Настройка при развертывании
Azure CLI 110 30 Да (до 250)
Шаблон Resource Manager 110 30 Да (до 250)
Портал 110 110 (настраивается на вкладке "Пулы узлов") Да (до 250)

Настройка максимальных модулей pod на узел для новых кластеров

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

Если при создании пулов узлов не указано maxPods , вы получите значение по умолчанию 30 для Azure CNI.

Минимальное значение максимального числа модулей pod на узел применяется, чтобы обеспечить необходимое пространство для системных модулей pod, критически важных для работоспособности кластера. Минимальное значение максимального числа модулей pod на узел равно 10, но только если в конфигурации каждого пула узлов имеется место для не менее 30 модулей pod. Например, установка максимального количества модулей pod на узел не менее 10 требует, чтобы каждый отдельный пул узлов должен иметь не менее трех узлов. Это требование применяется для каждого нового пула узлов, созданного также, поэтому если 10 определяется как максимальные модули pod на узел, каждый добавленный пул узлов должен иметь не менее трех узлов.

Сеть Минимум Максимум
Azure CNI 10 250
Kubenet 10 250

Примечание.

Минимальное значение в предыдущей таблице строго применяется службой AKS. Нельзя задать значение maxPods, которое меньше минимального значения, так как это позволяет предотвратить запуск кластера.

  • Azure CLI. Укажите аргумент --max-pods при развертывании кластера с помощью команды az aks create. Максимальное значение — 250.
  • Шаблон Resource Manager. Укажите свойство maxPods в объекте ManagedClusterAgentPoolProfile при развертывании кластера с шаблоном Resource Manager. Максимальное значение — 250.
  • Портал Azure. Изменение Max pods per node поля в параметрах пула узлов при создании кластера или добавлении нового пула узлов.

Настройка максимальных модулей pod на узел для существующих кластеров

Параметр maxPods на узел можно определить при создании нового пула узлов. Если необходимо увеличить параметр maxPods в существующем кластере, добавьте новый пул узлов с новым требуемым числом maxPods . После переноса модулей pod в новый пул удалите старый пул. Чтобы удалить любой старый пул в кластере, убедитесь, что вы устанавливаете режимы пула узлов, как определено в документе пулов системных узлов.

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

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

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

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

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

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

  • Должен быть за пределами диапазона IP-адресов виртуальной сети вашего кластера.
  • Не должен пересекаться с диапазоном других виртуальных сетей, с которыми связан кластер виртуальной сети.
  • не должен перекрываться с какими-либо локальными IP-адресами.
  • Не должен быть в диапазонах 169.254.0.0/16, 172.30.0.0/16, 172.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 для динамического выделения 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.

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

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

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

    Да, при развертывании кластера с помощью Azure CLI или шаблона Resource Manager. См. статью Конфигурация сети в службе Azure Kubernetes (AKS).

    Невозможно изменить максимальное количество контейнеров pod в узле в имеющемся кластере.

  • Как настроить дополнительные свойства для подсети, созданной во время создания кластера AKS? Например, конечные точки службы.

    Полный список свойств для виртуальной сети и подсетей, создаваемых во время создания кластера AKS, можно настроить на странице стандартной конфигурации виртуальной сети на портале Azure.

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

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

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

Узнайте больше о сетевом взаимодействии в AKS из следующих статей: