Dimensionar recursos de Kubernetes de manera eficiente

Un Deployment con recursos ajustados a menudo no se nota en la prueba de carga, sino el lunes por la mañana después de un Release. Inversamente, las solicitudes demasiado grandes ocupan capacidad que se paga en el clúster, pero nunca se utiliza. Dimensionar eficientemente los recursos de Kubernetes, por lo tanto, no significa simplemente ingresar los valores más bajos posibles. Significa equilibrar la disponibilidad, el rendimiento y los costos de la nube basándose en datos operativos reales.

Para las empresas medianas, esta es una tarea operativa con un impacto directo en el negocio. Las cargas de trabajo dimensionadas incorrectamente prolongan los tiempos de incidentes, obstaculizan la escalabilidad y aumentan los costos de infraestructura. En cambio, las solicitudes y límites bien elegidos crean plataformas planificables, lanzamientos más rápidos y más espacio para el desarrollo de productos.

Por qué dimensionar recursos en Kubernetes es complicado

Kubernetes planifica los Pods principalmente en base a sus Resource Requests. Una solicitud de CPU de 500m no reserva un tiempo de cálculo garantizado, pero sí le indica al Scheduler la necesidad esperada. En el caso de la memoria, la situación es más estricta: si un contenedor supera su límite establecido, Kubernetes puede finalizarlo. El resultado es, a menudo, un evento OOMKilled y un reinicio justo cuando la aplicación está bajo presión.

El punto decisivo: las solicitudes y los límites no describen lo mismo. Una solicitud de CPU demasiado alta provoca que los nodos parezcan estar llenos, aunque su carga real permanezca baja. Un límite de CPU demasiado estrecho puede causar throttling. La aplicación tiene su lugar en el clúster, pero procesa las solicitudes más lentamente. En servicios que consumen mucha memoria, unos límites de memoria demasiado bajos pueden llevar a reinicios repetidos, mientras que unos valores excesivos reducen la densidad de nodos.

No existe una fórmula universal. Un servicio Java con Heap, Metaspace y bibliotecas nativas se comporta de manera diferente a un servicio Go, un backend Node.js o un Batch-Worker. Incluso un servicio API con carga uniforme necesita reservas de seguridad diferentes que un sistema de comercio electrónico con picos al comienzo de la campaña. Por lo tanto, una buena dimensionamiento comienza con el comportamiento real en tiempo de ejecución, no con valores predeterminados de un Helm-Chart.

Dimensionando eficientemente los recursos de Kubernetes: De métricas a objetivos

El primer paso es un claro inventario. No es necesario optimizar todas las aplicaciones al mismo tiempo. Tienen prioridad los servicios críticos para el negocio, cargas de trabajo con reinicios frecuentes, Pods con throttling de CPU y aplicaciones que muestran una capacidad reservada notablemente alta pero poco utilizada. Especialmente en clústeres establecidos, ahí suelen estar los mayores palancas de costos y estabilidad.

Considere las métricas durante un período de tiempo suficientemente largo. Un solo día de trabajo rara vez es representativo. Es más útil analizar varias semanas que incluyan períodos pico, lanzamientos, ciclos mensuales y procesamiento en segundo plano planificado. Son decisivos el uso de CPU, el consumo de memoria, la frecuencia de reinicios, las latencias, las tasas de errores y la cantidad de Pods en espera o no programables.

Para la solicitud de CPU, normalmente se sugiere un valor que cubra la necesidad alta típica, sin reservar completamente picos a corto plazo. Cuán cerca debe estar este valor del percentil superior depende del servicio. Para una API de checkout crítica en cuanto a latencia, es más sensato tener más reservas que para un worker de reporting asíncrono. Un límite de CPU debe establecerse de manera consciente, no reflexivamente. En muchas aplicaciones web, un límite ajustado puede causar más daño a causa del throttling que el ahorro que se obtiene.

En el caso de la memoria, el margen de seguridad es más importante. La memoria no se puede limitar como la CPU a corto plazo. La solicitud debe reflejar el nivel esperable de forma confiable, y el límite debe dejar suficiente espacio para picos realistas. En aplicaciones JVM, el Heap configurado no es suficiente como base. Los contenedores también requieren memoria adicional para Metaspace, hilos, memoria directa, cachés y el sistema operativo. Quien ignore estas partes, producirá OOMKills a pesar de tener un Heap aparentemente generoso.

Evaluar perfiles de carga en lugar de promedios

Los promedios son seductores para la planificación de capacidad y a menudo son inútiles en la realidad de producción. Un servicio con un consumo promedio de 200 MiB puede necesitar regularmente 800 MiB para ciertas solicitudes. Si su límite se ajusta al promedio, el próximo reinicio no será una sorpresa, sino un punto débil planeado.

