Se usó la API de Cloud Translation para traducir esta página.

Crea un clúster de usuario

En GKE on VMware, tus cargas de trabajo se ejecutan en uno o más clústeres de usuario. En este documento, se muestra cómo crear un clúster de usuario.

Hay varias herramientas que puedes usar para crear un clúster de usuario:

gkectl
Consola de Google Cloud
Google Cloud CLI
Terraform

Tres de estas herramientas (console, gcloud CLI y Terraform) son clientes de la API de GKE On-Prem.

Si deseas obtener orientación sobre qué herramienta te gustaría usar, consulta Elige una herramienta para administrar el ciclo de vida de un clúster.

Antes de comenzar

Si aún no lo hiciste, configura tus recursos de Google Cloud como se describe en estos documentos:
Cuando configures el proyecto host de flota, ten en cuenta la herramienta que elegiste, ya que, si elegiste uno de los clientes de la API de GKE On-Prem, debes habilitar APIs adicionales.
Antes de crear un clúster de usuario, debes tener un clúster de administrador para administrar el clúster de usuario. Si aún no lo hiciste, crea una estación de trabajo de administrador y un clúster de administrador.

Si decidiste usar uno de los clientes de la API de GKE On-Prem, debes habilitar el registro de auditoría y Cloud Logging para el clúster de administrador.
Determina la versión del clúster de usuario que deseas instalar. Cuando creas un clúster de usuario, por lo general, debes instalar la versión que coincide con la del clúster de administrador. Pero puedes instalar una versión posterior del parche o una versión secundaria posterior. Para obtener más información, consulta Instala una versión posterior a la versión del clúster de administrador.
Piensa si quieres que tu clúster de usuario habilite Controlplane V2. Cuando el plano de control V2 está habilitado, el plano de control del clúster de usuario se ejecuta en uno o más nodos del clúster de usuario. Te recomendamos que habilites el plano de control V2. La alternativa es crear un clúster de usuario que use kubeception. En el caso de kubeception, el plano de control del clúster de usuario se ejecuta en uno o más nodos del clúster de administrador.
Revisa el documento de planificación de direcciones IP y asegúrate de tener suficientes direcciones IP disponibles.
Revisa la descripción general del balanceo de cargas y vuelve a decidir tu decisión sobre el tipo de balanceador de cargas que deseas usar. Puedes usar el balanceador de cargas agrupado de MetalLB o configurar de forma manual el balanceador de cargas que desees. Para el balanceo de cargas manual, debes configurar el balanceador de cargas antes de crear el clúster de usuario.
Piensa en cuántos grupos de nodos necesitas y qué sistema operativo quieres ejecutar en cada uno de tus grupos.
Piensa si deseas usar clústeres de vSphere independientes para el clúster de administrador y los clústeres de usuario, y si deseas usar centros de datos separados. Además, piensa si deseas usar instancias independientes de vCenter Server.

Crea un clúster de usuario

gkectl

Descripción general del procedimiento

Estos son los pasos principales que implica usar gkectl para crear un clúster de usuario:

Conéctate a la estación de trabajo de administrador

La estación de trabajo de administrador es una máquina que tiene las herramientas necesarias para crear un clúster de usuario.
Completa los archivos de configuración

Especifica los detalles de tu clúster nuevo. Para ello, completa un archivo de configuración del clúster de usuario, un archivo de configuración de credenciales y, posiblemente, un archivo de bloque de IP.
(Opcional) Importa imágenes de SO a vSphere y envía imágenes de contenedor al registro privado, si corresponde.

Ejecuta gkectl prepare.
Crea un clúster de usuario

Ejecuta gkectl create cluster para crear un clúster como se especifica en el archivo de configuración.
Verifica que el clúster de usuario esté en ejecución

Usa kubectl para ver los nodos del clúster.

Al final de este procedimiento, tendrás un clúster de usuario en ejecución en el que podrás implementar las cargas de trabajo.

Si usas los Controles del servicio de VPC, es posible que veas errores cuando ejecutes algunos comandos de gkectl, como "Validation Category: GCP - [UNKNOWN] GCP service: [Stackdriver] could not get GCP services". Para evitar estos errores, agrega el parámetro --skip-validation-gcp a tus comandos.

Completa los archivos de configuración

Sigue estos pasos en la estación de trabajo de administrador.

Cuando gkeadm creó la estación de trabajo de administrador, generó un segundo archivo de configuración llamado user-cluster.yaml. Este archivo de configuración sirve para crear tu clúster de usuario.

Familiarízate con el archivo de configuración mediante el análisis del documento del archivo de configuración del clúster de usuario. Se recomienda mantener este documento abierto en una pestaña o ventana separada, ya que harás referencia a él a medida que completes los siguientes pasos.

`name`

Configura el campo name con el nombre que desees para el clúster de usuarios.

`gkeOnPremVersion`

Ya se completó este campo. Especifica la versión de GKE en VMware. Por ejemplo, 1.28.400-gke.75.

`enableControlplaneV2`

Para crear un clúster de usuario que tenga habilitado el plano de control V2, establece enableControlplaneV2 en true.

Cuando el plano de control V2 está habilitado, el plano de control del clúster de usuario se ejecuta en los nodos del clúster de usuario. Te recomendamos que habilites el plano de control V2.

kubeception

Si configuras este campo como false, el clúster usará kubecetption. Con kubeception, el plano de control del clúster de usuario se ejecuta en nodos en el clúster de administrador.

Para un clúster de kubeception:

Establece enableControlplaneV2 en false.
No completes la sección controlPlaneIPBlock.
Especifica las direcciones IP de los nodos del plano de control del clúster de usuario en el archivo de bloque de IP del clúster de administrador.

`enableDataplaneV2`

Configura enableDataplaneV2 en true.

`vCenter`

Los valores que estableces en la sección vCenter del archivo de configuración del clúster de administrador son globales. Es decir, se aplican al clúster de administrador y a los clústeres de usuario asociados.

Para cada clúster de usuario que crees, tienes la opción de anular algunos de los valores de vCenter globales.

Para anular cualquiera de los valores de vCenter globales, completa los campos relevantes en la sección vCenter del archivo de configuración de tu clúster de usuario.

En particular, es posible que desees usar clústeres de vSphere separados para el clúster de administrador y los clústeres de usuario, y centros de datos separados para el clúster de administrador y los clústeres de usuario.

Usa un centro de datos y un clúster de vSphere

La opción predeterminada es usar un centro de datos y un clúster de vSphere para el clúster de administrador y el de usuario. Para esta opción, no establezcas ningún valor de vCenter en el archivo de configuración del clúster de usuario. Los valores vCenter se heredarán del clúster de administrador.

Usa clústeres de vSphere independientes

Si deseas crear un clúster de usuario que esté en su propio clúster de vSphere, especifica un valor para vCenter.cluster en el archivo de configuración del clúster de usuario.

Si el clúster de administrador y el de usuario están en clústeres de vSphere separados, pueden estar en el mismo centro de datos o en centros de datos diferentes.

Usa centros de datos de vSphere independientes

El clúster de usuario y el de administrador pueden estar en diferentes centros de datos. En ese caso, también estarán en clústeres de vSphere separados.

Si especificas vCenter.datacenter en el archivo de configuración del clúster de usuario, también debes especificar lo siguiente:

vCenter.networkName
vCenter.datastore o vCenter.storagePolicyName
vCenter.cluster o vCenter.resourcePool

Usa cuentas de vCenter separadas

Un clúster de usuario puede usar una cuenta de vCenter diferente del clúster de administrador, con vCenter.credentials diferente. La cuenta de vCenter para el clúster de administrador necesita acceso al centro de datos del clúster de administrador, mientras que la cuenta de vCenter para el clúster de usuario solo necesita acceso al centro de datos del clúster de usuario.

Usa instancias independientes de vCenter Server

En algunas situaciones, tiene sentido crear un clúster de usuario que use su propia instancia de vCenter Server. Es decir, el clúster de administrador y el clúster de usuario asociado usan instancias diferentes de vCenter Server.

Por ejemplo, en una ubicación perimetral, es posible que desees tener una máquina física que ejecute vCenter Server y una o más máquinas físicas que ejecuten ESXi. Luego, puedes usar tu instancia local de vCenter Server para crear una jerarquía de objetos de vSphere, que incluya centros de datos, clústeres, grupos de recursos, almacenes de datos y carpetas.

Completa la sección vCenter completa del archivo de configuración del clúster de usuario. En particular, especifica un valor para vCenter.address que sea diferente de la dirección de vCenter Server que especificaste en el archivo de configuración del clúster de administrador. Por ejemplo:

vCenter:
  address: "vc-edge.example"
  datacenter: "vc-edge"
  cluster: "vc-edge-workloads"
  resourcePool: "vc-edge-pool
  datastore: "vc-edge-datastore
  caCertPath: "/usr/local/google/home/me/certs/edge-cacert.pem"
  credentials:
    fileRef:
      path: "credential.yaml"
      entry: "vCenter-edge"
  folder: "edge-vm-folder"

También completa el campo network.vCenter.networkName.

`network`

Decide cómo quieres que tus nodos trabajadores obtengan sus direcciones IP. Las opciones son las siguientes:

Desde un servidor DHCP que configures con anticipación. Configura network.ipMode.type como "dhcp".
De una lista de direcciones IP estáticas que proporciones. Configura network.ipMode.type como "static" y crea un archivo de bloques de IP que proporcione las direcciones IP estáticas. Para ver un ejemplo de un archivo de bloque de IP, consulta Ejemplo de archivos de configuración completados.

Si decidiste usar direcciones IP estáticas para tus nodos trabajadores, completa el campo network.ipMode.ipBlockFilePath.

Los nodos del plano de control para el clúster de usuario deben obtener sus direcciones IP de una lista de direcciones estáticas que proporciones. Esto es así incluso si tus nodos trabajadores obtienen sus direcciones de un servidor DHCP. Si deseas especificar direcciones IP estáticas para los nodos del plano de control, completa la sección network.controlPlaneIPBlock. Si deseas un clúster de usuario con alta disponibilidad (HA), especifica tres direcciones IP. De lo contrario, especifica una dirección IP.

Completa la sección hostConfig para especificar los servidores DNS y NTP. Estos servidores DNS y NTP son para los nodos del plano de control. Si usas direcciones IP estáticas para tus nodos trabajadores, estos servidores DNS y NTP también son para los nodos trabajadores.

network.podCIDR y network.serviceCIDR tienen valores prepropagados que puedes dejar sin modificar, a menos que entren en conflicto con direcciones que ya se usan en tu red. Kubernetes usa estos rangos para asignar direcciones IP a Pods y objetos Service en tu clúster.

Sin importar si dependes de un servidor DHCP o especificas una lista de direcciones IP estáticas, debes tener suficientes direcciones IP disponibles para el clúster de usuario. Para obtener una explicación de cuántas direcciones IP necesitas, consulta Planifica las direcciones IP.

`loadBalancer`

Reserva una VIP para el servidor de la API de Kubernetes del clúster de usuario. Dedica otro VIP para el servicio de entrada de tu clúster de usuario. Proporciona tus VIP como valores para loadBalancer.vips.controlPlaneVIP y loadBalancer.vips.ingressVIP.

Decide qué tipo de balanceo de cargas quieres usar. Las opciones son las siguientes:

Balanceo de cargas en paquetes de MetalLB. Configura loadBalancer.kind como "MetalLB". También completa la sección loadBalancer.metalLB.addressPools y configura enableLoadBalancer como true para al menos uno de tus grupos de nodos. Para obtener más información, consulta Balanceo de cargas en paquetes con MetalLB.
Balanceo de cargas manual. Configura loadBalancer.kind como "ManualLB" y completa la sección manualLB. Para obtener más información, consulta Balanceo de cargas manual.

Para obtener más información sobre las opciones de balanceo de cargas, consulta Descripción general del balanceo de cargas.

`advancedNetworking`

Si planeas crear una puerta de enlace NAT de salida, configura advancedNetworking como true.

`multipleNetworkInterfaces`

Decide si deseas configurar varias interfaces de red para Pods y configurar multipleNetworkInterfaces según corresponda.

`storage`

Si deseas inhabilitar la implementación de los componentes de CSI de vSphere, configura storage.vSphereCSIDisabled como true.

`masterNode`

En la sección masterNode, puedes especificar cuántos nodos del plano de control deseas para el clúster de usuario: uno o tres. También puedes especificar un almacén de datos para los nodos del plano de control y si deseas habilitar el cambio de tamaño automático de los nodos del plano de control.

Recuerda que especificaste las direcciones IP para los nodos del plano de control en la sección network.controlPlaneIPBlock.

`nodePools`

Un grupo de nodos es un conjunto de nodos dentro de un clúster que tienen la misma configuración. Por ejemplo, los nodos de un grupo podrían ejecutar Windows y los nodos en otro grupo podrían ejecutar Linux.

Debes especificar al menos un grupo de nodos mediante la sección nodePools.

Para obtener más información, consulta Grupos de nodos y Crea y administra grupos de nodos.

`antiAffinityGroups`

Establece antiAffinityGroups.enabled en true o false.

En este campo, se especifica si GKE en VMware crea reglas de antiafinidad de Distributed Resource Scheduler (DRS) para tus nodos trabajadores, lo que hace que se distribuyan en al menos tres hosts físicos del centro de datos.

`stackdriver`

Si deseas habilitar Cloud Logging y Cloud Monitoring para tu clúster, completa la sección stackdriver.

Esta sección es obligatoria de forma predeterminada. Es decir, si no completas esta sección, debes incluir la marca --skip-validation-stackdriver cuando ejecutes gkectl create cluster.

Ten en cuenta los siguientes requisitos para los clústeres nuevos:

El ID en stackdriver.projectID debe ser el mismo que el ID en gkeConnect.projectID y cloudAuditLogging.projectID.
La región de Google Cloud establecida en stackdriver.clusterLocation debe ser la misma que la región establecida en cloudAuditLogging.clusterLocation y gkeConnect.location (si el campo se incluye en el archivo de configuración). Además, si gkeOnPremAPI.enabled es true, se debe configurar la misma región en gkeOnPremAPI.location.

Si los IDs de proyecto y las regiones no son los mismos, la creación del clúster fallará.

`gkeConnect`

El clúster de usuario debe estar registrado en una flota de Google Cloud.

Completa la sección gkeConnect para especificar un proyecto host de flota y una cuenta de servicio asociada. El ID en gkeConnect.projectID debe ser el mismo que el ID configurado en stackdriver.projectID y cloudAuditLogging.projectID. Si los ID del proyecto no son iguales, la creación del clúster fallará.

En 1.28 y versiones posteriores, tienes la opción de especificar una región en la que los servicios Fleet and Connect se ejecutan en gkeConnect.location. Si no incluyes este campo, el clúster usará las instancias globales de estos servicios.

Si incluyes gkeConnect.location en tu archivo de configuración, la región que especifiques debe ser la misma que la región configurada en cloudAuditLogging.clusterLocation, stackdriver.clusterLocation y gkeOnPremAPI.location. Si las regiones no son iguales, la creación del clúster fallará.

`gkeOnPremAPI`

En 1.16 y versiones posteriores, si la API de GKE On-Prem está habilitada en tu proyecto de Google Cloud, todos los clústeres del proyecto se inscriben en la API de GKE On-Prem de forma automática en la región configurada en stackdriver.clusterLocation. La región gkeOnPremAPI.location debe ser la misma que la región especificada en cloudAuditLogging.clusterLocation, gkeConnect.location (si el campo está incluido en el archivo de configuración) y stackdriver.clusterLocation.

Si deseas inscribir todos los clústeres del proyecto en la API de GKE On-Prem, asegúrate de seguir los pasos que se indican en Antes de comenzar para activar y usar la API de GKE On-Prem en el proyecto.
Si no deseas inscribir el clúster en la API de GKE On-Prem, incluye esta sección y establece gkeOnPremAPI.enabled en false. Si no quieres inscribir ningún clúster en el proyecto, inhabilita gkeonprem.googleapis.com (el nombre del servicio para la API de GKE On-Prem) en el proyecto. Para obtener instrucciones, consulta Inhabilita servicios.

`usageMetering`

Si deseas habilitar la medición de uso para tu clúster, completa la sección usageMetering.

`cloudAuditLogging`

Si deseas integrar los registros de auditoría del servidor de la API de Kubernetes del clúster a los Registros de auditoría de Cloud, completa la sección cloudAuditLogging.

Ten en cuenta los siguientes requisitos para los clústeres nuevos:

El ID en cloudAuditLogging.projectID debe ser el mismo que el ID en gkeConnect.projectID y stackdriver.projectID.
La región de cloudAuditLogging.clusterLocation debe ser la misma que la región establecida en gkeConnect.location (si el campo se incluye en el archivo de configuración) y stackdriver.clusterLocation. Además, si gkeOnPremAPI.enabled es true, se debe configurar la misma región en gkeOnPremAPI.location.

Si los IDs de proyecto y las regiones no son los mismos, la creación del clúster fallará.

Ejemplo de archivos de configuración completados

A continuación, se muestra un ejemplo de un archivo de bloque de IP y un archivo de configuración de clúster de usuario:

user-ipblock.yaml

blocks:
  - netmask: 255.255.255.0
    gateway: 172.16.21.1
    ips:
    - ip: 172.16.21.2
      hostname: worker-vm-1
    - ip: 172.16.21.3
      hostname: worker-vm-2
    - ip: 172.16.21.4
      hostname: worker-vm-3
    - ip: 172.16.21.5
      hostname: worker-vm-4

user-cluster.yaml

cat user-cluster.yaml
apiVersion: v1
kind: UserCluster
name: "my-user-cluster"
gkeOnPremVersion: 1.28.400-gke.75
enableControlplaneV2: true
enableDataplaneV2: true
network:
  hostConfig:
    dnsServers:
    - "203.0.113.2"
    - "198.51.100.2"
    ntpServers:
    - "216.239.35.4"
  ipMode:
    type: "static"
    ipBlockFilePath: "user-ipblock.yaml"
  serviceCIDR: 10.96.0.0/20
  podCIDR: 192.168.0.0/16
  controlPlaneIPBlock:
    netmask: "255.255.255.0"
    gateway: "172.16.21.1"
    ips:
    - ip: "172.16.21.6"
      hostname: "cp-vm-1"
    - ip: "172.16.21.7"
      hostname: "cp-vm-2"
    - ip: "172.16.21.8"
      hostname: "cp-vm-3"
loadBalancer:
  vips:
    controlPlaneVIP: "172.16.21.40"
    ingressVIP: "172.16.21.30"
  kind: MetalLB
  metalLB:
    addressPools:
    - name: "address-pool-1"
      addresses:
      - "172.16.21.30-172.16.21.39"
masterNode:
  cpus: 4
  memoryMB: 8192
  replicas: 3
nodePools:
- name: "worker-node-pool"
  cpus: 4
  memoryMB: 8192
  replicas: 3
  enableLoadBalancer: true
antiAffinityGroups:
  enabled: true
gkeConnect:
  projectID: "my-project-123"
  location: "us-central1"
  registerServiceAccountKeyPath: "connect-register-sa-2203040617.json"
stackdriver:
  projectID: "my-project-123"
  clusterLocation: "us-central1"
  enableVPC: false
  serviceAccountKeyPath: "log-mon-sa-2203040617.json"
autoRepair:
  enabled: true

Estos son los puntos importantes que debes comprender en el ejemplo anterior:

Las direcciones IP estáticas para los nodos trabajadores se especifican en un archivo de bloque de IP. El archivo de bloque de IP tiene cuatro direcciones, aunque solo haya tres nodos trabajadores. La dirección IP adicional es necesaria durante la actualización, la actualización y la reparación automática del clúster.
Los servidores DNS y NTP se especifican en la sección hostConfig. En este ejemplo, estos servidores DNS y NTP son para los nodos del plano de control y los nodos trabajadores. Esto se debe a que los nodos trabajadores tienen direcciones IP estáticas. Si los nodos trabajadores obtuvieran sus direcciones IP de un servidor DHCP, estos servidores DNS y NTP serían solo para los nodos del plano de control.
Las direcciones IP estáticas para los tres nodos del plano de control se especifican en la sección network.controlPlaneIPBlock del archivo de configuración del clúster de usuario. No se necesita una dirección IP adicional en este bloque.
El plano de control V2 está habilitado.
El campo masterNode.replicas está configurado como 3, por lo que el clúster tendrá un plano de control de alta disponibilidad.
La VIP del plano de control y la VIP de entrada están en la misma VLAN que los nodos trabajadores y los del plano de control.
Las VIP que se reservan para los Services de tipo LoadBalancer se especifican en la sección loadBalancer.metalLB.addressPools del archivo de configuración del clúster de usuario. Estas VIP están en la misma VLAN que los nodos trabajadores y los nodos del plano de control. El conjunto de VIP especificado en esta sección debe incluir la VIP de entrada y no la VIP del plano de control.
El archivo de configuración del clúster de usuario no incluye una sección vCenter. Por lo tanto, el clúster de usuario usa los mismos recursos de vSphere que el clúster de administrador.

Valida tu archivo de configuración

Una vez que hayas completado el archivo de configuración de tu clúster de administrador, ejecuta gkectl check-config para verificar que el archivo sea válido:

gkectl check-config --kubeconfig ADMIN_CLUSTER_KUBECONFIG --config USER_CLUSTER_CONFIG

Reemplaza lo siguiente:

ADMIN_CLUSTER_KUBECONFIG es la ruta de acceso del archivo kubeconfig del clúster de administrador.
USER_CLUSTER_CONFIG es la ruta de acceso del archivo de configuración del clúster de usuario.

Si el comando muestra algún mensaje de error, soluciona los problemas y vuelve a validar el archivo.

Si deseas omitir las validaciones que llevan más tiempo, pasa la marca --fast. Para omitir validaciones individuales, usa las marcas --skip-validation-xxx. Para obtener más información sobre el comando check-config, consulta Ejecuta verificaciones previas.

3. Importa imágenes de SO a vSphere y envía imágenes de contenedor a un registro privado (opcional).

Ejecuta gkectl prepare si se cumple alguna de las siguientes condiciones:

El clúster de usuario está en un centro de datos de vSphere diferente al del clúster de administrador.
El clúster de usuario tiene un vCenter Server diferente al del clúster de administrador.
El clúster de usuario usa un registro de contenedores privado que es diferente del registro privado que usa el clúster de administrador.

gkectl prepare --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --bundle-path BUNDLE \
    --user-cluster-config USER_CLUSTER_CONFIG

Reemplaza lo siguiente:

ADMIN_CLUSTER_KUBECONFIG: Es la ruta de acceso del archivo kubeconfig del clúster de administrador.
BUNDLE: Es la ruta de acceso del archivo de paquete. Este archivo se encuentra en la estación de trabajo de administrador en /var/lib/gke/bundles/. Por ejemplo:
```
/var/lib/gke/bundles/gke-onprem-vsphere-1.28.400-gke.75-full.tgz
```
USER_CLUSTER_CONFIG es la ruta de acceso del archivo de configuración del clúster de usuario.

4. Crear un clúster de usuario

Crear un clúster de usuario

gkectl create cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG --config USER_CLUSTER_CONFIG

Ubica el archivo kubeconfig del clúster de usuario

El comando gkectl create cluster crea un archivo kubeconfig llamado USER_CLUSTER_NAME-kubeconfig en el directorio actual. Necesitarás este archivo kubeconfig más adelante para interactuar con tu clúster de usuario.

El archivo kubeconfig contiene el nombre del clúster de usuario. Para ver el nombre del clúster, puedes ejecutar el siguiente comando:

kubectl config get-clusters --kubeconfig USER_CLUSTER_KUBECONFIG

El resultado muestra el nombre del clúster. Por ejemplo:

NAME
my-user-cluster

Si lo deseas, puedes cambiar el nombre y la ubicación de tu archivo kubeconfig.

5. Verifica que el clúster de usuario esté en ejecución

Verifica que el clúster de usuario esté en ejecución:

kubectl get nodes --kubeconfig USER_CLUSTER_KUBECONFIG

Reemplaza USER_CLUSTER_KUBECONFIG con la ruta de tu archivo kubeconfig del clúster de usuario.

En el resultado, se muestran los nodos del clúster de usuario. Por ejemplo:

cp-vm-1       Ready    control-plane,master   18m
cp-vm-2       Ready    control-plane,master   18m
cp-vm-3       Ready    control-plane,master   18m
worker-vm-1   Ready                           6m7s
worker-vm-2   Ready                           6m6s
worker-vm-3   Ready                           6m14s

Console

Comenzar

En la consola de Google Cloud, ve a la página Crea un clúster de GKE on VMware.

Ir a Crea un clúster de GKE en VMware
Selecciona el proyecto de Google Cloud en el que deseas crear el clúster. El proyecto seleccionado también se usa como el proyecto host de la flota. Este debe ser el mismo proyecto en el que está registrado el clúster de administrador. Después de crear el clúster de usuario, se registra de forma automática en la flota del proyecto seleccionado.

Conceptos básicos del clúster

Ingresa información básica sobre el clúster.

Ingresa un Nombre para el clúster de usuarios.
En Clúster de administrador, selecciona el clúster de administrador de la lista. Si no especificaste un nombre para el clúster de administrador cuando lo creaste, el nombre se genera con el formato gke-admin-[HASH]. Si no reconoces el nombre del clúster de administrador, ejecuta el siguiente comando en tu estación de trabajo de administrador:
```
KUBECONFIG=ADMIN_CLUSTER_KUBECONFIG
kubectl get OnPremAdminCluster -n kube-system -o=jsonpath='{.items[0].metadata.name}'
```
Si no se muestra el clúster de administrador que deseas usar, consulta la sección de solución de problemas El clúster de administrador no se muestra en la lista desplegable aspectos básicos del clúster.
En el campo Ubicación de la API de GCP, selecciona la región de Google Cloud de la lista. Esta configuración especifica la región en la que se ejecutan los siguientes servicios y APIs:
- API de GKE On-Prem (gkeonprem.googleapis.com)
- Servicio de flota (gkehub.googleapis.com)
- Conectar servicio (gkeconnect.googleapis.com)
Este parámetro de configuración también controla la región en la que se almacenan los siguientes elementos:
- Los metadatos del clúster de usuario que la API de GKE On-Prem necesita para administrar el ciclo de vida del clúster
- Los datos de Cloud Logging y Cloud Monitoring de los componentes del sistema
- El registro de auditoría de administrador creado por los registros de auditoría de Cloud
El nombre, el proyecto y la ubicación del clúster juntos identifican de forma única el clúster en Google Cloud.
Selecciona la versión de GKE en VMware para tu clúster de usuario.
Como creador de clústeres, se te otorgan privilegios de administrador de clúster. De forma opcional, ingresa la dirección de correo electrónico de otro usuario que administrará el clúster en el campo Usuario administrador del clúster en la sección Autorización.

Cuando se crea el clúster, la API de GKE On-Prem aplica las políticas de control de acceso basado en funciones (RBAC) de Kubernetes al clúster para otorgarte a ti y a otros usuarios administradores la función clusterrole/cluster-admin de Kubernetes, que proporciona acceso completo a todos los recursos del clúster en todos los espacios de nombres.

Nota: Además de las políticas de RBAC de Kubernetes, debes otorgar roles de Identity and Access Management (IAM) a los usuarios que no son propietarios del proyecto. Para obtener detalles sobre cómo otorgar los roles de IAM, consulta Asigna roles necesarios.
Haz clic en Siguiente para ir a la sección Plano de control.

Plano de control

