Требования к системе для AKS на Windows Server

Область применения: Windows Server 2022, Windows Server 2019

В этой статье описываются требования к настройке службы Azure Kubernetes (AKS) на Windows Server. Общие сведения об AKS на Windows Server см. в обзоре AKS.

Требования к аппаратному обеспечению

Корпорация Майкрософт рекомендует приобрести проверенное решение для оборудования и программного обеспечения Windows Server от наших партнеров. Эти решения разработаны, собраны и проверены для реализации эталонной архитектуры и проверки совместимости и надежности, чтобы вы могли быстро начать работу. Убедитесь, что используются системы, компоненты, устройства и драйверы Windows Server сертифицированы в каталоге Windows Server.

Максимальные поддерживаемые спецификации оборудования

AkS в развертываниях Windows Server, превышающих следующие спецификации, не поддерживаются:

Требования к вычислениям

Минимальные требования к памяти

Кластер AKS можно настроить следующим образом, чтобы запустить AKS на одном узле Windows Server с ограниченным объемом ОЗУ:

Общее минимальное требование: 30 ГБ ОЗУ.

Это минимальное требование для развертывания AKS с одним рабочим узлом для запуска контейнерных приложений. Если вы выберете добавить рабочие узлы или балансировщик нагрузки HAProxy, окончательные требования к ОЗУ изменятся соответствующим образом.

Рекомендуемые требования к вычислительным ресурсам

Для рабочей среды окончательный размер зависит от приложения и количества рабочих узлов, которые планируется развернуть в кластере Windows Server. Если вы решили запустить AKS на одном сервере Windows, вы не получите такие функции, как высокая доступность, которые доступны в отказоустойчивом кластере Windows Server.

Необходимо установить одну и ту же операционную систему на каждом сервере в кластере. В Центре обработки данных Windows Server одинаковые ОС и версия должны быть одинаковыми на каждом сервере в кластере. Каждая ОС должна использовать регион en-us и выбор языка. Эти параметры нельзя изменить после установки.

Требования к системе хранения данных

AKS в Windows Server поддерживает следующие реализации хранилища:

Для кластера Windows Server поддерживаются две поддерживаемые конфигурации хранилища для выполнения рабочих нагрузок виртуальных машин:

• Гибридное хранилище балансирует производительность и емкость с помощью флэш-хранилища и жестких дисков (HDD).
• Хранилище all-flash обеспечивает максимальную производительность с помощью твердотельных накопителей (SSD) или NVMe.

Kubernetes использует etcd для хранения состояния кластеров. Etcd хранит конфигурацию, спецификации и состояние запущенных pod'ов. Кроме того, Kubernetes использует хранилище для обнаружения служб. В рамках координационной роли для работы Kubernetes и поддерживаемых им рабочих нагрузок задержка и пропускная способность к etcd критически важны. Необходимо запустить AKS на SSD. Дополнительные сведения см. в разделе "Производительность".

Для кластера Windows Server Datacenter можно развернуть с использованием локального хранилища или хранения на базе SAN. Для локального хранилища рекомендуется использовать встроенное Storage Spaces Direct или эквивалентное сертифицированное виртуальное решение SAN для создания гиперконвергентной инфраструктуры с общими томами кластера, которые могут использоваться рабочими нагрузками. Для Объединённые дисковые пространства необходимо, чтобы ваше хранилище было гибридным (Flash + HDD), которое балансирует производительность и ёмкость, или полностью на основе флэш-памяти (SSD, NVMe) для максимальной производительности. Если вы решили развернуть хранилище на основе SAN, убедитесь, что хранилище SAN может обеспечить достаточную производительность для выполнения нескольких рабочих нагрузок виртуальных машин. Более старое хранилище SAN на основе HDD может не обеспечить необходимые уровни производительности для выполнения нескольких рабочих нагрузок виртуальных машин, и могут возникнуть проблемы с производительностью и время ожидания.

Для развертываний Windows Server с одним узлом с помощью локального хранилища настоятельно рекомендуется использовать все флэш-хранилище (SSD, NVMe), чтобы обеспечить необходимую производительность для размещения нескольких виртуальных машин на одном физическом узле. Без хранилища флэш-памяти более низкий уровень производительности hdD может вызвать проблемы с развертыванием и время ожидания.

Требования к сети

Следующие требования применяются к кластеру Центра обработки данных Windows Server.

