Что такое Request в Kubernetes? — пример ответа на собеседовании Devops Инженер

Ответ

В Kubernetes request — это гарантированный минимум ресурсов (CPU и памяти), который планировщик (kube-scheduler) резервирует для контейнера на узле. Это ключевой механизм для планирования (scheduling) и управления ресурсами кластера.

Как это работает:

Когда вы создаёте Pod, вы указываете requests для каждого контейнера.
Kube-scheduler ищет узел, у которого достаточно свободных (аллоцируемых) ресурсов, чтобы удовлетворить сумму всех requests для Pod'а.
Если такого узла нет, Pod остаётся в состоянии Pending.
Назначенные ресурсы закрепляются за Pod'ом и не могут быть использованы другими Pod'ами на этом узле, даже если контейнер их фактически не потребляет.

Пример манифеста:

apiVersion: v1
kind: Pod
metadata:
  name: frontend-app
spec:
  containers:
  - name: web-server
    image: nginx:alpine
    resources:
      requests:
        memory: "256Mi"   # Гарантированные 256 МиБ памяти
        cpu: "250m"       # Гарантированные 0.25 CPU ядра (250 милли-CPU)
      limits:
        memory: "512Mi"
        cpu: "500m"

Отличие `requests` от `limits`:	Параметр	`requests`
Назначение	Гарантия, планирование. Минимум, который контейнер получит всегда.	Ограничение, защита. Максимум, который контейнеру разрешено использовать.
Влияние на планирование	Да. Scheduler проверяет наличие `requests` на узле.	Нет. Scheduler игнорирует `limits` при размещении Pod'а.
При превышении	Неприменимо. Контейнер может использовать меньше.	CPU: Throttling (ограничение). Memory: Контейнер будет убит (OOMKilled).

Практическое значение для DevOps:

Эффективное использование кластера: Правильная настройка requests предотвращает overcommit (чрезмерную загрузку) узлов и позволяет scheduler'у оптимально размещать workloads.
Стабильность сервисов: Критичные продакшн-сервисы получают гарантированные ресурсы и не страдают от «шумных соседей».
Автомасштабирование: Горизонтальное автоскейлирование Pod'ов (HPA) и узлов (Cluster Autoscaler) используют метрики потребления относительно requests, а не limits.

В моей практике настройка реалистичных requests на основе мониторинга (например, по перцентилям из Prometheus) была ключом к стабильной работе кластера из 200+ узлов, позволяя достичь высокой плотности размещения без конфликтов за ресурсы.