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

Управление узлами Kubernetes и пулами узлов

Архитектура Kubernetes состоит из двух уровней: плоскости управления и хотя бы одного узла в пуле узлов. В этой статье описывается и сравнивается, как Служба Amazon Elastic Kubernetes (EKS) и Служба Azure Kubernetes (AKS) управляют узлами агентов и рабочими узлами.

Замечание

Эта статья является частью серии статей, которые помогают специалистам, знакомым с Amazon EKS, понять Службу Azure Kubernetes (AKS).

В Amazon EKS и AKS облачная платформа предоставляет уровень плоскости управления и управляет им, а клиент управляет уровнем узлов. На следующей схеме показана связь между плоскостью управления и узлами в архитектуре AKS Kubernetes.

Схема, показывющая плоскость управления и узлы в архитектуре AKS.

Группы управляемых узлов Amazon EKS

Группы управляемых узлов Amazon EKS автоматизируют подготовку и управление жизненным циклом рабочих узлов Amazon Elastic Compute Cloud (EC2) для кластеров Amazon EKS. Пользователи Amazon Web Services (AWS) могут использовать служебную программу командной строки eksctl для создания, обновления или завершения узлов для кластеров EKS. Обновления и завершение работы узлов автоматически устанавливают ограничения и осушают узлы, чтобы поддерживать доступность приложений.

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

Дополнительные сведения см. в разделе "Создание группы управляемых узлов " и обновление группы управляемых узлов.

Вы также можете запускать pod Kubernetes в AWS Fargate. Fargate предоставляет по запросу оптимальную мощность вычислительных ресурсов для контейнеров. Дополнительные сведения см. в разделе "Упрощение управления вычислительными ресурсами".

Карпентер

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

  • Отслеживайте модули pod, которые планировщик Kubernetes не может запланировать из-за ограничений ресурсов.

  • Оцените требования к планированию, такие как запросы ресурсов, селекторы для выбора узлов, правила совместимости и соответствия (tolerations) для нераспределяемых pod.

  • Настройте новые узлы, соответствующие требованиям незапланированных модулей pod.

  • Удалите узлы, если они больше не нужны.

С помощью Karpenter можно определить пулы узлов, которые имеют ограничения на развертывание узлов, такие как таинты, метки, требования (типы экземпляров и зоны), а также ограничения на общий объем развернутых ресурсов. При развертывании рабочих нагрузок необходимо указать различные ограничения на планирование в спецификациях подов. Например, можно указать запросы ресурсов или ограничения, селекторы узлов, аффинности узлов или подов, толерантности и ограничения распределения топологии. Затем Карпентер настраивает узлы правильного размера на основе этих спецификаций.

Перед запуском Karpenter пользователи Amazon EKS в основном зависели от групп автоматического масштабирования Amazon EC2 и автомасштабирования кластера Kubernetes для динамической настройки вычислительной емкости своих кластеров. Вам не нужно создавать десятки групп узлов, чтобы обеспечить гибкость и разнообразие, которое предоставляет Карпентер. В отличие от автомасштабирования кластера Kubernetes, Karpenter меньше зависит от версий Kubernetes и не требует переходов между API AWS и Kubernetes.

Karpenter объединяет обязанности оркестрации экземпляров в одной системе, которая проще, стабильнее и лучше учитывает потребности кластера. Karpenter помогает преодолеть проблемы кластерного автомасштабирования, предоставляя упрощенные способы:

  • Настройте узлы на основе требований к рабочей нагрузке.

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

  • Добейтесь улучшенного планирования подов в большом масштабе за счет быстрого запуска узлов и размещения подов.

По сравнению с группами автоматического масштабирования и группами управляемых узлов Карпентер интегрирует управление масштабированием более тесно с API-интерфейсами Kubernetes. Группы автоматического масштабирования и группы управляемых узлов — это собственные абстракции AWS, которые активируют масштабирование на основе метрик уровня AWS, таких как загрузка ЦП EC2. Несмотря на то что автомасштабирование кластера соединяет абстракции Kubernetes с абстракциями AWS, это происходит в ущерб определенной гибкости, например, планирования для конкретной зоны доступности.

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

Контейнеры Каты

Kata Container — это проект с открытым исходным кодом, предоставляющий высокозащищенную среду выполнения контейнеров. Он объединяет легковесный характер контейнеров с преимуществами безопасности виртуальных машин. Контейнеры Kata повышают изоляцию рабочей нагрузки и безопасность, запуская каждый контейнер с другой гостевой операционной системой, в отличие от традиционных контейнеров, которые совместно используют одно ядро Linux между рабочими нагрузками. Контейнеры Kata выполняют контейнеры в виртуальной машине, совместимой с Open Container Initiative (OCI), которая обеспечивает строгую изоляцию между контейнерами на одном и том же хост-компьютере. Контейнеры Kata предоставляют следующие функции:

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

  • Улучшенная безопасность: Использование технологии виртуальных машин обеспечивает дополнительный уровень безопасности, что снижает риск разбиения контейнеров.

  • Совместимость с отраслевыми стандартами: Kata Container интегрируется с отраслевыми средствами, такими как формат контейнера OCI и Интерфейс среды выполнения контейнеров Kubernetes.

  • Поддержка нескольких архитектур и гипервизоров: Kata Containers поддерживает архитектуры AMD64 и ARM, и его можно использовать с гипервизорами, такими как Облачный гипервизор и Firecracker.

  • Простое развертывание и управление: Kata Containers упрощает оркестрацию рабочей нагрузки, так как она использует систему оркестрации Kubernetes.

Чтобы настроить и запустить контейнеры Kata в AWS, настройте кластер Amazon EKS для использования Firecracker. Firecracker — это технология виртуализации с открытым исходным кодом из Amazon, которая помогает создавать безопасные, мультитенантные контейнеры и службы на основе функций. Используйте Firecracker для развертывания рабочих нагрузок в упрощенных виртуальных машинах, называемых микроВМ, которые обеспечивают повышенную безопасность и изоляцию рабочих нагрузок по сравнению с традиционными виртуальными машинами. МикроВМ также повышают скорость и эффективность ресурсов контейнеров. Выполните действия, чтобы запустить контейнеры Kata в AWS EKS.

Выделенные хосты

При использовании Amazon EKS для развертывания и запуска контейнеров можно запускать контейнеры на выделенных узлах Amazon EC2. Однако эта функция доступна только для самостоятельно управляемых групп узлов. Поэтому необходимо вручную создать шаблон запуска и группы автоматического масштабирования. Затем зарегистрируйте выделенные узлы, запустите шаблон и группы автоматического масштабирования в кластере EKS. Чтобы создать эти ресурсы, используйте тот же метод, что и общее автоматическое масштабирование EC2.

Дополнительные сведения об использовании AWS EKS для запуска контейнеров на выделенных узлах EC2 см. в следующих ресурсах:

Узлы и пулы узлов AKS

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

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

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

AKS объединяет узлы одной конфигурации в пулы узлов виртуальных машин, выполняющих рабочие нагрузки AKS. Используйте системные пулы узлов для размещения критически важных системных подов, таких как CoreDNS. Используйте пулы узлов пользователей для размещения модулей pod рабочей нагрузки. Если требуется только один пул нод в кластере AKS, например в среде разработки, можно размещать Pod'ы приложений в системном пуле нод.

Схема с одним узлом Kubernetes.

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

Каждый узел агента в пуле системных или пользовательских узлов по сути является виртуальной машиной. Масштабируемые наборы виртуальных машин Azure настраивают виртуальные машины, а кластер AKS управляет ими. Дополнительные сведения см. в разделе "Пулы узлов".

Вы можете определить начальное число и размер рабочих узлов при создании кластера AKS или при добавлении новых узлов и пулов узлов в существующий кластер AKS. Если размер виртуальной машины не указан, размер по умолчанию Standard_D2s_v3 для пулов узлов Windows и Standard_DS2_v2 для пулов узлов Linux.

Это важно

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

Создание пула узлов

При создании пула узлов связанный масштабируемый набор виртуальных машин создается в группе ресурсов узла. Эта группа ресурсов Azure содержит все ресурсы инфраструктуры для кластера AKS. К этим ресурсам относятся узлы Kubernetes, ресурсы виртуальной сети, управляемые удостоверения и хранилище.

По умолчанию группа ресурсов узла имеет такое имя MC_<resourcegroupname>_<clustername>_<location>. AKS автоматически удаляет группу ресурсов узла при удалении кластера. Эту группу ресурсов следует использовать только для ресурсов, использующих жизненный цикл кластера.

Дополнительные сведения см. в статье "Создание пулов узлов для кластера в AKS".

Добавление пула узлов

Чтобы добавить пул узлов в новый или существующий кластер AKS, используйте портал Azure, Azure CLI или REST API AKS. Вы также можете использовать инфраструктуру как код (IaC), такие как Bicep, шаблоны Azure Resource Manager или Terraform.

В следующем примере кода используется команда Azure CLI az aks nodepool add для добавления пула узлов под названием mynodepool, который содержит три узла. Он добавляет пул узлов в существующий кластер AKS, который называется myAKSCluster в группу ресурсов myResourceGroup.

az aks nodepool add \
      --resource-group myResourceGroup \
      --cluster-name myAKSCluster \
      --node-vm-size Standard_D8ds_v4 \
      --name mynodepool \
      --node-count 3

Пулы точечных узлов

