# Сборщик мусора

LLMS index: [llms.txt](/llms.txt)

---

<!-- overview -->
Сбор мусора — это собирательный термин для различных механизмов, используемых Kubernetes для очистки ресурсов кластера. Это позволить очистить ресурсы, такие как:

  * [Неудачные pod-ы](/docs/concepts/workloads/pods/pod-lifecycle/#pod-garbage-collection)
  * [Завершенные задания](/docs/concepts/workloads/controllers/ttlafterfinished/)
  * [Объекты без ссылок на владельца Objects](#owners-dependents)
  * [Не используемые контейнеры и образы контейнеров](#containers-images)
  * [Dynamically provisioned PersistentVolumes with a StorageClass reclaim policy of Delete](/docs/concepts/storage/persistent-volumes/#delete)
  * [Устаревшие или просроченные запросы подписания сертификатов (CSR)](/docs/reference/access-authn-authz/certificate-signing-requests/#request-signing-process)
  * <a class='glossary-tooltip' title='Узел — рабочая машина в Kubernetes.' data-bs-toggle='tooltip' data-bs-placement='top' href='/ru/docs/concepts/architecture/nodes/' target='_blank' aria-label='Nodes'>Nodes</a> удалено в следующих сценариях:
    * В облаке, когда кластер использует [диспетчер облачных контроллеров](/docs/concepts/architecture/cloud-controller/)
    * Локально когда кластер использует дополнение, аналогичное диспетчер облачных контроллеров
  * [Объекты аренды узлов](/docs/concepts/architecture/nodes/#heartbeats)

## Владельцы и зависимости {#owners-dependents}

Многие объекты в Kubernetes ссылаются друг на друга через [*ссылки владельцев*](/docs/concepts/overview/working-with-objects/owners-dependents/). 
Ссылки владельцев сообщают управляющему слою, какие объекты зависят от других.
Kubernetes использует ссылки владельцев, чтобы предоставить управляющему слою и другим API
клиентам, возможность очистить связанные ресурсы перед удалением объекта. В большинстве случаев, Kubernetes автоматически управляет ссылками владельцев.

Владелец отличается от [меток и селекторов](/docs/concepts/overview/working-with-objects/labels/)
которые также используют некоторые ресурсы. Например, рассмотрим
<a class='glossary-tooltip' title='Способ представления приложения, запущенного в наборе подов, в виде сетевого сервиса.' data-bs-toggle='tooltip' data-bs-placement='top' href='/ru/docs/concepts/services-networking/service/' target='_blank' aria-label='Службу'>Службу</a> которая создает объект
`EndpointSlice`. Служба использует *метки* чтобы позволить управляющему слою определить, какие  `EndpointSlice` объекты используются для этой службы. В дополнение 
к меткам, каждый `EndpointSlice` управляет ои имени службы, имеет
ссылку владельца. Ссылки владельцев помогают различным частям Kubernetes избегать
вмешательства в объекты, которые они не контролируют.


<div class="alert alert-info" role="note"><h4 class="alert-heading">Примечание:</h4><p>Ссылки на владельцев перекрестных пространств имен запрещены по дизайну.
Зависимости пространства имен могут указывать на область действия кластера или владельцев пространства имен.
Владелец пространства имен <strong>должен</strong> быть в том же пространстве имен, что и зависимости.
Если это не возможно, ссылка владельца считается отсутствующей и зависимый объект подлежит удалению, как только будет проверено отсутствие всех владельцев.</p>
<p>Зависимости области действия кластер может указывать только владельцев области действия кластера.
В версии v1.20+, если зависимость с областью действия кластера указывает на пространство имен как владелец,
тогда он рассматривается как имеющий неразрешимую ссылку на владельца и не может быть обработан сборщиком мусора.</p>
<p>В версии v1.20+, если сборщик мусора обнаружит недопустимое перекрестное пространство имен <code>ownerReference</code>,
или зависящие от области действия кластера <code>ownerReference</code> ссылка на тип пространства имен, предупреждающее событие с причиной <code>OwnerRefInvalidNamespace</code> и <code>involvedObject</code> сообщающее о недействительной зависимости.
Вы можете проверить наличие такого рода событий, выполнив <code>kubectl get events -A --field-selector=reason=OwnerRefInvalidNamespace</code>.</p>
</div>


## Каскадное удаление {#cascading-deletion}

Kubernetes проверяет и удаляет объекты, на которые больше нет ссылок владельцев, так же как и pod-ов, оставленных после удаления ReplicaSet. Когда Вы удаляете объект, вы можете контролировать автоматический ли Kubernetes удаляет зависимые объекты автоматически в процессе вызова *каскадного удаления*. Существует два типа каскадного удаления, а именно: 

  * Каскадное удаление Foreground
  * Каскадное удаление Background

Вы так же можете управлять как и когда сборщик мусора удаляет ресурсы, на которые ссылаются владельцы с помощью Kubernetes <a class='glossary-tooltip' title='A namespaced key that tells Kubernetes to wait until specific conditions are met before it fully deletes an object marked for deletion.' data-bs-toggle='tooltip' data-bs-placement='top' href='/ru/docs/concepts/overview/working-with-objects/finalizers/' target='_blank' aria-label='finalizers'>finalizers</a>. 

### Каскадное удаление Foreground {#foreground-deletion}

В Каскадном удалении Foreground, объект владельца, который вы удаляете, сначала переходить в состояние *в процессе удаления*. В этом состоянии с объектом-владельцем происходить следующее: 

  * Сервер Kubernetes API устанавливает полю объекта `metadata.deletionTimestamp`
    время, когда объект был помечен для удаления.
  * Сервер Kubernetes API так же устанавливает метку  `metadata.finalizers`для поля
    `foregroundDeletion`. 
  * Объект остается видимым благодаря Kubernetes API пока процесс удаления не завершиться

После того как владелец объекта переходит в состояние прогресса удаления, контроллер удаляет зависимые объекты. После удаления всех зависимых объектов, контроллер удаляет объект владельца. На этом этапе, объект больше не отображается в Kubernetes API. 

Во время каскадного удаления foreground, единственным зависимым, которые блокируют удаления владельца, являются те, у кого имеется поле `ownerReference.blockOwnerDeletion=true`.
Чтобы узнать больше. Смотрите [Использование каскадного удаления foreground](/docs/tasks/administer-cluster/use-cascading-deletion/#use-foreground-cascading-deletion).

### Каскадное удаление Background {#background-deletion}

В каскадном удалении background, сервер Kubernetes API немедленно удаляет владельца объекта, а контроллер очищает зависимые объекты в фоновом режиме. По умолчанию, Kubernetes использует каскадное удаление background, если вы в ручную не используете удаление foreground или не решите отключить зависимые объекты.

Чтобы узнать больше. Смотрите [Использование каскадного удаления background](/docs/tasks/administer-cluster/use-cascading-deletion/#use-background-cascading-deletion).

### Осиротевшие зависимости

Когда Kubernetes удаляет владельца объекта, оставшиеся зависимости называются *осиротевшими* объектами. По умолчанию, Kubernetes удаляет зависимые объекты. Чтобы узнать, как переопределить это поведение смотрите [Удаление объектов владельца и осиротевших зависимостей](/docs/tasks/administer-cluster/use-cascading-deletion/#set-orphan-deletion-policy).

## Сбор мусора из неиспользуемых контейнеров и образов {#containers-images}

<a class='glossary-tooltip' title='Агент, работающий на каждом узле в кластере. Он следит за тем, чтобы контейнеры были запущены в поде.' data-bs-toggle='tooltip' data-bs-placement='top' href='/ru/docs/reference/command-line-tools-reference/kubelet' target='_blank' aria-label='kubelet'>kubelet</a> выполняет сбор мусора для неиспользуемых образов каждые пять минут и для неиспользуемых контейнеров каждую минуту. Вам следует избегать использования внешних инструментов для сборки мусора, так как они могут
нарушить поведение kubelet и удалить контейнеры, которые должны существовать. 

Чтобы настроить параметры для сборщика мусора для неиспользуемого контейнера и сборки мусора образа, подстройте 
kubelet использую [конфигурационный файл](/docs/tasks/administer-cluster/kubelet-config-file/)
и измените параметры, связанные со сборщиком мусора используя тип ресурса
[`KubeletConfiguration`](/docs/reference/config-api/kubelet-config.v1beta1/#kubelet-config-k8s-io-v1beta1-KubeletConfiguration).

### Жизненный цикл контейнерных образов Container image lifecycle

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

  * `HighThresholdPercent`
  * `LowThresholdPercent`

Использование диска выше настроенного значения `HighThresholdPercent` запускает сборку мусора, которая удаляет образы в порядке основанном на последнем использовании, начиная с самого старого. Kubelet удаляет образы до тех пор, пока использование диска не достигнет значения  `LowThresholdPercent`.

### Сборщик мусора контейнерных образов {#container-image-garbage-collection}

Kubelet собирает не используемые контейнеры на основе следующих переменных, которые вы можете определить: 

  * `MinAge`: минимальный возраст, при котором kubelet может начать собирать мусор контейнеров. Отключить, установив значение `0`.
  * `MaxPerPodContainer`: максимальное количество неактивных контейнеров, которое может быть у каждой пары Pod-ов. Отключить, установив значение меньше чем `0`.
  * `MaxContainers`: максимальное количество не используемых контейнеров, которые могут быть в кластере. Отключить, установив значение меньше чем `0`. 

В дополнение к этим переменным, kubelet собирает неопознанные и удаленные контейнеры, обычно начиная с самого старого. 

`MaxPerPodContainer` и `MaxContainer` могут потенциально конфликтовать друг с другом в ситуациях, когда требуется максимальное количество контейнеров в Pod-е (`MaxPerPodContainer`) выйдет за пределы допустимого общего количества глобальных не используемых контейнеров (`MaxContainers`). В этой ситуации kubelet регулирует `MaxPodPerContainer` для устранения конфликта. Наихудшим сценарием было бы понизить `MaxPerPodContainer` да `1` и изгнать самые старые контейнеры.
Кроме того, владельцы контейнеров в pod-е могут быть удалены, как только они становятся старше чем `MinAge`.


<div class="alert alert-info" role="note"><h4 class="alert-heading">Примечание:</h4>Kubelet собирает мусор только у контейнеров, которыми он управляет.</div>


## Настройка сборщик мусора {#configuring-gc}

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

  * [Настройка каскадного удаления объектов Kubernetes](/docs/tasks/administer-cluster/use-cascading-deletion/)
  * [Настройка очистки завершенных заданий](/docs/concepts/workloads/controllers/ttlafterfinished/)
  
<!-- * [Configuring unused container and image garbage collection](/docs/tasks/administer-cluster/reconfigure-kubelet/) -->

## Что дальше

* Узнайте больше о [ownership of Kubernetes objects](/docs/concepts/overview/working-with-objects/owners-dependents/).
* Узнайте больше о Kubernetes [finalizers](/docs/concepts/overview/working-with-objects/finalizers/).
* Узнать о [TTL контроллере](/docs/concepts/workloads/controllers/ttlafterfinished/) (beta) that cleans up finished Jobs.