Kubernetes: сбор мусора и выселения

Логотип Kubernetes на абстрактном фоне

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

Container Images
Clearing Old Containers
Should I Manually Intervene?
The Future: Evictions
Summary

Обзор

Активный кластер Kubernetes накапливает остановленные контейнеры и неиспользуемые образы. Когда такие артефакты остаются на узлах, они занимают диск и могут вызвать проблемы с размещением новых подов. Kubelet — рабочий процесс, запускающийся на каждом узле — управляет автоматической очисткой образов и контейнеров. Цель этой статьи — объяснить, как это работает, какие флаги настраивать, и как подготовиться к переходу на систему выселений.

Важно: Kubelet — это компонент, отвечающий за жизненный цикл контейнеров и управление ресурсами на узле. Изменения в его конфигурации влияют на стабильность узла.

Container Images

Kubelet включает встроенную систему сборки мусора для очистки неиспользуемых образов. Она оценивает, какие образы можно удалить, основываясь на двух ключевых факторах:

занятость диска для образов (imagefs),
время последнего использования образа.

Правило выбора — Kubelet будет удалять объекты, пытаясь снизить использование диска ниже «низкого» порога, когда оно превышает «высокий» порог. Обычно большие образы, давно не использовавшиеся, удаляются раньше маленьких, недавно использовавшихся.

Вы можете задать пороговые значения, чтобы контролировать агрессивность сборки мусора.

Флаги, управляющие порогами

--image-gc-high-threshold — верхний порог (по умолчанию 85%). Когда использование диска превышает этот процент, запускается сборка мусора.
--image-gc-low-threshold — нижний порог (по умолчанию 80%). Сборка мусора попытается снизить использование до этого уровня.

Пример записи в файле конфигурации, который обычно присутствует на узле:

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

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

После изменения файла выполните перезагрузку конфигурации системных юнитов и перезапустите kubelet:

systemctl daemon-reload
systemctl restart kubelet

Примечание: в различных дистрибутивах и установках kubelet-флаги могут храниться в других местах (например, systemd drop-in, kubelet.service.d). Убедитесь, что редактируете правильный файл на каждом узле.

Когда стоит снижать пороги

Узлы с ограничённым диском: снизьте пороги до более агрессивных значений (например, high=60, low=50).
Нагрузочные кластеры с частыми развёртываниями: более агрессивная очистка предотвратит накопление образов.

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

Clearing Old Containers

Kubelet также удаляет остановленные и неизвестные контейнеры. Для этого есть несколько связанных флагов:

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

Эти флаги позволяют задать границы: например, оставить несколько последних экземпляров контейнера для отладки, но удалить более старые.

Should I Manually Intervene?

Короткий ответ: обычно нет. Не рекомендуется вручную удалять образ или контейнеры через внешние инструменты или напрямую удалять файлы на узле. Такое вмешательство может нарушить соответствие ожиданий Kubelet и создать неконсистентное состояние.

Если вы видите, что диск заполняется, сначала скорректируйте настройки Kubelet: уменьшите image-gc-* пороги, установите minimum-container-ttl-duration и задайте лимиты мёртвых контейнеров. Только если автоматические механизмы не справляются — исследуйте причины (например, логи, трейсинг pull-операций, ошибки реестра).

Важно: внешняя очистка, выполненная без учёта состояния Kubelet, может привести к тому, что Kubelet будет пытаться восстановить отсутствующие артефакты, что в свою очередь увеличит сетевой трафик и задержки старта подов.

The Future: Evictions

Парадигма управления ресурсами в Kubernetes движется к системе выселений (evictions). Она унифицирует правила удаления ресурсов, обрабатывая не только образы и контейнеры, но и остановки подов при нехватке памяти, inode и других ресурсов.

Evictions поддерживают два режима:

Жёсткое выселение (hard eviction) — немедленные действия без льготного периода.
Мягкое выселение (soft eviction) — с настраиваемым льготным периодом. Если проблема исчезает в течение периода, действие отменяется.

Примеры флагов для Kubelet:

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

Эта команда указывает Kubelet немедленно пытаться удалить неиспользуемые образы, если доступное место для imagefs стало меньше 1 GiB.

Мягкий пример:

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

Здесь ресурсы будут рассмотрены к удалению только если условие сохраняется не менее 5 минут.

Примечание: части старой конфигурации, связанные с dead-containers, уже отмечены как deprecated и со временем будут заменены на эквиваленты в системе evictions.

Практическая методология (минимальная)

