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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Уровень требований Тип узла 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-узел 16 32 60
  • Дисковое пространство PVC для системных компонентов: если для хранения системных PVC (модулей prometheus, upmeter и других) будет использоваться локальное дисковое пространство узла, то необходимо дополнительно выделить >= 100 ГБ.
  • Характеристики worker-узлов во многом зависят от характера запускаемой на узле (узлах) нагрузки, в таблице указаны минимальные требования. Под системные сервисы (kubelet) и системные поды на worker-узлах требуется заложить как минимум 1 CPU и 2 ГБ памяти.
  • Для всех узлов следует выделять быстрые диски (400+ IOPS).

Кластер, состоящий из одного узла

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

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

В «Быстром старте» есть инструкции по развёртыванию кластера на одном узле. После снятия 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 Kubernetes Platform знает, каких усилий требует организация работы production-кластера в Kubernetes. Мы будем рады, если DKP позволит вам реализовать задуманное. Поделитесь своим опытом и вдохновите других на переход в Kubernetes.