Сетевая архитектура для AKS в локальной среде Azure

Windows Server

В этом сценарии показано, как разрабатывать и реализовывать сетевые концепции для развертывания узлов Служба Azure Kubernetes (AKS) в кластерах AKS.

В этой статье содержатся рекомендации по проектированию сетей для узлов Kubernetes и контейнеров Kubernetes. Это часть набора рекомендаций по архитектуре двух статей. Ознакомьтесь с рекомендациями по базовой архитектуре.

Внимание

Сведения в этой статье относятся к AKS в Azure Stack HCI, версии 22H2 и AKS-HCI в Windows Server. Последняя версия AKS выполняется в ОС Azure Stack HCI версии 23H2. Дополнительные сведения о последней версии см. в AKS в ОС Azure Stack HCI версии 23H2.

Архитектура

На следующем рисунке показана сетевая архитектура для службы Azure Kubernetes в локальных кластерах центра обработки данных Azure или Windows Server 2019/2022:

Скачайте файл Visio для этой архитектуры.

Сценарий состоит из следующих компонентов и возможностей:

Azure Stack HCI версии 22H2— это решение кластера гиперконвергентной инфраструктуры (HCI), в котором размещаются виртуализированные рабочие нагрузки Windows и Linux и их хранилище в гибридной локальной среде. Локальный экземпляр Azure реализуется как кластер узлов 2-4.
Отказоустойчивый кластер центра обработки данных Windows Server 2019/2022 — это группа независимых компьютеров, которые совместно работают для повышения доступности и масштабируемости кластеризованных ролей.
Служба Azure Kubernetes в локальном Azure — это локальная реализация службы Azure Kubernetes (AKS), которая автоматизирует выполнение контейнерных приложений в масштабе.
домен Active Directory Службы — это иерархическая структура, которая хранит сведения об объектах в сети. Он предоставляет решение для удостоверений и доступа для удостоверений, связанных с пользователями, компьютерами, приложениями или другими ресурсами, включенными в границу безопасности.
Кластер управления, известный также как узел AKS, отвечает за развертывание нескольких кластеров рабочей нагрузки и управление ими. Кластер управления использует 1 IP-адрес из пула узлов, но необходимо зарезервировать еще 2 IP-адреса для операций обновления. Кластер управления также использует один IP-адрес из пула ВИРТУАЛЬНЫх IP-адресов.
Кластер рабочей нагрузки — это высокодоступное развертывание Kubernetes с помощью виртуальных машин Linux для запуска компонентов плоскости управления Kubernetes и рабочих узлов Linux и (или) рабочих узлов Windows.
- Плоскость управления. Выполняется в дистрибутиве Linux и содержит компоненты сервера API для взаимодействия с API Kubernetes и распределенного хранилища значений ключей и т. д. для хранения всех конфигураций и данных кластера. Он использует один IP-адрес из пула узлов и один IP-адрес из пула ВИРТУАЛЬНЫх IP-адресов.
- Подсистема балансировки нагрузки. Выполняется на виртуальной машине Linux и предоставляет службы с балансировкой нагрузки для кластера рабочей нагрузки. Он использует один IP-адрес из пула узлов и один IP-адрес из пула ВИРТУАЛЬНЫх IP-адресов.
- Рабочие узлы. Запустите операционную систему Windows или Linux, включающую контейнерные приложения. Он использует IP-адреса из пула узлов, но следует запланировать не менее 3 IP-адресов для операций обновления.
- Ресурсы Kubernetes. Модули Pod представляют один экземпляр приложения, который обычно сопоставляет 1:1 с контейнером, но некоторые модули pod могут содержать несколько контейнеров. Развертывания представляют один или несколько идентичных модулей pod. Модули pod и развертывания логически группируются в пространство имен, которое управляет доступом к управлению ресурсами. Они используют 1 IP-адрес для каждого модуля pod из пула ВИРТУАЛЬНЫх IP-адресов.
Azure Arc — это облачная служба, которая расширяет модель управления на основе Azure Resource Manager до ресурсов, отличных от Azure, включая виртуальные машины, кластеры Kubernetes и контейнерные базы данных.
Политика Azure — это облачная служба, которая оценивает Azure и локальные ресурсы через интеграцию с Azure Arc, сравнивая свойства с настраиваемыми бизнес-правилами.
Azure Monitor — это облачная служба, которая обеспечивает максимальную доступность и производительность приложений и служб, предоставляя комплексное решение для сбора, анализа и работы с телеметрией из облачных и локальных сред.
Microsoft Defender для облака — это единая система управления безопасностью инфраструктуры, которая повышает уровень безопасности центров обработки данных и обеспечивает расширенную защиту от угроз в гибридных рабочих нагрузках в облаке и локальной среде.

