Расчёт ресурсов¶
Оценки, не бенчмарк
Цифры ниже — оценки по характеру нагрузки каждого компонента и по
топологии демо-чарта, а не результат измерений. Ни Helm-чарт, ни
Docker Compose не задают фиксированных CPU/memory-лимитов, которые
можно было бы процитировать как проверенные. Прежде чем полагаться
на эти диапазоны в продакшене, снимите собственные метрики
(kubectl top, Prometheus) на своём профиле нагрузки.
Профиль: Pilot/Demo¶
Ориентир — demo Helm-чарт Alatyr: по одной реплике на каждый компонент (сервер, PostgreSQL, Vault, frontend), без HA. Разумно для пилота или демо-окружения с до ~200 устройств.
Ресурсы — не лицензионный лимит
Расчёт ресурсов ниже не отменяет ограничения по числу устройств из
действующей лицензии — базовая (бесплатная) лицензия ограничена 50
устройствами, платная — числом max_devices. Прежде чем планировать
пилот на ~200 устройств, убедитесь, что действующая лицензия покрывает
это число, см. Лицензирование.
| Компонент | CPU (request / limit) | Memory (request / limit) | Почему |
|---|---|---|---|
| Server (Go) | 50–100m / 250–500m | 64–128Mi / 256Mi | Лёгкий Go-бинарь без тяжёлых рантайм-зависимостей; в покое — десятки МБ RSS, всплески CPU только при TLS/crypto-операциях выпуска (/enroll*) |
| PostgreSQL | 100–250m / 500m | 128–256Mi / 512Mi | Потребление памяти следует за настройками буферизации Postgres; при ~200 устройствах датасет (устройства, заявки на выпуск, журнал аудита) — десятки–низкие сотни МБ |
Vault (server -dev) |
50–100m / 250m | 64–128Mi / 256Mi | Демо-чарт запускает Vault в dev-режиме — in-memory backend, авто-unseal; PKI- и SSH-secrets-engine смонтированы в одном экземпляре. Не оценивайте по этим цифрам production-Vault — dev-режим не хранит состояние на диске и не переживает рестарт пода |
| Frontend (nginx + статика Vite) | 10–25m / 100m | 16–32Mi / 64Mi | Статические ассеты за nginx, без серверного рендеринга |
Итого по кластеру: порядка 0.2–0.5 vCPU и 300–550Mi памяти на все
четыре компонента вместе — этого достаточно как ориентир для
requests, если разворачиваете демо-чарт на общем/некритичном узле.
Диск. Demo-чарт резервирует под данные PostgreSQL 5Gi по умолчанию (настраивается размером хранилища PostgreSQL в values чарта). При пилотном масштабе (сотни устройств, умеренный объём журнала аудита) этого оценочно хватает надолго — рост журнала аудита зависит от частоты операций (выпуск/отзыв/логин) в вашем окружении, которую эта оценка учесть не может. Настройте алерт на заполнение тома.
Профиль: Production¶
Для тысяч устройств топология демо-чарта — не отправная точка, а
только источник соотношений между компонентами. Как и для пилотного
профиля, расчёт ресурсов здесь не отменяет лицензионный лимит на число
устройств — на масштаб в тысячи устройств потребуется платная лицензия с
соответствующим max_devices, см. Лицензирование. Реальный
production-деплой потребует:
- нескольких реплик сервера за load balancer'ом — но прежде чем размещать N реплик API-сервера, посмотрите страницу Отказоустойчивость: там описаны ограничения, специфичные для SCEP-поллинга, которые влияют на то, как масштабировать сервер горизонтально;
- production-режима Vault (не
-dev): постоянный storage backend (Raft/Consul), ручной или auto-unseal через KMS, в идеале — HA-кластер Vault (нечётное число узлов), что выходит далеко за рамки одноподового демо-чарта; - PostgreSQL с ресурсами, пропорциональными реальному датасету, и отдельным планом на бэкапы/репликацию (демо-чарт даёт один под без реплики и без задачи резервного копирования).
| Компонент | CPU (request / limit) | Memory (request / limit) | Почему |
|---|---|---|---|
| Server (на реплику) | 250–500m / 1 vCPU | 128–256Mi / 512Mi | Тот же лёгкий Go-бинарь; на тысячах устройств значение имеет число реплик (см. Отказоустойчивость) и частота /enroll/checkin-трафика, а не размер одного пода |
| PostgreSQL | 500m–1 vCPU / 2 vCPU | 512Mi–1Gi / 2Gi | Датасет и WAL-нагрузка растут с числом устройств и историей заявок на выпуск и журнала аудита; на этом масштабе также рассмотрите read-реплику под отчётность |
| Vault (production, на узел HA-кластера) | 250m–1 vCPU / 2 vCPU | 256Mi–1Gi / 2Gi | Требуемые ресурсы сильно зависят от выбранного storage backend (Raft/Consul) и числа узлов кластера (обычно 3+ для HA) — это оценка на узел, не на весь кластер |
| Frontend (на реплику) | 10–25m / 100m | 16–32Mi / 64Mi | Статика; масштабируется по объёму HTTP-запросов от Admin UI, не по числу устройств |
Диск. На тысячах устройств 5Gi из демо-чарта, скорее всего, будет
мало — рост журнала аудита и заявок на выпуск пропорционален числу
операций выпуска/отзыва/проверки, что зависит от политики ротации
сертификатов и retention-политики аудита у конкретного заказчика.
Ориентируйтесь не на фиксированное число ГБ, а на мониторинг занятости
тома с алертом задолго до заполнения, плюс план на расширение тома
(storageClassName с поддержкой online-resize) или архивацию старых
записей журнала аудита.