Mapa de lecturaDe la señal a una decisión operativa
  1. 01Entender
  2. 02Priorizar
  3. 03Actuar

Kubernetes automatiza despliegues y recuperación, pero también multiplica componentes efímeros, etiquetas y relaciones. Un pod que desaparece puede llevarse la evidencia del problema; un clúster “verde” puede alojar una aplicación lenta. Por eso la observabilidad Kubernetes debe conectar plataforma y experiencia, no limitarse a contar pods.

Las cinco capas que hay que observar

1. Experiencia del usuario

Disponibilidad, errores y latencia de las transacciones críticas. Es la capa que determina impacto. Puede medirse con RUM, sintéticos y métricas de aplicación.

2. Aplicaciones y servicios

Tasa, errores, duración, dependencias y trazas. Debe incluir versión desplegada, namespace, servicio y propietario.

3. Workloads

Deployments, StatefulSets, DaemonSets, Jobs y Pods. Importan reinicios, estados pendientes, errores de imagen, probes y límites.

4. Nodos y recursos

CPU, memoria, disco, red, presión, capacidad asignable y saturación. Debe distinguir uso real de requests y limits configurados.

5. Control plane

API server, scheduler, controllers y etcd. Su degradación puede afectar cambios, escalado y recuperación aunque las aplicaciones continúen respondiendo por un tiempo.

Métricas: empezar por síntomas

Las métricas de Kubernetes se exponen desde componentes, kubelet y herramientas como kube-state-metrics. El riesgo es convertir cada métrica en una alerta.

Priorizá:

  • Latencia y errores de servicios críticos.
  • Pods no disponibles respecto del estado deseado.
  • Reinicios persistentes y CrashLoopBackOff.
  • Workloads pendientes por falta de recursos o restricciones.
  • Saturación y presión de nodos.
  • Errores y latencia del API server.
  • Salud de etcd y latencia de almacenamiento.
  • Pérdida o demora del pipeline de telemetría.

Una alerta debe señalar impacto o riesgo próximo y tener responsable. El resto puede quedar disponible para diagnóstico.

Logs: la evidencia desaparece con el pod

Los contenedores escriben normalmente a stdout y stderr; el runtime y kubelet administran archivos en el nodo. Kubernetes no ofrece un almacenamiento central duradero. Se necesita un agente o collector que reenvíe los logs antes de que roten o desaparezca el nodo.

Buenas prácticas:

  • Logs estructurados en JSON.
  • Timestamp y severidad consistentes.
  • service.name, entorno, versión, namespace y pod.
  • trace_id y span_id para correlación.
  • Redacción de secretos y datos personales.
  • Límites de volumen y retención por categoría.

No uses nombres de pod como identidad principal: cambian. La identidad debe representar el servicio y la versión.

Trazas: seguir una solicitud entre pods

Las trazas distribuidas muestran cómo una solicitud atraviesa ingress, servicios, colas y bases de datos. OpenTelemetry puede instrumentar aplicaciones y enviar OTLP a un Collector desplegado en el clúster.

Una traza útil permite responder:

  • ¿Dónde se agregó latencia?
  • ¿Qué dependencia falló?
  • ¿La falla afecta una versión o zona?
  • ¿Hay reintentos que amplifican carga?
  • ¿Qué logs corresponden a la transacción?

Sin propagación de contexto, cada microservicio aparece como una isla.

Arquitectura de recolección

Un patrón común combina:

  • DaemonSet para telemetría por nodo, logs y métricas locales.
  • Gateway Collector para procesamiento, muestreo y exportación.
  • Prometheus para scraping de métricas.
  • Backend de logs y trazas, gestionado o autogestionado.

El diseño debe contemplar picos, backpressure, reintentos, memoria y comportamiento cuando el backend no está disponible. La observabilidad no debe tumbar la aplicación que intenta observar.

Cardinalidad: el costo oculto de las etiquetas

Kubernetes agrega dimensiones útiles —cluster, namespace, pod, container—, pero combinarlas con IDs únicos puede multiplicar series. Controlá especialmente:

  • UID de pod y container.
  • Rutas HTTP sin parametrizar.
  • IDs de usuario, request o sesión.
  • Labels creados dinámicamente.
  • Histograms con demasiados buckets.

Conservá detalle en logs o trazas cuando no sea necesario como etiqueta métrica.

Dashboard mínimo de Kubernetes

Un dashboard operativo debería mostrar:

  1. SLO y señales RED de aplicaciones críticas.
  2. Estado deseado vs disponible de workloads.
  3. Pods pendientes, fallidos y reinicios.
  4. Capacidad y presión por nodo y namespace.
  5. Errores y latencia del control plane.
  6. Cambios y despliegues recientes.
  7. Salud y pérdida del pipeline de telemetría.

Separá la vista ejecutiva de la vista de plataforma. Un gerente necesita impacto y tendencia; un SRE necesita detalle para actuar.

Multi-cluster: conservar contexto sin multiplicar tableros

Cuando existen varios clústeres, copiar el mismo dashboard para cada uno dificulta comparar y agrega mantenimiento. Normalizá atributos como organización, cuenta, región, clúster, entorno y equipo. Luego permití filtrar desde una vista global hacia el detalle.

No centralices todo sin evaluar conectividad y aislamiento. Un pipeline regional puede reducir transferencia y mantener operación cuando falla el enlace central. Para servicios regulados, la residencia de logs y trazas puede exigir backends o retenciones diferentes.

Medí además la salud por clúster del Collector, retrasos de exportación y volumen descartado. Si una región deja de enviar telemetría, una vista global podría interpretar ausencia de datos como ausencia de incidentes.

Errores frecuentes

  • Alertar por cada reinicio sin considerar el estado final.
  • Observar nodos pero no transacciones.
  • Conservar logs sin límites.
  • Usar dashboards importados sin adaptarlos a SLOs.
  • No etiquetar responsables.
  • Ignorar el costo de cardinalidad.
  • No probar qué ocurre cuando falla el Collector.

Antes de ampliar el stack, ejecutá una prueba: eliminá un pod, saturá una dependencia en un entorno controlado y simulá indisponibilidad del backend. El equipo debería identificar impacto, servicio y causa sin depender del nombre del pod que ya desapareció. Registrá tiempo, pasos y telemetría faltante; esa evidencia define la siguiente mejora mucho mejor que instalar otro dashboard.

Próximo paso

CTL integra Kubernetes con Prometheus, Grafana y OpenTelemetry. Agendá una evaluación para revisar cobertura, alertas y costo.

Preguntas frecuentes

¿Qué diferencia hay entre metrics-server y Prometheus?

Metrics Server entrega métricas de recursos para funciones como autoscaling y kubectl top; no está pensado como solución histórica completa. Prometheus recolecta y almacena series para análisis y alertas.

¿Conviene un Collector por clúster?

Depende del volumen, aislamiento y disponibilidad. Un gateway por clúster simplifica contexto y fallas, mientras gateways regionales pueden centralizar procesamiento. La arquitectura debe probarse bajo carga.

¿Cómo se observa un pod que ya desapareció?

La telemetría debe exportarse fuera del nodo y asociarse a identidades estables. Los eventos de Kubernetes, logs centralizados y trazas conservan evidencia después de terminar el pod.

Fuentes verificables