Компоненты

Подробности сценария

Варианты использования этого сценария описаны в первой статье серии , базовой архитектуре.

Сеть узлов Kubernetes

Основное внимание в проектировании сети для AKS на локальной платформе Azure является выбор сетевой модели, которая предоставляет достаточно IP-адресов. AKS в Azure Local использует виртуальные сети для выделения IP-адресов ресурсам узла Kubernetes. Можно использовать две модели назначения IP-адресов:

Статические IP-сети являются более предсказуемыми, но добавляют дополнительные усилия для начальной конфигурации.
Сеть динамического протокола конфигурации узла (DHCP) использует динамическое выделение IP-адресов и меньше усилий, но необходимо быть осторожным, чтобы не исчерпать доступный пул IP-адресов. Кроме того, необходимо управлять резервированиями и диапазонами исключений для пулов виртуальных IP-адресов и определенных ресурсов кластера, таких как служба агента облака.

Обе модели назначений должны планировать IP-адреса для:

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

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

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

Для облачного агента требуется плавающий IP-адрес из виртуального пула IP-адресов.
Компонент сервера API, работающий внутри виртуальной машины Kubernetes (KVA), использует IP-адрес из виртуального пула IP-адресов. Сервер API является компонентом плоскости управления Kubernetes, которая предоставляет API Kubernetes. Сервер API — это интерфейс для плоскости управления Kubernetes. KVA — это виртуальная машина под управлением Mariner Linux и размещает кластер Kubernetes. IP-адрес плавает и также используется для любой другой виртуальной машины KVA, развернутой в AKS в локальной среде Azure. Виртуальная машина KVA также размещает службу балансировки нагрузки виртуальных IP-адресов Kubernetes.
Планирование IP-адресов для количества виртуальных машин уровня управления, развернутых на целевых серверах, так как они также используют больше IP-адресов из виртуального пула IP-адресов. Рекомендации описаны в следующем разделе.
Целевой кластер содержит виртуальную машину подсистемы балансировки нагрузки, которая является HAProxy и владеет виртуальным пулом IP-адресов для целевого кластера. Эта виртуальная машина предоставляет все службы Kubernetes через виртуальный пул IP-адресов.
Приложения, выполняемые в модулях pod Kubernetes, используют IP-адреса из виртуального пула IP-адресов.
Подсистема балансировки нагрузки HAProxy развертывается как специализированная виртуальная машина и может использоваться для балансировки нагрузки входящих запросов между несколькими конечными точками. Они используют IP-адреса из виртуального пула IP-адресов, и необходимо запланировать IP-адресацию для каждого кластера рабочей нагрузки.

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

Узлы Kubernetes развертываются как виртуальные машины в akS в локальном развертывании Azure. Убедитесь, что вы планируете количество IP-адресов в соответствии с общим количеством узлов Kubernetes и включает по крайней мере три дополнительных IP-адреса, которые используются во время процесса обновления. Для конфигурации статических IP-адресов необходимо указать диапазон IP-пула IP-адресов узла Kubernetes. Это не требуется для выделения DHCP. Планирование дополнительных IP-адресов для:

