Автомасштабирование сервиса
Вопрос
Как ты настроишь автомасштабирование веб-сервиса в Kubernetes, чтобы он выдерживал пики и не переплачивать?
Попробуйте сами
Ответьте вслух за 2 минуты, как на собесе. Потом сверьтесь с тезисами: что прозвучало, а что нет.
Показать ответ и разбор
Коротко
Что должно прозвучать в ответе
HPA по CPU (от requests) или по своей метрике: RPS, задержка, длина очереди
Правильные requests: от них считается утилизация и зависит планирование
minReplicas для отказоустойчивости (не меньше 2-3), maxReplicas как предохранитель
`behavior`: быстро вверх, медленно вниз, чтобы не было «пилы»
Автоскейлер узлов для подов в Pending, запас ёмкости или приоритеты для быстрой реакции
Готовность приложения: быстрый старт, readiness, graceful shutdown; проверка нагрузочным тестом
Что могут спросить следом
- Почему не масштабировать по памяти?
- Что делать, если новые поды стартуют 2 минуты?
- Когда нужен KEDA?
Разбор
Базово HPA по CPU с целью около 60-70% от requests, поэтому сначала выставляю честные requests по метрикам. Если сервис упирается не в CPU, а, например, в очередь или во внешние вызовы, масштабирую по своей метрике через адаптер Prometheus или KEDA: RPS на под, длина очереди, лаг потребителя. minReplicas не меньше двух-трёх для отказоустойчивости, maxReplicas как предохранитель от счёта за облако и от перегрузки базы. В behavior разрешаю быстрый рост и медленное уменьшение с окном стабилизации, чтобы не было пилы. Новые поды должны куда-то поместиться: Cluster Autoscaler или Karpenter добавят узлы, но это минуты, поэтому для резких пиков держу небольшой запас ёмкости, например низкоприоритетные поды-заглушки. Само приложение должно быстро стартовать, иметь readiness и корректно останавливаться, иначе масштабирование будет порождать ошибки. И проверяю всё нагрузочным тестом с реальным профилем, а не только на графиках.
Ответьте сами, а не прочитайте
В тренажёре вопрос попадёт в повторения и вернётся, когда начнёт забываться. Плюс билеты с зачётом: 20 вопросов, не больше 2 ошибок.