Ограничения ресурсов, размеры виртуальных машин и регионы для AKS, включаемых Azure Arc

  • Статья

Область применения: AKS в Azure Stack HCI 22H2, AKS в Windows Server

В этой статье содержатся сведения о проверенных конфигурациях, ограничениях ресурсов, размерах виртуальных машин и регионах для Служба Azure Kubernetes (AKS), включенных в Azure Arc. В тестах использовался последний выпуск AKS в Azure Stack HCI.

Максимальные спецификации

AKS, включенные развертываниями Arc, были проверены со следующими конфигурациями, включая указанные максимальные значения. Имейте в виду, что превышение этих максимальных значений выполняется на ваш страх и риск и может привести к неожиданным поведению и сбоям. В этой статье содержатся некоторые рекомендации о том, как избежать распространенных ошибок конфигурации, а также помогут вам создать конфигурацию большего размера. При возникновении сомнений обратитесь за помощью в местный офис Майкрософт или отправьте вопрос в сообществе Azure Stack HCI.

Ресурс Максимум
Физические серверы на кластер 8
Общее число виртуальных машин 200

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

Системная роль Размер виртуальной машины
AKS-Host Standard_A4_v2
Узел уровня управления целевым кластером Default
Подсистема балансировки нагрузки haProxy целевого кластера (необязательно) Standard_A4_v2
Рабочий узел целевого кластера Linux Standard_K8S3_v1
Рабочий узел Windows целевого кластера Standard_K8S3_v1

Конфигурация оборудования каждого физического узла в кластере Azure Stack HCI выглядит следующим образом:

  • Корпус: Сервер Dell PowerEdge R650 или аналогичный.
  • ОЗУ: RDIMM, 3200 MT/с, двойной ранг, всего 256 ГБ.
  • ЦП: два (2) Intel Xeon Silver 4316 2.3G, 20C/40T, 10,4 GT/с, 30 МБ кэша, Turbo, HT (150 Вт) DDR4-2666.
  • Диск: 8 жестких дисков (2 ТБ или больше) и 2 x 1,6 ТБ NVMe для поддержки конфигураций хранилища S2D.
  • Сеть: четыре (4) 100-гибитных сетевых адаптера (Mellanox или Intel).

Инженеры Майкрософт протестировали AKS, включенные в Arc, с помощью приведенной выше конфигурации. Для одного узла. 2 узла, 4 узла и 8 узлов Отказоустойчивые кластеры Windows. Если у вас есть требования к превышению протестированной конфигурации, см. статью Масштабирование AKS в Azure Stack HCI.

Важно!

При обновлении развертывания AKS временно используются дополнительные ресурсы. Каждая виртуальная машина обновляется в последовательном потоке обновления, начиная с узлов уровня управления. Для каждого узла в кластере Kubernetes создается виртуальная машина узла. Старая виртуальная машина узла ограничена, чтобы предотвратить развертывание на ней рабочих нагрузок. Затем ограниченная виртуальная машина очищается из всех контейнеров, чтобы распределить контейнеры между другими виртуальными машинами в системе. Затем истощаемая виртуальная машина удаляется из кластера, завершает работу и заменяется новой обновленной виртуальной машиной. Этот процесс повторяется до тех пор, пока не будут обновлены все виртуальные машины.

Доступные размеры виртуальных машин

Для AKS в Azure Stack HCI доступны следующие размеры виртуальных машин для узлов уровня управления, рабочих узлов Linux и рабочих узлов Windows. Хотя размеры виртуальных машин, такие как Standard_K8S2_v1 и Standard_K8S_v1 , поддерживаются для тестирования и развертывания с низкими требованиями к ресурсам, используйте эти размеры с осторожностью и применяйте строгое тестирование, так как они могут привести к непредвиденным сбоям из-за нехватки памяти.

