Що відбувається після перезапуску вузла

Системні компоненти на вузлі іноді перезапускаються — через оновлення, збій або свідому дію оператора. Ця сторінка описує, що відбувається з Podʼами та з вузлом, коли kubelet, середовище виконання контейнерів або вузол загалом перезапускається.

У справному кластері такі перезапуски зазвичай безпечні й не порушують роботу робочих навантажень. У розділах нижче описано ефекти, про які варто знати; вони стають більш помітними на великих або сильно завантажених вузлах. Найбільш руйнівним випадком є перезавантаження вузла, яке охоплює як перезапуск середовища виконання контейнерів, так і перезапуск kubelet, але з більшими наслідками, оскільки спочатку зупиняється кожен контейнер на вузлі.

Вплив перезапуску kubelet

Якщо перезапускається лише kubelet, контейнери, які вже працюють, продовжують працювати. Kubelet відновлює своє уявлення про вузол і узгоджує запущені контейнери з бажаним станом. Протягом цього періоду відбувається наступне:

  • Kubelet повторно ініціалізує та повторно синхронізує свої кеші, що створює сплеск запитів до API сервера. На великих вузлах з численними Podʼами цей сплеск може бути значним.

  • Стан вузла тимчасово повідомляється як NotReady, доки kubelet не завершить ініціалізацію. Поки вузол перебуває у стані NotReady, планувальник не розміщує на ньому нові Podʼи.

  • Пульс вузла призупиняється, поки kubelet вимкнено, і відновлюється після його перезапуску та завершення ініціалізації, коли kubelet поновлює свій обʼєкт Lease і знову публікує статус вузла.

  • Kubelet зберігає готовність запущених контейнерів під час перезапуску. Готовність кожного Podʼа керує обʼєктами EndpointSlices, Endpoints та downstream-конфігурацією (такою як Gateways або Ingresses); це означає, що скидання готовності контейнерів при кожному перезапуску створювало б велике навантаження на API сервер та компоненти, які відстежують стан точок доступу, і могло б тимчасово вилучати справні Podʼи з балансування навантаження Service. Ця поведінка описана в KEP-4781: Fix inconsistent container ready state after kubelet restart. Скидання готовності контейнерів до false при кожному перезапуску було типовою поведінкою протягом тривалого часу. Функціональна можливість ChangeContainerStatusOnKubeletRestart дозволяє повернутися до цієї поведінки, але це застарілий резервний механізм, який заплановано до видалення, тому не варто на нього покладатися. Детальніше див. Поведінка Podʼів під час перезапусків kubelet.

  • Під час початкового запуску kubelet збирання сміття невикористаних образів та контейнерів, а також виселення Podʼів, спричинені тиском на вузол, призупиняються. Це призупинення триває короткий пільговий період після завершення kubelet основних процедур запуску. Така затримка може сповільнити реакцію вузла на нестачу памʼяті або дискового простору.

  • Поточні отримання образів скасовуються. Залежно від середовища виконання контейнерів, скасований процес отримання образів можливо доведеться починати спочатку при повторній спробі.

  • Допуск Podʼів запускається знову для Podʼів на вузлі, оскільки kubelet повторно пропускає їх через перевірки допуску. Якщо мітки або taint вузла змінилися, поки kubelet був вимкнений, Pod може не пройти допуск і бути відхиленим, навіть якщо він уже працював. Це поточна поведінка, і питання, чи слід її вважати помилкою, досі обговорюється; див. kubernetes/kubernetes#123859 для обговорення та деталей.

Загалом у справному кластері перезапуск kubelet не порушує запущені робочі навантаження. Однак на великих кластерах з перевантаженими вузлами навантаження повторної ініціалізації та призупинені збирання сміття й виселення можуть сприяти нестабільності системи.

Kubernetes не визначає поведінку вашого середовища виконання контейнерів, якщо ви його перезапускаєте. Залежно від використовуваного середовища виконання контейнерів, перезапуск може спричинити зупинку або перезапуск усіх локальних контейнерів. Однак більшість середовищ виконання контейнерів, що використовуються з Kubernetes, використовують конфігурацію, яка дозволяє перезапускати середовище виконання, залишаючи контейнери виконуватись.

Вплив перезапуску середовища виконання контейнерів

