Сетевые понятия для развертывания узлов AKS

Область применения: AKS на Windows Server

Вы можете выбрать две модели назначения IP-адресов для архитектуры сети для AKS в Windows Server. AKS поддерживает несколько вариантов развертывания для службы Azure Kubernetes (AKS):

• Статические IP-сети: виртуальная сеть выделяет статические IP-адреса серверу API кластера Kubernetes, узлам Kubernetes, базовым виртуальным машинам, подсистемам балансировки нагрузки и любым службам Kubernetes, работающим поверх кластера.
• Сеть DHCP: виртуальная сеть выделяет динамические IP-адреса узлам Kubernetes, базовым виртуальным машинам и подсистемам балансировки нагрузки с помощью DHCP-сервера. Сервер API кластера Kubernetes и все службы Kubernetes, выполняемые на вершине кластера, по-прежнему выделяются статическими IP-адресами.

Виртуальный пул IP-адресов

Пул виртуальных IP-адресов (VIP) — это набор IP-адресов, которые являются обязательными для любого развертывания в AKS Arc. Пул ВИРТУАЛЬНЫх IP-адресов — это диапазон зарезервированных IP-адресов, используемых для выделения IP-адресов серверу API кластера Kubernetes. Это гарантирует, что приложения в службах Kubernetes всегда доступны. Помните, что независимо от выбранной модели виртуальной сети и модели назначения адресов, вам необходимо предоставить пул виртуальных IP-адресов для развертывания AKS-кластера.

Количество IP-адресов в пуле виртуальных IP-адресов (VIP) зависит от количества кластеров для приложений и служб Kubernetes, запланированных для развертывания.

В зависимости от вашей сетевой модели, определение пула VIP отличается следующим образом:

• Статический IP-адрес: если вы используете статический IP-адрес, убедитесь, что виртуальные IP-адреса находятся в той же подсети.
• DHCP: если сеть настроена с ПОМОЩЬЮ DHCP, обратитесь к администратору сети, чтобы исключить диапазон IP-адресов пула ВИРТУАЛЬНЫх IP-адресов из области DHCP, используемой для развертывания AKS.

Пул IP-адресов виртуальных машин узла Kubernetes

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

• Статический IP-адрес: необходимо указать диапазон пула IP-адресов виртуальной машины узла Kubernetes. Количество IP-адресов в этом диапазоне зависит от общего количества узлов Kubernetes, которые вы планируете использовать для развертывания в кластерах AKS и кластерах с рабочими нагрузками Kubernetes. Помните, что обновления используют один до трех дополнительных IP-адресов во время обновления.
• DHCP: вам не нужно указывать пул виртуальных машин Kubernetes, так как IP-адреса узлам Kubernetes динамически выделяются DHCP-сервером в сети.

Виртуальная сеть со статическими IP-сетями (рекомендуется)

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

Укажите следующие параметры при определении виртуальной сети со статическими IP-конфигурациями:

• Имя: имя виртуальной сети.

• Префикс адреса: префикс IP-адреса, используемый для подсети.

• Шлюз: IP-адрес шлюза по умолчанию для подсети.

• DNS-сервер: массив IP-адресов, указывающий на DNS-серверы, которые будут использоваться для подсети. Можно предоставить не менее одного и не более трех серверов.

• Пул виртуальных машин узлов Kubernetes: непрерывный диапазон IP-адресов, используемых для виртуальных машин узла Kubernetes.

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

  Примечание.

  Пул виртуальных IP-адресов должен быть частью той же подсети, что и пул виртуальных машин узлов Kubernetes.

• Идентификатор виртуальной локальной сети: идентификатор виртуальной ЛС для виртуальной сети. Если это опущено, виртуальная сеть не будет помечена.

Виртуальная сеть с DHCP-сетевым подключением

Эта сетевая модель создает виртуальную сеть, которая выделяет IP-адреса с помощью DHCP для всех объектов в развертывании.

При определении виртуальной сети со статическими IP-конфигурациями необходимо указать следующие параметры:

• Имя: имя виртуальной сети.

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

  Примечание.

  Адреса пула VIP должны находиться в той же подсети, что и область DHCP, и их необходимо исключить из области DHCP для предотвращения конфликтов адресов.

