Kubernetes v1.33: Оновлення в життєвому циклі контейнерів в 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 ви можете встановити нульову тривалість для хуків життєвого циклу сну. Для кластера зі стандартною конфігурацією вам не потрібно вмикати жодних функціональних можливостей, щоб зробити це можливим.
Container stop signals
Такі середовища виконання контейнерів, як 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 Kuberentes та 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, щоб мати змогу використовувати цей сигнал. Ви зможете налаштувати сигнали SIGTERM і SIGKILL, тільки якщо Pod планується на вузол Windows. Ви також не зможете вказати containers[*].lifecycle.stopSignal, якщо поле spec.os.name дорівнює нулю або не встановлено.
Як долучитися?
Ця функція розроблена SIG Node. Якщо ви зацікавлені в тому, щоб допомогти розвивати цю функцію, поділитися відгуками або взяти участь у будь-яких інших поточних проєктах SIG Node, будь ласка, звʼяжіться з нами!
Ви можете звʼязатися з SIG Node кількома способами:
Ви також можете звʼязатися зі мною напряму:
- GitHub: @sreeram-venkitesh
- Slack: @sreeram.venkitesh