Размер виртуальной машины ЦП Память (ГБ) Тип GPU Количество ЦП
Default 4 4
Standard_A2_v2 2 4
Standard_A4_v2 4 8
Standard_D2s_v3 2 8
Standard_D4s_v3 4 16
Standard_D8s_v3 8 32
Standard_D16s_v3 16 64
Standard_D32s_v3 32 128
Standard_DS2_v2 2 7
Standard_DS3_v2 2 14
Standard_DS4_v2 8 28
Standard_DS5_v2 16 56
Standard_DS13_v2 8 56
Standard_K8S_v1 4 2
Standard_K8S2_v1 2 2
Standard_K8S3_v1 4 6
Standard_NK6 6 12 Tesla T4 1
Standard_NK12 12 24 Tesla T4 2

Поддерживаемые регионы Azure для регистрации Azure

AKS, включенная Arc, поддерживается в следующих регионах Azure:

  • Восточная Австралия
  • Восточная часть США
  • Юго-Восточная Азия
  • Западная Европа

Масштабирование AKS в Azure Stack HCI

Масштабирование развертывания AKS в Azure Stack HCI требует планирования заранее, зная о рабочих нагрузках и целевом использовании кластера. Кроме того, учитывайте аппаратные ресурсы в базовой инфраструктуре, такие как общее количество ядер ЦП, общий объем памяти, хранилища, IP-адреса и т. д.

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

Прежде чем начать, примите во внимание следующие моменты, чтобы определить максимальный масштаб и количество целевых кластеров, которые необходимо поддерживать.

  • Количество IP-адресов, доступных для модулей pod в целевом кластере.
  • Количество IP-адресов, доступных для служб Kubernetes в целевом кластере.
  • Количество модулей pod, необходимых для выполнения рабочих нагрузок.

Чтобы определить размер виртуальной машины узла Служба Azure Kubernetes, необходимо знать количество рабочих узлов и целевых кластеров, так как это определяет размер виртуальной машины узла AKS. Пример:

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

Примечание

Один узел AKS может управлять только целевыми кластерами на одной платформе.

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

Параметры по умолчанию, которые в настоящее время невозможно изменить в AKS

В настоящее время существуют конфигурации и параметры по умолчанию, недоступные для управления клиентом во время или после развертывания. Эти параметры могут ограничить масштаб для заданного целевого кластера.

  • Количество IP-адресов для модулей pod Kubernetes в целевом кластере ограничено подсетью 10.244.0.0/16. То есть для модулей pod можно использовать 255 IP-адресов на рабочий узел во всех пространствах имен Kubernetes. Чтобы просмотреть CIDR pod, назначенный каждому рабочему узлу в кластере, используйте следующую команду в PowerShell:
kubectl get nodes -o json | findstr 'hostname podCIDR'

                    "kubernetes.io/hostname": "moc-lip6cotjt0f",
                                "f:podCIDR": {},
                                "f:podCIDRs": {
                                    "f:kubernetes.io/hostname": {},
                "podCIDR": "10.244.2.0/24",
                "podCIDRs": [
                    "kubernetes.io/hostname": "moc-lmb6zqozk4m",
                                "f:podCIDR": {},
                                "f:podCIDRs": {
                                    "f:kubernetes.io/hostname": {},
                "podCIDR": "10.244.4.0/24",
                "podCIDRs": [
                    "kubernetes.io/hostname": "moc-wgwhhijxtfv",
                                "f:podCIDR": {},
                                "f:podCIDRs": {
                                    "f:kubernetes.io/hostname": {},
                "podCIDR": "10.244.5.0/24",
                "podCIDRs": [

В этом примере можно увидеть три узла с тремя идентификаторами CIDR, каждый из которых может разместить 254 модуля pod. В документации по масштабированию Kubernetes рекомендуется не превышать 110 модулей pod на узел по соображениям производительности. См. раздел Рекомендации по работе с большими кластерами.

Дополнительные рекомендации

  • Количество IP-адресов для служб Kubernetes за пределами выделенного пула ВИРТУАЛЬНЫх IP-адресов поступают из пула 10.96.0.0/16 адресов. Система использует один из 255 доступных адресов для сервера API Kubernetes.
  • Размер виртуальной машины узла AKS можно задать только при установке при первом запуске Set-AksHciConfig . Его невозможно будет изменить.
  • Вы можете задать размер виртуальных машин уровня управления целевым кластером и подсистемы балансировки нагрузки только во время создания целевого кластера.

Пример масштабирования

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

  • Вы хотите полностью терпеть потерю одного физического узла в кластере Azure Stack HCI.
  • Вы хотите поддерживать обновление целевых кластеров до более новых версий.
  • Необходимо обеспечить высокий уровень доступности узлов уровня управления целевого кластера и узлов подсистемы балансировки нагрузки.
  • Вы хотите зарезервировать часть общей емкости Azure Stack HCI для этих случаев.

Предложения

  • Для обеспечения оптимальной производительности необходимо задать не менее 15 процентов (100/8 = 12,5) емкости кластера, чтобы разрешить перераспределение всех ресурсов с одного физического узла на остальные семь (7) узлов. Эта конфигурация гарантирует, что у вас есть резерв, доступный для обновления или других операций AKS за два дня.

  • Если вы хотите выйти за пределы 200 виртуальных машин для кластера Azure Stack HCI максимального размера 8 (восемь) узлов оборудования, увеличьте размер виртуальной машины узла AKS. Удвоение размера приводит к примерно удвоите количество виртуальных машин, которыми он может управлять. В кластере Azure Stack HCI с 8 узлами можно получить до 8192 виртуальных машин (8 x 1024) на основе рекомендуемых ограничений ресурсов Azure Stack HCI, описанных в разделе Максимальное поддерживаемое оборудование. Вы должны зарезервировать примерно 30 % емкости, что оставляет теоретические ограничения в 5734 виртуальных машин на всех узлах.

    • Standard_D32s_v3 для узла AKS с 32 ядрами и 128 ГБ может поддерживать не более 1600 узлов.

    Примечание

    Так как эта конфигурация не была тщательно протестирована, она требует тщательного подхода и проверки.

  • В таком масштабе может потребоваться разделить среду по крайней мере на 8 целевых кластеров с 200 рабочими узлами в каждом.

  • Чтобы запустить 200 рабочих узлов в одном целевом кластере, можно использовать уровень управления по умолчанию и размер подсистемы балансировки нагрузки. В зависимости от количества модулей pod на узел можно подняться по крайней мере на один размер на уровне управления и использовать Standard_D8s_v3.

  • В зависимости от количества служб Kubernetes, размещенных в каждом целевом кластере, может потребоваться увеличить размер виртуальной машины подсистемы балансировки нагрузки и при создании целевого кластера, чтобы обеспечить высокую производительность и маршрутизацию трафика.

Развертывание AKS, включаемое Arc, распределяет рабочие узлы для каждого пула узлов в целевом кластере по доступным узлам Azure Stack HCI с помощью логики размещения Azure Stack HCI.

Важно!

Размещение узла не сохраняется во время обновления платформы и AKS и будет меняться со временем. Сбой физического узла также повлияет на распределение виртуальных машин между остальными узлами кластера.

Примечание

Не запускайте более четырех целевых кластеров одновременно, если физический кластер уже заполнен на 50 %, так как это может привести к временному состязанию за ресурсы. При большом масштабировании пулов узлов целевого кластера учитывайте доступные физические ресурсы, так как AKS не проверяет доступность ресурсов для параллельно выполняющихся процессов создания и масштабирования. Всегда обеспечьте достаточный резерв для обновления и отработки отказа. Особенно в очень больших средах эти операции при параллельном выполнении могут привести к быстрому исчерпанию ресурсов.

Если вы сомневаетесь, обратитесь за помощью в местный офис Майкрософт или опубликуйте публикацию на форуме сообщества Azure Stack HCI.

Дальнейшие действия