• Идентификатор виртуальной локальной сети: идентификатор виртуальной ЛС для виртуальной сети. Если не указано, виртуальная сеть не помечена.

Локальная облачная служба Майкрософт

Microsoft On-Premises Cloud (MOC) — это стек управления, который позволяет управлять виртуальными машинами SDDC на базе Windows Server в облаке. MOC состоит из следующих элементов:

• Один экземпляр высокодоступной cloud agent службы, развернутой в кластере. Этот агент выполняется на любом узле в кластере Windows Server и настроен на переключение на другой узел в случае отказа.
• Выполняется node agent на каждом физическом узле.

Чтобы установить связь с MOC, необходимо указать CIDR IP-адреса, который будет использоваться для сервиса. Это -cloudserviceCIDR параметр в Set-AksHciConfig команде, которая используется для назначения IP-адреса облачной службе агента и обеспечения высокой доступности облачной службы агента.

Выбор IP-адреса для службы MOC зависит от базовой сетевой модели, используемой развертыванием кластера на Windows Server.

• Узлы кластера Windows Server с режимом выделения IP-адресов на основе DHCP: если IP-адреса для узлов кластера назначаются с DHCP-сервера, присутствующего в физической сети, вам не нужно вручную указывать IP-адрес для службы MOC, так как служба MOC также получает IP-адрес от DHCP-сервера.

• Узлы кластера Windows Server со статической моделью выделения IP-адресов. Если узлы кластера назначены статическим IP-адресам, необходимо явно указать IP-адрес облачной службы MOC. IP-адрес службы MOC должен находиться в той же подсети, что и IP-адреса узлов кластера Windows Server. Чтобы явно назначить IP-адрес для службы MOC, используйте -cloudserviceCIDR параметр в команде Set-AksHciConfig . Убедитесь, что введите IP-адрес в формате CIDR, например: 10.11.23.45/16

Сравнение сетевых моделей

DHCP и статический IP-адрес обеспечивают сетевое подключение к AKS в развертывании Windows Server. Каждая из этих моделей имеет свои преимущества и недостатки. На высоком уровне следует учитывать следующие соображения.

DHCP — не гарантирует длительное время существования IP-адресов для некоторых типов ресурсов в развертывании AKS. — поддерживает расширение зарезервированных IP-адресов DHCP, если развертывание становится больше, чем вы изначально ожидали.

Статический IP-адрес — гарантирует долговременные IP-адреса для всех ресурсов в развертывании AKS. — Так как автоматическое расширение пула IP-адресов узлов Kubernetes не поддерживается, возможно, вы не сможете создавать новые кластеры, если вы исчерпали IP-пул узлов Kubernetes.

В следующей таблице сравнивается распределение IP-адресов для ресурсов между статическими ip-адресами и моделями сети DHCP:

Минимальные резервирования IP-адресов для развертывания AKS

Независимо от модели развертывания количество зарезервированных IP-адресов остается неизменным. В этом разделе описывается количество IP-адресов, которые необходимо зарезервировать на основе модели развертывания AKS Arc.

Минимальное резервирование IP-адресов

Как минимум, необходимо зарезервировать следующее число IP-адресов для развертывания:

Кроме того, необходимо зарезервировать следующее число IP-адресов для пула VIP-адресов.

Как видно, количество необходимых IP-адресов является переменной в зависимости от архитектуры развертывания AKS и количества служб, выполняемых в кластере Kubernetes. Рекомендуется резервировать не менее 256 IP-адресов (/24 подсети) для развертывания.

Пошаговое руководство по примеру развертывания

Джейн — это ИТ-администратор, начинающийся с AKS на Windows Server. Она хочет развернуть два кластера Kubernetes: кластер Kubernetes A и кластер Kubernetes B в своем кластере Windows Server. Она также хочет запустить приложение для голосования на вершине своего кластера. Это приложение содержит три экземпляра интерфейсного пользовательского интерфейса, работающего в двух кластерах и одном экземпляре серверной базы данных.

• Кластер Kubernetes A имеет 3 узла уровня управления и 5 рабочих узлов.
• Кластер Kubernetes B имеет 1 узел уровня управления и 3 рабочих узла.
• 3 экземпляра пользовательского интерфейса (порт 443).
• 1 экземпляр серверной базы данных (порт 80).

