Перед развёртыванием кластера под управлением 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-узла пострадает весь кластер.

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

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

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

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

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

 Master-узел 8 16 60
Worker-узел 4 12 60
Frontend-узел 2 4 50
Узел мониторинга 4 8 50
Системный узел 6 12 50
Системный узел (если нет выделенных узлов мониторинга) 8 16 60
Кластер с одним-единственным master-узлом Master-узел 6 12 60
  • Характеристики worker-узлов во многом зависят от характера запускаемой на узле (узлах) нагрузки, в таблице указаны минимальные требования.
  • Для всех узлов следует выделять быстрые диски (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 в редакции Еnterprise 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.