Todos los campos de la sección Plano de control se configuran con valores predeterminados. Revisa los valores predeterminados y, de manera opcional, cámbialos según sea necesario.

En el campo CPU virtuales del nodo del plano de control, ingresa la cantidad de CPU virtuales (4 como mínimo) para cada nodo del plano de control del clúster de usuario.
En el campo Memoria de nodo del plano de control, ingresa el tamaño de la memoria en MiB (8,192 como mínimo y debe ser un múltiplo de 4) de cada plano de control del clúster de usuario.
En Nodos del plano de control, selecciona la cantidad de nodos del plano de control para el clúster de usuario. Por ejemplo, puedes seleccionar 1 nodo de plano de control para un entorno de desarrollo y 3 nodos de plano de control para entornos de producción y alta disponibilidad (HA).
De forma opcional, selecciona Cambio de tamaño automático de nodos. Cambiar el tamaño significa que la CPU virtual y los recursos de memoria asignados a un nodo se ajustan automáticamente. Cuando se habilita, se cambia el tamaño de los nodos del plano de control para el clúster de usuario según la cantidad de nodos trabajadores en el clúster de usuario. Por lo tanto, a medida que agregas más nodos trabajadores al clúster de usuario, aumenta el tamaño de los nodos del plano de control.
De forma opcional, selecciona Habilitar plano de control v2. Habilitar el plano de control V2 significa que el plano de control de un clúster de usuario se ejecuta en uno o más nodos en el clúster de usuario, en lugar de hacerlo en el clúster de administrador (denominado kubeception).

Cuando seleccionas Habilitar el plano de control v2, aparece la sección IP del nodo del plano de control. Ingresa la dirección IP de la puerta de enlace, la máscara de subred y las direcciones IP de los nodos del plano de control.

Cuando el plano de control V2 está habilitado, los campos de CPU virtual y memoria se aplican a los nodos del plano de control en el clúster de usuario. La cantidad de nodos se determina por la cantidad de direcciones IP que ingreses. Cuando el plano de control V2 no está habilitado, los campos de CPU virtual, memoria y cantidad de nodos del plano de control se aplican a los nodos del clúster de administrador. Asegúrate de reservar suficientes direcciones IP para el clúster de administrador.
Haz clic en Siguiente para ir a la sección Herramientas de redes.

Redes

En esta sección, debes especificar las direcciones IP para los nodos, los Pods y los objetos Service del clúster. Un clúster de usuario debe tener una dirección IP para cada nodo y una dirección IP adicional para un nodo temporal que se necesita durante las actualizaciones del clúster, las actualizaciones y las reparaciones automáticas. Para obtener más información, consulta ¿Cuántas direcciones IP necesita un clúster de usuario?

En la sección IP de nodo, selecciona el modo de IP para el clúster de usuario. Selecciona una de las siguientes opciones:
- DHCP: Elige DHCP si deseas que los nodos del clúster obtengan la dirección IP de un servidor DHCP.
- Estática: Elige Estática si deseas proporcionar direcciones IP estáticas para los nodos del clúster o si deseas configurar el balanceo de cargas manual.
Si seleccionaste DHCP, continúa con el siguiente paso para especificar los CIDR de Pods y Services. En Modo de IP estática, proporciona la siguiente información:
1. Ingresa la dirección IP de la Puerta de enlace para el clúster de usuario.
2. Ingresa la Máscara de subred para los nodos del clúster de usuario.
3. En la sección Direcciones IP, ingresa las direcciones IP y, de forma opcional, los nombres de host para los nodos del clúster de usuario. Puedes ingresar una dirección IP v4 individual (como 192.0.2.1) o un bloque CIDR de direcciones IPv4 (como 192.0.2.0/24).
  - Si ingresas un bloque CIDR, no ingreses un nombre de host.
  - Si ingresas una dirección IP individual, puedes ingresar un nombre de host de forma opcional. Si no ingresas un nombre de host, GKE en VMware usa el nombre de la VM de vSphere como nombre de host.
4. Haz clic en + Agregar dirección IP según sea necesario para ingresar más direcciones IP.
En la sección CIDR de servicios y Pods, la consola proporciona los siguientes rangos de direcciones para tu servicio y pod de Kubernetes:
- CIDR de Service: 10.96.0.0./20
- CIDR de Pod: 192.168.0.0/16
Si prefieres ingresar tus propios rangos de direcciones, consulta Direcciones IP para pods y Service a fin de obtener prácticas recomendadas.
Si seleccionaste Modo de IP estática o Habilitar el plano de control v2, especifica la siguiente información en la sección Configuración del host:
1. Ingresa las direcciones IP de los servidores DNS.
2. Ingresa las direcciones IP de los servidores NTP.
3. También puedes ingresar los dominios de búsqueda de DNS.
Haz clic en Siguiente para ir a la sección Balanceador de cargas.

Balanceador de cargas

Elige el balanceador de cargas que deseas configurar en el clúster. Consulta la Descripción general del balanceador de cargas para obtener más información.

Selecciona el Tipo de balanceador de cargas de la lista.

Incluido con MetalLB

Configura el balanceo de cargas en paquetes con MetalLB. Puedes usar MetalLB para el clúster de usuario solo si tu clúster de administrador usa SeeSaw o MetalLB. Esta opción requiere una configuración mínima. MetalLB se ejecuta directamente en los nodos del clúster y no requiere VM adicionales. Para obtener más información sobre los beneficios de usar MetalLB y cómo se compara con las otras opciones de balanceo de cargas, consulta Balanceo de cargas en paquetes con MetalLB.

En la sección Grupos de direcciones, configura al menos un grupo de direcciones de la siguiente manera:
1. Ingresa un Nombre para el grupo de direcciones.
2. Ingresa un rango de direcciones IP que contenga la VIP de Ingress en cualquier notación CIDR (p. ej., 192.0.2.0/26) o la notación de rangos (p. ej., 192.0.2.64-192.0.2.72). Para especificar una sola dirección IP en un grupo, usa /32 en la notación CIDR (p. ej., 192.0.2.1/32).
3. Si las direcciones IP de los Services de tipo LoadBalancer no están en el mismo rango de direcciones IP que la VIP de Ingress, haz clic en + Agregar un rango de direcciones IP y, luego, ingresa otra dirección.
  
  Las direcciones IP en cada grupo no pueden superponerse y deben estar en la misma subred que los nodos del clúster.
4. En Asignación de direcciones IP, selecciona una de las siguientes opciones:
  - Automática: Elige esta opción si quieres que el controlador de MetalLB asigne de forma automática direcciones IP del grupo de direcciones a Services de tipo LoadBalancer.
  - Manual: Elige esta opción si tienes la intención de usar direcciones del grupo a fin de especificar manualmente direcciones para servicios de tipo LoadBalancer.
5. Haz clic en Evita las direcciones IP con errores si deseas que el controlador de MetalLB no use direcciones del grupo que terminan en .0 o .255. Esto evita el problema de los dispositivos consumidores con errores que descartan por error el tráfico enviado a esas direcciones IP especiales.
6. Cuando hayas terminado, haz clic en Listo.
Si es necesario, haz clic en Agregar grupo de direcciones.
En la sección IP virtuales, ingresa lo siguiente:
- VIP del plano de control: La dirección IP de destino que se usará para el tráfico enviado al servidor de la API de Kubernetes del clúster de usuario. El servidor de la API de Kubernetes para el clúster de usuario se ejecuta en un nodo en el clúster de administrador. Esta dirección IP debe estar en el mismo dominio L2 que los nodos del clúster de administrador. No agregues esta dirección en la sección Grupos de direcciones.
- VIP de Ingress: La dirección IP que se configurará en el balanceador de cargas para el proxy de Ingress. Debes agregar esto a un grupo de direcciones en la sección Grupos de direcciones.
Haz clic en Continuar.

BIG-IP de F5

Puedes usar BIG-IP de F5 para el clúster de usuario solo si el clúster de administrador usa BIG-IP de F5. Asegúrate de instalar y configurar el ADC de BIG-IP de F5 antes de integrarlo con GKE en VMware.

El nombre de usuario y la contraseña de F5 se heredan del clúster de administrador.

En la sección IP virtuales, ingresa lo siguiente:
- VIP del plano de control: La dirección IP del destino que se usará para el tráfico enviado al servidor de la API de Kubernetes.
- VIP de Ingress: La dirección IP que se configurará en el balanceador de cargas para el proxy de Ingress.
En el campo Dirección, ingresa la dirección de tu balanceador de cargas BIG-IP de F5.
En el campo Partición, ingresa el nombre de una partición de BIG-IP que creaste para el clúster de usuario.
En el campo nombre del grupo de SNAT, ingresa el nombre de tu grupo de SNAT, si corresponde.
Haz clic en Continuar.

Manual

Puedes usar un balanceador de cargas manual para el clúster de usuario solo si el clúster de administrador usa un balanceador de cargas manual. En GKE on VMware, el servidor de la API de Kubernetes y el proxy de entrada se exponen mediante un servicio de Kubernetes de tipo LoadBalancer. Elige tus propios valores de nodePort en el rango de 30,000 a 32,767 para estos servicios. En el caso del proxy de entrada, elige un valor de nodePort para el tráfico HTTP y HTTPS. Consulta Habilita el modo de balanceo de cargas manual para obtener más información.

En la sección IP virtuales, ingresa lo siguiente:
- VIP del plano de control: La dirección IP del destino que se usará para el tráfico enviado al servidor de la API de Kubernetes.
- VIP de Ingress: La dirección IP que se configurará en el balanceador de cargas para el proxy de Ingress.
En el campo Control-plan node port, ingresa un valor nodePort para el servidor de la API de Kubernetes.
En el campo Puerto del nodo HTTP de Ingress, ingresa un valor nodePort para el tráfico HTTP al proxy de Ingress.
En el campo Puerto del nodo HTTPS de Ingress, ingresa un valor nodePort para el tráfico HTTPS al proxy de Ingress.
En el campo Puerto del nodo del servidor de Konnectivity, ingresa un valor nodePort para el servidor de Konnectivity.
Haz clic en Continuar.

Funciones

En esta sección, se muestran las características y operaciones que están habilitadas en el clúster.

Los siguientes elementos se habilitan de forma automática y no se pueden inhabilitar:
- Cloud Logging de servicios del sistema
- Cloud Monitoring de servicios del sistema
- El registro de auditoría de actividad del administrador
Las siguientes opciones están habilitadas de forma predeterminada, pero puedes inhabilitarlas:
- Habilita el controlador CSI de vSphere: También se denomina complemento de almacenamiento de vSphere. El controlador de Container Storage Interface (CSI) se ejecuta en un clúster de Kubernetes implementado en vSphere para aprovisionar volúmenes persistentes en el almacenamiento de vSphere. Para obtener más información, consulta Usa el controlador de interfaz de almacenamiento de contenedores de vSphere.
- Habilita las reglas de antiafinidad: Las reglas antiafinidad de Distributed Resource Scheduler (DRS) de VMware se crean automáticamente para los nodos del clúster de usuario, lo que hace que se distribuyan en al menos 3 hosts físicos del centro de datos. Asegúrate de que el entorno de vSphere cumpla con los requisitos.
Nota: Si seguiste las instrucciones en Configura la infraestructura mínima, solo tienes un host ESXi, así que asegúrate de borrar la opción Habilitar grupos de antiafinidad.
Haz clic en Siguiente para configurar un grupo de nodos.

Grupos de nodos

El clúster se creará con al menos un grupo de nodos. Un grupo de nodos es una plantilla para un grupo de nodos trabajadores que se creó en este clúster. Para obtener más información, consulta Crea y administra grupos de nodos.

En la sección Node pool defaults, completa lo siguiente:
1. Ingresa el nombre del grupo de nodos o acepta “default-pool” como el nombre.
2. Ingresa la cantidad de vCPUs para cada nodo del grupo (4 como mínimo por trabajador del clúster de usuario).
3. Ingresa el tamaño de la memoria en mebibytes (MiB) para cada nodo del grupo (el mínimo es de 8,192 MiB por nodo trabajador del clúster de usuario y debe ser un múltiplo de 4).
4. En el campo Nodos, ingresa la cantidad de nodos del grupo (3 como mínimo). Si ingresaste direcciones IP estáticas para las IP de nodo en la sección Herramientas de redes, asegúrate de haber ingresado suficientes direcciones IP para alojar estos nodos del clúster de usuario.
5. Selecciona el tipo de imagen de SO: Ubuntu, Ubuntu Containerd o COS.
6. Ingresa el Tamaño del disco de arranque en gibibytes (GiB) (mínimo 40 GiB).
7. Si usas MetalLB como balanceador de cargas, MetalLB debe estar habilitado en al menos un grupo de nodos. Deja seleccionada la opción Usar este grupo de nodos para el balanceo de cargas de MetalLB o agrega otro grupo de nodos para usar con MetalLB.
En la sección Metadatos del grupo de nodos (opcional), si quieres agregar etiquetas y taints de Kubernetes, haz lo siguiente:
1. Haz clic en + Add Kubernetes Labels. Ingresa la Clave y el Valor de la etiqueta. Repite la acción según sea necesario.
2. Haz clic en + Agregar taint. Ingresa la Clave, el Valor y el Efecto para el taint. Repite la acción según sea necesario.
Haz clic en Verify and Complete para crear el clúster de usuario. La creación del clúster de usuario tarda 15 minutos o más. La consola muestra mensajes de estado mientras verifica la configuración y crea el clúster en tu centro de datos.

Si se produce un error cuando se verifica la configuración, la consola muestra un mensaje de error que debería ser lo suficientemente claro como para que puedas solucionar el problema de configuración y volver a intentar crear el clúster.

Para obtener más información sobre los posibles errores y cómo corregirlos, consulta Soluciona problemas relacionados con la creación de clústeres de usuario en la consola de Google Cloud.

gcloud CLI

Usa el siguiente comando para crear un clúster de usuario:

gcloud container vmware clusters create

