Збір сміття
Збирання сміття — це загальний термін для різних механізмів, які Kubernetes використовує для очищення ресурсів кластера. Це дозволяє очищати ресурси, такі як:
- Припиненні Podʼи
- Завершені завдання (Jobs)
- Обʼєкти без власників
- Невикористані контейнери та образи контейнерів
- Динамічно створені томи PersistentVolumes із політикою вилучення StorageClass Delete
- Застарілі або прострочені запити на підпис сертифікатів (CSRs)
- Видалені вузли в наступних сценаріях:
- У хмарі, коли кластер використовує керування контролером хмари
- На місці, коли кластер використовує надбудову, схожу на контролер хмари
- Обʼєкти Node Lease
Власники та залежності
Багато обʼєктів в Kubernetes повʼязані один з одним через посилання на власника. Посилання на власника повідомляють панелі управління, які обʼєкти залежать від інших. Kubernetes використовує посилання на власника для того, щоб дати панелі управління та іншим клієнтам API можливість очищати повʼязані ресурси перед видаленням обʼєкта. У більшості випадків Kubernetes автоматично керує посиланнями на власника.
Власність відрізняється від механізму міток та селекторів, які також використовують деякі ресурси. Наприклад, розгляньте Service, який створює обʼєкти EndpointSlice
. Сервіс використовує мітки, щоб дозволити панелі управління визначити, які обʼєкти EndpointSlice
використовуються для цього Сервісу. Кожен обʼєкт EndpointSlice
, який керується Сервісом, має власників. Посилання на власника допомагають різним частинам Kubernetes уникати втручання в обʼєкти, якими вони не керують.
Примітка:
Посилання на власника через простір імен заборонені зазначеною концепцією. Обʼєкти, які використовують простори імен можуть вказувати власників загального простору імен або простору імен. Власник простору імен повинен існувати в тому ж просторі імен, що і залежний обʼєкт. Якщо цього не відбувається, таке посилання вважається відсутнім, і залежний обʼєкт підлягає видаленню після перевірки відсутності всіх власників.
Обʼєкти залежні від загального простору імен можуть вказувати тільки загальних власників. У v1.20+, якщо залежний обʼєкт, який залежить від класу, вказує простор імен як власника, йому не вдасться вирішити посилання на власника та його не можна буде прибрати через збирання сміття.
У v1.20+, якщо збирач сміття виявляє недійсний перехресний простір імен ownerReference
або кластерний залежний з ownerReference
, що посилається на тип простору імен, повідомляється про попереджувальну подію з причиною OwnerRefInvalidNamespace
та involvedObject
недійсного залежного елемента. Ви можете перевірити наявність такого роду подій, запустивши kubectl get events -A --field-selector=reason=OwnerRefInvalidNamespace
.
Каскадне видалення
Kubernetes перевіряє та видаляє обʼєкти, які більше не мають власників, наприклад, Podʼи, які залишилися після видалення ReplicaSet. Коли ви видаляєте обʼєкт, ви можете контролювати, чи автоматично видаляє Kubernetes залежні обʼєкти, у процесі, що називається каскадним видаленням. Існують два типи каскадного видалення:
- Каскадне видалення на передньому плані
- Каскадне видалення у фоні
Ви також можете контролювати те, як і коли збирання сміття видаляє ресурси, які мають посилання на власника, використовуючи завершувачі Kubernetes.
Каскадне видалення на передньому плані
У каскадному видаленні на передньому плані обʼєкт власника, який видаляється, спочатку потрапляє в стан deletion in progress. У цьому стані стається наступне для обʼєкта власника:
- Сервер API Kubernetes встановлює поле
metadata.deletionTimestamp
обʼєкта на час, коли обʼєкт був позначений на видалення. - Сервер API Kubernetes також встановлює поле
metadata.finalizers
вforegroundDeletion
. - Обʼєкт залишається видимим через API Kubernetes, поки не буде завершений процес видалення.
Після того як обʼєкт власника потрапляє в стан видалення в процесі, контролер видаляє залежні обʼєкти. Після видалення всіх залежних обʼєктів контролер видаляє обʼєкт власника. На цьому етапі обʼєкт більше не є видимим в API Kubernetes.
Під час каскадного видалення на передньому плані тільки ті залежні обʼєкти, які мають поле ownerReference.blockOwnerDeletion=true
, блокують видалення власника. Дивіться Використання каскадного видалення на передньому плані, щоб дізнатися більше.
Каскадне видалення у фоні
В каскадному видаленні у фоні сервер API Kubernetes видаляє обʼєкт власника негайно, а контролер видаляє залежні обʼєкти в фоновому режимі. Типово Kubernetes використовує каскадне видалення у фоні, якщо ви не використовуєте видалення вручну на передньому плані або не вибираєте залишити залежні обʼєкти.
Дивіться Використання каскадного видалення у фоні, щоб дізнатися більше.
Залишені залежності
Коли Kubernetes видаляє обʼєкт власника, залишені залежні обʼєкти називаються залишеними обʼєктами. Типово Kubernetes видаляє залежні обʼєкти. Щоб дізнатися, як перевизначити цю поведінку, дивіться Видалення власників та залишені залежності.
Збір сміття невикористаних контейнерів та образів
kubelet виконує збір сміття невикористаних образів кожні дві хвилини та невикористаних контейнерів кожну хвилину. Ви повинні уникати використання зовнішніх інструментів для збору сміття, оскільки вони можуть порушити поведінку kubelet та видаляти контейнери, які повинні існувати.
Щоб налаштувати параметри для збору сміття невикористаних контейнерів та образів, налаштуйте kubelet за допомогою файлу конфігурації та змініть параметри, повʼязані зі збором сміття, використовуючи ресурс типу KubeletConfiguration
.
Життєвий цикл образу контейнера
Kubernetes керує життєвим циклом всіх образів через свій менеджер образів, який є частиною kubelet, співпрацюючи з cadvisor. Kubelet враховує наступні обмеження щодо використання дискового простору при прийнятті рішень про збір сміття:
HighThresholdPercent
LowThresholdPercent
Використання дискового простору вище встановленого значення HighThresholdPercent
викликає збір сміття, який видаляє образи в порядку їх останнього використання, починаючи з найстаріших. Kubelet видаляє образи до тих пір, поки використання дискового простору не досягне значення LowThresholdPercent
.
Збір сміття для невикористаних контейнерних образів
Kubernetes v1.30 [beta]
Як бета-функцію, ви можете вказати максимальний час, протягом якого локальний образ може бути невикористаний, незалежно від використання дискового простору. Це налаштування kubelet, яке ви вказуєте для кожного вузла.
Щоб налаштувати параметр, увімкніть feature gate ImageMaximumGCAge
для kubelet, а також встановіть значення поля ImageMaximumGCAge
в файлі конфігурації kubelet.
Значення вказується як duration Kubernetes; Допустимі одиниці часу для поля ImageMaximumGCAge
у файлі конфігурації kubelet:
- «ns» для наносекунд
- «us» або «µs» для мікросекунд
- «ms» для мілісекунд
- «s» для секунд
- «m» для хвилин
- «h» для годин
Наприклад, ви можете встановити значення поля конфігурації 12h45m
, що означає 12 годин 45 хвилин.
Примітка:
Ця функція не відстежує використання образів kubeletʼами під час перезапуску. Якщо kubelet перезапускається, вік відстежуваного образу скидається, що призводить до того, що kubelet очікує повний проміжок часуImageMaximumGCAge
перед тим як кваліфікувати образ для прибирання збирачем сміття на основі віку образу.Збір сміття контейнерів
Kubelet збирає сміття невикористаних контейнерів на основі наступних змінних, які ви можете визначити:
MinAge
: мінімальний вік, при якому kubelet може видаляти контейнер. Вимкніть, встановивши на значення0
.MaxPerPodContainer
: максимальна кількість мертвих контейнерів які кожен Pod може мати. Вимкніть, встановивши менше0
.MaxContainers
: максимальна кількість мертвих контейнерів у кластері. Вимкніть, встановивши менше0
.
Крім цих змінних, kubelet збирає сміття невизначених та видалених контейнерів, як правило, починаючи з найстарших.
MaxPerPodContainer
та MaxContainers
можуть потенційно конфліктувати одне з одним в ситуаціях, де збереження максимальної кількості контейнерів на кожен Pod (MaxPerPodContainer
) вийде за допустиму загальну кількість глобальних мертвих контейнерів (MaxContainers
). У цій ситуації kubelet коригує MaxPerPodContainer
для вирішення конфлікту. У найгіршому випадку може бути знижений MaxPerPodContainer
до 1
та видалені найдавніші контейнери. Крім того, контейнери, які належать Podʼам, які були видалені, видаляються, якщо вони старше MinAge
.
Примітка:
Kubelet збирає сміття лише для контейнерів, якими він керує.Налаштування збору сміття
Ви можете налаштовувати збір сміття ресурсів, налаштовуючи параметри, специфічні для контролерів, що керують цими ресурсами. На наступних сторінках показано, як налаштовувати збір сміття:
- Налаштування каскадного видалення обʼєктів Kubernetes
- Налаштування очищення завершених завдань (Jobs)
Що далі
- Дізнайтеся більше про власність обʼєктів Kubernetes.
- Дізнайтеся більше про завершувачі Kubernetes.
- Дізнайтеся про контролер TTL, який очищає завершені завдання.