Сбор мусора в Kubernetes

Кратко

Kubernetes по умолчанию очищает неиспользуемые образы и остановленные контейнеры через Kubelet. Настройки можно менять с помощью флагов Kubelet (threshold- и eviction-параметры). Не удаляйте артефакты вручную — это может привести к рассинхронизации состояния узла.

Быстрые ссылки

• Образы контейнеров
• Очистка старых контейнеров
• Нужно ли вмешиваться вручную?
• Будущее: evictions
• Краткое резюме

Образы контейнеров

Kubelet, процесс-агент на каждом рабочем узле, содержит встроенный механизм очистки образов (garbage collection). Он автоматически отслеживает неиспользуемые образы и периодически удаляет те, которые считаются кандидатом на удаление. Решение о том, какой образ удалить в первую очередь, основано на двух факторах: объёме занимаемого места и времени последнего использования. Большой образ, не использовавшийся неделю, скорее будет удалён раньше, чем маленький образ, который использовался вчера.

Чтобы контролировать поведение очистки образов, заданы два порога дискового использования:

• image-gc-high-threshold — «высокий» порог, по умолчанию 85%.
• image-gc-low-threshold — «низкий» целевой порог, по умолчанию 80%.

Когда использование диска превышает высокий порог, Kubelet запускает процедуру очистки и пытается уменьшить использование до низкого порога. Вы можете изменить эти значения, если хотите более агрессивную или более консервативную стратегию управления диском.

Пример изменения через kubeadm-файл аргументов:

/var/lib/kubelet/kubeadm-flags.env

Внутри файла можно задать:

KUBELET_KUBEADM_ARGS="--image-gc-high-threshold=60 --image-gc-low-threshold=50"

После редактирования перезагрузите systemd и сам kubelet:

systemctl daemon-reload
systemctl restart kubelet

Важные заметки:

• Эти флаги применяются локально на каждом узле; для масштабного изменения применяйте их через конфигурацию узлов в Kubeadm/или через DaemonSet управления конфигурациями.
• Значения должны соответствовать вашей политике размещения образов и объёму диска узлов.

Очистка старых контейнеров

Kubelet также управляет удалением остановленных или «неопознанных» контейнеров. Чтобы дать старым контейнерам «период ожидания» перед удалением, используется минимальное время жизни контейнера и несколько дополнительных флагов.

Основные флаги, влияющие на удаление контейнеров:

• –maximum-dead-containers — максимальное число старых контейнеров, которые можно хранить на узле; значение -1 (по умолчанию) означает отсутствие предела.
• –maximum-dead-containers-per-container — максимум старых экземпляров для каждого контейнера (по образцу замены контейнера новыми версиями).
• –minimum-container-ttl-duration — минимальное время жизни (TTL) для мёртвых контейнеров; только после истечения этого периода контейнер станет кандидатом на удаление. Значение по умолчанию 0 означает отсутствие льготного периода.

Применение тех же процедур редактирования и перезапуска Kubelet, описанных выше, позволяет настроить эти параметры.

Пример разумной стратегии для среды CI/CD: держать 1–2 старых экземпляра для дебага (maximum-dead-containers-per-container=2) и минимальное TTL 10 минут, чтобы временные перезапуски не удалялись мгновенно.

Нужно ли вмешиваться вручную?

Короткий ответ: как правило — нет.

Пояснение:

• Ручное удаление образов или контейнеров (через файловую систему или сторонние инструменты) может привести к рассинхронизации состояния между Kubelet и контейнерным рантаймом. Это может вызвать ошибки при последующем запуске или остановке подов.
• Если пространство на диске заполняется и поведение Kubelet кажется недостаточно агрессивным, сначала попробуйте изменить Kubelet-флаги (см. разделы выше). Это безопасный и поддерживаемый путь.
• Проверяйте логи Kubelet (journalctl -u kubelet) и вывод kubectl describe node для диагностирования проблем, прежде чем предпринимать внешние удаления.

Команды для диагностики:

journalctl -u kubelet --since "1h"
kubectl describe node 

Будущее: evictions

Механизм порогов и флагов для garbage collection постепенно заменяется единой моделью evictions — системы выселений, которая унифицирует правила удаления подов и других ресурсов при дефиците ресурсов.

Основная идея:

• Evictions работают по правилам «hard» и «soft». Hard-eviction выполняется немедленно без льготного периода. Soft-eviction задаёт пользовательский grace period: если причина устранена до истечения периода — удаление отменяется.
• Evictions мониторят множество ресурсов (память, пространство для образов, inode и т.д.) и позволяют описывать правила в единой форме.

Примеры конфигурации для изображений:

--eviction-hard=imagefs.available<1Gi

Эта настройка указывает Kubelet немедленно освобождать пространство (включая удаление неиспользуемых образов), если для хранения образов остаётся меньше 1GiB.

--eviction-soft=imagefs.available<1Gi
--eviction-soft-grace-period=imagefs.available=5m

