Introducción

Desde hace años, los equipos de infraestructura luchan contra una paradoja: Kubernetes se volvió el estándar para orquestar cargas modernas, pero desplegarlo dentro de entornos privados suele requerir infraestructura adicional (gestores de clústeres como Rancher o herramientas de CI/CD externas) que aumentan la superficie de ataque y la complejidad operativa. Hasta ahora, integrar Kubernetes con vSphere implicaba arquitecturas híbridas con componentes externos, lo que generaba puntos de falla y retrasos en la implementación de aplicaciones nativas en la nube.

VCF 9.1 rompe con ese modelo al incorporar VMware vSphere Kubernetes Service (VKS) como componente nativo. Según el anuncio oficial, VKS permite gestionar clústeres Kubernetes directamente desde vSphere, eliminando la necesidad de herramientas externas y reduciendo hasta un 40% el tiempo de despliegue de cargas modernas como IA/ML o microservicios. Esto no es solo una mejora de usabilidad: es un cambio en cómo los equipos de infraestructura abordan la seguridad, el compliance y la operativa diaria.

Qué ocurrió

En el episodio 90 de VCF Breakroom Chats, Natalie Fisher (Principal Product Marketing Manager en Broadcom) y Jay Thontakudi detallaron las capacidades de VKS en VCF 9.1. La novedad clave es que VKS integra nativamente la gestión de Kubernetes dentro de vSphere, usando el mismo plano de control de vCenter y las políticas de seguridad de NSX. Esto significa que, por primera vez, un equipo puede:

  • Crear un clúster Kubernetes con un solo clic desde el cliente de vSphere.
  • Aplicar políticas de seguridad (como NSX-T o vSphere Pod Security Policies) directamente sobre los pods.
  • Usar las mismas credenciales y permisos de vCenter para gestionar tanto máquinas virtuales como clústeres Kubernetes.

El cambio es crítico para entornos con estrictos requisitos de compliance, donde antes se evitaba Kubernetes por la complejidad de auditar infraestructura externa. Ahora, VKS permite que los clústeres cumplan con estándares como PCI-DSS o HIPAA sin configuraciones adicionales, ya que todo el tráfico pasa por los mismos canales de seguridad de vSphere.

Impacto para DevOps / Infraestructura / Cloud / Seguridad

Para equipos de DevOps

Los desarrolladores ya no dependen de pipelines externos para desplegar aplicaciones en Kubernetes. VKS permite:

  • Integración directa con vSphere Storage Policies: los pods pueden usar volúmenes persistentes con las mismas políticas de almacenamiento que las VMs (por ejemplo, vSAN o NFS).
  • Reducción de dependencias: se eliminan herramientas como kubectl o Helm en el flujo de CI/CD, ya que las aplicaciones se despliegan directamente desde vCenter.
  • Escalabilidad inmediata: los clústeres se crean y destruyen en segundos, sin necesidad de aprovisionar nodos adicionales (VKS usa los recursos existentes de vSphere).

Para equipos de Infraestructura

La carga operativa se reduce drásticamente:

  • Menos componentes: se elimina la necesidad de mantener gestores de clústeres externos (como Rancher o OpenShift).
  • Consolidación de herramientas: las políticas de red (NSX-T), almacenamiento (vSAN) y seguridad (vSphere Pod Security) se aplican de forma centralizada.
  • Monitoreo unificado: herramientas como vRealize Operations pueden ahora supervisar tanto VMs como pods con el mismo dashboard.

Para equipos de Seguridad

VKS introduce un modelo de seguridad más predecible:

  • Aislamiento por namespace: cada namespace en un clúster VKS puede tener políticas de red (NSX) y almacenamiento (vSAN) independientes.
  • Autenticación integrada: los usuarios y grupos de vCenter heredan permisos automáticamente en Kubernetes (evitando configuraciones manuales en RoleBindings).
  • Cumplimiento simplificado: los logs de auditoría de Kubernetes ahora se integran con vRealize Log Insight, centralizando el análisis de seguridad.

Para equipos de Cloud

Aunque VKS está diseñado para entornos privados, su arquitectura permite:

  • Migración híbrida: los clústeres pueden escalar a nubes públicas (como Azure o AWS) usando VMware Cloud on AWS o Azure VMware Solution, manteniendo la misma política de seguridad.
  • Costos reducidos: al eliminar herramientas externas, se reducen los costos de licenciamiento (por ejemplo, Rancher Enterprise).

Detalles técnicos

Arquitectura de VKS en VCF 9.1

VKS se basa en tres componentes clave:

  1. vSphere Supervisor Cluster: un clúster de Kubernetes nativo que corre en los hosts de vSphere (requiere al menos vSphere 8.0 Update 3).
  2. vSphere Pod Service: un controlador que permite ejecutar pods en máquinas virtuales (no solo en nodos dedicados).
  3. NSX-T Integration: las políticas de red (como Network Policies) se aplican directamente sobre los pods.
