Ця стаття була опублікована більше року тому. Старіші статті можуть містити застарілу інформацію. Перевірте, чи інформація на цій сторінці не втратила актуальності з моменту її публікації.
Kubernetes v1.33: Оновлення життєвого циклу контейнерів
У Kubernetes v1.33 представлено декілька оновлень життєвого циклу контейнерів. Дія Sleep для хуків життєвого циклу контейнера тепер підтримує нульову тривалість сну (можливість типово увімкнена). Також зʼявилася альфа-підтримка для налаштування сигналу зупинки, що надсилається контейнерам при завершенні їхньої роботи.
У цій статті ви дізнаєтеся більше про ці нові аспекти життєвого циклу контейнера і про те, як ними користуватися.
Нульове значення для дії Sleep
У Kubernetes v1.29 введено дію Sleep для хуків життєвого циклу контейнерів PreStop і PostStart. Дія Sleep дозволяє вашим контейнерам призупиняти роботу на певний час після запуску контейнера або перед його завершенням. Це було необхідно для забезпечення простого способу керування належним завершенням роботи. До появи дії Sleep люди використовували команду sleep за допомогою дії exec у своїх хуках життєвого циклу контейнера. Якщо ви хотіли це зробити, вам потрібно було мати двійковий файл для команди sleep в образі вашого контейнера. Це важко зробити, якщо ви використовуєте сторонні образи.
Дія sleep, коли її було додано, спочатку не підтримувала тривалість сну у нуль секунд. Функція time.Sleep, яку приховано використовується дією Sleep, підтримує тривалість сну у нуль секунд. Використання відʼємного або нульового значення для часу сну призводить до негайного повернення, що призводить до невиконання дії. Ми хотіли отримати таку саму поведінку для дії sleep. Цю підтримку нульової тривалості було додано у версії 1.32 за допомогою функціональної можливості PodLifecycleSleepActionAllowZero.
Функціональна можливість PodLifecycleSleepActionAllowZero перейшла до бета-версії у версії 1.33 і тепер типово увімкнена. Оригінальна дія Sleep для хуків preStop і postStart типово увімкнена, починаючи з Kubernetes v1.30. У кластері під керуванням Kubernetes v1.33 ви можете встановити нульову тривалість для хуків життєвого циклу сну. Для кластера з типовою конфігурацією вам не потрібно вмикати жодних функціональних можливостей, щоб зробити це можливим.
Сигнали зупинки контейнерів
Такі середовища виконання контейнерів, як containerd та CRI-O, враховують інструкцію StopSignal у визначенні образу контейнера. За допомогою цієї інструкції можна вказати власний сигнал зупинки, який середовище виконання використовуватиме для завершення роботи контейнерів на основі цього образу. Налаштування сигналу зупинки спочатку не було частиною Pod API у Kubernetes. До версії Kubernetes v1.33 єдиним способом перевизначити сигнал зупинки для контейнерів було перебудувати образ контейнера з новим власним сигналом зупинки (наприклад, вказавши STOPSIGNAL у Containerfile або Dockerfile).
Функціональна можливість ContainerStopSignals, яка була додана у Kubernetes v1.33, додає сигнали зупинки до API Kubernetes. Це дозволяє користувачам вказати власний сигнал зупинки в специфікації контейнера. Сигнали зупинки додаються до API як новий життєвий цикл разом з наявними обробниками життєвого циклу PreStop та PostStart. Для того, щоб використовувати цю можливість, ми очікуємо, що в Pod буде вказана операційна система за допомогою spec.os.name. Це необхідно для того, щоб ми могли перехресно перевірити сигнал зупинки на відповідність операційній системі і переконатися, що контейнери в Pod створюються з правильним сигналом зупинки для операційної системи, для якої планується створення Pod. Для Podʼів, запланованих на вузлах Windows, допустимими сигналами зупинки є лише SIGTERM і SIGKILL. Повний список сигналів, що підтримуються на вузлах Linux, можна знайти тут.
Типова поведінка
Якщо у життєвому циклі контейнера визначено власний сигнал зупинки, то для завершення роботи контейнера буде використано сигнал, визначений у життєвому циклі, враховуючи, що середовище виконання контейнера також підтримує власні сигнали зупинки. Якщо у життєвому циклі контейнера не визначено спеціального сигналу зупинки, середовище виконання повернеться до сигналу зупинки, визначеного в образі контейнера. Якщо в образі контейнера не визначено жодного сигналу зупинки, буде використано типовий сигнал зупинки середовища виконання. Типовим сигналом є SIGTERM як для containerd, так і для CRI-O.
Розбіжність версій
Щоб ця можливість працювала належним чином, версії Kubernetes та середовища виконання контейнера повинні підтримувати сигнали зупинки контейнера. Зміни до API Kubernetes та kubelet доступні в альфа-версії, починаючи з v1.33, які можна увімкнути за допомогою функціональної можливості ContainerStopSignals. Реалізації середовища виконання контейнерів для containerd та CRI-O все ще перебувають у процесі розробки та будуть випущені найближчим часом.
Використання сигналів зупинки контейнера
Щоб увімкнути цю можливість, вам потрібно увімкнути функціональну можливість ContainerStopSignals в kube-apiserver та kubelet. Після того, як у вас є вузли з увімкненою функціональною можливістю, ви можете створювати Podʼи з життєвим циклом StopSignal і правильною назвою ОС, наприклад, таким чином:
apiVersion: v1
kind: Pod
metadata:
name: nginx
spec:
os:
name: linux
containers:
- name: nginx
image: nginx:latest
lifecycle:
stopSignal: SIGUSR1
Зверніть увагу, що сигнал SIGUSR1 у цьому прикладі може бути використаний лише у тому випадку, якщо Pod контейнера заплановано на вузол Linux. Отже, нам потрібно вказати spec.os.name як linux, щоб мати змогу використовувати цей сигнал. Якщо Pod планується на вузол Windows, ви зможете налаштувати лише сигнали SIGTERM і SIGKILL. Ви також не зможете вказати containers[*].lifecycle.stopSignal, якщо поле spec.os.name дорівнює nil або не встановлено.
Як долучитися?
Розвиток цієї можливості веде SIG Node. Якщо ви зацікавлені в тому, щоб допомогти розвивати цю можливість, поділитися відгуками або взяти участь у будь-яких інших поточних проєктах SIG Node, будь ласка, звʼяжіться з нами!
Ви можете звʼязатися з SIG Node кількома способами:
Ви також можете звʼязатися зі мною напряму:
- GitHub: @sreeram-venkitesh
- Slack: @sreeram.venkitesh