Google Cloud anunció el 25 de septiembre que los clústeres Google Kubernetes Engine Standard ya admiten hasta 512 pods por nodo, el doble del límite anterior de 256. Los nodos configurados para alojar entre 257 y 512 pods reciben un bloque CIDR de pods /22, equivalente a 1.024 direcciones IP, según las notas oficiales de GKE.
El límite pasa de 256 a 512 pods
La ampliación afecta a GKE Standard, donde las empresas mantienen un mayor control sobre la configuración de los nodos. Un límite superior permite concentrar más cargas pequeñas en cada máquina cuando la arquitectura y los recursos disponibles lo permiten.
Eso no significa que cualquier clúster deba duplicar automáticamente su densidad. CPU, memoria, tráfico de red, límites del sistema operativo y comportamiento de las aplicaciones siguen determinando cuántos pods puede soportar un nodo de forma segura.
Los nodos más densos usan un CIDR /22
Google indica que los nodos configurados para 257 a 512 pods reciben un bloque /22 para las direcciones de pods, con 1.024 IP disponibles. Este detalle es relevante para empresas que diseñan rangos secundarios de VPC o que ya tienen redes con espacio IP ajustado.
Antes de aumentar la densidad, un equipo debería comprobar que su planificación de direcciones admite el nuevo tamaño por nodo y que no crea conflictos con otros rangos del entorno.
Qué puede ganar una pyme tecnológica
En cargas formadas por muchos servicios pequeños, jobs o componentes auxiliares, una mayor densidad puede reducir el número de nodos necesarios. El efecto real sobre costes depende del tamaño de las máquinas, la reserva de recursos, el autoscaling y la utilización efectiva.
También puede simplificar ciertos clústeres al evitar crear nodos adicionales solo por alcanzar el límite numérico de pods, aunque siga existiendo capacidad de CPU o memoria.
Qué revisar antes de cambiar la configuración
Las empresas deberían medir consumo real por pod, picos de CPU y memoria, tráfico este-oeste y presión sobre almacenamiento. También conviene validar políticas de red, DaemonSets y componentes que se ejecutan en cada nodo, porque todos ellos consumen recursos aunque el límite teórico permita más pods.
En entornos productivos, el cambio debería probarse primero en un node pool controlado. Una mayor densidad aumenta además el impacto potencial de la caída de un nodo, por lo que disponibilidad y distribución de réplicas siguen siendo factores esenciales.
Para equipos que operan infraestructura y software, también son relevantes el parche crítico de GitLab, los fallos de StockAgile, la remediación de Cloudflare CASB, el nuevo Microsoft Defender, las capacidades agénticas de Workspace y la adopción de passkeys.
Fotografía: Brett Sayles / Pexels.