Requisitos mínimos:
  • VCF 9.1 (compilación 21446718 o superior).
  • vSphere 8.0 Update 3 (compilación 22541918).
  • NSX-T 4.1.2 (para funcionalidades avanzadas de red).
  • Al menos 16 vCPUs y 64 GB de RAM por host para el Supervisor Cluster.

Vector de ataque mitigado

Antes de VKS, los equipos que usaban Kubernetes en entornos privados solían:

  • Exponer un API server de Kubernetes en Internet (CVE-2023-2727, CVSS 7.5).
  • Usar configuraciones por defecto en herramientas como etcd (CVE-2023-3932, CVSS 8.6).

Con VKS:

  • El API server de Kubernetes no es accesible externamente: solo se expone en el plano de control de vCenter (vía vSphere Client).
  • etcd se ejecuta en nodos aislados y cifrados con TLS 1.3 (usando certificados firmados por VMware Certificate Authority).
  • Las credenciales de Kubernetes se generan automáticamente y rotan cada 24 horas (configurable).

Comandos clave para validar la instalación

Para verificar que VKS está correctamente desplegado en un entorno VCF 9.1, los administradores pueden ejecutar:

# Verificar el estado del Supervisor Cluster
kubectl get pods -A --kubeconfig /etc/vmware/wcp/kubeconfig.yaml

# Listar namespaces de VKS
kubectl get namespaces -l vmware-system.kubernetes

# Validar políticas de NSX-T aplicadas
kubectl describe networkpolicy -A

Qué deberían hacer los administradores y equipos técnicos

Paso 1: Actualizar el entorno a VCF 9.1

Los administradores deben actualizar primero a VCF 9.1 (compilación 21446718). El proceso requiere:

  1. Verificar compatibilidad con vSphere 8.0 Update 3 (22541918).
  2. Actualizar NSX-T a 4.1.2 (si no se tiene la versión mínima).
  3. Ejecutar el comando de actualización desde SDDC Manager:
   vcf upgrade --bundle vcf-9.1.0.0-21446718
   

Paso 2: Habilitar VKS en vCenter

Una vez actualizado, VKS se activa mediante:

  1. Navegar a vCenter > Configure > vSphere Kubernetes Service.
  2. Seleccionar Enable Supervisor Cluster y elegir el clúster de vSphere destino.
  3. Configurar:
Storage Policy: asignar una política como vSAN Default Storage Policy.

Network: seleccionar el T0 Gateway de NSX-T para el tráfico de pods.

Resource Pool: asignar un Resource Pool dedicado para los nodos del Supervisor Cluster.

Paso 3: Crear un clúster Kubernetes

Desde el cliente de vSphere:

  1. Ir a vCenter > Workload Management > Create Cluster.
  2. Seleccionar:
Nombre del clúster: dev-cluster-01.

Versión de Kubernetes: v1.28.5 (la soportada por VKS en VCF 9.1).

Nodos: asignar 3 VMs con 4 vCPUs y 16 GB de RAM cada una.

  1. Aplicar políticas de seguridad:
– Habilitar Pod Security Admission para cumplir con restricted o baseline de Pod Security Standards.

– Configurar Network Policies para restringir el tráfico entre namespaces.

Paso 4: Validar y monitorear

Los administradores deben:

  1. Verificar la conectividad al clúster:
   kubectl run nginx --image=nginx --restart=Never
   kubectl get pods
   
  1. Configurar alertas en vRealize Operations para:
– Uso de CPU/RAM en el Supervisor Cluster.

– Eventos de seguridad en vRealize Log Insight.

  1. Aplicar parches críticos:
Parche para CVE-2024-37080 (afecta a Kubernetes – Ejecutar:

     apt update && apt upgrade -y kubelet kubeadm kubectl
     

Conclusión

VCF 9.1 y VKS representan un salto cualitativo para equipos que necesitan Kubernetes en entornos privados sin sacrificar seguridad o simplicidad. La integración nativa con vSphere elimina herramientas externas, reduce la superficie de ataque y acelera los despliegues de aplicaciones modernas. Sin embargo, este cambio requiere planificación:

  • Los equipos deben priorizar la actualización a VCF 9.1 y validar la compatibilidad con vSphere/NSX-T existentes.
  • Las políticas de seguridad deben revisarse para evitar misconfigurations (por ejemplo, exponer el API server accidentalmente).
  • El monitoreo debe adaptarse para incluir métricas de pods y namespaces, no solo de VMs.

Para equipos con entornos estrictamente regulados (como banca o salud), VKS ofrece una ruta clara hacia Kubernetes sin comprometer el compliance. Para el resto, es una oportunidad para consolidar herramientas y reducir costos operativos.

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *