Nutanix NKP 2.19 trae Kubernetes 1.36.2 y nuevos requisitos de upgrade
NKP 2.19 ya está disponible con Kubernetes 1.36.2 por defecto, despliegue bare metal y gestión de VMs AHV. Antes de actualizar clústeres 2.18 hay que revisar proyectos de Prism Central, tokens de Docker Hub y la migración de catálogos.
Nutanix declaró disponible de forma general NKP 2.19, una actualización de Nutanix Kubernetes Platform que amplía los entornos donde puede operar el clúster y cambia varios pasos de actualización. La página de producto está fechada el 20 de octubre y el blog corporativo confirmó la disponibilidad general el 22; no es una preview. La versión instala Kubernetes 1.36.2 por defecto y mantiene soporte para la familia 1.35.x.
Bare metal, VMs y un flujo de upgrade distinto
La novedad de infraestructura más visible es NKP Metal, que permite desplegar y gestionar Kubernetes directamente sobre servidores físicos. Nutanix describe un flujo que usa Foundation Central y el inventario de hosts de NKP para preparar imágenes de sistema, registrar máquinas y formar clústeres bare metal; también se pueden añadir pools de trabajadores físicos a clústeres virtualizados. Eso amplía las opciones de cómputo, pero no convierte cualquier servidor en un nodo soportado: la matriz de compatibilidad y los requisitos de hardware siguen mandando.
-InfraCrew dice: el bare metal elimina una capa de virtualización; no elimina la lista de modelos, firmware y redes que hay que validar antes.-
NKP 2.19 incorpora además VM Operator para AHV, que permite gestionar operaciones compatibles del ciclo de vida de máquinas Linux y Windows mediante APIs de Kubernetes. La idea es que el equipo administre VMs y contenedores desde un modelo declarativo común, no que las VMs pasen a ser pods ni que desaparezcan las diferencias de almacenamiento, red y soporte entre ambos. Es un encaje para equipos que ya operan AHV y Kubernetes; la cobertura real depende de las funciones que ofrezca el operador en esta versión.
También cambia el camino de actualización de clústeres ClusterClass. Para clústeres de carga de trabajo basados en ClusterClass, incluidos Nutanix y EKS, ahora se puede iniciar el upgrade por clúster desde la interfaz o con un comando de CLI. El flujo actualiza primero las aplicaciones de plataforma y después Kubernetes, la infraestructura del clúster y sus complementos. En los clústeres que no usan ClusterClass aparece nkp upgrade platform-apps, pero el clúster de gestión debe pasar primero a 2.19.
Los requisitos previos no son cosméticos
El cambio que más puede frenar un upgrade de 2.18 es usar un único proyecto de Prism Central para los nodos de control y de trabajo. Si el clúster cruza varios proyectos, Nutanix indica que hay que consolidarlos antes de actualizar. Un clúster que hoy está saludable no garantiza que el nuevo flujo acepte la misma distribución: esta condición merece validación antes de abrir la ventana de mantenimiento.
-InfraCrew dice: un preflight que descubre la topología en mitad de la ventana no es un preflight; es una sorpresa con calendario.-
Hay otros ajustes con efecto directo en automatización. Los clústeres de gestión que aún no tengan token de Docker Hub deben aportarlo durante el upgrade; los catálogos basados en GitRepository dejan de admitirse y sus recursos AppDeployment deben migrarse a OCIRepository. También desaparece el argumento --kommander-applications-repository de nkp install kommander y nkp upgrade kommander. Si los pipelines lo envían hoy, fallarán hasta que se retire ese argumento.
La actualización reemplaza Kubernetes Dashboard por Headlamp, aunque las instancias existentes de Dashboard siguen funcionando después del upgrade y Nutanix aconseja migrarlas. La plataforma también advierte que ciertas configuraciones de Nutanix AI con instancia única pueden impedir drenar nodos de trabajo. Es un límite especialmente relevante en ventanas que combinen upgrade de clúster y cargas aceleradas: prueba el drenado con la configuración concreta antes de programar un cambio simultáneo.
Qué comprobar antes de mover producción
Nutanix lista Kubernetes 1.36.2 como instalación predeterminada, además de la rama soportada 1.35.x. Su compatibilidad publicada incluye Rocky Linux y Red Hat Enterprise Linux 9.8, Prism Central pc.7.5/pc.7.6, AOS 7.5/7.6, NDK 2.3 y Nutanix Enterprise AI 2.8.0/2.8.1. Las capacidades del catálogo de IA dependen también de la licencia Pro o Ultimate; la asignación dinámica de GPU cubre NVIDIA y AMD, pero no particionado NVIDIA Multi-Instance GPU.
Para un equipo de plataforma, el plan sensato es inventariar clústeres ClusterClass y no ClusterClass, comprobar el proyecto de cada nodo, validar el token de registro y migrar los catálogos antes de la ventana. Después conviene probar el orden de upgrades, el drenado de trabajadores con AI y los pipelines que todavía llamen a flags retirados. La promesa práctica de 2.19 es un modelo operativo más amplio; obtenerla sin interrupciones depende de preparar las incompatibilidades que acompañan al cambio.
-InfraCrew dice: si el pipeline conserva un flag retirado, no es compatibilidad hacia atrás; es una nota de migración que alguien tiene que leer.-
Diccionario de la Crew
Disponibilidad general (GA) — Estado en que una versión se ofrece como lanzamiento de producción y no como preview.
NKP Metal — Opción de NKP para desplegar Kubernetes directamente sobre servidores físicos.
VM Operator — Operador que gestiona operaciones compatibles de máquinas virtuales mediante APIs de Kubernetes.
ClusterClass — Plantilla declarativa de Cluster API que define la configuración de un tipo de clúster.
OCIRepository — Recurso de catálogo que apunta a paquetes almacenados como artefactos OCI.
