Життєвий цикл Pod
Ця сторінка описує життєвий цикл Pod. Podʼи слідують визначеному життєвому циклу, починаючи з фази Pending
, переходячи до фази Running
, якщо принаймні один з його основних контейнерів запускається добре, а потім до фаз Succeeded
або Failed
, залежно від того, чи завершився будь-який контейнер у Pod з помилкою.
Поки Pod працює, kubelet може перезапускати контейнери, щоб вирішити деякі види несправностей. У межах Pod Kubernetes відстежує різні стани контейнера і визначає дії, які слід вжити, щоб знову забезпечити справність Pod.
В API Kubernetes у Pod є як специфікація, так і фактичний стан. Стан для обʼєкта Pod складається з набору станів Pod. Ви також можете вставляти власні дані готовності в дані стани для Pod, якщо це корисно для вашого застосунку.
Podʼи плануються лише один раз протягом свого життя. Як тільки Pod призначено (сплановано) для вузла, Pod працює на цьому вузлі до тих пір, поки не зупиниться або не буде завершений.
Тривалість життя Pod
Podʼи, подібно окремим контейнерам застосунків, вважаються відносно ефемерними (а не постійними) обʼєктами. Podʼи створюються, отримують унікальний ідентифікатор (UID) і призначаються вузлам, де вони залишаються до моменту завершення (відповідно до політики перезапуску) або видалення. Якщо вузол відмовляє, Podʼи, призначені до цього вузла, призначаються для видалення після періоду затримки.
Самі по собі Podʼи не здатні до самовідновлення. Якщо Pod призначено до вузла, який потім відмовляє, Pod видаляється; подібно до того, Pod не виживе при відмові через відсутність ресурсів або обслуговування вузла. Kubernetes використовує більш абстрактний рівень, який називається контролер, який відповідає за управління відносно одноразовими екземплярами Podʼа.
Даний Pod (визначений UID) ніколи не "переплановується" на інший вузол; замість цього, цей Pod може бути замінений новим, майже ідентичним Podʼом, навіть з тією самою назвою, якщо це потрібно, але з іншим UID.
Коли говорять, що щось має такий самий термін життя, як і Pod, таке як volume, це означає, що ця річ існує стільки часу, скільки існує цей конкретний Pod (з таким самим UID). Якщо цей Pod буде видалений з будь-якої причини, і навіть якщо буде створений ідентичний замінник, повʼязана річ (у цьому прикладі — том) також буде знищена і створена знову.
Діаграма Podʼа
Багатоконтейнерний Pod, який містить витягувач файлів та вебсервер, який використовує постійний том для спільного сховища для контейнерів.
Фази Pod
Поле status
обʼєкта PodStatus Podʼа містить поле phase
.
Фази Pod — це простий, високорівневий підсумок того, на якому етапі свого життєвого циклу знаходиться Pod. Фаза не призначена бути всеосяжним підсумком спостережень за станом контейнера чи Pod, і бути процесом за спостереженням стану.
Кількість та значення фаз Pod є строго прописаними. Крім того, що зазначено тут, не слід вважати, що щось відомо про Podʼи з певним значенням phase
.
Ось можливі значення для phase
:
Значення | Опис |
---|---|
Pending | Pod прийнятий кластером Kubernetes, але один чи кілька контейнерів ще не було налаштовано та готові до запуску. Це включає час, який Pod витрачає на очікування планування, а також час, який витрачається на завантаження образів контейнерів з мережі. |
Running | Pod привʼязаний до вузла, і всі контейнери створені. Принаймні один контейнер все ще працює або перебуває у процесі запуску чи перезапуску. |
Succeeded | Всі контейнери в Podʼі завершили роботу успішно і не будуть перезапущені. |
Failed | Всі контейнери в Podʼі завершили роботу, і принаймні один контейнер завершився з помилкою. Іншими словами, контейнер вийшов зі статусом, відмінним від нуля, або його завершила система, і контейнер не налаштований на автоматичний перезапуск. |
Unknown | З якоїсь причини не вдалося отримати стан Podʼа. Ця фаза, як правило, виникає через помилку в комунікації з вузлом, де повинен виконуватися Pod. |
Примітка:
Коли Pod видаляється, за деякими командами kubectl він позначається якTerminating
. Цей статус Terminating
не є однією з фаз Podʼа. Pod отримує термін на відповідне завершення, який типово становить 30 секунд. Ви можете використовувати прапорець --force
для примусового завершення роботи Podʼа.Починаючи з Kubernetes 1.27, kubelet переводить видалені Podʼи, крім статичних Podʼів та примусово видалених Podʼів без завершувача, в термінальну фазу (Failed
або Succeeded
залежно від статусів exit контейнерів Podʼа) перед їх видаленням із сервера API.
Якщо вузол вмирає або відключається від іншої частини кластера, Kubernetes застосовує політику встановлення phase
всіх Podʼів на втраченому вузлі у Failed.
Стани контейнера
Окрім фаз Podʼа загалом Kubernetes відстежує стан кожного контейнера всередині Podʼа. Ви можете використовувати хуки життєвого циклу контейнера, щоб запускати події на певних етапах життєвого циклу контейнера.
Як тільки планувальник призначає Pod вузлу, kubelet починає створювати контейнери для цього Podʼа, використовуючи середовище виконання контейнерів. Існує три можливі стани контейнера: Waiting
(Очікування), Running
(Виконання) та Terminated
(Завершено).
Щоб перевірити стан контейнерів Podʼа, ви можете використовувати kubectl describe pod <ім'я-пода>
. Вивід показує стан для кожного контейнера в межах цього Podʼа.
Кожен стан має конкретне значення:
Waiting
Якщо контейнер не перебуває в стані або Running
, або Terminated
, то він знаходиться в стані Waiting
(Очікування). Контейнер в стані Waiting
все ще виконує операції, які він потребує для завершення запуску: наприклад, витягує образ контейнера із реєстру образів контейнерів або застосовує Secret. Коли ви використовуєте kubectl
для опитування Podʼа із контейнером, який перебуває в стані Waiting
, ви також бачите поле Reason, щоб узагальнити причину, чому контейнер знаходиться в цьому стані.
Running
Статус Running
вказує на те, що виконання контейнера відбувається без проблем. Якщо існує налаштований хук postStart
— його роботу завершено. Коли ви використовуєте kubectl
для опитування Podʼа із контейнером, який перебуває в стані Running
, ви також бачите інформацію про те, коли контейнер увійшов в стан Running
.
Terminated
Контейнер в стані Terminated
розпочав виконання і потім або завершив його успішно, або зазнав відмови з певних причин. Коли ви використовуєте kubectl
для опитування Podʼа із контейнером, який перебуває в стані Terminated
, ви бачите причину, код виходу та час початку та завершення періоду виконання цього контейнера.
Якщо у контейнера є налаштований хук preStop
, цей хук запускається перед тим, як контейнер увійде в стан Terminated
.
Як Podʼи вирішують проблеми з контейнерами
Kubernetes порається з відмовами контейнерів в межах Podʼів за допомогою політики перезапуску, визначеної в spec
Podʼа. Ця політика визначає, як Kubernetes реагує на виходи контейнерів через помилки або інші причини, які складаються з наступних етапів:
- Початковий збій: Kubernetes намагається негайно перезапустити контейнер на основі політики перезапуску Podʼа.
- Повторні збої: Після початкового збою Kubernetes застосовує експоненційну затримку для наступних перезапусків, описане в
restartPolicy
. Це запобігає швидким, повторним спробам перезапуску, що може перенавантажити систему. - Стан
CrashLoopBackOff
: Це означає, що механізм затримки працює для певного контейнера, який знаходиться в циклі збоїв, невдач і постійного перезапуску. - Скидання затримки: Якщо контейнер успішно працює протягом певного часу (наприклад, 10 хвилин), Kubernetes скидає затримку, розглядаючи будь-який новий збій як перший.
На практиці, CrashLoopBackOff
— це стан або подія, яку можна помітити у виводі команди kubectl
, при описі або перегляді списку Podʼів, коли контейнер в Podʼі не запускається належним чином, а потім безперервно намагається запуститися, але безуспішно.
Іншими словами, коли контейнер увійшов у цикл збоїв, Kubernetes застосовує експоненційну затримку, про яку було згадано в політиці перезапуску контейнера. Цей механізм запобігає неправильному контейнеру перевантажувати систему безперервними невдалими спробами запуску.
CrashLoopBackOff
може бути спричинений проблемами, такими як:
- Помилки застосунків, які призводять до виходу контейнера.
- Помилки конфігурації, такі як неправильні змінні середовища або відсутність конфігураційних файлів.
- Обмеження ресурсів, коли контейнеру може бракувати памʼяті або процесорного часу для правильного запуску.
- Невдалі перевірки готовності, якщо застосунок не починає обслуговувати запити у передбачений час.
- Проблеми контейнерних перевірок готовності або перевірок запуску, що повертають результат
Failure
, як згадано у розділі про перевірки.
Щоб розібратися у причинах CrashLoopBackOff
проблеми, користувач може:
- Перевірити логи: Використовуйте
kubectl logs <name-of-pod>
, щоб перевірити логи контейнера. Це часто є безпосереднім способом діагностики проблеми, що викликає збої. - Перевірити події: Використовуйте
kubectl describe pod <name-of-pod>
для перегляду подій для Podʼа, які можуть надати підказки про проблеми конфігурації або ресурсів. - Перевірити конфігурацію: Переконайтеся, що конфігурація Podʼа, включаючи змінні середовища та змонтовані томи, є правильною і що всі необхідні зовнішні ресурси доступні.
- Перевірити обмеження ресурсів: Переконайтеся, що контейнер має достатньо CPU та памʼяті. Іноді збільшення ресурсів у визначенні Podʼа може вирішити проблему.
- Перевірити застосунок: Можуть існувати помилки або неправильні конфігурації в коді застосунку. Запуск цього образу контейнера локально або в середовищі розробки може допомогти діагностувати проблеми, специфічні для застосунку.
Політика перезапуску контейнера
У полі spec
Podʼа є поле restartPolicy
із можливими значеннями Always, OnFailure та Never. Стандартне значення — Always.
restartPolicy
для Podʼа застосовується до контейнер застосунків в Podʼі та до звичайних контейнерів ініціалізації. Контейнери Sidecar не звертають уваги на поле restartPolicy
на рівні Podʼа: в Kubernetes, sidecar визначається як запис всередині initContainers
, який має свою політику перезапуску контейнера на рівні контейнера, встановлену на Always
. Для контейнерів ініціалізації, які завершують роботу із помилкою, kubelet виконує їх перезапуск, якщо політика перезапуску Podʼа встановлена як OnFailure
або Always
:
Always
: автоматично перезапускає контейнер після його завершення, незалежно від статусу завершення.OnFailure
: перезапускає контейнер тільки після його завершення з помилкою (код виходу відмінний від нуля).Never
: ніколи автоматично не перезапускає контейнер, що завершив роботу.
Коли kubelet обробляє перезапуск контейнера згідно з налаштованою політикою перезапуску, це стосується лише перезапусків, які призводять до заміни контейнерів всередині того ж Podʼа та на тому ж вузлі. Після завершення контейнерів у Podʼі, kubelet перезапускає їх із затримкою, що зростає експоненційно (10 с, 20 с, 40 с, …), і обмеженою пʼятьма хвилинами (300 секунд). Якщо контейнер виконується протягом 10 хвилин без проблем, kubelet скидає таймер затримки перезапуску для цього контейнера. Контейнери Sidecar та життєвий цикл Podʼа пояснює поведінку контейнерів ініціалізації
при вказанні поля restartpolicy
для нього.
Стани Podʼа
У Podʼа є статус, який містить масив PodConditions, через які Pod проходить чи не проходить. Kubelet управляє наступними PodConditions:
PodScheduled
: Pod був запланований на вузол.PodReadyToStartContainers
: (бета-функція; типово увімкнено) Pod sandbox був успішно створений, і була налаштована мережа.ContainersReady
: всі контейнери в Pod готові.Initialized
: всі контейнери ініціалізації успішно завершили виконання.Ready
: Pod може обслуговувати запити і його слід додати до балансування навантаження всіх відповідних Services.
Назва поля | Опис |
---|---|
type | Імʼя цього стану Podʼа. |
status | Вказує, чи застосовується цей стан, з можливими значеннями "True ", "False " або "Unknown ". |
lastProbeTime | Відмітка часу останнього запиту стану Podʼа. |
lastTransitionTime | Відмітка часу для останнього переходу Podʼа з одного статусу в інший. |
reason | Машиночитаний текст у форматі UpperCamelCase, який вказує причину останньої зміни стану. |
message | Повідомлення, яке вказує подробиці щодо останнього переходу стану, яке може розібрати людина. |
Готовність Podʼа
Kubernetes v1.14 [stable]
Ваш застосунок може внести додатковий зворотний звʼязок або сигнали в PodStatus: готовність Podʼа. Щоб використовувати це, встановіть readinessGates
в spec
Podʼа, щоб вказати список додаткових станів, які kubelet оцінює для готовності Podʼа.
Стани готовності визначаються поточним станом полів status.condition
для Podʼа. Якщо Kubernetes не може знайти такий стан в полі status.conditions
Podʼа, стан подається як "False
".
Наприклад:
kind: Pod
...
spec:
readinessGates:
- conditionType: "www.example.com/feature-1"
status:
conditions:
- type: Ready # вбудований стан Podʼа
status: "False"
lastProbeTime: null
lastTransitionTime: 2018-01-01T00:00:00Z
- type: "www.example.com/feature-1" # додатковий стан Podʼа
status: "False"
lastProbeTime: null
lastTransitionTime: 2018-01-01T00:00:00Z
containerStatuses:
- containerID: docker://abcd...
ready: true
...
Стани Podʼа, які ви додаєте, повинні мати імена, які відповідають формату ключа міток Kubernetes.
Стан для готовності Podʼа
Команда kubectl patch
не підтримує зміну статусу обʼєкта накладанням патчів. Щоб встановити ці status.conditions
для Podʼа, застосунки та оператори повинні використовувати дію PATCH
. Ви можете використовувати бібліотеку клієнтів Kubernetes для написання коду, який встановлює власні стани Podʼа для готовності Podʼа.
Для Podʼа, який використовує власні стани, Pod оцінюється як готовий тільки коли застосовуються обидві наступні твердження:
- Всі контейнери в Pod готові.
- Всі стани, вказані в
readinessGates
, рівніTrue
.
Коли контейнери Podʼа готові, але принаймні один власний стан відсутній або False
, kubelet встановлює стан Podʼа ContainersReady в True
.
Готовність мережі Podʼа
Kubernetes v1.29 [beta]
Примітка:
На початкових стадіях створення цей стан називалиPodHasNetwork
.Після того, як Pod отримує призначення на вузол, йому потрібно бути допущеним до kubelet та мати встановлені всі необхідні томи зберігання. Як тільки ці фази завершаться, kubelet співпрацює з середовищем виконання контейнерів (використовуючи Інтерфейс середовища виконання контейнера (CRI)), щоб налаштувати ізольоване середовище виконання та налаштувати мережу для Podʼа. Якщо feature gate PodReadyToStartContainersCondition
увімкнено (є типово увімкненим для Kubernetes 1.30), стан PodReadyToStartContainers
буде додано до поля status.conditions
Podʼа.
Стан PodReadyToStartContainers
встановлюється в False
Kubelet, коли він виявляє, що у Podʼа немає ізольованого середовища виконання із налаштованою мережею. Це трапляється в
наступних випадках:
- На початковому етапі життєвого циклу Podʼа, коли kubelet ще не почав налаштовувати середовище виконання для Podʼа за допомогою середовища виконання контейнерів.
- Пізніше в життєвому циклі Podʼа, коли sandbox Podʼа був знищений через:
- перезавантаження вузла без вилучення Podʼа
- для середовищ виконання контейнерів, які використовують віртуальні машини для ізоляції, Pod sandbox віртуальної машини перезавантажується, що потім вимагає створення нового sandbox та свіжої конфігурації мережі контейнера.
Стан PodReadyToStartContainers
встановлюється в True
kubelet після успішного завершення створення і налаштування ізольованого середовища виконання для Podʼа за допомогою втулка виконання. Kubelet може почати витягувати образ контейнера та створювати контейнери після встановлення стану PodReadyToStartContainers
в True
.
Для Podʼа з контейнерами ініціалізації kubelet встановлює стан Initialized
в True
після успішного завершення контейнерів ініціалізації (що відбувається після успішного створення sandbox та налаштування мережі контейнером втулка виконання). Для Podʼа без контейнерів ініціалізації kubelet встановлює стан Initialized
в True
перед початком створення sandbox та налаштування мережі.
Готовність планування Podʼа
Kubernetes v1.26 [alpha]
Дивіться документацію про стани готовності планування Podʼа.
Діагностика контейнера
Проба (probe) — це діагностика, яку періодично виконує kubelet для контейнера. Для виконання діагностики kubelet або виконує код всередині контейнера, або виконує мережевий запит.
Механізми перевірки
Існує чотири різних способи перевірки контейнера за допомогою проб. Кожна проба повинна визначати один з чотирьох цих механізмів:
exec
- Виконує вказану команду всередині контейнера. Діагностика вважається успішною, якщо команда виходить з кодом стану 0.
grpc
- Виконує віддалений виклик процедури gRPC. Цільовий обʼєкт повинен мати підтримку gRPC health checks. Діагностика вважається успішною, якщо
status
відповіді рівнийSERVING
. httpGet
- Виконує HTTP-запит
GET
до IP-адреси Podʼа з вказаним портом та шляхом. Діагностика вважається успішною, якщо код стану відповіді більший або рівний 200 і менше ніж 400. tcpSocket
- Виконує перевірку TCP до IP-адреси Podʼа за вказаним портом. Діагностика вважається успішною, якщо порт відкритий. Якщо віддалена система (контейнер) відразу закриває зʼєднання після відкриття, це вважається нормальним.
Увага:
На відміну від інших механізмів, виконання пробиexec
передбачає створення/розгалуження кількох процесів при кожному виконанні. В результаті використання проб з exec на кластерах з високою щільністю Pod, низькими інтервалами initialDelaySeconds
, periodSeconds
, конфігуруючи будь-яку пробу з механізмом exec, може виникнути надмірне навантаження на використання центрального процесора вузла. У таких сценаріях розгляньте можливість використання альтернативних механізмів проб, щоб уникнути надмірного навантаження.Результат проби
Кожна проба має один із трьох результатів:
Success
- Контейнер пройшов діагностику.
Failure
- Контейнер не пройшов діагностику.
Unknown
- Діагностика не пройшла (не потрібно вживати жодних заходів, і kubelet буде робити подальші перевірки).
Типи проб
Kubelet може опціонально виконувати та реагувати на три типи проб для робочих контейнерів:
livenessProbe
- Вказує, чи контейнер працює. Якщо ця проба не проходить, kubelet припиняє роботу контейнера, і він підлягає перезапуску відповідно до своєї політики перезапуску. Якщо контейнер не надає пробу життєздатності, стандартний стан —
Success
. readinessProbe
- Вказує, чи готовий контейнер відповідати на запити. Якщо проба готовності завершиться невдачею, контролер endpoint видаляє IP-адресу Podʼа з endpoint усіх служб, які відповідають Podʼу. Стандартний стан готовності перед початковою затримкою —
Failure
. Якщо контейнер не надає пробу готовності, стандартний стан —Success
. startupProbe
- Вказує, чи запущено застосунок всередині контейнера. Усі інші проби вимкнено, якщо надана проба запуску, поки вона не стане успішною. Якщо проба запуску завершиться невдачею, kubelet вбиває контейнер, і він підлягає перезапуску відповідно до політики перезапуску. Якщо контейнер не надає пробу запуску, стандартний стан —
Success
.
Для отримання докладнішої інформації щодо налаштування проб життєздатності, готовності або запуску дивіться Налаштування проб життєздатності, готовності та запуску.
Коли слід використовувати пробу життєздатності?
Якщо процес у вашому контейнері може аварійно завершитися, коли виникає проблема або він стає нездоровим, вам можливо не потрібна проба життєздатності; kubelet автоматично виконає правильну дію згідно з політикою перезапуску Podʼа.
Якщо ви хочете, щоб роботу вашого контейнера було припинено та він був перезапущений у разі невдачі проби, то вказуйте пробу життєздатності та встановлюйте restartPolicy
на Always або OnFailure.
Коли слід використовувати пробу готовності?
Якщо ви хочете розпочати надсилання трафіку до Podʼа лише після успішної проби, вказуйте пробу готовності. У цьому випадку проба готовності може бути такою самою, як і проба життєздатності, але наявність проби готовності в специфікації означає, що Pod розпочне роботу без отримання будь-якого трафіку і почне отримувати трафік лише після успішності проби.
Якщо ви хочете, щоб ваш контейнер міг вимкнутися для обслуговування, ви можете вказати пробу готовності, яка перевіряє конкретний endpoint для готовності, відмінний від проби життєздатності.
Якщо ваш застосунок залежить від бекенд сервісів, ви можете реалізувати як пробу життєздатності, так і пробу готовності. Проба життєздатності пройде, коли саме застосунок є справним, але проба готовності додатково перевірить, що кожна необхідна служба доступна. Це допомагає уникнути направлення трафіку до Podʼів, які можуть відповідати лише повідомленнями про помилки.
Якщо вашому контейнеру потрібно працювати з великими даними, файлами конфігурації або міграціями під час запуску, ви можете використовувати пробу запуску. Однак, якщо ви хочете виявити різницю між застосунком, який зазнав невдачі, і щастосунком, який все ще обробляє дані запуску, вам може більше підійти проба готовності.
Примітка:
Якщо вам потрібно мати можливість забрати запити при видаленні Podʼа, вам, можливо, не потрібна проба готовності; при видаленні Pod автоматично переводить себе в стан неготовності, незалежно від того, чи існує проба готовності. Pod залишається в стані неготовності, поки контейнери в Podʼі не зупиняться.Коли слід використовувати пробу запуску?
Проби запуску корисні для Podʼів, в яких контейнери потребують багато часу, щоб перейти в режим експлуатації. Замість встановлення довгого інтервалу життєздатності, ви можете налаштувати окрему конфігурацію для спостереження за контейнером при запуску, встановивши час, більший, ніж дозволяв би інтервал життєздатності.
Якщо ваш контейнер зазвичай запускається довше, ніж
initialDelaySeconds + failureThreshold × periodSeconds
, вам слід вказати пробу запуску, яка перевіряє той самий endpoint, що й проба життєздатності. Типово для periodSeconds
— 10 секунд. Потім ви повинні встановити його failureThreshold
настільки великим, щоб дозволити контейнеру запускатися, не змінюючи стандартних значень проби життєздатності. Це допомагає захистити від блокування роботи.
Завершення роботи Podʼів
Оскільки Podʼи представляють процеси, які виконуються на вузлах кластера, важливо дозволити цим процесам завершувати роботу відповідним чином, коли вони більше не потрібні (замість раптового зупинення за допомогою сигналу KILL
і відсутності можливості завершити роботу).
Дизайн спрямований на можливість запитування видалення та знання про те, коли процеси завершують роботу, а також можливість забезпечення завершення видалень у настанні строки. Коли ви запитуєте видалення Podʼа, кластер реєструє та відстежує призначений строк належного припинення роботи перед тим, як дозволити примусове закінчення роботи Podʼа. З цим відстеженням примусового завершення, kubelet намагається виконати належне завершення роботи Podʼу.
Зазвичай, з цим належним завершенням роботи, kubelet робить запити до середовища виконання контейнера з метою спроби зупинити контейнери у Podʼі, спочатку надсилаючи сигнал TERM (також відомий як SIGTERM) основному процесу в кожному контейнері з таймаутом для належного завершення. Запити на зупинку контейнерів обробляються середовищем виконання контейнера асинхронно. Немає гарантії щодо порядку обробки цих запитів. Багато середовищ виконання контейнерів враховують значення STOPSIGNAL
, визначене в образі контейнера і, якщо воно відрізняється, надсилають значення STOPSIGNAL, визначене в образі контейнера, замість TERM. Після закінчення строку належного завершення роботи сигнал KILL надсилається до будь-яких залишкових процесів, а потім Pod видаляється з API Server. Якщо kubelet або служба управління середовищем виконання перезапускається під час очікування завершення процесів, кластер повторює спробу спочатку, включаючи повний початковий строк належного завершення роботи.
Приклад роботи:
Ви використовуєте інструмент
kubectl
, щоб вручну видалити певний Pod, з типовим значення строку належного припинення роботи (30 секунд).В Podʼі в API-сервері оновлюється час, поза яким Pod вважається "мертвим", разом із строком належного припинення роботи. Якщо ви використовуєте
kubectl describe
для перевірки Podʼа, який ви видаляєте, цей Pod показується як "Terminating". На вузлі, на якому виконується Pod: як тільки kubelet бачить, що Pod був позначений як такий, що закінчує роботу (встановлений строк для належного вимкнення), kubelet розпочинає локальний процес вимкнення Podʼа.Якщо один із контейнерів Podʼа визначає
preStop
хук, іterminationGracePeriodSeconds
в специфікації Podʼа не встановлено на 0, kubelet виконує цей хук всередині контейнера. СтандартноterminationGracePeriodSeconds
встановлено на 30 секунд.Якщо
preStop
хук все ще виконується після закінчення строку належного припинення роботи, kubelet запитує невелике подовження строку належного припинення роботи в розмірі 2 секунд.Примітка:
Якщо `preStop` хук потребує більше часу для завершення, ніж дозволяє стандартний строк належного припинення роботи, вам слід змінити `terminationGracePeriodSeconds` відповідно до цього.
Kubelet робить виклик до середовища виконання контейнера для надсилання сигналу TERM процесу 1 всередині кожного контейнера.
Примітка:
Контейнери в Podʼі отримують сигнал TERM в різний час та в довільному порядку. Якщо порядок вимкнення має значення, розгляньте можливість використання `preStop` хука для синхронізації.
У той же час, коли kubelet розпочинає належне вимкнення Podʼа, панель управління оцінює, чи слід вилучити цей Pod з обʼєктів EndpointSlice (та Endpoints), де ці обʼєкти представляють Service із налаштованим selector. ReplicaSets та інші ресурси робочого навантаження більше не розглядають такий Pod як дійсний.
Podʼи, які повільно завершують роботу, не повинні продовжувати обслуговувати звичайний трафік і повинні почати завершення та завершення обробки відкритих зʼєднань. Деякі застосунки потребують більш часу для належного завершення роботи, наприклад, сесії піготовки до обслуговування та завершення.
Будь-які endpoint, які представляють Podʼи, що закінчують свою роботу, не вилучаються негайно з EndpointSlices, а статус, який вказує на стан завершення, викладається з EndpointSlice API (та застарілого API Endpoints). Endpointʼи, які завершуть роботу, завжди мають статус
ready
якfalse
(для сумісності з версіями до 1.26), тому балансувальники навантаження не будуть використовувати його для звичайного трафіку.Якщо трафік на завершуючомуся Podʼі ще потрібний, фактичну готовність можна перевірити як стан
serving
. Детальніше про те, як реалізувати очищення зʼєднань, можна знайти в розділі Порядок завершення роботи Podʼів та Endpointʼів
Примітка:
Якщо у вашому кластері відключено feature gateEndpointSliceTerminatingCondition
(є типов увікненим з Kubernetes 1.22, і заблокована в 1.26), то панель управління Kubernetes вилучає Pod з будь-яких відповідних EndpointSlices, щойно належне завершеня роботи Podʼа починається. Описана вище поведінка стосується випадку, коли EndpointSliceTerminatingCondition
увімкнено.Примітка:
Починаючи з Kubernetes 1.29, якщо ваш Pod включає один чи кілька контейнерів sidecar (контейнери ініціалізації з політикою постіного перезапуску), kubelet затримає надсилання сигналу TERM цим контейнерам sidecar до тих пір, поки останній основний контейнер повністю не завершить роботу. Контейнери sidecar будуть завершені в зворотньому порядку, в якому вони визначені в специфікації Podʼа. Це забезпечує, що контейнери sidecar продовжуватимуть обслуговувати інші контейнери в Podʼі до тих пір, поки вони не будуть більше потрібні.
Слід зазначити, що повільне завершення основного контейнера також затримає завершення контейнерів sidecar. Якщо строк належного завершення роботи закінчується до завершення процесу, може відбутися екстрене завершення. У цьому випадку всі залишкові контейнери в Podʼі будуть завершені одночасно із коротким строком належного завершення роботи.
Так само, якщо у Podʼа є хук preStop, який перевищує строк належного завершення роботи, екстрене завершення також може відбутися. Загалом, якщо ви використовували хуки preStop для управління порядком завершення без контейнерів sidecar, ви можете тепер видалити їх і дозволити kubelet автоматично керувати завершенням контейнерів sidecar.
- Коли строк належного завершення роботи закінчується, kubelet виконує примусове вимкнення. Середовище виконання контейнера відсилає сигнал
SIGKILL
будь-яким процесам, які все ще працюють в будь-якому контейнері в Podʼі. Крім того, kubelet очищає прихований контейнерpause
, якщо середовище виконання контейнера використовує його. - Kubelet переводить Pod у термінальну фазу (
Failed
абоSucceeded
залежно від кінцевого стану його контейнерів). Цей крок гарантується починаючи з версії 1.27. - Kubelet спричинює примусове видалення обʼєкта Pod з API-сервера, встановлюючи строк належного заверщення на 0 (безпосереднє видалення).
- API-сервер видаляє обʼєкт API Pod, який потім більше не є видимим для жодного клієнта.
Примусове завершення Podʼів
Увага:
Примусове завершення може бути потенційно руйнівним для деяких завдань та їх Podʼів.Типово всі видалення є належними протягом 30 секунд. Команда kubectl delete
підтримує опцію --grace-period=<seconds>
, яка дозволяє вам перевизначити типове значення своїм.
Встановлення належного завершення роботи в 0
примусово та негайно видаляє Pod з API сервера. Якщо Pod все ще працює на вузлі, це примусове видалення спричинює початок негайного прибирання kubelet.
Примітка:
Ви повинні вказати додатковий прапорtwm--force
разом із --grace-period=0
, щоб виконати примусове видалення.Під час примусового видалення API-сервер не чекає підтвердження від kubelet, що Pod завершено на вузлі, на якому він працював. Він негайно видаляє Pod в API, щоб можна було створити новий pod з тим самим ім'ям. На вузлі Podʼи, які мають бути видалені негайно, все ще отримують невеликий строк для завершення роботи перед примусовим вимиканням.
Увага:
Негайне видалення не чекає підтвердження того, що робочий ресурс було завершено. Ресурс може продовжувати працювати в кластері нескінченно.Якщо вам потрібно примусово видалити Podʼи, які є частиною StatefulSet, дивіться документацію для видалення Podʼів з StatefulSet.
Збір сміття Podʼів
Для несправних Podʼів обʼєкти API залишаються в API кластера, поки людина чи контролер явно їх не видалять.
Збірник сміття Podʼів (PodGC), який є контролером панелі управління, прибирає завершені Podʼів (із фазою Succeeded
або Failed
), коли кількість Podʼів перевищує налаштований поріг (визначений параметром terminated-pod-gc-threshold
в kube-controller-manager). Це запобігає витоку ресурсів при створенні та завершенні Podʼів з часом.
Крім того, PodGC очищує будь-які Podʼи, які відповідають одній з наступних умов:
- є осиротілими Podʼів — привʼязаними до вузла, якого вже не існує,
- є незапланованими Podʼами у стані завершення,
- є Podʼів у стані завершення, привʼязаними до непрацюючого вузла з позначкою
node.kubernetes.io/out-of-service
, коли ввімкнено функціоналNodeOutOfServiceVolumeDetach
.
Коли ввімкнено функціонал PodDisruptionConditions
, разом із прибиранням Podʼів, PodGC також позначає їх як несправнені, якщо вони перебувають в незавершеній фазі. Крім того, PodGC додає стан руйнування Podʼу під час очищення осиротілого Podʼу. Див. стани руйнування Podʼів
для отримання докладніших відомостей.
Що далі
Отримайте практичний досвід прикріплення обробників до подій життєвого циклу контейнера.
Отримайте практичний досвід налаштування проб Liveness, Readiness та Startup.
Дізнайтеся більше про обробники життєвого циклу контейнера.
Дізнайтеся більше про контейнери sidecar.
Для докладної інформації про статус Podʼа та контейнера в API, перегляньте документацію API, яка охоплює
status
для Podʼа.