Поды застряли в состоянии PodInitializing на неопределенный срок

У меня есть задание cron для k8s, которое состоит из контейнера инициализации и контейнера с одним подом. В случае сбоя контейнера инициализации Pod в основном контейнере никогда не запускается и остается в «PodInitializing» на неопределенное время.

Мое намерение состоит в том, чтобы задание не удалось выполнить, если контейнер инициализации выйдет из строя.

---
apiVersion: batch/v1beta1
kind: CronJob
metadata:
  name: job-name
  namespace: default
  labels:
    run: job-name
spec:
  schedule: "15 23 * * *"
  startingDeadlineSeconds: 60
  concurrencyPolicy: "Forbid"
  successfulJobsHistoryLimit: 30
  failedJobsHistoryLimit: 10
  jobTemplate:
    spec:
      # only try twice
      backoffLimit: 2
      activeDeadlineSeconds: 60
      template:
        spec:
          initContainers:
          - name: init-name
            image: init-image:1.0
          restartPolicy: Never
          containers:
          - name: some-name
            image: someimage:1.0
          restartPolicy: Never

kubectl на застрявшем модуле приводит к:

Name:               job-name-1542237120-rgvzl
Namespace:          default
Priority:           0
PriorityClassName:  <none>
Node:               my-node-98afffbf-0psc/10.0.0.0
Start Time:         Wed, 14 Nov 2018 23:12:16 +0000
Labels:             controller-uid=ID
                    job-name=job-name-1542237120
Annotations:        kubernetes.io/limit-ranger:
                      LimitRanger plugin set: cpu request for container elasticsearch-metrics; cpu request for init container elasticsearch-repo-setup; cpu requ...
Status:             Failed
IP:                 10.0.0.0
Controlled By:      Job/job-1542237120
Init Containers:
init-container-name:
    Container ID:  docker://ID
    Image:         init-image:1.0
    Image ID:      init-imageID
    Port:          <none>
    Host Port:     <none>
    State:          Terminated
      Reason:       Error
      Exit Code:    1
      Started:      Wed, 14 Nov 2018 23:12:21 +0000
      Finished:     Wed, 14 Nov 2018 23:12:32 +0000
    Ready:          False
    Restart Count:  0
    Requests:
      cpu:        100m
    Environment:  <none>
    Mounts:
      /var/run/secrets/kubernetes.io/serviceaccount from default-token-wwl5n (ro)
Containers:
  some-name:
    Container ID:  
    Image:         someimage:1.0
    Image ID:      
    Port:          <none>
    Host Port:     <none>
    State:          Waiting
      Reason:       PodInitializing
    Ready:          False
    Restart Count:  0
    Requests:
      cpu:        100m
    Environment:  <none>
    Mounts:
      /var/run/secrets/kubernetes.io/serviceaccount from default-token-wwl5n (ro)
Conditions:
  Type              Status
  Initialized       False 
  Ready             False 
  ContainersReady   False 
  PodScheduled      True

kubernetes kubernetes-pod kubernetes-cronjob kubernetes-jobs
person Anderson    schedule 15.11.2018    source источник
comment
чтение логов контейнера инициализации с kubectl logs <pod> -c <init_container_name> всегда помогает!   -  person Ivan Aracki    schedule 20.05.2020
comment
спасибо, я знаю, почему это не удается, и нормально, если это не удается, вопрос был в том, что делать в ответ на успех / неудачу :)   -  person Anderson    schedule 18.06.2020

Ответы (3)


arrow_upward
20
arrow_downward

Чтобы попытаться понять это, я бы запустил команду:

kubectl get pods - При необходимости добавьте параметр пространства имен.

Затем скопируйте имя модуля и запустите:

kubectl describe pod {POD_NAME}

Это должно дать вам некоторую информацию о том, почему он застрял в состоянии инициализации.

person ajtrichards    schedule 15.11.2018
comment
Я думаю, что это дизайн контейнеров инициализации, он не запустит основные контейнеры, пока все контейнеры инициализации не завершатся успешно. Недостаток может заключаться в том, что не ожидается, что контейнеры инициализации выйдут из строя (в моем случае это так). Я пошел дальше и провел описание в капсуле. Я добавил результат описания в исходный пост. - person Anderson; 15.11.2018

arrow_upward
4
arrow_downward

Я думаю, вы могли упустить из виду, что это ожидаемое поведение контейнеров инициализации. Правило состоит в том, что в случае сбоя initContainers Pod не будет перезапускаться, если для параметра restartPolicy установлено значение Never, в противном случае Kubernetes будет перезапускать его до тех пор, пока он не завершится успешно.

Также:

В случае сбоя контейнера инициализации Pod в основном контейнере никогда не запускается и остается в «PodInitializing» на неопределенное время.

Согласно документации:

Pod не может быть готов до тех пор, пока не будут выполнены все контейнеры инициализации. Порты в контейнере инициализации не объединяются в службу. Pod, который инициализируется, находится в состоянии Pending, но для его условия Initializing должно быть задано значение true.

* Я вижу, что вы пытались изменить это поведение, но я не уверен, что вы можете сделать это с помощью CronJob, я видел примеры с Jobs. Но я просто теоретизирую, и если этот пост не помог вам решить вашу проблему, я могу попытаться воссоздать его в лабораторной среде.

person aurelius    schedule 15.11.2018
comment
Спасибо. Я как бы подумал, что контейнеры инициализации не предназначены для этого, но было бы здорово, если бы я мог автоматически избавиться от заданий PodInitialising. Вы говорите, что видели примеры с Джобсом? Не могли бы вы их предоставить? Cronjob - это просто контроллер, а поды объявляются в соответствии со спецификацией задания, поэтому, если я смогу получить задание по отказу застрявших контейнеров, это решит мою проблему. - person Anderson; 16.11.2018

arrow_upward
1
arrow_downward

Поскольку вы уже выяснили, что initcontainers предназначены для успешного выполнения до завершения. Если вы не можете избавиться от контейнеров инициализации, в этом случае я бы сделал так, чтобы убедиться, что контейнер инициализации все время успешно завершается. Результат контейнера инициализации может быть записан в том emptydir, что-то вроде файла состояния, совместно используемого как вашим контейнером инициализации, так и вашим рабочим контейнером. Я бы делегировал рабочему контейнеру ответственность за решение, что делать в случае неудачного завершения инициализации контейнера.

person Bal Chua    schedule 16.11.2018