Виртуальная машина KVA также использует дополнительные IP-адреса для Kubernetes из пула IP-адресов виртуальных машин Узла Kubernetes. Запланируйте добавление IP-адресов во время обновления, так как виртуальная машина KVA использует тот же виртуальный IP-адрес для службы API, но требует отдельного IP-адреса из пула IP-адресов узлов Kubernetes.
Виртуальные машины уровня управления используют один IP-адрес из пула IP-адресов виртуальных машин узла Kubernetes для службы сервера API. Эти виртуальные машины также размещают агент Azure ARC, который подключается к портал Azure для целей управления.
Узлы в пуле узлов (Linux или Windows) будут использовать IP-адреса из пула IP-адресов, выделенных для виртуальной машины узла Kubernetes.

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

Планирование диапазона IP-адресов для локального облака Майкрософт (MOC), который включает стек управления, чтобы виртуальные машины в локальной среде Azure управляли в облаке. Выделение IP-адресов для службы MOC находится в базовой физической сети, а IP-адреса, настроенные для узлов локального кластера Azure, находятся в центре обработки данных. Вы можете настроить IP-адреса для физических узлов локального центра Azure в одном из следующих вариантов:

Узлы локального кластера Azure с режимом выделения IP-адресов на основе DHCP. Служба MOC получает IP-адрес из службы DHCP, представленной в физической сети.
Узлы локального кластера Azure с моделью выделения статических IP-адресов. IP-адрес облачной службы MOC должен быть явно указан в виде диапазона IP-адресов в формате безклассового Inter-Domain маршрутизации (CIDR), и он должен находиться в той же подсети, что и IP-адреса узлов локального кластера Azure.

Подсистема балансировки нагрузки в AKS в локальной среде Azure

Для небольшого развертывания можно использовать встроенную подсистему балансировки нагрузки, развернутую как виртуальную машину Linux, которая использует HAProxy + KeepAlive для отправки трафика в службы приложений, развернутые в составе кластера AKS. Подсистема балансировки нагрузки HAProxy настраивает pod в качестве конечных точек в подсистеме балансировки нагрузки. Он загружает запросы балансировать запросы к серверу API Kubernetes и управляет трафиком в службы приложений.

Вы также можете использовать пользовательский подсистему балансировки нагрузки для управления трафиком в службы. Настраиваемая подсистема балансировки нагрузки обеспечивает дополнительную гибкость в развертывании и гарантирует, что AKS в локальной среде Azure работает вместе с существующими развертываниями, такими как развертывания SDN, использующие подсистемы балансировки нагрузки. Для пользовательских подсистем балансировки нагрузки kube-virtual IP предоставляет кластеры Kubernetes с виртуальным IP-адресом и подсистемой балансировки нагрузки для уровня управления и служб Kubernetes типа LoadBalancer. Служба IP-адресов kube-virtual развертывается автоматически на каждом рабочем узле.

AKS в Локальной среде Azure также поддерживает использование подсистем балансировки нагрузки на основе MetalLB или других подсистем балансировки нагрузки OSS Kubernetes для балансировки трафика, предназначенного для служб в кластере рабочей нагрузки. MetalLB — это реализация подсистемы балансировки нагрузки для кластеров Kubernetes без операционной системы, используя стандартные протоколы маршрутизации, такие как протокол BGP пограничного шлюза. Он может работать с сетевыми надстройками, Calico и Flannel, но необходимо убедиться, что диапазон виртуальных IP-адресов, предоставленный во время установки AKS на локальном компьютере Azure, не перекрывается с диапазоном IP-адресов, запланированным для пользовательской подсистемы балансировки нагрузки.

Развертывание этого сценария

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

Рассмотрите возможность реализации контроллера входящего трафика для завершения TLS, обратимого прокси-сервера или настраиваемой маршрутизации трафика. Контроллеры входящего трафика работают на уровне 7 и могут использовать интеллектуальные правила для распределения трафика приложения. Ресурсы входящего трафика Kubernetes используются при настройке правил входящего трафика и маршрутов для отдельных служб Kubernetes. При определении контроллера входящего трафика вы объединяете правила маршрутизации трафика в один ресурс, который выполняется в составе кластера.

