Вы переносите набор Python backend-сервисов в Kubernetes и должны задать requests/limits по CPU/памяти и настроить horizontal pod autoscaling. Какие риски несёт как недооценка, так и переоценка лимитов, и как выбрать политику автоскейлинга для сервиса с неравномерной нагрузкой? Обсудите компромиссы, риски и критерии выбора — единственного правильного решения может не быть.?

Короткий ответ

Недооценка лимитов приводит к OOMKill или CPU throttling под нагрузкой, переоценка — к неэффективному использованию кластера и более высоким затратам; для неравномерной нагрузки разумно сочетать консервативные requests под реальный baseline с запасом в limits и настраивать HPA с учётом времени прогрева новых подов, возможно с кастомными метриками, а не только CPU.

Как это работает подробнее

requests резервируется планировщиком при размещении пода, limits — верхняя граница, при превышении которой по памяти под получает OOMKill, по CPU — throttling через cgroups; HPA по умолчанию масштабируется по доле использования CPU относительно requests.cpu, поэтому неверный requests искажает решения автоскейлера.

Пример кода

config.yamlКопировать

resources:
  requests: { cpu: "250m", memory: "256Mi" }
  limits:   { cpu: "500m", memory: "512Mi" }
---
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
spec:
  minReplicas: 3
  maxReplicas: 20
  metrics:
    - type: Resource
      resource: { name: cpu, target: { type: Utilization, averageUtilization: 70 } }
  behavior:
    scaleUp: { stabilizationWindowSeconds: 30 }

Что использовать на практике

• Рекомендация. requests задают на основе измерений под реалистичной нагрузкой; для скачкообразной нагрузки учитывают время холодного старта новых подов в поведении HPA, иначе всплеск обгонит скорость автоскейлинга; для сервисов с внешним ограничением (пул соединений к БД) масштабирование по CPU может упереться в лимит БД раньше, чем в лимит CPU.
• Компромисс. точная настройка требует профилирования и может быстро устареть при изменении трафика — операционные издержки против риска инцидентов от грубой оценки; выбор между CPU-based HPA и кастомными метриками зависит от того, какая метрика реально коррелирует с перегрузкой, и от сложности внедрения адаптера метрик.

Подводные камни

• Риск. ставить limits сильно выше requests «на всякий случай» — даёт поду захватить много ресурсов ноды и вызвать noisy neighbor; настраивать HPA только по CPU для сервиса, узкое место которого — память или внешние соединения.