Revise los requisitos del sistema para configurar vSphere with Tanzu en un clúster de vSphere mediante el uso de la pilas de redes de NSX-T Data Center.

Límites de configuración de clústeres de vSphere with Tanzu

VMware proporciona límites de configuración en la herramienta Valores máximos de configuración de VMware.

Para los límites de configuración específicos de vSphere with Tanzu, incluidos los clústeres supervisor y los clústeres de Tanzu Kubernetes, seleccione vSphere > vSphere 7.0 > vSphere with Kubernetes > VMware Tanzu Kubernetes Grid Service for vSphere y haga clic en Ver límites o bien siga este vínculo.

Requisitos para un clúster de dominio de carga de trabajo, Edge y administración

vSphere with Tanzu se puede implementar con funciones de administración de cargas de trabajo, Edge y administración combinada en un único clúster de vSphere.
Tabla 1. Requisitos informáticos mínimos para el clúster de administración de cargas de trabajo, Edge y administración
Sistema Tamaño de implementación mínimo CPU Memoria Almacenamiento
vCenter Server 7.0 Pequeño 2 16 GB 290 GB
Hosts ESXi 7.0 3 hosts ESXi con 1 dirección IP estática por host.

Si utiliza vSAN: 3 hosts ESXi con al menos 2 NIC físicas por host es el valor mínimo. Sin embargo, se recomienda utilizar 4 hosts ESXi por resistencia durante la aplicación de revisiones y la actualización.

Los hosts deben unirse a un clúster con vSphere DRS y HA habilitados. vSphere DRS debe estar en el modo Totalmente automatizado o Parcialmente automatizado.

Precaución: No deshabilite vSphere DRS después de configurar el clúster supervisor. Tener DRS habilitado en todo momento es un requisito previo obligatorio para ejecutar cargas de trabajo en el clúster supervisor. Si se deshabilita DRS, se interrumpirán los clústeres de Tanzu Kubernetes.
8 64 GB por host No aplicable
NSX Manager Mediano 6 24 GB 300 GB
NSX Edge 1 Grande 8 32 GB 200 GB
NSX Edge 2 Grande 8 32 GB 200 GB
Máquinas virtuales de plano de control de Kubernetes 3 4 16 GB 16 GB

Topología con clúster de administración y Edge y clúster de administración de cargas de trabajo independientes

vSphere with Tanzu se puede implementar en dos clústeres, uno para las funciones de Edge y de administración, y otro dedicado a la administración de cargas de trabajo.

Tabla 2. Requisitos informáticos mínimos para el clúster de Edge y administración
Sistema Tamaño de implementación mínimo CPU Memoria Almacenamiento
vCenter Server 7.0 Pequeño 2 16 GB 290 GB
Hosts ESXi 7.0 2 hosts ESXi 8 64 GB por host No aplicable
NSX Manager Mediano 6 24 GB 300 GB
NSX Edge 1 Grande 8 32 GB 200 GB
NSX Edge 2 Grande 8 32 GB 200 GB
Tabla 3. Requisitos informáticos mínimos para el clúster de administración de cargas de trabajo
Sistema Tamaño de implementación mínimo CPU Memoria Almacenamiento
Hosts ESXi 7.0 3 hosts ESXi con 1 dirección IP estática por host.

Si utiliza vSAN: 3 hosts ESXi con al menos 2 NIC físicas por host es el mínimo; sin embargo, se recomiendan 4 hosts ESXi para conseguir resiliencia durante la aplicación de revisiones y actualizaciones.

Los hosts deben unirse a un clúster con vSphere DRS y HA habilitados. vSphere DRS debe estar en el modo Totalmente automatizado.

Precaución: No deshabilite vSphere DRS después de configurar el clúster supervisor. Tener DRS habilitado en todo momento es un requisito previo obligatorio para ejecutar cargas de trabajo en el clúster supervisor. Si se deshabilita DRS, se interrumpirán los clústeres de Tanzu Kubernetes.
8 64 GB por host No aplicable
Máquinas virtuales de plano de control de Kubernetes 3 4 16 GB 16 GB

Requisitos de red

Independientemente de la topología que implemente para la administración de cargas de trabajo de Kubernetes en vSphere, la implementación debe cumplir los requisitos de red que se muestran en la siguiente tabla.
Nota: No puede crear clústeres IPv6 con un clúster supervisor de vSphere 7 ni registrar clústeres IPv6 con Tanzu Mission Control.
Componente Cantidad mínima Configuración necesaria
IP estáticas para las máquinas virtuales del plano de control de Kubernetes Bloque de 5 Un bloque de 5 direcciones IP estáticas consecutivas que se asignarán a las máquinas virtuales del plano de control de Kubernetes en el clúster supervisor.
Red de tráfico de administración 1 Una red de administración que se pueda enrutar a los hosts ESXi y a vCenter Server, y un servidor DHCP. La red debe poder acceder a un registro del contenedor y tener conectividad a Internet si el registro del contenedor se encuentra en la red externa. El registro del contenedor debe poder resolverse a través del DNS y la configuración de salida que se describe a continuación debe poder acceder a él.
Servidor NTP y DNS 1 Un servidor DNS y un servidor NTP que se pueden utilizar para vCenter Server.
Nota: Configure NTP en todos los hosts ESXi, los sistemas de vCenter Server y las instancias de NSX Manager.
servidor DHCP 1 Opcional. Configure un servidor DHCP para adquirir automáticamente direcciones IP para administración. El servidor DHCP debe admitir identificadores de cliente y proporcionar servidores DNS compatibles, dominios de búsqueda de DNS y un servidor NTP.
Registro de imágenes 1 Acceda a un registro para el servicio.
Subred de red de administración 1
La subred que se utiliza para el tráfico de administración entre los hosts ESXi y vCenter Server, las instancias de NSX Appliance y el plano de control de Kubernetes. El tamaño de la subred debe ser el siguiente:
  • Una dirección IP por adaptador de VMkernel de host.
  • Una dirección IP para vCenter Server Appliance.
  • Una o cuatro direcciones IP para NSX Manager. Cuatro cuando se realiza una agrupación de NSX Manager de 3 nodos y 1 IP virtual (VIP).
  • 5 direcciones IP para el plano de control de Kubernetes. 1 para cada uno de los 3 nodos, 1 para la IP virtual, 1 para la actualización sucesiva de clústeres.
