Кубернетес позволяют контейнеру выходить без перезапуска - PullRequest
0 голосов
/ 15 ноября 2018

Довольно распространенная настройка, которую я вижу для докера, - заставить контейнер вращаться, выполнить задачу и затем выйти. Это то, что я делаю довольно часто с docker-compose, где у меня есть контейнер узлов, который выполняет процесс сборки и не нуждается в поддержке после сборки статических файлов. В этих случаях, если я посмотрю на вывод docker-compose ps, в то время как другие мои контейнеры открыты и открыты для порта, состояние контейнеров узла будет «Выход 0». Хотя в противном случае мне не нужен доступ к этому контейнеру, он может быть запущен.

Какая хорошая практика для перевода этой настройки в Kubernetes?

Мой первоначальный подход состоял в том, чтобы поместить все в один модуль, но выход из контейнера вызывает CrashLoopBackOff, и из-за политики перезапуска модуля модуль продолжает перезапускаться. Если бы я оставил эту настройку, я бы хотел, чтобы модуль перезапускался только в случае сбоя одного из других контейнеров. Он уже перемещает статические файлы сборки в том, доступный для других контейнеров.

Должен ли этот контейнер быть перемещен в другой модуль, который не перезапускается? Похоже, это излишне усложнит развертывание.

Ответы [ 2 ]

0 голосов
/ 15 ноября 2018

контейнер узла, который выполняет процесс сборки и ему не нужно оставаться в рабочем состоянии после сборки статических файлов

Это похоже на определение контейнера инициализации : «Они всегда выполняются до завершения. Каждый из них должен успешно выполняться до запуска следующего.»

В вашей спецификации развертывания в части шаблона Pod у вас будет отдельный раздел initContainers:, содержащий отдельный контейнер только для сборки. Он имеет тот же формат, что и раздел containers:, который содержит основное приложение, но запускается сначала, до завершения, один раз. Вам может потребоваться создать том в контексте модуля Pod для совместного использования содержимого с основным контейнером, но это может быть что-то вроде модуля типа emptyDir: без действительного постоянного хранилища.

Если вы действительно «строите» что-то в смысле запуска такого инструмента, как Webpack, который в основном генерирует статические файлы, то все же лучше перенести этот процесс в Dockerfile, чтобы вы могли запустить неизмененный образ, не занимаясь еще большей сборкой во время развертывания.

0 голосов
/ 15 ноября 2018

Как правило, для предотвращения повторного использования POD restartPolicy: Never ( подробнее о политике перезапуска ).

Кроме того, для того, что вы хотите запустить «до завершения», используйте компонент k8s под названием Job ( больше на задании ):

apiVersion: batch/v1
kind: Job
metadata:
  name: <job_name>
spec:
  template:
    spec:
      containers:
      <...>

Для запуска задания до первого успеха (exit code 0) установите restartPolicy: OnFailure.

...