Требования к системе для Служба Azure Kubernetes в Azure Stack HCI и Windows Server
Область применения: Azure Stack HCI версии 21H2 и 20H2; Windows Server 2022 Datacenter, Windows Server 2019 Datacenter
В этой статье рассматриваются требования к настройке Служба Azure Kubernetes в Azure Stack HCI или в центре обработки данных сервера Windows и его использовании для создания кластеров Kubernetes. Общие сведения об AKS в Azure Stack HCI и сервере Windows см. в статье AKS в Azure Stack HCI и обзоре сервера Windows.
требования к Active Directory
Для AKS в Azure Stack HCI и Windows Server или Windows Server Datacenter для оптимальной работы в среде Active Directory убедитесь, что выполнены следующие требования:
Настройте синхронизацию времени, чтобы расхождение не превышало 2 минуты на всех узлах кластера и контроллере домена. Сведения о настройке синхронизации времени см. в разделе Windows Службе времени.
Убедитесь, что учетные записи пользователей, используемые для добавления обновлений, а также управление AKS в Azure Stack HCI и Windows Server или кластеры Windows Server Datacenter имеют правильные разрешения в Active Directory. Если вы используете подразделения для управления групповыми политиками для серверов и служб, учетным записям пользователей потребуются разрешения на чтение, изменение и удаление всех объектов в подразделении.
Используйте отдельное подразделение (OU) для серверов и служб AKS в Azure Stack HCI и Windows Server или кластеров центров обработки данных Windows. Использование отдельного подразделения позволяет управлять доступом и разрешениями с большей степенью детализации.
Если вы используете шаблоны объектов групповой политики в контейнерах в Active Directory, убедитесь, что развертывание AKS в Azure Stack HCI и Windows Server исключается из политики. Усиление защиты сервера будет доступно в следующем выпуске.
Требования к оборудованию
Корпорация Майкрософт рекомендует приобрести проверенное аппаратное или программное решение Azure Stack HCI у наших партнеров. Эти решения разработаны, собраны и проверены для запуска эталонной архитектуры и проверки совместимости и надежности, чтобы быстро приступить к работе. Убедитесь, что системы, компоненты, устройства и драйверы, которые вы используете, Windows Server Certified в каталоге серверов Windows. Посетите веб-сайт решений Azure Stack HCI для проверенных решений.
Максимальные поддерживаемые спецификации оборудования
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 с одним узлом | 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 | Служба хранилища с прямым подключением | 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 для создания гиперконвергентной инфраструктуры, которая представляет общие тома кластера для использования рабочими нагрузками. Для Локальные дисковые пространства требуется, чтобы ваше хранилище было гибридным (flash + HDD), которое балансирует производительность и емкость, или все флэш-память (SSD, NVMe), что повышает производительность. Если вы решили развернуть хранилище на основе SAN, убедитесь, что хранилище SAN может обеспечить достаточную производительность для выполнения нескольких рабочих нагрузок виртуальных машин. Старое хранилище SAN на основе HDD может не обеспечить требуемый уровень производительности для выполнения нескольких рабочих нагрузок виртуальных машин, и могут возникнуть проблемы с производительностью и время ожидания.
Для развертываний с одним узлом Windows Server с использованием локального хранилища настоятельно рекомендуется использовать хранилище всех флэш-памяти (SSD, NVMe), чтобы обеспечить необходимую производительность для размещения нескольких виртуальных машин на одном физическом узле. Без хранилища флэш-памяти более низкие уровни производительности в HDD могут привести к проблемам развертывания и истечению времени ожидания.
Требования к сети
Следующие требования применяются к кластеру Azure Stack HCI или Windows Server и кластеру 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 для обнаружения. Если динамический DNS не является вариантом, выполните действия, описанные в set-AksHciConfig.
Назначение IP-адресов
В AKS в Azure Stack HCI и сервере Windows виртуальные сети используются для выделения 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 и количества служб, выполняемых в кластере Kubernetes. Для развертывания рекомендуется зарезервировать в общей сложности 256 IP-адресов (/24 подсети).
Дополнительные сведения о требованиях к сети см. в концепциях сети узлов в AKS в Azure Stack HCI и Windows Server и сетевых концепциях контейнеров в AKS в Azure Stack HCI и Windows Server.
Требования к сетевому порту и URL-адресу
AKS в Azure Stack HCI и требования к серверу Windows
При создании кластера 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 | Сервер gRPC wssdAgent | Правила между виртуальными локальными сетями не требуются. |
| 45001 | Физические узлы Hyper-V | Проверка подлинности wssdAgent gRPC | Правила между виртуальными локальными сетями не требуются. |
| 46000 | Виртуальные машины AKS | wssdCloudAgent to 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.b.tlu.dl.delivery.mp.microsoft.com | 80 | Используется при скачивании AKS в каталоге продуктов Azure Stack HCI, битах продуктов и образах ОС из SFS. Происходит при запуске Set-AksHciConfig и в любое время загрузки из SFS. |
| msk8s.f.tlu.dl.delivery.mp.microsoft.com | 80 | Используется при скачивании AKS в каталоге продуктов Azure Stack HCI, битах продуктов и образах ОС из SFS. Происходит при запуске Set-AksHciConfig и в любое время загрузки из SFS. |
| login.microsoftonline.com | 443 | Используется для входа в Azure при запуске Set-AksHciRegistration. |
| login.windows.net | 443 | Используется для входа в Azure при запуске Set-AksHciRegistration. |
| management.azure.com | 443 | Используется для входа в Azure при запуске Set-AksHciRegistration. |
| www.microsoft.com | 443 | Используется для входа в Azure при запуске Set-AksHciRegistration. |
| msft.sts.microsoft.com | 443 | Используется для входа в Azure при запуске Set-AksHciRegistration. |
| graph.windows.net | 443 | Используется для входа в Azure при запуске Set-AksHciRegistration. |
| ecpacr.azurecr.io | 443 | Требуется для извлечения образов контейнеров при запуске Install-AksHci. |
| Конечная точка .blob.core.windows.net США: wus2replica.blob.core.windows.net | 443 | Требуется для извлечения образов контейнеров при запуске Install-AksHci. |
| mcr.microsoft.com, *.mcr.microsoft.com | 443 | Требуется для извлечения образов контейнеров при запуске Install-AksHci. |
| akshci.azurefd.net | 443 | Требуется для выставления счетов AKS в Azure Stack HCI при запуске Install-AksHci. |
| arck8onboarding.azurecr.io | 443 | Требуется для извлечения образов контейнеров при запуске Install-AksHci. |
| v20.events.data.microsoft.com | 443 | Используется периодически для отправки необходимых диагностических данных майкрософт из узла Azure Stack HCI или Windows Server. |
| adhs.events.data.microsoft.com | 443 | Используется периодически для отправки необходимых диагностических данных Майкрософт с узлов уровня управления. |
Требования Arc для Kubernetes
Примечание
Так как кластер управления (узел AKS) использует Azure Arc для выставления счетов, необходимо следовать этим требованиям к сети для кластеров Kubernetes с поддержкой Azure Arc.
Требования к Azure Stack HCI
Примечание
Также следует просмотреть URL-адреса Azure Stack HCI.
Требования к Arc для серверов
Примечание
Так как Arc для серверов устанавливается по умолчанию на узлах Azure Stack HCI из Azure Stack HCI 21H2, необходимо также просмотреть Arc для URL-адресов агентов сервера.
требования к 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, пользователь, регистрирующий кластер, должен иметь по крайней мере одно из следующих условий:
- Учетная запись пользователя со встроенной ролью владельца .
- Субъект-служба с одним из следующих уровней доступа:
- Встроенный кластер Kubernetes — роль подключения Azure Arc
- Встроенная роль участника
- Встроенная роль владельца
Если ваша подписка Azure выполняется через EA или CSP, проще всего развернуть AKS в Azure Stack HCI и Windows Server с просьбой администратора Azure создать субъект-службу с соответствующими разрешениями. Администраторы могут проверить, как создать субъект-службу.
Необязательно. Создание субъекта-службы
Выполните следующие действия, чтобы создать субъект-службу со встроенной ролью подключенного кластера Microsoft.Kubernetes . Только владельцы подписок могут создавать субъекты-службы с правильным назначением ролей. Вы можете проверить уровень доступа, перейдя к подписке, щелкнув элемент управления доступом (IAM) в левой части портал Azure и щелкнув "Просмотреть мой доступ".
Установите и импортируйте следующие модули Azure PowerShell:
Install-Module -Name Az.Accounts -Repository PSGallery -RequiredVersion 2.2.4
Import-Module Az.Accounts
Install-Module -Name Az.Resources -Repository PSGallery -RequiredVersion 3.2.0
Import-Module Az.Resources
Install-Module -Name AzureAD -Repository PSGallery -RequiredVersion 2.0.2.128
Import-Module AzureAD
Закройте все окна PowerShell и снова откройте новый административный сеанс.
Войдите в Azure с помощью команды PowerShell Подключение-AzAccount:
Connect-AzAccount
Задайте подписку, которую вы хотите использовать для регистрации узла AKS для выставления счетов в качестве подписки по умолчанию, выполнив команду Set-AzContext .
Set-AzContext -Subscription myAzureSubscription
Проверьте правильность контекста входа, выполнив команду 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. Эта команда создает субъект-службу с помощью microsoft. Роль подключенного кластера Kubernetes и задает область на уровне подписки. Дополнительные сведения о создании субъектов-служб см. в статье о создании субъекта-службы Azure с помощью Azure PowerShell.
$sp = New-AzADServicePrincipal -role "Microsoft.Kubernetes connected cluster"
Получите пароль для субъекта-службы, выполнив следующую команду:
$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. Вы должны заметить эти элементы и безопасно хранить их. После этого в портал Azure в разделе "Подписки" контроль доступа и назначения ролей вы увидите новый субъект-службу.
Группа ресурсов Azure
Перед регистрацией необходимо иметь группу ресурсов Azure в регионе Azure "Восточная часть США", "Юго-Восточная Азия" или "Западная Европа".
Дальнейшие действия
После выполнения всех описанных выше предварительных требований можно настроить узел AKS в Azure Stack HCI с помощью: