Kubernetes, uno de los sistemas para la gestión de contenedores más populares, automatiza el trabajo necesario para implementar y escalar una aplicación contenedorizada administrando un gran número de microservicios interdependientes. Adicionalmente, permite migrar e implementar aplicaciones contenedorizadas en varias plataformas en un entorno multinube.
En una encuesta reciente realizada por Red Hat se muestra que cerca del 70% de los líderes de TI trabajan para organizaciones que usan Kubernetes, también conocido como K8s. Esto se debe a que hay actualizaciones regulares por parte de la comunidad, que nutre el entorno con las últimas soluciones.
Sin embargo, el crecimiento constante de los microservicios dentro de la plataforma de Kubernetes crea una multitud de problemas que podrían hacer que aplicaciones críticas para el negocio no estén disponibles para los usuarios finales.
Aunque Kubernetes se renueva para implementar aplicaciones virtualmente donde sea, también enfrenta la desventaja de tener muchos componentes dentro de su red. Otra consiste en que incluso una pequeña interrupción de servicios dentro de la red de clusters puede detener toda la operación.
Por lo tanto, es crucial que los administradores de TI conozcan todas las dificultades que pueden generarse en Kubernetes. En este artículo se abordan varios retos que los administradores de TI enfrentan con los sistemas K8s y cómo una herramienta para el monitoreo de Kubernetes los supera.
Problemas comunes con Kubernetes
1. Uso ineficiente de los recursos
La mayoría de los problemas en el sistema Kubernetes se debe a que los recursos del gestor de contenedores se configuran incorrectamente. Cuando se programa una carga de trabajo, el contenedor puede solicitar la cantidad requerida de recursos de CPU y memoria. El programador de Kubernetes asigna el nodo correcto al pod que puede asumir la tarea con base en la cantidad de recursos solicitados.
Generalmente se especifica un valor para garantizar que Kubernetes asigna suficientes recursos nodales a un pod sin exceder el límite. No obstante, la aplicación se ralentiza cuando un contenedor asigna más recursos de los disponibles. Esto deriva en un uso excesivo. Similarmente, hay una infrautilización cuando se asignan más recursos de los utilizados. Esto también ralentiza la aplicación.
También se puede establecer un límite para restringir la cantidad de recursos a los que el contenedor tiene acceso. Estas limitaciones están predeterminadas dentro del pod para garantizar que se ejecute la carga de trabajo sin demora y no se impida el progreso de los demás.
Cuando se hace una solicitud de CPU o memoria, el límite de uso se establece en un valor tal que haya suficiente espacio para soportar un uso excesivo de dichos recursos.
¿Pero qué sucedería si el pod consume más de lo que se le permite? Esto puede conllevar dos problemas importantes de Kubernetes.
Aceleración de la CPU
La aceleración de la CPU sucede cuando el uso de la CPU se acerca a su límite. Ya que este último especifica el uso máximo de la CPU disponible para el pod, la aplicación no tendrá acceso a una cantidad adecuada de los recursos que se requieren para ejecutar la carga de trabajo. Subsecuentemente, el pod podría apagarse y reiniciarse. Como un mecanismo de respuesta, la CPU se acelera para minimizar su uso. Esto puede ralentizar la aplicación.
OOMKilled
El error OOMKilled se da cuando el contenedor consume más recursos de memoria que los asignados. Ya que el uso de la memoria trata de exceder el límite de esta, el proceso asociado queda muerto por falta de memoria (OOMKilled) o terminado. El kubelet luego se reinicia y trata de asignar memoria con base en la solicitud. Si el pod se reinicia, habrá cierto retraso debido al tiempo de carga.
Frecuentemente, la aceleración de la CPU y el error OOMKilled se pueden resolver optimizando o eliminando el límite del recurso. Sin embargo, identificar estos problemas puede ser un reto enorme en una infraestructura de contenedores grandes.
Con frecuencia, esto se refleja en latencia y un retraso en el rendimiento. Debido a que hay varios elementos de Kubernetes involucrados, puede resultar difícil navegar a través de la red y limitar las anomalías.
Un software para el monitoreo de Kubernetes como ManageEngine Applications Manager recopila datos para mostrar el valor límite de la CPU y memoria para cada pod.
El monitor de esta solución también supervisa el estado del pod, la actividad de uso de CPU y memoria del cluster, y los recuentos del procesador de CPU asignable para cada nodo. Además, el monitor muestra gráficas que detallan los 5 nodos o pods principales. De esta forma, se pueden identificar fácilmente los componentes que han excedido el límite.
Al analizar colectivamente estos datos, se pueden tomar decisiones para eliminar o alterar el límite impuesto en los pods y ayudar a contrarrestar la aceleración de la CPU y el código del error OOMKilled.
2. Error CrashLoopBackOff
Cuando hay recursos insuficientes de CPU o memoria, los pods podrían apagarse sin poderse programar para un nodo. Esto provoca que el kubelet reinicie el pod defectuoso.
Este último es propenso a un nuevo fallo, así como a entrar en un bucle que activa el código de error CrashLoopBackOff. Cada vez que el contenedor se detiene para un reinicio, el tiempo de carga aumenta exponencialmente.
El código de error CrashLoopBackOff puede aparecer cuando un contenedor arranca por primera vez y entra en un bucle. Otras causas del error CrashLoopBackOff son errores de configuración, disparidad de los nombres de los recursos, bloqueo de los recursos y problemas de conectividad.
Como se mencionó antes, tener visibilidad sobre el uso de los recursos y las configuraciones de su contenedor puede ayudarle a evitar que sus pods entren en el bucle de reinicio.
El monitor de contenedores de Kubernetes en Applications Manager proporciona el estado de cada contenedor y el número de veces que se ha reiniciado en un periodo de tiempo determinado. Estos detalles se pueden analizar para ayudar a identificar un posible error CrashLoopBackOff que podría ser difícil de detectar de otra manera.
3. Error ErrImagePull
ErrImagePull es otro error que se da cuando el pod no es capaz de tomar la imagen solicitada del registro de contenedores. Luego, el pod entra en estado ErrImageBackOff. Esto ocurre cuando el nombre de la imagen del contenedor especificado en el pod del contenedor es incorrecto. Recuperar la imagen equivocada también puede conllevar una falla del pod, lo que sería fatal para las operaciones de la aplicación.
Emplear los servicios de una herramienta para el monitoreo de Kubernetes como Applications Manager ayuda a los administradores a realizar una verificación detallada de su sistema de contenedores para identificar posibles disparidades.
Puede editar la especificación del pod para proporcionar el nombre correcto y tomar manualmente la imagen. También puede ver el número total de imágenes disponibles en cada nodo dentro del dashboard de Kubernetes.
4. Interrupción de servicios
Hay varios servicios de Kubernetes responsables de facilitar la comunicación entre distintos nodos dentro de una red de clusters. Una interrupción en cualquiera de estos servicios podría impactar el intercambio de recursos entre los contenedores, ya que no se podrá acceder al nodo.
Puede haber muchas razones detrás de la interrupción de servicios y todas pueden tener un impacto enorme en la conectividad de la red.
Algunas veces, los servicios fallan en la etapa de creación y pueden ser difíciles de detectar cuando se está trabajando con un gran número de ellos. Este es otro ejemplo de cuán útil es el monitoreo de servicios de Kubernetes en Applications Manager.
Este enumera cada servicio de contenedor junto con el espacio de nombres asociado y los detalles de la aplicación. También muestra el protocolo, tipo y puerto objetivo de cada servicio.
Lo anterior puede ser útil para garantizar que sus pods están escuchando el servicio correcto. Incluso puede controlar los espacios de nombres asociados de cada servicio, ya que cualquier discrepancia puede resultar en una falla.
5. PVC no disponible para vinculaciones
Para una gestión eficiente del almacenamiento, es importante controlar el estado de disponibilidad para cada unidad de almacenamiento de volumen persistente (PV) y reclamación de volumen persistente (PVC) después de que un pod la use.
Con frecuencia, cuando se elimina un PVC, el PV podría no estar disponible después del reinicio. Esto se debe a que es posible que todavía se estén almacenando datos antiguos del pod. Al usar nuestro monitor de Kubernetes, los usuarios pueden identificar PV y PVC no disponibles para hacer las rectificaciones necesarias.
Además, nuestra herramienta también muestra la clase de almacenamiento de cada PVC. Es importante garantizar que se definan adecuadamente. Los PVC que no tengan una clase de almacenamiento definida fallarán.
Asimismo, es crucial garantizar que el PV correcto se remite a los pods. Si no hay capacidad de almacenamiento suficiente para respaldar la reclamación, esto podría resultar en una falla del PV. Al monitorear los PVC con Applications Manager, los usuarios pueden obtener un resumen general de la cantidad de almacenamiento solicitado por los PVC y comprobar si pueden acomodarse según el PV vinculado.
6. Indisponibilidad de aplicaciones
Cada nodo está confinado a una cierta cantidad de pods que pueden asignarse para el uso de recursos. Exceder este límite máximo podría hacer que el nodo sea inaccesible para otros pods. Esta interrupción de la carga de trabajo podría afectar directamente la aplicación contenedorizada.
Nuestra herramienta para el monitoreo de K8s ayuda a prevenir la indisponibilidad de las aplicaciones al desglosar el recuento máximo de pods disponibles y usados para cada nodo de Kubernetes. Los administradores pueden tomar medidas rápidas para evitar cualquier interrupción al designar que las alarmas se activen cuando el recuento de pods se acerque al límite.
Ventajas de la herramienta de monitoreo de Kubernetes en Applications Manager
- Visibilidad completa de un cluster de Kubernetes con estadísticas detalladas y estado de la actividad de nodos, pods, servicios y PV
- Salud y disponibilidad en tiempo real para distintos componentes y espacios de nombres de Kubernetes
- Gráficas visuales que ordenan distintos nodos y pods que pueden ayudar a gestionar recursos de manera eficiente
- Monitoreo sin agentes que se puede configurar en minutos
- Gestión de fallos con alertas instantáneas que se activan cuando un parámetro cruza el umbral deseado
- Informes de proyección inteligentes que pueden ayudar a predecir las tendencias de crecimiento de recursos en Kubernetes con base en datos históricos
Conclusión
Sortear los obstáculos frecuentes de Kubernetes usando una herramienta integral para el monitoreo como Applications Manager le permite obtener lo mejor de su sistema para la gestión de contenedores. Applications Manager examina su sistema Kubernetes para ayudar a descubrir cualquier problema que podría surgir.
Applications Manager también monitorea otros componentes de su infraestructura de TI. Estos incluyen servicios en la nube, bases de datos, servidores, hardware, servicios e incluso la aplicación en sí.
Con compatibilidad para más de 150 tecnologías, Applications Manager es la solución de monitoreo única para su negocio basado en aplicaciones.
Obtenga más información sobre Applications Manager con una prueba gratuita de 30 días. Puede descubrir todas las funciones del monitor de Kubernetes y entender cómo se adaptan a su organización. Asimismo, puede recibir respuestas a sus preguntas sobre el producto de nuestros expertos en soluciones programando una demostración gratuita y personalizada.
