Kubernetes en Producción: Gestión y Monitoreo

Introducción: La Madurez de un Clúster Kubernetes en Producción

Llevar una aplicación a producción sobre Kubernetes no es un paseo por el parque. Muchos equipos se estrellan contra la realidad cuando su clúster de desarrollo, que funcionaba de maravilla, empieza a mostrar problemas de latencia, fugas de memoria o caídas inesperadas bajo carga real. La gestión y el monitoreo de Kubernetes en producción dejan de ser una opción para convertirse en una necesidad crítica.

Este artículo está diseñado para SysAdmins y DevOps que ya tienen un clúster en pie y necesitan madurarlo. Abordaremos las mejores prácticas de gestión de recursos, estrategias de escalabilidad y, sobre todo, cómo construir un stack de monitoreo que te permita dormir tranquilo. Olvídate de los dashboards bonitos sin contexto; aquí hablamos de alertas útiles y métricas accionables.

Gestión de Recursos: El Corazón de la Estabilidad

Un clúster de producción no perdona la falta de planificación. Si no gestionas correctamente los recursos de CPU y memoria, tus aplicaciones se comportarán como niños en una tienda de golosinas: consumirán todo lo que encuentren y dejarán a otros sin nada.

Requests y Limits: La Línea de Base

La primera regla de la gestión en producción es nunca desplegar un Pod sin definir requests y limits. Los requests garantizan que el Pod tenga los recursos mínimos que necesita, mientras que los limits evitan que un Pod acapare todo el nodo.

resources:
  requests:
    memory: "256Mi"
    cpu: "250m"
  limits:
    memory: "512Mi"
    cpu: "500m"

[WARNING] No establezcas limits iguales a requests sin pensar. Si pones límites muy ajustados, el Pod será killado por OOM (Out Of Memory) ante cualquier pico. Deja un margen de seguridad del 20-30% entre ambos valores.

Quality of Service (QoS) Classes

Kubernetes asigna una clase QoS a cada Pod según la configuración de recursos. Entenderlas es clave para predecir el comportamiento del clúster bajo presión:

• Guaranteed: Todos los contenedores tienen requests y limits iguales para CPU y memoria. Son los Pods más privilegiados.
• Burstable: Al menos un contenedor tiene requests menores que limits. Es el caso más común en producción.
• BestEffort: Sin requests ni limits. Son los primeros en ser sacrificados cuando el nodo se queda sin recursos.

Recomendación: Para cargas de trabajo críticas (bases de datos, balanceadores), usa siempre Guaranteed. Para microservicios stateless, Burstable es suficiente y más eficiente.

Escalabilidad: Más Allá del HPA

La escalabilidad en Kubernetes no se limita a añadir réplicas. Un clúster de producción debe escalar de forma inteligente, tanto horizontal (Pods) como vertical (nodos).

Horizontal Pod Autoscaler (HPA) con Métricas Personalizadas

El HPA básico con CPU/memoria está bien para empezar, pero en producción necesitas métricas más relevantes, como la longitud de la cola de mensajes o el tiempo de respuesta de una API.

# Ejemplo de HPA con métricas personalizadas usando Prometheus Adapter
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: api-gateway-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: api-gateway
  minReplicas: 3
  maxReplicas: 20
  metrics:
  - type: Pods
    pods:
      metric:
        name: http_requests_per_second
      target:
        type: AverageValue
        averageValue: 100

[TIP] Configura un cooldown (periodo de enfriamiento) en el HPA para evitar el "flapping" (escalar y desescalar constantemente). En Kubernetes, esto se controla con los flags --horizontal-pod-autoscaler-downscale-stabilization y --horizontal-pod-autoscaler-upscale-delay.

Cluster Autoscaler: El Salvavidas del Nodo

El Cluster Autoscaler (CA) es el encargado de añadir o eliminar nodos del clúster cuando los Pods no pueden ser programados por falta de recursos. En un entorno cloud (AWS, GCP, Azure), se integra con los Auto Scaling Groups.

Configuración clave:

• Define grupos de nodos con diferentes tipos de instancia (spot para cargas elásticas, on-demand para cargas críticas).
• Ajusta el scale-down-delay-after-add para evitar eliminar nodos recién creados.
• Usa skip-nodes-with-local-storage si tienes volúmenes efímeros.

Monitoreo: De Datos a Decisiones

El monitoreo en producción no es solo tener un dashboard bonito. Es tener la capacidad de detectar anomalías antes de que afecten a los usuarios, entender la causa raíz y actuar rápido. El stack estándar hoy es Prometheus + Grafana + Alertmanager, pero vamos a ver cómo configurarlo para que sea realmente útil.

Métricas Esenciales para un Clúster en Producción

No monitorices todo; monitoriza lo que importa. Aquí tienes una lista de métricas críticas agrupadas por capa:

Nivel de Nodo

• CPU y memoria utilizada vs. capacidad total.
• Presión de disco (especialmente en nodos con etcd o bases de datos).
• Número de Pods fallidos o en estado CrashLoopBackOff.

Nivel de Pod

• Tasa de reinicios (restart_count).
• Latencia de solicitudes (percentiles p50, p95, p99).
• Errores HTTP (5xx, 4xx).
• Uso de memoria vs. límite (para detectar OOM inminente).

Nivel de Servicio (SLOs)

• Disponibilidad: ¿qué porcentaje de solicitudes se completan correctamente?
• Latencia: ¿cuánto tarda en responder el sistema?
• Throughput: ¿cuántas solicitudes puede manejar por segundo?

