Сборщик мусора
Сбор мусора — это собирательный термин для различных механизмов, используемых Kubernetes для очистки ресурсов кластера. Это позволить очистить ресурсы, такие как:
- Неудачные pod-ы
- Завершенные задания
- Объекты без ссылок на владельца Objects
- Не используемые контейнеры и образы контейнеров
- Dynamically provisioned PersistentVolumes with a StorageClass reclaim policy of Delete
- Устаревшие или просроченные запросы подписания сертификатов (CSR)
- Nodes удалено в следующих сценариях:
- В облаке, когда кластер использует диспетчер облачных контроллеров
- Локально когда кластер использует дополнение, аналогичное диспетчер облачных контроллеров
- Объекты аренды узлов
Владельцы и зависимости
Многие объекты в Kubernetes ссылаются друг на друга через ссылки владельцев. Ссылки владельцев сообщают управляющему слою, какие объекты зависят от других. Kubernetes использует ссылки владельцев, чтобы предоставить управляющему слою и другим API клиентам, возможность очистить связанные ресурсы перед удалением объекта. В большинстве случаев, Kubernetes автоматически управляет ссылками владельцев.
Владелец отличается от меток и селекторов
которые также используют некоторые ресурсы. Например, рассмотрим
Службу которая создает объект
EndpointSlice. Служба использует метки чтобы позволить управляющему слою определить, какие EndpointSlice объекты используются для этой службы. В дополнение
к меткам, каждый EndpointSlice управляет ои имени службы, имеет
ссылку владельца. Ссылки владельцев помогают различным частям Kubernetes избегать
вмешательства в объекты, которые они не контролируют.
Примечание:
Ссылки на владельцев перекрестных пространств имен запрещены по дизайну. Зависимости пространства имен могут указывать на область действия кластера или владельцев пространства имен. Владелец пространства имен должен быть в том же пространстве имен, что и зависимости. Если это не возможно, ссылка владельца считается отсутствующей и зависимый объект подлежит удалению, как только будет проверено отсутствие всех владельцев.
Зависимости области действия кластер может указывать только владельцев области действия кластера. В версии v1.20+, если зависимость с областью действия кластера указывает на пространство имен как владелец, тогда он рассматривается как имеющий неразрешимую ссылку на владельца и не может быть обработан сборщиком мусора.
В версии v1.20+, если сборщик мусора обнаружит недопустимое перекрестное пространство имен ownerReference,
или зависящие от области действия кластера ownerReference ссылка на тип пространства имен, предупреждающее событие с причиной OwnerRefInvalidNamespace и involvedObject сообщающее о недействительной зависимости.
Вы можете проверить наличие такого рода событий, выполнив kubectl get events -A --field-selector=reason=OwnerRefInvalidNamespace.
Каскадное удаление
Kubernetes проверяет и удаляет объекты, на которые больше нет ссылок владельцев, так же как и pod-ов, оставленных после удаления ReplicaSet. Когда Вы удаляете объект, вы можете контролировать автоматический ли Kubernetes удаляет зависимые объекты автоматически в процессе вызова каскадного удаления. Существует два типа каскадного удаления, а именно:
- Каскадное удаление Foreground
- Каскадное удаление Background
Вы так же можете управлять как и когда сборщик мусора удаляет ресурсы, на которые ссылаются владельцы с помощью Kubernetes finalizers.
Каскадное удаление Foreground
В Каскадном удалении Foreground, объект владельца, который вы удаляете, сначала переходить в состояние в процессе удаления. В этом состоянии с объектом-владельцем происходить следующее:
- Сервер Kubernetes API устанавливает полю объекта
metadata.deletionTimestampвремя, когда объект был помечен для удаления. - Сервер Kubernetes API так же устанавливает метку
metadata.finalizersдля поляforegroundDeletion. - Объект остается видимым благодаря Kubernetes API пока процесс удаления не завершиться
После того как владелец объекта переходит в состояние прогресса удаления, контроллер удаляет зависимые объекты. После удаления всех зависимых объектов, контроллер удаляет объект владельца. На этом этапе, объект больше не отображается в Kubernetes API.
Во время каскадного удаления foreground, единственным зависимым, которые блокируют удаления владельца, являются те, у кого имеется поле ownerReference.blockOwnerDeletion=true.
Чтобы узнать больше. Смотрите Использование каскадного удаления foreground.
Каскадное удаление Background
В каскадном удалении background, сервер Kubernetes API немедленно удаляет владельца объекта, а контроллер очищает зависимые объекты в фоновом режиме. По умолчанию, Kubernetes использует каскадное удаление background, если вы в ручную не используете удаление foreground или не решите отключить зависимые объекты.
Чтобы узнать больше. Смотрите Использование каскадного удаления background.
Осиротевшие зависимости
Когда Kubernetes удаляет владельца объекта, оставшиеся зависимости называются осиротевшими объектами. По умолчанию, Kubernetes удаляет зависимые объекты. Чтобы узнать, как переопределить это поведение смотрите Удаление объектов владельца и осиротевших зависимостей.
Сбор мусора из неиспользуемых контейнеров и образов
kubelet выполняет сбор мусора для неиспользуемых образов каждые пять минут и для неиспользуемых контейнеров каждую минуту. Вам следует избегать использования внешних инструментов для сборки мусора, так как они могут нарушить поведение kubelet и удалить контейнеры, которые должны существовать.
Чтобы настроить параметры для сборщика мусора для неиспользуемого контейнера и сборки мусора образа, подстройте
kubelet использую конфигурационный файл
и измените параметры, связанные со сборщиком мусора используя тип ресурса
KubeletConfiguration.
Жизненный цикл контейнерных образов Container image lifecycle
Kubernetes управляет жизненным циклом всех образов с помощью своего менеджера образов, которые являются частью kubelet, в сотрудничестве с cadvisor. При принятии решений о сборке мусора, kubelet учитывает следующие ограничения использования диска:
HighThresholdPercentLowThresholdPercent
Использование диска выше настроенного значения HighThresholdPercent запускает сборку мусора, которая удаляет образы в порядке основанном на последнем использовании, начиная с самого старого. Kubelet удаляет образы до тех пор, пока использование диска не достигнет значения LowThresholdPercent.
Сборщик мусора контейнерных образов
Kubelet собирает не используемые контейнеры на основе следующих переменных, которые вы можете определить:
MinAge: минимальный возраст, при котором kubelet может начать собирать мусор контейнеров. Отключить, установив значение0.MaxPerPodContainer: максимальное количество неактивных контейнеров, которое может быть у каждой пары Pod-ов. Отключить, установив значение меньше чем0.MaxContainers: максимальное количество не используемых контейнеров, которые могут быть в кластере. Отключить, установив значение меньше чем0.
В дополнение к этим переменным, kubelet собирает неопознанные и удаленные контейнеры, обычно начиная с самого старого.
MaxPerPodContainer и MaxContainer могут потенциально конфликтовать друг с другом в ситуациях, когда требуется максимальное количество контейнеров в Pod-е (MaxPerPodContainer) выйдет за пределы допустимого общего количества глобальных не используемых контейнеров (MaxContainers). В этой ситуации kubelet регулирует MaxPodPerContainer для устранения конфликта. Наихудшим сценарием было бы понизить MaxPerPodContainer да 1 и изгнать самые старые контейнеры.
Кроме того, владельцы контейнеров в pod-е могут быть удалены, как только они становятся старше чем MinAge.
Примечание:
Kubelet собирает мусор только у контейнеров, которыми он управляет.Настройка сборщик мусора
Вы можете настроить сборку мусора ресурсов, настроив параметры, специфичные для контроллеров, управляющих этими ресурсами. В последующих страницах показано, как настроить сборку мусора:
Что дальше
- Узнайте больше о ownership of Kubernetes objects.
- Узнайте больше о Kubernetes finalizers.
- Узнать о TTL контроллере (beta) that cleans up finished Jobs.