Пул точечных узлов — это пул узлов, поддерживаемый точечным масштабируемым набором виртуальных машин . Используйте точечные виртуальные машины для узлов в кластере AKS, чтобы воспользоваться неиспользуемой емкостью Azure по сниженной стоимости. Объем доступной неиспользуемой емкости зависит от факторов, таких как размер узла, регион и время дня.

При развертывании пула точечных узлов Azure выделяет точечные узлы, если емкость доступна. Но у точечных узлов нет соглашения об уровне обслуживания (SLA). Точечный масштабируемый набор, поддерживающий пул точечных узлов, развертывается в одном домене сбоя и не предоставляет гарантии высокой доступности. Когда Azure нуждается в емкости, инфраструктура Azure вытесняет точечные узлы. Вы получаете уведомление до 30 секунд до вытеснения. Пул точечных узлов нельзя использовать в качестве пула узлов по умолчанию кластера. Используйте пул точечных узлов только в качестве дополнительного пула.

Используйте точечные узлы для рабочих нагрузок, которые могут обрабатывать прерывания, ранние завершения или вытеснения. Например, запланируйте в пуле точечных узлов задания пакетной обработки, среды разработки и тестирования и большие вычислительные рабочие нагрузки. Дополнительные сведения см. в разделе Об ограничениях экземпляров Spot.

az aks nodepool add Следующая команда добавляет пул точечных узлов в существующий кластер с включенным автомасштабированием.

  az aks nodepool add \
      --resource-group myResourceGroup \
      --cluster-name myAKSCluster \
      --name myspotnodepool \
      --node-vm-size Standard_D8ds_v4 \
      --priority Spot \
      --eviction-policy Delete \
      --spot-max-price -1 \
      --enable-cluster-autoscaler \
      --min-count 1 \
      --max-count 3 \
      --no-wait

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

Временные диски операционной системы

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

В отличие от этого, временные диски ОС хранятся только на хост-компьютере, например на временном диске. Кроме того, они обеспечивают более низкую задержку чтения и записи, а также ускоряют масштабирование узлов и обновление кластера. Как и временный диск, цена на виртуальную машину включает временный диск ОС, поэтому не взимается дополнительная плата за хранение.

Это важно

Если вы явно не запрашиваете управляемые диски для ОС, AKS по умолчанию использует эфемерную ОС, если это возможно для заданной конфигурации пула узлов.

Чтобы использовать эфемерную ОС, диск ОС должен помещаться в кэш виртуальной машины. Документация по виртуальным машинам Azure показывает размер кэша виртуальных машин в скобках рядом с пропускной способностью ввода-вывода (ввода-вывода) в виде размера кэша в гибибайтах (GiB).

Например, виртуальная машина AKS с размером по умолчанию Standard_DS2_v2 и диском ОС объёмом 100 ГБ поддерживает эфемерную операционную систему, но имеет кэш объёмом всего 86 ГБ. Эта конфигурация по умолчанию использует управляемые диски, если вы явно не указываете в противном случае. Если вы явно запрашиваете эфемерную ОС для этого размера виртуальной машины, вы получите ошибку проверки.

Если вы запрашиваете ту же виртуальную машину Standard_DS2_v2 с диском ОС размером 60 ГБ, по умолчанию вы получите эфемерную ОС. Запрошенный размер ОС размером 60 ГБ меньше максимального размера кэша в 86 ГБ.

Standard_D8s_v3 с диском ОС размером 100 ГБ поддерживает эфемерную ОС и имеет размер кэша размером 200 ГБ. Если тип диска ОС не указан, пул узлов по умолчанию получает эфемерную ОС.

az aks nodepool add Следующая команда показывает, как добавить новый пул узлов в существующий кластер с временным диском ОС. Параметр --node-osdisk-type задает тип Ephemeralдиска ОС, а --node-osdisk-size параметр определяет размер диска ОС.

  az aks nodepool add \
      --resource-group myResourceGroup \
      --cluster-name myAKSCluster \
      --name mynewnodepool \
      --node-vm-size Standard_D8ds_v4 \
      --node-osdisk-type Ephemeral \
      --node-osdisk-size 48

Дополнительные сведения см. в разделе "Временный диск ОС".

Пулы узлов виртуальных машин Azure в AKS

Каждая управляемая группа узлов в EKS поддерживается группой автоматического масштабирования Amazon EC2 , управляемой Amazon EKS. Эта интеграция позволяет EKS автоматически настраивать и масштабировать экземпляры EC2 в группе узлов.

Группы автоматического масштабирования можно настроить для поддержки нескольких типов экземпляров EC2, но нельзя указать, сколько узлов нужно создать или масштабировать для каждого типа экземпляра. Вместо этого EKS управляет масштабированием группы узлов на основе требуемой конфигурации и политик. Этот подход упрощает и автоматизирует процесс управления для группы узлов, чтобы выбрать типы экземпляров EC2, которые соответствуют вашим требованиям к рабочей нагрузке. Вы также можете запустить самостоятельно управляемые узлы Amazon Linux с помощью eksctl средства командной строки или консоли управления AWS.

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

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

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

При создании пула узлов виртуальных машин требуется по крайней мере один ManualScaleProfile в ScaleProfile. Можно создать несколько профилей масштабирования вручную для одного пула узлов виртуальных машин.

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

  • Гибкость: Спецификации узлов можно обновить в соответствии с вашими рабочими нагрузками и потребностями.

  • Точно настроенный элемент управления: Элементы управления на уровне одного узла помогают указать и объединить узлы различных спецификаций для повышения согласованности.

  • Эффективность: Чтобы упростить операционные требования, можно уменьшить объем памяти узла для кластера.

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

В следующей таблице сравниваются пулы узлов виртуальных машин со стандартными пулами узлов масштабируемых наборов виртуальных машин .

Тип пула узлов Возможности
пул узлов виртуальных машин Вы можете добавлять, удалять или обновлять узлы в пуле узлов. Типы виртуальных машин могут быть любой виртуальной машиной одного типа семейства, например серии D или серии A.
Масштабируемый пул узлов виртуальных машин Вы можете добавлять или удалять узлы с одинаковым размером и типом в пуле узлов. При добавлении нового размера виртуальной машины в кластер необходимо создать пул узлов.

Пулы узлов виртуальных машин имеют следующие ограничения:

  • Автомасштабирование кластера не поддерживается.
  • InfiniBand недоступна.
  • Пулы узлов Windows не поддерживаются.
  • Эта функция недоступна на портале Azure. Используйте Azure CLI или REST API для выполнения операций создания, чтения, обновления и удаления (CRUD) или управления пулом.
  • Снимок пула узлов не поддерживается.
  • Все размеры виртуальных машин в пуле узлов должны быть из одного семейства виртуальных машин. Например, нельзя объединить тип виртуальной машины серии N с типом виртуальной машины серии D в одном пуле узлов.
  • Пулы узлов виртуальных машин позволяют использовать до пяти разных размеров виртуальных машин на пул узлов.

Виртуальные узлы

Виртуальные узлы можно использовать для быстрого масштабирования рабочих нагрузок приложений в кластере AKS. Виртуальные узлы обеспечивают быструю подготовку pod, и вы оплачиваете только за время выполнения посекундно. Вам не нужно ждать автомасштабирования кластера для развертывания новых рабочих узлов, чтобы запускать больше реплик подов. Поддержка виртуальных узлов доступна только для контейнеров и узлов Linux. Надстройка виртуальных узлов для AKS основана на проекте с открытым исходным кодом Virtual Kubelet.

Функции виртуального узла зависят от Экземпляры контейнеров Azure. Дополнительные сведения см. в статье "Создание и настройка кластера AKS для использования виртуальных узлов".

Тейнты, метки и теги

При создании пула узлов можно добавить таинты и метки Kubernetes и теги Azure. Каждая отметка, метка или тег применяются ко всем узлам в этом пуле узлов.

Чтобы создать пул узлов, имеющий запятую, можно использовать az aks nodepool add команду с параметром --node-taints . Чтобы пометить узлы в пуле узлов, используйте --labels параметр и укажите список меток, как показано в следующем коде:

  az aks nodepool add \
      --resource-group myResourceGroup \
      --cluster-name myAKSCluster \
      --name mynodepool \
      --node-vm-size Standard_NC6 \
      --node-taints sku=gpu:NoSchedule \
      --labels dept=IT costcenter=9999

Дополнительные сведения см. в разделе Указание запятнанности, метки или тега для пула узлов.

Зарезервированные системные метки

Amazon EKS добавляет автоматические метки Kubernetes ко всем узлам в группе управляемых узлов, например eks.amazonaws.com/capacityType, которая указывает тип емкости. AKS также автоматически добавляет системные ярлыки к узлам агента.

Следующие префиксы зарезервированы для использования AKS и не могут использоваться для узлов:

  • kubernetes.azure.com/
  • kubernetes.io/

Другие зарезервированные префиксы см. в разделе "Известные метки Kubernetes", "заметки" и "Запятая".

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

В столбце использования виртуального узла:

  • N/A означает, что свойство не применяется к виртуальным узлам, так как для него требуется изменить узел.
  • То же самое означает, что ожидаемые значения одинаковы для пула виртуальных узлов и стандартного пула узлов.
  • Virtual заменяет значения SKU виртуальных машин, поскольку поды виртуальных узлов не раскрывают базовые виртуальные машины.
  • Версия виртуального узла относится к текущей версии виртуального выпуска соединителя Kubelet-ACI.
  • Имя подсети виртуального узла — это подсеть, которая развертывает pods виртуального узла в контейнерных экземплярах.
  • Виртуальная сеть виртуального узла — это виртуальная сеть , содержащая подсеть виртуального узла.
