Сетевая архитектура ДЛЯ AKS в Azure Stack HCI

Azure Stack

Windows Server

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

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

Архитектура

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

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

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

Azure Stack HCI (20H2) — это решение кластера гиперконвергентной инфраструктуры (HCI), в котором размещаются виртуализированные рабочие нагрузки Windows и Linux и их хранилище в гибридной локальной среде. Кластер Azure Stack HCI реализуется как кластер 2-4 узла.
Отказоустойчивый кластер центра обработки данных Windows Server 2019/2022 — это группа независимых компьютеров, которые совместно работают для повышения доступности и масштабируемости кластеризованных ролей.
Служба Azure Kubernetes в Azure Stack HCI (гибридная среда AKS) — это локальная реализация Служба 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 для облака][] — это единая система управления безопасностью инфраструктуры, которая укрепляет безопасность центров обработки данных и обеспечивает расширенную защиту от угроз в гибридных рабочих нагрузках в облаке и локальной среде.

Компоненты

[Azure Stack HCI (20H2)] [1]
[Отказоустойчивый кластер центра обработки данных Windows Server 2019/2022] []
[Служба Azure Kubernetes (AKS)][]
[Центр Администратор Windows][]
[Подписка Azure] []
[Azure Arc] [2]
[Управление доступом на основе ролей Azure (RBAC)] []
[Azure Monitor] [3]
[Microsoft Defender для облака][4]

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

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

Сеть узлов Kubernetes

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

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

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

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

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

Виртуальный пул IP-адресов — это набор IP-адресов, которые являются обязательными для любого развертывания AKS в Azure Stack HCI. Запланируйте количество 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 Stack HCI. Виртуальная машина KVA также размещает службу балансировки нагрузки виртуальных IP-адресов Kubernetes.
Планирование IP-адресов для количества виртуальных машин уровня управления, развернутых на целевых серверах, так как они также используют больше IP-адресов из виртуального пула IP-адресов. Рекомендации описаны в следующем разделе.
Целевой кластер содержит виртуальную машину подсистемы балансировки нагрузки, которая является HAProxy и владеет виртуальным пулом IP-адресов для целевого кластера. Эта виртуальная машина предоставляет все службы Kubernetes через виртуальный пул IP-адресов.
Приложения, выполняемые в модулях pod Kubernetes, используют IP-адреса из виртуального пула IP-адресов.
Подсистема балансировки нагрузки HAProxy развертывается как специализированная виртуальная машина и может использоваться для балансировки нагрузки входящих запросов между несколькими конечными точками. Они используют IP-адреса из виртуального пула IP-адресов, и необходимо запланировать IP-адресацию для каждого кластера рабочей нагрузки.

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

Узлы Kubernetes развертываются как виртуальные машины в развертывании AKS в Azure Stack HCI. Убедитесь, что вы планируете количество 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 Stack HCI управляли в облаке. Выделение IP-адресов для службы MOC находится в базовой физической сети, а IP-адреса, настроенные для узлов кластера Azure Stack HCI, находятся в центре обработки данных. Вы можете настроить IP-адреса для физических узлов Azure Stack HCI в одном из следующих элементов:

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

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

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

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

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

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

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

Сети Kubernetes

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

[Сеть Project Calico] []. Это сетевая модель по умолчанию для AKS в Azure Stack HCI и основана на сети с открытым исходным кодом, которая обеспечивает сетевую безопасность для контейнеров, виртуальных машин и собственных рабочих нагрузок на основе узлов. Политика сети 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 Stack HCI

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

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

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

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

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

Требования к сети узла для Azure Stack HCI

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[службы домен Active Directory]: /windows-server/identity/ad-ds/get-started/virtual-dc/домен Active Directory Services-overview [Management cluster]: /azure/aks/hybrid/kubernetes-concepts#the-management-cluster [Кластер рабочей нагрузки]: /azure/aks/hybrid/kubernetes-concepts#the-workload-cluster [Azure Arc]: /azure/azure-arc/overview [ Политика Azure]: /azure/management/policy/overview [Azure Monitor]: /azure/azure-monitor/overview [Microsoft Defender для облака]: /azure/defender-for-cloud/defender-for-cloud-introduction [1] https://azure.microsoft.com/products/azure-stack/hci/ : [Windows Server 2019/2022 datacenter failover cluster]: /windows-server/failover-кластеризация/failover- кластеризация-overview [Служба Azure Kubernetes (AKS)]: [Windows Администратор Center]: https://azure.microsoft.com/services/kubernetes-service/ /windows-server/manage/windows-admin-center/overview [Подписка Azure]: https://azure.microsoft.com [2]: https://azure.microsoft.com/services/azure-arc/ [Управление доступом на основе ролей (RBAC)]: /azure/role-based-access-control/ [3]: [4]: https://azure.microsoft.com/services/monitor/https://azure.microsoft.com/services/defender-for-cloud/ [контроллер ingress]: /azure/aks/hybrid/create-ingress-controller [Project Calico network]: [Flannel overlay network.]: [Dynamic Virtual Machine Multi-Queue] https://techcommunity.microsoft.com/t5/networking-blog/synthetic-accelerations-in-a-nutshell-windows-server-2019/ba-p/653976 : [Network ATC]: https://projectcalico.docs.tigera.io/security/calico-network-policy https://techcommunity.microsoft.com/t5/networking-blog/introducing-kubernetes-overlay-networking-for-windows/ba-p/363082 /azure-stack/hci/concepts/network-atc-overview [служба Kubernetes с поддержкой Azure Arc]: /azure/azure-arc/kubernetes/ [Microsoft Azure Well-Architected Framework]: /azure/architecture/framework [калькулятор цен Azure]: https://azure.microsoft.com/pricing/calculator [оптимизация затрат]: /azure/architecture/framework/cost/overview [Microsoft Azure Well-Architected Framework.]: /azure/architecture/framework/ [управление кластером Kubernetes с помощью GitOps]: /azure/azure-arc/kubernetes/use-gitop подключенный кластер [гибридное управление и развертывание Azure Arc для кластеров Kubernetes]: /azure/architecture/hybrid/arc-hybrid-kubernetes [использование Azure RBAC для авторизации Kubernetes]: /azure/aks/manage-azure-rbac

Базовая архитектура AKS в Azure Stack HCI

Share via

Сетевая архитектура ДЛЯ AKS в Azure Stack HCI

Архитектура

Компоненты

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

Сеть узлов Kubernetes

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

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

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

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

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

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

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

Сети Kubernetes

Проектирование сети Azure Stack HCI

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

Требования к сети узла для Azure Stack HCI

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

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

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

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

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

модели трафика служба хранилища

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

Надежность

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

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

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

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

Соавторы

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

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

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

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

Share via

Сетевая архитектура ДЛЯ AKS в Azure Stack HCI

Архитектура

Компоненты

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

Сеть узлов Kubernetes

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

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

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

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

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

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

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

Сети Kubernetes

Проектирование сети Azure Stack HCI

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

Требования к сети узла для Azure Stack HCI

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

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

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

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

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

модели трафика служба хранилища

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

Надежность

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

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

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

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

Соавторы

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

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

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

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

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