Después de crear el clúster, debes crear al menos un grupo de nodos con el siguiente comando:

gcloud container vmware node-pools create

La mayoría de las marcas para crear el clúster y el grupo de nodos corresponden a los campos del archivo de configuración del clúster de usuario. Para ayudarte a comenzar, puedes probar un comando completo en la sección Ejemplos.

Antes de comenzar

Obtén el nombre y la ubicación de la membresía de la flota del clúster de administrador:
```
gcloud container fleet memberships list \
    --project=FLEET_HOST_PROJECT_ID
```
Reemplaza FLEET_HOST_PROJECT_ID por el ID del proyecto en el que está registrado el clúster de administrador.

El resultado es similar al siguiente:
```
NAME             EXTERNAL_ID                           LOCATION
admin-cluster-1  bb7803b4-8438-4b22-859f-4559b4b29072  global
admin-cluster-2  ee16ee2b-6ec0-49fc-9413-3c89cbc70854  global
admin-cluster-3  fc2b7ef5-39ff-4b63-b919-04c5adc67be4  us-west1
```
La ubicación especifica dónde se ejecutan los servicios Fleet y Connect. Los clústeres de administrador creados antes de la versión 1.28 se administran con los servicios globales Fleet y Connect. En la versión 1.28 y en versiones posteriores, puedes especificar global o una región de Google Cloud cuando creas el clúster de administrador. Especifica la región en la marca --admin-cluster-membership-location en los comandos de ejemplo que siguen.
Obtén una lista de las versiones disponibles:
```
gcloud container vmware clusters query-version-config \
    --admin-cluster-membership=ADMIN_CLUSTER_NAME \
    --admin-cluster-membership-project=FLEET_HOST_PROJECT_ID \
    --admin-cluster-membership-location=ADMIN_CLUSTER_REGION \
    --location=REGION
```
Reemplaza lo siguiente:
- ADMIN_CLUSTER_NAME: Es el nombre del clúster de administrador.
- FLEET_HOST_PROJECT_ID: El ID del proyecto en el que está registrado el clúster de administrador
- ADMIN_CLUSTER_REGION: La región de membresía de la flota del clúster de administrador Puede ser una región global o de Google Cloud. Usa la ubicación del clúster de administrador del resultado de gcloud container fleet memberships list.
- REGION: Es la región de Google Cloud que usarás cuando crees el clúster. Esta es la región en la que se ejecutan la API de GKE On-Prem y los servicios Fleet y Connect. Especifica us-west1 o alguna otra región compatible.
El resultado del comando es similar al siguiente:
```
versions:
- isInstalled: true
  version: 1.14.3-gke.25
- version: 1.14.4-gke.54
- version: 1.15.0-gke.581
```
Las versiones que puedes usar para crear un clúster de usuario tienen anotaciones con isInstalled=true, lo que significa que el clúster de administrador tiene los componentes específicos de la versión que necesita para administrar los clústeres de usuario de esa versión. Si deseas crear un clúster de usuario con otra versión disponible, consulta Instala una versión posterior a la versión del clúster de administrador.

Ejemplos

En los siguientes ejemplos, se muestra cómo crear un clúster de usuario con diferentes balanceadores de cargas. Para obtener información sobre las opciones de balanceo de cargas disponibles, consulta Descripción general del balanceador de cargas.

En los ejemplos, se usan los valores predeterminados para configurar los nodos del plano de control. Si deseas cambiar alguno de los valores predeterminados, incluye las marcas que se describen en la sección Marcas del plano de control. Si es necesario, también puedes cambiar algunos parámetros de configuración de vSphere.

Después de que el clúster se ejecuta, debes agregar un grupo de nodos antes de implementar las cargas de trabajo, como se describe en la sección Crea un grupo de nodos.

MetalLB y DHCP

En este ejemplo, se muestra cómo crear un clúster de usuario con el balanceador de cargas en paquetes de MetalLB y cómo usar tu servidor DHCP para obtener direcciones IP para los nodos del clúster.

Puedes usar MetalLB para el clúster de usuario solo si tu clúster de administrador usa SeeSaw o MetalLB. Esta opción de balanceo de cargas requiere una configuración mínima. MetalLB se ejecuta directamente en los nodos de tu clúster y no requiere VM adicionales. Para obtener más información sobre los beneficios de usar MetalLB y cómo se compara con las otras opciones de balanceo de cargas, consulta Balanceo de cargas en paquetes con MetalLB.

gcloud container vmware clusters create USER_CLUSTER_NAME \
    --project=FLEET_HOST_PROJECT_ID \
    --admin-cluster-membership=ADMIN_CLUSTER_NAME \
    --admin-cluster-membership-project=FLEET_HOST_PROJECT_ID \
    --admin-cluster-membership-location=ADMIN_CLUSTER_REGION \
    --location=REGION \
    --version=VERSION \
    --admin-users=YOUR_EMAIL_ADDRESS \
    --admin-users=ANOTHER_EMAIL_ADDRESS \
    --service-address-cidr-blocks=SERVICE_CIDR_BLOCK \
    --pod-address-cidr-blocks=POD_CIDR_BLOCK \
    --metal-lb-config-address-pools='pool=NAME,avoid-buggy-ips=True|False,manual-assign=True|False,addresses=IP_ADDRESS_RANGE_1;IP_ADDRESS_RANGE_2;...' \
    --control-plane-vip=CONTROL_PLANE_VIP \
    --ingress-vip=INGRESS_VIP \
    --enable-dhcp

Reemplaza lo siguiente:

USER_CLUSTER_NAME: Es el nombre que elijas para el clúster de usuario. No se puede cambiar el nombre después de crear el clúster. El nombre debe cumplir con los siguientes requisitos:
- Contener 40 caracteres como máximo.
- Contener solo caracteres alfanuméricos en minúscula o un guiones (-).
- Comenzar con un carácter alfabético
- Terminar con un carácter alfanumérico
FLEET_HOST_PROJECT_ID: El ID del proyecto en el que deseas crear el clúster. El proyecto especificado también se usa como el proyecto host de la flota. Debe ser el mismo proyecto en el que está registrado el clúster de administrador. Después de crear el clúster de usuario, se registra automáticamente en la flota del proyecto seleccionado. El proyecto host de la flota no se puede cambiar después de que se crea el clúster.
ADMIN_CLUSTER_NAME: Es el nombre del clúster de administrador que gestiona el clúster de usuario. En la marca --admin-cluster-membership, puedes usar el nombre del clúster especificado por completo, que tiene el siguiente formato:
```
    projects/FLEET_HOST_PROJECT_ID/locations/ADMIN_CLUSTER_REGION/memberships/ADMIN_CLUSTER_NAME
```
De forma alternativa, puedes establecer --admin-cluster-membership en el nombre del clúster de administrador, como en el comando de ejemplo. Cuando usas solo el nombre del clúster de administrador, configura el ID del proyecto del clúster de administrador con --admin-cluster-membership-project y la ubicación con --admin-cluster-membership-location. La ubicación del clúster de administrador es global o una región de Google Cloud. Si necesitas encontrar la región, ejecuta gcloud container fleet memberships list.
REGION: Es la región de Google Cloud en la que se ejecutan la API de GKE On-Prem (gkeonprem.googleapis.com), el servicio de flota (gkehub.googleapis.com) y el servicio Connect (gkeconnect.googleapis.com). Especifica us-west1 o alguna otra región compatible. No se puede cambiar la región después de crear el clúster. Este parámetro de configuración especifica la región en la que se almacenan los siguientes elementos:
- Los metadatos del clúster de usuario que necesita la API de GKE On-Prem para administrar el ciclo de vida del clúster
- Los datos de Cloud Logging y Cloud Monitoring de los componentes del sistema
- El registro de auditoría de administrador creado por los registros de auditoría de Cloud
El nombre, el proyecto y la ubicación del clúster en conjunto identifican de forma única el clúster en Google Cloud.

Importante: Si planeas instalar Anthos Service Mesh, debes instalar la versión 1.19.3 o posterior. Esto es necesario porque los servicios Fleet y Connect se ejecutan en una región.
VERSION: Es la versión de GKE en VMware para el clúster de usuario.
YOUR_EMAIL_ADDRESS y ANOTHER_EMAIL_ADDRESS: Si no incluyes la marca --admin-users, como creador del clúster, se te otorgarán privilegios de administrador de clúster de forma predeterminada. Sin embargo, si incluyes --admin-users para designar a otro usuario como administrador, anulas el valor predeterminado y debes incluir tu dirección de correo electrónico y la del otro administrador. Por ejemplo, para agregar dos administradores:
```
    --admin-users=sara@example.com \
    --admin-users=amal@example.com
```
.
Cuando se crea el clúster, la API de GKE On-Prem aplica las políticas de control de acceso basado en roles (RBAC) de Kubernetes al clúster para otorgarte a ti y a otros usuarios administradores el rol clusterrole/cluster-admin de Kubernetes, que proporciona acceso completo a todos los recursos del clúster en todos los espacios de nombres.

Nota: Además de las políticas de RBAC de Kubernetes, debes otorgar algunos roles de Identity and Access Management (IAM) a los usuarios que no son propietarios del proyecto. Para obtener detalles sobre cómo otorgar los roles de IAM, consulta Otorga los roles necesarios.

SERVICE_CIDR_BLOCK: Es un rango de direcciones IP, en formato CIDR, que se usará para los servicios del clúster. Debe ser al menos un rango de /24.
Ejemplo: --service-address-cidr-blocks=10.96.0.0/20
POD_CIDR_BLOCK: Es un rango de direcciones IP, en formato CIDR, que se usará para los Pods del clúster. Debe ser al menos un rango /18.
Ejemplo: --pod-address-cidr-blocks=192.168.0.0/16

--metal-lb-config-address-pools: Incluye esta marca para especificar la configuración de los grupos de direcciones que usará el balanceador de cargas de MetalLB. El valor de la marca tiene el siguiente formato:
```
--metal-lb-config-address-pool 'pool=NAME,avoid-buggy-ips=True|False,manual-assign=True|False,addresses=IP_ADDRESS_RANGE_1;IP_ADDRESS_RANGE_2;...' \
```
El valor tiene segmentos que comienzan con las palabras clave pool, avoid-buggy-ip, manual-assign y addresses. Separa cada segmento con una coma.
- pool: Es un nombre que elijas para el grupo.
- avoid-buggy-ips1: Si estableces esto como True, el controlador de MetalLB no asignará las direcciones IP que terminen en .0 o .255 a los servicios. De esta forma, se evita el problema de que los dispositivos de consumidores con errores dejen de enviar por error el tráfico enviado a esas direcciones IP especiales. Si no se especifica, el valor predeterminado es False.
- manual-assign: Si no quieres que el controlador de MetalLB asigne de forma automática las direcciones IP de este grupo a los servicios, establece esto en True. Luego, un desarrollador puede crear un Service de tipo LoadBalancer y especificar de forma manual una de las direcciones del grupo. Si no se especifica, manual-assign se establece en False.
- En la lista de addresses: Cada dirección debe ser un rango en notación CIDR o en formato de rango con guion. Si quieres especificar una sola dirección IP en un grupo (como para la VIP de entrada), usa /32 en la notación CIDR, por ejemplo: 192.0.2.1/32.
Ten en cuenta lo siguiente:
- Encierra todo el valor entre comillas simples.
- No se permiten los espacios en blanco.
- Separa cada rango de direcciones IP con un punto y coma.
Por ejemplo:
```
--metal-lb-config-address-pool 'pool=pool1,avoid-buggy-ips=True,manual-assign=True,addresses=10.251.134.80/32;192.168.1.0/26;192.168.1.2-192.168.1.3'
```

CONTROL_PLANE_VIP: La dirección IP que elegiste configurar en el balanceador de cargas para el servidor de la API de Kubernetes del clúster de usuario.
Ejemplo: --control-plane-vip=203.0.113.3
INGRESS_VIP: La dirección IP que elegiste configurar en el balanceador de cargas para el proxy de entrada.
Ejemplo: --ingress-vip=10.251.134.80

La dirección IP para la VIP de entrada debe estar en uno de los grupos de direcciones de MetalLB.

--enable-dhcp: Incluye --enable-dhcp si deseas que los nodos del clúster obtengan su dirección IP desde un servidor DHCP que proporciones. No incluyas esta marca si quieres proporcionar direcciones IP estáticas para los nodos del clúster o si deseas configurar el balanceo de cargas manual.

IP estáticas y MetalLB

En este ejemplo, se muestra cómo crear un clúster de usuario con el balanceador de cargas en paquetes de MetalLB y cómo asignar direcciones IP estáticas a los nodos del clúster.

Asegúrate de desplazarte si es necesario para completar el marcador de posición ADMIN_CLUSTER_NAME para la marca --admin-cluster-membership. En este ejemplo, se usa el nombre del clúster de administrador especificado por completo, por lo que no necesitas incluir --admin-cluster-membership-location ni --admin-cluster-membership-project.

gcloud container vmware clusters create USER_CLUSTER_NAME \
    --project=FLEET_HOST_PROJECT_ID \
    --admin-cluster-membership=ADMIN_CLUSTER_NAME \
    --admin-cluster-membership-project=FLEET_HOST_PROJECT_ID \
    --admin-cluster-membership-location=ADMIN_CLUSTER_REGION \
    --location=REGION \
    --version=VERSION \
    --admin-users=YOUR_EMAIL_ADDRESS \
    --admin-users=ANOTHER_EMAIL_ADDRESS \
    --service-address-cidr-blocks=SERVICE_CIDR_BLOCK \
    --pod-address-cidr-blocks=POD_CIDR_BLOCK \
    --metal-lb-config-address-pools='pool=NAME,avoid-buggy-ips=True|False,manual-assign=True|False,addresses=IP_ADDRESS_RANGE_1;IP_ADDRESS_RANGE_2;...' \
    --control-plane-vip=CONTROL_PLANE_VIP \
    --ingress-vip=INGRESS_VIP \
    --static-ip-config-ip-blocks='gateway=GATEWAY,netmask=NETMASK,ips=IP_ADDRESS_1;IP_ADDRESS_2 HOST_2;...' \
    --dns-servers=DNS_SERVER,... \
    --dns-search-domains=DNS_SEARCH_DOMAIN,... \
    --ntp-servers=NTP_SERVER,...

Reemplaza lo siguiente:

USER_CLUSTER_NAME: Es el nombre que elijas para el clúster de usuario. No se puede cambiar el nombre después de crear el clúster. El nombre debe cumplir con los siguientes requisitos:
- Contener 40 caracteres como máximo.
- Contener solo caracteres alfanuméricos en minúscula o un guiones (-).
- Comenzar con un carácter alfabético
- Terminar con un carácter alfanumérico
FLEET_HOST_PROJECT_ID: El ID del proyecto en el que deseas crear el clúster. El proyecto especificado también se usa como el proyecto host de la flota. Debe ser el mismo proyecto en el que está registrado el clúster de administrador. Después de crear el clúster de usuario, se registra automáticamente en la flota del proyecto seleccionado. El proyecto host de la flota no se puede cambiar después de que se crea el clúster.
ADMIN_CLUSTER_NAME: Es el nombre del clúster de administrador que gestiona el clúster de usuario. En la marca --admin-cluster-membership, puedes usar el nombre del clúster especificado por completo, que tiene el siguiente formato:
```
    projects/FLEET_HOST_PROJECT_ID/locations/ADMIN_CLUSTER_REGION/memberships/ADMIN_CLUSTER_NAME
```
De forma alternativa, puedes establecer --admin-cluster-membership en el nombre del clúster de administrador, como en el comando de ejemplo. Cuando usas solo el nombre del clúster de administrador, configura el ID del proyecto del clúster de administrador con --admin-cluster-membership-project y la ubicación con --admin-cluster-membership-location. La ubicación del clúster de administrador es global o una región de Google Cloud. Si necesitas encontrar la región, ejecuta gcloud container fleet memberships list.
REGION: Es la región de Google Cloud en la que se ejecutan la API de GKE On-Prem (gkeonprem.googleapis.com), el servicio de flota (gkehub.googleapis.com) y el servicio Connect (gkeconnect.googleapis.com). Especifica us-west1 o alguna otra región compatible. No se puede cambiar la región después de crear el clúster. Este parámetro de configuración especifica la región en la que se almacenan los siguientes elementos:
- Los metadatos del clúster de usuario que necesita la API de GKE On-Prem para administrar el ciclo de vida del clúster
- Los datos de Cloud Logging y Cloud Monitoring de los componentes del sistema
- El registro de auditoría de administrador creado por los registros de auditoría de Cloud
El nombre, el proyecto y la ubicación del clúster en conjunto identifican de forma única el clúster en Google Cloud.

Importante: Si planeas instalar Anthos Service Mesh, debes instalar la versión 1.19.3 o posterior. Esto es necesario porque los servicios Fleet y Connect se ejecutan en una región.
VERSION: Es la versión de GKE en VMware para el clúster de usuario.
YOUR_EMAIL_ADDRESS y ANOTHER_EMAIL_ADDRESS: Si no incluyes la marca --admin-users, como creador del clúster, se te otorgarán privilegios de administrador de clúster de forma predeterminada. Sin embargo, si incluyes --admin-users para designar a otro usuario como administrador, anulas el valor predeterminado y debes incluir tu dirección de correo electrónico y la del otro administrador. Por ejemplo, para agregar dos administradores:
```
    --admin-users=sara@example.com \
    --admin-users=amal@example.com
```
.
Cuando se crea el clúster, la API de GKE On-Prem aplica las políticas de control de acceso basado en roles (RBAC) de Kubernetes al clúster para otorgarte a ti y a otros usuarios administradores el rol clusterrole/cluster-admin de Kubernetes, que proporciona acceso completo a todos los recursos del clúster en todos los espacios de nombres.

Nota: Además de las políticas de RBAC de Kubernetes, debes otorgar algunos roles de Identity and Access Management (IAM) a los usuarios que no son propietarios del proyecto. Para obtener detalles sobre cómo otorgar los roles de IAM, consulta Otorga los roles necesarios.

SERVICE_CIDR_BLOCK: Es un rango de direcciones IP, en formato CIDR, que se usará para los servicios del clúster. Debe ser al menos un rango de /24.
Ejemplo: --service-address-cidr-blocks=10.96.0.0/20
POD_CIDR_BLOCK: Es un rango de direcciones IP, en formato CIDR, que se usará para los Pods del clúster. Debe ser al menos un rango /18.
Ejemplo: --pod-address-cidr-blocks=192.168.0.0/16

--metal-lb-config-address-pools: Incluye esta marca para especificar la configuración de los grupos de direcciones que usará el balanceador de cargas de MetalLB. El valor de la marca tiene el siguiente formato:
```
--metal-lb-config-address-pool 'pool=NAME,avoid-buggy-ips=True|False,manual-assign=True|False,addresses=IP_ADDRESS_RANGE_1;IP_ADDRESS_RANGE_2;...' \
```
El valor tiene segmentos que comienzan con las palabras clave pool, avoid-buggy-ip, manual-assign y addresses. Separa cada segmento con una coma.
- pool: Es un nombre que elijas para el grupo.
- avoid-buggy-ips1: Si estableces esto como True, el controlador de MetalLB no asignará las direcciones IP que terminen en .0 o .255 a los servicios. De esta forma, se evita el problema de que los dispositivos de consumidores con errores dejen de enviar por error el tráfico enviado a esas direcciones IP especiales. Si no se especifica, el valor predeterminado es False.
- manual-assign: Si no quieres que el controlador de MetalLB asigne de forma automática las direcciones IP de este grupo a los servicios, establece esto en True. Luego, un desarrollador puede crear un Service de tipo LoadBalancer y especificar de forma manual una de las direcciones del grupo. Si no se especifica, manual-assign se establece en False.
- En la lista de addresses: Cada dirección debe ser un rango en notación CIDR o en formato de rango con guion. Si quieres especificar una sola dirección IP en un grupo (como para la VIP de entrada), usa /32 en la notación CIDR, por ejemplo: 192.0.2.1/32.
Ten en cuenta lo siguiente:
- Encierra todo el valor entre comillas simples.
- No se permiten los espacios en blanco.
- Separa cada rango de direcciones IP con un punto y coma.
Por ejemplo:
```
--metal-lb-config-address-pool 'pool=pool1,avoid-buggy-ips=True,manual-assign=True,addresses=10.251.134.80/32;192.168.1.0/26;192.168.1.2-192.168.1.3'
```

CONTROL_PLANE_VIP: La dirección IP que elegiste configurar en el balanceador de cargas para el servidor de la API de Kubernetes del clúster de usuario.
Ejemplo: --control-plane-vip=203.0.113.3
INGRESS_VIP: La dirección IP que elegiste configurar en el balanceador de cargas para el proxy de entrada.
Ejemplo: --ingress-vip=10.251.134.80

La dirección IP para la VIP de entrada debe estar en uno de los grupos de direcciones de MetalLB.

--static-ip-config-ip-blocks: Especifica la puerta de enlace predeterminada, la máscara de subred y una lista de las direcciones IP estáticas para los nodos trabajadores en el clúster de usuario. El valor de la marca tiene el siguiente formato:
```
--static-ip-config-ip-blocks 'gateway=GATEWAY,netmask=NETMASK,ips=IP_ADDRESS_1;IP_ADDRESS_2 HOST_2;...'
```
El valor tiene segmentos que comienzan con las palabras clave gateway, netmask y ips. Separa los segmentos con una coma.

Ten en cuenta lo siguiente:
- Encierra todo el valor entre comillas simples.
- No se permiten espacios en blanco, excepto entre una dirección IP y un nombre de host.
En la lista de direcciones IP, sigue estos pasos:
- Puedes especificar una dirección IP individual o un bloque CIDR de direcciones IP.
- Separa cada dirección IP o bloque de CIDR con un punto y coma.
- Para una dirección IP individual, tienes la opción de especificar un nombre de host después de la dirección IP. Separa la dirección IP y el nombre de host con un espacio. Cuando no especificas un nombre de host, GKE on VMware usa el nombre de la VM de vSphere como nombre de host.
- Si especificas un bloque CIDR, no especifiques un valor para el nombre de host.
Por ejemplo:
```
--static-ip-config-ip-blocks 'gateway=172.16.23.254,netmask=255.255.252.0,ips=172.16.20.10;172.16.20.11 host2;172.16.20.12/30'
```
DNS_SERVER: Es una lista separada por comas de las direcciones IP de los servidores DNS para las VM.
DNS_SEARCH_DOMAIN: Es una lista separada por comas de los dominios de búsqueda de DNS que usarán los hosts. Estos dominios se usan como parte de una lista de búsqueda de dominios.
Por ejemplo:
```
--dns-search-domains example.com,examplepetstore.com
```
NTP_SERVER: Es una lista separada por comas de las direcciones IP de los servidores de tiempo para que usen las VM.

BIG-IP y DHCP de F5

En este ejemplo, se muestra cómo crear un clúster de usuario con el balanceador de cargas BIG-IP de F5 y usar el servidor DHCP con el fin de obtener direcciones IP para los nodos del clúster.

Puedes usar F5 para el clúster de usuario solo si el clúster de administrador usa F5. Asegúrate de instalar y configurar el ADC de BIG-IP de F5 antes de integrarlo con GKE en VMware.

gcloud container vmware clusters create USER_CLUSTER_NAME \
    --project=FLEET_HOST_PROJECT_ID \
    --admin-cluster-membership=ADMIN_CLUSTER_NAME \
    --admin-cluster-membership-project=FLEET_HOST_PROJECT_ID \
    --admin-cluster-membership-location=ADMIN_CLUSTER_REGION \
    --location=REGION \
    --version=VERSION \
    --admin-users=YOUR_EMAIL_ADDRESS \
    --admin-users=ANOTHER_EMAIL_ADDRESS \
    --service-address-cidr-blocks=SERVICE_CIDR_BLOCK \
    --pod-address-cidr-blocks=POD_CIDR_BLOCK \
    --f5-config-address=F5_CONFIG_ADDRESS \
    --f5-config-partition=F5_CONFIG_PARTITION \
    --f5-config-snat-pool=F5_CONFIG_SNAT_POOL \
    --control-plane-vipCONTROL_PLANE_VIP \
    --ingress-vip=INGRESS_VIP \
    --enable-dhcp

USER_CLUSTER_NAME: Es el nombre que elijas para el clúster de usuario. No se puede cambiar el nombre después de crear el clúster. El nombre debe cumplir con los siguientes requisitos:
- Contener 40 caracteres como máximo.
- Contener solo caracteres alfanuméricos en minúscula o un guiones (-).
- Comenzar con un carácter alfabético
- Terminar con un carácter alfanumérico
FLEET_HOST_PROJECT_ID: El ID del proyecto en el que deseas crear el clúster. El proyecto especificado también se usa como el proyecto host de la flota. Debe ser el mismo proyecto en el que está registrado el clúster de administrador. Después de crear el clúster de usuario, se registra automáticamente en la flota del proyecto seleccionado. El proyecto host de la flota no se puede cambiar después de que se crea el clúster.
ADMIN_CLUSTER_NAME: Es el nombre del clúster de administrador que gestiona el clúster de usuario. En la marca --admin-cluster-membership, puedes usar el nombre del clúster especificado por completo, que tiene el siguiente formato:
```
    projects/FLEET_HOST_PROJECT_ID/locations/ADMIN_CLUSTER_REGION/memberships/ADMIN_CLUSTER_NAME
```
De forma alternativa, puedes establecer --admin-cluster-membership en el nombre del clúster de administrador, como en el comando de ejemplo. Cuando usas solo el nombre del clúster de administrador, configura el ID del proyecto del clúster de administrador con --admin-cluster-membership-project y la ubicación con --admin-cluster-membership-location. La ubicación del clúster de administrador es global o una región de Google Cloud. Si necesitas encontrar la región, ejecuta gcloud container fleet memberships list.
REGION: Es la región de Google Cloud en la que se ejecutan la API de GKE On-Prem (gkeonprem.googleapis.com), el servicio de flota (gkehub.googleapis.com) y el servicio Connect (gkeconnect.googleapis.com). Especifica us-west1 o alguna otra región compatible. No se puede cambiar la región después de crear el clúster. Este parámetro de configuración especifica la región en la que se almacenan los siguientes elementos:
- Los metadatos del clúster de usuario que necesita la API de GKE On-Prem para administrar el ciclo de vida del clúster
- Los datos de Cloud Logging y Cloud Monitoring de los componentes del sistema
- El registro de auditoría de administrador creado por los registros de auditoría de Cloud
El nombre, el proyecto y la ubicación del clúster en conjunto identifican de forma única el clúster en Google Cloud.

Importante: Si planeas instalar Anthos Service Mesh, debes instalar la versión 1.19.3 o posterior. Esto es necesario porque los servicios Fleet y Connect se ejecutan en una región.
VERSION: Es la versión de GKE en VMware para el clúster de usuario.
YOUR_EMAIL_ADDRESS y ANOTHER_EMAIL_ADDRESS: Si no incluyes la marca --admin-users, como creador del clúster, se te otorgarán privilegios de administrador de clúster de forma predeterminada. Sin embargo, si incluyes --admin-users para designar a otro usuario como administrador, anulas el valor predeterminado y debes incluir tu dirección de correo electrónico y la del otro administrador. Por ejemplo, para agregar dos administradores:
```
    --admin-users=sara@example.com \
    --admin-users=amal@example.com
```
.
Cuando se crea el clúster, la API de GKE On-Prem aplica las políticas de control de acceso basado en roles (RBAC) de Kubernetes al clúster para otorgarte a ti y a otros usuarios administradores el rol clusterrole/cluster-admin de Kubernetes, que proporciona acceso completo a todos los recursos del clúster en todos los espacios de nombres.

Nota: Además de las políticas de RBAC de Kubernetes, debes otorgar algunos roles de Identity and Access Management (IAM) a los usuarios que no son propietarios del proyecto. Para obtener detalles sobre cómo otorgar los roles de IAM, consulta Otorga los roles necesarios.

SERVICE_CIDR_BLOCK: Es un rango de direcciones IP, en formato CIDR, que se usará para los servicios del clúster. Debe ser al menos un rango de /24.
Ejemplo: --service-address-cidr-blocks=10.96.0.0/20
POD_CIDR_BLOCK: Es un rango de direcciones IP, en formato CIDR, que se usará para los Pods del clúster. Debe ser al menos un rango /18.
Ejemplo: --pod-address-cidr-blocks=192.168.0.0/16

F5_CONFIG_ADDRESS: Es la dirección del balanceador de cargas de BIG-IP de F5.
F5_CONFIG_PARTITION:Es el nombre de una partición de BIG-IP que creaste para el clúster de usuario.
F5_CONFIG_SNAT_POOL: Es el nombre del grupo de SNAT, si corresponde.

CONTROL_PLANE_VIP: La dirección IP que elegiste configurar en el balanceador de cargas para el servidor de la API de Kubernetes del clúster de usuario.
Ejemplo: --control-plane-vip=203.0.113.3
INGRESS_VIP: La dirección IP que elegiste configurar en el balanceador de cargas para el proxy de entrada.
Ejemplo: --ingress-vip=10.251.134.80

La dirección IP para la VIP de entrada debe estar en uno de los grupos de direcciones de MetalLB.

--enable-dhcp: Incluye --enable-dhcp si deseas que los nodos del clúster obtengan su dirección IP desde un servidor DHCP que proporciones. No incluyas esta marca si quieres proporcionar direcciones IP estáticas para los nodos del clúster o si deseas configurar el balanceo de cargas manual.

Balanceador de cargas manual e IP estáticas

En este ejemplo, se muestra cómo crear un clúster de usuario con un balanceador de cargas manual y asignar direcciones IP estáticas a los nodos del clúster.

Puedes usar un balanceador de cargas manual para el clúster de usuario solo si el clúster de administrador usa un balanceador de cargas manual. En GKE on VMware, el servidor de la API de Kubernetes, el proxy de entrada y el servicio de complementos para la agregación de registros se exponen mediante un servicio de Kubernetes de tipo LoadBalancer. Elige tus propios valores de nodePort en el rango de 30,000 a 32,767 para estos servicios. En el caso del proxy de entrada, elige un valor de nodePort para el tráfico HTTP y HTTPS. Consulta Habilita el modo de balanceo de cargas manual para obtener más información.

gcloud container vmware clusters create USER_CLUSTER_NAME \
    --project=FLEET_HOST_PROJECT_ID \
    --admin-cluster-membership=ADMIN_CLUSTER_NAME \
    --admin-cluster-membership-project=FLEET_HOST_PROJECT_ID \
    --admin-cluster-membership-location=ADMIN_CLUSTER_REGION \
    --location=REGION \
    --version=VERSION \
    --admin-users=YOUR_EMAIL_ADDRESS \
    --admin-users=ANOTHER_EMAIL_ADDRESS \
    --service-address-cidr-blocks=SERVICE_CIDR_BLOCK \
    --pod-address-cidr-blocks=POD_CIDR_BLOCK \
    --control-plane-vip=CONTROL_PLANE_VIP \
    --control-plane-node-port=CONTROL_PLANE_NODE_PORT \
    --ingress-vip=INGRESS_VIP \
    --ingress-http-node-port=INGRESS_HTTP_NODE_PORT \
    --ingress-https-node-port=INGRESS_HTTPS_NODE_PORT \
    --konnectivity-server-node-port=KONNECTIVITY_SERVER_NODE_PORT

Reemplaza lo siguiente:

USER_CLUSTER_NAME: Es el nombre que elijas para el clúster de usuario. No se puede cambiar el nombre después de crear el clúster. El nombre debe cumplir con los siguientes requisitos:
- Contener 40 caracteres como máximo.
- Contener solo caracteres alfanuméricos en minúscula o un guiones (-).
- Comenzar con un carácter alfabético
- Terminar con un carácter alfanumérico
FLEET_HOST_PROJECT_ID: El ID del proyecto en el que deseas crear el clúster. El proyecto especificado también se usa como el proyecto host de la flota. Debe ser el mismo proyecto en el que está registrado el clúster de administrador. Después de crear el clúster de usuario, se registra automáticamente en la flota del proyecto seleccionado. El proyecto host de la flota no se puede cambiar después de que se crea el clúster.
ADMIN_CLUSTER_NAME: Es el nombre del clúster de administrador que gestiona el clúster de usuario. En la marca --admin-cluster-membership, puedes usar el nombre del clúster especificado por completo, que tiene el siguiente formato:
```
    projects/FLEET_HOST_PROJECT_ID/locations/ADMIN_CLUSTER_REGION/memberships/ADMIN_CLUSTER_NAME
```
De forma alternativa, puedes establecer --admin-cluster-membership en el nombre del clúster de administrador, como en el comando de ejemplo. Cuando usas solo el nombre del clúster de administrador, configura el ID del proyecto del clúster de administrador con --admin-cluster-membership-project y la ubicación con --admin-cluster-membership-location. La ubicación del clúster de administrador es global o una región de Google Cloud. Si necesitas encontrar la región, ejecuta gcloud container fleet memberships list.
REGION: Es la región de Google Cloud en la que se ejecutan la API de GKE On-Prem (gkeonprem.googleapis.com), el servicio de flota (gkehub.googleapis.com) y el servicio Connect (gkeconnect.googleapis.com). Especifica us-west1 o alguna otra región compatible. No se puede cambiar la región después de crear el clúster. Este parámetro de configuración especifica la región en la que se almacenan los siguientes elementos:
- Los metadatos del clúster de usuario que necesita la API de GKE On-Prem para administrar el ciclo de vida del clúster
- Los datos de Cloud Logging y Cloud Monitoring de los componentes del sistema
- El registro de auditoría de administrador creado por los registros de auditoría de Cloud
El nombre, el proyecto y la ubicación del clúster en conjunto identifican de forma única el clúster en Google Cloud.

Importante: Si planeas instalar Anthos Service Mesh, debes instalar la versión 1.19.3 o posterior. Esto es necesario porque los servicios Fleet y Connect se ejecutan en una región.
VERSION: Es la versión de GKE en VMware para el clúster de usuario.
YOUR_EMAIL_ADDRESS y ANOTHER_EMAIL_ADDRESS: Si no incluyes la marca --admin-users, como creador del clúster, se te otorgarán privilegios de administrador de clúster de forma predeterminada. Sin embargo, si incluyes --admin-users para designar a otro usuario como administrador, anulas el valor predeterminado y debes incluir tu dirección de correo electrónico y la del otro administrador. Por ejemplo, para agregar dos administradores:
```
    --admin-users=sara@example.com \
    --admin-users=amal@example.com
```
.
Cuando se crea el clúster, la API de GKE On-Prem aplica las políticas de control de acceso basado en roles (RBAC) de Kubernetes al clúster para otorgarte a ti y a otros usuarios administradores el rol clusterrole/cluster-admin de Kubernetes, que proporciona acceso completo a todos los recursos del clúster en todos los espacios de nombres.

Nota: Además de las políticas de RBAC de Kubernetes, debes otorgar algunos roles de Identity and Access Management (IAM) a los usuarios que no son propietarios del proyecto. Para obtener detalles sobre cómo otorgar los roles de IAM, consulta Otorga los roles necesarios.

SERVICE_CIDR_BLOCK: Es un rango de direcciones IP, en formato CIDR, que se usará para los servicios del clúster. Debe ser al menos un rango de /24.
Ejemplo: --service-address-cidr-blocks=10.96.0.0/20
POD_CIDR_BLOCK: Es un rango de direcciones IP, en formato CIDR, que se usará para los Pods del clúster. Debe ser al menos un rango /18.
Ejemplo: --pod-address-cidr-blocks=192.168.0.0/16

CONTROL_PLANE_VIP: La dirección IP que elegiste configurar en el balanceador de cargas para el servidor de la API de Kubernetes del clúster de usuario.

Ejemplo: --control-plane-vip=203.0.113.3
CONTROL_PLANE_NODE_PORT: Es un valor nodePort para el servidor de la API de Kubernetes.
INGRESS_VIP: La dirección IP que elegiste configurar en el balanceador de cargas para el proxy de entrada

Ejemplo: --ingress-vip=203.0.113.4
INGRESS_HTTP_NODE_PORT: Es un valor nodePort para el tráfico HTTP al proxy de entrada.
INGRESS_HTTPS_NODE_PORT: Es un valor nodePort para el tráfico HTTPS al proxy de entrada.
KONNECTIVITY_SERVER_NODE_PORT: Un valor nodePort para el servidor de Konnectivity.

--static-ip-config-ip-blocks: Especifica la puerta de enlace predeterminada, la máscara de subred y una lista de las direcciones IP estáticas para los nodos trabajadores en el clúster de usuario. El valor de la marca tiene el siguiente formato:
```
--static-ip-config-ip-blocks 'gateway=GATEWAY,netmask=NETMASK,ips=IP_ADDRESS_1;IP_ADDRESS_2 HOST_2;...'
```
El valor tiene segmentos que comienzan con las palabras clave gateway, netmask y ips. Separa los segmentos con una coma.

Ten en cuenta lo siguiente:
- Encierra todo el valor entre comillas simples.
- No se permiten espacios en blanco, excepto entre una dirección IP y un nombre de host.
En la lista de direcciones IP, sigue estos pasos:
- Puedes especificar una dirección IP individual o un bloque CIDR de direcciones IP.
- Separa cada dirección IP o bloque de CIDR con un punto y coma.
- Para una dirección IP individual, tienes la opción de especificar un nombre de host después de la dirección IP. Separa la dirección IP y el nombre de host con un espacio. Cuando no especificas un nombre de host, GKE on VMware usa el nombre de la VM de vSphere como nombre de host.
- Si especificas un bloque CIDR, no especifiques un valor para el nombre de host.
Por ejemplo:
```
--static-ip-config-ip-blocks 'gateway=172.16.23.254,netmask=255.255.252.0,ips=172.16.20.10;172.16.20.11 host2;172.16.20.12/30'
```
DNS_SERVER: Es una lista separada por comas de las direcciones IP de los servidores DNS para las VM.
DNS_SEARCH_DOMAIN: Es una lista separada por comas de los dominios de búsqueda de DNS que usarán los hosts. Estos dominios se usan como parte de una lista de búsqueda de dominios.
Por ejemplo:
```
--dns-search-domains example.com,examplepetstore.com
```
NTP_SERVER: Es una lista separada por comas de las direcciones IP de los servidores de tiempo para que usen las VM.

Marcas del plano de control

Si deseas usar valores no predeterminados para la configuración del plano de control, incluye una o más de las siguientes marcas:

--cpus=vCPUS: Es la cantidad de CPU virtuales (4 como mínimo) para cada nodo del plano de control del clúster de usuario. Si no se especifica, el valor predeterminado es de 4 CPU virtuales.
--memory=MEMORY: Es el tamaño de la memoria en mebibytes (MiB) de cada plano de control del clúster de usuario. El valor mínimo es 8,192 y debe ser un múltiplo de 4. Si no se especifica, el valor predeterminado es 8192.
--replicas=NODES: Es la cantidad de nodos del plano de control para el clúster de usuario. Por ejemplo, puedes seleccionar 1 nodo de plano de control para un entorno de desarrollo y 3 nodos de plano de control para entornos de producción de alta disponibilidad (HA).
--enable-auto-resize: Si deseas habilitar el cambio de tamaño automático de los nodos del plano de control para el clúster de usuario, incluye --enable-auto-resize. Cambiar el tamaño significa que la CPU virtual y los recursos de memoria asignados a un nodo se ajustan automáticamente. Cuando se habilita, se cambia el tamaño de los nodos del plano de control para el clúster de usuario según la cantidad de nodos trabajadores en el clúster de usuario. Por lo tanto, a medida que agregas más nodos trabajadores al clúster de usuario, aumenta el tamaño de los nodos del plano de control.
--enable-control-plane-v2: Si deseas habilitar el plano de control V2, incluye --enable-control-plane-v2. Cuando el plano de control V2 está habilitado, el plano de control de un clúster de usuario se ejecuta en uno o más nodos del clúster de usuario. De forma predeterminada, el plano de control de un clúster de usuario se ejecuta en uno o más nodos del clúster de administrador (denominado modelo de kubeception). Cuando el plano de control V2 está habilitado, los valores de --cpus y --memory se aplican a los nodos del plano de control en el clúster de usuario. La cantidad de nodos se determina según la cantidad de direcciones IP que ingreses en --control-plane-ip-block. Cuando el plano de control V2 no está habilitado, los valores de --cpus, --memory y --replicas se aplican a los nodos del plano de control en el clúster de administrador. Asegúrate de reservar suficientes direcciones IP para el clúster de administrador.

Si habilitas el plano de control V2, también debes especificar las siguientes marcas:
- --dns-servers=DNS_SERVER_1,...: Es una lista separada por comas de las direcciones IP de los servidores DNS para las VM.
- --ntp-servers=NTP_SERVER_1,...: Es una lista separada por comas de las direcciones IP de los servidores de tiempo para que usen las VM.
- --control-plane-ip-block, que tiene el siguiente formato:
```
  --control-plane-ip-block 'gateway=CP_GATEWAY,netmask=CP_NETMASK,ips=CP_IP_ADDRESS_1;CP_IP_ADDRESS_2 CP_HOST_2'
```
  El valor tiene segmentos que comienzan con las palabras clave gateway, netmask y ips. Separa los segmentos con una coma.
  
  Ten en cuenta lo siguiente:
  - Encierra todo el valor entre comillas simples.
  - No se permiten espacios en blanco, excepto entre una dirección IP y un nombre de host.
    
    En la lista de direcciones IP, sigue estos pasos:
  - Puedes especificar una dirección IP individual o un bloque CIDR de direcciones IP.
  - Separa cada dirección IP o bloque de CIDR con un punto y coma.
  - Para una dirección IP individual, tienes la opción de especificar un nombre de host después de la dirección IP. Separa la dirección IP y el nombre de host con un espacio.
  - Si especificas un bloque CIDR, no especifiques un valor para el nombre de host.
    
    Por ejemplo:
```
--control-plane-ip-block 'gateway=192.168.0.1,netmask=255.0.0.0,ips=192.168.1.1;192.168.1.2 hostname-2;192.168.2.2/28`
```
- Opcional: --dns-search-domains=DNS_SEARCH_DOMAIN_1,...: Una lista separada por comas de los dominios de búsqueda de DNS que deben usar los hosts. Estos dominios se usan como parte de una lista de búsqueda de dominios.
  
  Por ejemplo:
```
--dns-search-domains example.com,examplepetstore.com
```
Para obtener una lista completa de las marcas y sus descripciones, consulta la referencia de la CLI de gcloud.

Marcas de vSphere

Especifica las siguientes marcas opcionales si es necesario:
--disable-aag-config: Si no incluyes esta marca, las reglas de antiafinidad de VMware Distributed Resource Scheduler (DRS) se crean de forma automática para los nodos del clúster de usuario, lo que hace que se distribuyan en al menos 3 hosts físicos del centro de datos. Asegúrate de que tu entorno de vSphere cumpla con los requisitos. Si tu clúster no cumple con los requisitos, incluye esta marca.

Nota: Si seguiste las instrucciones en Configura la infraestructura mínima, solo tienes un host de ESXi, así que asegúrate de incluir esta marca.
--disable-vsphere-csi: Si no incluyes esta marca, los componentes de la interfaz de almacenamiento de contenedores (CSI) de vSphere se implementarán en el clúster de usuario. El controlador de CSI se ejecuta en un clúster de Kubernetes nativo implementado en vSphere para aprovisionar volúmenes persistentes en el almacenamiento de vSphere. Para obtener más información, consulta Usa el controlador de interfaz de almacenamiento de contenedores de vSphere. Si no quieres implementar los componentes de CSI, incluye esta marca.

Para obtener una lista completa de las marcas y sus descripciones, consulta la referencia de la CLI de gcloud.

Antes de ejecutar el comando gcloud para crear el clúster, es posible que quieras incluir --validate-only a fin de validar la configuración que especificaste en las marcas del comando gcloud. Cuando estés listo para crear el clúster, quita esta marca y ejecuta el comando.

El resultado del comando es similar al siguiente:
```
Waiting for operation [projects/example-project-12345/locations/us-west1/operations/operation-1679543737105-5f7893fd5bae9-942b3f97-75e59179] to complete.
```
En el resultado de ejemplo, la string operation-1679543737105-5f7893fd5bae9-942b3f97-75e59179 es la OPERATION_ID de la operación de larga duración. Puedes averiguar el estado de la operación con el siguiente comando:
```
gcloud container vmware operations describe OPERATION_ID \
  --project=FLEET_HOST_PROJECT_ID \
  --location=REGION
```
Para obtener más información, consulta gcloud container vmware operations.

La creación del clúster de usuario tarda 15 minutos o más. Puedes ver el clúster en Google Cloud Console en la página Clústeres de Anthos.

Crear un grupo de nodos

Después de crear el clúster, debes crear al menos un grupo de nodos antes de implementar las cargas de trabajo.
```
gcloud container vmware node-pools create NODE_POOL_NAME \
--cluster=USER_CLUSTER_NAME  \
--project=FLEET_HOST_PROJECT_ID \
--location=REGION \
--image-type=IMAGE_TYPE  \
--boot-disk-size=BOOT_DISK_SIZE \
--cpus=vCPUS \
--memory=MEMORY \
--replicas=NODES \
--enable-load-balancer
```
Reemplaza lo siguiente:
NODE_POOL_NAME: Es un nombre que elijas para el grupo de nodos. El nombre debe cumplir con los siguientes requisitos:
- Contener 40 caracteres como máximo.
- Contener solo caracteres alfanuméricos en minúscula o un guiones (-).
- Comenzar con un carácter alfabético
- Terminar con un carácter alfanumérico
USER_CLUSTER_NAME: Es el nombre del clúster de usuario recién creado.
FLEET_HOST_PROJECT_ID: El ID del proyecto en el que está registrado el clúster.
REGION: Es la región de Google Cloud que especificaste cuando creaste el clúster.
IMAGE_TYPE: El tipo de imagen de SO que se ejecutará en las VM del grupo de nodos. Establece una de las siguientes opciones: ubuntu_containerd o cos.
BOOT_DISK_SIZE: El tamaño del disco de arranque en gibibytes (GiB) para cada nodo del grupo. El mínimo es 40 GiB.
vCPUs: La cantidad de CPU virtuales para cada nodo del grupo de nodos. El mínimo es 4.
MEMORY: Es el tamaño de la memoria en mebibytes (MiB) para cada nodo del grupo. El mínimo es de 8,192 MiB por nodo trabajador del clúster de usuario y el valor debe ser un múltiplo de 4.
NODES: la cantidad de nodos en el grupo de nodos. El mínimo es 3.
Si usas MetalLB como balanceador de cargas, de manera opcional, incluye --enable-load-balancer si deseas permitir que la bocina de MetalLB se ejecute en los nodos del grupo. MetalLB debe estar habilitado en al menos un grupo de nodos. Si no incluyes esta marca, debes crear otro grupo de nodos para usar con MetalLB.

Para obtener más información sobre las marcas opcionales, consulta Agrega un grupo de nodos y la referencia de la CLI de gcloud.

Ejemplos de comandos de gcloud

MetalLB y DHCP

gcloud container vmware clusters create user-cluster-1 \
    --project=example-project-12345 \
    --location=us-west1 \
    --admin-cluster-membership=projects/example-project-12345/locations/global/memberships/admin-cluster-1 \
    --version=1.28.300-gke.123 \
    --admin-users=sara@example.com \
    --admin-users=amal@example.com \
    --enable-dhcp \
    --service-address-cidr-blocks=10.96.232.0/24 \
    --pod-address-cidr-blocks=192.168.0.0/16 \
    --metal-lb-config-address-pools='pool=lb-pool-1,manual-assign=False,avoid-buggy-ips=True,addresses=10.251.133.0/24;10.251.134.80/32;10.251.134.81/32' \
    --metal-lb-config-address-pools='pool=lb-pool-2,manual-assign=True,addresses=172.16.20.62/32' \
    --control-plane-vip=172.16.20.61 \
    --ingress-vip=172.16.20.62

Para obtener una descripción de la marca --metal-lb-config-address-pools, consulta Balanceador de cargas.

IP estáticas y MetalLB

gcloud container vmware clusters create user-cluster-3 \
    --project=example-project-12345 \
    --location=europe-west1 \
    --admin-cluster-membership=projects/example-project-12345/locations/global/memberships/admin-cluster-1 \
    --version=1.28.300-gke.123 \
    --admin-users=sara@example.com \
    --admin-users=amal@example.com \
    --static-ip-config-ip-blocks='gateway=172.16.23.254,netmask=255.255.252.0,ips=172.16.20.10 user-vm-1;172.16.20.11 user-vm-2' \
    --static-ip-config-ip-blocks='gateway=172.16.23.255,netmask=255.255.252.0,ips=172.16.20.12 user-vm-3;172.16.20.13 extra-vm' \
    --dns-servers=203.0.113.1,198.51.100.1 \
    --dns-search-domains=example.com,altostrat.com \
    --ntp-servers=216.239.35.4,216.239.35.5 \
    --service-address-cidr-blocks=10.96.232.0/24 \
    --pod-address-cidr-blocks=192.168.0.0/16 \
    --metal-lb-config-address-pools='pool=lb-pool-1,manual-assign=False,avoid-buggy-ips=True,addresses=10.251.133.0/24;10.251.134.80/32;10.251.134.81/32' \
    --metal-lb-config-address-pools='pool=lb-pool-2,manual-assign=True,addresses=172.16.20.62/32' \
    --control-plane-vip=172.16.20.61 \
    --ingress-vip=172.16.20.62

BIG-IP y DHCP de F5

gcloud container vmware clusters create user-cluster-2 \
    --project=example-project-12345 \
    --location=us-west1 \
    --admin-cluster-membership=projects/example-project-12345/locations/global/memberships/admin-cluster-1 \
    --version=1.28.300-gke.123 \
    --admin-users=sara@example.com \
    --admin-users=amal@example.com \
    --enable-dhcp \
    --service-address-cidr-blocks=10.96.232.0/24 \
    --pod-address-cidr-blocks=192.168.0.0/16 \
    --f5-config-address=203.0.113.2 \
    --f5-config-partition=my-f5-admin-partition \
    --control-plane-vip=172.16.20.61 \
    --ingress-vip=172.16.20.62

Para obtener una descripción de las marcas de F5, consulta Balanceador de cargas.

Balanceador de cargas manual e IP estáticas

gcloud container vmware clusters create user-cluster-4 \
    --project=example-project-12345 \
    --location=asia-east1 \
    --admin-cluster-membership=projects/example-project-12345/locations/global/memberships/admin-cluster-1 \
    --version=1.28.300-gke.123 \
    --admin-users=sara@example.com \
    --admin-users=amal@example.com \
    --static-ip-config-ip-blocks='gateway=172.16.23.254,netmask=255.255.252.0,ips=172.16.20.10 user-vm-1;172.16.20.11 user-vm-2' \
    --static-ip-config-ip-blocks='gateway=172.16.23.255,netmask=255.255.252.0,ips=172.16.20.12 user-vm-3;172.16.20.13 extra-vm' \
    --dns-servers=203.0.113.1,198.51.100.1  \
    --ntp-servers=216.239.35.4,216.239.35.5 \
    --service-address-cidr-blocks=10.96.232.0/24 \
    --pod-address-cidr-blocks=192.168.0.0/16 \
    --control-plane-vip=172.16.20.61 \
    --control-plane-node-port=30968 \
    --ingress-vip=172.16.20.62 \
    --ingress-http-node-port=32527 \
    --ingress-https-node-port=30139 \
    --konnectivity-server-node-port=30969

Terraform

Antes de comenzar

Obtén el nombre y la ubicación de la membresía de la flota del clúster de administrador:
```
gcloud container fleet memberships list \
    --project=FLEET_HOST_PROJECT_ID
```
Reemplaza FLEET_HOST_PROJECT_ID por el ID del proyecto en el que está registrado el clúster de administrador.

El resultado es similar al siguiente:
```
NAME             EXTERNAL_ID                           LOCATION
admin-cluster-1  bb7803b4-8438-4b22-859f-4559b4b29072  global
admin-cluster-2  ee16ee2b-6ec0-49fc-9413-3c89cbc70854  global
admin-cluster-3  fc2b7ef5-39ff-4b63-b919-04c5adc67be4  us-west1
```
La ubicación especifica dónde se ejecutan los servicios Fleet y Connect. Los clústeres de administrador creados antes de la versión 1.28 se administran con los servicios globales Fleet y Connect. En la versión 1.28 y en versiones posteriores, puedes especificar global o una región de Google Cloud cuando creas el clúster.
Obtén una lista de las versiones disponibles:
```
gcloud container vmware clusters query-version-config \
    --admin-cluster-membership=ADMIN_CLUSTER_NAME \
    --admin-cluster-membership-project=FLEET_HOST_PROJECT_ID \
    --admin-cluster-membership-location=ADMIN_CLUSTER_REGION \
    --location=REGION
```
Reemplaza lo siguiente:
- ADMIN_CLUSTER_NAME: Es el nombre del clúster de administrador.
- FLEET_HOST_PROJECT_ID: El ID del proyecto en el que está registrado el clúster de administrador
- ADMIN_CLUSTER_REGION: La región de membresía de la flota del clúster de administrador Puede ser una región global o de Google Cloud. Usa la ubicación del clúster de administrador del resultado de gcloud container fleet memberships list.
- REGION: Es la región de Google Cloud que usarás cuando crees el clúster. Esta es la región en la que se ejecutan la API de GKE On-Prem y los servicios Fleet y Connect. Especifica us-west1 o alguna otra región compatible.
El resultado del comando es similar al siguiente:
```
versions:
- isInstalled: true
  version: 1.14.3-gke.25
- version: 1.14.4-gke.54
- version: 1.15.0-gke.581
```
Las versiones que puedes usar para crear un clúster de usuario tienen anotaciones con isInstalled=true, lo que significa que el clúster de administrador tiene los componentes específicos de la versión que necesita para administrar los clústeres de usuario de esa versión. Si deseas crear un clúster de usuario con otra versión disponible, consulta Instala una versión posterior a la versión del clúster de administrador.

Ejemplo

Puedes usar la siguiente muestra de configuración básica para crear un clúster de usuario con el balanceador de cargas en paquete de MetalLB y un grupo de nodos.

Para obtener más información y otros ejemplos, consulta la documentación de referencia de google_gkeonprem_vmware_cluster.

Establece variables en `terraform.tfvars`

En la muestra, se proporciona un archivo de variables de ejemplo para pasar a main.tf, que muestra cómo configurar el balanceador de cargas agrupado de MetalLB y habilitar los nodos del clúster para obtener sus direcciones IP desde un servidor DHCP que proporciones.

Clona el repositorio anthos-samples y cambia al directorio en el que se encuentra la muestra de Terraform:

git clone https://github.com/GoogleCloudPlatform/anthos-samples
cd anthos-samples/anthos-onprem-terraform/avmw_user_cluster_metallb

Crea una copia del archivo terraform.tfvars.sample:
```
cp terraform.tfvars.sample terraform.tfvars
```
Modifica los valores de los parámetros en terraform.tfvars.
```
project_id                  = "FLEET_HOST_PROJECT_ID"
region                      = "REGION"
admin_cluster_name          = "ADMIN_CLUSTER_NAME"
on_prem_version             = "VERSION"
admin_user_emails           = ["YOUR_EMAIL_ADDRESS", "ADMIN_2_EMAIL_ADDRESS"]
cluster_name                = "avmw-user-cluster-metallb"
control_plane_node_cpus     = 4
control_plane_node_memory   = 8192
control_plane_node_replicas = 3
control_plane_vip           = "CONTROL_PLANE_VIP"
ingress_vip                 = "INGRESS_VIP"
lb_address_pools            = [
    { name = "lbpool_1", addresses = ["10.200.0.51-10.200.0.70"] }
]
```
En la siguiente lista, se describen las variables:
- project_id: El ID del proyecto en el que deseas crear el clúster. El proyecto especificado también se usa como el proyecto host de la flota. Este debe ser el mismo proyecto en el que está registrado el clúster de administrador. Después de crear el clúster de usuario, se registra de forma automática en la flota del proyecto seleccionado. No se puede cambiar el proyecto host de la flota después de que se cree el clúster.
- region: Es la región de Google Cloud en la que se ejecutan la API de GKE On-Prem (gkeonprem.googleapis.com), el servicio de flota (gkehub.googleapis.com) y el servicio Connect (gkeconnect.googleapis.com). Especifica us-west1 o alguna otra región compatible.
- admin_cluster_name: Es el nombre del clúster de administrador que gestiona el clúster de usuario. En el ejemplo, se supone que el clúster de administrador usa la región global. Si tienes un clúster de administrador regional, haz lo siguiente:
  1. Abre main.tf en un editor de texto.
  2. Busca admin_cluster_membership, que se ve de la siguiente manera:
```
admin_cluster_membership = "projects/${var.project_id}/locations/global/memberships/${var.admin_cluster_name}"
```
  1. Cambia global a la región que usa el clúster de administrador y guarda el archivo.
- on_prem_version: Es la versión de GKE en VMware para el clúster de usuario. Por lo general, debes especificar la misma versión que el clúster de administrador. Para especificar una versión posterior, instala una versión posterior a la del clúster de administrador. Si no conoces la versión del clúster de administrador, ejecuta gcloud container vmware clusters query-version-config, que es el primer paso en Instala una versión posterior a la del clúster de administrador.
- admin_user_emails: Una lista de direcciones de correo electrónico de los usuarios a los que se les otorgarán privilegios de administrador en el clúster. Asegúrate de agregar tu dirección de correo electrónico si quieres administrar el clúster.
  
  Cuando se crea el clúster, la API de GKE On-Prem aplica las políticas de control de acceso basado en funciones (RBAC) de Kubernetes al clúster para otorgar a los usuarios administradores la función clusterrole/cluster-admin de Kubernetes, que proporciona acceso completo a todos los recursos del clúster en todos los espacios de nombres. Esto también permite a los usuarios iniciar sesión en la consola con su identidad de Google.
- cluster_name: Un nombre que elijas para el clúster de usuario El nombre no se puede cambiar después de crear el clúster. El nombre debe cumplir con los siguientes requisitos:
  - Contener 40 caracteres como máximo.
  - Contener solo caracteres alfanuméricos en minúscula o un guiones (-).
  - Comenzar con un carácter alfabético
  - Terminar con un carácter alfanumérico
- control_plane_node_cpus: Es la cantidad de CPU virtuales para cada nodo del plano de control del clúster de usuario. El mínimo es 4 CPU virtuales.
- control_plane_node_memory: Es el tamaño de la memoria en mebibytes (MiB) de cada plano de control del clúster de usuario. El valor mínimo es 8,192 y debe ser un múltiplo de 4.
- control_plane_node_replicas: Es la cantidad de nodos del plano de control para el clúster de usuario. Por ejemplo, puedes ingresar 1 nodo de plano de control para un entorno de desarrollo y 3 nodos de plano de control para entornos de producción y alta disponibilidad (HA).
- control_plane_vip: La dirección IP virtual (VIP) que elegiste configurar en el balanceador de cargas para el servidor de la API de Kubernetes del clúster de usuario.
- ingress_vip: La dirección IP que elegiste configurar en el balanceador de cargas para el proxy de entrada
- lb_address_pools: Una lista de mapas que definen los grupos de direcciones que usará el balanceador de cargas de MetalLB. La VIP de entrada debe estar en uno de estos grupos. Especifica lo siguiente:
  - name: Es un nombre para el grupo.
  - addresses: Es un rango de direcciones en formato de notación CIDR o de rango con guion. Si deseas especificar una sola dirección IP en un grupo (como para la VIP de entrada), usa /32 en la notación CIDR, por ejemplo: 192.0.2.1/32.
  Reemplaza las direcciones IP de ejemplo por tus valores y agrega grupos de direcciones adicionales si es necesario.
Guarda los cambios en terraform.tfvars. Si no quieres realizar ningún cambio opcional a main.tf, ve a la siguiente sección: Crea el clúster y un grupo de nodos.

Opcional: Establece la configuración del clúster en `main.tf`

En esta sección, se explican algunos cambios de configuración opcionales que puedes realizar en main.tf. Antes de realizar cambios, crea una copia de seguridad de main.tf:

cp main.tf main.tf.bak

Modo de direccionamiento IP del nodo trabajador

De forma predeterminada, main.tf configura el clúster para que use un servidor DHCP que proporcionas con el fin de asignar direcciones IP a los nodos trabajadores del clúster. El DHCP se configura incluyendo el mapa dhcp_config dentro del bloque network_config. Si deseas proporcionar direcciones IP estáticas para tus nodos trabajadores, realiza los siguientes cambios en main.tf:

Reemplaza el bloque network_config e incluye un bloque static_ip_config. Por ejemplo:

  network_config {
    service_address_cidr_blocks = ["10.96.0.0/12"]
    pod_address_cidr_blocks = ["192.168.0.0/16"]
    host_config {
      dns_servers = ["10.254.41.1"]
      ntp_servers = ["216.239.35.8"]
    }
    static_ip_config {
      ip_blocks {
        netmask = "255.255.252.0"
        gateway = "10.251.31.254"
        ips {
          ip = "10.251.30.153"
          hostname = "vm-1"
        }
        ips {
          ip = "10.251.31.206"
          hostname = "vm-2"
        }
        ips {
          ip = "10.251.31.193"
          hostname = "vm-3"
        }
        ips {
          ip = "10.251.30.230"
          hostname = "vm-4"
        }
      }
    }
  }

Reemplaza lo siguiente por tus valores:
- service_address_cidr_blocks: Es un rango de direcciones IP, en formato CIDR, que se usará para los servicios del clúster. Debe ser al menos un rango de /24.
- pod_address_cidr_blocks: Es un rango de direcciones IP, en formato CIDR, que se usará para los Pods del clúster. Debe ser al menos un rango /18.
- dns_servers: Una lista de las direcciones IP de servidores DNS para las VM
- ntp_servers: Una lista de las direcciones IP de los servidores de tiempo para que usen las VM.
- En el bloque static_ip_config, reemplaza los valores de netmask y gateway por las direcciones de tu red. Reemplaza ip y hostname por las direcciones IP y los nombres de host de tus nodos trabajadores.

Configura el plano de control V2

De forma predeterminada, main.tf configura el plano de control para que el clúster de usuario se ejecute en uno o más nodos del clúster de administrador (denominado modelo de kubeception). Si lo prefieres, puedes habilitar el Plano de control V2. Cuando el plano de control V2 está habilitado, el plano de control de un clúster de usuario se ejecuta en uno o más nodos del clúster de usuario. Para configurar el plano de control V2, realiza los siguientes cambios en main.tf:

Agrega la siguiente línea después de la línea con admin_cluster_membership:
```
  enable_control_plane_v2 = "true"
```

Agrega un mapa control_plane_v2_config al bloque network_config, por ejemplo:

  control_plane_v2_config {
    control_plane_ip_block {
      netmask = "255.255.252.0"
      gateway = "10.250.71.254"
      ips {
        ip = "10.250.68.54"
        hostname = "cpv2-vm1"
      }
      ips {
        ip = "10.250.68.128"
        hostname = "cpv2-vm2"
      }
      ips {
        ip = "10.250.71.50"
        hostname = "cpv2-vm3"
      }
    }
  }

Reemplaza los valores para netmask y gateway por las direcciones IP de tu red. Reemplaza ip y hostname por las direcciones IP de los nodos del plano de control.

Crea el clúster y un grupo de nodos

Inicializa y crea terraform plan:
```
terraform init
```
Terraform instala las bibliotecas necesarias, como el proveedor de Google Cloud.
Revisa la configuración y realiza cambios si es necesario:
```
terraform plan
```
Aplica el plan de Terraform para crear el clúster de usuario:
```
terraform apply
```
La creación del clúster de usuario toma alrededor de 15 minutos o más, y el grupo de nodos tarda otros 15 minutos. Puedes ver el clúster en Google Cloud Console en la página Clústeres de Anthos.

Instala una versión posterior a la versión del clúster de administrador

Un clúster de administrador puede administrar clústeres de usuario en diferentes versiones. Si deseas crear un clúster de usuario que sea una versión posterior a la del clúster de administrador, debes descargar y, luego, implementar los componentes que el clúster de administrador necesita para administrar los clústeres de usuario de esa versión, de la siguiente manera:

Obtén una lista de las versiones disponibles:
```
gcloud container vmware clusters query-version-config \
    --admin-cluster-membership=ADMIN_CLUSTER_NAME \
    --admin-cluster-membership-project=FLEET_HOST_PROJECT_ID \
    --location=REGION
```
Reemplaza lo siguiente:
- ADMIN_CLUSTER_NAME: Es el nombre del clúster de administrador.
- FLEET_HOST_PROJECT_ID: El ID del proyecto en el que está registrado el clúster de administrador
- REGION: Es la región de Google Cloud en la que se ejecuta la API de GKE On-Prem. Esta es la región que especificarás cuando crees el clúster de usuario. Especifica us-west1 o alguna otra región compatible.
El resultado del comando es similar al siguiente:
```
versions:
- isInstalled: true
  version: 1.14.3-gke.25
- version: 1.14.4-gke.54
- version: 1.15.0-gke.581
```
Las versiones instaladas en el clúster de administrador tienen anotaciones con isInstalled=true.
Si aún no lo hiciste, inscribe el clúster de administrador en la API de GKE On-Prem. Después de inscribir el clúster en la API de GKE On-Prem, no es necesario que vuelvas a realizar este paso.
Descarga la versión nueva de los componentes y, luego, impleméntalo en el clúster de administrador:
```
gcloud vmware admin-clusters update ADMIN_CLUSTER_NAME \
    --project=FLEET_HOST_PROJECT_ID \
    --location=REGION \
    --required-platform-version=VERSION
```
Con este comando, se descarga la versión de los componentes que especificas en --required-platform-version en el clúster de administrador y, luego, se implementan los componentes. Ahora puedes crear un clúster de usuario con la versión especificada.

Soluciona problemas

Consulta Soluciona problemas de creación y actualización de clústeres.

Crea un clúster de usuario

Antes de comenzar

Crea un clúster de usuario

gkectl

Descripción general del procedimiento

Completa los archivos de configuración

name

gkeOnPremVersion

enableControlplaneV2

kubeception

enableDataplaneV2

vCenter

Usa un centro de datos y un clúster de vSphere

Usa clústeres de vSphere independientes

Usa centros de datos de vSphere independientes

Usa cuentas de vCenter separadas

Usa instancias independientes de vCenter Server

network

loadBalancer

advancedNetworking

multipleNetworkInterfaces

storage

masterNode

nodePools

antiAffinityGroups

stackdriver

gkeConnect

gkeOnPremAPI

usageMetering

cloudAuditLogging

Ejemplo de archivos de configuración completados

user-ipblock.yaml

user-cluster.yaml

Valida tu archivo de configuración

3. Importa imágenes de SO a vSphere y envía imágenes de contenedor a un registro privado (opcional).

4. Crear un clúster de usuario

Crear un clúster de usuario

Ubica el archivo kubeconfig del clúster de usuario

5. Verifica que el clúster de usuario esté en ejecución

Console

Comenzar

Conceptos básicos del clúster

Plano de control

Redes

Balanceador de cargas

Incluido con MetalLB

BIG-IP de F5

Manual

Funciones

Grupos de nodos

gcloud CLI

Antes de comenzar

Ejemplos

MetalLB y DHCP

IP estáticas y MetalLB

BIG-IP y DHCP de F5

Balanceador de cargas manual e IP estáticas

Marcas del plano de control

Marcas de vSphere

Crear un grupo de nodos

Ejemplos de comandos de gcloud

MetalLB y DHCP

IP estáticas y MetalLB

BIG-IP y DHCP de F5

Balanceador de cargas manual e IP estáticas

Terraform

Antes de comenzar

Ejemplo

Establece variables en terraform.tfvars

Opcional: Establece la configuración del clúster en main.tf

Modo de direccionamiento IP del nodo trabajador

Configura el plano de control V2

Crea el clúster y un grupo de nodos

Instala una versión posterior a la versión del clúster de administrador

Soluciona problemas

¿Qué sigue?

`name`

`gkeOnPremVersion`

`enableControlplaneV2`

`enableDataplaneV2`

`vCenter`

`network`

`loadBalancer`

`advancedNetworking`

`multipleNetworkInterfaces`

`storage`

`masterNode`

`nodePools`

`antiAffinityGroups`

`stackdriver`

`gkeConnect`

`gkeOnPremAPI`

`usageMetering`

`cloudAuditLogging`

Establece variables en `terraform.tfvars`

Opcional: Establece la configuración del clúster en `main.tf`