Понимание и настройка сборки мусора Kubernetes

Сборка мусора — это процесс, с помощью которого Kubernetes удаляет зависимые объекты после удаления ресурса. Он также выполняет автоматическую очистку избыточных элементов в вашем кластере. Готовые контейнеры и неиспользуемые образы периодически удаляются, чтобы предотвратить накопление большого количества ненужных ресурсов с течением времени.

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

Базовая сборка мусора

Сборщик мусора Kubernetes обрабатывает удаление зависимых объектов, старых контейнеров и неиспользуемых образов. Kubelet периодически запускает операции очистки, пока его служба активна. Он удалит остановленные контейнеры, например, из завершенных заданий, и удалит неиспользуемые образы, как только будет достигнут определенный порог использования диска.

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

Ссылки владельца

Отношения родитель-потомок выражаются ссылками владельца Kubernetes. Владельцы несут ответственность за вложенные в них объекты. Это создает граф зависимостей, который информирует процесс сборки мусора.

Kubernetes использует эталонные данные владельца, чтобы определить, какие ресурсы следует удалить перед удалением цели. Например, поды, являющиеся частью набора реплик, будут иметь ссылку на владельца, определяющую эту ссылку. Удаление ReplicaSet также автоматически удалит внутри него поды.

Ссылки на владельцев задаются для объектов в их поле манифеста metadata.ownerReference. Обычно вам не нужно проверять или изменять это поле вручную, поскольку ссылки на владельца автоматически управляются контроллерами Kubernetes.

Дети могут заблокировать удаление своих родителей, установив в поле metadata.blockOwnerDeletion логическое значение true. Это предотвратит удаление родителей в цепочке ownerReference объекта до тех пор, пока сам объект не будет удален.

Каскадные механизмы удаления

Цепочка ссылок владельца означает, что существует два способа удаления объектов:

Фоновое удаление: сначала удаляется целевой объект, а затем его зависимые элементы.
Удаление переднего плана: сначала удаляются зависимые объекты, а затем целевой объект.

Рассмотрим команду удаления, например следующую:

$ kubectl delete deployment/demo-app

Метод фонового удаления немедленно удалит объект развертывания demo-app. Это оставит его модули работающими в вашем кластере. Они будут автоматически удалены в фоновом режиме в рамках процесса сборки мусора.

Удаление переднего плана начинается с пометки развертывания demo-app как «выполняется удаление». Затем он удаляет все зависимые объекты, которые существуют внутри него. Развертывание demo-app останется видимым в вашем кластере, пока его модули не будут удалены. Развертывание будет очищено после удаления иждивенцев.

Фоновое каскадирование — это механизм по умолчанию. Он предлагает немедленный результат, который удаляет целевой объект из вашего кластера без задержки. Однако в некоторых сценариях удаление переднего плана может быть более желательным, например, когда вы хотите, чтобы Deployment или ReplicaSet удалялись только после того, как его модули были уничтожены. Это позволяет избежать короткого периода, когда поды фактически остаются осиротевшими, а их владелец ReplicaSet уже ушел.

Вы можете согласиться на удаление переднего плана, передав флаг --cascade=foreground команде kubectl delete:

$ kubectl delete deployment/demo-app --cascade=foreground

Будут удалены модули, а затем развертывание demo-app.

Отключение сборки мусора зависимых элементов

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

$ kubectl delete deployment/demo-app --cascade=orphan

Эта команда немедленно удаляет развертывание demo-app, но оставляет его модули нетронутыми. Они будут продолжать работать в вашем кластере, пока не будут удалены отдельно как часть другой команды. Хотя такое поведение редко бывает желательным, оно может быть полезно, если вы решите, что подам больше не нужно находиться в Deployment или ReplicaSet.

Сборка мусора и финализаторы

Финализаторы также влияют на работу сборки мусора. Они предотвращают удаление до тех пор, пока не будут выполнены определенные условия.

Многие явно «застрявшие» удаления вызваны ожидающими финализаторами. Финализатор, который не помечен как завершенный, предотвратит удаление объекта из вашего кластера. После очистки финализатора плоскость управления Kubernetes продолжит удаление.

Некоторые финализаторы включены в Kubernetes, например, защита pv-protection от удаления активно используемых томов. Другие могут быть добавлены сторонними контроллерами, которые вы добавляете в свой кластер. Не рекомендуется переопределять финализатор, так как это может создать неправильное состояние, которое приведет к неожиданному поведению.

Настройка сборки мусора неиспользуемых ресурсов

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

maximum-dead-containers — максимальное количество старых контейнеров, которые могут продолжать существовать после запуска сборки мусора. Значение по умолчанию -1 снимает ограничение.
maximum-dead-containers-per-container — установите максимальное количество сохраняемых старых контейнеров для каждого контейнера. Это определяет, сколько предыдущих версий контейнера остается в кластере после запуска новой замены.
minimum-container-ttl-duration — Контейнеры становятся доступными для сборки мусора через столько минут после их остановки. Значение по умолчанию 0 отключает задержку.
image-gc-high-threshold — когда использование диска достигает этого процента, Kubelet попытается отсеять неиспользуемые изображения…
image-gc-low-threshold – … чтобы снизить использование до этого уровня.

Эти параметры устанавливаются как флаги запуска Kubelet. Флаги обычно помещаются в /var/lib/kubelet/kubeadm-flags.env:

KUBELET_KUBEADM_ARGS="--image-gc-high-threshold=60 --image-gc-low-threshold=50 --minimum-container-ttl-duration=5"

Эта конфигурация позволит автоматически удалять контейнеры, которые были избыточными в течение как минимум пяти минут. Каждый проход сборки мусора также будет пытаться удалить старые образы, как только будет достигнуто 60% использования диска, с целью снизить потребление до 50%.

Вы должны перезапустить процесс Kubelet после внесения этих изменений:

$ sudo systemctl daemon-reload
$ sudo systemctl restart kubelet

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

Краткое содержание

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

Для достижения наилучших результатов вы должны придерживаться механизмов, которые предоставляет Kubernetes. Проект предостерегает от использования сторонних инструментов для сборки мусора, поскольку они могут создавать несогласованности состояний, вызывающие проблемы в вашем кластере.