На основе предыдущей таблицы она должна зарезервировать:

• 3 IP-адреса узла AKS (один IP-адрес для узла плоскости управления и два IP-адреса для выполнения операций обновления).
• 3 IP-адреса для узлов уровня управления в кластере A (один IP-адрес на узел плоскости управления).
• 5 IP-адресов для рабочих узлов в кластере A (один IP-адрес на рабочий узел).
• 6 IP-адресов дополнительно для кластера A (пять IP-адресов для выполнения операций обновления и 1 IP-адреса для подсистемы балансировки нагрузки).
• 1 IP-адреса для узлов уровня управления в кластере B (один IP-адрес на узел плоскости управления).
• 3 IP-адреса рабочих узлов в кластере B (один IP-адрес на рабочий узел).
• 6 IP-адресов дополнительно для кластера B (пять IP-адресов для выполнения операций обновления и 1 IP-адреса для подсистемы балансировки нагрузки).
• 2 IP-адреса для серверов API кластера Kubernetes (один IP-адрес для кластера Kubernetes).
• 3 IP-адреса для службы Kubernetes (один IP-адрес для каждого экземпляра внешнего пользовательского интерфейса, так как все они используют один и тот же порт. Серверная база данных может использовать любой из трех IP-адресов, если он будет использовать другой порт).

Как упоминалось ранее, Джейн требует 32 IP-адресов для развертывания кластера. Поэтому Джейн должна зарезервировать подсеть /26 для своей виртуальной сети.

Разделение зарезервированных IP-адресов на основе статической сетевой модели IP-адресов

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

• Пул IP-адресов виртуальных машин узла Kubernetes: для виртуальных машин узла Kubernetes и виртуальной машины подсистемы балансировки нагрузки. Этот пул IP-адресов также включает IP-адрес, необходимый для выполнения операций обновления.
• Виртуальный пул IP-адресов: для сервера API Kubernetes и служб Kubernetes.

В этом примере Джейн должна дополнительно разделить эти IP-адреса между пулами ВИРТУАЛЬНЫх IP-адресов и пулами IP-адресов узлов Kubernetes:

• 5 (два для сервера API кластера Kubernetes и три для служб Kubernetes) из 32 IP-адресов для её пула виртуальных IP-адресов.
• 27 (все IP-адреса для ее узлов Kubernetes и базовых виртуальных машин, виртуальных машин балансировщика нагрузки и операций обновления) в пуле IP-адресов узлов Kubernetes.

Разделение зарезервированных IP-адресов на основе модели сети DHCP

Хотя общее количество зарезервированных IP-адресов остается неизменным, модель развертывания определяет, как эти IP-адреса разделяются между группами IP-адресов. Как описано в предыдущем разделе, сетевая модель DHCP имеет одну область IP-адресов:

• Виртуальный пул IP-адресов: для сервера API Kubernetes и служб Kubernetes

Работа с предыдущим примером:

• Джейн должна зарезервировать 32 IP-адреса или подсеть /26 на своем DHCP-сервере.
• Она должна исключить 5 адресов (два для сервера API кластера Kubernetes и три для служб Kubernetes) из пула 32 IP-адресов DHCP для своего пула VIP.

Контроллеры входящего трафика

Во время развертывания целевого кластера создается ресурс балансировщика нагрузки на основе HAProxy. Балансировщик нагрузки настроен на распределение трафика между подами в вашей службе на заданном порте. Подсистема балансировки нагрузки работает только на уровне 4, что означает, что служба не знает о фактическом приложении; т. е. это не может сделать никаких дополнительных рекомендаций по маршрутизации.

Контроллеры входящего трафика работают на уровне 7 и могут использовать более интеллектуальные правила для распределения трафика приложения. Частое использование контроллера входящего трафика — маршрутизация ТРАФИКА HTTP в разные приложения на основе входящего URL-адреса.

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

В этой статье рассматриваются некоторые понятия сети для развертывания узлов AKS на Windows Server. Дополнительные сведения см. в следующих статьях:

• Основные понятия сети контейнеров
• Кластеры и рабочие нагрузки
• Развертывание кластера рабочей нагрузки Kubernetes