Kubernetes en producción: lo que de verdad importa

Kubernetes es una de las tecnologías que más ha transformado la forma en que las empresas despliegan y gestionan aplicaciones en los últimos años. Pero hay una brecha enorme entre saber lo suficiente de Kubernetes para superar un tutorial introductorio y tener un clúster estable, seguro y eficiente en producción. Esa brecha la pagan las empresas en forma de incidentes, horas de operación no planificadas y facturas de cloud inesperadamente altas.

Este artículo no es una introducción a Kubernetes. Si necesitas entender qué es un Pod, un Deployment o un Service, hay centenares de recursos excelentes para eso. Lo que encontrarás aquí es una guía de las decisiones, configuraciones y prácticas que realmente marcan la diferencia cuando Kubernetes se usa para ejecutar aplicaciones críticas de negocio.

Hablaremos de gestión de recursos, alta disponibilidad, seguridad, redes, almacenamiento, monitorización, gestión del ciclo de vida del clúster y los errores más frecuentes que cometen equipos con experiencia en Kubernetes. El objetivo es que quien gestione un clúster de producción salga de aquí con una lista clara de cosas que revisar o implementar.

La primera regla: define y asigna recursos a todos tus workloads

Uno de los errores más comunes y costosos en Kubernetes es desplegar contenedores sin definir requests y limits de CPU y memoria. Los requests son la cantidad de recursos que Kubernetes garantiza para el contenedor y usa para tomar decisiones de scheduling. Los limits son el máximo que el contenedor puede consumir. Sin estos valores definidos, el scheduler de Kubernetes toma decisiones de colocación arbitrarias, los nodos se pueden saturar de forma impredecible y, en el peor de los casos, el kubelet empieza a expulsar pods (eviction) en momentos de alta carga.

La práctica correcta es definir siempre requests y limits para todos los contenedores. Para establecer valores correctos, hay que observar el comportamiento real de la aplicación en condiciones de carga representativas usando las métricas de Vertical Pod Autoscaler (VPA) en modo recomendación, que analiza el consumo histórico y sugiere valores óptimos sin alterar los deployments.

Quality of Service y sus implicaciones en producción

Kubernetes clasifica los pods en tres clases de QoS según la configuración de recursos: Guaranteed (requests == limits en todos los contenedores), Burstable (requests < limits) y BestEffort (sin requests ni limits). Los pods BestEffort son los primeros en ser expulsados cuando el nodo tiene presión de memoria. Los pods Guaranteed son los últimos. Para aplicaciones críticas de negocio, lo recomendable es la clase Guaranteed, aunque implica una utilización de recursos algo menor.

Alta disponibilidad: más allá de las réplicas

Aumentar el número de réplicas de un Deployment es el primer paso hacia la alta disponibilidad, pero no es suficiente. Si todas las réplicas de un servicio crítico acaban en el mismo nodo por una mala distribución del scheduler, la pérdida de ese nodo derriba el servicio completo. Hay dos mecanismos en Kubernetes para controlar la distribución de pods: Pod Affinity/Anti-Affinity y Topology Spread Constraints.

• Pod Anti-Affinity con regla preferredDuringSchedulingIgnoredDuringExecution: instruye al scheduler a evitar colocar dos réplicas del mismo deployment en el mismo nodo, sin hacer esto un requisito estricto que pueda impedir el scheduling.
• Topology Spread Constraints: mecanismo más moderno y flexible que permite distribuir pods de forma equilibrada entre nodos, zonas de disponibilidad o cualquier otra topología definida mediante etiquetas. Es el enfoque recomendado para clústeres modernos.
• Pod Disruption Budgets (PDB): definen el número mínimo de réplicas disponibles durante operaciones de mantenimiento voluntarias. Sin PDBs, un drenado de nodo puede dejar un servicio sin réplicas si el autoscaler no ha reaccionado a tiempo.
• Readiness y Liveness Probes correctamente configuradas: el readiness probe determina cuándo un pod está listo para recibir tráfico. El liveness probe detecta si el proceso principal ha quedado bloqueado. Configurarlos con valores incorrectos de initialDelaySeconds o timeoutSeconds es una de las causas más frecuentes de disponibilidad degradada.

