Ответ
Kubernetes нужен, когда вы перерастаете возможности простого хостинга или ручного управления контейнерами. В моей практике переход на K8s был оправдан в следующих ситуациях:
1. Частые и сложные деплои: Когда мы перешли на микросервисы и количество деплоев в день выросло с одного до десятков. Kubernetes с его Rolling Updates и Health Checks позволил обновлять сервисы без простоя.
2. Непредсказуемая или "рваная" нагрузка: Для сервиса с пиковой нагрузкой в часы распродаж мы настроили Horizontal Pod Autoscaler (HPA), который автоматически добавлял реплики при росте CPU-нагрузки выше 70%.
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
name: frontend-hpa
spec:
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: frontend
minReplicas: 2
maxReplicas: 10
metrics:
- type: Resource
resource:
name: cpu
target:
type: Utilization
averageUtilization: 70
3. Необходимость эффективно утилизировать ресурсы: На физических серверах у нас были простаивающие мощности. Kubernetes scheduler стал размещать поды с разных сервисов на одних и тех же нодах, что сократило затраты на инфраструктуру на ~30%.
4. Управление конфигурацией и секретами: Вместо раздачи конфигов по серверам мы стали использовать ConfigMaps и Secrets, которые монтируются в поды как тома или переменные окружения. Это упростило смену конфигурации и повысило безопасность.
Когда мы отложили внедрение K8s: На раннем этапе стартапа, когда был один монолит и небольшая команда. Сначала использовали Docker Compose для разработки и managed-сервис (как AWS ECS) для продакшена, чтобы сфокусироваться на продукте, а не на инфраструктуре.