Требования к системе для Служба Azure Kubernetes в Azure Stack HCI и Windows Server
Область применения: Azure Stack HCI версий 22H2, 21H2 и 20H2; Windows Server 2022 Datacenter, Windows Server 2019 Datacenter
В этой статье рассматриваются требования к настройке Служба Azure Kubernetes в Azure Stack HCI или Windows Server Datacenter и ее использованию для создания кластеров Kubernetes. Общие сведения об AKS в Azure Stack HCI и Windows Server см. в статье Обзор AKS в Azure Stack HCI и Windows Server.
требования к Active Directory
Для оптимальной работы AKS в Azure Stack HCI и отказоустойчивом кластере Windows Server или Windows Server Datacenter с 2 или более физическими узлами в среде Active Directory убедитесь, что выполнены следующие требования:
Примечание
Active Directory не требуется для развертываний Azure Stack HCI или Windows Server с одним узлом.
Настройте синхронизацию времени, чтобы расхождение не превышало 2 минуты на всех узлах кластера и контроллере домена. Сведения о настройке синхронизации времени см. в разделе Служба времени Windows.
Убедитесь, что учетные записи пользователей, используемые для добавления обновления и управления AKS в Azure Stack HCI и кластерах Windows Server или Windows Server Datacenter, имеют правильные разрешения в Active Directory. Если вы используете подразделения для управления групповыми политиками для серверов и служб, учетным записям пользователей потребуются разрешения на перечисление, чтение, изменение и удаление для всех объектов в подразделении.
Используйте отдельное подразделение для серверов и служб AKS в Azure Stack HCI и кластерах Windows Server или Windows Server Datacenter. Использование отдельного подразделения позволяет управлять доступом и разрешениями с большей степенью детализации.
Если вы используете шаблоны объектов групповой политики в контейнерах в Active Directory, убедитесь, что развертывание AKS в Azure Stack HCI и Windows Server исключается из политики. Усиление защиты сервера будет доступно в следующем выпуске.
Требования к оборудованию
Корпорация Майкрософт рекомендует приобрести проверенное аппаратное или программное решение Azure Stack HCI у наших партнеров. Эти решения разрабатываются, собираются и проверяются для выполнения эталонной архитектуры, а также для проверка совместимости и надежности, что позволяет быстро приступить к работе. Следует проверка, что системы, компоненты, устройства и драйверы, которые вы используете, сертифицированы для Windows Server в каталоге Windows Server. Проверенные решения см. на веб-сайте решений Azure Stack HCI .
Важно!
Главными системами для рабочих развертываний должно быть физическое оборудование. Вложенная виртуализация не поддерживается за пределами использования в руководстве по оценке. Вложенная виртуализация характеризуется как развертывание Azure Stack HCI или Windows Server на виртуальной машине и установка гибридной среды AKS на этой виртуальной машине.
Максимальные поддерживаемые спецификации оборудования
Развертывания AKS в Azure Stack HCI и Windows Server, превышающие следующие спецификации, не поддерживаются:
Ресурс | Максимальная |
---|---|
Физические серверы на кластер | 8 |
Общее число виртуальных машин | 200 |
Требования к вычислительным ресурсам
Минимальные требования к памяти
Кластер AKS можно настроить следующим образом, чтобы запустить AKS на одном узле Windows Server с ограниченным объемом ОЗУ.
Тип кластера | Размер виртуальной машины уровня управления | Рабочий узел | Для операций обновления | Подсистема балансировки нагрузки |
---|---|---|---|---|
Узел AKS | Standard_A4_v2 размер виртуальной машины = 8 ГБ | NA — узел AKS не имеет рабочих узлов | 8GB | NA — узел AKS использует kubevip для балансировки нагрузки |
Кластер рабочей нагрузки | Standard_A4_v2 размер виртуальной машины = 8 ГБ | Standard_K8S3_v1 для 1 рабочего узла = 6 ГБ | Можно повторно использовать 8 ГБ, зарезервированные выше, для обновления кластера рабочей нагрузки | NA, если для балансировки нагрузки используется kubevip (вместо подсистемы балансировки нагрузки HAProxy по умолчанию) |
Общее минимальное требование | 30 ГБ ОЗУ |
Помните, что указанные выше минимальные требования — это развертывание AKS-HCI с 1 рабочим узлом для запуска контейнерных приложений. Если вы решили добавить рабочие узлы или подсистему балансировки нагрузки HAProxy, окончательное требование к ОЗУ изменится соответствующим образом.
Рекомендуемые требования к вычислительным ресурсам
Среда | Число ядер ЦП на сервер | ОЗУ |
---|---|---|
Кластер Azure Stack HCI или Windows Server | 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 Datacenter, то на каждом сервере в кластере должны быть одинаковые ос и версии. Каждая ОС должна использовать выбранные EN-US
регион и язык. Эти параметры нельзя изменить после установки.
Требования к системе хранения данных
Следующие реализации хранилища поддерживаются AKS в Azure Stack HCI и Windows Server:
Имя | Тип хранилища | Требуемая емкость |
---|---|---|
Кластер Azure Stack HCI | Общие тома кластера | 1 TБ |
Отказоустойчивый кластер Windows Server Datacenter | Общие тома кластера | 1 TБ |
Windows Server Datacenter с одним узлом | Хранилище с прямым подключением | 500 ГБ |
Для кластера Azure Stack HCI или Windows Server у вас есть две поддерживаемые конфигурации хранилища для выполнения рабочих нагрузок виртуальных машин.
- Гибридное хранилище распределяет производительность и емкость с помощью хранилища флэш-памяти и жестких дисков (HDD).
- Хранилище с флэш-памятью повышает производительность с помощью твердотельных накопителей (SSD) или NVMe.
Системы, которые имеют только хранилище на основе HDD, не поддерживаются Azure Stack HCI и поэтому не рекомендуются для запуска AKS в Azure Stack HCI и Windows Server. Дополнительные сведения о рекомендуемых конфигурациях дисков см. в документации по Azure Stack HCI. Все системы, проверенные в каталоге Azure Stack HCI , попадают в одну из двух поддерживаемых конфигураций хранилища, указанных выше.
Kuberentes использует etcd для хранения состояния кластеров. Etcd хранит конфигурацию, спецификации и состояние запущенных модулей pod. Кроме того, Kubernetes использует хранилище для обнаружения служб. В качестве координирующего компонента для работы Kubernetes и рабочих нагрузок, которые он поддерживает, задержка и пропускная способность etcd имеют решающее значение. AkS необходимо запустить на SSD. Дополнительные сведения см. в статье Производительность на etcd.io.
Для кластера на основе Windows Server Datacenter можно выполнить развертывание с локальным хранилищем или хранилищем на основе SAN. Для локального хранилища рекомендуется использовать встроенную Локальные дисковые пространства или эквивалентное сертифицированное виртуальное решение SAN для создания гиперконвергентной инфраструктуры, которая представляет общие тома кластера для использования рабочими нагрузками. Для Локальные дисковые пространства необходимо, чтобы ваше хранилище было гибридным (флэш-память + HDD), которое балансирует производительность и емкость, или все флэш-накопители (SSD, NVMe), которое обеспечивает максимальную производительность. Если вы решили выполнить развертывание с хранилищем на основе SAN, убедитесь, что хранилище SAN может обеспечить достаточную производительность для выполнения нескольких рабочих нагрузок виртуальных машин. Старое хранилище SAN на основе HDD может не обеспечивать необходимые уровни производительности для выполнения нескольких рабочих нагрузок виртуальных машин, и вы можете столкнуться с проблемами производительности и временем ожидания.
Для развертываний Windows Server с одним узлом с использованием локального хранилища настоятельно рекомендуется использовать хранилище с флэш-памятью (SSD, NVMe), чтобы обеспечить необходимую производительность для размещения нескольких виртуальных машин на одном физическом узле. Без хранилища флэш-памяти более низкие уровни производительности на жестких дисках могут привести к проблемам с развертыванием и истечению времени ожидания.
Требования к сети
К кластеру Azure Stack HCI и кластеру Windows Server Datacenter применяются следующие требования:
Убедитесь, что у вас есть существующий внешний виртуальный коммутатор, если вы используете Windows Admin Center. Для кластеров Azure Stack HCI или Windows Server этот параметр и его имя должны быть одинаковыми на всех узлах кластера.
Убедитесь, что протокол IPv6 отключен для всех сетевых адаптеров.
Для успешного развертывания узлы кластера Azure Stack HCI или Windows Server и виртуальные машины кластера Kubernetes должны иметь внешнее подключение к Интернету.
Убедитесь, что все подсети, определенные для кластера, маршрутизируются между собой и в Интернет.
Убедитесь, что между узлами Azure Stack HCI и виртуальными машинами клиента есть сетевое подключение.
Разрешение DNS-имен требуется для того, чтобы все узлы могли взаимодействовать друг с другом.
(Рекомендуется) Включите динамические обновления DNS в среде DNS, чтобы разрешить AKS в Azure Stack HCI и Windows Server зарегистрировать имя универсального кластера облачного агента в системе DNS для обнаружения.
Назначение IP-адресов
В AKS в Azure Stack HCI и Windows Server виртуальные сети используются для выделения IP-адресов ресурсам Kubernetes, которым они требуются, как указано выше. Существует две модели сети, в зависимости от требуемой архитектуры AKS в Azure Stack HCI и Windows Server.
Примечание
Архитектура виртуальных сетей, определенная здесь для развертываний AKS в Azure Stack HCI и Windows Server, отличается от базовой физической сетевой архитектуры в центре обработки данных.
Сеть статических 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 в Azure Stack HCI и Windows Server, а также количества служб, запущенных в кластере Kubernetes. Рекомендуется зарезервировать в общей сложности 256 IP-адресов (/24 подсеть) для развертывания.
Дополнительные сведения о требованиях к сети см. в статье Основные понятия сети узлов в AKS в Azure Stack HCI и Концепции сети Windows Server и контейнеров в AKS в Azure Stack HCI и Windows Server.
Требования к сетевым портам и URL-адресам
Требования к AKS в Azure Stack HCI и Windows Server
При создании кластера Azure Kubernetes в Azure Stack HCI на каждом сервере кластера автоматически открываются следующие порты брандмауэра.
Если узлы физического кластера Azure Stack HCI и виртуальные машины кластера Azure Kubernetes находятся на двух изолированных виртуальных локальных сетях, эти порты необходимо открыть в брандмауэре между ними.
Port | Источник | Описание | Примечания брандмауэра |
---|---|---|---|
22 | Виртуальные машины AKS | Требуется для сбора журналов при использовании Get-AksHciLogs | При использовании отдельных виртуальных ЛС физические узлы Hyper-V должны получить доступ к виртуальным машинам AKS на этом порту. |
6443 | Виртуальные машины AKS | Требуется для взаимодействия с API Kubernetes | При использовании отдельных виртуальных ЛС физические узлы Hyper-V должны получить доступ к виртуальным машинам AKS на этом порту. |
45000 | Физические узлы Hyper-V | wssdAgent gRPC Server | Правила между виртуальными локальными сетями не требуются. |
45001 | Физические узлы Hyper-V | Проверка подлинности wssdAgent gRPC | Правила между виртуальными локальными сетями не требуются. |
46000 | Виртуальные машины AKS | wssdCloudAgent в lbagent | При использовании отдельных виртуальных ЛС физические узлы Hyper-V должны получить доступ к виртуальным машинам AKS на этом порту. |
55 000 | Ресурс кластера (-CloudServiceCIDR) | Сервер gRPC облачного агента | При использовании отдельных виртуальных ЛС виртуальные машины AKS должны получить доступ к IP-адресу ресурса кластера на этом порту. |
65000 | Ресурс кластера (-CloudServiceCIDR) | Проверка подлинности gRPC облачного агента | При использовании отдельных виртуальных ЛС виртуальные машины AKS должны получить доступ к IP-адресу ресурса кластера на этом порту. |
Если для подключения к Интернету в сети требуется прокси-сервер, см. статью Использование параметров прокси-сервера в AKS в Azure Stack HCI и Windows Server.
Следующие URL-адреса необходимо добавить в список разрешений.
URL-адрес | Порт | Примечания |
---|---|---|
msk8s.api.cdp.microsoft.com | 443 | Используется при скачивании каталога продуктов AKS в Azure Stack HCI, битов продуктов и образов ОС из SFS. Возникает при запуске Set-AksHciConfig и при загрузке из SFS. |
msk8s.f.tlu.dl.delivery.mp.microsoft.com msk8s.b.tlu.dl.delivery.mp.microsoft.com | 80 | Используется при скачивании каталога продуктов AKS в Azure Stack HCI, битов продуктов и образов ОС из SFS. Возникает при запуске Set-AksHciConfig и при загрузке из SFS. |
login.microsoftonline.com login.windows.net management.azure.com graph.windows.net msft.sts.microsoft.com | 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-HCI. Эта конечная точка необходима для скачивания клиента Helm, чтобы упростить развертывание диаграммы helm агента. |
*.arc.azure.net | 443 | Требуется для управления гибридными кластерами AKS в портал Azure. |
dl.k8s.io | 443 | Требуется для скачивания и обновления двоичных файлов Kubernetes для Azure Arc. |
akshci.azurefd.net | 443 | Требуется для выставления счетов AKS в Azure Stack HCI при выполнении Install-AksHci . |
gcs.prod.monitoring.core.windows.net v20.events.data.microsoft.com | 443 | Используется периодически для отправки необходимых диагностических данных Майкрософт из узла Azure Stack HCI или Windows Server. |
Примечание
AKS в Azure Stack HCI и Windows Server хранит и обрабатывает данные клиентов. По умолчанию данные клиента остаются в регионе, в который клиент развертывает экземпляр службы. Эти данные хранятся в региональных центрах обработки данных, управляемых корпорацией Майкрософт. Для регионов с требованиями к месту расположения данных данные клиентов всегда хранятся в одном регионе.
Дополнительные требования к URL-адресу для функций Azure Arc
В приведенном выше списке URL-адресов рассматриваются минимальные URL-адреса, необходимые для подключения службы AKS в Службе Azure Stack HCI к 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 и более поздних версий, также следует ознакомиться с URL-адресами агентов сервера Arc.
Растянутые кластеры в AKS в Azure Stack HCI и AKS в Windows Server
Как описано в обзоре растянутых кластеров, развертывание 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 Stack HCI и Windows Server. Чтобы использовать 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)
Azure AD разрешения, роль и уровень доступа
Для регистрации приложения в клиенте Azure AD необходимо иметь достаточные разрешения.
Чтобы проверка, что у вас есть достаточные разрешения, следуйте приведенным ниже сведениям.
- Перейдите на портал Azure и выберите Роли и администраторы в разделе Azure Active Directory, чтобы проверка свою роль.
- Если ваша роль — Пользователь, необходимо убедиться, что пользователи, не являющиеся администраторами, могут регистрировать приложения.
- Чтобы проверка, можно ли зарегистрировать приложения, перейдите в раздел Параметры пользователей в службе Azure Active Directory, чтобы проверка, если у вас есть разрешение на регистрацию приложения.
Если для параметра регистрации приложений установлено значение Нет, регистрировать приложения такого типа могут только пользователи с ролью администратора. Сведения о доступных ролях администратора и конкретных разрешениях в Azure AD, которые предоставляются каждой роли, см. в статье Azure AD встроенных ролей. Если вашей учетной записи назначена роль пользователя , но параметр регистрации приложений ограничен пользователями-администраторами, попросите администратора назначить вам одну из ролей администратора, которые могут создавать и управлять всеми аспектами регистрации приложений, или разрешить пользователям регистрировать приложения.
Если у вас недостаточно разрешений для регистрации приложения и ваш администратор не может предоставить вам эти разрешения, самый простой способ развернуть AKS в Azure Stack HCI и Windows Server — попросить администратора Azure создать субъект-службу с соответствующими разрешениями. Администраторы могут проверка следующем разделе, чтобы узнать, как создать субъект-службу.
Роль и уровень доступа подписки Azure
Чтобы проверка уровень доступа, перейдите к своей подписке, выберите Управление доступом (IAM) в левой части портал Azure, а затем выберите Просмотреть мой доступ.
- Если вы используете Windows Admin Center для развертывания узла AKS или кластера рабочей нагрузки AKS, у вас должна быть подписка Azure, владельцем которой вы являетесь.
- Если вы используете PowerShell для развертывания узла AKS или кластера рабочей нагрузки AKS, пользователь, регистрирующий кластер, должен иметь по крайней мере один из следующих компонентов:
Если ваша подписка Azure осуществляется через EA или CSP, самый простой способ развернуть AKS в Azure Stack HCI и Windows Server — попросить администратора Azure создать субъект-службу с соответствующими разрешениями. Администраторы могут проверка приведенном ниже разделе о том, как создать субъект-службу.
Необязательно. Создание субъекта-службы
Выполните следующие действия, чтобы создать субъект-службу со встроенной ролью владелец . Только владельцы подписок могут создавать субъекты-службы с правильным назначением ролей. Вы можете проверка уровень доступа, перейдя к своей подписке, щелкнув Управление доступом (IAM) в левой части портал Azure а затем щелкнув Просмотреть мой доступ.
Задайте следующие переменные PowerShell в окне администрирования PowerShell. Убедитесь, что вы хотите использовать подписку и клиент для регистрации узла AKS для выставления счетов.
$subscriptionID = <Your Azure subscrption ID>
$tenantID = <Your Azure tenant ID>
Установите и импортируйте гибридный модуль PowerShell AKS:
Install-Module -Name AksHci
Войдите в Azure с помощью команды PowerShell Connect-AzAccount :
Connect-AzAccount -tenant $tenantID
Задайте подписку, которую вы хотите использовать для регистрации узла AKS для выставления счетов, в качестве подписки по умолчанию, выполнив команду Set-AzContext .
Set-AzContext -Subscription $subscriptionID
Убедитесь, что контекст входа правильный, выполнив команду PowerShell Get-AzContext . Убедитесь, что вы хотите использовать подписку, клиент и учетную запись для регистрации узла AKS для выставления счетов.
Get-AzContext
Name Account SubscriptionName Environment TenantId
---- ------- ---------------- ----------- --------
myAzureSubscription (92391anf-... user@contoso.com myAzureSubscription AzureCloud xxxxxx-xxxx-xxxx-xxxxxx
Создайте субъект-службу, выполнив команду PowerShell New-AzADServicePrincipal . Эта команда создает субъект-службу с ролью владельца и задает область на уровне подписки. Дополнительные сведения о создании субъектов-служб см. в статье Создание субъекта-службы Azure с помощью Azure PowerShell.
$sp = New-AzADServicePrincipal -role "Owner" -scope /subscriptions/$subscriptionID
Получите пароль для субъекта-службы, выполнив следующую команду. Обратите внимание, что приведенная ниже команда работает только для Az.Accounts 2.6.0 или более поздней версии. Мы автоматически загружаем модуль Az.Accounts 2.6.0 при установке модуля AksHci PowerShell.
$secret = [System.Runtime.InteropServices.Marshal]::PtrToStringAuto([System.Runtime.InteropServices.Marshal]::SecureStringToBSTR($sp.Secret))
Write-Host "Application ID: $($sp.ApplicationId)"
Write-Host "App Secret: $secret"
Из приведенных выше выходных данных теперь у вас есть идентификатор приложения и секрет , доступные при развертывании AKS в Azure Stack HCI и Windows Server. Вы должны заметить эти элементы и хранить их в безопасности. После создания в портал Azure в разделе Подписки, контроль доступа, а затем Назначения ролей вы увидите новый субъект-службу.
Группа ресурсов Azure
Перед регистрацией необходимо иметь группу ресурсов Azure в регионе Azure "Восточная Австралия", "Восточная часть США", "Юго-Восточная Азия" или "Западная Европа".
Дальнейшие действия
Выполнив все описанные выше предварительные требования, вы можете настроить узел AKS в Azure Stack HCI с помощью следующих средств: