Обзор сетевых возможностей Azure CNI в Службе Kubernetes Azure (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-адресов или необходимости повторно создавать кластеры в подсети большего размера по мере увеличения потребностей вашего приложения.

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

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

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

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

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

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

Плагин сети Azure: Если используется плагин сети Azure, внутренняя служба LoadBalancer с "externalTrafficPolicy=Local" не может быть доступна для виртуальных машин с IP-адресом в clusterCIDR, не принадлежащем кластеру 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. Чтобы приступить к работе, ознакомьтесь со статьей Защита трафика между подами с помощью политик сети в AKS.

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

  Да, при развертывании кластера с помощью Azure CLI или шаблона Resource Manager. См. Максимальное количество подов на узел.

  Вы не можете изменить максимальное количество подов на узел в существующем кластере.

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

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

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

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

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

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

• Использование статического IP-адреса с балансировщиком нагрузки службы Azure Kubernetes (AKS)

• Использование внутреннего балансировщика нагрузки в Службе Kubernetes Azure (AKS)

• Использование надстройки маршрутизации приложений в службе Azure Kubernetes (AKS)