Жизненный цикл контейнера

Во-первых, жизненный цикл контейнера.

Два, введение в композицию

2.1 Контейнер инициализации

Pod может иметь несколько контейнеров, и приложения запускаются в контейнерах. Но он также может иметь один или несколько контейнеров инициализации, которые запускаются перед контейнером приложения.

Контейнеры инициализации очень похожи на обычные контейнеры, за исключением следующих двух моментов:

• Контейнер инициализации всегда запускается, пока не завершится успешно
• Каждый контейнер инициализации должен успешно завершиться до запуска следующего контейнера инициализации.

Если контейнер Init Pod выходит из строя, Kubernetes будет продолжать перезапускать Pod до тех пор, пока контейнер Init не завершится успешно. Однако, если политика restartPolicy, соответствующая поду, никогда не будет перезапущена.

Шаблон контейнера инициализации

apiVersion:v1
kind:Pod
metadata:
  name:myapp-pod
  labels:
    app:myapp
spec:
  containers:
 - name:myapp-container
	images:busybox
	command:["sh", "-c", "echo The App is Running! && sleep 3600"]
  initContainers:
 - name:init-myservice
	image:busybox
	command:["sh", "-c","until nslookup myservice;do echo waiting for myservice;sleep 2;done; "]
 - name:init-mydb
    image:busybox
	command:["sh","-c", "until nslookup mydb;do echo waiting for mydb;sleep 2;done;"]

Специальная записка:

• Во время процесса запуска Pod контейнер Init будет запускаться после инициализации сети и объема данных по порядку . Каждый контейнер должен успешно завершиться до запуска следующего контейнера.
• Если он завершается из-за времени выполнения или сбоя, контейнер не запустится, и контейнер Init повторит попытку в соответствии с политикой, указанной в restartPolicy модуля.
• До того, как все контейнеры инициализации будут неудачными, Pod не станет готовым. Порты контейнера Init не будут агрегированы в Службе ( то есть порты нескольких контейнеров Init одинаковы и не будут конфликтовать, потому что контейнер Init выйдет после успешного выполнения, а затем запустит следующий контейнер Init ). Инициализируемый Pod находится в состоянии Pending, но для состояния Initializing должно быть установлено значение true.
• Если Pod перезапускается, необходимо перезапустить все контейнеры Init.
• Изменения в спецификации контейнера Init ограничиваются полем образа контейнера , а изменения в других полях не вступят в силу. Изменение поля изображения в контейнере инициализации эквивалентно перезапуску модуля.
• Контейнер Init содержит все поля контейнера приложения, кроме readinessProbe. Поскольку контейнер Init не может определять состояния, отличные от готовности, кроме завершения. Это будет выполнено при проверке (???)
• Имя каждого приложения и контейнера инициализации в модуле должно быть уникальным; использование того же имени для любого другого контейнера вызовет ошибку во время проверки.

2.2 Контейнерный зонд

Зонд - это периодическая диагностика, выполняемая кубелетом на контейнере. Для диагностики kubelet вызывает обработчик, реализованный контейнером.

Есть три типа обработчиков:

• ExecAction: выполнить указанную команду в контейнере, если код возврата равен 0 при выходе из команды, диагностика считается успешной.
• TCPSocketAction: выполнить проверку TCP IP-адреса контейнера на указанном порту. Если порт открыт, диагностика считается успешной.
• HTTPGetAction: выполнить HTTP-запрос Get на IP-адрес контейнера на указанном порту и пути. Если код состояния ответа больше или равен 200 и меньше 400, диагностика считается успешной.

Каждый зонд получит один из следующих трех результатов:

• Успешно: контейнер прошел диагностику
• Ошибка: контейнер не прошел диагностику.
• Неизвестно: диагностика не прошла, поэтому никаких действий предприниматься не будет.

Метод обнаружения:

• livenessProbe: указывает, запущен ли контейнер. Если обнаружение выживания не сработает, кубелет убьет контейнер, и на него повлияет стратегия перезапуска. Если контейнер не предоставляет зонд выживания, статус по умолчанию - Успех.
• readinessProbe: указывает, готов ли контейнер к обслуживанию запроса. Если обнаружение готовности завершится неудачно, контроллер конечной точки удалит IP-адрес модуля из всех конечных точек службы, соответствующих этому модулю. Состояние готовности перед начальной задержкой по умолчанию - Отказ. Если контейнер не предоставляет зонд готовности, статус по умолчанию - Успех.

Пример 1: Готовый зонд

apiVersion:v1
kind:Pod
metadata:
  name:readiness-httpget-pod
  namespace:default
spec:
  containers:
  - name:readiness-httpget-container
    image:XXX/myapp:v1
    imagePullPolicy:IfNotPresentports
    readinessProbe:
      httpGet:
        port:http
        path:/index1.html
      initialDelaySeconds:1
      periodSceonds:3

Пример 2: определение выживаемости

apiVersion:v1
kind:Pod
metadata:
  name:liveness-exec-pod
  namespace:default
spec:
  containers:
 - name:liveness-exec-container
    image:hub.atguigu.com/library/busybox
    imagePullPolicy:IfNotPresentports
    command:["/bin/sh","-c","touch /tmp/live;sleep 60;rm -rf /tmp/live;sleep 3600"]
    livenessProbe:
      exec:
        command:["test","-e", "/tmp/live"]
      initialDelaySeconds:1
      periodSceonds:3

2.3 Возможные значения фазы стручка (завершение)

• В ожидании: Pod был принят системой Kubernetes, но один или несколько образов контейнеров еще не созданы. Время ожидания включает время, чтобы запланировать Pod, и время, чтобы загрузить зеркало через сеть, что может занять некоторое время.
• Выполняется: модуль привязан к узлу, и все контейнеры в модуле созданы. По крайней мере, один контейнер работает, запускается или перезапускается.
• Успешно: все контейнеры в модуле были успешно остановлены и не будут перезапущены
• Сбой: все контейнеры в модуле были остановлены, и по крайней мере один контейнер был остановлен из-за сбоя. Другими словами, контейнер выходит с ненулевым статусом или завершается системой.
• Неизвестно: статус модуля не может быть получен по некоторым причинам, обычно из-за сбоя связи с хостом, на котором находится модуль.

2.4 Классификация стручков

• Автономный модуль: модуль завершен, модуль этого типа не будет создан.
• Pod, управляемый контроллером: в жизненном цикле контроллера всегда должно поддерживаться количество копий Pod.