Перед развёртыванием кластера под управлением Deckhouse Kubernetes Platform необходимо определиться с конфигурацией будущего кластера и выбрать параметры для будущих узлов кластера, такие как количество RAM, CPU и так далее.

Планирование установки

Прежде чем приступить к развёртыванию кластера, необходимо провести планирование ресурсов, которые могут потребоваться для его работы. Для этого следует ответить на несколько вопросов:

  • Какая нагрузка планируется на кластер?
  • Требуется ли кластеру режим повышенной нагрузки?
  • Требуется ли кластеру режим высокой доступности?
  • Какие модули DKP планируется использовать?

Ответы на эти вопросы помогут определить необходимое количество узлов для развёртывания кластера. См. подробнее в разделе «Сценарии развёртывания».

Все описанное дальше применимо к установке Deckhouse Kubernetes Platform с набором модулей Default.

Сценарии развёртывания

В разделе приведён примерный расчёт ресурсов, необходимых для кластера, в зависимости от предполагаемой нагрузки.

Конфигурация кластера Master-узлы Worker-узлы Frontend-узлы Системные узлы Узлы мониторинга
Минимальная 1 не менее 1 – – –
Типовая 3 не менее 1 2 2 -
Повышенная нагрузка 3 не менее 1 2 2 2

Типы узлов в таблице:

  • master-узлы — узлы, управляющие кластером;
  • frontend-узлы — узлы, балансирующие входящий трафик, на них работают Ingress-контроллеры;
  • узлы мониторинга — служат для запуска Grafana, Prometheus и других компонентов мониторинга;
  • системные узлы — предназначены для запуска модулей Deckhouse;
  • worker-узлы — предназначены для запуска пользовательских приложений.

Подробнее с этими типами узлов можно ознакомиться в секции «Особенности конфигурации» раздела «Подготовка к production».

Приведённые в таблице конфигурации:

  • Минимальная — кластер в такой конфигурации подходит для небольших проектов с невысокой нагрузкой и надёжностью. Характеристики worker-узла выбираются самостоятельно исходя из предполагаемой пользовательской нагрузки. Также следует учитывать, что в такой конфигурации некоторые из компонентов DKP также будут работать на worker-узле.

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

  • Типовая – рекомендуемая конфигурация. Устойчива к отказам до двух мастер-узлов. Значительно повышает доступность сервисов.
  • Кластер с повышенной нагрузкой — отличается от типовой конфигурации выделенными узлами мониторинга. Позволяет обеспечить высокий уровень наблюдаемости в кластере даже при высоких нагрузках.

Deckhouse Kubernetes Platform, начиная с версии 1.74, имеет механизм контроля целостности модулей, который защищает их от подмены и изменения. Этот механизм включается автоматически при поддержке операционной системой на узлах, где установлен Deckhouse, модуля ядра erofs. При отсутствии этого модуля ядра Deckhouse продолжит работу без механизма контроля целостности модулей, при этом появится алерт о неработоспособности этой функциональности.

Выбор ресурсов для узлов

Уровень требований Тип узла CPU (шт.) RAM (ГБ) Объем диска (ГБ)
Минимальные

Работа кластера на узлах с минимальными требованиями сильно зависит от набора включённых модулей DKP.
При большом количестве включённых модулей ресурсы узлов лучше увеличить.

 		Master-узел 4 8 60
Worker-узел 4 8 60
Frontend-узел 2 4 50
Узел мониторинга 4 8 50 / 150*
Системный узел 2 4 50 / 150*
Системный узел (если нет выделенных узлов мониторинга) 4 8 60 / 160*
Production

 Master-узел 8 16 60
Worker-узел 4 12 60
Frontend-узел 2 4 50
Узел мониторинга 6 12 50 / 150*
Системный узел 4 8 50 / 150*
Системный узел (если нет выделенных узлов мониторинга) 8 16 60 / 160*
Кластер с одним-единственным master-узлом Master-узел 6 12 160
  • Дисковое пространство PVC для системных компонентов: если для хранения системных PVC (модулей prometheus, upmeter и других) будет использоваться локальное дисковое пространство узла, то необходимо дополнительно выделить >= 100 ГБ.
  • Характеристики worker-узлов во многом зависят от характера запускаемой на узле (узлах) нагрузки, в таблице указаны минимальные требования. Под системные сервисы (kubelet) и системные поды на worker-узлах требуется заложить как минимум 1 CPU и 2 ГБ памяти.
  • Для всех узлов следует выделять быстрые диски (400+ IOPS).

Кластер с одним-единственным master-узлом

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

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

В «Быстром старте» есть инструкции по развёртыванию кластера на единственном master-узле. После снятия taint с узла на нём будут запущены все компоненты кластера, входящие в выбранный набор модулей (по умолчанию — Default). Для успешной работы кластера в таком режиме потребуются 16 CPU, 32 ГБ RAM и 60 ГБ дискового пространства на быстром диске (400+ IOPS). Эта конфигурация позволит запускать некоторую полезную нагрузку.

В такой конфигурации при нагрузке в 2500 RPS на условное веб-приложение (статическая страница Nginx) из 30 подов и входящем трафике в 24 Мбит/с:

  • нагрузка на CPU суммарно будет повышаться до ~60%;
  • значения RAM и диска не возрастают, но в реальности будут зависеть от количества метрик, собираемых с приложений, и характера обработки полезной нагрузки.

Рекомендуется провести нагрузочное тестирование вашего приложения и с учетом этого скорректировать мощности сервера.

Примеры конфигураций

Для развертывания Deckhouse Kubernetes Platform в редакции Enterprise Edition с набором модулей Default необходима следующая конфигурация узлов:

  • master-узлы — 1 шт, 4 CPU, 8 ГБ RAM;
  • frontend-узлы — 1 шт, 2 CPU, 4 ГБ RAM;
  • системные узлы — 1 шт, 8 CPU, 16 ГБ RAM;
  • worker-узлы — 1 шт, 4 CPU, 8 ГБ RAM.

При необходимости DKP в такой же конфигурации можно запустить и на одном узле с 16 CPU, 32 ГБ RAM для виртуальной машины или 10 CPU, 24 ГБ RAM для bare-metal-сервера.

Требования к аппаратным характеристикам узлов

Машины, предназначенные стать узлами будущего кластера, должны соответствовать следующим требованиям:

  • Архитектура ЦП — на всех узлах должна использоваться архитектура ЦП x86_64.
  • Однотипные узлы — все узлы должны иметь одинаковую конфигурацию для каждого типа узлов. Узлы должны быть одной марки и модели с одинаковой конфигурацией ЦП, памяти и хранилища.
  • Сетевые интерфейсы — каждый узел должен иметь по крайней мере один сетевой интерфейс для маршрутизируемой сети.

Требования к сети между узлами

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

Сообщество

Следите за новостями проекта в Telegram.

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

Команда Deckhouse знает, каких усилий требует организация работы production-кластера в Kubernetes. Мы будем рады, если Deckhouse позволит вам реализовать задуманное. Поделитесь своим опытом и вдохновите других на переход в Kubernetes.