Этикетка Ценность Пример или параметры Использование виртуальных узлов
kubernetes.azure.com/agentpool <agent pool name> nodepool1 Тот же
kubernetes.io/arch amd64 runtime.GOARCH Не применимо
kubernetes.io/os <OS type> Linux или Windows Linux
node.kubernetes.io/instance-type <VM size> Standard_NC6 Virtual
topology.kubernetes.io/region <Azure region> westus2 Тот же
topology.kubernetes.io/zone <Azure zone> 0 Тот же
kubernetes.azure.com/cluster <MC_RgName> MC_aks_myAKSCluster_westus2 Тот же
kubernetes.azure.com/mode <mode> User или System User
kubernetes.azure.com/role agent Agent Тот же
kubernetes.azure.com/scalesetpriority <scale set priority> Spot или Regular Не применимо
kubernetes.io/hostname <hostname> aks-nodepool-00000000-vmss000000 Тот же
kubernetes.azure.com/storageprofile <OS disk storage profile> Managed Не применимо
kubernetes.azure.com/storagetier <OS disk storage tier> Premium_LRS Не применимо
kubernetes.azure.com/instance-sku <SKU family> Standard_N Virtual
kubernetes.azure.com/node-image-version <VHD version> AKSUbuntu-1804-2020.03.05 Версия виртуального узла
kubernetes.azure.com/subnet <nodepool subnet name> subnetName Имя подсети виртуального узла
kubernetes.azure.com/vnet <nodepool virtual network name> vnetName Виртуальная сеть виртуального узла
kubernetes.azure.com/ppg <nodepool ppg name> ppgName Не применимо
kubernetes.azure.com/encrypted-set <nodepool encrypted-set name> encrypted-set-name Не применимо
kubernetes.azure.com/accelerator <accelerator> nvidia Не применимо
kubernetes.azure.com/fips_enabled <fips enabled> True Не применимо
kubernetes.azure.com/os-sku <os/sku> См. статью "Создание или обновление SKU ОС" Linux артикул

пулы узлов Windows;

С помощью AKS можно создавать пулы узлов контейнеров Windows Server и использовать их с помощью подключаемого модуля сетевого интерфейса контейнеров Azure . Сведения о планировании необходимых диапазонов подсети и рекомендаций по сети см. в статье "Настройка сетевого интерфейса контейнеров Azure".

az aks nodepool add Следующая команда добавляет пул узлов, на котором выполняются контейнеры Windows Server:

  az aks nodepool add \
      --resource-group myResourceGroup \
      --cluster-name myAKSCluster \
      --name mywindowsnodepool \
      --node-vm-size Standard_D8ds_v4 \
      --os-type Windows \
      --node-count 1

Предыдущая команда использует подсеть по умолчанию в виртуальной сети кластера AKS. Дополнительные сведения о создании кластера AKS с пулом узлов Windows см. в статье "Создание контейнера Windows Server в AKS".

Рекомендации по пулу узлов

Следующие рекомендации и ограничения применяются при создании пулов отдельных или нескольких узлов и управлении ими.

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

  • Системные пулы должны содержать по крайней мере один узел. Вы можете удалить пул системных узлов, если у вас есть другой пул системных узлов, который будет использоваться в кластере AKS. Пулы узлов пользователей могут содержать ноль или больше узлов.

  • Размер виртуальной машины для пула узлов нельзя изменить после создания.

  • Для нескольких пулов узлов кластер AKS должен использовать балансировщики нагрузки Standard SKU. Базовые подсистемы балансировки нагрузки SKU не поддерживают несколько пулов узлов.

  • Все пулы узлов кластера должны находиться в одной виртуальной сети, а все подсети, назначенные пулу узлов, должны находиться в одной виртуальной сети.

  • Если при создании кластера создается несколько пулов узлов, версии Kubernetes для всех пулов узлов должны соответствовать версии уровня управления. Чтобы обновить версии после настройки кластера, используйте операции с пулом узлов.

Масштабирование пулов узлов

По мере изменения рабочей нагрузки приложения может потребоваться изменить количество узлов в пуле узлов. Чтобы вручную масштабировать количество узлов вверх или вниз, используйте команду az aks nodepool scale . В следующем примере число узлов в mynodepool увеличивается до пяти:

az aks nodepool scale \
    --resource-group myResourceGroup \
    --cluster-name myAKSCluster \
    --name mynodepool \
    --node-count 5

Автоматическое масштабирование пулов узлов