Сбор данных: мониторьте imagefs и rootfs, количество мёртвых контейнеров, частоту pull-операций.
Оценка риска: определите критичные узлы и приложения, чувствительные к времени старта или к недоступности реестра.
Тестирование: на тестовых узлах примените более агрессивные пороги и наблюдайте поведение.
Внедрение: поэтапно применяйте изменения на продакшн-узлах, отслеживая метрики.
Миграция: переключайтесь на eviction-флаги, удаляя устаревшие dead-containers конфигурации.

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

Администратор кластера

Проверить текущие значения image-gc-* и maximum-dead-containers на каждом узле.
Настроить мониторинг свободного места для imagefs.
Подготовить план отката изменений конфигурации kubelet.

DevOps / SRE

Тестировать время старта подов при удалении образов.
Настроить алерты на превышение image-gc-high-threshold и частые pull-ошибки.
Они же — планировать релизы с учётом возможных задержек скачивания образов.

Разработчики

Снижение размеров образов: multi-stage builds, удаление ненужных слоёв.
Использование immutable tags или digest для предсказуемости кеширования образов.

Шаблоны конфигурации и подсказки (cheat sheet)

Консервативные настройки (подходит для узлов с большим диском):

--image-gc-high-threshold=85
--image-gc-low-threshold=80
--minimum-container-ttl-duration=0
--maximum-dead-containers=-1

Агрессивные настройки (узлы с ограниченным диском):

--image-gc-high-threshold=60
--image-gc-low-threshold=50
--minimum-container-ttl-duration=10m
--maximum-dead-containers=5
--maximum-dead-containers-per-container=2

Примеры для evictions (рекомендуется тестировать перед применением в prod):

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

Фикс: используйте единицы — Ki, Mi, Gi — чтобы исключить двусмысленность.

Модель принятия решений (heuristic)

Если узел часто достигает high-threshold → снизьте high и low или включите evictions.
Если поды долго стартуют после очистки образов → увеличьте low-threshold или обеспечьте локальный pull-through cache.
Если реестр ненадёжен → избегайте агрессивного удаления образов.

flowchart TD
  A[Проблема: мало места] --> B{Диск imagefs заполнен?}
  B -- Да --> C{Eviction настроен?}
  B -- Нет --> D[Проверить rootfs и inode]
  C -- Да --> E[Оценить hard/soft и grace period]
  C -- Нет --> F[Настроить image-gc пороги как временное решение]
  E --> G[Применить и наблюдать]
  F --> G
  G --> H[Тесты: pull время, рестарт подов]
  H --> I[Внедрение в prod по этапам]

Факт-бокс — ключевые значения

По умолчанию: image-gc-high-threshold = 85%, image-gc-low-threshold = 80%.
default minimum-container-ttl-duration = 0 (без льготного периода).
Evictions поддерживают мягкий (soft) и жёсткий (hard) режимы.

Контрпримеры и когда автоматическая очистка не сработает

Если реестр образов недоступен, удаление образов приведёт к ошибкам pull и длительному запуску подов.
При наличии критичных приложений с долгим стартом — агрессивная очистка ухудшит стабильность.
На узлах с нестандартной разметкой диска Kubelet может неправильно оценивать imagefs и rootfs; требуется дополнительная проверка конфигурации.

Советы по безопасности и соответствию

Логи удаления образов и контейнеров должны храниться в централизованный системе логирования для аудита.
При настройке eviction-флагов документируйте причины и план отката.
Будьте осторожны при автоматическом удалении: убедитесь, что резервные политики и backup’ы учтены.

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

Старые флаги, управляемые для dead-containers, помечены как deprecated; планируйте миграцию на evictions.
Тестируйте миграцию на тестовой группе узлов до массового развёртывания.
Проверяйте версию Kubernetes и changelog Kubelet для известных изменений в поведении сборки мусора.

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

Метрики imagefs снижаются до заданных low-threshold в тестовой среде без критического увеличения времени старта подов.
Логи и алерты не показывают неожиданных ошибок pull после применения новых настроек.
План отката проверен и работает для каждого изменённого узла.

Резюме

Kubelet по умолчанию управляет сборкой мусора образов и удалением остановленных контейнеров. Для гибкого и однородного управления ресурсами в кластере рекомендован переход на механизм evictions, который объединяет правила удаления и вводит поддержу льготного периода для мягких выселений. Настройка image-gc-* остаётся полезной для быстрых и инкрементальных корректировок, но долгосрочная стратегия должна учитывать evictions и резервирование образов. Тестируйте изменения поэтапно, документируйте и используйте role-based чеклисты.

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

Конец статьи.