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

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?

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.

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

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

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

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.

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

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.

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.

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

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

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.

Resolví este problema Aumenté el recurso de memoria

  resources:
          limits:
            cpu: 1
            memory: 1Gi
          requests:
            cpu: 100m
        memory: 250Mi 

Tuve el mismo problema y ahora finalmente lo resolví. No estoy usando el archivo docker-compose. Acabo de agregar esta línea en mi archivo Docker y funcionó.

ENV CI=true

Referencia: https://github.com/GoogleContainerTools/skaffold/issues/3882

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.

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

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