Para crear un archivo de configuración de clúster, puede copiar un archivo de configuración existente de una implementación anterior en vSphere y actualizarlo. Si lo prefiere, puede crear un archivo desde cero mediante una plantilla vacía.
La siguiente plantilla incluye todas las opciones pertinentes para implementar clústeres de administración en vSphere. Puede copiar esta plantilla y utilizarla para implementar clústeres de administración en vSphere.
Las opciones obligatorias no están comentadas. Los ajustes opcionales están comentados. Los valores predeterminados se incluyen donde corresponda.
#! ---------------------------------------------------------------------
#! Basic cluster creation configuration
#! ---------------------------------------------------------------------
CLUSTER_NAME:
CLUSTER_PLAN: dev
INFRASTRUCTURE_PROVIDER: vsphere
# CLUSTER_API_SERVER_PORT: # For deployments without NSX Advanced Load Balancer
ENABLE_CEIP_PARTICIPATION: true
ENABLE_AUDIT_LOGGING: true
CLUSTER_CIDR: 100.96.0.0/11
SERVICE_CIDR: 100.64.0.0/13
# CAPBK_BOOTSTRAP_TOKEN_TTL: 30m
#! ---------------------------------------------------------------------
#! vSphere configuration
#! ---------------------------------------------------------------------
VSPHERE_SERVER:
VSPHERE_USERNAME:
VSPHERE_PASSWORD:
VSPHERE_DATACENTER:
VSPHERE_RESOURCE_POOL:
VSPHERE_DATASTORE:
VSPHERE_FOLDER:
VSPHERE_NETWORK: VM Network
# VSPHERE_CONTROL_PLANE_ENDPOINT: # Required for Kube-Vip
# VSPHERE_CONTROL_PLANE_ENDPOINT_PORT: 6443
VIP_NETWORK_INTERFACE: "eth0"
# VSPHERE_TEMPLATE:
VSPHERE_SSH_AUTHORIZED_KEY:
# VSPHERE_STORAGE_POLICY_ID: ""
VSPHERE_TLS_THUMBPRINT:
VSPHERE_INSECURE: false
DEPLOY_TKG_ON_VSPHERE7: false
ENABLE_TKGS_ON_VSPHERE7: false
#! ---------------------------------------------------------------------
#! Node configuration
#! ---------------------------------------------------------------------
# SIZE:
# CONTROLPLANE_SIZE:
# WORKER_SIZE:
# OS_NAME: ""
# OS_VERSION: ""
# OS_ARCH: ""
# VSPHERE_NUM_CPUS: 2
# VSPHERE_DISK_GIB: 40
# VSPHERE_MEM_MIB: 4096
# VSPHERE_MTU:
# VSPHERE_CONTROL_PLANE_NUM_CPUS: 2
# VSPHERE_CONTROL_PLANE_DISK_GIB: 40
# VSPHERE_CONTROL_PLANE_MEM_MIB: 8192
# VSPHERE_WORKER_NUM_CPUS: 2
# VSPHERE_WORKER_DISK_GIB: 40
# VSPHERE_WORKER_MEM_MIB: 4096
#! ---------------------------------------------------------------------
#! VMware NSX specific configuration for enabling NSX routable pods
#! ---------------------------------------------------------------------
# NSXT_POD_ROUTING_ENABLED: false
# NSXT_ROUTER_PATH: ""
# NSXT_USERNAME: ""
# NSXT_PASSWORD: ""
# NSXT_MANAGER_HOST: ""
# NSXT_ALLOW_UNVERIFIED_SSL: false
# NSXT_REMOTE_AUTH: false
# NSXT_VMC_ACCESS_TOKEN: ""
# NSXT_VMC_AUTH_HOST: ""
# NSXT_CLIENT_CERT_KEY_DATA: ""
# NSXT_CLIENT_CERT_DATA: ""
# NSXT_ROOT_CA_DATA: ""
# NSXT_SECRET_NAME: "cloud-provider-vsphere-nsxt-credentials"
# NSXT_SECRET_NAMESPACE: "kube-system"
#! ---------------------------------------------------------------------
#! NSX Advanced Load Balancer configuration
#! ---------------------------------------------------------------------
AVI_ENABLE: false
AVI_CONTROL_PLANE_HA_PROVIDER: false
# AVI_NAMESPACE: "tkg-system-networking"
# AVI_DISABLE_INGRESS_CLASS: true
# AVI_AKO_IMAGE_PULL_POLICY: IfNotPresent
# AVI_ADMIN_CREDENTIAL_NAME: avi-controller-credentials
# AVI_CA_NAME: avi-controller-ca
# AVI_CONTROLLER:
# AVI_USERNAME: ""
# AVI_PASSWORD: ""
# AVI_CLOUD_NAME:
# AVI_SERVICE_ENGINE_GROUP:
# AVI_NSXT_T1LR: # Required for NSX ALB deployments on NSX Cloud.
# AVI_MANAGEMENT_CLUSTER_SERVICE_ENGINE_GROUP:
# AVI_DATA_NETWORK:
# AVI_DATA_NETWORK_CIDR:
# AVI_MANAGEMENT_CLUSTER_VIP_NETWORK_NAME:
# AVI_MANAGEMENT_CLUSTER_VIP_NETWORK_CIDR:
# AVI_CA_DATA_B64: ""
# AVI_LABELS: ""
# AVI_DISABLE_STATIC_ROUTE_SYNC: true
# AVI_INGRESS_DEFAULT_INGRESS_CONTROLLER: false
# AVI_INGRESS_SHARD_VS_SIZE: ""
# AVI_INGRESS_SERVICE_TYPE: ""
# AVI_INGRESS_NODE_NETWORK_LIST: ""
#! ---------------------------------------------------------------------
#! Image repository configuration
#! ---------------------------------------------------------------------
# TKG_CUSTOM_IMAGE_REPOSITORY: ""
# TKG_CUSTOM_IMAGE_REPOSITORY_CA_CERTIFICATE: ""
#! ---------------------------------------------------------------------
#! Proxy configuration
#! ---------------------------------------------------------------------
# TKG_HTTP_PROXY: ""
# TKG_HTTPS_PROXY: ""
# TKG_NO_PROXY: ""
#! ---------------------------------------------------------------------
#! Machine Health Check configuration
#! ---------------------------------------------------------------------
ENABLE_MHC:
ENABLE_MHC_CONTROL_PLANE: true
ENABLE_MHC_WORKER_NODE: true
MHC_UNKNOWN_STATUS_TIMEOUT: 5m
MHC_FALSE_STATUS_TIMEOUT: 12m
#! ---------------------------------------------------------------------
#! Identity management configuration
#! ---------------------------------------------------------------------
IDENTITY_MANAGEMENT_TYPE: "none"
#! Settings for IDENTITY_MANAGEMENT_TYPE: "oidc"
# CERT_DURATION: 2160h
# CERT_RENEW_BEFORE: 360h
# OIDC_IDENTITY_PROVIDER_CLIENT_ID:
# OIDC_IDENTITY_PROVIDER_CLIENT_SECRET:
# OIDC_IDENTITY_PROVIDER_GROUPS_CLAIM: groups
# OIDC_IDENTITY_PROVIDER_ISSUER_URL:
# OIDC_IDENTITY_PROVIDER_SCOPES: "email,profile,groups,offline_access"
# OIDC_IDENTITY_PROVIDER_USERNAME_CLAIM: email
#! The following two variables are used to configure Pinniped JWTAuthenticator for workload clusters
# SUPERVISOR_ISSUER_URL:
# SUPERVISOR_ISSUER_CA_BUNDLE_DATA:
#! Settings for IDENTITY_MANAGEMENT_TYPE: "ldap"
# LDAP_BIND_DN:
# LDAP_BIND_PASSWORD:
# LDAP_HOST:
# LDAP_USER_SEARCH_BASE_DN:
# LDAP_USER_SEARCH_FILTER:
# LDAP_USER_SEARCH_ID_ATTRIBUTE: dn
# LDAP_USER_SEARCH_NAME_ATTRIBUTE:
# LDAP_GROUP_SEARCH_BASE_DN:
# LDAP_GROUP_SEARCH_FILTER:
# LDAP_GROUP_SEARCH_NAME_ATTRIBUTE: dn
# LDAP_GROUP_SEARCH_USER_ATTRIBUTE: dn
# LDAP_ROOT_CA_DATA_B64:
#! ---------------------------------------------------------------------
#! Antrea CNI configuration
#! ---------------------------------------------------------------------
# ANTREA_NO_SNAT: true
# ANTREA_NODEPORTLOCAL: true
# ANTREA_NODEPORTLOCAL_ENABLED: true
# ANTREA_NODEPORTLOCAL_PORTRANGE: 61000-62000
# ANTREA_TRAFFIC_ENCAP_MODE: "encap"
# ANTREA_PROXY: true
# ANTREA_PROXY_ALL: true
# ANTREA_PROXY_LOAD_BALANCER_IPS: false
# ANTREA_PROXY_NODEPORT_ADDRS:
# ANTREA_PROXY_SKIP_SERVICES: ""
# ANTREA_POLICY: true
# ANTREA_TRACEFLOW: true
# ANTREA_DISABLE_UDP_TUNNEL_OFFLOAD: false
# ANTREA_ENABLE_USAGE_REPORTING: false
# ANTREA_EGRESS: true
# ANTREA_EGRESS_EXCEPT_CIDRS: ""
# ANTREA_FLOWEXPORTER: false
# ANTREA_FLOWEXPORTER_COLLECTOR_ADDRESS: "flow-aggregator.flow-aggregator.svc:4739:tls"
# ANTREA_FLOWEXPORTER_POLL_INTERVAL: "5s"
# ANTREA_FLOWEXPORTER_ACTIVE_TIMEOUT: "5s"
# ANTREA_FLOWEXPORTER_IDLE_TIMEOUT: "15s"
# ANTREA_IPAM: false
# ANTREA_KUBE_APISERVER_OVERRIDE: ""
# ANTREA_MULTICAST: false
# ANTREA_MULTICAST_INTERFACES: ""
# ANTREA_NETWORKPOLICY_STATS: true
# ANTREA_SERVICE_EXTERNALIP: true
# ANTREA_TRANSPORT_INTERFACE: ""
# ANTREA_TRANSPORT_INTERFACE_CIDRS: ""
Proporcione información para permitir que Tanzu Kubernetes Grid inicie sesión en vSphere y para designar los recursos que Tanzu Kubernetes Grid puede utilizar.
VSPHERE_SERVER
, VSPHERE_USERNAME
y VSPHERE_PASSWORD
con la dirección IP o el FQDN de la instancia de vCenter Server y las credenciales que se utilizarán para iniciar sesión.Proporcione las rutas de acceso completas al centro de datos vSphere, el grupo de recursos, los almacenes de datos y la carpeta en la que se implementará el clúster de administración:
VSPHERE_DATACENTER
: /<MY-DATACENTER>
VSPHERE_RESOURCE_POOL
: /<MY-DATACENTER>/host/<CLUSTER>/Resources
VSPHERE_DATASTORE
: /<MY-DATACENTER>/datastore/<MY-DATASTORE>
VSPHERE_FOLDER
: /<MY-DATACENTER>/vm/<FOLDER>.
VSPHERE_CONTROL_PLANE_ENDPOINT
o déjelo en blanco:
VSPHERE_NETWORK
y VIP_NETWORK_INTERFACE
.VSPHERE_TEMPLATE
para especificar la ruta de acceso a un archivo OVA si utiliza varias imágenes OVA personalizadas para la misma versión de Kubernetes. Utilice el formato /MY-DC/vm/MY-FOLDER-PATH/MY-IMAGE
. Para obtener más información, consulte Implementar un clúster con una imagen OVA personalizada en Crear y administrar clústeres de carga de trabajo de TKG 2.4 con CLI de Tanzu.VSPHERE_SSH_AUTHORIZED_KEY
. Para obtener información sobre cómo obtener una clave SSH, consulte Preparar para implementar clústeres de administración en vSphere.VSPHERE_TLS_THUMBPRINT
o establezca VSPHERE_INSECURE: true
para omitir la verificación por huella digital.VSPHERE_STORAGE_POLICY_ID
y especifique el nombre de una directiva de almacenamiento para las máquinas virtuales que configuró en vCenter Server, para que la utilice el clúster de administración.Por ejemplo:
#! ---------------------------------------------------------------------
#! vSphere configuration
#! ---------------------------------------------------------------------
VSPHERE_SERVER: 10.185.12.154
VSPHERE_USERNAME: [email protected]
VSPHERE_PASSWORD: <encoded:QWRtaW4hMjM=>
VSPHERE_DATACENTER: /dc0
VSPHERE_RESOURCE_POOL: /dc0/host/cluster0/Resources/tanzu
VSPHERE_DATASTORE: /dc0/datastore/sharedVmfs-1
VSPHERE_FOLDER: /dc0/vm/tanzu
VSPHERE_NETWORK: "VM Network"
VSPHERE_CONTROL_PLANE_ENDPOINT: 10.185.11.134
VIP_NETWORK_INTERFACE: "eth0"
VSPHERE_TEMPLATE: /dc0/vm/tanzu/my-image.ova
VSPHERE_SSH_AUTHORIZED_KEY: ssh-rsa AAAAB3[...]tyaw== [email protected]
VSPHERE_TLS_THUMBPRINT: 47:F5:83:8E:5D:36:[...]:72:5A:89:7D:29:E5:DA
VSPHERE_INSECURE: false
VSPHERE_STORAGE_POLICY_ID: "My storage policy"
La CLI de Tanzu crea los nodos individuales de los clústeres de administración y los clústeres de carga de trabajo de acuerdo con la configuración que se proporciona en el archivo de configuración. En vSphere, puede configurar todas las máquinas virtuales de los nodos para que tengan las mismas configuraciones predefinidas, establecer diferentes configuraciones predefinidas para los nodos de trabajo y el plano de control, o personalizar las configuraciones de los nodos. Con esta configuración, puede crear clústeres que tengan nodos con diferentes configuraciones en los nodos del clúster de administración. También puede crear clústeres en los que los nodos del plano de control y los nodos de trabajo tengan configuraciones diferentes.
La CLI de Tanzu proporciona las siguientes configuraciones predefinidas para los nodos del clúster:
small
: 2 CPU, 4 GB de memoria, disco de 20 GBmedium
: 2 CPU, 8 GB de memoria, disco de 40 GBlarge
: 4 CPU, 16 GB de memoria, disco de 40 GBextra-large
: 8 CPU, 32 GB de memoria, disco de 80 GBPara crear un clúster en el que todas las máquinas virtuales del plano de control y del nodo de trabajo tengan el mismo tamaño, especifique la variable SIZE
. Si establece la variable SIZE
, todos los nodos se crearán con la configuración establecida.
SIZE: "large"
Para crear un clúster en el que las máquinas virtuales del nodo de trabajo y el plano de control sean de diferentes tamaños, especifique las opciones CONTROLPLANE_SIZE
y WORKER_SIZE
.
CONTROLPLANE_SIZE: "medium"
WORKER_SIZE: "extra-large"
Puede combinar las opciones de CONTROLPLANE_SIZE
y WORKER_SIZE
con la opción SIZE
. Por ejemplo, si especifica SIZE: "large"
con WORKER_SIZE: "extra-large"
, los nodos del plano de control se establecerán en large
y los nodos de trabajo se establecerán en extra-large
.
SIZE: "large"
WORKER_SIZE: "extra-large"
Puede personalizar la configuración de los nodos en lugar de usar las configuraciones predefinidas.
Para utilizar la misma configuración personalizada para todos los nodos, especifique las opciones de VSPHERE_NUM_CPUS
, VSPHERE_DISK_GIB
y VSPHERE_MEM_MIB
.
VSPHERE_NUM_CPUS: 2
VSPHERE_DISK_GIB: 40
VSPHERE_MEM_MIB: 4096
Para definir diferentes configuraciones personalizadas para los nodos de plano de control y los nodos de trabajo, especifique las opciones VSPHERE_CONTROL_PLANE_*
y VSPHERE_WORKER_*
.
VSPHERE_CONTROL_PLANE_NUM_CPUS: 2
VSPHERE_CONTROL_PLANE_DISK_GIB: 20
VSPHERE_CONTROL_PLANE_MEM_MIB: 8192
VSPHERE_WORKER_NUM_CPUS: 4
VSPHERE_WORKER_DISK_GIB: 40
VSPHERE_WORKER_MEM_MIB: 4096
Puede anular esta configuración mediante las opciones SIZE
, CONTROLPLANE_SIZE
y WORKER_SIZE
.
Para utilizar NSX Advanced Load Balancer, primero debe implementarlo en el entorno de vSphere. Consulte Instalar NSX Advanced Load Balancer. Después de implementar NSX Advanced Load Balancer, configure un clúster de administración de vSphere para utilizar el equilibrador de carga.
Por ejemplo:
AVI_ENABLE: true
AVI_CONTROL_PLANE_HA_PROVIDER: true
AVI_NAMESPACE: "tkg-system-networking"
AVI_DISABLE_INGRESS_CLASS: true
AVI_AKO_IMAGE_PULL_POLICY: IfNotPresent
AVI_ADMIN_CREDENTIAL_NAME: avi-controller-credentials
AVI_CA_NAME: avi-controller-ca
AVI_CONTROLLER: 10.185.10.217
AVI_USERNAME: "admin"
AVI_PASSWORD: "<password>"
AVI_CLOUD_NAME: "Default-Cloud"
AVI_SERVICE_ENGINE_GROUP: "Default-Group"
AVI_NSXT_T1LR:""
AVI_DATA_NETWORK: nsx-alb-dvswitch
AVI_DATA_NETWORK_CIDR: 10.185.0.0/20
AVI_MANAGEMENT_CLUSTER_VIP_NETWORK_NAME: ""
AVI_MANAGEMENT_CLUSTER_VIP_NETWORK_CIDR: ""
AVI_CA_DATA_B64: LS0tLS1CRU[...]UtLS0tLQo=
AVI_LABELS: ""
AVI_DISABLE_STATIC_ROUTE_SYNC: true
AVI_INGRESS_DEFAULT_INGRESS_CONTROLLER: false
AVI_INGRESS_SHARD_VS_SIZE: ""
AVI_INGRESS_SERVICE_TYPE: ""
AVI_INGRESS_NODE_NETWORK_LIST: ""
De forma predeterminada, el clúster de administración y todos los clústeres de carga de trabajo que administra utilizarán el equilibrador de carga. Para obtener información sobre cómo configurar las variables de NSX Advanced Load Balancer, consulte NSX Advanced Load Balancer en la Referencia de variables de archivo de configuración de la .
Puede utilizar NSX ALB como proveedor de endpoint del plano de control en Tanzu Kubernetes Grid. En la siguiente tabla se describen las diferencias entre NSX ALB y Kube-Vip, que es el proveedor de endpoint del plano de control predeterminado en Tanzu Kubernetes Grid.
Kube-Vip | NSX ALB | |
---|---|---|
Envía tráfico a | Nodo de plano de control único |
Varios nodos del plano de control |
Requiere configurar VIP de endpoint | Sí |
No Asigna VIP desde el grupo de direcciones IP estáticas de NSX ALB |
Si el entorno de vSphere utiliza NSX, puede configurarlo para implementar pods enrutables o NO_NAT
.
NotaPods enrutables de NSX es una función experimental de esta versión. Pronto se agregará información sobre cómo implementar pods enrutables de NSX a esta documentación.
#! ---------------------------------------------------------------------
#! NSX specific configuration for enabling NSX routable pods
#! ---------------------------------------------------------------------
# NSXT_POD_ROUTING_ENABLED: false
# NSXT_ROUTER_PATH: ""
# NSXT_USERNAME: ""
# NSXT_PASSWORD: ""
# NSXT_MANAGER_HOST: ""
# NSXT_ALLOW_UNVERIFIED_SSL: false
# NSXT_REMOTE_AUTH: false
# NSXT_VMC_ACCESS_TOKEN: ""
# NSXT_VMC_AUTH_HOST: ""
# NSXT_CLIENT_CERT_KEY_DATA: ""
# NSXT_CLIENT_CERT_DATA: ""
# NSXT_ROOT_CA_DATA: ""
# NSXT_SECRET_NAME: "cloud-provider-vsphere-nsxt-credentials"
# NSXT_SECRET_NAMESPACE: "kube-system"
Para configurar un clúster de administración que admita IPv6 en un entorno de redes IPv6:
Prepare el entorno como se describe en (opcional) Establecer variables y reglas para IPv6.
Establezca las siguientes variables en el archivo de configuración para el clúster de administración.
TKG_IP_FAMILY
en ipv6
.VSPHERE_CONTROL_PLANE_ENDPOINT
en una dirección IPv6 estática.CLUSTER_CIDR and SERVICE_CIDR
. El valor predeterminado es fd00:100:64::/48
y fd00:100:96::/108
, respectivamente.Puede configurar un clúster de carga de trabajo o de administración que ejecute nodos en varias zonas de disponibilidad (Availability Zones, AZ) como se describe en Ejecución de clústeres en varias zonas de disponibilidad
Requisitos previos
FailureDomain
y Deployment Zone
en KubernetesPara configurar un clúster con nodos implementados en varias AZ:
VSPHERE_REGION
y VSPHERE_ZONE
con las categorías de etiqueta de región y zona k8s-region
y k8s-zone
.VSPHERE_AZ_0
, VSPHERE_AZ_1
y VSPHERE_AZ_2
con los nombres de los objetos VsphereDeploymentZone
en los que se deben implementar las máquinas.
VsphereDeploymentZone
asociada con VSPHERE_AZ_0
es el VSphereFailureDomain
en el que se implementa la implementación de la máquina que termina en md-0
; de igual modo, VSPHERE_AZ_1
es el VSphereFailureDomain
en el que se implementa la implementación de la máquina que termina en md-1
y VSPHERE_AZ_2
es el VSphereFailureDomain
en el que se implementa la implementación de la máquina que termina en md-2
.VSphereFailureDomain
.WORKER_MACHINE_COUNT
establece el número total de trabajos para el clúster. El número total de trabajadores se distribuye por turnos entre el número de AZ especificadasVSPHERE_AZ_CONTROL_PLANE_MATCHING_LABELS
establece etiquetas de selector de clave/valor para las AZ en las que pueden implementarse los nodos del clúster. Esto permite, por ejemplo, especificar todas las AZ de una región y un entorno sin tener que enumerarlas todas de forma individual: "region=us-west-1,environment=staging"
.SKIP_MULTI_AZ_VERIFY
en true
para omitir las comprobaciones de que todas las zonas y regiones vSphere a las que se hace referencia existen, se especifican de forma coherente y están en el mismo nivel.Para obtener la lista completa de opciones que debe especificar al implementar clústeres en vSphere, consulte la referencia de variables del archivo de configuración.
TKG admite Node IPAM en clúster para clústeres de administración independientes en vSphere y los clústeres de carga de trabajo basados en clases que administran. Para obtener más información y las limitaciones actuales, consulte Node IPAM en Crear y administrar clústeres de carga de trabajo de TKG 2.4 con CLI de Tanzu.
No se puede implementar un clúster de administración con Node IPAM directamente desde la interfaz del instalador; debe implementarlo desde un archivo de configuración. Sin embargo, puede crear el archivo de configuración ejecutando la interfaz del instalador, haciendo clic en Revisar configuración (Review Configuration) > Exportar configuración (Export Configuration) y, a continuación, editando el archivo de configuración generado como se describe a continuación.
Para implementar un clúster de administración que utilice IPAM en clúster para sus nodos:
Como requisito previo, recopile las direcciones IP de los servidores de nombres que se utilizarán para los nodos de trabajo y el plano de control del clúster. Esto es necesario porque los nodos del clúster ya no recibirán servidores de nombres a través de DHCP para resolver nombres en vCenter.
Edite el archivo de configuración del clúster de administración para incluir opciones como la siguiente, como se describe en la tabla Node IPAM en la referencia de variable de archivo de configuración:
MANAGEMENT_NODE_IPAM_IP_POOL_GATEWAY: "10.10.10.1"
MANAGEMENT_NODE_IPAM_IP_POOL_ADDRESSES: "10.10.10.2-10.10.10.100,10.10.10.105"
MANAGEMENT_NODE_IPAM_IP_POOL_SUBNET_PREFIX: "24"
CONTROL_PLANE_NODE_NAMESERVERS: "10.10.10.10,10.10.10.11"
WORKER_NODE_NAMESERVERS: "10.10.10.10,10.10.10.11"
Donde CONTROL_PLANE_NODE_NAMESERVERS
y WORKER_NODE_NAMESERVERS
son las direcciones de los servidores de nombres que se utilizarán. Puede especificar un solo servidor de nombres o dos servidores de nombres separados por comas. Es posible que necesite más de un servidor de nombres en entornos que requieran redundancia. En este caso, una máquina virtual de nodo solo utilizará un servidor de nombres a la vez y se utilizarán servidores de nombres secundarios si el servidor de nombres no se puede resolver. También puede especificar más de un servidor de nombres para cambiar de forma independiente los servidores de nombres para los nodos de plano de control y de trabajo, respectivamente, a fin de controlar la resolución de servicios en los distintos tipos de nodos.
Para configurar la unidad de transmisión máxima (Maximum Transmission Unit, MTU) para los clústeres de administración y los clústeres de carga de trabajo en un conmutador estándar de vSphere, establezca la variable VSPHERE_MTU
. La configuración de VSPHERE_MTU
se aplica tanto a los clústeres de administración como a los clústeres de carga de trabajo.
Si no se especifica, la MTU predeterminada del nodo de vSphere es 1500. El valor máximo es 9000. Para obtener información sobre las MTU, consulte Acerca de las redes de vSphere en la documentación de vSphere 8.
En vSphere 7 y vSphere 8, vSphere with Tanzu ofrece un supervisor integrado que funciona como clúster de administración y proporciona una mejor experiencia que un clúster de administración independiente. Se admite la implementación de un clúster de administración de Tanzu Kubernetes Grid en vSphere 7 o vSphere 8 cuando el supervisor no está presente, pero la opción preferida es habilitar vSphere with Tanzu y utilizar el supervisor si es posible. Azure VMware Solution no admite un clúster supervisor, por lo que debe implementar un clúster de administración. Para obtener más información, consulte El supervisor de vSphere with Tanzu es un clúster de administración.
Si vSphere with Tanzu está habilitado, la interfaz del instalador indica que puede utilizar el servicio TKG como forma preferida de ejecutar cargas de trabajo de Kubernetes, en cuyo caso no necesita un clúster de administración independiente. Presenta una opción:
Configurar vSphere with Tanzu (Configure vSphere with Tanzu) abre el vSphere Client para que pueda configurar el supervisor como se describe en Configurar y administrar un supervisor en la documentación de vSphere 8.
Implementar clúster de administración de TKG (Deploy TKG Management Cluster) permite seguir implementando un clúster de administración independiente, para vSphere 7 o vSphere 8, y según sea necesario para Azure VMware Solution.
Después de que haya terminado de actualizar el archivo de configuración del clúster de administración, cree el clúster de administración siguiendo las instrucciones de Implementar clúster de administración desde un archivo de configuración.