# Ejemplo de regla de alerta en Prometheus
- alert: HighMemoryUsage
  expr: (sum(container_memory_working_set_bytes{container!=""}) by (pod) / sum(container_spec_memory_limit_bytes{container!=""}) by (pod)) > 0.9
  for: 5m
  labels:
    severity: critical
  annotations:
    summary: "Pod {{ $labels.pod }} usando más del 90% de memoria"

Logging Centralizado: La Otra Cara del Monitoreo

El monitoreo de métricas es reactivo; los logs son la lupa forense. En producción, necesitas una solución de logging centralizado que agregue logs de todos los contenedores, nodos y componentes del plano de control.

Stack recomendado: Fluentd o Loki para recolección, Elasticsearch o Loki para almacenamiento, y Kibana o Grafana para visualización.

[INFO] Si usas managed Kubernetes (EKS, GKE, AKS), suele venir con integración nativa para logs (CloudWatch, Stackdriver, Azure Monitor). Aprovecha esas integraciones antes de montar tu propio stack.

Prácticas Avanzadas de Gestión

Namespaces y Cuotas de Recursos

En un clúster compartido por múltiples equipos, los namespaces son tu mejor aliado para el aislamiento. Pero no basta con crearlos; debes asignar cuotas de recursos para evitar que un equipo acapare todo.

apiVersion: v1
kind: ResourceQuota
metadata:
  name: team-a-quota
  namespace: team-a
spec:
  hard:
    requests.cpu: "4"
    requests.memory: "8Gi"
    limits.cpu: "8"
    limits.memory: "16Gi"
    persistentvolumeclaims: "5"
    pods: "20"

Políticas de Red y Seguridad

El monitoreo también incluye la seguridad. Usa Network Policies para restringir el tráfico entre Pods y Pod Security Standards (PSS) para evitar que los contenedores se ejecuten con privilegios excesivos.

# Ejemplo de Network Policy que solo permite tráfico desde el namespace de monitoreo
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-monitoring
spec:
  podSelector:
    matchLabels:
      app: my-app
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          name: monitoring
    ports:
    - port: 8080

Estrategias de Actualización y Mantenimiento

Un clúster en producción no puede estar desactualizado. Las actualizaciones de Kubernetes traen parches de seguridad, mejoras de rendimiento y nuevas funcionalidades. Sin embargo, actualizar un clúster de producción es un arte.

Estrategia de Actualización de Nodos

• Rolling update: Actualiza nodos de uno en uno, drenando los Pods antes de la actualización. Es la más segura.
• Blue/Green: Mantén dos conjuntos de nodos (versión antigua y nueva) y cambia el tráfico gradualmente.
• Canary: Actualiza un pequeño subconjunto de nodos primero y monitorea el impacto.

[WARNING] Siempre prueba las actualizaciones en un clúster staging idéntico al de producción. No confíes en que el proceso funcionará igual en entornos cloud vs. on-premise.

Backup y Disaster Recovery

El monitoreo no sirve de nada si no tienes un plan de recuperación. Asegúrate de hacer backups regulares de:

• etcd: El cerebro del clúster. Sin un backup de etcd, no puedes restaurar el estado del clúster.
• Persistent Volumes: Datos de aplicaciones stateful (bases de datos, colas).
• Manifiestos: Guarda todos los YAMLs en un repositorio Git (GitOps).

# Backup de etcd (ejemplo para clúster self-managed)
ETCDCTL_API=3 etcdctl snapshot save /backup/etcd-snapshot-$(date +%Y%m%d%H%M%S).db \
  --endpoints=https://127.0.0.1:2379 \
  --cacert=/etc/kubernetes/pki/etcd/ca.crt \
  --cert=/etc/kubernetes/pki/etcd/server.crt \
  --key=/etc/kubernetes/pki/etcd/server.key

Herramientas Recomendadas para el Día 2

Aquí tienes un listado de herramientas que todo equipo de producción debería considerar:

• Prometheus Operator: Para gestionar el stack de monitoreo como código.
• Grafana Loki: Para logging ligero y nativo de Kubernetes.
• Kiali: Para visualizar la topología de servicios en un Service Mesh (Istio).
• K9s: Terminal UI para gestionar el clúster desde la línea de comandos.
• Velero: Para backup y restore de clústeres y volúmenes persistentes.

Conclusión: El Monitoreo es un Proceso, no un Producto

Gestionar Kubernetes en producción es un viaje continuo. No existe una configuración mágica que resuelva todos los problemas. Lo que funciona hoy puede no funcionar mañana cuando el tráfico se duplique o cuando despliegues una nueva versión con un comportamiento diferente.

La clave está en construir una cultura de observabilidad: donde cada miembro del equipo sepa interpretar las métricas, donde las alertas sean accionables y donde el monitoreo no sea un añadido, sino una parte integral del ciclo de vida de la aplicación.

Empieza con lo básico: requests, limits, HPA basado en métricas reales y un stack de monitoreo simple pero efectivo. Luego, itera. Añade dashboards, ajusta alertas, automatiza respuestas. Y recuerda: un clúster que no se monitorea es un clúster que está a punto de fallar.

[TIP] No caigas en la trampa de "monitorear por monitorear". Cada métrica que añadas debe responder a una pregunta concreta: ¿esto me ayuda a detectar un problema antes de que ocurra? Si la respuesta es no, sácala.