Требования к системе для AKS, включенные Azure Arc в Azure Stack HCI 22H2
Применимо к: Azure Stack HCI версии 22H2; Windows Server 2022, Windows Server 2019
В этой статье описаны требования к настройке Служба Azure Kubernetes (AKS), включенной Azure Arc. Общие сведения об AKS, включенном Arc, см. в обзоре AKS.
Требования к аппаратному обеспечению
Корпорация Майкрософт рекомендует приобрести проверенное аппаратное или программное решение Azure Stack HCI от наших партнеров. Эти решения разработаны, собраны и проверены для запуска эталонной архитектуры и проверки совместимости и надежности, чтобы быстро работать. Убедитесь, что используются системы, компоненты, устройства и драйверы Windows Server сертифицированы в каталоге Windows Server. Ознакомьтесь с веб-сайтом решений Azure Stack HCI для проверенных решений.
Внимание
Хост-системы для рабочих развертываний должны быть физическим оборудованием. Вложенная виртуализация, охарактеризуемая как развертывание Azure Stack HCI или Windows Server на виртуальной машине и установка AKS в этой виртуальной машине, не поддерживается.
Максимальные поддерживаемые спецификации оборудования
AkS в Azure Stack HCI и развертываниях Windows Server, превышающие следующие спецификации, не поддерживаются:
Ресурс | Максимум |
---|---|
Физические серверы на кластер | 8 (Azure Stack HCI версии 22H2 и Windows Server) |
Общее количество виртуальных машин | 200 |
Требования к вычислениям
Минимальные требования к памяти
Кластер AKS можно настроить следующим образом, чтобы запустить AKS на одном узле Windows Server с ограниченным объемом ОЗУ:
Тип кластера | Размер виртуальной машины уровня управления | Рабочий узел | Для операций обновления | Подсистема балансировки нагрузки |
---|---|---|---|---|
Узел AKS | размер виртуальной машины Standard_A4_v2 = 8 ГБ | N/A — узел AKS не имеет рабочих узлов. | 8 ГБ | Узел N/A — AKS использует kubevip для балансировки нагрузки. |
Кластер рабочей нагрузки | размер виртуальной машины Standard_A4_v2 = 8 ГБ | Standard_K8S3_v1 для 1 рабочего узла = 6 ГБ | Можно повторно использовать этот зарезервированный 8 ГБ для обновления кластера рабочей нагрузки. | N/A, если kubevip используется для балансировки нагрузки (вместо подсистемы балансировки нагрузки HAProxy по умолчанию). |
Общее минимальное требование: 30 ГБ ОЗУ.
Это минимальное требование для развертывания AKS с одним рабочим узлом для запуска контейнерных приложений. Если вы решили добавить рабочие узлы или подсистему балансировки нагрузки HAProxy, окончательный оЗУ изменится соответствующим образом.
Рекомендуемые требования к вычислительным ресурсам
Среда | Ядра ЦП на сервер | ОЗУ |
---|---|---|
Azure Stack HCI | 32 | 256 ГБ |
Отказоустойчивый кластер Windows Server | 32 | 256 ГБ |
Один узел Windows Server | 16 | 128 ГБ |
Для рабочей среды окончательный размер зависит от приложения и количества рабочих узлов, которые планируется развернуть в кластере Azure Stack HCI или Windows Server. Если вы решили запустить AKS на одном узле Windows Server, вы не получаете такие функции, как высокий уровень доступности, которые работают с AKS в кластере Azure Stack HCI или кластере Windows Server или отказоустойчивом кластере Windows Server.
Другие требования к вычислительным ресурсам AKS в Azure Stack HCI и Windows Server соответствуют требованиям Azure Stack HCI. Дополнительные сведения о требованиях к серверу Azure Stack HCI см. в статье о требованиях к серверу Azure Stack HCI.
Необходимо установить одну и ту же операционную систему на каждом сервере в кластере. Если вы используете Azure Stack HCI, на каждом сервере в кластере должна быть одна и та же версия ос и версия. Если вы используете Центр обработки данных Windows Server, то на каждом сервере в кластере должна быть одна и та же версия ос и версия. Каждая ОС должна использовать регион en-us и выбор языка. Эти параметры нельзя изменить после установки.
Требования к системе хранения данных
AKS в Azure Stack HCI и Windows Server поддерживают следующие реализации хранилища:
Имя. | Тип хранилища | Требуемая емкость |
---|---|---|
Кластер Azure Stack HCI | Общие тома кластера | 1 TБ |
Отказоустойчивый кластер Центра обработки данных Windows Server | Общие тома кластера | 1 TБ |
Центр обработки данных Windows Server с одним узлом | Система хранения с прямым подключением | 500 ГБ |
Для кластера Azure Stack HCI или Windows Server поддерживаются две поддерживаемые конфигурации хранилища для выполнения рабочих нагрузок виртуальных машин:
- Гибридное хранилище балансирует производительность и емкость с помощью флэш-хранилища и жестких дисков (HDD).
- Хранилище all-flash обеспечивает максимальную производительность с помощью твердотельных накопителей (SSD) или NVMe.
Системы, имеющие только хранилище на основе HDD, не поддерживаются Azure Stack HCI, поэтому не рекомендуется запускать AKS в Azure Stack HCI и Windows Server. Дополнительные сведения о рекомендуемых конфигурациях дисков см. в документации по Azure Stack HCI. Все системы, проверенные в каталоге Azure Stack HCI, попадают в одну из этих двух поддерживаемых конфигураций хранилища.
Kubernetes использует etcd для хранения состояния кластеров. Etcd хранит конфигурацию, спецификации и состояние запущенных модулей pod. Кроме того, Kubernetes использует хранилище для обнаружения служб. В качестве координирующего компонента для работы Kubernetes и поддерживаемых рабочих нагрузок, задержка и пропускная способность и т. д. являются критически важными. Необходимо запустить AKS на SSD. Дополнительные сведения см. в разделе "Производительность " на etcd.io.
Для кластера windows Server Datacenter можно развернуть с локальным хранилищем или хранилищем на основе SAN. Для локального хранилища рекомендуется использовать встроенное Локальные дисковые пространства или эквивалентное сертифицированное виртуальное решение SAN для создания гиперконвергентной инфраструктуры, которая представляет общие тома кластера для использования рабочими нагрузками. Для Локальные дисковые пространства необходимо, чтобы ваше хранилище было гибридным (flash+ HDD), которое балансирует производительность и емкость, или все флэш-памяти (SSD, NVMe), что повышает производительность. Если вы решили развернуть хранилище на основе SAN, убедитесь, что хранилище SAN может обеспечить достаточную производительность для выполнения нескольких рабочих нагрузок виртуальных машин. Более старое хранилище SAN на основе HDD может не обеспечить необходимые уровни производительности для выполнения нескольких рабочих нагрузок виртуальных машин, и могут возникнуть проблемы с производительностью и время ожидания.
Для развертываний Windows Server с одним узлом с помощью локального хранилища настоятельно рекомендуется использовать все флэш-хранилище (SSD, NVMe), чтобы обеспечить необходимую производительность для размещения нескольких виртуальных машин на одном физическом узле. Без хранилища флэш-памяти более низкий уровень производительности hdD может вызвать проблемы с развертыванием и время ожидания.
Требования к сети
Следующие требования применяются к кластеру Azure Stack HCI 22H2 и кластеру Центра обработки данных Windows Server. Требования к сети в Azure Stack HCI 23H2 см. в разделе "Требования к сети".
- Для Azure Stack HCI 22H2 и Windows Server убедитесь, что у вас есть существующий внешний виртуальный коммутатор, настроенный, если вы используете Windows Admin Center. Для кластеров HCI или Windows Server этот параметр и его имя должны совпадать во всех узлах кластера. Для HCI 23H2 см. требования к системе сети.
- Убедитесь, что IPv6 отключен для всех сетевых адаптеров.
- Для успешного развертывания узлы кластера Azure Stack HCI или Windows Server и виртуальные машины кластера Kubernetes должны иметь внешнее подключение к Интернету.
- Убедитесь, что все подсети, определенные для кластера, являются маршрутизируемыми между собой и в Интернете.
- Убедитесь, что между узлами Azure Stack HCI и виртуальными машинами клиента есть сетевое подключение.
- Разрешение DNS-имен требуется для всех узлов, чтобы иметь возможность взаимодействовать друг с другом.
- (Рекомендуется) Включите динамические обновления DNS в среде DNS, чтобы разрешить AKS регистрировать универсальное имя кластера облачного агента в системе DNS для обнаружения.
Назначение IP-адресов
В AKS с поддержкой Arc виртуальные сети используются для выделения IP-адресов ресурсам Kubernetes, которые требуют их, как описано ранее. В зависимости от требуемой архитектуры сети AKS можно выбрать две сетевые модели.
Примечание.
Архитектура виртуальной сети, определенная здесь для развертываний AKS, отличается от базовой архитектуры физической сети в центре обработки данных.
- Статические IP-сети: виртуальная сеть выделяет статические IP-адреса серверу API кластера Kubernetes, узлам Kubernetes, базовым виртуальным машинам, подсистемам балансировки нагрузки и любым службам Kubernetes, которые вы запускаете на вершине кластера.
- Сеть DHCP: виртуальная сеть выделяет динамические IP-адреса узлам Kubernetes, базовым виртуальным машинам и подсистемам балансировки нагрузки с помощью DHCP-сервера. Сервер API кластера Kubernetes и все службы Kubernetes, которые вы запускаете поверх кластера, по-прежнему выделяют статические IP-адреса.
Минимальное резервирование IP-адресов
Как минимум, необходимо зарезервировать следующее число IP-адресов для развертывания:
Тип кластера | Узел плоскости управления | Рабочий узел | Для операций обновления | Подсистема балансировки нагрузки |
---|---|---|---|---|
Узел AKS | 1 IP-адрес | Неприменимо | 2 IP | Неприменимо |
Кластер рабочей нагрузки | 1 IP-адрес на узел | 1 IP-адрес на узел | 5 IP-адресов | 1 IP-адрес |
Кроме того, необходимо зарезервировать следующее число IP-адресов для пула ВИРТУАЛЬНЫх IP-адресов:
Тип ресурса | Число IP-адресов |
---|---|
Сервер API кластера | 1 на кластер |
Службы Kubernetes | 1 на службу |
Как видно, количество необходимых IP-адресов является переменной в зависимости от архитектуры AKS и количества служб, выполняемых в кластере Kubernetes. Рекомендуется резервировать 256 IP-адресов (/24 подсети) для развертывания.
Дополнительные сведения о требованиях к сети см. в концепциях сетевых сетей узлов в AKS и контейнерах в AKS.
Требования к сетевому порту и URL-адресу
AKS, включенные требованиями Arc
При создании кластера Kubernetes в Azure Stack HCI следующие порты брандмауэра автоматически открываются на каждом сервере в кластере.
Если узлы физического кластера Azure Stack HCI и виртуальные машины кластера Azure Kubernetes находятся на двух изолированных виртуальных сетях, эти порты должны быть открыты в брандмауэре между ними:
Порт | Оригинал | Description | Заметки брандмауэра |
---|---|---|---|
22 | Виртуальные машины AKS | Требуется для сбора журналов при использовании Get-AksHciLogs . |
При использовании отдельных виртуальных СЕТЕЙ физические узлы Hyper-V должны получить доступ к виртуальным машинам AKS на этом порту. |
6443 | Виртуальные машины AKS | Требуется для взаимодействия с API Kubernetes. | При использовании отдельных виртуальных СЕТЕЙ физические узлы Hyper-V должны получить доступ к виртуальным машинам AKS на этом порту. |
45 000 | Физические узлы Hyper-V | сервер wssdAgent gRPC. | Правила кросс-виртуальной локальной сети не требуются. |
45001 | Физические узлы Hyper-V | проверка подлинности wssdAgent gRPC. | Правила кросс-виртуальной локальной сети не требуются. |
46000 | Виртуальные машины AKS | wssdCloudAgent в lbagent. | При использовании отдельных виртуальных СЕТЕЙ физические узлы Hyper-V должны получить доступ к виртуальным машинам AKS на этом порту. |
55000 | Ресурс кластера (-CloudServiceCIDR) | Сервер gRPC облачного агента. | При использовании отдельных виртуальных ЛС виртуальные машины AKS должны получить доступ к IP-адресу ресурса кластера на этом порту. |
65000 | Ресурс кластера (-CloudServiceCIDR) | Проверка подлинности gRPC облачного агента. | При использовании отдельных виртуальных ЛС виртуальные машины AKS должны получить доступ к IP-адресу ресурса кластера на этом порту. |
Если для подключения к Интернету требуется использовать прокси-сервер, см. раздел "Использование параметров прокси-сервера" в AKS.
В список разрешений необходимо добавить следующие URL-адреса:
URL | Порт | Примечания. |
---|---|---|
msk8s.api.cdp.microsoft.com | 443 | Используется при скачивании AKS в каталоге локальных продуктов Azure, битах продуктов и образах ОС из SFS. Происходит при запуске Set-AksHciConfig и в любое время загрузки из SFS. |
msk8s.b.tlu.dl.delivery.mp.microsoft.com msk8s.f.tlu.dl.delivery.mp.microsoft.com |
80 | Используется при скачивании AKS в каталоге локальных продуктов Azure, битах продуктов и образах ОС из SFS. Происходит при запуске Set-AksHciConfig и в любое время загрузки из SFS. |
login.microsoftonline.com login.windows.net management.azure.com msft.sts.microsoft.com graph.windows.net |
443 | Используется для входа в Azure при запуске Set-AksHciRegistration . |
ecpacr.azurecr.io mcr.microsoft.com *.mcr.microsoft.com *.data.mcr.microsoft.com *.blob.core.windows.net конечная точка США: wus2replica*.blob.core.windows.net |
443 | Требуется для извлечения образов контейнеров при запуске Install-AksHci . |
<region.dp.kubernetesconfiguration.azure.com> | 443 | Требуется для подключения гибридных кластеров AKS к Azure Arc. |
gbl.his.arc.azure.com | 443 | Требуется для получения региональной конечной точки, позволяющей запрашивать назначенные системой сертификаты управляемых удостоверений. |
*.his.arc.azure.com | 443 | Требуется для получения сертификатов управляемого удостоверения, назначаемого системой. |
k8connecthelm.azureedge.net | 443 | Kubernetes с поддержкой Arc использует Helm 3 для развертывания агентов Azure Arc в akS в локальном кластере управления Azure. Эта конечная точка необходима для скачивания клиента Helm для упрощения развертывания диаграммы helm агента. |
*.arc.azure.net | 443 | Требуется для управления гибридными кластерами AKS в портал Azure. |
dl.k8s.io | 443 | Требуется для скачивания и обновления двоичных файлов Kubernetes для Azure Arc. |
akshci.azurefd.net | 443 | Требуется для AKS в локальном выставлении счетов Azure при запуске Install-AksHci . |
v20.events.data.microsoft.com gcs.prod.monitoring.core.windows.net |
443 | Используется периодически для отправки необходимых диагностических данных майкрософт из узла Azure Local или Windows Server. |
Примечание.
AKS, включенные в Arc, хранят и обрабатывают данные клиента. По умолчанию данные клиента остаются в пределах региона, в котором клиент развертывает экземпляр службы. Эти данные хранятся в региональных центрах обработки данных, управляемых корпорацией Майкрософт. Для регионов с требованиями к месту расположения данных данные клиента всегда хранятся в одном регионе.
Дополнительные требования к URL-адресу для функций Azure Arc
Предыдущий список URL-адресов охватывает минимальные необходимые URL-адреса для подключения службы AKS к Azure для выставления счетов. Необходимо разрешить дополнительные URL-адреса, если вы хотите использовать подключение к кластеру, пользовательские расположения, Azure RBAC и другие службы Azure, такие как Azure Monitor и т. д., в кластере рабочей нагрузки AKS. Полный список URL-адресов Arc см. в статье о требованиях к сети Kubernetes с поддержкой Azure Arc.
Вы также должны просмотреть URL-адреса Azure Stack HCI. Так как Arc для агентов сервера теперь устанавливается по умолчанию на узлах Azure Stack HCI из Azure Stack HCI 21H2 и более поздних версий, необходимо также просмотреть Arc для URL-адресов агентов сервера.
Растянутые кластеры в AKS
Как описано в обзоре растянутых кластеров, развертывание AKS в Azure Stack HCI и Windows Server с помощью растянутых кластеров Windows не поддерживается. Мы рекомендуем использовать подход резервного копирования и аварийного восстановления для непрерывности работы центра обработки данных. Дополнительные сведения см. в статье "Выполнение резервного копирования или восстановления кластера рабочей нагрузки с помощью Velero и хранилища BLOB-объектов Azure в Azure Stack HCI и Windows Server" и "Развертывание конфигураций в AksHci с помощью GitOps с Flux версии 2 для обеспечения непрерывности приложений".
Требования к Windows Admin Center
Windows Admin Center — это пользовательский интерфейс для создания и управления AKS, включенных Azure Arc. Чтобы использовать Windows Admin Center с AKS в Azure Stack HCI и Windows Server, необходимо выполнить все условия в следующем списке.
Это требования для компьютера под управлением шлюза Windows Admin Center:
- Windows 10 или Windows Server.
- Зарегистрировано в Azure.
- В том же домене, что и кластер Azure Stack HCI или Windows Server Datacenter.
- Подписка Azure, в которой у вас есть права владельца. Вы можете проверить уровень доступа, перейдя к подписке и выбрав элемент управления доступом (IAM) в левой части портал Azure, а затем выбрав "Просмотреть мой доступ".
Требования Azure
Необходимо подключиться к учетной записи Azure.
Учетная запись Azure и подписка
Если у вас еще нет учетной записи Azure, создайте ее. Вы можете использовать существующую подписку любого типа:
- Бесплатная учетная запись с кредитами Azure для учащихся или подписчиков Visual Studio.
- Подписка с оплатой по мере использования с помощью кредитной карты.
- Подписка, полученная через Соглашение Enterprise (EA).
- Подписка, полученная с помощью программы поставщик облачных решений (CSP).
Разрешения Microsoft Entra, роль и уровень доступа
Необходимо иметь достаточные разрешения для регистрации приложения в клиенте Microsoft Entra.
Чтобы проверить наличие достаточных разрешений, следуйте приведенным ниже сведениям:
- Перейдите к портал Azure и выберите роли и администраторы в разделе идентификатора Microsoft Entra, чтобы проверить свою роль.
- Если ваша роль — пользователь, необходимо убедиться, что пользователи, не являющиеся администраторами, могут регистрировать приложения.
- Чтобы проверить, можно ли зарегистрировать приложения, перейдите к параметрам пользователей в службе Microsoft Entra, чтобы проверить, есть ли у вас разрешение на регистрацию приложения.
Если для параметра регистрации приложений задано значение No, только пользователи с ролью администратора могут зарегистрировать эти типы приложений. Дополнительные сведения о доступных ролях администратора и конкретных разрешениях в идентификаторе Microsoft Entra, предоставленных каждой роли, см. в статье о встроенных ролях Microsoft Entra. Если вашей учетной записи назначена роль пользователя , но параметр регистрации приложения ограничен пользователями администратора, попросите администратора назначить вам одну из ролей администратора, которые могут создавать и управлять всеми аспектами регистрации приложений или разрешать пользователям регистрировать приложения.
Если у вас недостаточно разрешений для регистрации приложения, а администратор не может предоставить вам эти разрешения, проще всего развернуть AKS, чтобы попросить администратора Azure создать субъект-службу с правильными разрешениями. Администраторы могут проверить следующий раздел, чтобы узнать, как создать субъект-службу.
Роль подписки Azure и уровень доступа
Чтобы проверить уровень доступа, перейдите к подписке, выберите элемент управления доступом (IAM) в левой части портал Azure, а затем выберите "Просмотреть мой доступ".
- Если вы используете Windows Admin Center для развертывания узла AKS или кластера рабочей нагрузки AKS, у вас должна быть подписка Azure, в которой вы являетесь владельцем.
- Если вы используете PowerShell для развертывания узла AKS или кластера рабочей нагрузки AKS, пользователь, регистрирующий кластер, должен иметь по крайней мере одно из следующих элементов:
- Учетная запись пользователя со встроенной ролью владельца .
- Субъект-служба с одним из следующих уровней доступа:
- Встроенная роль участника .
- Встроенная роль владельца .
Если ваша подписка Azure выполняется через EA или CSP, проще всего развернуть AKS с просьбой администратора Azure создать субъект-службу с правильными разрешениями. Администраторы могут проверить следующий раздел о том, как создать субъект-службу.
Необязательно. Создание субъекта-службы
Выполните следующие действия, чтобы создать субъект-службу со встроенной ролью владельца . Только владельцы подписок могут создавать субъекты-службы с правильным назначением ролей. Вы можете проверить уровень доступа, перейдя к подписке, выбрав управление доступом (IAM) в левой части портал Azure, а затем выберите "Просмотреть мой доступ".
Задайте следующие переменные PowerShell в окне администрирования PowerShell. Убедитесь, что подписка и клиент являются тем, что вы хотите использовать для регистрации узла AKS для выставления счетов:
$subscriptionID = "<Your Azure subscrption ID>"
$tenantID = "<Your Azure tenant ID>"
Установите и импортируйте модуль PowerShell AKS:
Install-Module -Name AksHci
Войдите в Azure с помощью команды Connect-AzAccount PowerShell:
Connect-AzAccount -tenant $tenantID
Задайте подписку, которую вы хотите использовать для регистрации узла AKS для выставления счетов в качестве подписки по умолчанию, выполнив команду Set-AzContext :
Set-AzContext -Subscription $subscriptionID
Убедитесь, что контекст входа исправен, выполнив команду Get-AzContext PowerShell. Убедитесь, что подписка, клиент и учетная запись используются для регистрации узла AKS для выставления счетов:
Get-AzContext
Name Account SubscriptionName Environment TenantId
---- ------- ---------------- ----------- --------
myAzureSubscription (92391anf-... user@contoso.com myAzureSubscription AzureCloud xxxxxx-xxxx-xxxx-xxxxxx
Создайте субъект-службу, выполнив команду New-AzADServicePrincipal PowerShell. Эта команда создает субъект-службу с ролью владельца и задает область на уровне подписки. Дополнительные сведения о создании субъектов-служб см. в статье о создании субъекта-службы Azure с помощью Azure PowerShell.
$sp = New-AzADServicePrincipal -role "Owner" -scope /subscriptions/$subscriptionID
Получите пароль для субъекта-службы, выполнив следующую команду. Обратите внимание, что эта команда работает только для Az.Accounts 2.6.0 или ниже. Мы автоматически скачиваем модуль Az.Accounts 2.6.0 при установке модуля PowerShell AksHci:
$secret = $sp.PasswordCredentials[0].SecretText
Write-Host "Application ID: $($sp.ApplicationId)"
Write-Host "App Secret: $secret"
В предыдущих выходных данных теперь у вас есть идентификатор приложения и секрет, доступный при развертывании AKS. Вы должны заметить эти элементы и безопасно хранить их. При этом в портал Azure в разделе "Подписки" контроль доступа и назначения ролей вы увидите новый субъект-службу.
Группа ресурсов Azure
Перед регистрацией необходимо иметь группу ресурсов Azure в Восточной Австралии, восточной части США, Юго-Восточной Азии или регионе Azure Западной Европы.
Регионы Azure
Предупреждение
AKS Arc в настоящее время поддерживает создание кластера исключительно в указанных ниже регионах Azure. Если вы пытаетесь развернуть в регионе за пределами этого списка, происходит сбой развертывания.
Служба AKS Arc используется для регистрации, выставления счетов и управления. В настоящее время она поддерживается в следующих регионах:
- Восточная часть США
- Центрально-южная часть США
- Западная Европа
Требования к Active Directory
Для отказоустойчивого кластера AKS с 2 или более физическими узлами для оптимальной работы в среде Active Directory убедитесь, что выполнены следующие требования:
Примечание.
Active Directory не требуется для развертываний Azure Stack HCI или Windows Server.
- Настройте синхронизацию времени, чтобы расхождение не превышало 2 минуты во всех узлах кластера и контроллере домена. Сведения о настройке синхронизации времени см . в службе времени Windows.
- Убедитесь, что учетные записи пользователей, используемые для добавления обновления, а также управление кластерами AKS или Windows Server Datacenter имеют правильные разрешения в Active Directory. Если вы используете подразделения для управления групповыми политиками для серверов и служб, учетные записи пользователей требуют списка, чтения, изменения и удаления разрешений для всех объектов в подразделении.
- Используйте отдельную подразделение организации (OU) для серверов и служб кластерами AKS или Windows Server Datacenter. Использование отдельного подразделения позволяет управлять доступом и разрешениями с более детальной степенью детализации.
- Если вы используете шаблоны групповой политики в контейнерах в Active Directory, убедитесь, что развертывание AKS в Azure Stack HCI и Windows Server исключается из политики.
Следующие шаги
Выполнив все указанные выше предварительные требования, вы можете настроить узел AKS в Azure Stack HCI: