Kubernetes v1.34: Більш точний контроль над перезапуском контейнерів
З виходом Kubernetes 1.34, було представлено нову альфа-функцію, яка надає більш детальний контроль над перезапусками контейнерів у межах Pod. Ця функція, названа Container Restart Policy and Rules, дозволяє вам вказати політику перезапуску для кожного контейнера окремо, перевизначаючи глобальну політику перезапуску Podʼа. Крім того, вона також дозволяє перезапускати окремі контейнери на основі їх кодів виходу. Ця функція доступна за альфа-функціональною можливістю ContainerRestartRules.
Ця функція була давно очікуваною. Розглянемо, як вона працює і як ви можете її використовувати.
Проблема з єдиною політикою перезапуску
До цієї функції restartPolicy встановлювалася на рівні Podʼа. Це означало, що всі контейнери в Podʼі ділили одну й ту ж політику перезапуску (Always, OnFailure або Never). Хоча це підходить для багатьох випадків використання, в інших ситуаціях це може бути обмеженням.
Наприклад, розглянемо Pod з основним контейнером застосунку та ініціалізаційним контейнером, який виконує деякі початкові налаштування. Ви можете захотіти, щоб основний контейнер завжди перезапускався у разі збою, але ініціалізаційний контейнер повинен виконуватися лише один раз і ніколи не перезапускатися. З єдиною політикою перезапуску на рівні Pod це було неможливо.
Введення політик перезапуску для кожного контейнера
З новою функцією ContainerRestartRules ви тепер можете вказати restartPolicy для кожного контейнера в специфікації вашого Podʼа. Ви також можете визначити restartPolicyRules, щоб контролювати перезапуски на основі кодів виходу. Це дає вам детальний контроль, необхідний для обробки складних сценаріїв.
Варіанти використання
Давайте розглянемо деякі реальні випадки використання, де політики перезапуску для кожного контейнера можуть бути корисними.
Перезапуски на місці для завдань навчання моделей
У дослідженнях машинного навчання часто потрібно організовувати велику кількість тривалих навчальних навантажень AI/ML. У цих сценаріях збої навантаження є неминучими. Коли навантаження зазнає збою з кодом виходу, що підлягає повторному виконанню, ви хочете, щоб контейнер швидко перезапускався без повторного планування всього Podʼа, що споживає значну кількість часу та ресурсів. Перезапуск невдалого контейнера "на місці" є критично важливим для кращого використання обчислювальних ресурсів. Контейнер повинен перезапускатися "на місці" лише у разі збою через помилку, що підлягає повторному виконанню; в іншому випадку контейнер і Pod повинні завершити роботу та, можливо, бути повторно запланованими.
Це тепер можна досягти за допомогою правил restartPolicyRules на рівні контейнера. Навантаження може завершитися з різними кодами, щоб представити помилки, що підлягають повторному виконанню, і непідлягають повторному виконанню. Завдяки restartPolicyRules навантаження може бути швидко перезапущено на місці, але лише тоді, коли помилка підлягає повторному виконанню.
Ініціалізаційні контейнери з одноразовим виконанням
Ініціалізаційні контейнери часто використовуються для виконання початкових налаштувань для основного контейнера, таких як налаштування середовищ і облікових даних. Іноді ви хочете, щоб основний контейнер завжди перезапускався, але не хочете повторювати ініціалізацію, якщо вона зазнає збою.
З політикою перезапуску на рівні контейнера це тепер можливо. Ініціалізаційний контейнер може виконуватися лише один раз, і його збій буде вважатися збоєм Podʼа. Якщо ініціалізація проходить успішно, основний контейнер завжди може бути перезапущений.
Podʼи з кількома контейнерами
Для Podʼів, які виконують кілька контейнерів, ви можете мати різні вимоги до перезапуску для кожного контейнера. Деякі контейнери можуть мати чітке визначення успіху і повинні перезапускатися лише у разі збою. Інші можуть потребувати постійного перезапуску.
Це тепер можливо з політикою перезапуску на рівні контейнера, що дозволяє окремим контейнерам мати різні політики перезапуску.
Як це використовувати
Щоб використовувати цю нову функцію, вам потрібно увімкнути функціональну можливість ContainerRestartRules в панелі управління вашого кластера Kubernetes та робочих вузлах, які працюють на Kubernetes 1.34+. Після увімкнення ви можете вказати поля restartPolicy та restartPolicyRules у визначеннях ваших контейнерів.
Ось кілька прикладів:
Приклад 1: Перезапуск на основі конкретних кодів виходу
У цьому прикладі контейнер повинен перезапуститися, якщо і тільки якщо він зазнає збою з помилкою, що підлягає повторному виконанню, що представляється кодом виходу 42.
Щоб досягти цього, контейнер має restartPolicy: Never, і правило політики перезапуску, яке вказує Kubernetes перезапустити контейнер на місці, якщо він завершується з кодом 42.
apiVersion: v1
kind: Pod
metadata:
name: restart-on-exit-codes
annotations:
kubernetes.io/description: "This Pod only restart the container only when it exits with code 42."
spec:
restartPolicy: Never
containers:
- name: restart-on-exit-codes
image: docker.io/library/busybox:1.28
command: ['sh', '-c', 'sleep 60 && exit 0']
restartPolicy: Never # Політика перезапуску контейнера повинна бути вказана, якщо правила вказані
restartPolicyRules: # Тільки перезапустити контейнер, якщо він завершується з кодом 42
- action: Restart
exitCodes:
operator: In
values: [42]
Приклад 2: Ініціалізаційний контейнер з одною спробою запуску
У цьому прикладі Pod повинен завжди перезапускатися після успішної ініціалізації. Однак ініціалізація повинна бути спробована лише один раз.
Щоб досягти цього, Pod має політику перезапуску Always. Ініціалізаційний контейнер init-once спробує запуститися лише один раз. Якщо він зазнає невдачі, Pod зазнає невдачі. Це дозволяє Pod зазнати невдачі, якщо ініціалізація не вдалася, але також продовжувати працювати, як тільки ініціалізація буде успішною.
apiVersion: v1
kind: Pod
metadata:
name: fail-pod-if-init-fails
annotations:
kubernetes.io/description: "This Pod has an init container that runs only once. After initialization succeeds, the main container will always be restarted."
spec:
restartPolicy: Always
initContainers:
- name: init-once # Цей контейнер ініціалізації спробує запуститись лише один раз. Якщо спроба не вдасться, Pod не працюватиме.
image: docker.io/library/busybox:1.28
command: ['sh', '-c', 'echo "Failing initialization" && sleep 10 && exit 1']
restartPolicy: Never
containers:
- name: main-container # Цей контейнер завжди буде перезапущений, як тільки ініціалізація буде успішною.
image: docker.io/library/busybox:1.28
command: ['sh', '-c', 'sleep 1800 && exit 0']
Приклад 3: Контейнери з різними політиками перезапуску
У цьому прикладі є два контейнери з різними вимогами до перезапуску. Один повинен завжди перезапускатися, тоді як інший повинен перезапускатися лише у разі збою.
Це досягається за допомогою різних політик перезапуску на рівні контейнера для кожного з двох контейнерів.
apiVersion: v1
kind: Pod
metadata:
name: on-failure-pod
annotations:
kubernetes.io/description: "This Pod has two containers with different restart policies."
spec:
containers:
- name: restart-on-failure
image: docker.io/library/busybox:1.28
command: ['sh', '-c', 'echo "Not restarting after success" && sleep 10 && exit 0']
restartPolicy: OnFailure
- name: restart-always
image: docker.io/library/busybox:1.28
command: ['sh', '-c', 'echo "Always restarting" && sleep 1800 && exit 0']
restartPolicy: Always
Дізнайтеся більше
- Ознайомтеся з документацією про політику перезапуску контейнерів.
- Ознайомтеся з KEP для правил перезапуску контейнерів
Плани
Більше дій та сигналів для перезапуску Pod і контейнерів зʼявляться незабаром! Зокрема, планується додати підтримку перезапуску всього Podʼа. Планування та обговорення цих функцій тривають. Не соромтеся ділитися відгуками або запитами до спільноти SIG Node!
Ми будемо раді отримати ваші відгуки!
Це альфа-функція, і проєкт Kubernetes хотів би почути ваші відгуки. Будь ласка, спробуйте її. Ця функція керується SIG Node. Якщо ви зацікавлені в допомозі в розробці цієї функції, обміні відгуками або участі в будь-яких інших поточних проєктах SIG Node, будь ласка, звʼяжіться зі спільнотою SIG Node!
Ви можете звʼязатися з SIG Node кількома способами: