VKS 3.8 acerca Kubernetes 1.37 al ciclo de vSphere
Broadcom describe VKS 3.8 para Kubernetes en VMware Cloud Foundation: soporte a la rama 1.37, upgrades encadenados y nuevos controles de placement. Varias capacidades promocionadas en la misma entrada siguen marcadas como futuras.
VMware Cloud Foundation describió el 2 de noviembre VKS 3.8, una nueva versión de vSphere Kubernetes Service para operar clústeres sobre la nube privada de VMware. La novedad de plataforma más concreta es soporte para Kubernetes 1.37, además de mejoras de upgrade y colocación de cargas. Conviene separar la descripción del fabricante de una matriz de compatibilidad: el anuncio cuenta qué incorpora la versión, pero no reemplaza la comprobación del punto de partida de cada entorno.
La pieza central es el upgrade encadenado entre versiones de VKS. Broadcom dice que el flujo incorpora comprobaciones de dependencias y señala APIs deprecadas; durante el recorrido, los nodos de trabajo se cordonan y drenan una sola vez en lugar de repetir ese paso por cada versión intermedia. Eso puede reducir trabajo manual y tiempo de mantenimiento, pero no convierte un upgrade en operación sin impacto: el comportamiento de las aplicaciones, las políticas de disponibilidad y la ruta soportada siguen condicionando la ventana.
-InfraCrew dice: automatizar los saltos intermedios quita scripts de la mesa; no quita la responsabilidad de probarlos.-
Lo que cambia para el equipo de plataforma
La rama 1.37 ya forma parte de las tres ramas que Kubernetes mantiene activas, junto a 1.36 y 1.35. El proyecto Kubernetes lista 1.37.1 como la versión de parche más reciente, publicada el 15 de septiembre, y marca su fin de vida para octubre de 2027. Broadcom afirma que VKS separa su cadencia de la plataforma core y que pretende entregar soporte a una versión upstream dentro de 60 días; esa es la política anunciada por el proveedor, no una garantía de que cualquier combinación de vSphere y clúster se pueda actualizar directamente.
En entornos VCF 9.1, la publicación describe políticas más granulares para colocar node pools en sitios concretos de un clúster extendido y reservar hosts con GPU para cargas que sí las necesiten. La separación puede ayudar a equilibrar resiliencia y coste: que el plano de control compita con un entrenamiento por aceleradores caros suele ser una discusión fácil de evitar con reglas de placement. La referencia a VCF 9.1 importa: no hay que extender esa capacidad a todas las instalaciones de VKS por el mero hecho de compartir nombre de producto.
VKS 3.8 también integra External Secrets Operator para sincronizar credenciales con vaults empresariales, Tekton para pipelines dentro del clúster y ArgoCD para entrega continua. El fabricante añade políticas de admisión con OPA Gatekeeper, deshabilita SSH en nodos de control y trabajo, y describe verificaciones de integridad con AIDE. Son cambios de operación además de funciones: si el equipo aún depende de modificar hosts por SSH, debe validar su procedimiento de soporte antes de adoptar una configuración endurecida.
-InfraCrew dice: si el camino normal de mantenimiento era “entrar al nodo y tocarlo”, una versión que apaga SSH pide revisar el runbook antes del cambio, no después.-
El pie de página que cambia el alcance
No todas las capacidades de la entrada están disponibles hoy. Broadcom marca con nota de futura entrega el Quick Start, la asignación dinámica de GPU mediante DRA y la observabilidad con OpenTelemetry. No las cuentes como funciones listas para producción ni como motivo para actualizar hasta que el proveedor las incorpore y publique las condiciones correspondientes.
-InfraCrew dice: una capacidad marcada como futura no aparece en la ventana del martes por ósmosis.-
La matriz de compatibilidad sigue siendo el paso previo al cambio: confirma que el despliegue ejecuta Supervisor y la versión de VMware Cloud Foundation admitida; luego compara origen y destino en las release notes de VKS. La página upstream ayuda a entender el ciclo de Kubernetes, pero no responde qué APIs, CNI, CSI o add-ons están certificados en una versión concreta de la distribución. Esa parte le corresponde a la matriz del producto.
El valor operativo está en recortar tareas manuales y controlar placement para equipos que hoy mantienen upgrades multi-salto o necesitan separar cargas de control y aplicación en infraestructura compartida. La decisión no debería descansar en las promesas de velocidad del anuncio: las mejoras concretas son la automatización de dependencias, una sola pasada de drenaje en la cadena y nuevas políticas de colocación; la compatibilidad exacta y las piezas futuras todavía requieren validación.
Diccionario de la Crew
VKS — vSphere Kubernetes Service, distribución y plano de operación de clústeres Kubernetes integrado con vSphere.
cordonar y drenar — Marcar un nodo para que no reciba nuevas cargas y evacuar sus pods antes de mantenimiento.
VCF — VMware Cloud Foundation, plataforma de infraestructura privada que integra vSphere y servicios relacionados.
External Secrets Operator — Complemento de Kubernetes que sincroniza secretos desde gestores externos hacia recursos del clúster.
OPA Gatekeeper — Controlador que aplica políticas de admisión a recursos que se intentan crear en Kubernetes.
AIDE — Herramienta de comprobación de integridad de archivos y directorios.
CNI — Interfaz que integra plugins de red con la configuración de red de Kubernetes.
CSI — Interfaz estándar para integrar sistemas de almacenamiento con Kubernetes.
API — Interfaz que permite consultar o modificar funciones de un servicio.
Fuentes
VMware Cloud Foundation Blog — VKS 3.8 | https://blogs.vmware.com/cloud-foundation/2026/11/02/vks-3-8-advancing-ai-modern-workloads-private-cloud/
Kubernetes — Releases | https://kubernetes.io/releases/
