Требования к системе для 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 ГБ | Н/Д — узел AKS не имеет рабочих узлов. | 8GB | Н/Д — узел AKS использует kubevip для балансировки нагрузки. |
| Кластер рабочей нагрузки | Standard_A4_v2 размер виртуальной машины = 8 ГБ | Standard_K8S3_v1 для 1 рабочего узла = 6 ГБ | Можно повторно использовать зарезервированные 8 ГБ для обновления кластера рабочей нагрузки. | Н/Д, если для балансировки нагрузки используется 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 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 , входят в одну из этих двух поддерживаемых конфигураций хранилища.
Kubernetes использует 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 22H2 и Windows Server Datacenter. Требования к сети в 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 находятся в двух изолированных виртуальных локальных сетях, эти порты должны быть открыты в брандмауэре между ними:
| Port | Источник | Описание | Примечания брандмауэра |
|---|---|---|---|
| 22 | Виртуальные машины AKS | Требуется для сбора журналов при использовании Get-AksHciLogs. |
При использовании отдельных виртуальных ЛС физические узлы Hyper-V должны обращаться к виртуальным машинам AKS на этом порту. |
| 6443 | Виртуальные машины AKS | Требуется для взаимодействия с API Kubernetes. | При использовании отдельных виртуальных ЛС физические узлы Hyper-V должны обращаться к виртуальным машинам AKS на этом порту. |
| 45000 | Физические узлы Hyper-V | сервер wssdAgent gRPC. | Правила между виртуальными локальными сетями не требуются. |
| 45001 | Физические узлы Hyper-V | проверка подлинности wssdAgent gRPC. | Правила между виртуальными локальными сетями не требуются. |
| 46000 | Виртуальные машины AKS | wssdCloudAgent в lbagent. | При использовании отдельных виртуальных ЛС физические узлы Hyper-V должны обращаться к виртуальным машинам AKS на этом порту. |
| 55 000 | Ресурс кластера (-CloudServiceCIDR) | Сервер gRPC облачного агента. | При использовании отдельных виртуальных ЛС виртуальные машины AKS должны обращаться к IP-адресу ресурса кластера через этот порт. |
| 65000 | Ресурс кластера (-CloudServiceCIDR) | Проверка подлинности gRPC облачного агента. | При использовании отдельных виртуальных ЛС виртуальные машины AKS должны обращаться к IP-адресу ресурса кластера через этот порт. |
Если для подключения к Интернету требуется использовать прокси-сервер, см. статью Использование параметров прокси-сервера в AKS.
В список разрешений необходимо добавить следующие 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 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-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, включенный Arc, хранит и обрабатывает данные клиентов. По умолчанию данные клиента остаются в регионе, в котором клиент развертывает экземпляр службы. Эти данные хранятся в региональных центрах обработки данных, управляемых корпорацией Майкрософт. Для регионов с требованиями к месту расположения данных данные клиентов всегда хранятся в одном регионе.
Дополнительные требования к URL-адресу для функций Azure Arc
Предыдущий список URL-адресов содержит минимальные URL-адреса, необходимые для подключения службы AKS к Azure для выставления счетов. Если вы хотите использовать подключение к кластеру, пользовательские расположения, Azure RBAC и другие службы Azure, такие как Azure Monitor и т. д., в кластере рабочей нагрузки AKS необходимо разрешить дополнительные URL-адреса. Полный список URL-адресов Arc см. в статье Требования к сети Kubernetes с поддержкой Azure Arc.
Также следует просмотреть URL-адреса Azure Stack HCI. Так как Arc для агентов сервера теперь устанавливается по умолчанию на узлах Azure Stack HCI из Azure Stack HCI 21H2 и более поздних версий, также следует ознакомиться с URL-адресами агентов сервера Arc.
Растянутые кластеры в 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 ID, чтобы проверка свою роль.
- Если ваша роль — Пользователь, необходимо убедиться, что пользователи, не являющиеся администраторами, могут регистрировать приложения.
- Чтобы проверка, можно ли зарегистрировать приложения, перейдите в раздел Параметры пользователя в службе Microsoft Entra, чтобы проверка, если у вас есть разрешение на регистрацию приложения.
Если для параметра регистрации приложений задано значение Нет, регистрировать эти типы приложений могут только пользователи с ролью администратора. Сведения о доступных ролях администратора и конкретных разрешениях в Microsoft Entra ID, которые предоставляются каждой роли, см. в статье 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>"
Установите и импортируйте модуль AKS PowerShell:
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 = $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. Если вы используете подразделения для управления групповыми политиками для серверов и служб, учетным записям пользователей требуются разрешения на перечисление, чтение, изменение и удаление для всех объектов в подразделении.
- Используйте отдельное подразделение для серверов и служб кластеров AKS или Windows Server Datacenter. Использование отдельного подразделения позволяет управлять доступом и разрешениями с большей степенью детализации.
- Если вы используете шаблоны объектов групповой политики в контейнерах в Active Directory, убедитесь, что развертывание AKS в Azure Stack HCI и Windows Server исключается из политики.
Дальнейшие действия
Выполнив все описанные выше предварительные требования, вы можете настроить узел AKS в Azure Stack HCI с помощью следующих средств:
Обратная связь
Ожидается в ближайшее время: в течение 2024 года мы постепенно откажемся от GitHub Issues как механизма обратной связи для контента и заменим его новой системой обратной связи. Дополнительные сведения см. в разделе https://aka.ms/ContentUserFeedback.
Отправить и просмотреть отзыв по