Рекомендации по основным функциям планировщика в "Службе Azure Kubernetes" (AKS)

При управлении кластерами в Cлужбе Azure Kubernetes (AKS) часто возникает необходимость изолировать команды и рабочие нагрузки. Планировщик Kubernetes позволяет вам контролировать распределение вычислительных ресурсов или ограничивать влияние событий обслуживания.

В этой статье с рекомендациями главное внимание уделяется основным возможностям планирования Kubernetes для операторов кластера. В этой статье вы узнаете, как:

Применение квот ресурсов

Руководство по лучшим практикам

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

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

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

• Вычислительные ресурсы, например ЦП, память и GPU.
• Ресурсы хранения, включая общее количество томов или объем дискового пространства для данного класса хранения.
• Число объектов, таких как максимальное количество секретов, служб или заданий, которые могут быть созданы.

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

При определении квот, все поды, созданные в пределах пространства имён, должны содержать пределы или запросы на ресурсы в своих спецификациях. Если они не содержат таких значений, можно отклонить развертывание. Вместо этого вы можете настроить запросы по умолчанию и ограничения для пространства имен.

В следующем примере манифест YAML с именем dev-app-team-quotas.yaml устанавливает жесткое ограничение (максимальные значения составляют 10 для ЦП, 20Gi для памяти и 10 для pod):

apiVersion: v1
kind: ResourceQuota
metadata:
  name: dev-app-team
spec:
  hard:
    cpu: "10"
    memory: 20Gi
    pods: "10"

Эта квота ресурсов может применяться путем указания пространства имен, например dev-apps:

kubectl apply -f dev-app-team-quotas.yaml --namespace dev-apps

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

Дополнительные сведения о доступных объектах ресурсов, областях и приоритетах см. в разделе Квоты ресурсов в Kubernetes.

Планирование доступности с помощью бюджетов нарушений работы pod

Рекомендации по наилучшей практике

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

Существует два события прерывания работы, из-за которых удаляются pod:

Непреднамеренные прерывания работы

Непреднамеренные прерывания работы — это события, которые обычно неподконтрольны оператору кластера или владельцу приложения. Включить:

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

Непреднамеренные прерывания работы могут быть уменьшены за счет:

• Использование нескольких реплик ваших pod в процессе развертывания.
• Запуск нескольких узлов в кластере AKS.

Преднамеренные прерывания работы

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

• Обновления кластера
• Обновленный шаблон развертывания
• Случайное удаление пода

Kubernetes предоставляет pod disruption budgets для добровольных сбоев, позволяя планировать, как развертывания или наборы реплик реагируют при возникновении события добровольного сбоя. Используя бюджеты неработоспособности pod, операторы кластера могут определить минимальное количество доступных или максимальное количество недоступных ресурсов.

Если вы обновляете кластер или обновляете шаблон развертывания, планировщик Kubernetes будет планировать дополнительные pod на других узлах, прежде чем разрешить преднамеренное прерывание работы. Планировщик ожидает перезагрузки узла до тех пор, пока определенное количество pod не будет успешно запланировано на других узлах кластера.

Давайте рассмотрим в качестве примера набор реплик с пятью подами, где запущен NGINX. Поды в наборе реплик имеют назначенную метку app: nginx-frontend. Во время события преднамеренного прерывания, например обновления кластера, необходимо убедиться, что по крайней мере три pod продолжают работать. Следующий манифест YAML для объекта PodDisruptionBudget определяет такие требования:

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
   name: nginx-pdb
spec:
   minAvailable: 3
   selector:
    matchLabels:
      app: nginx-frontend

Можно также определить процент, например 60%, что позволит автоматически компенсировать масштабирование набора реплик за счет увеличения количества подов.

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

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
   name: nginx-pdb
spec:
   maxUnavailable: 2
   selector:
    matchLabels:
      app: nginx-frontend

После определения бюджета неработоспособности pod нужно создать его в кластере AKS, как и в случае с любым другим объектом Kubernetes:

kubectl apply -f nginx-pdb.yaml

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

Дополнительные сведения об использовании бюджетов сбоев для pod см. в статье Определение бюджета сбоев для вашего приложения.

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

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

• Мультитенантность и изоляция кластера
• Дополнительные функции планировщика Kubernetes
• Проверка подлинности и авторизация