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

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

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

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

• Виртуальная сеть для кластера 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 узла. Дополнительные сведения см. в разделе Группы безопасности сети.

Примечание.

Kubenet недоступен для контейнеров Windows Server. Чтобы использовать пулы узлов Windows Server, необходимо использовать Azure CNI.

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

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

При использовании подсети узла Azure CNI каждый модуль pod получает IP-адрес в подсети IP и может напрямую взаимодействовать с другими модулями pod и службами. Размер кластеров может соответствовать размеру указанного диапазона 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 назначает службам в вашем кластере. Этот диапазон нельзя обновить после создания кластера. Можно использовать любой диапазон частных адресов, который отвечает следующим требованиям:

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

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

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

Kubenet

Кластеры AKS используют kubenet и создают виртуальную сеть Azure и подсеть по умолчанию. При использовании kubenet узлы получают IP-адрес из подсети виртуальной сети Azure. Модули pod получают IP-адреса из логически различающегося адресного пространства в подсеть виртуальной сети Azure узлов. Затем настраивается преобразование сетевых адресов (NAT), чтобы модули pod могли получать доступ к ресурсам в виртуальной сети Azure. Исходный IP-адрес трафика преобразуется в первичный IP-адрес узла. Этот подход значительно сокращает количество IP-адресов, которые необходимо зарезервировать в сетевом пространстве для использования модулей pod.

Можно настроить максимальное количество модулей pod, развертываемых на узле во время создания кластера или при создании пулов узлов. Если при создании пулов узлов не указано maxPods значение по умолчанию 110 для kubenet.

Общие сведения о сети kubenet с использованием пользовательской подсети

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

При использовании kubenet IP-адрес в подсети виртуальной сети получают только узлы. Объекты Pod не могут взаимодействовать напрямую. Вместо этого определяемая пользователем маршрутизация (UDR) и IP-пересылка обрабатывают подключение между модулями pod между узлами. UDR и конфигурация IP-пересылки создаются и поддерживаются службой AKS по умолчанию, но вы можете использовать собственную таблицу маршрутов для пользовательского управления маршрутами, если вы хотите. Вы также можете развернуть модули pod за службой, которая получает назначенный IP-адрес и балансирует трафик для приложения. На приведенной ниже схеме показано, как узлы AKS (но не объекты pod) получают IP-адрес в подсети виртуальной сети:

поддержка Azure не более 400 маршрутов в UDR, поэтому у вас не может быть кластер AKS размером более 400 узлов. Виртуальные узлы AKS и политики сети Azure не поддерживаются с kubenet. Поддерживаются политики сети Calico.

Ограничения и рекомендации для kubenet

• При проектировании kubenet требуется дополнительный прыжок, что значительно увеличивает задержку связи с объектом pod.
• Для использования kubenet необходимы таблицы маршрутов и определяемые пользователем маршруты, что повышает сложность операций.
  • Дополнительные сведения см. в статье Настройка исходящего трафика кластера с помощью пользовательской таблицы маршрутизации в AKS и настройка исходящего трафика кластера с исходящими типами в AKS.
• Прямая адресация объектов pod не поддерживается из-за особенностей kubenet.
• В отличие от кластеров Azure CNI, несколько кластеров kubenet не могут совместно использовать подсеть.
• AKS не применяет группы безопасности сети (NSG) к своей подсети и не изменяет ни одну из групп безопасности сети, связанных с этой подсетью. Если вы предоставляете свою собственную подсеть и добавляете группы безопасности сети, связанные с этой подсетью, необходимо убедиться, что правила безопасности в группах безопасности сети разрешают трафик между узлом и CIDR pod. Дополнительные сведения см. в разделе Группы безопасности сети.
• Функции , не поддерживаемые в kubenet , включают:
  • Сетевые политики Azure
  • пулы узлов Windows;
  • надстройка виртуальных узлов.

Примечание.

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

Доступность и исчерпание IP-адресов

Распространенная проблема с Azure CNI заключается в том, что назначенный диапазон IP-адресов слишком мал, чтобы затем добавить дополнительные узлы при масштабировании или обновлении кластера. Группа сети также может не иметь возможности выдавать достаточно большой диапазон IP-адресов для поддержки ожидаемых требований приложения. В этом случае можно создать кластер AKS, в котором используется kubenet, и подключиться к существующей подсети виртуальной сети. Такой подход позволяет узлам получать определенные IP-адреса без необходимости резервировать большое количество IP-адресов перед любыми потенциальными модулями pod, которые могут выполняться в кластере.

С помощью kubenet можно использовать гораздо меньший диапазон IP-адресов и поддерживать большие кластеры и требования приложений. Например, с диапазоном IP-адресов /27 в подсети можно запустить кластер узлов 20-25 с достаточной емкостью для масштабирования или обновления. Этот размер кластера может поддерживать до 22 200–2750 модулей pod (по умолчанию — не более 110 модулей pod на узел). Максимальное количество модулей pod на узел, которое можно настроить с помощью kubenet в AKS, равно 250.

Приведенные ниже базовые расчеты показывают разницу между моделями сети.

• kubenet: простой диапазон IP-адресов /24 может поддерживать до 251 узлов в кластере. Каждая подсеть виртуальной сети Azure резервирует первые три IP-адреса для операций управления. Это число узлов может поддерживать до 27 610 модулей pod, при этом по умолчанию не более 110 модулей pod на узел.
• Azure CNI: тот же базовый диапазон подсети /24 может поддерживать только 8 узлов в кластере. Это число узлов может поддерживать только до 240 модулей pod, при этом по умолчанию не более 30 модулей pod на узел.

Примечание.

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

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

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

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

Часто задаваемые вопросы о подсети Pod Pod Azure CNI

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

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

• Какой исходный IP-адрес определят внешние системы для трафика, источником которого является pod с поддержкой 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.

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

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

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

  По умолчанию кластеры 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 для динамического выделения 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. См. статью Конфигурация сети в службе Azure Kubernetes (AKS).

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

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