Поделиться через

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

  • Статья

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

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

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

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

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

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

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

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

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

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

Внимание

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

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

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

Размер виртуальной машины ЦП Память (ГБ) Тип GPU Количество ЦП
По умолчанию. 4 4
Стандартный 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

Масштабирование развертывания AKS в Azure Local включает в себя планирование заранее, зная о рабочих нагрузках и целевом использовании кластера. Кроме того, рассмотрим аппаратные ресурсы в базовой инфраструктуре, такие как общее количество ядер ЦП, общая память, хранилище, 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.
  • Вы хотите поддерживать обновление целевых кластеров до более новых версий.
  • Вы хотите обеспечить высокий уровень доступности узлов плоскости управления целевым кластером и узлов подсистемы балансировки нагрузки.
  • Вы хотите зарезервировать часть общей емкости Azure Local для этих случаев.

Предложения

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

  • Если вы хотите выйти за пределы 200-виртуальной машины для максимального размера аппаратного кластера (8) узла Azure, увеличьте размер виртуальной машины узла AKS. Удвоение размера приводит к примерно двойному количеству виртуальных машин, которыми он может управлять. В 8-узлом локальном кластере Azure можно получить до 8 192 (8x1024) виртуальных машин, основанных на ограничениях локальных ресурсов Azure, описанных в спецификациях максимального поддерживаемого оборудования. Вы должны зарезервировать примерно 30 % емкости, что оставляет вас теоретическим ограничением в 5734 виртуальных машин на всех узлах.

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

    Примечание.

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

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

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

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

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

Внимание

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

Примечание.

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

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

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