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

kubernetes vs docker (5)

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

El pod se bloquea porque se inicia y luego sale inmediatamente, por lo que Kubernetes se reinicia y el ciclo continúa.

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 la salida de "describe 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 log en ambos pods.

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

Este es mi archivo yaml replicationController : archivo yaml replicationController

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 hizo a partir de este simple archivo 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 kubernetes en CentOs-1611, versión 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 por "ejecución de la ventana acoplable" pude ejecutar la imagen sin ningún problema, solo a través de kubernetes obtuve el bloqueo.

¿Puede alguien ayudarme? ¿Cómo puedo depurar sin ver ningún registro?

Desde esta página , el contenedor muere después de ejecutar todo correctamente pero se bloquea porque todos los comandos terminaron. 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 tener en cuenta que en el entorno Docker , este problema no se encuentra. Sólo Kubernetes quiere una aplicación en ejecución.

Si tiene una aplicación que tarda más en arrancar, puede estar relacionada con los valores iniciales de las sondas de preparación / vida. initialDelaySeconds mi problema aumentando el valor de initialDelaySeconds a initialDelaySeconds ya que mi aplicación SpringBoot se ocupa de mucha inicialización. La documentación no menciona el valor predeterminado 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

What es el valor predeterminado de initialDelaySeconds .

El algoritmo de comprobación de estado o preparación funciona como:
espere initialDelaySeconds
realice la verificación y espere un tiempo de espera por un tiempo de espera si el número de éxitos continuos es mayor que el éxito.
Si el número de fallas continuadas es mayor que la failureThreshold falla del retorno del failureThreshold , de lo contrario, debe esperar un periodSeconds y comenzar una nueva verificación.

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

Tenía la necesidad de mantener un pod en marcha para las posteriores llamadas de exub de kubectl y, como se ha dicho en los comentarios anteriores, mi clúster k8 mató a mi pod porque había completado la ejecución de todas sus tareas. Logré mantener mi pod en marcha 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

kubectl -n <namespace-name> describe pod <pod name> kubectl -n mortgages-dev2 logs -p <pod name>