Cada platform engineer con el que hablé el último año tiene alguna versión de la misma hoja de cálculo. Filas para node groups, columnas para familias de instancias, una pestaña para prod, otra para staging y una celda de comentario con esperanza que dice "revisar el próximo trimestre". Suele ser precisa durante unas seis horas. Después, un deploy trae nuevas pod requests, Karpenter levanta una familia c7i en lugar de una m6i, se recupera un nodo Spot y la hoja se convierte silenciosamente en ficción. No es un problema de disciplina. Es un problema de números. La topología de nodos en Kubernetes cambia más rápido de lo que cualquier persona puede rastrear, y la planificación estática nunca iba a seguirle el ritmo a los autoscalers, al churn de Spot y a los deploys diarios. La respuesta real no es una hoja de cálculo mejor ni un dashboard más bonito. Es un rightsizing continuo y automatizado que trata las pod requests y la topología de nodos como un único loop conectado, corriendo sin esperar a que alguien actualice una celda.
¿Por qué falla el seguimiento manual de node pools en Kubernetes?
El seguimiento manual de node pools falla porque las pod requests, el comportamiento del autoscaler y las interrupciones de Spot cambian más rápido de lo que se puede actualizar cualquier hoja de cálculo. Hay tres fuerzas que vuelven imposibles los cálculos.
Primero, las pod requests se desvían. Los equipos hacen deploys varias veces al día. Cada rollout puede cambiar las requests de CPU y memoria, a veces de forma deliberada y otras por accidente, cuando se actualiza una imagen base. Tu hoja asumía que un pod necesitaba 500m de CPU. El release de ayer lo subió a 750m. Nadie le avisó a la hoja.
Segundo, los autoscalers remodelan el cluster en tiempo real. Karpenter y Cluster Autoscaler eligen tipos de instancia según los pods pendientes en ese momento, las restricciones de bin-packing y la disponibilidad. Un plan que dice "corremos 12 nodos m6i.2xlarge" es una foto de un instante. Una hora después podrías tener 8 c7i.xlarge y 4 r7i.large, y ambas configuraciones son correctas para el workload que existía en ese instante.
Tercero, las interrupciones de Spot rompen supuestos cada semana. AWS recupera un nodo, Karpenter sustituye por una familia de instancia distinta y la topología sobre la que planificaste ya no existe. Si tu modelo de costos depende de "estamos al 70% en Spot en esta familia", estás adivinando.
La FinOps Foundation lo dice de forma explícita: la planificación ágil e iterativa se prefiere sobre la planificación estática de largo plazo en una porción creciente del estate tecnológico. La topología de nodos cae justo en esa porción creciente.
¿Cuál es la diferencia entre rightsizing de nodos y rightsizing de pods?
El rightsizing de nodos elige las familias y tamaños de instancia adecuados para tu cluster. El rightsizing de pods define las requests correctas de CPU y memoria para cada workload. Suelen tratarse como problemas separados, y por eso justamente los dos suelen quedar mal resueltos.
Las pod requests moldean la elección del nodo
Si tus pod requests están infladas, el scheduler necesita nodos más grandes para acomodarlas. Terminas pagando por un margen que ningún workload va a usar. Ajusta las requests al uso real y, de repente, los mismos workloads caben en nodos más chicos y baratos. El node pool no tenía que cambiar. Los pods sí.
La elección del nodo moldea el rendimiento del pod
Corre un servicio Java memory-bound en una familia de instancia compute-optimized y vas a pelear con OOMKills sin importar con cuánto cuidado ajustes el heap de la JVM. Elige una instancia basada en ARM sin revisar tus imágenes de contenedor y la mitad de tus pods no va a schedulear. La familia de nodo es una decisión de rendimiento, no solo de costos.
Un loop, no dos
Ninguno de los dos problemas se resuelve de forma aislada. PerfectScale analiza el comportamiento del workload y la topología de nodos en conjunto, y aplica los cambios sin reiniciar pods. Esa última parte importa. El Vertical Pod Autoscaler reinicia pods para cambiar las requests, algo aceptable para workloads stateless pero doloroso en el resto de los casos. El rightsizing continuo que no requiere reinicios cierra el loop que los dashboards y las revisiones manuales dejan abierto.
Para profundizar en cómo la elección de familia de instancia impacta a workloads reales, nuestro artículo sobre estrategias de selección de nodepool repasa los tradeoffs.
¿Cómo planifican los platform engineers los node pools de Kubernetes sin hojas de cálculo?
Los platform engineers planifican los node pools de Kubernetes automatizando el loop de análisis y dejando la responsabilidad en manos de los Engineers que operan los workloads. Es un cambio: pasar de la propiedad centralizada en una hoja de cálculo a la toma de decisiones descentralizada, lo que refleja el principio de FinOps de que la responsabilidad sobre el uso y el costo debe empujarse al borde.
Algunas acciones prácticas hacen que esto funcione:
- Instrumenta primero, decide después. Necesitas datos de uso a nivel de pod, utilización de nodos e historial de topología en un solo lugar. Si tus datos viven en tres herramientas, volviste a las hojas de cálculo con otro nombre.
- Vincula las recomendaciones a responsables. Una recomendación sin nombre asignado se convierte en tarea de nadie. Los equipos de plataforma que exponen las sugerencias de rightsizing por workload a los equipos de dev que los operan logran una adopción más rápida.
- Automatiza lo que es seguro. El rightsizing de workloads estables y bien entendidos no necesita a un humano en el loop. Reserva la revisión humana para los workloads con SLAs ajustados o patrones inusuales.
- Respeta las restricciones de SLA. El rightsizing basado en ML que solo mira promedios va a subaprovisionar tu p99. Busca análisis que modelen el comportamiento del workload a lo largo del tiempo, no solo fotos puntuales.
Paramount Pictures redujo sus problemas de resiliencia en un 90% tras adoptar PerfectScale, en gran parte al eliminar las tareas manuales que solían consumir el tiempo del equipo de platform engineering. Ese es el resultado práctico de pasar de una planificación basada en hojas de cálculo a un loop continuo.
Para los equipos que aún están agarrando el músculo, nuestra guía definitiva para mantener livianos los clusters de Kubernetes cubre los hábitos operativos que hacen que esto funcione.
¿Cómo se compara la optimización continua con los dashboards y VPA?
Los dashboards te muestran lo que pasó. El Vertical Pod Autoscaler cambia las pod requests, pero reinicia los pods para hacerlo. La optimización continua hace el análisis y aplica los cambios sin reinicios, y eso la ubica en otra categoría de herramienta.
Esta es la diferencia práctica. Un dashboard te dice que el node group X está al 40% de utilización. Genial. Ahora alguien tiene que decidir qué hacer al respecto, coordinar con el equipo que opera los workloads, agendar una ventana de cambio y actualizar la hoja de cálculo. Eso es toil, y escala de forma lineal con la cantidad de workloads que corres.
VPA resuelve parte de esto ajustando las pod requests de forma automática, pero no sabe nada de la topología de nodos y reinicia los pods para aplicar los cambios. Para un servicio stateful o un batch job de larga duración, ese costo de reinicio es real.
PerfectScale corre de forma continua sobre EKS, GKE, AKS y clusters autogestionados, sin cambios en helm charts ni modificaciones de código. Del setup a la primera recomendación pasan menos de 5 minutos. El análisis considera el comportamiento del pod, la topología de nodos y las restricciones de SLA en conjunto, y los cambios se aplican sin reinicios de pods. En más de 500 clusters productivos, los equipos ven cerca de un 40% de reducción de costos y un 60% menos de incidentes relacionados con recursos.
Ese es el cambio: de "aquí tienes un dashboard, buena suerte" a "el loop está corriendo, revisa los cambios".
Frequently asked
questions
¿Qué es una estrategia de node pools en Kubernetes?
Una estrategia de node pools en Kubernetes define sobre qué tipos de instancia, tamaños y restricciones de topología corren tus workloads, y cómo esas decisiones se ajustan a medida que cambian las pod requests. Cubre la selección de familia de instancia, la mezcla entre Spot y on-demand, y cómo deben comportarse los autoscalers bajo carga.
¿Por qué falla el rightsizing manual de nodos en Kubernetes?
El rightsizing manual de nodos falla porque las pod requests cambian con cada deployment, los autoscalers remodelan el cluster de forma continua y las interrupciones de Spot intercambian familias de instancia sin previo aviso. Cualquier plan estático se vuelve inexacto pocas horas después de haberse escrito.
¿En qué se diferencia el rightsizing de nodos del rightsizing de pods?
El rightsizing de nodos selecciona los tipos y tamaños de instancia para el cluster, mientras que el rightsizing de pods define las requests de CPU y memoria para cada workload. Son el mismo problema de optimización visto desde dos caras, y resolverlos por separado deja pérdida o riesgo de rendimiento sobre la mesa.
¿Se puede automatizar la selección de node pools en Kubernetes de forma segura?
Sí, si la automatización analiza el comportamiento del workload, la topología de nodos y las restricciones de SLA en conjunto, y aplica los cambios sin reiniciar pods. Las herramientas que solo ajustan pod requests o solo recomiendan tipos de nodo se pierden la mitad del problema.
¿En cuánto tiempo se ven resultados del rightsizing automatizado?
PerfectScale entrega sus primeras recomendaciones a los 5 minutos de la instalación. Las mejoras significativas de costo y confiabilidad suelen aparecer en las primeras semanas, a medida que el sistema construye un modelo de comportamiento de cada workload.
Las hojas de cálculo no son una estrategia de node pools. Son una foto de un instante en un cluster que nunca deja de moverse. Un rightsizing continuo y automatizado que trate las pod requests y la topología de nodos como un solo loop es el único enfoque que le sigue el ritmo al comportamiento real de Kubernetes. Los Engineers que operan los workloads deberían ser dueños de las decisiones, respaldados por datos que estén realmente al día.