• Убедитесь, что у вас есть существующий внешний виртуальный коммутатор, настроенный, если вы используете Windows Admin Center. Для кластеров Windows Server этот параметр и его имя должны совпадать во всех узлах кластера.
• Убедитесь, что для всех сетевых адаптеров отключен IPv6.
• Для успешного развертывания узлы кластера Windows Server и виртуальные машины кластера Kubernetes должны иметь внешнее подключение к Интернету.
• Убедитесь, что все подсети, определенные для кластера, являются маршрутизируемыми между собой и в Интернете.
• Убедитесь, что между узлами Windows Server и виртуальными машинами клиента есть сетевое подключение.
• Разрешение DNS-имен требуется для всех узлов, чтобы иметь возможность взаимодействовать друг с другом.
• (Рекомендуется) Включите динамические обновления DNS в среде DNS, чтобы разрешить AKS регистрировать универсальное имя кластера облачного агента в системе DNS для обнаружения.

Назначение IP-адресов

В AKS в Windows Server виртуальные сети используются для выделения IP-адресов ресурсам Kubernetes, которые требуют их, как описано ранее. В зависимости от требуемой архитектуры сети AKS можно выбрать две сетевые модели.

• Статические IP-сети: виртуальная сеть выделяет статические IP-адреса серверу API кластера Kubernetes, узлам Kubernetes, базовым виртуальным машинам, подсистемам балансировки нагрузки и любым службам Kubernetes, которые вы запускаете на вершине кластера.
• Сеть DHCP: виртуальная сеть выделяет динамические IP-адреса узлам Kubernetes, базовым виртуальным машинам и подсистемам балансировки нагрузки с помощью DHCP-сервера. Сервер API кластера Kubernetes и все службы Kubernetes, которые вы запускаете поверх кластера, по-прежнему выделяют статические IP-адреса.

Минимальное резервирование IP-адресов

Как минимум, необходимо зарезервировать следующее число IP-адресов для развертывания:

Кроме того, необходимо зарезервировать следующее число IP-адресов для пула ВИРТУАЛЬНЫх IP-адресов:

Как видно, количество необходимых IP-адресов является переменной в зависимости от архитектуры AKS и количества служб, выполняемых в кластере Kubernetes. Рекомендуется резервировать 256 IP-адресов (/24 подсети) для развертывания.

Для получения дополнительной информации о сетевых требованиях, см. концепции сетевого взаимодействия узлов в AKS и концепции сетевого взаимодействия контейнеров в AKS.

Требования к сетевому порту и URL-адресу

ТРЕБОВАНИЯ AKS к Windows Server

При создании кластера Kubernetes следующие порты брандмауэра автоматически открываются на каждом сервере в кластере.

Если узлы физического кластера и виртуальные машины кластера Azure Kubernetes находятся в двух изолированных виртуальных сетях, эти порты должны быть открыты в брандмауэре между ними:

Если для подключения к Интернету требуется использовать прокси-сервер, см. раздел "Использование параметров прокси-сервера" в AKS.

[{
    "URL": "msk8s.api.cdp.microsoft.com",
    "Port": "443 ",
    "Notes": "Used when downloading the AKS on Azure Stack HCI product catalog, product bits, and OS images from SFS.Occurs when running `Set-AksHciConfig` and at any time you download from SFS."
}, {
    "URL": "msk8s.b.tlu.dl.delivery.mp.microsoft.com",
    "Port": "80",
    "Notes": "Used when downloading the AKS on Azure Stack HCI product catalog, product bits, and OS images from SFS. Occurs when running `Set-AksHciConfig` and at any time you download from SFS."
}, {
    "URL": "msk8s.f.tlu.dl.delivery.mp.microsoft.com",
    "Port": "80",
    "Notes": "Used when downloading the AKS on Azure Stack HCI product catalog, product bits, and OS images from SFS. Occurs when running `Set-AksHciConfig` and at any time you download from SFS."
}, {
    "URL": "login.microsoftonline.com",
    "Port": "443",
    "Notes": "Used for logging into Azure when running `Set-AksHciRegistration`."
}, {
    "URL": "login.windows.net",
    "Port": "443",
    "Notes": "Used for logging into Azure when running `Set-AksHciRegistration`."
}, {
    "URL": "management.azure.com",
    "Port": "443",
    "Notes": "Used for logging into Azure when running `Set-AksHciRegistration`."
}, {
    "URL": "www.microsoft.com",
    "Port": "443",
    "Notes": "Used for logging into Azure when running `Set-AksHciRegistration`."
}, {
    "URL": "msft.sts.microsoft.com",
    "Port": "443",
    "Notes": "Used for logging into Azure when running `Set-AksHciRegistration`."
}, {
    "URL": "graph.windows.net",
    "Port": "443",
    "Notes": "Used for logging into Azure when running `Set-AksHciRegistration`."
}, {
    "URL": "ecpacr.azurecr.io",
    "Port": "443",
    "Notes": "Required to pull container images when running `Install-AksHci`."
}, {
    "URL": "*.blob.core.windows.net  US endpoint: wus2replica*.blob.core.windows.net",
    "Port": "443",
    "Notes": "Required to pull container images when running `Install-AksHci`."
}, {
    "URL": "mcr.microsoft.com, *.mcr.microsoft.com",
    "Port": "443",
    "Notes": "Required to pull container images when running `Install-AksHci`."
}, {
    "URL": "akshci.azurefd.net",
    "Port": "443",
    "Notes": "Required for AKS on Azure Stack HCI billing when running `Install-AksHci`."
}, {
    "URL": "v20.events.data.microsoft.com",
    "Port": "443",
    "Notes": "Used periodically to send Microsoft required diagnostic data from the Azure Stack HCI or Windows Server host."
}, {
    "URL": "gcs.prod.monitoring.core.windows.net",
    "Port": "443",
    "Notes": "Used periodically to send Microsoft required diagnostic data from control plane nodes."
}]

Дополнительные требования к URL-адресу для функций Azure Arc

Предыдущий список URL-адресов охватывает минимальные необходимые URL-адреса для подключения службы AKS к Azure для выставления счетов. Необходимо разрешить дополнительные URL-адреса, если вы хотите использовать такие службы, как подключение к кластеру, пользовательские расположения, Azure RBAC и Azure Monitor, а также другие службы Azure в кластере рабочей нагрузки AKS. Полный список URL-адресов Arc см. в статье о требованиях к сети Kubernetes с поддержкой Azure Arc.

Растянутые кластеры в AKS

Как описано в обзоре растянутых кластеров, развертывание AKS на Windows Server с использованием растянутых кластеров Windows не поддерживается. Мы рекомендуем использовать подход резервного копирования и аварийного восстановления для непрерывности работы центра обработки данных. Дополнительные сведения см. в статье "Выполнение резервного копирования или восстановления кластера рабочей нагрузки с помощью Velero и хранилища BLOB-объектов Azure в Windows Server", а также "Развертывание конфигураций в AksHci с помощью GitOps и Flux v2" для обеспечения непрерывности приложений.

Требования к Windows Admin Center

Windows Admin Center — это пользовательский интерфейс для создания и управления AKS на Windows Server. Чтобы использовать Windows Admin Center с AKS на Windows Server, необходимо выполнить все условия в следующем списке.

Это требования для компьютера под управлением шлюза Windows Admin Center:

• Windows 10 или Windows Server.
• Зарегистрировано в Azure.
• В том же домене, что и кластер Центра обработки данных Windows Server.
• Подписка Azure, в которой у вас есть права владельца. Вы можете проверить уровень доступа, перейдя к подписке и выбрав элемент управления доступом (IAM) в левой части портал Azure, а затем выбрав "Просмотреть мой доступ".

Требования Azure

Необходимо подключиться к учетной записи Azure.

Учетная запись Azure и подписка

Если у вас еще нет учетной записи Azure, создайте ее. Вы можете использовать существующую подписку любого типа:

• Бесплатная учетная запись с кредитами Azure для учащихся или подписчиков Visual Studio.
• Подписка с оплатой по мере использования с помощью кредитной карты.
• Подписка, полученная через Корпоративное соглашение (EA).
• Подписка, полученная в рамках программы "Cloud Solution Provider" (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-...        [email protected]             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 при установке модуля 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 используется для регистрации, выставления счетов и управления. В настоящее время она поддерживается в следующих регионах:

• Восточная часть США
• Центрально-южная часть США
• Западная Европа

Требования к Active Directory

Для отказоустойчивого кластера AKS с 2 или более физическими узлами для оптимальной работы в среде Active Directory убедитесь, что выполнены следующие требования:

• Настройте синхронизацию времени, чтобы расхождение не превышало 2 минуты во всех узлах кластера и контроллере домена. Сведения о настройке синхронизации времени см. в разделе Служба времени Windows.
• Убедитесь, что учетные записи пользователей, используемые для добавления обновления, а также управление кластерами AKS или Windows Server Datacenter имеют правильные разрешения в Active Directory. Если вы используете организационные единицы (ОЕ) для управления групповыми политиками для серверов и служб, для учетных записей пользователей требуется разрешения на чтение, изменение и удаление всех объектов в организационной единице.
• Используйте отдельное подразделение организации (OU) для серверов и служб, управляемых кластерами AKS или Windows Server Datacenter. Использование отдельного подразделения позволяет управлять доступом и разрешениями с большей степенью детализации.
• Если вы используете шаблоны групповой политики в контейнерах в Active Directory, убедитесь, что развертывание AKS на Windows Server исключается из политики.

Следующие шаги

После удовлетворения всех этих предварительных требований можно настроить узел AKS с помощью:

• Windows Admin Center;
• PowerShell