Рекомендации по основным функциям планировщика в "Службе Azure Kubernetes" (AKS)
При управлении кластерами в Cлужбе Azure Kubernetes (AKS) часто возникает необходимость изолировать команды и рабочие нагрузки. Планировщик Kubernetes позволяет вам контролировать распределение вычислительных ресурсов или ограничивать влияние событий обслуживания.
В этой статье с рекомендациями главное внимание уделяется основным возможностям планирования Kubernetes для операторов кластера. Вы узнаете, как выполнять следующие задачи:
- Использование квот ресурсов для предоставления фиксированного объема ресурсов для команд или рабочих нагрузок.
- Ограничение влияния запланированного обслуживания с помощью бюджетов неработоспособности pod.
Применение квот ресурсов
Общие рекомендации
Планируйте и применяйте квоты ресурсов на уровне пространства имен. Если pod не определяют запросы ресурсов и ограничения, отклоните развертывание. Наблюдайте за использованием ресурсов и при необходимости изменяйте квоты.
Ограничения и запросы на получение ресурсов помещаются в спецификацию pod. Запросы используются планировщиком Kubernetes во время развертывания для поиска доступного узла в кластере. Ограничения и запросы работают на уровне отдельных pod. Дополнительные сведения об определении этих значений см. в разделе Определение запросов и ограничений ресурсов pod.
Чтобы обеспечить возможность резервировать и ограничивать ресурсы для команды или проекта разработки, следует использовать квоты ресурсов. Эти квоты определяются в пространстве имен и могут использоваться для установки на следующей основе:
- Вычислительные ресурсы, например ЦП, память и GPU.
- Ресурсы хранения, включая общее количество томов или объем дискового пространства для данного класса хранения.
- Число объектов, таких как максимальное количество секретов, служб или заданий, которые могут быть созданы.
Kubernetes не перегружает ресурсы. Как только общее количество запросов на ресурсы превысит назначенную квоту, все дальнейшие развертывания будут неудачными.
При определении квоты ресурсов все pod, созданные в пространстве имен, должны содержать ограничения или запросы в спецификациях pod. Если они не содержат таких значений, можно отклонить развертывание. Вместо этого вы можете настроить запросы по умолчанию и ограничения для пространства имен.
В следующем примере манифест 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.
Преднамеренные прерывания работы
Преднамеренные прерывания работы — это события, запрошенные оператором кластера или владельцем приложения. Включить:
- Обновления кластера
- Обновленный шаблон развертывания
- Случайное удаление pod
Kubernetes предоставляет бюджеты на прерывание работы pod для добровольных сбоев, позволяя планировать реагирование развертываний или наборов реплик при возникновении события добровольного прерывания. Используя бюджеты неработоспособности pod, операторы кластера могут определить минимальное количество доступных или максимальное количество недоступных ресурсов.
Если вы обновляете кластер или обновляете шаблон развертывания, планировщик Kubernetes будет планировать дополнительные pod на других узлах, прежде чем разрешить преднамеренное прерывание работы. Планировщик ожидает перезагрузки узла до тех пор, пока определенное количество pod не будет успешно запланировано на других узлах кластера.
Давайте рассмотрим в качестве примера набор реплик с пятью pod, на которых выполняется NGINX. Эти pod в наборе реплик имеют присвоенную метку 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.
Можно определить максимальное число недоступных экземпляров в наборе реплик. В этом случае также можно определить процент максимального количества недоступных pod. Следующий манифест YAML бюджета неработоспособности pod определяет, что не более двух pod в реплике набора будут недоступны:
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 см. в рекомендациях на такие темы: