Merge pull request #29626 from mshalmanov/main
[ru] Add translate garbage-collection.md file in the content/ru/docs/…pull/29629/head
Kubernetes Prow Robot
GitHub
commit
a8071cca02
|
|
@ -0,0 +1,134 @@
|
|||
---
|
||||
title: Сборщик мусора
|
||||
content_type: concept
|
||||
weight: 50
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
{{<glossary_definition term_id="garbage-collection" length="short">}} Это позволить очистить ресурсы, такие как:
|
||||
|
||||
* [Неудачные 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)](/reference/access-authn-authz/certificate-signing-requests/#request-signing-process)
|
||||
* {{<glossary_tooltip text="Nodes" term_id="node">}} удалено в следующих сценариях:
|
||||
* В облаке, когда кластер использует [диспетчер облачных контроллеров](/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/)
|
||||
которые также используют некоторые ресурсы. Например, рассмотрим
|
||||
{{<glossary_tooltip text="Службу" term_id="service">}} которая создает объект
|
||||
`EndpointSlice`. Служба использует *метки* чтобы позволить плоскости управления определить какие `EndpointSlice` объекты используются для этой службы. В дополнение
|
||||
к меткам, каждый `EndpointSlice` управляет ои имени службы, имеет
|
||||
ссылку владельца. Ссылки владельцев помогают различным частям Kubernetes избегать
|
||||
вмешательства в объекты, которые они не контролируют.
|
||||
|
||||
{{< note >}}
|
||||
Ссылки на владельцев перекрестных пространств имен запрещены по дизайну.
|
||||
Зависимости пространства имен могут указывать на область действия кластера или владельцев пространства имен.
|
||||
Владелец пространства имен **должен** быть в том же пространстве имен что и зависимости.
|
||||
Если это не возможно, cсылка владельца считается отсутствующей и зависимый объект подлежит удалению, как только будет проверено отсутствие всех владельцев.
|
||||
|
||||
Зависимости области действия кластер может указывать только владельцев области действия кластера.
|
||||
В версии v1.20+, если зависимость с областью действия кластера указывает на пространство имен как владелец,
|
||||
тогда он рассматривается как имеющий неразрешимую ссылку на владельца и не может быть обработан сборщиком мусора.
|
||||
|
||||
В версии v1.20+, если сборщик мусора обнаружит недопустимое перекрестное пространство имен `ownerReference`,
|
||||
или зависящие от облости действия кластера `ownerReference` ссылка на тип пространства имен, предупреждающее событие с причиной `OwnerRefInvalidNamespace` и `involvedObject` сообщающеся о не действительной зависимости.
|
||||
Вы можете проверить наличие такого рода событий, выполнив `kubectl get events -A --field-selector=reason=OwnerRefInvalidNamespace`.
|
||||
{{< /note >}}
|
||||
|
||||
## Каскадное удаление {#cascading-deletion}
|
||||
|
||||
Kubernetes проверяет и удаляет объекты, на которые больше нет ссылок владельцев, так же как и pod-ов, оставленных после удаления ReplicaSet. Когда Вы удаляете объект, вы можете контролировать автоматический ли Kubernetes удаляет зависимые объекты автоматически в процессе вызова *каскадного удаления*. Существует два типа каскадного удаления, а именно:
|
||||
|
||||
* Каскадное удалени Foreground
|
||||
* Каскадное удаление Background
|
||||
|
||||
Вы так же можете управлять как и когда сборщик мусора удаляет ресурсы, на которые ссылаются владельцы с помощью Kubernetes {{<glossary_tooltip text="finalizers" term_id="finalizer">}}.
|
||||
|
||||
### Каскадное удалени 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}
|
||||
|
||||
{{<glossary_tooltip text="kubelet" term_id="kubelet">}} выполняет сбор мусора для неиспользуемых образов каждые пять минут и для неиспользуемых контейнеров каждую минуту. Вам следует избегать использования внешних инструментов для сборки мусора, так как они могут
|
||||
нарушить поведение 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`.
|
||||
|
||||
{{<note>}}
|
||||
Kubelet собирает мусор только у контейнеров, которыми он управляет.
|
||||
{{</note>}}
|
||||
|
||||
## Настройка сборщик мусора {#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/) -->
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
* Узнайте больше о [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.
|
||||
|
|
@ -0,0 +1,23 @@
|
|||
---
|
||||
title: Сборшик мусора
|
||||
id: garbage-collection
|
||||
date: 2021-07-07
|
||||
full_link: /docs/concepts/workloads/controllers/garbage-collection/
|
||||
short_description: >
|
||||
A collective term for the various mechanisms Kubernetes uses to clean up cluster
|
||||
resources.
|
||||
|
||||
aka:
|
||||
tags:
|
||||
- fundamental
|
||||
- operation
|
||||
---
|
||||
Сборщик мусора - это собирательный термин для различных механизмов? используемых Kubernetes для очистки ресурсов кластера.
|
||||
|
||||
<!--more-->
|
||||
|
||||
Kubernetes использует сборку мусора для очистки таких ресурсов, как [неиспользуемые контейнеры и образы](/docs/concepts/workloads/controllers/garbage-collection/#containers-images),
|
||||
[неудачные Pod-ы](/docs/concepts/workloads/pods/pod-lifecycle/#pod-garbage-collection),
|
||||
[объекты, принадлежащие целевому ресурсу](/docs/concepts/overview/working-with-objects/owners-dependents/),
|
||||
[завершенные задачи](/docs/concepts/workloads/controllers/ttlafterfinished/), and resources
|
||||
that have expired or failed.
|
||||
Loading…
Reference in New Issue