AKS поддерживает автоматическое масштабирование пулов узлов с помощью автомасштабирования кластера. Включите эту функцию в каждом пуле узлов и определите минимальное и максимальное количество узлов.

az aks nodepool add Команда добавляет новый пул узлов под названием mynodepool в существующий кластер. Параметр --enable-cluster-autoscaler включает автомасштабирование кластера в новом пуле узлов. Параметры --min-count и --max-count указывают минимальное и максимальное количество узлов в пуле.

  az aks nodepool add \
  --resource-group myResourceGroup \
  --cluster-name myAKSCluster \
  --name mynewnodepool \
  --node-vm-size Standard_D8ds_v4 \
  --enable-cluster-autoscaler \
  --min-count 1 \
  --max-count 5

Следующая команда az aks nodepool update обновляет минимальное количество узлов от одного до трех для пула mynewnodepool узлов.

  az aks nodepool update \
  --resource-group myResourceGroup \
  --cluster-name myAKSCluster \
  --name mynewnodepool \
  --update-cluster-autoscaler \
  --min-count 1 \
  --max-count 3

Чтобы отключить автомасштабирование кластера, используйте az aks nodepool update команду с параметром --disable-cluster-autoscaler .

  az aks nodepool update \
  --resource-group myResourceGroup \
  --cluster-name myAKSCluster \
  --name mynodepool \
  --disable-cluster-autoscaler

Чтобы повторно включить автомасштабирование кластера в существующем кластере, используйте az aks nodepool update команду и укажите параметры --enable-cluster-autoscaler, --min-count и --max-count.

Дополнительные сведения об использовании автомасштабирования кластера для отдельных пулов узлов см. в статье Об использовании автомасштабирования кластера в AKS.

Песочница Pod

Чтобы легко настроить и запустить контейнеры Kata в AKS в качестве полностью управляемого решения, используйте песочницу Pod. Функция «Подовая песочница» в AKS создает границу изоляции между приложением контейнера и общими ресурсами ядра и вычислительных ресурсов хоста контейнера, такими как ЦП, память и сеть.

Песочница Pod дополняет другие меры безопасности или средства управления защитой данных, чтобы помочь рабочим нагрузкам арендаторов защитить конфиденциальную информацию и соответствовать нормативным требованиям, отраслевым стандартам или требованиям управления. К этим требованиям относятся стандарт безопасности данных отрасли оплаты (PCI DSS), Международная организация по стандартизации (ISO) 27001, а также закон о переносимости и подотчетности медицинского страхования (HIPAA).

Развёртывайте приложения в отдельных кластерах или пулах узлов, чтобы изолировать нагрузки арендаторов разных команд или заказчиков. Вы можете использовать несколько кластеров и пулов узлов, если для вашей организации или программного обеспечения в качестве службы (SaaS) требуется их. Но некоторые сценарии используют один кластер с общими пулами узлов виртуальной машины. Например, можно использовать один кластер для запуска ненадежных и доверенных подов на одном узле или располагать DaemonSets и привилегированные контейнеры на одном узле для ускорения локального взаимодействия и функциональной группировки.

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

Песочница Pod основана на контейнерах Kata, работающих на контейнерном хосте Azure Linux для стека AKS, чтобы обеспечить аппаратно гарантированную изоляцию. Контейнеры Kata в AKS основаны на гипервизоре Azure, защищенном безопасностью. Она обеспечивает изоляцию для каждого модуля pod с помощью вложенной упрощенной виртуальной машины Kata, которая использует ресурсы из родительского узла виртуальной машины. В этой модели каждый pod Kata получает собственное ядро в отдельной гостевой виртуальной машине Kata. Эта модель используется для размещения нескольких контейнеров Kata на одной гостевой виртуальной машине, продолжая запускать контейнеры на родительской виртуальной машине. Эта модель обеспечивает сильную границу изоляции в общем кластере AKS.

Дополнительные сведения см. в статье "Поддержка изолированных контейнеров для виртуальной машины Kata" в AKS для песочницы Pod.

Выделенный узел Azure

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

Используйте выделенный узел с AKS, чтобы обеспечить следующие преимущества:

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

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

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

Карпентер

Karpenter — это проект управления жизненным циклом узлов с открытым кодом, созданный для Kubernetes. Добавьте Karpenter в кластер Kubernetes, чтобы повысить эффективность и стоимость выполнения рабочих нагрузок в этом кластере. Карпентер следит за подами, которые планировщик Kubernetes помечает как неподдающиеся планированию. Он также динамически подготавливает узлы и управляет ими, которые могут соответствовать требованиям pod.

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

Например, может потребоваться, чтобы некоторые приложения клиентов выполнялись в пулах узлов, оптимизированных для GPU, и другие для запуска в пулах узлов, оптимизированных для памяти. Если для вашего приложения требуется низкая задержка при хранении, вы можете использовать Karpenter, чтобы указать, что pod нуждается в узле, который работает в определённой зоне доступности. Затем вы можете разместить хранилище и уровень приложений.

AKS включает автоматическую подготовку узлов в кластерах AKS с помощью Karpenter. Большинству пользователей следует использовать режим автоматического предоставления узлов, чтобы включить Karpenter в качестве управляемой надстройки. Дополнительные сведения см. в разделе автоматической подготовки узла. Если вам нужна более расширенная настройка, вы можете самостоятельно разместить Karpenter. Дополнительные сведения см. в разделе AKS Karpenter Provider.

Конфиденциальные виртуальные машины

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

Платформа AWS поддерживает конфиденциальные вычисления через анклавы Nitro, доступные в экземплярах EC2 и Amazon EKS. Экземпляры Amazon EC2 также поддерживают AMD Secure Encrypted Virtualization Secure Nested Paging (SEV-SNP). Репозиторий аттестации среды выполнения GitHub предоставляет артефакты для создания и развертывания образа Amazon Machine для EKS с поддержкой AMD SEV-SNP.

Azure предоставляет клиентам конфиденциальные виртуальные машины для обеспечения строгой изоляции, конфиденциальности и безопасности в кластере AKS. Эти конфиденциальные виртуальные машины используют надежную среду выполнения на основе оборудования. В частности, конфиденциальные виртуальные машины Azure используют технологию AMD SEV-SNP. Эта технология ограничивает доступ гипервизора и другого кода управления узлом к памяти и состоянию виртуальной машины. Используйте этот подход для добавления дополнительного уровня защиты и защиты от доступа к операторам. Дополнительные сведения см. в статье Об использовании конфиденциальных виртуальных машин в кластере AKS и обзоре конфиденциальных виртуальных машин в Azure.

Федеральные стандарты информационных процессов

Федеральные стандарты обработки информации (FIPS) 140-3 — это стандарт правительства США, определяющий минимальные требования к безопасности для криптографических модулей в продуктах и системах информационных технологий. Включите соответствие FIPS пулам узлов AKS для повышения изоляции, конфиденциальности и безопасности рабочих нагрузок клиента. Соответствие FIPS помогает обеспечить использование проверенных криптографических модулей для шифрования, хэширования и других операций, связанных с безопасностью. Используйте пулы узлов AKS с поддержкой FIPS, чтобы использовать надежные криптографические алгоритмы и механизмы, которые помогают соответствовать нормативным и отраслевым требованиям. Дополнительные сведения о том, как укрепить безопасность мультитенантных сред AKS, см. в разделе "Включение FIPS для пулов узлов AKS".

Шифрование на основе узла

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

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

В AKS диски ОС и диски данных используют шифрование на стороне сервера с помощью ключей, управляемых платформой, по умолчанию. Кеши этих дисков шифруются в состоянии покоя с помощью ключей, управляемых платформой. Вы можете использовать собственный ключ шифрования ключа для шифрования ключа защиты данных. Этот метод называется шифрованием конверта или оболочкой. Указанный ключ шифрования также шифрует кэш для дисков ОС и дисков данных.

Шифрование на основе узла добавляет уровень безопасности для мультитенантных сред. Данные каждого арендатора на диске ОС и кэшах дисков данных шифруются в состоянии покоя с помощью ключей, управляемых клиентом или платформой, в зависимости от выбора типа шифрования дисков. Дополнительные сведения см. в следующих ресурсах:

Обновления и улучшения

Azure периодически обновляет свою платформу размещения виртуальных машин, чтобы повысить надежность, производительность и безопасность. Эти обновления охватывают такие процессы, как установка исправлений программных компонентов в среде хостинга, модернизация основных сетевых компонентов или вывод из эксплуатации оборудования. Дополнительные сведения см. в разделе "Обслуживание виртуальных машин в Azure".

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

Если для обновления требуется перезагрузка, Azure предоставляет уведомление и временной интервал, в течение которого можно начать обновление. Период самостоятельного обслуживания для хост-компьютеров обычно составляет 35 дней, если обновление не является срочным.

Для обновления виртуальных машин можно использовать плановое обслуживание. Управление уведомлениями о плановом обслуживании с помощью Azure CLI, Azure PowerShell или портала Azure. Плановое обслуживание определяет, используется ли функция автоматического обновления кластера и планируется ли обновление во время периода обслуживания автоматически. Дополнительные сведения см. в статье "Использование планового обслуживания для планирования периодов обслуживания для кластера AKS " и команды az aks maintenanceconfiguration.

Обновления Kubernetes

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

