web-dev-qa-db-fra.com

Pods bloqués indéfiniment dans l'état PodInitializing

J'ai un cronjob k8s qui se compose d'un conteneur init et d'un conteneur pod. Si le conteneur init échoue, le pod du conteneur principal ne démarre jamais et reste indéfiniment dans "PodInitializing".

Mon intention est que le travail échoue si le conteneur init échoue.

---
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

un kubectl sur le pod qui est bloqué se traduit par:

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
kuberneteskubernetes-podkubernetes-cronjobkubernetes-jobs
3
Anderson

Je pense que vous pourriez manquer que c'est le comportement attendu des conteneurs init. La règle est qu'en cas d'échec d'initContainers, un pod ne redémarrera pas si restartPolicy est défini sur Jamais, sinon Kubernetes continuera de le redémarrer jusqu'à ce qu'il réussisse.

Aussi:

Si le conteneur init échoue, le pod du conteneur principal ne démarre jamais et reste indéfiniment dans "PodInitializing".

Selon documentation:

Un pod ne peut pas être prêt tant que tous les conteneurs Init n'ont pas réussi. Les ports d'un conteneur Init ne sont pas agrégés sous un service. Un pod en cours d'initialisation est dans l'état En attente mais doit avoir une condition Initialisation définie sur true.

* Je peux voir que vous avez essayé de changer ce comportement, mais je ne sais pas si vous pouvez le faire avec CronJob, j'ai vu des exemples avec Jobs. Mais je ne fais que théoriser, et si ce message ne vous a pas aidé à résoudre votre problème, je peux essayer de le recréer dans un environnement de laboratoire.

3
aurelius

Pour essayer de comprendre cela, j'exécuterais la commande:

kubectl get pods - Ajoutez le paramètre d'espace de noms si nécessaire.

Copiez ensuite le nom du module et exécutez:

kubectl describe pod {POD_NAME}

Cela devrait vous donner des informations sur la raison pour laquelle il est bloqué dans l'état d'initialisation.

2
ajtrichards

Puisque vous avez déjà compris que les conteneurs init sont censés fonctionner jusqu'à la fin, avec succès. Si vous ne pouvez pas vous débarrasser des conteneurs init, ce que je ferais dans ce cas est de m'assurer que le conteneur init se termine avec succès tout le temps. Le résultat du conteneur init peut être écrit dans un volume emptydir, quelque chose comme un fichier d'état, partagé par votre conteneur init et votre conteneur de travail. Je déléguerais au conteneur de travail la responsabilité de décider quoi faire au cas où le conteneur d'init se terminerait en vain.

1
Bal Chua