Вторая конфигурация показывает «мягкую» эвакуацию: образа будут удаляться только если свободное пространство держится ниже 1GiB хотя бы 5 минут.

Примечание: флаги, связанные с dead-containers, уже помечены как deprecated и могут быть удалены в будущих версиях. Evictions уже используются для образов и постепенно получают поддержку для остальных классов мусора.

Как выбрать между threshold и evictions — простая методика

1. Если у вас текущая рабочая конфигурация и вы хотите только скорректировать поведение — настройте image-gc-* и minimum-container-ttl-duration.
2. Если вы планируете унифицировать политику удаления ресурсов (память, диски, inode) — переходите на evictions и опишите правила конкретно под нужды кластера.
3. Всегда тестируйте изменения на отладочном узле или в staging перед применением в production.

flowchart TD
  A'Заполнен диск?' -->|Нет| B'Наблюдать'
  A -->|Да| C{Нужно срочно освободить место?}
  C -->|Да| D'Провести эвакуацию: evictions hard'
  C -->|Нет| E'Настроить evictions soft или image-gc thresholds'
  D --> F'Проверить логи kubelet'
  E --> F
  F --> G'Мониторить и откатить при проблемах'

Факт-бокс: значения по умолчанию и важные флаги

• image-gc-high-threshold: 85% (по умолчанию)
• image-gc-low-threshold: 80% (по умолчанию)
• minimum-container-ttl-duration: 0 (по умолчанию — без льгот)
• maximum-dead-containers: -1 (по умолчанию — без ограничения)
• eviction-hard / eviction-soft: настраиваются явными значениями (пример — imagefs.available<1Gi)

Риски и рекомендации по смягчению

Риск: ручное удаление приводит к рассинхрону Kubelet и контейнерного рантайма.

• Смягчение: используйте только поддерживаемые флаги Kubelet и операции через API Kubernetes.

Риск: слишком агрессивные пороги приводят к удалению часто используемых образов и увеличению времени холодных загрузок.

• Смягчение: учтите шаблоны развертывания (частота pull, сетевой throughput), используйте кеши образов или регистры в локальной сети.

Риск: недостаточно агрессивные пороги — заполнение диска и деградация узлов.

• Смягчение: мониторинг свободного диска, алерты и скрипты для оповещений, тестирование изменений в staging.

Чек-листы по ролям

• Для sRE / админа кластера:

  • Проверить текущие значения флагов на всех узлах.
  • Настроить мониторинг доступного пространства (Prometheus alert на imagefs.available).
  • Тестировать изменения на одном узле перед массовым раскатом.

• Для разработчика / владельца приложения:

  • Минимизировать размер образов (multi-stage builds, сжатие).
  • Использовать теги и политику retention для registry.
  • Документировать требования к дисковому пространству в манифесте приложения.

• Для команды CI/CD:

  • Автоматически чистить локальные артефакты между сборками.
  • Учитывать время cold-pull при изменении порогов.

Критерии приёмки

• После изменения параметров image-gc или eviction: свободное место должно быть в пределах ожидаемого поведения для выбранных порогов.
• Логи kubelet не содержат неожиданных ошибок, связанных с отсутствием образов.
• Контейнеры не теряют способность перезапускаться из-за удалённых артефактов.
• Мониторинг показывает отсутствие частых пиков pull-операций, вызванных преждевременным удалением образов.

Совместимость и миграция

• Проверяйте версию Kubernetes: evictions постепенно улучшают поддержку в разных релизах. Перед миграцией узнайте, какие ресурсы поддерживаются для soft/hard eviction в вашей версии.
• Если вы используете нестандартный контейнерный рантайм (containerd, cri-o, Docker), убедитесь, что рантайм корректно отрабатывает удаление образов по командам Kubelet.

Короткое руководство по тестированию (mini-methodology)

1. Выберите тестовый узел или ноду в staging.
2. Сымитируйте заполнение диска (создайте временные файлы в тестовом разделе) или загрузите набор образов.
3. Примените новые флаги Kubelet и перезапустите kubelet.
4. Наблюдайте за логами Kubelet и за метриками дискового пространства в течение 30–60 минут.
5. Откатите изменения, если поведение негативно влияет на латентность запуска подов.

Однострочный глоссарий

• Kubelet — агент, запускающийся на каждом узле, отвечает за контейнеры и взаимодействует с контейнерным рантаймом.
• imagefs — файловая система/раздел, где хранятся образы контейнеров.
• Eviction — механизм выселения/удаления ресурсов при дефиците.

Короткое резюме

Kubernetes автоматически очищает неиспользуемые образы и остановленные контейнеры через Kubelet. Настройки image-gc и параметры удаления контейнеров позволяют корректировать поведение. В долгосрочной перспективе рекомендуется переходить на систему evictions для унифицированного управления ресурсами. Всегда тестируйте изменения и избегайте ручного удаления артефактов.