Коли середовище виконання контейнерів (таке як containerd або CRI-O) перезапускається, kubelet втрачає зʼєднання з ним до його повернення. Протягом цього проміжку часу:

  • exec перевірки завершуються невдачею на час перезапуску, оскільки kubelet не може виконувати команди всередині контейнерів. При малому тайм-ауті та низькому порозі невдач, невдала перевірка життєздатності може призвести до перезапуску контейнера, а невдала перевірка готовності може спричинити вихід Podʼа зі стану Ready.

  • Вузол повідомляється kubelet як NotReady, що блокує планування нових Podʼів на цьому вузлі.

  • Операції з контейнерами, такі як перезапуски, ініціалізація та оновлення статусу, затримуються, доки середовище виконання знову не стане доступним.

  • Якщо під час перезапуску середовища виконання виконувався init контейнер, його стан виконання може бути втрачено, і в такому випадку init контейнер запускається знову.

  • У рідкісних випадках переривання операції в точний момент може залишити стан неузгодженим:

    • Перерване отримання образу може залишити неузгоджені шари образу, що може зробити образ непридатним до використання, доки його не буде отримано знову.

    • Перерване створення пісочниці, якщо воно перерване посеред виклику CNI або NRI, може залишити пісочницю в неузгодженому стані, коли CNI лише частково ініціалізовано з можливістю витоку ресурсів.

Переривання операції в точний момент — це малоймовірна ситуація, тому перезапуск середовища виконання контейнерів загалом є безпечною операцією. На сильно завантаженому вузлі, де кожна операція виконується повільніше, проміжок часу для переривання критичної операції більший, і ймовірність потрапити в один із таких граничних випадків зростає.

Вплив перезавантаження вузла

Перезавантаження вузла є найбільш руйнівною з цих подій, оскільки кожен контейнер на вузлі зупиняється. Перезавантаження охоплює як перезапуск середовища виконання контейнерів, так і перезапуск kubelet, але з більшими наслідками: у той час як окремий перезапуск kubelet або середовища виконання залишає вже запущені контейнери на місці, перезавантаження спочатку зупиняє кожен контейнер. Після завантаження вузла kubelet та середовище виконання контейнерів запускаються знову, причому жоден контейнер фактично не працює.

Перед запланованим перезавантаженням ви можете зменшити вплив, ізолювавши вузол, щоб планувальник перестав розміщувати на ньому нові Podʼи, а потім очистити його для виселення наявних Podʼів без порушень. Коли коректне вимкнення вузла увімкнено, kubelet також намагається зупинити запущені Podʼи належним чином, коли виявляє, що вузол вимикається.

Коли вузол повертається:

  • Перезавантаження зупиняє всі контейнери, і kubelet створює їх заново, коли вузол повертається. Якщо вузол залишається вимкненим довше, ніж налаштований період толерування, описаний нижче, лише Podʼи, керовані контролером (таким як Deployment, StatefulSet або DaemonSet), отримують заміну Podʼа. Заміна Podʼа може бути запланована на інший вузол. Самостійні Podʼи (без іншого обʼєкта або контролера, що ними керує) не створюються заново після видалення.

  • Вузол поновлює оренду та узгоджує свій статус. Він повідомляється як NotReady, доки kubelet, середовище виконання контейнерів і мережа не будуть готові. Поки вузол перебуває у стані NotReady, він може бути позначений taint як node.kubernetes.io/not-ready, і після налаштованого періоду толерування панель управління може виселити Podʼи, які його не толерують.

  • Kubelet повторно запускає допуск для Podʼів, призначених вузлу, тому міркування щодо міток та taint, описані в розділі перезапуск kubelet, застосовуються також тут.

  • Для Podʼів, які запитують пристрої, kubelet знову викликає відповідні втулки пристроїв, щоб підтвердити виділення пристроїв для Podʼів, які відновлюються на вузлі. Втулки пристроїв повинні повторно зареєструватися в kubelet після перезавантаження, щоб ці виділення могли бути узгоджені.

  • Локальне сховище, привʼязане до часу життя контейнера або Podʼа, може бути втрачено. Доступний для запису шар контейнера відкидається, коли контейнер створюється заново, тому дані, записані туди, не переживають перезавантаження. Том emptyDir існує, доки Pod залишається на вузлі: emptyDir в памʼяті (medium: Memory) завжди втрачається при перезавантаженні, оскільки зберігається в RAM, тоді як emptyDir на диску переживає перезавантаження, доки Pod не виселено або не видалено, і видаляється лише тоді, коли Pod залишає вузол.

Для робочих навантажень, які повинні витримувати перезавантаження вузлів, запускайте Podʼи через контролер, використовуйте постійні томи для даних, які повинні зберігатися, та налаштовуйте бюджети розладів і перевірки, щоб трафік надсилався лише до Podʼів, коли вони готові.

Що далі

Востаннє змінено July 05, 2026 at 10:33 PM PST: [uk] Ukrainian translation (all-in-one) (d96ae8cb81)