Es mejor separar las fases de carga típicas, altas y excepcionales. Esto incluye picos estacionales, importaciones de datos, tráfico de crawlers, acciones de marketing y despliegues con el inicio paralelo de nuevos Pods. No solo se trata de la pregunta: ¿cuánto consume el contenedor en operación normal? También: ¿qué sucede bajo carga, al escalar y ante errores de sistemas dependientes?

Solicitudes, límites y autoscaling deben coincidir

El autoscaling no corrige una mala dimensión base. El Horizontal Pod Autoscaler puede escalar Pods hacia arriba cuando se alcanzan los umbrales de métricas. Sin embargo, su cálculo a menudo se basa en el uso de CPU en relación con la solicitud. Si la solicitud de CPU es demasiado alta, la carga parece artificialmente baja y la escalabilidad se activa demasiado tarde. Si es demasiado baja, el sistema podría escalar de manera innecesariamente agresiva.

Además, el número máximo de réplicas debe ajustarse a la capacidad disponible del clúster. No sirve de nada escalar un servicio hasta 50 Pods si los nodos solo pueden alojar diez Pods adicionales con las solicitudes establecidas. Entonces, los Pods permanecen en estado Pending, mientras aumentan los tiempos de respuesta. Un Cluster Autoscaler o mecanismos comparables pueden mitigar esto, pero necesitan tiempo y grupos de nodos que funcionen.

Ajustes verticales mediante un Vertical Pod Autoscaler son útiles para ciertas cargas de trabajo, como servicios internos con una demanda variable, pero no extremadamente dinámica. En entornos críticos para la producción, la introducción debe realizarse de manera controlada. Los cambios automáticos en las solicitudes pueden provocar reinicios y deben estar alineados con estrategias de despliegue, objetivos de disponibilidad y ventanas de mantenimiento.

La solución estable consta de tres niveles: Pods dimensionados de manera realista, escalamiento horizontal configurado de manera sensata y suficiente capacidad de nodo disponible. Si falta alguno de estos niveles, el problema simplemente se desplaza. Un grupo de nodos elegido demasiado grande oculta malas solicitudes de Pods, hasta que la factura de la nube se vuelve visible. Nodos demasiado ajustados hacen que incluso las aplicaciones limpias configuradas sean innecesariamente frágiles.

Los errores más comunes en la operación productiva

Un error común son los mismos valores predeterminados para todos los servicios. 500m de CPU y 512 MiB de memoria pueden ser un buen punto de partida, pero no dicen nada sobre los requerimientos reales. Se vuelve especialmente problemático cuando los equipos adoptan estos valores por presión de tiempo y luego no los revisan más.

También es crítico asumir que los límites siempre son una ganancia de seguridad. Los límites de memoria son imprescindibles para limitar cargas de trabajo individuales y proteger los nodos. Los límites de CPU, sin embargo, requieren una decisión más diferenciada. En servicios con estrictos requisitos de latencia, el throttling de CPU puede ser más costoso que la capacidad ahorrada. Aquí, los SLOs y los costos deben ser considerados conjuntamente.

Un tercer error es la optimización sin visibilidad. Quien solo ajusta archivos YAML sin seguir el consumo, el throttling, los reinicios y la latencia de la aplicación posteriormente, trabaja a ciegas. La dimensionamiento no es un proyecto de infraestructura único. Debe ser parte del modelo operativo, al igual que el monitoring, Capacity Planning y la gestión de releases.

Un proceso robusto para equipos y operación de plataforma

En la práctica, se demuestra un ciclo repetible. Primero, se priorizan las cargas de trabajo por criticidad comercial y notoriedad. Luego, se evalúan las métricas de recursos y aplicaciones, se documentan hipótesis y se implementan cambios gradualmente. Después de cada ajuste, sigue una fase de observación bajo carga real. Solo cuando la latencia, la tasa de errores, la estabilidad de Pods y la evolución de costos son adecuadas, se adoptan los valores como un nuevo estándar.

Este proceso debe estar en la línea de entrega. Las definiciones de recursos deben estar versionadas, mantenidas mediante Infrastructure as Code y tratadas en revisiones. Con los nuevos servicios, los estándares mínimos vinculantes son útiles: ningún despliegue productivo sin solicitudes, límites de memoria comprensibles y paneles que contrasten uso y reserva. Así, de acciones de optimización individuales se convierte en una práctica de plataforma gestionable.

devRocks combina este trabajo técnico con una clara visión de operación. No el número más bajo en el manifiesto es el objetivo, sino una plataforma que reacciona de manera planificable bajo carga, no desacelera los lanzamientos y cuyos costos permanecen comprensibles.

El mejor momento para el primer análisis es antes del próximo problema de escalado. Comience con las pocas cargas de trabajo que más impactan los costos, el riesgo o la experiencia del cliente, y tome decisiones operativas vinculantes basadas en las métricas.