|
| 1 | +--- |
| 2 | +title: Сборщик мусора |
| 3 | +content_type: concept |
| 4 | +weight: 50 |
| 5 | +--- |
| 6 | + |
| 7 | +<!-- overview --> |
| 8 | +{{<glossary_definition term_id="garbage-collection" length="short">}} Это позволить очистить ресурсы, такие как: |
| 9 | + |
| 10 | + * [Неудачные pod-ы](/docs/concepts/workloads/pods/pod-lifecycle/#pod-garbage-collection) |
| 11 | + * [Завершенные задания](/docs/concepts/workloads/controllers/ttlafterfinished/) |
| 12 | + * [Объекты без ссылок на владельца Objects](#owners-dependents) |
| 13 | + * [Не используемые контейнеры и образы контейнеров](#containers-images) |
| 14 | + * [Dynamically provisioned PersistentVolumes with a StorageClass reclaim policy of Delete](/docs/concepts/storage/persistent-volumes/#delete) |
| 15 | + * [Устаревшие или просроченные запросы подписания сертификатов (CSR)](/reference/access-authn-authz/certificate-signing-requests/#request-signing-process) |
| 16 | + * {{<glossary_tooltip text="Nodes" term_id="node">}} удалено в следующих сценариях: |
| 17 | + * В облаке, когда кластер использует [диспетчер облачных контроллеров](/docs/concepts/architecture/cloud-controller/) |
| 18 | + * Локально когда кластер использует дополнение, аналогичное диспетчер облачных контроллеров |
| 19 | + * [Объекты аренды узлов](/docs/concepts/architecture/nodes/#heartbeats) |
| 20 | + |
| 21 | +## Владельцы и зависимости {#owners-dependents} |
| 22 | + |
| 23 | +Многие объекты в Kubernetes ссылаются друг на друга через [*ссылки владельцев*](/docs/concepts/overview/working-with-objects/owners-dependents/). |
| 24 | +Ссылки владельцев сообщают плоскости управления какие объекты зависят от других. |
| 25 | +Kubernetes использует ссылки владельцев, чтобы предоставить плоскости управления и другим API |
| 26 | +клиентам, возможность очистить связанные ресурсы передудалением объекта. В большинстве случаев, Kubernetes автоматический управляет ссылками владельцев. |
| 27 | + |
| 28 | +Владелец отличается от [меток и селекторов](/docs/concepts/overview/working-with-objects/labels/) |
| 29 | +которые также используют некоторые ресурсы. Например, рассмотрим |
| 30 | +{{<glossary_tooltip text="Службу" term_id="service">}} которая создает объект |
| 31 | +`EndpointSlice`. Служба использует *метки* чтобы позволить плоскости управления определить какие `EndpointSlice` объекты используются для этой службы. В дополнение |
| 32 | +к меткам, каждый `EndpointSlice` управляет ои имени службы, имеет |
| 33 | +ссылку владельца. Ссылки владельцев помогают различным частям Kubernetes избегать |
| 34 | +вмешательства в объекты, которые они не контролируют. |
| 35 | + |
| 36 | +{{< note >}} |
| 37 | +Ссылки на владельцев перекрестных пространств имен запрещены по дизайну. |
| 38 | +Зависимости пространства имен могут указывать на область действия кластера или владельцев пространства имен. |
| 39 | +Владелец пространства имен **должен** быть в том же пространстве имен что и зависимости. |
| 40 | +Если это не возможно, cсылка владельца считается отсутствующей и зависимый объект подлежит удалению, как только будет проверено отсутствие всех владельцев. |
| 41 | + |
| 42 | +Зависимости области действия кластер может указывать только владельцев области действия кластера. |
| 43 | +В версии v1.20+, если зависимость с областью действия кластера указывает на пространство имен как владелец, |
| 44 | +тогда он рассматривается как имеющий неразрешимую ссылку на владельца и не может быть обработан сборщиком мусора. |
| 45 | + |
| 46 | +В версии v1.20+, если сборщик мусора обнаружит недопустимое перекрестное пространство имен `ownerReference`, |
| 47 | +или зависящие от облости действия кластера `ownerReference` ссылка на тип пространства имен, предупреждающее событие с причиной `OwnerRefInvalidNamespace` и `involvedObject` сообщающеся о не действительной зависимости. |
| 48 | +Вы можете проверить наличие такого рода событий, выполнив `kubectl get events -A --field-selector=reason=OwnerRefInvalidNamespace`. |
| 49 | +{{< /note >}} |
| 50 | + |
| 51 | +## Каскадное удаление {#cascading-deletion} |
| 52 | + |
| 53 | +Kubernetes проверяет и удаляет объекты, на которые больше нет ссылок владельцев, так же как и pod-ов, оставленных после удаления ReplicaSet. Когда Вы удаляете объект, вы можете контролировать автоматический ли Kubernetes удаляет зависимые объекты автоматически в процессе вызова *каскадного удаления*. Существует два типа каскадного удаления, а именно: |
| 54 | + |
| 55 | + * Каскадное удалени Foreground |
| 56 | + * Каскадное удаление Background |
| 57 | + |
| 58 | +Вы так же можете управлять как и когда сборщик мусора удаляет ресурсы, на которые ссылаются владельцы с помощью Kubernetes {{<glossary_tooltip text="finalizers" term_id="finalizer">}}. |
| 59 | + |
| 60 | +### Каскадное удалени Foreground {#foreground-deletion} |
| 61 | + |
| 62 | +В Каскадном удалени Foreground, объект владельца, который вы удаляете, сначало переходить в состояние *в процессе удаления*. В этом состоянии с объектом-владельцем происходить следующее: |
| 63 | + |
| 64 | + * Сервер Kubernetes API устанавливает полю объекта `metadata.deletionTimestamp` |
| 65 | + время, когда объект был помечен для удаления. |
| 66 | + * Сервер Kubernetes API так же устанавливает метку `metadata.finalizers`для поля |
| 67 | + `foregroundDeletion`. |
| 68 | + * Объект остается видимым блогодоря Kubernetes API пока процесс удаления не завершиться |
| 69 | + |
| 70 | +После того, как владелец объекта переходит в состояние прогресса удаления, контроллер удаляет зависимые объекты. После удаления всех зависимых объектов, контроллер удаляет объект владельца. На этом этапе, объект больше не отображается в Kubernetes API. |
| 71 | + |
| 72 | +Во время каскадного удаления foreground, единственным зависимым, которые блокируют удаления владельца, являются те, у кого имеется поле `ownerReference.blockOwnerDeletion=true`. |
| 73 | +Чтобы узнать больше. Смотрите [Использование каскадного удаления foreground](/docs/tasks/administer-cluster/use-cascading-deletion/#use-foreground-cascading-deletion). |
| 74 | + |
| 75 | +### Каскадное удаление Background {#background-deletion} |
| 76 | + |
| 77 | +В каскадном удалении background, сервер Kubernetes API немедленно удаляет владельца объекта, а контроллер очищает зависимые объекты в фоновом режиме. По умолчанию, Kubernetes использует каскадное удаление background, если вы в ручную не используете удаление foreground или не решите отключить зависимые объекты. |
| 78 | + |
| 79 | +Чтобы узнать больше. Смотрите [Использование каскадного удаления background](/docs/tasks/administer-cluster/use-cascading-deletion/#use-background-cascading-deletion). |
| 80 | + |
| 81 | +### Осиротевшие зависимости |
| 82 | + |
| 83 | +Когда Kubernetes удаляет владельца объекта, оставшиеся зависимости называются *осиротевшыми* объектами. По умолчанию, Kubernetes удаляет зависимые объекты. Чтобы узнать, как переопределить это повидение смотрите [Удаление объектов владельца и осиротевших зависимостей](/docs/tasks/administer-cluster/use-cascading-deletion/#set-orphan-deletion-policy). |
| 84 | + |
| 85 | +## Сбор мусора из неиспользуемых контейнеров и изобробразов {#containers-images} |
| 86 | + |
| 87 | +{{<glossary_tooltip text="kubelet" term_id="kubelet">}} выполняет сбор мусора для неиспользуемых образов каждые пять минут и для неиспользуемых контейнеров каждую минуту. Вам следует избегать использования внешних инструментов для сборки мусора, так как они могут |
| 88 | +нарушить поведение kubelet и удалить контейнеры, которые должны существовать. |
| 89 | + |
| 90 | +Чтобы настроить параметры для сборшика мусора для неиспользуемого контейнера и сборки мусора образа, подстройте |
| 91 | +kubelet использую [конфигурационный файл](/docs/tasks/administer-cluster/kubelet-config-file/) |
| 92 | +и измените параметры, связанные со сборшиком мусора используя тип ресурса |
| 93 | +[`KubeletConfiguration`](/docs/reference/config-api/kubelet-config.v1beta1/#kubelet-config-k8s-io-v1beta1-KubeletConfiguration). |
| 94 | + |
| 95 | +### Жизненный цикл контейнерных образов Container image lifecycle |
| 96 | + |
| 97 | +Kubernetes управляет жизненным циклом всех образов с помощью своего *менеджера образов*, которые являются частью kubelet, в сотрудничестве с cadvisor. При принятии решений о сборке мусора, kubelet учитывает следующие ограничения использования диска: |
| 98 | + |
| 99 | + * `HighThresholdPercent` |
| 100 | + * `LowThresholdPercent` |
| 101 | + |
| 102 | +Использование диска выше настроенного значения `HighThresholdPercent` запускает сборку мусора, которая удаляет образы в порядке основанном на последнем использовании, начиная с самого старого. kubelet удлаяет образы до тех пор, пока использование диска не достигнет значения `LowThresholdPercent`. |
| 103 | + |
| 104 | +### Сборщик мусора контейнерных образов {#container-image-garbage-collection} |
| 105 | + |
| 106 | +kubelet собирает не используемые контейнеры на основе следующих переменных, которые вы можете определить: |
| 107 | + |
| 108 | + * `MinAge`: минимальный возраст, при котором kubelet может начать собирать мусор контейнеров. Отключить, установив значение `0`. |
| 109 | + * `MaxPerPodContainer`: максимальное количество некативныз контейнеров, которое может быть у каджой пары Pod-ов. Отключить, установив значение меньше чем `0`. |
| 110 | + * `MaxContainers`: максимальное количество не используемых контейнеров, которые могут быть в кластере. Отключить, установив значение меньше чем `0`. |
| 111 | + |
| 112 | +В дополнение к этим переменным, kubelet собирает неопознанные и удаленные контейнеры, обычно начиная с самого старого. |
| 113 | + |
| 114 | +`MaxPerPodContainer` и `MaxContainer` могут потенциально конфликтовать друг с другом в ситуациях, когда требуется максимальное количество контейнеров в Pod-е (`MaxPerPodContainer`) выйдет за пределы допустимого общего количества глобальных не используемых контейнеров (`MaxContainers`). В этой ситуации kubelet регулирует `MaxPodPerContainer` для устранения конфликта. наихудшим сценарием было бы понизить `MaxPerPodContainer` да `1` и изгнать самые старые контейнеры. |
| 115 | +Кроме того, владельцы контейнеров в pod-е могут быть удалены, как только они становятся старше чем `MinAge`. |
| 116 | + |
| 117 | +{{<note>}} |
| 118 | +Kubelet собирает мусор только у контейнеров, которыми он управляет. |
| 119 | +{{</note>}} |
| 120 | + |
| 121 | +## Настройка сборщик мусора {#configuring-gc} |
| 122 | + |
| 123 | +Вы можете настроить сборку мусора ресурсов, настроив параметры, специфичные для контроллеров, управляющих этими ресурсами. В последующих страницах показанно, как настроить сборку мусора: |
| 124 | + |
| 125 | + * [Настройка каскадного удаления объектов Kubernetes](/docs/tasks/administer-cluster/use-cascading-deletion/) |
| 126 | + * [Настройка очистки завершенных заданий](/docs/concepts/workloads/controllers/ttlafterfinished/) |
| 127 | + |
| 128 | +<!-- * [Configuring unused container and image garbage collection](/docs/tasks/administer-cluster/reconfigure-kubelet/) --> |
| 129 | + |
| 130 | +## {{% heading "whatsnext" %}} |
| 131 | + |
| 132 | +* Узнайте больше о [ownership of Kubernetes objects](/docs/concepts/overview/working-with-objects/owners-dependents/). |
| 133 | +* Узнайте больше о Kubernetes [finalizers](/docs/concepts/overview/working-with-objects/finalizers/). |
| 134 | +* Узнать о [TTL контроллере](/docs/concepts/workloads/controllers/ttlafterfinished/) (beta) that cleans up finished Jobs. |
0 commit comments