Отказоустойчивость Managed Kubernetes

Отказоустойчивость — это подход, позволяющий увеличить доступность приложения или сервиса. Поговорим об отказоустойчивости приложений, развёрнутых в кластере Kubernetes®.Yandex Managed Kubernetes из коробки обеспечивает определённый уровень отказоустойчивости:

• Доступ к мастер-ноде Managed Kubernetes предоставляется только на уровне API, а значит, даже владелец кластера не сможет «залезть внутрь» и сломать её.
• Автомасштабирование тоже существенно повышает отказоустойчивость.
• Managed Kubernetes плотно интегрирован с инфраструктурой Yandex.Cloud. Вы можете использовать Yandex Container Registry для хранения образов и Container Optimized Image для разворачивания контейнеров.

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

1. Отказ нодыВремя от времени ломается всё, в том числе виртуальные машины, серверы или стойки в дата-центре. Это значит, что выходят из строя размещённые на них ноды. Kubernetes будет автоматически расселять поды по действующим нодам и зонам доступности. Он делает это случайно, так что все поды могут оказаться на одном узле.Правильнее распределять копии контейнеров по разным узлам (виртуальным машинам), а в региональных кластерах — по разным зонам доступности. Вам поможет политика node anti-affinity, которая распределяет поды по узлам, или ещё более гибкий и современный инструмент Pod Topology Spread Constraints: он распределяет поды и по узлам, и по зонам доступности.

2. Обновление KubernetesKubernetes развивается очень быстро, и необходимо регулярно обновлять его, чтобы получать доступ к новым возможностям. При обновлении Kubernetes автоматически перезапускает ноды, а вместе с ними перезапускаются и размещённые там поды. Если перезапустится несколько нод одновременно — это может привести к недоступности приложения или сервиса.Чтобы управлять этим процессом, используйте Pod Disruption Budget. Его конфигурация позволяет ограничить число одновременно недоступных подов и обеспечить соблюдение SLA.Пример, где задаётся минимальное число одновременно доступных подов (параметр minAvailable):

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

Пример, где задаётся максимальное число одновременно недоступных подов (параметр maxUnavailable):

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

3. Сбой DNSDNS — очень важный и самый нагруженный сервис внутри кластера Kubernetes. Сбой в нём приводит к недоступности всего кластера.  Инструмент NodeLocal DNSCache позволяет нодам обращаться в DNS-сервис кластера не напрямую, а через локальный кеш, который обновляется по протоколу TCP. Включение NodeLocal DNSCache существенно сокращает внутренний трафик и увеличивает отказоустойчивость кластера.Несколько общих рекомендаций для Yandex Managed Kubernetes

• Обновляйте рабочую среду только вручную, используя каналы Regular или Stable. Отключите в рабочей среде автообновления в релизных каналах для мастера и для каждой группы узлов.
• Для рабочей среды используйте региональный тип мастера. О разнице между региональным и зональным мастером мы говорили, когда создавали кластер. SLA Yandex Managed Kubernetes распространяется именно на региональную конфигурацию.
• При настройке LoadBalancer явно прописывайте политику распределения трафика. За это отвечает параметр externalTrafficPolicy. Задавайте для него значение Local — тогда трафик будет напрямую попадать на те ноды, где запущены контейнеры приложений. При этом сокращается горизонтальный трафик между виртуальными машинами. Если же оставить значение по умолчанию (Cluster), то трафик будет случайно попадать на любой из узлов кластера, а затем перенаправляться на другие ноды, пока не встретит нужный под.
• Для всех сервисов настройте requests и limits, о которых мы говорили на уроке про автомасштабирование. Напомним: limits гарантируют, что сервис не превысит выделенные ему ресурсы процессора и оперативной памяти; requests нужны для автоматического горизонтального масштабирования подов.
• При автомасштабировании с помощью Cluster Autoscaler узлы создаются в одной зоне доступности. Для дополнительной страховки создайте по группе узлов в каждой зоне доступности.
• Разворачивайте сервисы типа Deployment в нескольких экземплярах. Это гарантирует доступность сервиса при проблемах с подом, нодой или даже целой зоной доступности.
• С помощью readiness-проб отслеживайте ситуации, когда приложение временно не может обслуживать трафик (например, потому что ждёт готовности смежного сервиса).