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

Master-узлы

Для обеспечения отказоустойчивости кластера всегда используйте не менее трёх master-узлов. Такое количество обеспечит безотказную работу кластера и позволит безопасно обновлять master-узлы. В большем числе нет необходимости, а двух узлов будет недостаточно для обеспечения согласия между master-узлами (кворума) в случае возникновения неполадок с одним из них.

При использовании всего одного master-узла его отказ приведет к сбою всего кластера, так как именно master-узел управляет ключевыми компонентами кластера, обеспечивающими его работу.

Frontend-узлы

Frontend-узлы балансируют входящий трафик, на них работают Ingress-контроллеры. Используйте более одного frontend-узла. Frontend-узлы должны выдерживать трафик при отказе как минимум одного frontend-узла.

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

Узлы мониторинга

Узлы мониторинга служат для запуска Grafana, Prometheus и других компонентов мониторинга. В нагруженных кластерах со множеством алертов и большими объемами метрик под мониторинг рекомендуется выделить отдельные узлы. Если этого не сделать, компоненты мониторинга будут размещены на системных узлах.

При выделении узлов под мониторинг важно, чтобы на них были быстрые диски (не менее 400 IOPS).

Системные узлы

Системные узлы предназначены для запуска модулей Deckhouse. Выделите два системных узла: в этом случае модули Deckhouse будут работать на них, не пересекаясь с пользовательскими приложениями кластера.

Предотвращение перегрузки Kubernetes API (FlowSchema)

В кластере под управлением DVP по умолчанию включен компонент, реализующий FlowSchema и PriorityLevelConfiguration для предотвращения перегрузки Kubernetes API.

FlowSchema устанавливает PriorityLevel для list-запросов от всех сервис-аккаунтов в пространствах имен Deckhouse (у которых установлен label heritage: deckhouse) к следующим apiGroup:

  • v1 (Pod, Secret, ConfigMap, Node и т. д.) — в кластерах с большим количеством основных ресурсов (например, секретов или подов).
  • apps/v1 (DaemonSet, Deployment, StatefulSet, ReplicaSet и т. д.) — при развертывании большого количества приложений в кластере (например, Deployment’ов).
  • deckhouse.io (кастомные ресурсы Deckhouse) — при наличии большого числа различных кастомных ресурсов Deckhouse в кластере.
  • cilium.io (кастомные ресурсы Cilium) — в кластерах с большим количеством политик Cilium.

Все запросы к API, соответствующие FlowSchema, помещаются в одну очередь обработки с общим приоритетом. Это ограничивает нагрузку на Kubernetes API и предотвращает его перегрузку при массовом выполнении list-запросов.

Компонент не имеет настроек, но доступны следующие команды:

  • Проверка состояния уровней приоритета (priority level):

    d8 k get --raw /debug/api_priority_and_fairness/dump_priority_levels

  • Проверка состояния очередей уровней приоритета:

    d8 k get --raw /debug/api_priority_and_fairness/dump_queues

Также он передаёт в Grafana следующие метрики:

  • apiserver_flowcontrol_rejected_requests_total — общее число отброшенных запросов.
  • apiserver_flowcontrol_dispatched_requests_total — общее число обработанных запросов.
  • apiserver_flowcontrol_current_inqueue_requests — количество запросов в очередях.
  • apiserver_flowcontrol_current_executing_requests — количество запросов в обработке.