Используйте контроллер входящего трафика для предоставления служб через внешние URL-адреса. Входящий трафик предоставляет маршруты HTTP и HTTPS извне кластера службам в кластере. Маршрутизация трафика управляется правилами, определенными в ресурсе входящего трафика. Правила входящего трафика HTTP содержат следующие сведения:

Необязательный узел. Если вы не предоставляете сведения о узле, правило применяется ко всему входящего HTTP-трафика.
Список путей, имеющих связанную серверную часть с service.name и номеромservice.port.name или service.port.number.
Серверная часть, которая предоставляет сочетание имен служб и портов.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: hello-world
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
    kubernetes.io/ingress.class: "nginx"
spec:
  rules:
  - host: test.example.com
     http:
       paths:
       - path: /hello-world
          pathType: Prefix
          backend:
            service:
              name: hello-world
              port:
                 number: 8080

Используйте контроллер входящего трафика для балансировки трафика между разными внутренними серверами приложения. Трафик разделяется и отправляется в разные конечные точки службы и развертывания на основе сведений о пути.

Чтобы маршрутизировать HTTP-трафик к нескольким именам узлов в одном IP-адресе, можно использовать другой ресурс входящего трафика для каждого узла. Трафик, поступающий через IP-адрес подсистемы балансировки нагрузки, направляется на основе имени узла и пути, предоставленного в правиле входящего трафика.

Основные понятия сети контейнеров в службе Azure Kubernetes (AKS) в локальной среде Azure

Kubernetes предоставляет уровень абстракции виртуальной сети, поэтому приложения на основе контейнеров могут взаимодействовать внутри или вне сети. Компонент kube-proxy выполняется на каждом узле и может предоставлять прямой доступ к службе, распределять трафик с помощью балансов нагрузки или использовать контроллеры входящего трафика для более сложной маршрутизации приложений. Kubernetes использует службы для логической группировки набора модулей pod и обеспечения сетевого подключения. Доступны следующие службы Kubernetes:

IP-адрес кластера: эта служба создает внутренний IP-адрес для внутренних приложений.
NodePort: эта служба создает сопоставление портов на базовом узле, что делает приложение доступным непосредственно с IP-адресом узла и портом.
LoadBalancer. Вы можете предоставлять службы Kubernetes внешним образом с помощью правил балансировки нагрузки или контроллера входящего трафика.
ExternalName:. Эта служба использует определенную запись DNS для приложения Kubernetes.

Сети Kubernetes

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

Сеть Project Calico. Это сетевая модель по умолчанию для AKS в Локальной среде Azure и основана на сети с открытым исходным кодом, которая обеспечивает сетевую безопасность для контейнеров, виртуальных машин и собственных рабочих нагрузок на основе узлов. Политика сети Calico может применяться к любой конечной точке, например модулям pod, контейнерам, виртуальным машинам или интерфейсам узла. Каждая политика состоит из правил, которые управляют входящего трафика и исходящего трафика с помощью действий, которые могут разрешать, запрещать, регистрировать или передавать трафик между исходными и конечными точками назначения. Calico может использовать расширенный фильтр пакетов Berkeley (eBPF) или сетевой конвейер ядра Linux для доставки трафика. Calico также поддерживается в Windows с помощью службы сети узлов (HNS) для создания сетевых пространств имен на конечную точку контейнера. В сетевой модели Kubernetes каждый модуль pod получает собственный IP-адрес, общий доступ между контейнерами в этом модуле. Модули pod взаимодействуют в сети с помощью IP-адресов pod, а изоляция определяется с помощью политик сети. Calico использует подключаемые модули CNI (Container Network Interface) для добавления или удаления модулей pod в сеть pod Kubernetes и подключаемых модулей CNI IPAM (управление IP-адресами) для выделения и освобождения IP-адресов.
Наложение сети фланнелла. Flannel создает слой виртуальной сети, который накладывает сеть узла. Наложение сети использует инкапсуляцию сетевых пакетов по существующей физической сети. Flannel упрощает управление IP-адресами (IPAM), поддерживает повторное использование IP-адресов между различными приложениями и пространствами имен и обеспечивает логическое разделение сетей контейнеров от подложной сети, используемой узлами Kubernetes. Сетевая изоляция достигается с помощью виртуальной сети локальной области eXtensible (VXLAN), протокола инкапсуляции, который обеспечивает подключение центра обработки данных с помощью туннелирования для растяжения подключений уровня 2 по базовой сети уровня 3. Flannel поддерживается контейнерами Linux с помощью DaemonSet и контейнеров Windows с помощью подключаемого модуля CNI Flannel.

Проектирование локальных сетей Azure

Общая структура сети включает в себя действия по планированию для локальной среды Azure.

Сначала начните с планирования оборудования и установки Azure Local. Вы можете приобрести интегрированные системы от партнера по оборудованию Майкрософт с предварительно установленной ОС Azure Stack HCI или приобрести проверенные узлы и установить операционную систему самостоятельно. Локальный сервер Azure предназначен для узла виртуализации, поэтому роли сервера Kubernetes должны выполняться на виртуальных машинах.

Требования к физической сети для локальной сети Azure

Корпорация Майкрософт не сертифицирует сетевые коммутаторы, но имеет определенные требования, необходимые поставщику оборудования:

Стандарт: IEEE 802.1Q, определяющий виртуальную локальную сеть (VLAN).
Стандарт: IEEE 802.1Qbb, определяющий управление потоками приоритета (PFC).
Стандарт: IEEE 802.1Qaz, определяющий расширенный выбор передачи (ETS).
Стандарт: IEEE 802.1AB, определяющий протокол обнаружения топологии уровня связи (LLTD).

Требования к сети узла для локальной среды Azure

Рассмотрите возможность использования сетевого адаптера, который достиг сертификации Windows Server Software Defined Data Center (SDDC) с дополнительным квалификацией уровня "Стандартный" или "Премиум" (AQ).

Убедитесь, что сетевой адаптер поддерживает следующее:

Динамическая виртуальная машина с несколькими очередями (Dynamic VMMQ или d.VMMQ) — это интеллектуальная технология получения для автоматической настройки сетевого трафика в ядра ЦП.
Удаленный прямой доступ к памяти (RDMA) — это разгрузка сетевого стека на сетевой адаптер. Это позволяет трафику хранилища SMB обойти операционную систему для обработки.
Гостевая RDMA позволяет рабочим нагрузкам SMB для виртуальных машин получить те же преимущества использования RDMA на узлах.
Switch Embedded Teaming (SET) — это технология совместной работы на основе программного обеспечения.

Рассмотрите возможность использования Сетевого ATC, который обеспечивает управление на основе намерений для упрощения конфигурации сети узла.

AKS на локальном компьютере Azure требует надежного подключения к сети с высокой пропускной способностью, низкой задержкой между каждым узлом сервера. Убедитесь, что доступен по крайней мере один сетевой адаптер и выделен для управления кластерами. Также убедитесь, что физические коммутаторы в сети настроены для разрешения трафика на любых виртуальных локальных сетях, которые вы будете использовать.

Виртуальный коммутатор

Локальная служба Azure упрощает проектирование сети, настраивая виртуальный коммутатор, который можно использовать для классификации сети. Карточка интерфейса виртуальной сети (vNIC) может быть размещена в разных виртуальных сетях для узлов, чтобы обеспечить другой поток трафика для следующих сетей:

Сеть управления. Сеть управления является частью сети северного юга и используется для обмена данными между узлами.
Вычислительная сеть. Вычислительная сеть является частью сети "север-юг" и используется для трафика виртуальных машин. Используйте качество обслуживания (QOS), виртуализацию одно корневых операций ввода-вывода (SR-IOV) и виртуальный удаленный прямой доступ к памяти (vRDMA) для настройки производительности сети по требованию.
Сеть хранилища. Сеть хранения является частью восточно-западной сети и требует RDMA с рекомендуемой пропускной способностью 10 ГБ+. Он используется для динамической миграции виртуальных машин.
Гостевая сеть виртуальной машины.