По умолчанию AKS настраивает обновление для всплесков с использованием одного дополнительного узла. Значение по умолчанию для max-surge параметров сводит к минимуму нарушения рабочей нагрузки. Эта конфигурация создает дополнительный узел для замены старых версий узлов перед оцеплением или очисткой существующих приложений. Вы можете настроить max-surge значение для пула узлов, чтобы оптимизировать компромисс между скоростью обновления и прерыванием обновления. max-surge Более высокое значение увеличивает скорость процесса обновления, но большое значение может max-surge привести к сбоям во время процесса обновления.

Например, max-surge значение 100% обеспечивает самый быстрый процесс обновления путем удвоения количества узлов. Но это значение также высвобождает все узлы в пуле узлов одновременно. Вы можете использовать это высокое значение для тестирования, но для пулов рабочих узлов используется max-surge параметр 33%.

AKS принимает целочисленные и процентные значения для max-surge значения. Целое число, например 5 , указывает на пять дополнительных узлов для всплеска. Вы можете задать значение max-surge процента от 1%100%до , округленное до ближайшего количества узлов. Значение, указывающее 50% значение всплеска в половину текущего количества узлов в пуле.

Во время обновления вы можете установить значение max-surge с минимальным значением 1 и максимальным значением, равным количеству узлов в пуле. Можно задать более крупные значения, но максимальное количество узлов для max-surge не может превышать количество узлов в пуле.

Это важно

Для операций обновления, связанных с увеличением нагрузки на узлы, требуется достаточно квоты подписки для запрошенного max-surge количества. Например, кластер с пятью пулами узлов, каждый из которых имеет четыре узла, имеет в общей сложности 20 узлов. Если каждый пул узлов имеет max-surge значение 50%, для завершения обновления требуются дополнительные вычислительные ресурсы и квота IP-адресов в 10 узлов, или по два узла на каждый из пяти пулов.

Если вы используете сетевой интерфейс контейнеров Azure, убедитесь, что в подсети достаточно IP-адресов , чтобы соответствовать требованиям ДЛЯ AKS.

Обновление пулов узлов

Чтобы просмотреть доступные обновления, используйте az aks get-upgrades.

az aks get-upgrades --resource-group <myResourceGroup> --name <myAKSCluster>

Чтобы просмотреть состояние пулов узлов, используйте az aks nodepool list.

  az aks nodepool list -g <myResourceGroup> --cluster-name <myAKSCluster>

Чтобы обновить пул одного узла, используйте az aks nodepool upgrade.

  az aks nodepool upgrade \
      --resource-group <myResourceGroup> \
      --cluster-name <myAKSCluster> \
      --name <mynodepool> \
      --kubernetes-version <KUBERNETES_VERSION>

Дополнительные сведения см. в следующих ресурсах:

Рекомендации по обновлению

При обновлении версии Kubernetes в кластере AKS рекомендуется использовать следующие рекомендации.

  • Необходимо обновить все пулы узлов в кластере AKS до той же версии Kubernetes. Поведение по умолчанию az aks upgrade обновляет все пулы узлов и контрольную плоскость.

  • Вручную выполните обновления или настройте канал автоматического обновления в кластере. Если вы используете плановое обслуживание для исправления виртуальных машин, автоматическое обновление также начинается во время указанного периода обслуживания. Дополнительные сведения см. в статье Обновление кластера AKS.

  • Команда az aks upgrade с --control-plane-only флагом обновляет плоскость управления кластером и не изменяет связанные пулы узлов в кластере. Чтобы обновить отдельные пулы узлов, укажите целевой пул узлов и версию Kubernetes в команде az aks nodepool upgrade .

  • Обновление кластера AKS инициирует вывод узлов из эксплуатации и освобождение их. Если у вас доступна недостаточная квота вычислений, обновление может завершиться ошибкой. Дополнительные сведения см. в разделе Увеличение региональных квот виртуальных ЦП .

  • max-surge Настройте параметр в зависимости от ваших потребностей. Используйте целое или процентное значение. Для пулов рабочих узлов используйте max-surge параметр 33%. Для получения дополнительной информации смотрите Настройка обновления узлового скачка.

  • При обновлении кластера AKS, использующего сеть сетевого интерфейса контейнеров Azure, убедитесь, что подсеть имеет достаточно доступных частных IP-адресов для дополнительных узлов, создаваемых max-surge параметрами. Дополнительные сведения см. в разделе "Настройка сетевых интерфейсов контейнеров Azure" в AKS.

  • Если пулы узлов кластера охватывают несколько зон доступности в регионе, процесс обновления может временно создать конфигурацию небалансированных зон. Дополнительные сведения см. в разделе Пулы узлов, охватывающие несколько зон доступности.

Соавторы

Корпорация Майкрософт поддерживает эту статью. Следующие авторы написали эту статью.

Основные авторы:

Другие участники:

Чтобы просмотреть неопубликованные профили LinkedIn, войдите в LinkedIn.

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