$ k8s-calc
requests и limits по фактическому потреблению. Цифры — из kubectl top, Prometheus или Lens.
входные данные
resources: # здесь появится результат
Как считаются рекомендации
CPU requests — среднее потребление плюс запас. Requests по CPU влияют на планирование пода и на гарантированную долю процессора при конкуренции, поэтому их считают от среднего, а не от пика: иначе кластер будет простаивать зарезервированным.
CPU limits — для латентно-чувствительных сервисов калькулятор предлагает не ставить лимит вовсе (частая рекомендация в сообществе: CPU-троттлинг больно бьёт по хвостовым задержкам, а «отобрать лишнее» CPU в отличие от памяти можно без убийства процесса). Для batch-нагрузок лимит ставится от пика с запасом, чтобы фоновая джоба не съедала ноду.
Memory requests и limits — от пика с запасом, и обычно равные друг другу (класс QoS Guaranteed по памяти). Память некомпрессируемый ресурс: превышение лимита — это OOMKill, поэтому экономить на запасе тут опаснее, чем на CPU.
Откуда взять входные цифры
Быстрый вариант — kubectl top pod <pod> в разные моменты дня. Правильный вариант — Prometheus: container_cpu_usage_seconds_total (rate за 5m, квантили за неделю) и container_memory_working_set_bytes (максимум за неделю). Берите период, включающий пиковую нагрузку — вечер, распродажу, начало месяца.
Частые ошибки
Requests «на глаз» с запасом ×10 — под резервирует ресурсы ноды, автоскейлер раздувает кластер, растёт счёт. Memory limit впритык к пику — любой всплеск, и под в CrashLoopBackOff по OOMKilled.