# Требования к нарезанию машин в кластере 

В рамках кластера учитываются не только pod’ы серверов приложений, но и все инфраструктурные компоненты, необходимые для работы системы: балансировщик, брокер очередей, планировщик заданий, компоненты маршрутизации, а также системы мониторинга и логирования (например, Prometheus, Grafana, Loki). Также отдельно учитываются база данных и файловое хранилище.

Приведенные далее требования и рекомендации относятся к системе в целом, однако основная часть ресурсов, как правило, приходится на серверы приложений.

- **CPU**
  - рассчитывается от нагрузки пользователей и интеграций;
  - минимальное значение — **2 vCPU на pod/инстанс**;
  - при росте нагрузки ресурсы масштабируются горизонтально за счет увеличения количества pod’ов или вертикально за счет увеличения ресурсов pod’а.

- **RAM**
  - основной параметр — **`Xmx` JVM**;
  - `Xmx` не должен превышать **32 ГБ**;
  - общий объем RAM должен быть не менее `Xmx + 10%`;
  - не рекомендуется выделять память без запаса.

- **Диск**
  - в кластере ориентир — **20 ГБ на pod**;
  - общий объем диска зависит от количества pod’ов;
  - для standalone-решения — не менее **120 ГБ на ВМ**.

- **Файловое хранилище**
  - используется NFS или S3-совместимое хранилище;
  - минимальные ресурсы: CPU — от 4, RAM — от 4 ГБ;
  - объем определяется отдельно.

- **База данных**
  - используется PostgreSQL;
  - рекомендуемая версия — **17 и выше**;
  - минимальная версия — **14**;
  - нагрузка на БД зависит от пользователей и интеграций.

- **Отказоустойчивость PostgreSQL**
  - возможные решения: Pacemaker или Postgres Pro Cluster.

- **Резервное копирование**
  - для баз до 1.5 ТБ можно использовать логические и бинарные дампы;
  - для баз более 1.5 ТБ используются потоковая репликация и физические бэкапы с WAL.

- **Сеть**
  - между всеми узлами требуется не менее **1 Гбит/с**;
  - такая пропускная способность должна быть обеспечена между нодами приложений, базой данных и файловым хранилищем;
  - для нагруженных систем рекомендуется 10 Гбит/с.

## Принципы нарезки кластера

Основной способ масштабирования — горизонтальный, за счет увеличения количества pod’ов и балансировки нагрузки между ними. Вертикальное масштабирование используется ограниченно, когда необходимо увеличить CPU и RAM конкретного pod’а.

При такой схеме pod’ы не должны хранить пользовательское состояние в локальной памяти. Сессии, данные и другие рабочие состояния должны размещаться во внешних компонентах, например в базе данных, кэше или файловом хранилище. Это позволяет свободно перераспределять нагрузку между pod’ами и упрощает отказоустойчивость. База данных, как правило, масштабируется вертикально, а также за счет использования реплик, обслуживающих запросы на чтение.

### Пример расчета на 500 одновременных пользователей

Для контура с 500 одновременными пользователями и 10–20 интеграционными потоками можно использовать следующую стартовую конфигурацию:

- слой приложений — 4 pod’а по 4 vCPU, 16 ГБ RAM и 20 ГБ диска на каждый pod;
- `Xmx` для каждого pod — порядка 12–14 ГБ;
- Kubernetes worker-ноды (варианты):
  - 4 ноды по 8 vCPU и 24 ГБ RAM,  
  или
  - 3 ноды по 8 vCPU и 48 ГБ RAM;
- диск на каждой ноде — не менее 120 ГБ;
- PostgreSQL — 8–16 vCPU и 32–64 ГБ RAM на основной узел;
- файловое хранилище — отдельный NFS или S3-совместимый узел с параметрами не менее 4 vCPU и 4 ГБ RAM;
- сеть между узлами — не менее 1 Гбит/с.


Конфигурация является ориентировочной и используется для предварительной оценки. Для точного расчета используйте sizing-инструмент.