Преимущество трафика RDMA на Востоке

Сетевой трафик "Восток-Запад" представляет связь между узлами, и он не предоставляет внешний доступ. Трафик остается в верхней части переключателя (ToR) и границы уровня 2. Он включает следующие типы трафика:

Пульс кластера и взаимодействие между узлами
[SMB] Уровень шины хранилища
[SMB] Общий том кластера
[SMB] Перестроение хранилища

Северо-южный трафик

North-South трафик — это внешний трафик, который достигает AKS в локальном экземпляре Azure. Вы можете спланировать трафик для диапазона служб Azure, которые обеспечивают мониторинг, выставление счетов и управление безопасностью с помощью интеграции Azure ARC. Северо-южный трафик имеет следующие характеристики:

Трафик выходит из переключателя ToR к позвоночнику или от позвоночника к переключателю ToR.
Трафик покидает физическую стойку или пересекает границу уровня 3 (IP).
Трафик включает управление (PowerShell, Windows Admin Center), вычислительные ресурсы (виртуальная машина) и трафик растянутого кластера между сайтами.
Использует коммутатор Ethernet для подключения к физической сети.

AKS в локальной среде Azure может использовать несколько вариантов развертывания сети кластера:

Конвергентная сеть, объединяющая несколько намерений сети (MGMT, вычисления, хранилище). Это рекомендуемое развертывание для более чем трех физических узлов и требует подключения всех физических сетевых адаптеров к тем же коммутаторам ToR. ROCEv2 настоятельно рекомендуется.
Развертывание без переключения использует связь North-South в качестве сетевой группы путем объединения вычислительных сетей и сетей управления.
Гибридное развертывание как сочетание обоих развертываний.

Лиза ДенБесте | Диспетчер программ управления проектами
Кенни Сложнее | Диспетчер проектов
Майк Костерсиц | Руководитель основного диспетчера программ
Мег Олсен | Основной
Нейт Уотерс | Менеджер по маркетингу продуктов

Другие участники:

Уолтер Оливер | Старший менеджер по программам

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

Общие сведения о службе AKS

Базовая архитектура ДЛЯ AKS в локальном Azure

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

Сетевая архитектура для AKS в локальной среде Azure

Архитектура

Компоненты

Подробности сценария

Сеть узлов Kubernetes

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

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

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

Подсистема балансировки нагрузки в AKS в локальной среде Azure

Развертывание этого сценария

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

Основные понятия сети контейнеров в службе Azure Kubernetes (AKS) в локальной среде Azure

Сети Kubernetes

Проектирование локальных сетей Azure

Требования к физической сети для локальной сети Azure

Требования к сети узла для локальной среды Azure

Виртуальный коммутатор

Преимущество трафика RDMA на Востоке

Северо-южный трафик

Рекомендации

Рекомендации по сети

Модели трафика хранилища

Рекомендации

Надежность

Безопасность

Оптимизация затрат

Эффективность работы

Оптимизация производительности

Соавторы

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

Обратная связь

Дополнительные ресурсы

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

Сетевая архитектура для AKS в локальной среде Azure

Архитектура

Компоненты

Подробности сценария

Сеть узлов Kubernetes

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

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

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

Подсистема балансировки нагрузки в AKS в локальной среде Azure

Развертывание этого сценария

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

Основные понятия сети контейнеров в службе Azure Kubernetes (AKS) в локальной среде Azure

Сети Kubernetes

Проектирование локальных сетей Azure

Требования к физической сети для локальной сети Azure

Требования к сети узла для локальной среды Azure

Виртуальный коммутатор

Преимущество трафика RDMA на Востоке

Северо-южный трафик

Рекомендации

Рекомендации по сети

Модели трафика хранилища

Рекомендации

Надежность

Безопасность

Оптимизация затрат

Эффективность работы

Оптимизация производительности

Соавторы

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

Связанные ресурсы

Обратная связь

Дополнительные ресурсы