Что такое pod eviction в Kubernetes и для чего он используется?

Pod Eviction (выселение пода) — это процесс принудительного завершения работы одного или нескольких подов на узле (ноде) Kubernetes, когда на этом узле возникает нехватка критических ресурсов, таких как память (memory pressure) или дисковое пространство (disk pressure). Это защитный механизм, предотвращающий полный крах узла из-за исчерпания ресурсов.

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

1. Мониторинг: kubelet на каждом узле постоянно отслеживает потребление ресурсов.
2. Пороги (Eviction Thresholds): Администратор настраивает пороги, при достижении которых срабатывает eviction (например, memory.available < 500Mi).
3. Приоритизация: Когда порог достигнут, kubelet начинает завершать поды не в случайном порядке, а по их классу качества обслуживания (QoS):
   • 1. BestEffort: Поды без лимитов и запросов ресурсов. Удаляются первыми.
   • 2. Burstable: Поды с запросами (requests), но без лимитов (limits) или с лимитами выше запросов.
   • 3. Guaranteed: Поды, у которых лимиты равны запросам для всех контейнеров (CPU и memory). Удаляются в последнюю очередь.
4. Перепланирование: Контроллер репликации (например, Deployment) обнаруживает, что под умер, и создает его новую копию на другом, менее нагруженном узле.

Пример конфигурации eviction в kubelet (через конфигурационный файл):

apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
evictionHard:
  memory.available: "500Mi"    # Выселение при менее 500 MiB свободной памяти
  nodefs.available: "10%"      # Выселение при менее 10% свободного места на корневом диске
  nodefs.inodesFree: "5%"      # Выселение при менее 5% свободных inode
  imagefs.available: "15%"     # Выселение при менее 15% свободного места на диске для образов
evictionSoft:
  memory.available: "700Mi"
evictionSoftGracePeriod:
  memory.available: "1m"       # Дается 1 минута на исправление ситуации при мягком пороге

Для чего используется в DevOps:

• Самовосстановление кластера: Автоматическое освобождение ресурсов для сохранения работоспособности узла и критически важных workload'ов.
• Защита от "шумных соседей": Предотвращает ситуацию, когда один плохо сконфигурированный под (без limits) исчерпывает всю память на узле, "убивая" все остальные сервисы.
• Интеграция с кластерными автомасштабировщинами (Cluster Autoscaler): Eviction может стать сигналом для автомасштабировщика, что узлов не хватает, и он добавит новый узел в пул.
• Управление стоимостью: Правильная настройка запросов (requests) и лимитов (limits) для подов гарантирует, что eviction будет затрагивать в первую очередь менее важные задачи, а критичный сервис останется работать.