Збір сміття
Збирання сміття — це загальний термін для різних механізмів, які 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
і знаходяться в кеші контролера збірки сміття. Кеш контролера збірки сміття не може містити обʼєкти, тип ресурсу яких не може бути успішно перелічений / переглянутий, або обʼєкти, які створюються одночасно з видаленням обʼєкта-власника. Дивіться Використання каскадного видалення на передньому плані, щоб дізнатися більше.
Каскадне видалення у фоні
При фоновому каскадному видаленні сервер Kubernetes API негайно видаляє обʼєкт-власник, а контролер збирача сміття (ваш власний або стандартний) очищає залежні обʼєкти у фоновому режимі. Якщо існує завершувач, він гарантує, що обʼєкти не будуть видалені, доки не будуть виконані всі необхідні завдання з очищення. Типово Kubernetes використовує каскадне видалення у фоні, якщо ви не використовуєте видалення вручну на передньому плані або не вибираєте залишити залежні обʼєкти.
Дивіться Використання каскадного видалення у фоні, щоб дізнатися більше.
Залишені залежності
Коли Kubernetes видаляє обʼєкт власника, залишені залежні обʼєкти називаються залишеними обʼєктами. Типово Kubernetes видаляє залежні обʼєкти. Щоб дізнатися, як перевизначити цю поведінку, дивіться Видалення власників та залишені залежності.
Збір сміття невикористаних контейнерів та образів
kubelet виконує збір сміття невикористаних образів кожні дві хвилини та невикористаних контейнерів кожну хвилину. Ви повинні уникати використання зовнішніх інструментів для збору сміття, оскільки вони можуть порушити поведінку kubelet та видаляти контейнери, які повинні існувати.
Щоб налаштувати параметри для збору сміття невикористаних контейнерів та образів, налаштуйте kubelet за допомогою файлу конфігурації та змініть параметри, повʼязані зі збором сміття, використовуючи ресурс типу KubeletConfiguration
.
Життєвий цикл образу контейнера
Kubernetes керує життєвим циклом всіх образів через свій менеджер образів, який є частиною kubelet, співпрацюючи з cadvisor. Kubelet враховує наступні обмеження щодо використання дискового простору при прийнятті рішень про збір сміття:
HighThresholdPercent
LowThresholdPercent
Використання дискового простору вище встановленого значення HighThresholdPercent
викликає збір сміття, який видаляє образи в порядку їх останнього використання, починаючи з найстаріших. Kubelet видаляє образи до тих пір, поки використання дискового простору не досягне значення LowThresholdPercent
.
Збір сміття для невикористаних контейнерних образів
Kubernetes v1.30 [beta]
(стандартно увімкнено: true)Як бета-функцію, ви можете вказати максимальний час, протягом якого локальний образ може бути невикористаний, незалежно від використання дискового простору. Це налаштування kubelet, яке ви вказуєте для кожного вузла.
Щоб налаштувати параметр встановіть значення поля imageMaximumGCAge
в файлі конфігурації kubelet.
Значення вказується як тривалість. Дивіться визначення тривалості в глосарії для отримання докладних відомостей
Наприклад, ви можете встановити значення поля конфігурації 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, який очищає завершені завдання.