Seguridad en Kubernetes: la superficie de ataque que no se puede ignorar

Kubernetes tiene una superficie de ataque significativa si no se configura con cuidado. Los recursos de seguridad nativos de Kubernetes, complementados con herramientas del ecosistema, permiten construir un clúster robusto, pero requieren configuración activa.

RBAC: el control de acceso de Kubernetes

Role-Based Access Control (RBAC) es el sistema de autorización de Kubernetes. Define quién puede hacer qué sobre qué recursos del clúster. El principio de mínimo privilegio se aplica igual que en IAM de cloud: los usuarios, service accounts y pipelines de CI/CD deben tener únicamente los permisos que necesitan. Evita usar el ClusterRole cluster-admin para usuarios o service accounts de aplicaciones. Limita los permisos a los namespaces donde cada entidad necesita operar.

Pod Security Standards

Pod Security Standards (PSS) reemplazó a Pod Security Policy en Kubernetes 1.25. Define tres niveles de restricción: Privileged (sin restricciones), Baseline (restricciones mínimas razonables) y Restricted (el más seguro, alineado con las mejores prácticas). Aplicar el nivel Restricted en namespaces de producción elimina la posibilidad de ejecutar contenedores como root, montar volúmenes de sistema del host, o usar hostNetwork y hostPID.

• Configura securityContext en todos los pods: runAsNonRoot: true, readOnlyRootFilesystem: true, allowPrivilegeEscalation: false.
• Usa Network Policies para restringir el tráfico entre pods. Por defecto, Kubernetes permite comunicación entre todos los pods del clúster. Una política deny-all como base y reglas de allow explícitas es el enfoque más seguro.
• Escanea las imágenes de contenedores antes de desplegarlas. Herramientas como Trivy, Grype o los servicios integrados en ECR, GCR o ACR identifican vulnerabilidades en los paquetes del sistema.
• Implementa un Admission Controller como Open Policy Agent (OPA) con Gatekeeper o Kyverno para aplicar políticas de seguridad y cumplimiento a nivel de clúster.
• Usa Secrets de Kubernetes solo para datos de pequeño tamaño y baja sensibilidad. Para secretos corporativos críticos, usa integraciones con HashiCorp Vault, AWS Secrets Manager o Azure Key Vault mediante el CSI Secrets Store Driver.
• Audita regularmente las imágenes en producción con herramientas de análisis de configuración como Polaris o Kubescape.

Gestión de redes: Ingress, Service Mesh y CNI

La capa de red de Kubernetes es una de las más complejas y la que más impacto tiene en el rendimiento y la seguridad del clúster. La elección del plugin CNI (Container Network Interface), el controlador de Ingress y la decisión de implementar o no un service mesh son decisiones arquitectónicas con consecuencias a largo plazo.

En cuanto al CNI, los más usados en producción son Calico (ofrece las Network Policies más completas, con capacidades de cortafuegos de capa 3), Cilium (basado en eBPF, proporciona visibilidad de red muy avanzada y políticas de capa 7) y Flannel (simple y ligero, pero sin soporte para Network Policies). Para entornos con requisitos de seguridad o de observabilidad de red avanzados, Cilium es la opción más recomendable actualmente.

Para la capa de Ingress, los controladores más populares son ingress-nginx, AWS Load Balancer Controller, Traefik y Kong Ingress Controller. La elección depende del proveedor cloud, los requisitos de autenticación (algunas empresas necesitan integración OIDC a nivel de Ingress) y las capacidades de rate limiting y WAF necesarias. Para entornos muy exigentes, considerar Envoy Gateway (la implementación de referencia del estándar Kubernetes Gateway API) es una apuesta de futuro.

Service Mesh: cuándo vale la pena Istio o Linkerd

Un service mesh añade una capa de infraestructura que gestiona la comunicación entre microservicios: TLS mutuo entre servicios, observabilidad de tráfico a nivel de servicio, circuit breaking, retries configurables y traffic splitting para canary deployments. Istio y Linkerd son los dos service meshes más adoptados en producción.

La pregunta clave es: ¿realmente necesito un service mesh? La respuesta es no para la mayoría de las aplicaciones monolíticas o de pocas decenas de microservicios. Los service meshes añaden complejidad operativa significativa (gestión del plano de control, inyección de sidecars, depuración más compleja) que solo está justificada cuando la aplicación tiene docenas o cientos de microservicios con requisitos de seguridad de tráfico entre servicios, observabilidad muy granular o patrones de tráfico avanzados como traffic splitting para A/B testing.

Kubernetes resuelve problemas complejos de forma elegante, pero también puede crear problemas complejos nuevos si se adopta sin la preparación operativa adecuada.

Almacenamiento persistente: el talón de Aquiles de Kubernetes

Kubernetes fue diseñado originalmente para cargas de trabajo stateless. El almacenamiento persistente (StatefulSets, PersistentVolumes) es más complejo de gestionar que los deployments stateless y tiene implicaciones en la disponibilidad, el rendimiento y el coste. Antes de desplegar bases de datos o sistemas de almacenamiento en Kubernetes, vale la pena evaluar si los servicios gestionados del proveedor cloud (RDS, Cloud SQL, Aurora, etc.) son más adecuados.

Si la decisión es usar almacenamiento persistente en Kubernetes, el Container Storage Interface (CSI) es el estándar para integrar sistemas de almacenamiento externos. Los proveedores cloud ofrecen drivers CSI para sus sistemas de almacenamiento nativos. Para almacenamiento distribuido gestionado dentro del propio clúster, Rook-Ceph y Longhorn son las opciones más maduras. Longhorn, de Rancher, tiene una curva de aprendizaje menor y es más adecuado para empresas que empiezan con almacenamiento persistente en Kubernetes.

Autoscaling: tres dimensiones que hay que conocer

Kubernetes ofrece tres mecanismos de autoscaling que operan en dimensiones diferentes y que, bien configurados juntos, permiten gestionar la variabilidad de carga de forma eficiente y económica.

• Horizontal Pod Autoscaler (HPA): escala el número de réplicas de un Deployment o StatefulSet basándose en métricas como el uso de CPU, el uso de memoria o métricas personalizadas (RPS, longitud de cola) mediante la Custom Metrics API. Es el mecanismo de autoscaling más usado.
• Vertical Pod Autoscaler (VPA): ajusta los requests y limits de CPU y memoria de los pods basándose en el consumo histórico. En modo recomendación, sugiere valores sin modificar los pods en ejecución. En modo automático, puede actualizar los pods reiniciándolos con la nueva configuración.
• Cluster Autoscaler (CA) o Karpenter: gestiona el escalado de nodos del clúster. Cuando el scheduler no puede colocar pods por falta de capacidad, el CA añade nodos. Cuando hay nodos infrautilizados, los drena y elimina. Karpenter, desarrollado por AWS y ahora open source, es más rápido y flexible que el CA tradicional, con capacidad de seleccionar el tipo de instancia óptimo para cada workload.

Observabilidad: métricas, logs y trazas distribuidas

Operar Kubernetes en producción sin observabilidad completa es como conducir por la autopista con los ojos cerrados. El stack de observabilidad estándar para Kubernetes se basa en tres pilares: métricas con Prometheus y Grafana, logs con el stack ELK (Elasticsearch, Logstash, Kibana) o Loki, y trazas distribuidas con Jaeger u OpenTelemetry.

Prometheus recopila métricas de todos los componentes de Kubernetes (kube-state-metrics, node-exporter, cAdvisor) y de las aplicaciones que exponen un endpoint /metrics. Grafana visualiza estas métricas en dashboards. El proyecto kube-prometheus-stack (antes prometheus-operator) despliega todo el stack con buenas configuraciones por defecto mediante Helm, y es el punto de partida recomendable para la mayoría de las empresas.