Nota: La red de administración y la red de carga de trabajo deben estar en subredes diferentes. No se admite la asignación de la misma subred a las redes de administración y carga de trabajo, lo que puede provocar errores y problemas en el sistema.
VLAN de red de administración 1 Identificador de VLAN de la subred de la red de administración.
VLAN 3 Las IP de VLAN son las direcciones IP de los endpoints de túnel (Tunnel Endpoints, TEP). Los TEP del host ESXi y los TEP de Edge deben ser enrutables.
Las direcciones IP de VLAN son necesarias para lo siguiente:
  • VTEP de host ESXi
  • VTEP de Edge con la IP estática
  • Puerta de enlace de nivel 0 y vínculo superior para el nodo de transporte.
Nota: El VTEP del host ESXi y el VTEP de Edge deben tener un tamaño de MTU superior a 1600.

Los hosts ESXi y los nodos de NSX-T Edge actúan como endpoints de túnel y se asigna una IP de endpoint de túnel (Tunnel Endpoint, TEP) a cada nodo de Edge y host.

Como las IP de TEP para hosts ESXi crean un túnel de superposición con IP de TEP en los nodos de Edge, las IP de VLAN deben poder enrutarse.

Se requiere una VLAN adicional para proporcionar conectividad de norte a sur a la puerta de enlace de nivel 0.

Los grupos de direcciones IP pueden compartirse entre clústeres. Sin embargo, el grupo de direcciones IP/VLAN de superposición de host no se debe compartir con la VLAN o el grupo de direcciones IP de superposición de Edge.

Nota: Si el TEP del host y el TEP de Edge usan diferentes NIC físicas, pueden utilizar la misma VLAN.
IP de vínculo superior de nivel 0 /24 direcciones IP privadas La subred de IP que se utiliza para el vínculo superior de nivel 0. Los requisitos para la dirección IP del vínculo superior de nivel 0 son los siguientes:
  • 1 dirección IP, si no se requiere redundancia de Edge.
  • 4 direcciones IP; si utiliza BGP y redundancia de Edge, necesitará 2 direcciones IP por Edge.
  • 3 direcciones IP, si utiliza rutas estáticas y redundancia de Edge.

La IP de administración de Edge, la subred, la puerta de enlace, la IP de vínculo superior, la subred y la puerta de enlace deben ser únicas.
MTU de red física 1.600 El tamaño de MTU debe ser 1600 o superior en cualquier red que transporte tráfico superpuesto.
Rango de CIDR del pod de vSphere /23 direcciones IP privadas Un rango de CIDR privado que proporciona direcciones IP a los pods de vSphere. Estas direcciones también se utilizan para los nodos del clúster de Tanzu Kubernetes.
Debe especificar un rango de CIDR único del pod de vSphere para cada clúster.
Nota: El rango de CIDR del pod de vSphere y el rango de CIDR de las direcciones del servicio de Kubernetes no deben superponerse.
Rango de CIDR de servicios de Kubernetes /16 direcciones IP privadas Un rango de CIDR privado para asignar direcciones IP a los servicios de Kubernetes. Debe especificar un rango de CIDR único de servicios de Kubernetes para cada clúster supervisor.
Rango de CIDR de salida /27 direcciones IP estáticas Una anotación de CIDR privado para determinar la IP de egreso de los servicios de Kubernetes. Solo se asigna una dirección IP de egreso para cada espacio de nombres en el clúster supervisor. La IP de egreso es la dirección que las entidades externas utilizan para comunicarse con los servicios en el espacio de nombres. La cantidad de direcciones IP de egreso limita el número de directivas de egreso que puede tener el clúster supervisor.
El valor mínimo es un CIDR de /27 o más. Por ejemplo, 10.174.4.96/27
Nota: Las direcciones IP de egreso y las direcciones IP de entrada no deben superponerse.
CIDR de entrada /27 direcciones IP estáticas Un rango de CIDR privado que se utilizará para las direcciones IP de entradas. La entrada permite aplicar directivas de tráfico a las solicitudes que entran en clúster supervisor desde redes externas. La cantidad de direcciones IP de entrada limita el número de entradas que puede tener el clúster.
El valor mínimo es un CIDR de /27 o más.
Nota: Las direcciones IP de egreso y las direcciones IP de entrada no deben superponerse.