Требования к системе для AKS, управляемых с помощью Azure Arc в Azure Local 22H2
Область применения: Локальная служба Azure, версии 22H2; Windows Server 2022, Windows Server 2019
В этой статье описаны требования к настройке Служба Azure Kubernetes (AKS), включенной Azure Arc. Общие сведения об AKS, включенном Arc, см. в обзоре AKS.
Требования к аппаратному обеспечению
Корпорация Майкрософт рекомендует приобрести проверенное решение локального оборудования и программного обеспечения Azure от наших партнеров. Эти решения разработаны, собраны и проверены для запуска эталонной архитектуры и проверки совместимости и надежности, чтобы быстро работать. Убедитесь, что используются системы, компоненты, устройства и драйверы Windows Server сертифицированы в каталоге Windows Server. На веб-сайте Azure доступны проверенные локальные решения.
Внимание
Хост-системы для рабочих развертываний должны быть физическим оборудованием. Вложенная виртуализация, представляющая собой развертывание Azure Local или Windows Server на виртуальной машине и установку AKS в этой виртуальной машине, не поддерживается.
Максимальные поддерживаемые спецификации оборудования
Развертывания AKS в локальной среде Azure и Windows Server, превышающие следующие спецификации, не поддерживаются:
| Ресурс | Максимум |
|---|---|
| Физические серверы на кластер | 8 (Локальная версия Azure 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 | 32 | 256 ГБ |
| Отказоустойчивый кластер Windows Server | 32 | 256 ГБ |
| Один узел Windows Server | 16 | 128 ГБ |
Для рабочей среды окончательный размер зависит от приложения и количества рабочих узлов, которые планируется развернуть в локальном или windows Server кластере Azure. Если вы решили запустить AKS на одном узле Windows Server, вы не получите такие функции, как высокая доступность, которые доступны при запуске AKS в локальном кластере Azure, кластере Windows Server или отказоустойчивом кластере Windows Server.
Другие требования к вычислительным ресурсам AKS в локальной среде Azure и Windows Server соответствуют локальным требованиям Azure. Для получения дополнительной информации о требованиях к локальному серверу Azure см. требования к локальной системе Azure.
Необходимо установить одну и ту же операционную систему на каждом сервере в кластере. Если вы используете Локальную среду Azure, на каждом сервере в кластере должна быть установлена одна и та же ОС и версия. Если вы используете Центр обработки данных Windows Server, то на каждом сервере в кластере должна быть одна и та же версия ос и версия. Каждая ОС должна использовать регион en-us и выбор языка. Эти параметры нельзя изменить после установки.
Требования к системе хранения данных
AKS в Локальной среде Azure и Windows Server поддерживает следующие реализации хранилища:
| Имя. | Тип хранилища | Требуемая емкость |
|---|---|---|
| Локальный кластер Azure | Общие тома кластера | 1 TБ |
| Отказоустойчивый кластер Центра обработки данных Windows Server | Общие тома кластера | 1 TБ |
| Центр обработки данных Windows Server с одним узлом | Система хранения с прямым подключением | 500 ГБ |
Для кластера Azure Local или Windows Server поддерживаются две поддерживаемые конфигурации хранилища для выполнения рабочих нагрузок виртуальных машин:
- Гибридное хранилище балансирует производительность и емкость с помощью флэш-хранилища и жестких дисков (HDD).
- Хранилище all-flash обеспечивает максимальную производительность с помощью твердотельных накопителей (SSD) или NVMe.
Системы, имеющие только хранилище на основе HDD, не поддерживаются локальной службой Azure, поэтому не рекомендуется запускать AKS на локальном компьютере Azure и Windows Server. Дополнительные сведения о рекомендуемых конфигурациях дисков см. в документации по локальной среде Azure. Все системы, проходящие валидацию в локальном каталоге Azure , соответствуют одной из двух поддерживаемых конфигураций хранилища.
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 Local 22H2 и кластеру Центра обработки данных Windows Server. Требования к сети в Azure Local 23H2 см. в разделе Требования к сети.
- Для Azure Local 22H2 и Windows Server убедитесь, что у вас есть существующий внешний виртуальный коммутатор, настроенный, если вы используете Windows Admin Center. Для кластеров Azure Local или Windows Server этот параметр и его имя должны совпадать во всех узлах кластера. Для Azure Local 23H2 см. требования к системе сети.
- Убедитесь, что IPv6 отключен для всех сетевых адаптеров.
- Для успешного развертывания узлы кластера Azure local или Windows Server и виртуальные машины кластера Kubernetes должны иметь внешнее подключение к Интернету.
- Убедитесь, что все подсети, определенные для кластера, являются маршрутизируемыми между собой и в Интернете.
- Убедитесь, что между локальными узлами Azure и виртуальными машинами клиента есть сетевое подключение.
- Разрешение 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 следующие порты брандмауэра автоматически открываются на каждом сервере в кластере.
Если узлы локального физического кластера Azure и виртуальные машины кластера 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. Так как Arc для агентов сервера теперь устанавливается по умолчанию на локальных узлах Azure из Azure Local 21H2 и более поздних версий, необходимо также просмотреть Arc для URL-адресов агентов сервера.
Растянутые кластеры в AKS
Как описано в обзоре растянутых кластеров, развертывание AKS на локальной версии Azure и Windows Server с использованием расширенных кластеров Windows не поддерживается. Мы рекомендуем использовать подход резервного копирования и аварийного восстановления для непрерывности работы центра обработки данных. Для получения дополнительной информации смотрите о выполнении резервного копирования или восстановления кластера рабочей нагрузки с помощью Velero и Azure Blob Storage на Azure Local и Windows Server; а также о развертывании конфигураций на AksHci с использованием GitOps с Flux v2 для обеспечения непрерывности приложений.
Требования к Windows Admin Center
Windows Admin Center — это пользовательский интерфейс для создания и управления AKS, подключённых через Azure Arc. Чтобы использовать Windows Admin Center с AKS на платформе Azure Local и Windows Server, необходимо соответствовать всем критериям, перечисленным в следующем списке.
Это требования для компьютера под управлением шлюза Windows Admin Center:
- Windows 10 или Windows Server.
- Зарегистрировано в Azure.
- В том же домене, что и Azure Local или кластер 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 Local или Windows Server с одним узлом.
- Настройте синхронизацию времени, чтобы расхождение не превышало 2 минуты во всех узлах кластера и контроллере домена. Сведения о настройке синхронизации времени см . в службе времени Windows.
- Убедитесь, что учетные записи пользователей, используемые для добавления обновления, а также управление кластерами AKS или Windows Server Datacenter имеют правильные разрешения в Active Directory. Если вы используете подразделения для управления групповыми политиками для серверов и служб, учетные записи пользователей требуют списка, чтения, изменения и удаления разрешений для всех объектов в подразделении.
- Используйте отдельную подразделение организации (OU) для серверов и служб кластерами AKS или Windows Server Datacenter. Использование отдельного подразделения позволяет управлять доступом и разрешениями с более детальной степенью детализации.
- Если вы используете шаблоны групповой политики в контейнерах в Active Directory, убедитесь, что развертывание AKS в Azure Local и Windows Server исключается из политики.
Следующие шаги
Выполнив все указанные выше предварительные требования, вы можете настроить узел AKS в локальной среде Azure с помощью следующих компонентов: