Nota
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
Si un pod tiene un CrashLoopBackOff
estado, es probable que el pod produzca un error o se salga inesperadamente, y el registro contiene un código de salida que no es cero. Estos son varios motivos posibles por los que el pod está en modo CrashLoopBackOff
bloqueado.
- Error de aplicación: la aplicación dentro del contenedor se bloquea poco después de iniciarse, a menudo debido a configuraciones incorrectas, dependencias que faltan o variables de entorno incorrectas.
- Límites de recursos incorrectos: si el pod supera sus límites de recursos de CPU o memoria, Kubernetes podría eliminar el contenedor. Este problema puede ocurrir si las solicitudes de recursos o los límites se establecen demasiado bajos.
- Missing or misconfigured ConfigMaps/Secrets: si la aplicación se basa en archivos de configuración o variables de entorno almacenadas en ConfigMaps o Secretos, pero faltan o están mal configurados, la aplicación podría bloquearse.
- Problemas de extracción de imágenes: si hay un problema con la imagen (por ejemplo, está dañado o tiene una etiqueta incorrecta), es posible que el contenedor no se inicie correctamente y produzca un error repetidamente.
- Error en los contenedores de inicialización: si el pod tiene contenedores de inicialización y uno o varios no se pueden ejecutar correctamente, el pod se reiniciará.
- Errores de sondeo de ejecución/preparación: si los sondeos de ejecución o preparación están mal configurados, Kubernetes podría detectar el contenedor como en mal estado y reiniciarlo.
- Dependencias de la aplicación no listas: es posible que la aplicación dependa de los servicios que aún no están listos, como bases de datos, colas de mensajes u otras API.
- Problemas de red: las configuraciones incorrectas de red pueden impedir que la aplicación se comunique con los servicios necesarios, lo que hace que se produzca un error.
-
Comandos o argumentos no válidos: es posible que el contenedor se inicie con un comando, un argumento o un comando no válidos
ENTRYPOINT
, lo que provoca un bloqueo.
Para obtener más información sobre el estado del contenedor, consulte Ciclo de vida del pod: estados del contenedor.
Tenga en cuenta las siguientes opciones y sus comandos kubectl asociados.
Opción | Comando kubectl |
---|---|
Depurar el pod en sí mismo | kubectl describe pod <pod-name> |
Depurar los controladores de replicación | kubectl describe replicationcontroller <controller-name> |
Leer el mensaje de finalización | kubectl get pod <pod-name> --output=yaml |
Examen de los registros | kubectl logs <pod-name> |
Nota:
Un pod también puede tener un CrashLoopBackOff
estado si ha finalizado la implementación, pero está configurado para mantener el reinicio aunque el código de salida sea cero. Por ejemplo, si implementa una imagen de busybox sin especificar ningún argumento, la imagen se inicia, ejecuta, finaliza y, a continuación, se reinicia en un bucle:
$ kubectl run nginx --image nginx
pod/nginx created
$ kubectl run busybox --image busybox
pod/busybox created
$ kubectl get pods --watch
NAME READY STATUS RESTARTS AGE
busybox 0/1 ContainerCreating 0 3s
nginx 1/1 Running 0 11s
busybox 0/1 Completed 0 3s
busybox 0/1 Completed 1 4s
busybox 0/1 CrashLoopBackOff 1 5s
$ kubectl describe pod busybox
Name: busybox
Namespace: default
Priority: 0
Node: aks-nodepool<number>-<resource-group-hash-number>-vmss<number>/<ip-address-1>
Start Time: Wed, 16 Aug 2023 09:56:19 +0000
Labels: run=busybox
Annotations: <none>
Status: Running
IP: <ip-address-2>
IPs:
IP: <ip-address-2>
Containers:
busybox:
Container ID: containerd://<64-digit-hexadecimal-value-1>
Image: busybox
Image ID: docker.io/library/busybox@sha256:<64-digit-hexadecimal-value-2>
Port: <none>
Host Port: <none>
State: Waiting
Reason: CrashLoopBackOff
Last State: Terminated
Reason: Completed
Exit Code: 0
Started: Wed, 16 Aug 2023 09:56:37 +0000
Finished: Wed, 16 Aug 2023 09:56:37 +0000
Ready: False
Restart Count: 2
Si no reconoce el problema después de crear más pods en el nodo, ejecute un pod en un solo nodo para determinar cuántos recursos usa realmente el pod.
Aviso de declinación de responsabilidades sobre la información de terceros
Los productos de otros fabricantes que se mencionan en este artículo han sido creados por compañías independientes de Microsoft. Microsoft no ofrece ninguna garantía, ya sea implícita o de otro tipo, sobre la confiabilidad o el rendimiento de dichos productos.
Ponte en contacto con nosotros para obtener ayuda
Si tiene preguntas o necesita ayuda, cree una solicitud de soporte o busque consejo en la comunidad de Azure. También puede enviar comentarios sobre el producto a la comunidad de comentarios de Azure.