Para logs, Grafana Loki se ha convertido en una alternativa popular al stack ELK gracias a su modelo de almacenamiento más económico (indexa solo las etiquetas, no el contenido de los logs) y su integración nativa con Grafana. Fluent Bit es el agente de logs más ligero y eficiente para recopilar logs de los pods y enviarlos a Loki, Elasticsearch o cualquier sistema de log management.

Gestión del ciclo de vida del clúster: upgrades y mantenimiento

Kubernetes publica nuevas versiones menores aproximadamente cada cuatro meses, y cada versión tiene soporte durante aproximadamente catorce meses. Esto significa que las empresas deben actualizar su versión de Kubernetes al menos una o dos veces al año para mantenerse dentro del soporte. Gestionar estos upgrades en producción sin incidentes requiere planificación y automatización.

Los servicios de Kubernetes gestionado (EKS, GKE, AKS) simplifican significativamente los upgrades. GKE ofrece actualizaciones automáticas configurables con ventanas de mantenimiento. EKS y AKS permiten actualizar los grupos de nodos de forma gradual (rolling update) o crear grupos de nodos nuevos con la versión actualizada y migrar las cargas de trabajo. La estrategia de blue/green a nivel de grupo de nodos, creando nodos nuevos con la versión actualizada y migrando los pods antes de eliminar los nodos antiguos, es la más segura para aplicaciones críticas.

GitOps: el modelo de operación más robusto para Kubernetes

GitOps es un paradigma operativo donde el estado deseado de la infraestructura y las aplicaciones se define en archivos de código (YAML de Kubernetes, charts de Helm, manifiestos de Kustomize) almacenados en un repositorio Git. Un operador de GitOps (Flux o Argo CD) reconcilia continuamente el estado del clúster con el estado definido en Git.

Las ventajas de GitOps son múltiples: el historial de Git proporciona una auditoría completa de todos los cambios en el clúster, con quién hizo el cambio, cuándo y por qué. El rollback es tan sencillo como revertir un commit. La recuperación ante desastres se reduce a restaurar el clúster y dejar que el operador de GitOps reconcilie el estado desde Git. Argo CD es actualmente el operador de GitOps más adoptado en el mercado, con una interfaz web que facilita la visualización del estado de los despliegues.

Errores más comunes en Kubernetes de producción

• No definir requests y limits: el error más frecuente y con más impacto en la estabilidad.
• Usar latest como tag de imagen: impide la reproducibilidad y hace imposible saber qué versión exacta está en producción.
• No configurar readiness y liveness probes: Kubernetes no sabe cuándo un pod está realmente listo o cuándo está bloqueado.
• Ignorar los Pod Disruption Budgets: los nodos se drenan durante los upgrades y dejan servicios sin réplicas disponibles.
• Usar Secrets de Kubernetes para credenciales críticas sin integraciones con gestores de secretos externos.
• No tener Network Policies: cualquier pod comprometido puede comunicarse con cualquier otro pod del clúster.
• Ejecutar contenedores como root cuando no es necesario.
• No monitorizar los eventos de eviction y OOMKill: son síntomas de problemas de resources que se ignoran hasta que causan un incidente mayor.
• No probar los procedimientos de disaster recovery: asumir que las copias de seguridad funcionan sin verificarlo periódicamente.

Conclusión: Kubernetes robusto se construye con disciplina

Kubernetes es una plataforma extraordinariamente poderosa que puede simplificar la operación de aplicaciones complejas, pero solo si se usa con disciplina y conocimiento. Los equipos que tienen más éxito con Kubernetes en producción no son necesariamente los que conocen más características de Kubernetes, sino los que tienen procesos bien definidos para la gestión de recursos, la seguridad, las actualizaciones y la respuesta ante incidentes.

Si estás empezando a usar Kubernetes en producción, comienza por lo fundamental: define recursos en todos tus pods, implementa readiness y liveness probes, configura Pod Disruption Budgets, activa RBAC con el principio de mínimo privilegio, despliega Prometheus y Grafana para observabilidad, y establece un proceso de actualización regular del clúster. Con esa base, el resto de las mejoras se pueden ir añadiendo de forma gradual y controlada.