Fijar Kubernetes ImagePullBackoff

Si ha estado trabajando con Kubernetes durante mucho tiempo, probablemente haya encontrado la condición de ImagePullBackoff. Si no está familiarizado con este problema, puede ser frustrante. Entonces, en este artículo, lo guiará a través de los conceptos básicos de este problema, cómo solucionarlo, cuáles son algunas razones típicas y dónde comenzar si lo enfrenta.

¿Cuál es el error ImagePullBackoff?

El problema de ImagePullBackoff es causado por el tiempo de ejecución de su contenedor Kubernetes que no puede obtener la imagen de un registro de contenedores público o privado. Kubernetes tirará constantemente la imagen con un retraso creciente de retroceso, como lo indica el componente de retroceso. Con cada intento, Kubernetes aumentará el retraso hasta que cumpla con la restricción de cinco minutos.

Puede parecer una declaración amplia sugerir que el tiempo de ejecución del contenedor (ya sea Docker, Container o algo más) no puede recuperar la imagen del registro, pero veamos las diversas causas que puede encontrar en la siguiente sección.

Las secciones anteriores repasarán las diversas razones por las cuales su cápsula puede estar en el estado de ImagePullbackoff cuando inicie su contenedor. También aprenderá cómo solucionar problemas y resolver este temido error.

¿Qué hace que ocurra el error de ImagePullBackoff??

Las siguientes son algunas de las razones por las cuales su cápsula puede estar atrapado en el estado de ImagePullbackoff:

• Imagen no disponible
• El nombre o etiqueta para la imagen es incorrecta.
• Se utiliza la imagen privada y hay un problema con la autenticación.
• Hay una dificultad con la red.
• El nombre del registro es inexacto.
• Límites de tarifa para registros de contenedores
• El Pod no tiene acceso a la imagen porque carece de las credenciales necesarias.
• Límites en las tasas de registro

Cómo solucionar problemas ImagePullBackoff?

Veamos algunas de las causas probables que se enumeran en la lista de balas.

1. La imagen del contenedor no está disponible, o el nombre utilizado es inexacto
El problema generalmente se genera si hay un error tipográfico o el hecho de que la imagen presionada al registro de contenedores fallará, pero se refiere a una imagen que no está allí. Intentemos recrear esto haciendo una cápsula con un nombre de imagen ficticio. El siguiente comando logra esto.

$ kubectl ejecutar newApp --image = my_image/my_image: Último

Como puede ver, se crea el Pod.

Si intentamos obtener los detalles de la cápsula con el comando get pods como puede ver a continuación.

$ Kubectl get pod

Aquí, se muestra que la imagen no está allí y no podemos tirarla.

Puede hacer uso del comando de describir kubectl con el fin de descubrir la causa raíz y encontrar más información sobre este problema. Debido a que el comando produce una gran cantidad de resultados, solo mostraremos las secciones que son pertinentes a nuestra discusión. El mensaje de error real se ve en la siguiente salida en eventos en la columna del mensaje:

$ Kubectl describe podlepp newapp

Algunas secciones del resultado producido son las siguientes después de ejecutar el comando Describe.

2. La etiqueta no existe
Es posible que las etiquetas de imagen que está intentando obtener se hayan retirado, o que haya escrito el nombre de la etiqueta erróneo. En algunas circunstancias, su POD se atascará en el estado de ImagePullbackoff una vez más, como se muestra en la muestra de código a continuación. Para reproducir este problema, usamos intencionalmente el nombre de la etiqueta erróneo, Lates en lugar de las últimas.

$ kubectl run appTwo --image = nginx: lates

El comando anterior ha creado la cápsula con el nombre que ha dado.

Después de eso, obtenemos los detalles de la cápsula con el comando get pod.

$ kubectl get pod

Como resultado, la imagen extrae fallas.

Ahora, nuevamente estamos usando el comando describir para comprender la causa de este estado.

$ Kubectl Describe la appTwo

En esta sección de eventos, puede ver el motivo del error ImagePullBackoff.

La razón se muestra claramente aquí para su mejor comprensión.

3. Credenciales incorrectas y registro de imágenes privadas

Aquí, estamos tratando de reproducir el problema y, para eso, comimos girar una cápsula que intenta extraer una imagen de un registro privado.

$ kubectl ejecutar appthree --image = Docker.io/hiyou/nameOfimage

El comando anterior da el siguiente resultado.

Después de eso, hemos ejecutado el comando de describir.

El comando descrito muestra los detalles generales de la cápsula y también menciona las razones detrás del error de ImagePullBackoff.

No hemos agregado un secreto a Kubernetes ni hemos incluido una referencia en la definición de POD. La cápsula se atascará en el estado de ImagePullbackoff una vez más, y la notificación verifica que el acceso al registro se niega:

Puede crear un secreto con el comando kubectl a continuación para corregir este error. El comando Kubectl se usa para crear un secreto para un registro de Docker (privado).

4. Límites de tasa de registro

Si verifica algunas de sus credenciales, como URL de registro, detalles y nombre de la etiqueta, puede obtener ImagePullBackoff debido a los límites de tasa de registro. Ahora solo puede tirar de 100 contenedores cada seis horas en Docker Hub. Si proporciona sus detalles de inicio de sesión, esto subirá a 200 tirones cada seis horas. En un clúster animado con numerosos vainas desplegadas con frecuencia, ese límite podría alcanzarse rápidamente.

Deberá esperar hasta alcanzar la tapa después de un límite de tiempo específico. Kubernetes ahora debería poder extraer con éxito la imagen e iniciar sus vainas.

Considere usar su registro en el clúster junto con un proxy para almacenar en caché sus imágenes relevantes. Esto puede ayudarlo a permanecer dentro de las limitaciones de tasa al reducir la cantidad de veces que llega a los servidores de Docker.

Conclusión

Cuando un nodo no puede extraer una imagen, las vainas de Kubernetes entran en el estado de ImagePullBackoff. Kubelet intentará el tirón regularmente, por lo que los problemas temporales no requerirán ninguna intervención manual. Este artículo discutió ImagePullbackoff y tres fuentes potenciales del problema. Aunque puede haber varias causas, leer el mensaje de error puede revelar rápidamente la verdadera causa del problema. Si examina y sigue los procedimientos anteriores, solucionar este problema debería ser simple.