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

Статья
06/24/2024

Область применения: AKS в Azure Stack HCI 22H2, AKS на Windows Server

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

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

Примечание.

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

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

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

Количество IP-адресов в пуле ВИРТУАЛЬНЫх IP-адресов зависит от количества кластеров рабочей нагрузки и служб Kubernetes, запланированных для развертывания.

В зависимости от сетевой модели определение пула ВИРТУАЛЬНЫх IP-адресов отличается следующим образом:

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

Пул 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-конфигурациями:

Внимание

Эта версия AKS не позволяет изменять конфигурацию сети после развертывания узла AKS или кластера рабочей нагрузки. Чтобы изменить параметры сети, необходимо начать заново, удалив кластеры рабочей нагрузки и удалив AKS.

Имя: имя виртуальной сети.
Префикс адреса: префикс IP-адреса, используемый для подсети.
Шлюз: IP-адрес шлюза по умолчанию для подсети.
DNS-сервер: массив IP-адресов, указывающий на DNS-серверы, которые будут использоваться для подсети. Можно предоставить не менее одного и не более трех серверов.
Пул виртуальных машин узлов Kubernetes: непрерывный диапазон IP-адресов, используемых для виртуальных машин узла Kubernetes.
Пул виртуальных IP-адресов: непрерывный диапазон IP-адресов, используемых для сервера API кластера Kubernetes и служб Kubernetes.

Примечание.

Пул ВИРТУАЛЬНЫх IP-адресов должен быть частью той же подсети, что и пул виртуальных машин Узлов Kubernetes.
Идентификатор виртуальной локальной сети: идентификатор виртуальной ЛС для виртуальной сети. Если он опущен, виртуальная сеть не помечена.

Виртуальная сеть с сетями DHCP

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

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

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

Примечание.

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

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

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

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

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

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

Примечание.

Выделение IP-адресов для службы MOC не зависит от модели виртуальной сети Kubernetes. Выделение IP-адресов зависит от базовой физической сети, а IP-адреса, настроенные для узлов кластера Azure Local или Windows Server в центре обработки данных.

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

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

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

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

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

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

Возможность	Статический IP-адрес	DHCP
Сервер API кластера Kubernetes	Назначается статически с помощью пула ВИРТУАЛЬНЫХ IP-адресов.	Назначается статически с помощью пула ВИРТУАЛЬНЫХ IP-адресов.
Узлы Kubernetes (на виртуальных машинах)	Назначен пул IP-адресов узлов Kubernetes.	Назначается динамически.
Службы Kubernetes	Назначается статически с помощью пула ВИРТУАЛЬНЫХ IP-адресов.	Назначается статически с помощью пула ВИРТУАЛЬНЫХ IP-адресов.
Виртуальная машина подсистемы балансировки нагрузки HAProxy	Назначен пул IP-адресов узлов Kubernetes.	Назначается динамически.
Локальная облачная служба Майкрософт	Зависит от конфигурации физической сети для узлов кластера Azure Local и Windows Server.	Зависит от конфигурации физической сети для узлов кластера Azure Local и Windows Server.
Пул ВИРТУАЛЬНЫХ IP-адресов	Обязательно	Обязательно
Пул IP-адресов виртуальных машин узла Kubernetes	Обязательно	Не поддерживается

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

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

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

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

Тип кластера	Узел плоскости управления	Рабочий узел	Для операций обновления	Подсистема балансировки нагрузки
Узел AKS	Один IP-адрес	Неприменимо	Два IP-адреса	Неприменимо
Кластер рабочей нагрузки	Один IP-адрес на узел	Один IP-адрес на узел	5 IP-адресов	Один IP-адрес

Кроме того, необходимо зарезервировать следующее число IP-адресов для пула ВИРТУАЛЬНЫх IP-адресов:

Тип ресурса	Число IP-адресов
Сервер API кластера	1 на кластер
Службы Kubernetes	1 на службу
Прикладные службы	1 на плановую службу

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

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

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

Кластер 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) из области DHCP 32 IP-адресов для своего пула ВИРТУАЛЬНЫх IP-адресов.

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

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

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

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

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

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