Mes pods kubernetes n'arrêtent pas de crasher avec "CrashLoopBackOff" mais je ne trouve aucun journal

Question

C'est ce que je reçois:

[root@centos-master ~]# kubectl get pods
NAME               READY     STATUS             RESTARTS   AGE
nfs-server-h6nw8   1/1       Running            0          1h
nfs-web-07rxz      0/1       CrashLoopBackOff   8          16m
nfs-web-fdr9h      0/1       CrashLoopBackOff   8          16m

Ci-dessous est la sortie de "décrire les gousses" kubectl décrire les gousses

Events:
  FirstSeen LastSeen    Count   From                SubobjectPath       Type        Reason      Message
  --------- --------    -----   ----                -------------       --------    ------      -------
  16m       16m     1   {default-scheduler }                    Normal      Scheduled   Successfully assigned nfs-web-fdr9h to centos-minion-2
  16m       16m     1   {kubelet centos-minion-2}   spec.containers{web}    Normal      Created     Created container with docker id 495fcbb06836
  16m       16m     1   {kubelet centos-minion-2}   spec.containers{web}    Normal      Started     Started container with docker id 495fcbb06836
  16m       16m     1   {kubelet centos-minion-2}   spec.containers{web}    Normal      Started     Started container with docker id d56f34ae4e8f
  16m       16m     1   {kubelet centos-minion-2}   spec.containers{web}    Normal      Created     Created container with docker id d56f34ae4e8f
  16m       16m     2   {kubelet centos-minion-2}               Warning     FailedSync  Error syncing pod, skipping: failed to "StartContainer" for "web" with CrashLoopBackOff: "Back-off 10s restarting failed container=web pod=nfs-web-fdr9h_default(461c937d-d870-11e6-98de-005056040cc2)"

J'ai deux gousses: nfs-web-07rxz, nfs-web-fdr9h, mais si je fais "kubectl journaux nfs-web-07rxz" ou avec l'option "-p", je ne vois pas de journaux dans les deux gousses.

[root@centos-master ~]# kubectl logs nfs-web-07rxz -p
[root@centos-master ~]# kubectl logs nfs-web-07rxz

C'est mon replicationController fichier yaml: replicationController fichier yaml

apiVersion: v1 kind: ReplicationController metadata:   name: nfs-web spec:   replicas: 2   selector:
    role: web-frontend   template:
    metadata:
      labels:
        role: web-frontend
    spec:
      containers:
      - name: web
        image: eso-cmbu-docker.artifactory.eng.vmware.com/demo-container:demo-version3.0
        ports:
          - name: web
            containerPort: 80
        securityContext:
          privileged: true

Mon menu fixe de l'image a été faite à partir de cette simple docker fichier:

FROM ubuntu
RUN apt-get update
RUN apt-get install -y nginx
RUN apt-get install -y nfs-common

Je suis en cours d'exécution de mon kubernetes cluster sur CentOs-1611, kube version:

[root@centos-master ~]# kubectl version
Client Version: version.Info{Major:"1", Minor:"3", GitVersion:"v1.3.0", GitCommit:"86dc49aa137175378ac7fba7751c3d3e7f18e5fc", GitTreeState:"clean", BuildDate:"2016-12-15T16:57:18Z", GoVersion:"go1.6.3", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"3", GitVersion:"v1.3.0", GitCommit:"86dc49aa137175378ac7fba7751c3d3e7f18e5fc", GitTreeState:"clean", BuildDate:"2016-12-15T16:57:18Z", GoVersion:"go1.6.3", Compiler:"gc", Platform:"linux/amd64"}

Si je lance le panneau de l'image par "docker run" j'ai été en mesure d'exécuter l'image sans aucun problème, seulement par le biais de kubernetes j'ai eu l'accident.

Quelqu'un peut-il m'aider, comment puis-je déboguer sans voir un journal?

Answer 1

Comme @Sukumar l'a commenté, vous devez que votre fichier Docker ait une commande à exécuter ou que votre ReplicationController spécifie une commande.

Le pod se bloque car il démarre puis se termine immédiatement. Kubernetes redémarre et le cycle se poursuit.

Answer 2

kubectl -n <namespace-name> describe pod <pod name>

kubectl -n <namespace-name> logs -p  <pod name> 

Answer 3

Si vous avez une application qui prend plus lent de bootstrap, il pourrait être lié à la valeur initiale de l'état de préparation/liveness sondes. J'ai résolu mon problème en augmentant la valeur de initialDelaySeconds de 120s que mes SpringBoot application traite avec beaucoup d'initialisation. La documentation ne pas mentionner la valeur par défaut 0 (https://kubernetes.io/docs/api-reference/v1.9/#probe-v1-core)

service:
  livenessProbe:
    httpGet:
      path: /health/local
      scheme: HTTP
      port: 8888
    initialDelaySeconds: 120
    periodSeconds: 5
    timeoutSeconds: 5
    failureThreshold: 10
  readinessProbe:
    httpGet:
      path: /admin/health
      scheme: HTTP
      port: 8642
    initialDelaySeconds: 150
    periodSeconds: 5
    timeoutSeconds: 5
    failureThreshold: 10

Une très bonne explication à propos de ces valeurs est donnée par Ce qui est la valeur par défaut de initialDelaySeconds.

La santé ou la préparation à l'algorithme de vérification des œuvres comme:

1. attendez initialDelaySeconds
2. effectuer la vérification et attendez timeoutSeconds pour un délai d'attente si le nombre de succès continu est plus grand que successThreshold retour réussite
3. si le nombre de suite de défaillances est plus grand que failureThreshold retour l'échec sinon attendez periodSeconds et de commencer une nouvelle case

Dans mon cas, ma demande peut maintenant bootstrap de façon très claire, de sorte que je sais que je ne vais pas me périodique crashloopbackoff car il est parfois à la limite de ces taux.

Answer 4

J'avais besoin de garder un pod en cours d'exécution pour les appels ultérieurs de kubectl exec et, comme le soulignaient les commentaires ci-dessus, mon pod était en train d'être tué par mon cluster k8s car il avait exécuté toutes ses tâches. J'ai réussi à garder mon pod en marche en le tapant simplement avec une commande qui ne s'arrêtait pas automatiquement comme dans:

 kubectl run YOUR_POD_NAME -n YOUR_NAMESPACE --image SOME_PUBLIC_IMAGE:latest --command tailf /dev/null
 

Answer 5

À partir de Cette page, le conteneur meurt après l'exécution de tout correctement mais se bloque parce que toutes les commandes terminées. Soit vous faites vos services à exécuter sur le premier plan, ou de vous créer un keep alive script. Ce faisant, Kubernetes montrera que votre demande est en cours d'exécution. Il faut noter que dans l' Docker environnement, ce problème n'est pas rencontré. C'est seulement Kubernetes qui veut une application en cours d'exécution.