Mis pods de Kubernetes siguen fallando con "CrashLoopBackOff" pero no puedo encontrar ningún registro

107

Esto es lo que sigo recibiendo:

[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

A continuación se muestra el resultado de "describir pods" kubectl describe pods

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

Tengo dos pods: nfs-web-07rxz, nfs-web-fdr9h, pero si hago "kubectl logs nfs-web-07rxz" o con la opción "-p" no veo ningún registro en ambos pods.

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

Este es mi archivo replicationController yaml : replicationController yaml file

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

Mi imagen de Docker se creó a partir de este simple archivo de Docker:

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

Estoy ejecutando mi clúster de kubernetes en CentOs-1611, versión de kube:

[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 ejecuto la imagen de la ventana acoplable mediante "ejecución de la ventana acoplable", pude ejecutar la imagen sin ningún problema, solo a través de kubernetes obtuve el bloqueo.

¿Alguien puede ayudarme, cómo puedo depurar sin ver ningún registro?

kubernetes 
— Lucifer
fuente
1
¿Puedes intentar agregar un comando al pod yaml?
— Sukumar
2
Verifique los registros con kubectl logs -f <pod_name>él podría ser el problema de inicio (servidor / contenedor).
— Vishrant
También puede correr kubectl get eventspara ver qué está causando el ciclo de aplastamiento.
— Margach Chris

Respuestas:

83

Como comentó @Sukumar, necesita que su Dockerfile tenga un comando para ejecutar o que su ReplicationController especifique un comando.

El módulo se bloquea porque se inicia y luego se cierra inmediatamente, por lo que Kubernetes se reinicia y el ciclo continúa.

— Steve Sloka
fuente
1
Si hemos agregado el Dockerfile adecuado y aún recibimos el error, ¿cuál puede ser la razón? Recibo el mismo error incluso si agregué correctamente el comando. Y cuando estoy probando la imagen de la ventana acoplable independiente sin usar la implementación de Kubernetes, obtengo el resultado. Entonces no es un problema con Dockerfile. ¿Es algo relacionado con el despliegue ?. Aquí agregué todo el problema al que me enfrento, stackoverflow.com/questions/56001352/… . ¿Puedes mirar eso?
— Jacob
2
Hay un muy buen blog que va en profundidad sobre lo que significa un CrashLoopBackoff y los diversos casos en los que esto puede suceder: managedkube.com/kubernetes/pod/failure/crashloopbackoff/k8sbot/...
— gar
52 
kubectl -n <namespace-name> describe pod <pod name>

kubectl -n <namespace-name> logs -p  <pod name>
— user128364
fuente
47
Aunque estos comandos pueden (o no resolver) el problema, una buena respuesta siempre debe contener una explicación de cómo se resuelve el problema.
— BDL
El primer comando kubectl -n <namespace-name> describe pod <pod name>es describir su pod, que se puede utilizar para ver cualquier error en la creación del pod y ejecutar el pod como falta de recursos, etc. Y el segundo comando kubectl -n <namespace-name> logs -p <pod name>para ver los registros de la aplicación que se ejecuta en el pod.
— iamabhishek
13

Tenía la necesidad de mantener un pod en ejecución para las siguientes llamadas ejecutivas de kubectl y, como los comentarios anteriores señalaron, mi grupo de k8s estaba matando a mi pod porque había completado la ejecución de todas sus tareas. Me las arreglé para mantener mi pod funcionando simplemente pateando el pod con un comando que no se detendría automáticamente como en:

kubectl run YOUR_POD_NAME -n YOUR_NAMESPACE --image SOME_PUBLIC_IMAGE:latest --command tailf /dev/null
— hmacias
fuente
7
tailfno funcionó para mí, pero esto sí (en Alpine Linux):--command /usr/bin/tail -- -f /dev/null
— Jakub Holý
1
no es el nombre de la vaina. es el nombre de la implementación. kubectl run <deployment name> -n <namespace> --image <image> --command tailf /dev/null
— Gabriel Wu
9

Si tiene una aplicación que tarda más en arrancar, podría estar relacionada con los valores iniciales de las sondas de preparación / actividad. Resolví mi problema aumentando el valor de initialDelaySecondsa 120 ya que mi SpringBootaplicación se ocupa de una gran cantidad de inicialización. La documentación no menciona el 0 predeterminado ( 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

Cuál es el valor predeterminado de initialDelaySeconds da una muy buena explicación sobre esos valores .

El algoritmo de verificación de estado o preparación funciona así:

  1. esperar initialDelaySeconds
  2. Realice la verificación y espere timeoutSecondsun tiempo de espera si el número de éxitos continuos es mayor que el successThresholdéxito de retorno.
  3. si la cantidad de fallas continuas es mayor que la failureThresholdfalla de retorno, de lo contrario, espere periodSecondsy comience una nueva verificación

En mi caso, mi aplicación ahora puede arrancar de una manera muy clara, de modo que sé que no obtendré retrocesos periódicos porque a veces estaría en el límite de esas tasas.

— Marcello de Sales
fuente
me ahorraste muchas horas! Gracias. Mi tiempo de prueba era de 90 y ni siquiera dejaba que la cápsula se iniciara.
— Abhinav Pandey
8

Desde esta página , el contenedor muere después de ejecutar todo correctamente, pero se bloquea porque todos los comandos finalizaron. O haces que tus servicios se ejecuten en primer plano o creas un script para mantener vivo. Al hacerlo, Kubernetes mostrará que su aplicación se está ejecutando. Tenemos que señalar que en el Dockermedio ambiente, este problema no se encuentra. Solo Kubernetes quiere una aplicación en ejecución.

Actualizar (un ejemplo):

A continuación, se explica cómo evitar CrashLoopBackOff , al iniciar un contenedor Netshoot :

kubectl run netshoot --image nicolaka/netshoot -- sleep infinity
— Julien Nyambal
fuente
6

Mi cápsula siguió fallando y no pude encontrar la causa. Afortunadamente, hay un espacio donde kubernetes guarda todos los eventos que ocurrieron antes de que mi pod se bloqueara .
(#Lista de eventos ordenados por marca de tiempo)

Para ver estos eventos, ejecute el comando:

kubectl get events --sort-by=.metadata.creationTimestamp

asegúrese de agregar un --namespace mynamespaceargumento al comando si es necesario

Los eventos que se muestran en la salida del comando me mostraron por qué mi pod seguía fallando.

— matyas
fuente
¡Gracias! Este consejo me ayudó a detectar que había un problema al montar el volumen en secreto.
— Leif John
También me ayudó a descubrir que la identidad administrada asignada en el pod era incorrecta.
— Jorn.Beyers
3

En su archivo yaml, agregue líneas de comando y argumentos:

...
containers:
      - name: api
        image: localhost:5000/image-name 
        command: [ "sleep" ]
        args: [ "infinity" ]
...

Funciona para mi.

— Marcela Romero
fuente
1

Observé el mismo problema y agregué el comando y el bloque args en el archivo yaml. Estoy copiando una muestra de mi archivo yaml como referencia

 apiVersion: v1
    kind: Pod
    metadata:
      labels:
        run: ubuntu
      name: ubuntu
      namespace: default
    spec:
      containers:
      - image: gcr.io/ow/hellokubernetes/ubuntu
        imagePullPolicy: Never
        name: ubuntu
        resources:
          requests:
            cpu: 100m
        command: ["/bin/sh"]
        args: ["-c", "while true; do echo hello; sleep 10;done"]
      dnsPolicy: ClusterFirst
      enableServiceLinks: true
— amit23comp
fuente
0

En mi caso el problema fue lo que Steve S. mencionó:

El módulo se bloquea porque se inicia y luego se cierra inmediatamente, por lo que Kubernetes se reinicia y el ciclo continúa.

Es decir, tenía una aplicación Java que mainarrojó una excepción (y algo anuló el controlador de excepciones no detectado predeterminado para que no se registrara nada). La solución fue poner el cuerpo de mainentry { ... } catch e imprimir la excepción. Así pude averiguar qué estaba mal y solucionarlo.

(Otra causa podría ser algo en la aplicación que llama System.exit; podría usar unSecurityManager con una anulación checkExitpara evitar (o registrar a la persona que llama) salir; consulte https://stackoverflow.com/a/5401319/204205 .)

— Jakub Holý
fuente
0

Mientras solucionaba el mismo problema, no encontré registros al usar kubeclt logs <pod_id>. Por lo tanto, ingresé a la instancia del nodo para intentar ejecutar el contenedor usando la ventana acoplable simple. Para mi sorpresa, esto también falló.

Al entrar al contenedor con: 

docker exec -it faulty:latest /bin/sh

y hurgando descubrí que no era la última versión.

Una versión defectuosa de la imagen de la ventana acoplable ya estaba disponible en la instancia.

Cuando eliminé la última instancia defectuosa con:

docker rmi faulty:latest

todo empezó a funcionar.

— javabeangrinder
fuente
0

Resolví este problema Aumenté el recurso de memoria

  resources:
          limits:
            cpu: 1
            memory: 1Gi
          requests:
            cpu: 100m
        memory: 250Mi
— Yosra ADDALI
fuente
0

Intente volver a ejecutar el pod y ejecutar

 kubectl get pods --watch

para ver el estado del módulo a medida que avanza.

En mi caso, solo vería el resultado final, 'CrashLoopBackOff', pero el contenedor de la ventana acoplable funcionó bien localmente. Así que observé las cápsulas usando el comando anterior y vi que el contenedor avanzaba brevemente a un estado OOMKilled , lo que significaba para mí que requería más memoria.

— Josh Wolff
fuente
0

Resolví este problema eliminando el espacio entre las comillas y el valor del comando dentro de la matriz, esto se debe a que el contenedor salió después del inicio y no hay ningún comando ejecutable presente que se ejecute dentro del contenedor.

['sh', '-c', 'echo Hello Kubernetes! && sleep 3600']
— arjun a
fuente
0

Tuve un problema similar, pero lo resolví cuando corrigí mi zookeeper.yamlarchivo que tenía el nombre del servicio que no coincidía con los nombres del contenedor de la implementación del archivo. Se resolvió haciéndolos iguales.

apiVersion: v1
kind: Service
metadata:
  name: zk1
  namespace: nbd-mlbpoc-lab
  labels:
    app: zk-1
spec:
  ports:
  - name: client
    port: 2181
    protocol: TCP
  - name: follower
    port: 2888
    protocol: TCP
  - name: leader
    port: 3888
    protocol: TCP
  selector:
    app: zk-1
---
kind: Deployment
apiVersion: extensions/v1beta1
metadata:
  name: zk-deployment
  namespace: nbd-mlbpoc-lab
spec:
  template:
    metadata:
      labels:
        app: zk-1
    spec:
      containers:
      - name: zk1
        image: digitalwonderland/zookeeper
        ports:
        - containerPort: 2181
        env:
        - name: ZOOKEEPER_ID
          value: "1"
        - name: ZOOKEEPER_SERVER_1
          value: zk1
— Ashna
fuente
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.