Рекомендации по использованию Managed Service for Kubernetes

Используйте эти рекомендации для ваших PRODUCTION-приложений, которым требуется:

• Высокая доступность и отказоустойчивость.
• Масштабирование нагрузки.
• Изоляция ресурсов.

Высокая доступность и отказоустойчивостьВысокая доступность и отказоустойчивость

• Используйте релизный канал REGULAR или STABLE.

  Совет

  Используйте релизный канал RAPID для тестовых окружений, чтобы быстрее тестировать обновления Kubernetes и Managed Service for Kubernetes.

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

• Настраивайте политики podDisruptionBudget, чтобы сократить время простоя сервисов во время обновления.

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

• Выделяйте мастеру и узлам достаточно вычислительных ресурсов (CPU, RAM).

• Минимизируйте или исключите переподписку ресурсов (особенно RAM) на узлах.

• Настраивайте корректные проверки состояния (Health Checks) для балансировщиков нагрузки.

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

• Разворачивайте сервисы типа 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).

В Yandex Cloud реализован механизм NLB Zone Shift, который позволяет отметить балансировщик специальным флагом. Если в зоне доступности произошел частичный сбой, который не фиксируется проверками состояния, служба поддержки Yandex Cloud отключит проблемную зону от этого балансировщика.

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

Подробнее о работе сетевого балансировщика нагрузки.

Балансировщик нагрузки уровня приложенияБалансировщик нагрузки уровня приложения

Балансировщик нагрузки уровня приложения (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 для установки лимитов на уровне пространства имен.

Мониторинг и эскалацияМониторинг и эскалация

Мониторинг и система предупреждений — важный инструмент обеспечения отказоустойчивости.

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