Рекомендации по использованию Managed Service for Kubernetes
Примечание
В регионе Казахстан доступна только зона доступности kz1-a.
Примечание
В регионе Казахстан поддерживаются базовые и высокодоступные мастера в одной зоне доступности.
Используйте эти рекомендации для ваших PRODUCTION-приложений, которым требуется:
- Высокая доступность и отказоустойчивость.
- Масштабирование нагрузки.
- Изоляция ресурсов.
Совет
Протестируйте предлагаемые стратегии на тестовом окружении перед внедрением в PRODUCTION.
Высокая доступность и отказоустойчивость
-
Используйте релизный канал
REGULARилиSTABLE.Совет
Используйте релизный канал
RAPIDдля тестовых окружений, чтобы быстрее тестировать обновления Kubernetes и Managed Service for Kubernetes. -
Контролируйте обновление кластера и группы узлов. Либо отключите автоматическое обновление и выполняйте его вручную, либо задайте время обновления так, чтобы ваши приложения были доступны в часы их активного использования.
-
Настраивайте политики
podDisruptionBudget, чтобы сократить время простоя сервисов во время обновления. -
Выбирайте высокодоступный тип мастера, размещенный в трех зонах. Сервисы Kubernetes будут доступны в случае сбоя на уровне зоны доступности. Соглашение об уровне обслуживания
сервиса Managed Service for Kubernetes распространяется на конфигурацию с высокодоступным мастером, размещенным в трех зонах. -
Выделяйте мастеру и узлам достаточно вычислительных ресурсов (CPU, RAM).
-
Минимизируйте или исключите переподписку ресурсов (особенно RAM) на узлах.
-
Настраивайте корректные проверки состояния (Health Checks) для балансировщиков нагрузки.
-
Чтобы повысить надежность кластера, создавайте группы узлов с автоматическим масштабированием в нескольких зонах доступности.
Совет
Managed Service for Kubernetes использует в качестве групп узлов кластера группы виртуальных машин Yandex Compute Cloud. Посмотрите описание групп ВМ при зональном инциденте и рекомендации по предотвращению его последствий.
-
Разворачивайте сервисы типа
DeploymentиStatefulSetв нескольких экземплярах в разных зонах доступности. Используйте стратегии Pod Topology Constraints и AntiAffinity , чтобы обеспечить высокую доступность сервисов и эффективное потребление ресурсов кластера Kubernetes.Для всех стратегий используйте комбинации меток:
topology.kubernetes.io/zone, чтобы сервисы сохраняли доступность в случае отказа зоны доступности.kubernetes.io/hostname, чтобы сервисы сохраняли доступность в случае отказа узла кластера.
Важно
На автомасштабирование ресурсов при отказе зоны доступности требуется время. Обязательно используйте указанные метки, чтобы распределить поды по разным узлам и зонам доступности и обеспечить работоспособность ваших приложений.
Масштабирование нагрузки
Используйте эти рекомендации, если нагрузка на ваш кластер Managed Service for Kubernetes постоянно растет:
- Для снижения нагрузки на Kubernetes DNS используйте NodeLocal DNS. Если кластер содержит более 50 узлов, используйте автоматическое масштабирование DNS.
- Чтобы снизить горизонтальный трафик внутри кластера, используйте сетевой балансировщик нагрузки и правило
externalTrafficPolicy:Local, если это возможно. - Заранее продумайте требования к хранилищам узлов:
- Изучите лимиты дисков для Yandex Compute Cloud.
- Проведите нагрузочное тестирование дисковой подсистемы в тестовом окружении.
- Для снижения задержки при высоких показателях IOPS используйте нереплицируемые диски.
Сетевой балансировщик нагрузки
Сетевой балансировщик нагрузки (Network Load Balancer) распределяет поступающий на него трафик между целевыми ресурсами (ВМ). Обработчик с публичным IP-адресом позволяет балансировщику обрабатывать трафик из интернета, а обработчик с приватным IP-адресом — внутренний трафик. Балансировщик проверяет доступность целевых ресурсов с помощью проверок состояния (Health Checks).
Чтобы оценить работоспособность вашего приложения при отказе одной из зон доступности, воспользуйтесь сценарием
Подробнее о работе сетевого балансировщика нагрузки.
Балансировщик нагрузки уровня приложения
Балансировщик нагрузки уровня приложения (Application Load Balancer) основан на сетевом балансировщике, но позволяет направлять трафик на произвольные приватные IP-адреса, например на IP-адреса ресурсов вне облачной сети. Для маршрутизации трафика используются промежуточные ВМ, выступающие в качестве обратных прокси.
Балансировщик нагрузки уровня приложения поддерживает ручное отключение зоны доступности, в которой произошел частичный сбой.
Подробнее о работе балансировщика нагрузки уровня приложения.
Изоляция ресурсов
Применяйте эти рекомендации для приложений, использующих общие ресурсы кластера Kubernetes.
Настройте значения limits и requests для всех сервисов кластера:
---
...
containers:
...
resources:
limits:
cpu: 250m
memory: 128Mi
requests:
cpu: 100m
memory: 64Mi
...
Укажите доступность vCPU в тысячных долях, а RAM — в мегабайтах. Сервис не превысит лимиты vCPU и RAM, указанные в значениях limits. Настройка requests позволяет масштабировать узлы кластера при помощи автоматического масштабирования.
Чтобы автоматически управлять ресурсами подов, настройте политики Kubernetes:
- Quality of Service for Pods
для создания подов различных классов доступности. - Limit Ranges
для установки лимитов на уровне пространства имен. - Resource Quotas
для ограничения общего потребления ресурсов в пространстве имен.
Resource Quota
Используйте политику ResourceQuota для ограничения ресурсов, которые могут быть использованы в рамках одного пространства имен:
---
apiVersion: v1
kind: ResourceQuota
metadata:
name: namespace-quota
namespace: my-namespace
spec:
hard:
# Вычислительные ресурсы
requests.cpu: "10"
requests.memory: 20Gi
limits.cpu: "20"
limits.memory: 40Gi
# Количество объектов
pods: "50"
services: "10"
secrets: "20"
configmaps: "20"
persistentvolumeclaims: "10"
# Ресурсы хранилища
requests.storage: 100Gi
С помощью ResourceQuota можно ограничить:
| Тип ресурса | Параметры | Описание |
|---|---|---|
| Вычислительные | requests.cpu, requests.memory, limits.cpu, limits.memory |
Суммарные запросы и лимиты vCPU и RAM для всех подов в пространстве имен |
| Хранилище | requests.storage, persistentvolumeclaims |
Общий объем запрашиваемого хранилища и количество PVC |
| Количество объектов | pods, services, secrets, configmaps, replicationcontrollers, deployments.apps, statefulsets.apps, jobs.batch, cronjobs.batch |
Максимальное количество объектов каждого типа |
| Расширенные ресурсы | requests.nvidia.com/gpu, limits.nvidia.com/gpu |
Ресурсы GPU и другие extended resources |
Совет
Комбинируйте ResourceQuota с LimitRange: ResourceQuota ограничивает суммарное потребление ресурсов в пространстве имен, а LimitRange задает значения по умолчанию и границы для отдельных контейнеров.
Мониторинг и эскалация
Мониторинг и система предупреждений — важный инструмент обеспечения отказоустойчивости.
- Настройте мониторинг метрик и создайте алерты, чтобы следить за состоянием мастера, узлов, подов и постоянных томов.
- Настройте для алертов политики эскалации.