Рекомендации по конфигурации узлов кластера и предотвращению перегрузки

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

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 — количество запросов в обработке.

Задержка перезагрузки или выключения узла, пока на нём работают критичные поды

В DKP поддерживается механизм включения задержки выключения или перезагрузки узла (далее просто «выключение узла»), если на нем запущены stateful-приложения или виртуальные машины (ВМ). Механизм реализуется сервисом d8-shutdown-inhibitor модуля node-manager.

Задержка срабатывает, если на узле запущены поды с лейблом pod.deckhouse.io/inhibit-node-shutdown. DKP откладывает выключение узла, чтобы пользователь смог перенести критичные поды на другой узел или завершить их работу штатным образом. Это полезно, например, для stateful-нагрузок и других случаев, когда необходимо избежать потери данных. Подробная информация о принципах работы и особенностях механизма представлена в документации модуля node-manager.

Включение задержки выключения узла

Чтобы включить механизм задержки выключения узла, добавьте на под лейбл pod.deckhouse.io/inhibit-node-shutdown (для Deployment укажите лейбл в шаблоне пода).

Пример манифеста пода с лейблом pod.deckhouse.io/inhibit-node-shutdown:

apiVersion: v1
kind: Pod
metadata:
  name: my-stateful-app
  labels:
    app: my-stateful-app
    pod.deckhouse.io/inhibit-node-shutdown: "true"
spec:
  containers:
    - name: app
      image: my-registry/my-app:1.0.0

Поиск подов, блокирующих выключение, и диагностика на узле

Для поиска подов, из-за которых блокируется выключение узла, используйте команду:

d8 k get po -A -l pod.deckhouse.io/inhibit-node-shutdown -o wide

Для просмотра состояния GracefulShutdownPostpone на узле используйте команду:

d8 k get node <NODE_NAME> -o jsonpath='{range .status.conditions[?(@.type=="GracefulShutdownPostpone")]}{.type}{"\t"}{.status}{"\t"}{.reason}{"\t"}{.message}{"\n"}{end}'

Возможные значения поля reason:

• WaitingForShutdownSignal — на узле работает механизм блокировки выключения, но блокировка ещё не началась;
• PodsWithLabelAreRunningOnNode — выключение заблокировано, поскольку на узле ещё работают поды с лейблом pod.deckhouse.io/inhibit-node-shutdown;
• NoRunningPodsWithLabel — блокировка снята, выключение может быть продолжено.

Дополнительные ресурсы

• Документация модуля node-manager