OpenShift en Producción: Lo que nadie te cuenta sobre operación day-2

El día que el cluster se entrega, todo funciona. Los namespaces están limpios, los nodos están saludables, los dashboards muestran verde en todo. El problema empieza tres meses después.

Alguien necesita hacer un upgrade y nadie sabe cómo. Los logs se acumulan y llenan el disco. Un equipo desplegó un pod que consume toda la memoria de un nodo. Y cuando algo falla a las 2 AM, el ingeniero de guardia pasa 40 minutos buscando en qué namespace está el problema.

Por qué day-2 es más difícil que day-1

Instalar OpenShift es un problema resuelto. Red Hat tiene documentación exhaustiva, los instaladores están maduros y hay cientos de guías paso a paso. Pero operar OpenShift en producción es un problema completamente diferente.

Upgrades: el terror silencioso

Un cluster OpenShift en producción necesita actualizarse regularmente. Parches de seguridad, nuevas versiones, correcciones de bugs. El problema es que cada upgrade puede romper algo:

Operadores que no se actualizaron: Un operador custom que funcionaba en 4.14 puede fallar en 4.15.
APIs deprecadas: Kubernetes depreca APIs regularmente. Si tus manifiestos usan una API que desapareció, tus despliegues se rompen.
Incompatibilidades de storage: Cambios en CSI drivers que afectan volúmenes existentes.
Network policies que cambian de comportamiento: Actualizaciones de OVN/Calico que modifican cómo se evalúan las políticas.

La solución no es “no actualizar”. Es tener un proceso de upgrade probado:

Ambiente de staging que replica producción — no un cluster de prueba con 3 nodos y sin tráfico.
Suite de smoke tests automatizados que validan cada workload crítico después del upgrade.
Rollback plan documentado y probado — no “esperamos que no haga falta”.
Ventanas de upgrade regulares — cuanto más tiempo esperas, más doloroso es el salto.

Capacity management: entre el desperdicio y el incendio

Sin governance de recursos, los clusters OpenShift se degradan rápidamente:

Equipos que piden 4 cores y 8GB por pod pero usan 0.2 cores y 500MB.
ResourceQuotas que nadie configuró, permitiendo que un namespace consuma todo el nodo.
Pods sin limits que causan OOM kills en cascada.
PersistentVolumes que nunca se liberan después de eliminar la aplicación.

Lo que funciona:

ResourceQuotas y LimitRanges en cada namespace — no opcional, obligatorio.
Monitoring de uso real vs. requested con Kubecost o Prometheus.
Revisiones mensuales de capacidad con datos, no con intuición.
Auto-scaling configurado correctamente: HPA para pods, Cluster Autoscaler para nodos.

Observabilidad: más que Prometheus y Grafana

Tener métricas no es tener observabilidad. Observabilidad real en OpenShift requiere tres señales correlacionadas:

Métricas: CPU, memoria, I/O, latencia de red, throughput de aplicación. Prometheus + Grafana es el estándar, pero las alertas deben ser accionables — no 500 alertas que todos ignoran.

Logs: Cada pod genera logs que necesitan recolectarse, indexarse y ser buscables. El stack por defecto de OpenShift (Elasticsearch + Fluentd + Kibana) funciona, pero a escala necesita tuning agresivo.

Trazas: Para aplicaciones distribuidas, las trazas son esenciales para entender el flujo de una petición a través de múltiples servicios. Jaeger o OpenTelemetry integrados en la plataforma.

La clave es la correlación: cuando una alerta de latencia salta, el ingeniero necesita ver las métricas del pod, los logs relevantes y la traza de la petición — todo en un solo lugar, no en tres herramientas diferentes.

Seguridad continua: no es un checkbox

La seguridad en OpenShift no termina con la configuración inicial:

Escaneo de imágenes en el pipeline CI/CD antes de que lleguen al cluster.
Security Context Constraints (SCCs) que previenen pods con privilegios innecesarios.
Network policies que implementan zero-trust entre namespaces.
RBAC granular — no todos necesitan ser cluster-admin.
Audit logging que registra quién hizo qué y cuándo.

GitOps: la respuesta a “quién cambió qué”

El patrón que más impacto tiene en operación day-2 es GitOps. Con ArgoCD o Flux, toda la configuración del cluster está en Git:

Cambios auditables: Cada modificación tiene un commit con autor y motivo.
Rollback trivial: Si algo se rompe, git revert y ArgoCD reconcilia.
Drift detection: Si alguien cambia algo manualmente en el cluster, se detecta y se revierte.
Environments consistentes: Dev, staging y producción se gestionan con el mismo proceso.

Hemos visto equipos que pasan de “me da miedo tocar producción” a “desplegamos cinco veces al día” simplemente implementando GitOps correctamente.

Métricas de un cluster bien operado

¿Cómo sabes si tu operación day-2 está funcionando? Estas son las métricas que monitoreamos:

Métrica	Bueno	Problemático
Frecuencia de upgrades	Cada 2-3 meses	Más de 6 meses sin actualizar
MTTR de incidentes	< 15 minutos	> 1 hora
% de recursos utilizados vs. asignados	> 60%	< 30%
Alertas accionables vs. ruido	> 80% accionables	Más ruido que señal
Despliegues por día	5+	Ventanas semanales
Tiempo para onboarding de un nuevo equipo	< 1 día	> 1 semana

Lo que hemos aprendido operando clusters en producción

Después de operar plataformas OpenShift para operadores de telecomunicaciones y empresas enterprise, estas son las lecciones que más nos marcaron:

El cluster más seguro es el que se actualiza regularmente. Cada mes sin upgrade es deuda técnica acumulada.
Sin ResourceQuotas, el cluster es una tragedia de los comunes. Cada equipo consume lo máximo posible porque el recurso es “gratis”.
Los runbooks no sirven si están en una wiki. Codifícalos en Git, pruébalos periódicamente, ejecútalos automáticamente.
La observabilidad es una inversión, no un gasto. El costo de una hora de troubleshooting sin visibilidad supera meses de licencias de herramientas.
GitOps no es opcional para clusters enterprise. La alternativa es kubectl apply manual a las 2 AM, y eso no escala.

¿Tu cluster OpenShift necesita mejor operación day-2? Solicita una evaluación de tu plataforma y te damos un plan de mejora concreto.