Поделиться через


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

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

При создании кластера 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 из следующих статей: