Cómo corregir el error de Kubernetes oomkilled
¿Qué es un error??
Oomkilled, para decirlo en pocas palabras, es un error de Kubernetes que ocurre cuando una vaina o contenedor usa más memoria de la que se le asigna. El OOM representa fuera de la memoria. Asesinado significa el final del proceso.
Aumentar la asignación de memoria es una manera fácil de resolver este problema recurrente. Sin embargo, esta técnica simple solo funciona si la memoria es infinitamente abundante y los recursos son ilimitados. Averigüemos más sobre el error oomable, sus principales causas, cómo solucionarlo y cómo equilibrar las asignaciones de memoria directamente en las siguientes secciones.
Tipos de error oomquillado
En Kubernetes, los errores Oomkilled vienen en dos variaciones diferentes. Uno está más otorgado: límite exagerado y el segundo está oomado: el límite del contenedor alcanzado.
Aprendamos más sobre estos errores con más profundidad.
Oomkilled: LIMIT Overommit Error
Cuando el agregado del límite de POD excede la memoria disponible del nodo, puede ocurrir un error. Por lo tanto, si un nodo tiene 6 GB de memoria disponible, por ejemplo, puede obtener seis vainas donde cada una requiere 1 GB de memoria. Sin embargo, corre el riesgo de quedarse sin memoria si incluso uno de esos pods está configurado con un límite de, por ejemplo, 1.1 gigabytes. Todo lo que se necesita para que Kubernetes comience a asesinar a los pods es que esa cápsula experimente un pico en el tráfico o una filtración de memoria no identificada.
Oomkilled: Límite de contenedor alcanzado
Kubernetes termina una aplicación con un error de "límite de contenedor oomkilled alcanzado" el código 137 si tiene una fuga de memoria o intenta consumir más memoria que el límite asignado.
Este es, con mucho, el error de memoria más elemental que puede ocurrir dentro de una cápsula. Cuando el límite del contenedor se alcanza normalmente, solo afecta a una cápsula, a diferencia del error de excomunción del límite, que tiene un impacto en la capacidad de RAM total del nodo.
Causas comunes de error oomquillado
Puede encontrar las causas típicas de este error en la siguiente lista. Tenga en cuenta que existen numerosas razones adicionales por las cuales ocurren errores omados y que muchos de estos son difíciles de identificar y resolver:
- Cuando se alcanza el límite de memoria del contenedor, la aplicación experimenta una carga que es más alta de lo normal.
- La aplicación tiene una fuga de memoria como resultado del límite de memoria del contenedor que se alcanza.
- El nodo se compromete en exceso, lo que significa que la cantidad total de memoria consumida por POD excede la memoria del nodo.
Cómo identificar el error OOMKILIZADO
El estado de la vaina se puede verificar para ver si se produce un error oomquillado. Luego, para obtener más información sobre el problema, use el comando Describe u obtenga. La salida del comando get pods, como se ve en lo siguiente, enumera los bloqueos de la cápsula que involucra una falla oomkilled.
Ejecute el comando "kubectl get pods" para encontrar el error. El estado de la vaina se muestra como terminación. Vea el siguiente comando y captura de pantalla:
> kubectl consigue vainas
El nombre de la cápsula, su estado, cuántas veces comenzó y la edad de la cápsula se obtiene por el comando "Get Pods". Aquí, puede ver que si se rompe una cápsula debido a un problema oomquillado, Kubernetes hace que el error sea muy obvio en el estado de la cápsula.
Cómo resolver el error Oomkilled?
Examinemos ahora una solución al error oomquillado.
En primer lugar, recopilamos los datos y guardamos el contenido del archivo para su uso posterior. Para hacerlo, primero realizamos el comando "kubectl describir pod". El comando ejecutado se adjunta de la siguiente manera:
> kubectl describir pod-pod-one/tmp/solving_oomkilled_error.TXT
Ahora debe mirar a través de los eventos de POD para el código de salida 137. Busque el siguiente mensaje (consulte la siguiente captura de pantalla) en la sección Evento del archivo de texto del archivo.
Debido a las limitaciones de memoria, el contenedor termina con el código de salida 137.
Hay dos razones más importantes para el error oomkilled. La primera razón es cuando la cápsula se termina debido al límite del contenedor y la segunda razón es cuando la cápsula se termina debido a la exageración en el nodo. Debe examinar los eventos de la historia reciente del POD para tratar de determinar qué causó el problema.
La sección anterior lo ayuda a identificar el error oomable. Una vez que haya terminado con eso, las siguientes consideraciones son necesarias para aplicar.
Si la cápsula se termina cuando se alcanza el límite del contenedor, estos puntos deben tenerse en cuenta:
- Analice si su aplicación necesita más memoria. Por ejemplo, si la aplicación es un sitio web que obtiene más tráfico, puede requerir más memoria de la que se planificó por primera vez. En este caso, el aumento del límite de memoria del contenedor en la especificación de POD resuelve el problema.
- Puede ocurrir una fuga de memoria en el programa si el uso de la memoria aumenta inesperadamente. Puede arreglar fácilmente la fuga de memoria y depurar la aplicación. En esta situación, aumentar el límite de memoria no es una solución recomendada porque la aplicación consume muchos recursos en los nodos.
Si el motivo de la terminación de Pod es el nodo exagerado, puede seguir estas pautas:
- El exceso de compromiso en un nodo también puede ocurrir cuando las cápsulas pueden organizarse en un nodo.
- Es importante averiguar la razón por la cual Kubernetes termina el POD con el error OOMKILIDADO. Realice actualizaciones con las solicitudes de memoria y limite los valores para evitar que el nodo sea exagerado.
Conclusión
Para resumir, los bloqueos de la cápsula son causados por un error más simple. Tener un plan de asignación de recursos apropiado para las instalaciones de Kubernetes es la mejor manera de manejar este problema. Al analizar cuidadosamente la utilización de recursos de la aplicación y la disponibilidad de los recursos en el clúster K8S, los usuarios pueden definir las limitaciones de recursos que no influirán en la funcionalidad del programa o el nodo.