Kubernetes y OpenShift se han convertido en la plataforma de referencia para desplegar aplicaciones modernas. Ofrecen escalabilidad, portabilidad y automatización, pero también introducen una complejidad nueva para los equipos de operaciones: los contenedores aparecen y desaparecen, las cargas se mueven entre nodos y un problema puede estar en cualquiera de varias capas.
Por eso la monitorización de Kubernetes no se puede abordar igual que la de un servidor tradicional. En este artículo repasamos qué capas hay que vigilar, qué métricas son imprescindibles y qué errores vemos con más frecuencia.
Por qué Kubernetes es diferente
En una infraestructura clásica, cada servidor tiene un nombre fijo y una función estable. En Kubernetes, en cambio:
- Los pods son efímeros: se crean, se destruyen y se reprograman constantemente.
- Las aplicaciones se reparten en microservicios que se comunican entre sí.
- El clúster ajusta los recursos de forma dinámica según la demanda.
- Un mismo síntoma (lentitud, errores) puede tener su origen en el nodo, en el clúster, en la red o en la propia aplicación.
Esto obliga a pasar de una monitorización basada en máquinas a una basada en servicios y capas.
Las cuatro capas que debes monitorizar
1. Infraestructura y nodos
Es la base física o virtual sobre la que corre el clúster. Hay que vigilar:
- CPU, memoria y disco de cada nodo.
- Estado de los nodos (Ready / NotReady).
- Presión de recursos (memoria, disco, número de procesos).
- Conectividad de red entre nodos.
2. Plano de control del clúster
Los componentes que gobiernan Kubernetes: API server, scheduler, controller manager y etcd. Si alguno falla, el clúster puede dejar de desplegar o reprogramar cargas aunque las aplicaciones sigan funcionando un tiempo.
3. Cargas de trabajo (pods, deployments, servicios)
Aquí se ve la salud de las aplicaciones desplegadas:
- Pods en estado de error, pendientes o en reinicio continuo (CrashLoopBackOff).
- Número de réplicas disponibles frente a las deseadas.
- Uso de CPU y memoria de cada contenedor frente a sus límites (requests y limits).
- Contenedores terminados por falta de memoria (OOMKilled).
4. Aplicaciones y experiencia de usuario
La capa más importante para el negocio. Un clúster sano no garantiza que la aplicación responda bien. Aquí entran los tiempos de respuesta, las tasas de error, las trazas entre microservicios y la experiencia real de los usuarios, que se cubren con análisis del rendimiento de las aplicaciones mediante APM, RUM y sondas sintéticas.
Métricas clave de un vistazo
| Capa | Métricas imprescindibles |
| Nodos | CPU, memoria, disco, estado Ready, presión de recursos |
| Plano de control | Disponibilidad del API server, latencia de etcd, estado del scheduler |
| Cargas de trabajo | Reinicios de pods, réplicas disponibles, uso frente a límites, OOMKilled |
| Aplicación | Tiempo de respuesta, tasa de errores, trazas, experiencia de usuario |
Errores habituales al monitorizar Kubernetes
Monitorizar solo los nodos
Es el error más común al venir de entornos tradicionales. Los nodos pueden estar perfectos mientras un deployment tiene la mitad de sus réplicas caídas.
No definir requests y limits
Sin límites de recursos bien definidos, es imposible saber si un contenedor consume más de lo previsto, y un único pod puede afectar a todo el nodo.
Alertar por cada pod que se reinicia
En Kubernetes, que un pod se reinicie puede ser normal. Alertar por cada evento genera ruido y fatiga de alertas. Lo importante es detectar patrones: reinicios continuos, réplicas insuficientes o servicios sin disponibilidad.
Tener una consola para Kubernetes y otra para el resto
Las aplicaciones en contenedores casi nunca viven aisladas: dependen de bases de datos, almacenamiento, redes o servicios cloud. Si cada entorno tiene su propia herramienta, correlacionar un problema se vuelve muy difícil.
Olvidar los logs
Las métricas indican que algo va mal; los logs explican qué. En entornos efímeros, si los logs no se centralizan, desaparecen con el pod. La consolidación de logs con Elastic resuelve este problema.
Monitorización unificada con Checkmk
Para evitar la fragmentación, en ToBeIT recomendamos herramientas capaces de monitorizar Kubernetes y OpenShift junto con el resto de la infraestructura. Checkmk, del que somos Partner Platinum en España y LATAM, permite unificar en un único panel servidores, red, entornos cloud (AWS, Azure, Google Cloud) y clústeres de contenedores. Lo contamos en detalle en Checkmk en entornos multi-cloud e híbridos.
De la monitorización a la observabilidad
En arquitecturas de microservicios, saber que algo falla no es suficiente: hay que saber por qué. Las soluciones de observabilidad de ToBeIT cubren entornos DevOps y cloud como OpenShift, Kubernetes o AKS, correlacionando métricas, logs y trazas para reducir el tiempo de resolución de incidencias.
Y antes de monitorizar: una buena containerización
Una monitorización eficaz empieza por una plataforma bien diseñada. En ToBeIT ofrecemos servicios de containerización para empresas con Kubernetes, Docker Swarm y OpenShift: implantación, gestión de clústeres y optimización adaptada a cada negocio.
Preguntas frecuentes
¿Qué diferencia hay entre monitorizar Kubernetes y OpenShift?
OpenShift está basado en Kubernetes y añade herramientas empresariales propias, por lo que las capas y métricas principales son las mismas. Lo importante es que la herramienta de monitorización soporte ambos entornos.
¿Qué es CrashLoopBackOff?
Es el estado de un pod que arranca, falla y se reinicia de forma repetida. Es una de las señales más importantes a vigilar en un clúster.
¿Necesito una herramienta específica para Kubernetes?
No necesariamente. Es preferible una herramienta que cubra Kubernetes junto con el resto de la infraestructura, para tener una visión unificada.
¿Tus contenedores están bajo control?
Si tu equipo opera Kubernetes u OpenShift y le falta visibilidad, contacta con ToBeIT. Diseñamos e implantamos la monitorización y la observabilidad de tus clústeres junto con el resto de tu infraestructura.
