Solución de Problemas Avanzada: Inmersión Profunda en Registros, Eventos y Métricas de Kubernetes

La solución de problemas en Kubernetes se vuelve más fácil cuando separas tres preguntas: ¿qué dijo el contenedor?, ¿qué hizo el plano de control? y ¿qué muestran las métricas? Los registros, eventos y métricas responden a diferentes partes del mismo incidente.

Los ejemplos a continuación muestran cómo usar los tres juntos cuando un pod falla, una imagen no se descarga, una carga de trabajo no se programa o un servicio parece saludable pero responde lentamente.

Registros de Kubernetes: La Base de la Depuración

Los registros son los registros detallados de lo que una aplicación o proceso del sistema está haciendo. En Kubernetes, los registros son generados por los contenedores que se ejecutan dentro de tus pods. A menudo son el primer lugar donde mirar cuando una aplicación no se comporta como se espera.

Accediendo a los Registros de Contenedores

El comando kubectl logs es tu herramienta principal para recuperar registros de los pods. Es versátil y ofrece varias opciones útiles.

Obtener registros de un solo contenedor en un pod:
```
kubectl logs <nombre-del-pod>
```
Si un pod tiene solo un contenedor, este comando funciona directamente.
Obtener registros de un contenedor específico en un pod con múltiples contenedores:
```
kubectl logs <nombre-del-pod> -c <nombre-del-contenedor>
```
Ver registros de una instancia anterior de un contenedor que falló: Si un contenedor se ha reiniciado debido a un error, puedes ver sus registros antes del reinicio usando la bandera --previous:
```
kubectl logs <nombre-del-pod> --previous
```
Seguir registros en tiempo real: Similar a tail -f, la bandera -f (o --follow) te permite transmitir nuevas entradas de registro a medida que se generan, lo cual es invaluable para depurar problemas en vivo.
```
kubectl logs -f <nombre-del-pod> -c <nombre-del-contenedor>
```
Filtrar registros por tiempo: Puedes especificar cuántas líneas desde el final recuperar (--tail) o registros de una duración específica (--since).
```
kubectl logs <nombre-del-pod> --tail=100 # Últimas 100 líneas
kubectl logs <nombre-del-pod> --since=1h # Registros de la última hora
```

Soluciones de Registro Centralizado

Si bien kubectl logs es excelente para la depuración inmediata, no es práctico para la gestión de registros a gran escala y a largo plazo. Para entornos de producción, las soluciones de registro centralizado son esenciales. Estas soluciones típicamente implican:

Agentes de Registro: Ejecutar un agente (por ejemplo, Fluentd, Fluent Bit, Filebeat) en cada nodo para recopilar registros de todos los pods.
Almacenamiento e Indexación de Registros: Almacenar registros en un repositorio central (por ejemplo, Elasticsearch, Loki, Splunk).
Visualización y Análisis de Registros: Proporcionar una interfaz para buscar, filtrar y visualizar registros (por ejemplo, Kibana, Grafana, Splunk UI).

Mejores Prácticas para el Registro

Registro Estructurado: Emitir registros en un formato estructurado (por ejemplo, JSON) para que sean fácilmente analizables y consultables por sistemas de registro centralizado.
Niveles de Registro Apropiados: Usar diferentes niveles de registro (DEBUG, INFO, WARN, ERROR, FATAL) para categorizar mensajes y controlar la verbosidad.
Evitar Información Sensible: No registrar datos sensibles (contraseñas, PII) directamente.

Eventos de Kubernetes: El Narrador del Clúster

Los eventos de Kubernetes son registros de cambios de estado y operaciones que ocurren dentro del clúster. Proporcionan información crucial sobre lo que Kubernetes mismo está haciendo (o fallando en hacer) en respuesta a tu estado deseado. Los eventos son invaluables para entender por qué los pods no se programan, las imágenes no se descargan o los volúmenes no se montan.

Accediendo a los Eventos de Kubernetes

Eventos a nivel de clúster:

kubectl get events

Este comando muestra todos los eventos recientes en el espacio de nombres actual. Puedes agregar --all-namespaces para ver eventos en todo el clúster.

Una salida de evento típica se ve así:

ÚLTIMA VEZ   TIPO      RAZÓN      OBJETO                         MENSAJE
3m21s        Normal    Scheduled   pod/my-app-789c6f66-abcde      Asignado exitosamente default/my-app-789c6f66-abcde a node01
3m20s        Normal    Pulling     pod/my-app-789c6f66-abcde      Descargando imagen "example/my-app:1.2.3"
2m58s        Warning   BackOff     pod/my-app-789c6f66-abcde      Retroceso reiniciando contenedor fallido app

Eventos para un solo objeto:
```
kubectl describe pod <nombre-del-pod>
```
La sección Eventos al final es a menudo la forma más rápida de ver problemas de programación, descarga, montaje y reinicio para un solo pod.

Ordenar eventos por tiempo de creación:

kubectl get events --sort-by=.metadata.creationTimestamp

Lo que los Eventos Generalmente Te Dicen

Los eventos son registros de corta duración, por lo que son mejores para fallos recientes. Busca estas razones comunes:

FailedScheduling: El programador no pudo colocar el pod. Verifica selectores de nodo, taints, tolerations, solicitudes de recursos y capacidad disponible.
ImagePullBackOff o ErrImagePull: Kubernetes no pudo descargar la imagen. Verifica el nombre de la imagen, la etiqueta, el acceso al registro y el secreto de descarga de imagen.
FailedMount: Un volumen no pudo montarse. Verifica el enlace de PVC, la clase de almacenamiento, los permisos del nodo y el estado del controlador CSI.
BackOff: Un contenedor sigue fallando. Combina el evento con kubectl logs --previous.

Métricas de Kubernetes: La Vista de Recursos

Las métricas te indican si el clúster tiene suficiente CPU, memoria y capacidad para la carga de trabajo. También te ayudan a separar los errores de aplicación de la presión de recursos.

Verificaciones Rápidas con metrics-server

Si metrics-server está instalado, usa kubectl top:

kubectl top nodes
kubectl top pods
kubectl top pod <nombre-del-pod> --containers

Una alta memoria de pod cerca del límite del contenedor a menudo coincide con reinicios de OOMKilled. Una alta CPU de nodo puede explicar la latencia incluso cuando los registros del pod se ven limpios.

Métricas Más Profundas con Prometheus

En producción, Prometheus y Grafana generalmente proporcionan la vista histórica de la que carece kubectl top. Las señales útiles incluyen:

Reinicios de contenedores a lo largo del tiempo.
Limitación de CPU para contenedores con límites bajos de CPU.
Conjunto de trabajo de memoria en comparación con los límites.
Pods pendientes por espacio de nombres.
Latencia de solicitudes del servidor API y tasa de error.
Presión de disco del nodo, presión de memoria y saturación de red.

Correlacionando Registros, Eventos y Métricas

Usa una ventana de tiempo y muévete del síntoma a la causa:

Verifica el estado del pod:

kubectl get pod <nombre-del-pod> -o wide
kubectl describe pod <nombre-del-pod>

Lee los registros actuales y anteriores:

kubectl logs <nombre-del-pod> -c <nombre-del-contenedor>
kubectl logs <nombre-del-pod> -c <nombre-del-contenedor> --previous

Verifica los eventos recientes del espacio de nombres:

kubectl get events --sort-by=.metadata.creationTimestamp

Compara el uso de recursos:

kubectl top pod <nombre-del-pod> --containers
kubectl top node

Por ejemplo, un pod con CrashLoopBackOff, registros anteriores que terminan en un error de falta de memoria, y métricas que muestran memoria cerca del límite apunta a un problema de límite de memoria o de memoria de la aplicación. Un pod atascado en Pending con eventos FailedScheduling y baja capacidad de nodo apunta a presión de programación, no a un error del contenedor.

Conclusión

No depures Kubernetes desde una sola señal. Los registros explican el comportamiento de la aplicación, los eventos explican las decisiones del plano de control y las métricas explican la presión de recursos. Cuando los alineas por tiempo y nombre de objeto, las causas raíz se vuelven mucho más fáciles de separar de los síntomas.