Los clústeres de Anthos en VMware ahora son Google Distributed Cloud (solo software) para VMware. Para obtener más información, consulta la descripción general del producto.

Esta página se ha traducido con Cloud Translation API.

Crear clúster de usuarios

En Google Distributed Cloud, tus cargas de trabajo se ejecutan en uno o varios clústeres de usuario. En este documento se explica cómo crear un clúster de usuarios. Si quieres usar dominios de topología, consulta Crear un clúster de usuarios para usarlo con dominios de topología.

Esta página está dirigida a administradores, arquitectos y operadores que configuran, monitorizan y gestionan la infraestructura tecnológica. Para obtener más información sobre los roles habituales y las tareas de ejemplo a las que hacemos referencia en el contenido, consulta Roles y tareas habituales de los usuarios de GKE. Google Cloud

En la versión 1.33 y posteriores, todos los clústeres nuevos se crean como clústeres avanzados. Consulta las diferencias al ejecutar clústeres avanzados.

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

gkectl
Google Cloud consola
Google Cloud CLI
Terraform

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

Para obtener información sobre qué herramienta puedes usar, consulta Elegir una herramienta para gestionar el ciclo de vida de un clúster.

Antes de empezar

Si tienes previsto usar gkectl para crear el clúster de usuarios, asegúrate de haber configurado tu estación de trabajo de administrador y de poder iniciar sesión en ella, tal como se describe en el artículo Crear una estación de trabajo de administrador.
Asegúrate de que tu estación de trabajo de administrador tenga la versión necesaria de gkectl. Normalmente, se usa la misma versión de gkectl que la que se usará al crear el clúster. Puedes especificar la versión del clúster en el campo gkeOnPremVersion del archivo de configuración del clúster. Durante la creación del clúster, se aplican las siguientes reglas de versión:
- La versión secundaria de gkectl no puede ser inferior a la versión secundaria del clúster. Por ejemplo, no se permite crear un clúster 1.30 con la versión 1.29 de gkectl. Las versiones de parche no importan. Por ejemplo, puedes usar la versión 1.29.0-gke.1456 de gkectl para crear un clúster con una versión de parche superior, como la 1.29.1000-gke.94.
- La versión secundaria gkectl no puede ser más de dos versiones secundarias superior a la versión del clúster. Por ejemplo, si vas a crear un clúster 1.28, la versión de gkectl puede ser 1.29 o 1.30. Sin embargo, no puedes usar la versión 1.31 de gkectl porque es tres versiones secundarias superior a la versión del clúster.
Si es necesario, consulta Descargar gkectl para obtener una versión compatible de gkectl.
Si aún no lo has hecho, configura tus Google Cloud recursos como se describe en estos documentos:
Cuando configures tu proyecto host de la flota, ten en cuenta la herramienta que elijas, ya que, si has seleccionado uno de los clientes de la API GKE On-Prem, hay APIs adicionales que debes habilitar. Para ver la lista de APIs, consulta Habilitar APIs en el proyecto host de tu flota.
Antes de crear un clúster de usuarios, debes tener un clúster de administrador para gestionarlo. Si aún no lo has hecho, crea una estación de trabajo de administrador y un clúster de administrador.
Determina la versión del clúster de usuario que quieres instalar. Cuando creas un clúster de usuarios, normalmente instalas la versión que coincide con la del clúster de administradores. Si quieres instalar una versión diferente en un clúster de usuario, consulta las reglas de versiones.
Si tienes previsto instalar la versión 1.30 o una versión posterior, se requiere Controlplane V2. Aunque instales la versión 1.29 o una anterior, te recomendamos que habilites Controlplane V2. Cuando Controlplane V2 está habilitado, el plano de control del clúster de usuarios se ejecuta en uno o varios nodos del propio clúster de usuarios. La alternativa es crear un clúster de usuarios que utilice kubeception. En el caso de kubeception, el plano de control del clúster de usuario se ejecuta en uno o varios nodos del clúster de administrador.
Consulta el documento de planificación de direcciones IP y asegúrate de que tienes suficientes direcciones IP disponibles.
Consulta la información general sobre el balanceo de carga y vuelve a plantearte qué tipo de balanceador de carga quieres usar. Puedes usar el balanceador de carga MetalLB incluido o configurar manualmente el balanceador de carga que elijas. En el caso del balanceo de carga manual, debes configurar el balanceador de carga antes de crear el clúster de usuarios.
Piensa en cuántos grupos de nodos necesitas y en qué sistema operativo quieres ejecutar en cada uno de ellos.
Piensa si quieres usar clústeres de vSphere independientes para tu clúster de administrador y tus clústeres de usuarios, y si quieres usar centros de datos independientes. También debes plantearte si quieres usar instancias independientes de vCenter Server.
En la versión 1.29 y posteriores, las comprobaciones preparatorias del lado del servidor están habilitadas de forma predeterminada. Las comprobaciones previas del lado del servidor requieren reglas de cortafuegos adicionales. En Reglas de firewall para clústeres de administrador, busca "Comprobaciones previas" y asegúrate de que todas las reglas de firewall necesarias estén configuradas.

Con las comprobaciones previas del lado del servidor, cuando creas un clúster de usuarios con gkectl, las comprobaciones previas se ejecutan en el clúster de administrador en lugar de localmente en la estación de trabajo del administrador. Las comprobaciones previas del lado del servidor también se ejecutan si usas la Google Cloud consola, la CLI de Google Cloud o Terraform para crear un clúster de usuario.

Crear un clúster de usuarios con la herramienta que prefieras

En esta sección se explica cómo crear un clúster de usuarios con gkectl, la consola, la CLI de gcloud y Terraform.

gkectl

Descripción general del procedimiento

Estos son los pasos principales para usar gkectl y crear un clúster de usuarios:

Rellena los archivos de configuración

Especifica los detalles de tu nuevo clúster completando un archivo de configuración de clúster de usuarios, un archivo de configuración de credenciales y, posiblemente, un archivo de bloque de IPs.
(Opcional) Importa imágenes de SO a vSphere y envía imágenes de contenedor al registro privado, si procede.

Ejecutar gkectl prepare.
Crear clúster de usuarios

Ejecuta gkectl create cluster para crear un clúster tal como se especifica en el archivo de configuración.
Verificar que el clúster de usuarios esté en funcionamiento

Usa kubectl para ver los nodos del clúster.

Al final de este procedimiento, tendrás un clúster de usuarios en funcionamiento en el que podrás desplegar tus cargas de trabajo.

Si usas Controles de Servicio de VPC, es posible que veas errores al ejecutar algunos comandos de gkectl, como "Validation Category: GCP - [UNKNOWN] GCP service: [Stackdriver] could not get GCP services". Para evitar estos errores, añade el parámetro --skip-validation-gcp a tus comandos.

Rellena los archivos de configuración

Si has usado gkeadm para crear tu estación de trabajo de administrador, gkeadm habrá generado una plantilla para el archivo de configuración de tu clúster de usuarios, llamado user-cluster.yaml. Además, gkeadm ha rellenado algunos campos por ti.

Si no has usado gkeadm para crear tu estación de trabajo de administrador, puedes usar gkectl para generar una plantilla para el archivo de configuración de tu clúster de usuarios.

Para generar una plantilla para el archivo de configuración de tu clúster de usuarios, sigue estos pasos:

gkectl create-config cluster --config=OUTPUT_FILENAME --gke-on-prem-version=VERSION

Haz los cambios siguientes:

OUTPUT_FILENAME: la ruta que quieras para la plantilla generada. Si omite esta marca, gkectl asigna el nombre user-cluster.yaml al archivo y lo coloca en el directorio actual.

VERSION: el número de versión que quieras. Por ejemplo: gkectl create-config cluster --gke-on-prem-version=1.33.0-gke.799.

Familiarízate con el archivo de configuración consultando el documento Archivo de configuración de clúster de usuarios. Te recomendamos que mantengas este documento abierto en otra pestaña o ventana, ya que lo consultarás cuando completes los pasos siguientes.

`name`

Asigna al campo name el nombre que quieras para el clúster de usuario.

`gkeOnPremVersion`

Este campo ya está rellenado. Especifica la versión de Google Distributed Cloud. Por ejemplo, 1.33.0-gke.799.

`enableAdvancedCluster`

En la versión 1.31, si quieres habilitar la función de clúster avanzado, define enableAdvancedCluster como true. Este campo debe tener el valor true si el clúster de administrador tiene habilitado el clúster avanzado.

Tenga en cuenta las siguientes diferencias entre las versiones:

En la versión 1.31, la función de clúster avanzado está en versión preliminar:
- Solo puedes habilitar clústeres avanzados al crear clústeres 1.31 nuevos.
- Una vez que se haya habilitado el clúster avanzado, no podrás actualizarlo a la versión 1.32. Habilita el clúster avanzado solo en un entorno de prueba.
En la versión 1.32, la función de clúster avanzado está disponible de forma general.
- De forma predeterminada, los clústeres de usuarios se crean como clústeres avanzados. Debes definir enableAdvancedCluster como false explícitamente si quieres crear un clúster no avanzado.
- En los clústeres que tienen habilitada la función de clústeres avanzados, se admiten las actualizaciones de clústeres.
En la versión 1.33 y posteriores, todos los clústeres se crean como clústeres avanzados. Si asignas el valor false a enableAdvancedCluster, no se podrá crear el clúster.

`enableControlplaneV2`

Para crear un clúster de usuarios con Controlplane V2 habilitado, asigna el valor true a enableControlplaneV2.

Si habilitas el clúster avanzado, debes asignar el valor true a enableControlplaneV2.

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

kubeception

Si asignas el valor false a este campo, el clúster usará kubecetption. Con kubeception, el plano de control del clúster de usuarios se ejecuta en nodos del clúster de administrador.

En un clúster de kubeception:

Asigna el valor false a enableControlplaneV2.
No rellenes 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 IPs del clúster de administrador.

`enableDataplaneV2`

Asigna el valor true a enableDataplaneV2.

`vCenter`

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

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

Para anular cualquiera de los valores globales de vCenter, rellena los campos correspondientes de la sección vCenter de tu archivo de configuración de clúster de usuario.

En concreto, puede que quieras usar clústeres de vSphere independientes para tu clúster de administrador y tus clústeres de usuarios, así como centros de datos independientes para tu clúster de administrador y tus clústeres de usuarios.

Usar 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 clúster de usuarios. Para esta opción, no definas ningún valor de vCenter en el archivo de configuración del clúster de usuarios. Los valores de vCenter se heredarán del clúster de administradores.

Usar clústeres de vSphere independientes

Si quieres crear un clúster de usuarios 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 usuarios.

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

Usar centros de datos de vSphere independientes

El clúster de usuarios y el clúster de administrador pueden estar en diferentes centros de datos. En ese caso, también se encuentran en clústeres de vSphere independientes.

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

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

Usar cuentas de vCenter independientes

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

Usar instancias independientes de vCenter Server

En determinadas situaciones, es conveniente crear un clúster de usuarios que utilice 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, puede que quieras tener una máquina física que ejecute vCenter Server y una o varias máquinas físicas que ejecuten ESXi. Después, puedes usar tu instancia local de vCenter Server para crear una jerarquía de objetos de vSphere, incluidos centros de datos, clústeres, grupos de recursos, almacenes de datos y carpetas.

Rellena toda la sección vCenter del archivo de configuración del clúster de usuarios. En concreto, especifica un valor para vCenter.address que sea diferente de la dirección de vCenter Server que hayas especificado 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 debe rellenar el campo network.vCenter.networkName.

`network`

Decide cómo quieres que obtengan sus direcciones IP los nodos de trabajo. Las opciones son las siguientes:

Desde un servidor DHCP que hayas configurado previamente. Asigna el valor "dhcp" a network.ipMode.type.
A partir de una lista de direcciones IP estáticas que proporciones. Asigna el valor network.ipMode.type a "static" y crea un archivo de bloque de IPs que proporcione las direcciones IP estáticas. Para ver un ejemplo de un archivo de bloqueo de IPs, consulta Ejemplo de archivos de configuración rellenados.

Si has decidido usar direcciones IP estáticas para tus nodos de trabajo, rellena el campo network.ipMode.ipBlockFilePath.

Los nodos del plano de control de tu clúster de usuario deben obtener sus direcciones IP de una lista de direcciones estáticas que proporciones. Esto ocurre aunque tus nodos de trabajo obtengan sus direcciones de un servidor DHCP. Para especificar direcciones IP estáticas para los nodos del plano de control, rellena la sección network.controlPlaneIPBlock. Si quieres un clúster de usuarios de alta disponibilidad, especifica tres direcciones IP. De lo contrario, especifica una dirección IP.

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

Los campos network.podCIDR y network.serviceCIDR tienen valores predefinidos que puedes dejar sin modificar, a menos que entren en conflicto con direcciones que ya se estén usando en tu red. Kubernetes usa estos intervalos para asignar direcciones IP a los pods y servicios de tu clúster.

Independientemente de si utilizas un servidor DHCP o especificas una lista de direcciones IP estáticas, debes tener suficientes direcciones IP disponibles para tu clúster de usuarios. Para saber cuántas direcciones IP necesitas, consulta Planificar las direcciones IP.

`loadBalancer`

Reserva una IP virtual para el servidor de la API de Kubernetes de tu clúster de usuario. Reserva otra IP virtual para el servicio de entrada de tu clúster de usuario. Proporciona tus VIPs como valores de loadBalancer.vips.controlPlaneVIP y loadBalancer.vips.ingressVIP.

Decide qué tipo de balanceo de carga quieres usar. Las opciones disponibles son:

Balanceo de carga agrupado de MetalLB. Asigna el valor "MetalLB" a loadBalancer.kind. También debes rellenar la sección loadBalancer.metalLB.addressPools y asignar el valor true a enableLoadBalancer en al menos uno de tus grupos de nodos. Para obtener más información, consulta Balanceo de carga agrupado con MetalLB.
Balanceo de carga manual. Define loadBalancer.kind como "ManualLB" y rellena la sección manualLB. Para obtener más información, consulta Balanceo de carga manual.

Para obtener más información sobre las opciones de balanceo de carga, consulta la información general sobre el balanceo de carga.

`advancedNetworking`

Si tienes previsto crear una pasarela de NAT de salida, asigna el valor true a advancedNetworking.

`multipleNetworkInterfaces`

Decide si quieres configurar varias interfaces de red para los pods y define multipleNetworkInterfaces en consecuencia.

`storage`

Si quieres inhabilitar la implementación de componentes de CSI de vSphere, asigna el valor true a storage.vSphereCSIDisabled.

`masterNode`

En la sección masterNode puedes especificar cuántos nodos del plano de control quieres que tenga tu clúster de usuario: especifica 3 para un clúster de alta disponibilidad (HA) o 1 para un clúster que no sea de alta disponibilidad. También puedes especificar un almacén de datos para los nodos del plano de control y si quieres habilitar el cambio de tamaño automático para los nodos del plano de control.

Si el campo enableAdvancedCluster tiene el valor true, debe asignar el valor 3 al campo replicas. Solo se admiten clústeres de usuarios de alta disponibilidad en clústeres avanzados.

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

`nodePools`

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

Debe especificar al menos un grupo de nodos rellenando la sección nodePools.

Si habilitas el clúster avanzado, asigna a nodePools[i]osImageType el valor ubuntu_cgroupv2 o ubuntu_containerd.

Para obtener más información, consulta los artículos sobre grupos de nodos y creación y gestión de grupos de nodos.

`antiAffinityGroups`

Asigna el valor true o false a antiAffinityGroups.enabled.

Este campo especifica si Google Distributed Cloud crea reglas de antiafinidad de Distributed Resource Scheduler (DRS) para tus nodos de trabajo, lo que hace que se distribuyan en al menos tres hosts físicos de tu centro de datos.

`stackdriver`

Si quieres habilitar Cloud Logging y Cloud Monitoring en tu clúster, rellena la sección stackdriver.

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

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

El ID de stackdriver.projectID debe ser el mismo que el de gkeConnect.projectID y cloudAuditLogging.projectID.
La región definida en stackdriver.clusterLocation debe ser la misma que la definida en cloudAuditLogging.clusterLocation y gkeConnect.location. Google Cloud Además, si gkeOnPremAPI.enabled es true, se debe definir la misma región en gkeOnPremAPI.location.

Si los IDs de proyecto y las regiones no son los mismos, no se podrá crear el clúster.

`gkeConnect`

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

Rellena la sección gkeConnect para especificar un proyecto del host de la flota y una cuenta de servicio asociada. El ID de gkeConnect.projectID debe ser el mismo que el ID definido en stackdriver.projectID y cloudAuditLogging.projectID. Si los IDs de proyecto no son los mismos, se produce un error al crear el clúster.

En la versión 1.28 y posteriores, puedes especificar una región en la que se ejecuten los servicios Fleet y Connect 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 configurada en cloudAuditLogging.clusterLocation, stackdriver.clusterLocation y gkeOnPremAPI.location. Si las regiones no son las mismas, no se podrá crear el clúster.

`gkeOnPremAPI`

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

Si quieres registrar todos los clústeres del proyecto en la API de GKE On-Prem, sigue los pasos que se indican en la sección Antes de empezar para activar y usar la API de GKE On-Prem en el proyecto.
Si no quieres registrar el clúster en la API GKE On-Prem, incluye esta sección y asigna el valor false a gkeOnPremAPI.enabled. Si no quieres registrar ningún clúster en el proyecto, inhabilita gkeonprem.googleapis.com (el nombre del servicio de la API de GKE On-Prem) en el proyecto. Para obtener instrucciones, consulta Inhabilitar servicios.

`cloudAuditLogging`

Si quieres integrar los registros de auditoría del servidor de la API de Kubernetes de tu clúster con Cloud Audit Logs, rellena la sección cloudAuditLogging.

Ten en cuenta los siguientes requisitos:

Si habilitas el clúster avanzado, asigna a cloudAuditLogging.serviceAccountKeyPath la misma ruta que a stackdriver.serviceAccountKeyPath.
El ID de cloudAuditLogging.projectID debe ser el mismo que el de gkeConnect.projectID y stackdriver.projectID.
La región de cloudAuditLogging.clusterLocation debe ser la misma que la región definida en gkeConnect.location y stackdriver.clusterLocation. Además, si gkeOnPremAPI.enabled es true, se debe definir la misma región en gkeOnPremAPI.location.

Si los IDs de proyecto y las regiones no son los mismos, no se podrá crear el clúster.

Ejemplo de archivos de configuración rellenados

A continuación, se muestran ejemplos de un archivo de bloque de IP y de un archivo de configuración de clúster de usuarios:

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.33.0-gke.799
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 tener en cuenta en el ejemplo anterior:

El campo nodePools.replicas tiene el valor 3, lo que significa que hay tres nodos de trabajo en "worker-node-pool". Todos los nodos de trabajo usan direcciones IP estáticas porque network.ipMode.type está definido como "static".
Las direcciones IP estáticas de los nodos de trabajador se especifican en un archivo de bloque de IPs. El archivo de bloque de IPs tiene cuatro direcciones, aunque solo hay tres nodos de trabajo. La dirección IP adicional es necesaria durante la actualización del clúster, la actualización y la reparación automática.
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 de trabajo. Esto se debe a que los nodos de trabajo tienen direcciones IP estáticas. Si los nodos de trabajo obtuvieran sus direcciones IP de un servidor DHCP, estos servidores DNS y NTP solo serían para los nodos del plano de control.
Las direcciones IP estáticas de 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 es necesario tener una dirección IP adicional en este bloque.
Controlplane V2 está habilitado.
El campo masterNode.replicas se define como 3, por lo que el clúster tendrá un plano de control de alta disponibilidad.
La dirección IP virtual del plano de control y la dirección IP virtual de entrada están en la misma VLAN que los nodos de trabajador y los nodos del plano de control.
Las IPs virtuales reservadas para los servicios de tipo LoadBalancer se especifican en la sección loadBalancer.metalLB.addressPools del archivo de configuración del clúster de usuarios. Estas IPs virtuales están en la misma VLAN que los nodos de trabajador y los nodos del plano de control. El conjunto de IPs virtuales especificadas en esta sección debe incluir la IP virtual de entrada y no debe incluir la IP virtual del plano de control.
El archivo de configuración del clúster de usuarios no incluye una sección vCenter. Por lo tanto, el clúster de usuarios usa los mismos recursos de vSphere que el clúster de administrador.

Validar el archivo de configuración

Una vez que hayas rellenado el archivo de configuración del clúster de usuarios, ejecuta gkectl check-config para verificar que el archivo es válido:

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

Haz los cambios siguientes:

ADMIN_CLUSTER_KUBECONFIG: la ruta del archivo kubeconfig de tu clúster de administrador
USER_CLUSTER_CONFIG: la ruta del archivo de configuración del clúster de usuarios

Si el comando devuelve algún mensaje de error, solucione los problemas y vuelva a validar el archivo.

Si quieres saltarte las validaciones que requieren más tiempo, usa la marca --fast. Para omitir validaciones concretas, usa las marcas --skip-validation-xxx. Para obtener más información sobre el comando check-config, consulta el artículo Ejecutar comprobaciones de solicitudes preparatorias.

(Opcional) Importar imágenes de SO a vSphere y enviar imágenes de contenedor a un registro privado

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

Tu clúster de usuarios está en un centro de datos de vSphere distinto del clúster de administrador.
El clúster de usuarios tiene un servidor vCenter diferente al del clúster de administradores.
El clúster de usuarios tiene una carpeta de vCenter diferente a la del clúster de administradores.
Tu clúster de usuario usa un registro de contenedores privado que es diferente del registro privado que usa tu clúster de administrador.

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

Haz los cambios siguientes:

ADMIN_CLUSTER_KUBECONFIG: la ruta del archivo kubeconfig de tu clúster de administrador
BUNDLE: la ruta del archivo del paquete. Este archivo se encuentra en la estación de trabajo de tu administrador, en /var/lib/gke/bundles/. Por ejemplo:
```
/var/lib/gke/bundles/gke-onprem-vsphere-1.33.0-gke.799-full.tgz
```
USER_CLUSTER_CONFIG: la ruta del archivo de configuración del clúster de usuarios

Crear clúster de usuarios

Ejecuta el siguiente comando para crear un clúster de usuarios:

gkectl create cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG --config USER_CLUSTER_CONFIG

Buscar el archivo kubeconfig del clúster de usuarios

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 de tu 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 quieres, puedes cambiar el nombre y la ubicación del archivo kubeconfig.

Verificar que el clúster de usuarios esté en funcionamiento

Verifica que tu clúster de usuario esté en funcionamiento:

kubectl get nodes --kubeconfig USER_CLUSTER_KUBECONFIG

Sustituye USER_CLUSTER_KUBECONFIG por la ruta del archivo kubeconfig de tu clúster de usuario.

El resultado muestra los nodos del clúster de usuarios. 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

Consola

Empezar

En la Google Cloud consola, ve a la página Crear clúster de VMs.

Ir a Crear clúster de VMs
Selecciona el Google Cloud proyecto en el que quieras crear el clúster. El proyecto seleccionado se usa como proyecto host de la flota. Debe ser el mismo proyecto en el que está registrado el clúster de administrador. Una vez creado el clúster de usuarios, se registra automáticamente en la flota del proyecto seleccionado.
En la sección Elige el tipo de clúster, selecciona Crear un clúster de usuario para un clúster de administrador.

Información básica de los clústeres

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

Introduce un nombre para el clúster de usuario.
En Clúster de administrador, selecciona el clúster de administrador de la lista. Si no has especificado un nombre para el clúster de administrador al crearlo, se generará un nombre 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 quieres usar, consulta la sección de solución de problemas El clúster de administrador no se muestra en la lista desplegable Conceptos básicos de los clústeres.
En el campo Ubicación de la API de GCP, selecciona la Google Cloud región de la lista. Este ajuste especifica la región en la que se ejecutan las siguientes APIs y servicios:
- API de GKE On-Prem (gkeonprem.googleapis.com)
- Servicio de flota (gkehub.googleapis.com)
- Conectar servicio (gkeconnect.googleapis.com)
Este ajuste también controla 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 gestionar 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 identifican de forma única el clúster en Google Cloud.
Selecciona la versión de Google Distributed Cloud para tu clúster de usuario.
Como creador del clúster, tienes privilegios de administrador del clúster. Opcionalmente, introduzca la dirección de correo de otro usuario que vaya a administrar el clúster en el campo Usuario administrador del clúster de 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 roles (RBAC) de Kubernetes al clúster para concederte 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 conceder algunos roles de gestión de identidades y accesos (IAM) a los usuarios que no sean propietarios del proyecto. Para obtener más información sobre cómo conceder los roles de gestión de identidades y accesos, consulta Conceder los 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 tienen valores predeterminados. Revisa los valores predeterminados y, si quieres, cámbialos según sea necesario.

En el campo vCPUs del nodo de plano de control, introduce el número de vCPUs (4 como mínimo) de cada nodo de plano de control de tu clúster de usuarios.
En el campo Memoria del nodo de plano de control, introduce el tamaño de la memoria en MiB (el mínimo es 8192 y debe ser un múltiplo de 4) de cada plano de control de tu clúster de usuarios.
En Nodos de plano de control, selecciona el número de nodos de plano de control de tu clúster de usuarios. 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.
También puedes seleccionar Cambio automático del tamaño de los nodos. Cambiar el tamaño significa que los recursos de vCPU y memoria asignados a un nodo se ajustan automáticamente. Cuando está habilitada, los nodos del plano de control del clúster de usuarios cambian de tamaño en función del número de nodos de trabajador del clúster de usuarios. Por lo tanto, a medida que añades más nodos de trabajador al clúster de usuarios, el tamaño de los nodos de plano de control aumenta.
En la sección IPs de nodos del plano de control, introduce las direcciones IP de la pasarela, la máscara de subred y los nodos del plano de control.
Haz clic en Siguiente para ir a la sección Redes.

Redes

En esta sección, se especifican las direcciones IP de los nodos, los pods y los servicios del clúster. Un clúster de usuarios necesita una dirección IP para cada nodo y una dirección IP adicional para un nodo temporal que se necesita durante las actualizaciones, las actualizaciones y la reparación automática del clúster. Para obtener más información, consulta ¿Cuántas direcciones IP necesita un clúster de usuarios?

En la sección IPs de nodos, selecciona el modo de IP del clúster de usuarios. Selecciona una de las opciones siguientes:
- DHCP: elige DHCP si quieres que los nodos del clúster obtengan su dirección IP de un servidor DHCP.
- Estático: elija Estático si quiere proporcionar direcciones IP estáticas para los nodos de su clúster o si quiere configurar el balanceo de carga manual.
Si has seleccionado DHCP, ve al siguiente paso para especificar los CIDRs de servicio y Pod. En el modo IP estática, proporciona la siguiente información:
1. Introduce la dirección IP de la puerta de enlace del clúster de usuarios.
2. Introduce la máscara de subred de los nodos del clúster de usuarios.
3. En la sección Direcciones IP, introduce las direcciones IP y, opcionalmente, los nombres de host de los nodos del clúster de usuarios. Puedes introducir una dirección IPv4 individual (como 192.0.2.1) o un bloque CIDR de direcciones IPv4 (como 192.0.2.0/24).
  - Si introduces un bloque CIDR, no introduzcas un nombre de host.
  - Si introduces una dirección IP individual, puedes introducir un nombre de host (opcional). Si no introduces un nombre de host, Google Distributed Cloud usará el nombre de la máquina virtual de vSphere como nombre de host.
4. Haz clic en + Añadir dirección IP según sea necesario para introducir más direcciones IP.
En la sección CIDRs de servicios y pods, la consola proporciona los siguientes intervalos de direcciones para tus servicios y pods de Kubernetes:
- CIDR de servicio: 10.96.0.0/20
- CIDR de pod: 192.168.0.0/16
Si prefieres introducir tus propios intervalos de direcciones, consulta las direcciones IP de pods y servicios para ver las prácticas recomendadas.
Si has seleccionado Modo IP estática o Habilitar control plane v2, especifica la siguiente información en la sección Configuración de host:
1. Introduce las direcciones IP de los servidores DNS.
2. Introduce las direcciones IP de los servidores NTP.
3. Opcionalmente, introduce dominios de búsqueda de DNS.
Haz clic en Siguiente para ir a la sección Balanceador de carga.

Balanceador de carga

Elige el balanceador de carga que quieras configurar para tu clúster. Consulta la descripción general de los balanceadores de carga para obtener más información.

Selecciona el Tipo de balanceador de carga de la lista.

Incluido con MetalLB

Configura el balanceo de carga agrupado con MetalLB. Solo puedes usar MetalLB en el clúster de usuario 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 de tu clúster y no requiere máquinas virtuales adicionales. Para obtener más información sobre las ventajas de usar MetalLB y cómo se compara con otras opciones de balanceo de carga, consulta Balanceo de carga agrupado con MetalLB.

En la sección Grupos de direcciones, configure al menos un grupo de direcciones de la siguiente manera:
1. Introduce un nombre para el grupo de direcciones.
2. Introduce un intervalo de direcciones IP que contenga la dirección IP virtual de entrada en notación CIDR (por ejemplo, 192.0.2.0/26) o notación de intervalo (por ejemplo, 192.0.2.64-192.0.2.72). Para especificar una sola dirección IP en un pool, usa /32 en la notación CIDR (por ejemplo, 192.0.2.1/32).
3. Si las direcciones IP de tus servicios de tipo LoadBalancer no están en el mismo intervalo de direcciones IP que la dirección IP virtual de entrada, haz clic en + Añadir intervalo de direcciones IP e introduce otro intervalo de direcciones.
  
  Las direcciones IP de cada grupo no pueden solaparse y deben estar en la misma subred que los nodos del clúster.
4. En Asignación de direcciones IP, seleccione una de las siguientes opciones:
  - Automático: elige esta opción si quieres que el controlador de MetalLB asigne automáticamente direcciones IP del grupo de direcciones a los servicios de tipo LoadBalancer.
  - Manual: elige esta opción si quieres usar direcciones del grupo para especificar manualmente las direcciones de los servicios de tipo LoadBalancer
5. Haz clic en Evitar direcciones IP con errores si quieres que el controlador de MetalLB no use direcciones del grupo que terminen en .0 o .255. De esta forma, se evita el problema de que los dispositivos de consumo con errores descarten por error el tráfico enviado a esas direcciones IP especiales.
6. Cuando hayas terminado, haz clic en Hecho.
Si es necesario, haz clic en Añadir grupo de direcciones.
En la sección IPs virtuales, introduce lo siguiente:
- IP virtual 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 del clúster de usuario se ejecuta en un nodo del clúster de administrador. Esta dirección IP debe estar en el mismo dominio de capa 2 que los nodos del clúster de administrador. No añadas esta dirección en la sección Grupos de direcciones.
- IP virtual de entrada: la dirección IP que se configurará en el balanceador de carga para el proxy de entrada. Debe añadirlo a un grupo de direcciones en la sección Grupos de direcciones.
Haz clic en Continuar.

F5 BIG-IP

Solo puedes usar F5 BIG-IP en el clúster de usuarios si tu clúster de administrador también lo usa. Asegúrate de instalar y configurar F5 BIG-IP ADC antes de integrarlo con Google Distributed Cloud.

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

En la sección IPs virtuales, introduce 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.
- IP virtual de entrada: la dirección IP que se configurará en el balanceador de carga para el proxy de entrada.
En el campo Dirección, introduce la dirección de tu balanceador de carga F5 BIG-IP.
En el campo Partition (Partición), introduzca el nombre de una partición de BIG-IP que haya creado para su clúster de usuarios.
En el campo Nombre del grupo de SNAT, introduce el nombre del grupo de SNAT, si procede.
Haz clic en Continuar.

Manual

Solo puedes usar un balanceador de carga manual para el clúster de usuarios si el clúster de administrador usa un balanceador de carga manual. En Google Distributed Cloud, 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 intervalo de 30000 a 32767 para estos servicios. En el proxy de entrada, elige un valor de nodePort para el tráfico HTTP y HTTPS. Consulta Habilitar el modo manual del balanceo de carga para obtener más información.

En la sección IPs virtuales, introduce 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.
- IP virtual de entrada: la dirección IP que se configurará en el balanceador de carga para el proxy de entrada.
En el campo Puerto del nodo del plano de control, introduce un valor nodePort para el servidor de la API de Kubernetes.
En el campo Puerto de nodo de Ingress para HTTP, introduce un valor nodePort para el tráfico HTTP al proxy de Ingress.
En el campo Puerto de nodo de Ingress para HTTPS, introduce un valor nodePort para el tráfico HTTPS al proxy de Ingress.
En el campo Puerto del nodo del servidor de Konnectivity, introduce un valor de nodePort para el servidor de Konnectivity.
Haz clic en Continuar.

Funciones

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

Las siguientes funciones se habilitan automáticamente y no se pueden inhabilitar:
- Cloud Logging de servicios del sistema
- Monitorización de servicios del sistema con Cloud Monitoring
- El registro de auditoría de la actividad del administrador
Las siguientes opciones están habilitadas de forma predeterminada, pero puedes inhabilitarlas:
- Habilita el controlador de CSI para vSphere: también se denomina complemento de almacenamiento de contenedores de vSphere. El controlador de la interfaz de almacenamiento de contenedores (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 Usar el controlador de la interfaz de almacenamiento de contenedores de vSphere.
- Habilita los grupos antiafinidad: se crean automáticamente reglas antiafinidad de Distributed Resource Scheduler (DRS) de VMware para los nodos de tu clúster de usuario, lo que hace que se distribuyan en al menos 3 hosts físicos de tu centro de datos. Asegúrate de que tu entorno de vSphere cumpla los requisitos.
Nota: Si has seguido los pasos de Configurar una infraestructura mínima, solo tienes un host ESXi, así que asegúrate de desactivar la opción Habilitar grupos antiafinidad.
Haga 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 de trabajo creados en este clúster. Para obtener más información, consulta el artículo Crear y gestionar grupos de nodos .

En la sección Valores predeterminados del grupo de nodos, haz lo siguiente:
1. Introduce el Nombre del grupo de nodos o acepta "default-pool" como nombre.
2. Introduce el número de vCPUs de cada nodo del grupo (un mínimo de 4 por cada trabajador del clúster de usuario).
3. Introduce el tamaño de la memoria en mebibytes (MiB) de cada nodo del grupo (el mínimo es de 8192 MiB por nodo de trabajo del clúster de usuario y debe ser un múltiplo de 4).
4. En el campo Nodos, introduce el número de nodos del pool (3 como mínimo). Si has introducido direcciones IP estáticas para las IPs de los nodos en la sección Redes, asegúrate de que has introducido suficientes direcciones IP para estos nodos del clúster de usuario.
5. Selecciona el tipo de imagen de SO: Ubuntu, Ubuntu Containerd o COS.
6. Introduce el tamaño del disco de arranque en gibibytes (GiB). El mínimo es 40 GiB.
7. Si usas MetalLB como balanceador de carga, debes habilitarlo en al menos un grupo de nodos. Deja seleccionada la opción Usar este grupo de nodos para el balanceo de carga de MetalLB o añade otro grupo de nodos para usarlo con MetalLB.
En la sección Metadatos del grupo de nodos (opcional), si quieres añadir etiquetas e intolerancias de Kubernetes, sigue estos pasos:
1. Haz clic en + Añadir etiquetas de Kubernetes. Introduce la clave y el valor de la etiqueta. Repite el proceso tantas veces como sea necesario.
2. Haz clic en + Añadir Taint. Introduce la clave, el valor y el efecto de la contaminación. Repite el proceso tantas veces como sea necesario.
Haz clic en Verificar y completar para crear el clúster de usuarios. La creación del clúster de usuarios 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 al verificar la configuración, la consola mostrará 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 solucionarlos, consulta Solucionar problemas de creación de clústeres de usuarios en la consola Google Cloud .

CLI de gcloud

Para crear un clúster de usuarios, usa el siguiente comando:

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 se corresponden con los campos del archivo de configuración del clúster de usuarios. Para ayudarte a empezar, puedes probar un comando completo en la sección Ejemplos.

Recoger información

Recoge la información que necesitas para crear el clúster.

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

El resultado debería ser 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 gestionan mediante los servicios globales de flota y de conexión. En la versión 1.28 y posteriores, puedes especificar global o una Google Cloud región al crear el clúster de administrador. En los comandos de ejemplo que se muestran a continuación, se especifica la región con la marca --admin-cluster-membership-location.
Para obtener una lista de las versiones disponibles, haz lo siguiente:
```
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
```
Haz los cambios siguientes:
- ADMIN_CLUSTER_NAME: nombre del clúster de administrador.
- FLEET_HOST_PROJECT_ID: ID del proyecto en el que está registrado el clúster de administrador.
- ADMIN_CLUSTER_REGION: la región de pertenencia a la flota del clúster de administrador. Puede ser global o de una Google Cloud región. Usa la ubicación del clúster de administradores de la salida de gcloud container fleet memberships list.
- REGION: la región que usarás al crear el clúster de usuarios. Google Cloud Es la región en la que se ejecuta la API de GKE On-Prem y almacena sus metadatos.
  - Si el clúster de administrador está registrado en la API de GKE On-Prem, usa la misma región que el clúster de administrador. Para consultar la región del clúster de administrador, ejecuta el siguiente comando:
```
gcloud container vmware admin-clusters list \
  --project=FLEET_HOST_PROJECT_ID \
  --location=-
```
  - Si el clúster de administrador no está registrado en la API de GKE On-Prem, especifica us-west1 u otra región admitida. Si posteriormente registras el clúster de administrador en la API de GKE On-Prem, usa la misma región que el clúster de usuario.
La salida del comando gcloud container vmware clusters query-version-config es similar a la siguiente:
```
versions:
- isInstalled: true
  version: 1.28.800-gke.109
- version: 1.29.0-gke.1456
- version: 1.29.100-gke.248
- version: 1.29.200-gke.245
- version: 1.29.300-gke.184
```
El comando también muestra una explicación de las versiones que puedes usar para crear o actualizar clústeres de usuarios. Las versiones permitidas se anotan con isInstalled: true, lo que significa que el clúster de administrador tiene los componentes específicos de la versión que necesita para gestionar los clústeres de usuario de esa versión. Si quieres usar una versión que esté instalada en el clúster de administrador, ve a la sección Ejemplos para crear el clúster de usuario.

Instalar otra versión

Un clúster de administrador puede gestionar clústeres de usuario con diferentes versiones. La salida del comando query-version-config muestra otras versiones que puedes usar al crear el clúster. Si quieres crear un clúster de usuarios con una versión diferente a la del clúster de administradores, debes descargar e implementar los componentes que necesita el clúster de administradores para gestionar clústeres de usuarios de esa versión, como se indica a continuación:

gcloud container vmware admin-clusters update ADMIN_CLUSTER_NAME \
    --project=FLEET_HOST_PROJECT_ID \
    --location=REGION \
    --required-platform-version=VERSION

Sustituye VERSION por una de las versiones que aparecen en el resultado del comando query-version-config.

El comando descarga la versión de los componentes que especifiques en --required-platform-version en el clúster de administrador y, a continuación, implementa los componentes. Ahora puedes crear un clúster de usuarios con la versión especificada.

Si vuelves a ejecutar gcloud container vmware clusters query-version-config, la versión que hayas especificado se anotará con isInstalled: true.

Ejemplos

En los siguientes ejemplos se muestra cómo crear un clúster de usuarios con diferentes balanceadores de carga con Controlplane V2 habilitado. Con Controlplane V2, el plano de control de un clúster de usuarios se ejecuta en uno o varios nodos del propio clúster de usuarios. Te recomendamos que habilites Controlplane V2. En la versión 1.30 y posteriores, los clústeres de usuario nuevos deben tener habilitado Controlplane V2. Para obtener información sobre las opciones de balanceo de carga disponibles, consulta el artículo Información general sobre los balanceadores de carga.

En la mayoría de los ejemplos se usan los valores predeterminados para configurar los nodos del plano de control. Si quieres cambiar alguno de los valores predeterminados, incluye las marcas descritas en la sección Marcas del plano de control. Si es necesario, también puedes cambiar algunos ajustes de vSphere.

Antes de ejecutar el comando gcloud para crear el clúster, puedes incluir --validate-only para validar la configuración que has especificado en las marcas del comando gcloud. Cuando quieras crear el clúster, elimina esta marca y ejecuta el comando.

Si aparece un error después de que el comando gcloud container vmware clusters create se haya ejecutado durante aproximadamente un minuto o más, comprueba si el clúster se ha creado parcialmente ejecutando el siguiente comando:

gcloud container vmware clusters list \
    --project=FLEET_HOST_PROJECT_ID \
    --location=-

Si el clúster no aparece en el resultado, corrige el error y vuelve a ejecutar gcloud container vmware clusters create.

Si el clúster aparece en el resultado, elimínalo con el siguiente comando:

gcloud container vmware clusters delete USER_CLUSTER_NAME \
    --project=FLEET_HOST_PROJECT_ID \
    --location=REGION \
    --force \
    --allow-missing

A continuación, corrige el error y vuelve a ejecutar gcloud container vmware clusters create.

Una vez que el clúster esté en funcionamiento, debes añadir un grupo de nodos antes de implementar cargas de trabajo, tal como se describe en la sección Crear un grupo de nodos.

MetalLB y DHCP

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

Solo puedes usar MetalLB en el clúster de usuario si tu clúster de administrador usa MetalLB. Esta opción de balanceo de carga requiere una configuración mínima. MetalLB se ejecuta directamente en los nodos de tu clúster y no requiere máquinas virtuales adicionales. Para obtener más información sobre las ventajas de usar MetalLB y cómo se compara con otras opciones de balanceo de carga, consulta Balanceo de carga agrupado con MetalLB.

El comando de ejemplo crea un clúster de usuario con las siguientes características, que puedes modificar según las necesidades de tu entorno.

Bandera	Descripción
`--admin-users`	Te concede a ti y a otro usuario derechos de administrador completos en el clúster.
`--enable-control-plane-v2`	Habilita Controlplane V2, que es la opción recomendada y obligatoria en la versión 1.30 y posteriores.
`--control-plane-ip-block`	Una dirección IP para el nodo del plano de control. Para crear un clúster de usuarios de alta disponibilidad, especifica tres direcciones IP y añade la marca `--replicas=3`.
`--metal-lb-config-address-pools`	Dos grupos de direcciones para el balanceador de carga MetalLB. Necesitas al menos un grupo de direcciones, pero puedes especificar más si es necesario. Para mayor comodidad, el ejemplo contiene un grupo de direcciones con el nombre "ingress-vip-pool" para recordar que la dirección IP del VIP de entrada debe estar en uno de los grupos de direcciones. Para especificar el CIDR de una sola dirección IP, añade `/32` a la dirección IP.

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=10.96.0.0/20 \
    --pod-address-cidr-blocks=192.168.0.0/16 \
    --metal-lb-config-address-pools='pool=NAME,avoid-buggy-ips=AVOID_BUGGY_IPS,manual-assign=MANUAL_ASSIGN,addresses=IP_ADDRESS_RANGE_1' \
    --metal-lb-config-address-pools='pool=ingress-vip-pool,avoid-buggy-ips=False,manual-assign=True,addresses=INGRESS_VIP/32' \
    --enable-control-plane-v2 \
    --dns-servers=DNS_SERVER_1 \
    --ntp-servers=NTP_SERVER_1 \
    --control-plane-ip-block 'gateway=CP_GATEWAY,netmask=CP_NETMASK,ips=CP_IP_ADDRESS_1 CP_HOST_1' \
    --control-plane-vip=CONTROL_PLANE_VIP \
    --ingress-vip=INGRESS_VIP \
    --enable-dhcp

Haz los cambios siguientes:

USER_CLUSTER_NAME: el nombre que elijas para el clúster de usuarios. El nombre no se puede cambiar después de crear el clúster. El nombre debe cumplir las condiciones siguientes:
- Contener un máximo de 40 caracteres
- Contener únicamente caracteres alfanuméricos en minúscula o un guion (-)
- Empezar por un carácter alfabético
- terminar con un carácter alfanumérico
FLEET_HOST_PROJECT_ID: el ID del proyecto en el que quieres crear el clúster. El proyecto especificado también se usa como proyecto host de la flota. Debe ser el mismo proyecto en el que está registrado el clúster de administrador. Una vez creado 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 una vez creado el clúster.
ADMIN_CLUSTER_NAME: el nombre del clúster de administrador que gestiona el clúster de usuario. En la marca --admin-cluster-membership, puedes usar el nombre de clúster totalmente especificado, que tiene el siguiente formato:
```
    projects/FLEET_HOST_PROJECT_ID/locations/ADMIN_CLUSTER_REGION/memberships/ADMIN_CLUSTER_NAME
```
También puedes definir --admin-cluster-membership con el nombre del clúster de administrador, como en el comando de ejemplo. Si solo usas el nombre del clúster de administrador, define 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 Google Cloud región. Si necesitas encontrar la región, ejecuta gcloud container fleet memberships list.
REGION: la región en la que se ejecutan la API de GKE On-Prem ( Google Cloud ), el servicio Fleet (gkeonprem.googleapis.com) y el servicio Connect (gkehub.googleapis.com).gkeconnect.googleapis.com Especifica us-west1 u otra región admitida. La región no se puede cambiar después de crear el clúster. Este ajuste 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 gestionar 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 identifican de forma única el clúster en Google Cloud.

Importante: Si tienes previsto instalar Cloud Service Mesh, debes instalar la versión 1.19.3 o una posterior. Esto es necesario porque los servicios Fleet y Connect se ejecutan en una región.
VERSION: la versión de Google Distributed Cloud de tu 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 concederán privilegios de administrador del clúster de forma predeterminada. Sin embargo, si incluyes --admin-users para designar a otro usuario como administrador, se anulará el valor predeterminado y deberás incluir tanto tu dirección de correo como la del otro administrador. Por ejemplo, para añadir dos administradores, sigue estos pasos:
```
    --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 concederte 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 control de acceso basado en roles (RBAC) de Kubernetes, debes asignar algunos roles de gestión de identidades y accesos (IAM) a los usuarios que no sean propietarios del proyecto. Para obtener más información sobre cómo conceder los roles de gestión de identidades y accesos, consulta el artículo Conceder los roles necesarios.

SERVICE_CIDR_BLOCK: un intervalo de direcciones IP en formato CIDR que se usará para los servicios de tu clúster. Debe ser al menos un intervalo /24.
Ejemplo: --service-address-cidr-blocks=10.96.0.0/20
POD_CIDR_BLOCK: intervalo de direcciones IP en formato CIDR que se usará para los pods de tu clúster. Debe ser al menos un intervalo /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 utilizará el balanceador de carga 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 empiezan por las palabras clave pool, avoid-buggy-ip, manual-assign y addresses. Separa cada segmento con una coma.
- pool: el nombre que elijas para el grupo.
- avoid-buggy-ips1: Si le asignas el valor True, el controlador de MetalLB no asignará a los servicios direcciones IP que terminen en .0 o .255. De esta forma, se evita el problema de que los dispositivos de consumo con errores descarten por error el tráfico enviado a esas direcciones IP especiales. Si no se especifica ningún valor, se utiliza False de forma predeterminada.
- manual-assign: Si no quieres que el controlador de MetalLB asigne automáticamente direcciones IP de este grupo a los servicios, define este valor como True. Después, un desarrollador puede crear un servicio de tipo LoadBalancer y especificar manualmente una de las direcciones del grupo. Si no se especifica, manual-assign se define como False.
- En la lista de addresses, cada dirección debe ser un intervalo en notación CIDR o en formato de intervalo con guion. Para especificar una sola dirección IP en un pool (por ejemplo, para la IP virtual de entrada), usa /32 en la notación CIDR. Por ejemplo: 192.0.2.1/32.
Ten en cuenta lo siguiente:
- Escribe todo el valor entre comillas simples.
- No se permiten espacios.
- Separe cada intervalo 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 has elegido para configurar en el balanceador de carga del 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 has elegido para configurar en el balanceador de carga del proxy de entrada.
Ejemplo: --ingress-vip=10.251.134.80

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

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

MetalLB e IPs estáticas

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

El comando de ejemplo crea un clúster de usuario con las siguientes características, que puedes modificar según las necesidades de tu entorno.

Bandera	Descripción
`--admin-users`	Te concede a ti y a otro usuario derechos de administrador completos en el clúster.
`--enable-control-plane-v2`	Habilita Controlplane V2, que es la opción recomendada y obligatoria en la versión 1.30 y posteriores.
`--control-plane-ip-block`	Una dirección IP para el nodo del plano de control. Para crear un clúster de usuarios de alta disponibilidad, especifica tres direcciones IP y añade la marca `--replicas=3`.
`--metal-lb-config-address-pools`	Dos grupos de direcciones para el balanceador de carga MetalLB. Necesitas al menos un grupo de direcciones, pero puedes especificar más si es necesario. Para mayor comodidad, el ejemplo contiene un grupo de direcciones con el nombre "ingress-vip-pool" para recordar que la dirección IP del VIP de entrada debe estar en uno de los grupos de direcciones. Para especificar el CIDR de una sola dirección IP, añade `/32` a la dirección IP.
`--static-ip-config-ip-blocks`	Cuatro direcciones IP para los nodos de trabajador de los clústeres. Esto incluye una dirección para un nodo adicional que se puede usar durante la actualización. Puedes especificar más direcciones IP si es necesario. El nombre de host es opcional.

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=10.96.0.0/20 \
    --pod-address-cidr-blocks=192.168.0.0/16 \
    --metal-lb-config-address-pools='pool=NAME,avoid-buggy-ips=AVOID_BUGGY_IPS,manual-assign=MANUAL_ASSIGN,addresses=IP_ADDRESS_RANGE_1' \
    --metal-lb-config-address-pools='pool=ingress-vip-pool,avoid-buggy-ips=False,manual-assign=True,addresses=INGRESS_VIP/32' \
    --enable-control-plane-v2 \
    --control-plane-ip-block 'gateway=CP_GATEWAY,netmask=CP_NETMASK,ips=CP_IP_ADDRESS_1 CP_HOST_1' \
    --control-plane-vip=CONTROL_PLANE_VIP \
    --ingress-vip=INGRESS_VIP \
    --static-ip-config-ip-blocks='gateway=GATEWAY,netmask=NETMASK,ips=IP_ADDRESS_1 HOST_1;IP_ADDRESS_2 HOST_2;IP_ADDRESS_3 HOST_3;IP_ADDRESS_4 HOST_4' \
    --dns-servers=DNS_SERVER_1 \
    --ntp-servers=NTP_SERVER_1

Haz los cambios siguientes:

USER_CLUSTER_NAME: el nombre que elijas para el clúster de usuarios. El nombre no se puede cambiar después de crear el clúster. El nombre debe cumplir las condiciones siguientes:
- Contener un máximo de 40 caracteres
- Contener únicamente caracteres alfanuméricos en minúscula o un guion (-)
- Empezar por un carácter alfabético
- terminar con un carácter alfanumérico
FLEET_HOST_PROJECT_ID: el ID del proyecto en el que quieres crear el clúster. El proyecto especificado también se usa como proyecto host de la flota. Debe ser el mismo proyecto en el que está registrado el clúster de administrador. Una vez creado 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 una vez creado el clúster.
ADMIN_CLUSTER_NAME: el nombre del clúster de administrador que gestiona el clúster de usuario. En la marca --admin-cluster-membership, puedes usar el nombre de clúster totalmente especificado, que tiene el siguiente formato:
```
    projects/FLEET_HOST_PROJECT_ID/locations/ADMIN_CLUSTER_REGION/memberships/ADMIN_CLUSTER_NAME
```
También puedes definir --admin-cluster-membership con el nombre del clúster de administrador, como en el comando de ejemplo. Si solo usas el nombre del clúster de administrador, define 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 Google Cloud región. Si necesitas encontrar la región, ejecuta gcloud container fleet memberships list.
REGION: la región en la que se ejecutan la API de GKE On-Prem ( Google Cloud ), el servicio Fleet (gkeonprem.googleapis.com) y el servicio Connect (gkehub.googleapis.com).gkeconnect.googleapis.com Especifica us-west1 u otra región admitida. La región no se puede cambiar después de crear el clúster. Este ajuste 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 gestionar 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 identifican de forma única el clúster en Google Cloud.

Importante: Si tienes previsto instalar Cloud Service Mesh, debes instalar la versión 1.19.3 o una posterior. Esto es necesario porque los servicios Fleet y Connect se ejecutan en una región.
VERSION: la versión de Google Distributed Cloud de tu 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 concederán privilegios de administrador del clúster de forma predeterminada. Sin embargo, si incluyes --admin-users para designar a otro usuario como administrador, se anulará el valor predeterminado y deberás incluir tanto tu dirección de correo como la del otro administrador. Por ejemplo, para añadir dos administradores, sigue estos pasos:
```
    --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 concederte 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 control de acceso basado en roles (RBAC) de Kubernetes, debes asignar algunos roles de gestión de identidades y accesos (IAM) a los usuarios que no sean propietarios del proyecto. Para obtener más información sobre cómo conceder los roles de gestión de identidades y accesos, consulta el artículo Conceder los roles necesarios.

SERVICE_CIDR_BLOCK: un intervalo de direcciones IP en formato CIDR que se usará para los servicios de tu clúster. Debe ser al menos un intervalo /24.
Ejemplo: --service-address-cidr-blocks=10.96.0.0/20
POD_CIDR_BLOCK: intervalo de direcciones IP en formato CIDR que se usará para los pods de tu clúster. Debe ser al menos un intervalo /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 utilizará el balanceador de carga 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 empiezan por las palabras clave pool, avoid-buggy-ip, manual-assign y addresses. Separa cada segmento con una coma.
- pool: el nombre que elijas para el grupo.
- avoid-buggy-ips1: Si le asignas el valor True, el controlador de MetalLB no asignará a los servicios direcciones IP que terminen en .0 o .255. De esta forma, se evita el problema de que los dispositivos de consumo con errores descarten por error el tráfico enviado a esas direcciones IP especiales. Si no se especifica ningún valor, se utiliza False de forma predeterminada.
- manual-assign: Si no quieres que el controlador de MetalLB asigne automáticamente direcciones IP de este grupo a los servicios, define este valor como True. Después, un desarrollador puede crear un servicio de tipo LoadBalancer y especificar manualmente una de las direcciones del grupo. Si no se especifica, manual-assign se define como False.
- En la lista de addresses, cada dirección debe ser un intervalo en notación CIDR o en formato de intervalo con guion. Para especificar una sola dirección IP en un pool (por ejemplo, para la IP virtual de entrada), usa /32 en la notación CIDR. Por ejemplo: 192.0.2.1/32.
Ten en cuenta lo siguiente:
- Escribe todo el valor entre comillas simples.
- No se permiten espacios.
- Separe cada intervalo 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 has elegido para configurar en el balanceador de carga del 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 has elegido para configurar en el balanceador de carga del proxy de entrada.
Ejemplo: --ingress-vip=10.251.134.80

La dirección IP de 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 de los nodos de trabajador del 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 empiezan por las palabras clave gateway, netmask y ips. Separa los segmentos con una coma.

Ten en cuenta lo siguiente:
- Escribe todo el valor entre comillas simples.
- No se permiten espacios, excepto entre una dirección IP y un nombre de host.
En la lista de direcciones IP:
- Puedes especificar una dirección IP individual o un bloque CIDR de direcciones IP.
- Separa cada dirección IP o bloque CIDR con un punto y coma.
- En el caso de una dirección IP concreta, puedes 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 no especificas un nombre de host, Google Distributed Cloud usará el nombre de la máquina virtual de vSphere como nombre de host.
- Si especifica un bloque CIDR, no especifique ningún 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: lista separada por comas de las direcciones IP de los servidores DNS de las VMs.
DNS_SEARCH_DOMAIN: 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: lista separada por comas de las direcciones IP de los servidores de tiempo que usarán las VMs.

Balanceo de carga manual e IPs estáticas

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

Solo puede usar un balanceador de carga manual para el clúster de usuario si su clúster de administrador usa un balanceador de carga manual. En Google Distributed Cloud, el servidor de la API de Kubernetes, el proxy de entrada y el servicio complementario para la agregación de registros se exponen mediante un servicio de Kubernetes de tipo LoadBalancer. Elige tus propios valores de nodePort en el intervalo de 30.000 a 32.767 para estos servicios. En el proxy de entrada, elige un valor de nodePort para el tráfico HTTP y HTTPS. Consulta Habilitar el modo manual del balanceo de carga para obtener más información.

El comando de ejemplo crea un clúster de usuario con las siguientes características, que puedes modificar según las necesidades de tu entorno.

Bandera	Descripción
`--admin-users`	Te concede a ti y a otro usuario derechos de administrador completos en el clúster.
`--enable-control-plane-v2`	Habilita Controlplane V2, que es la opción recomendada y obligatoria en la versión 1.30 y posteriores.
`--control-plane-ip-block`	Una dirección IP para el nodo del plano de control. Para crear un clúster de usuarios de alta disponibilidad, especifica tres direcciones IP y añade la marca `--replicas=3`.
`--static-ip-config-ip-blocks`	Cuatro direcciones IP para los nodos de trabajador de los clústeres. Esto incluye una dirección para un nodo adicional que se puede usar durante la actualización. Puedes especificar más direcciones IP si es necesario. El nombre de host es opcional.

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=10.96.0.0/20 \
    --pod-address-cidr-blocks=192.168.0.0/16 \
    --enable-control-plane-v2 \
    --control-plane-ip-block 'gateway=CP_GATEWAY,netmask=CP_NETMASK,ips=CP_IP_ADDRESS_1 CP_HOST_1' \
    --control-plane-vip=CONTROL_PLANE_VIP \
    --ingress-vip=INGRESS_VIP \
    --ingress-http-node-port=INGRESS_HTTP_NODE_PORT \
    --ingress-https-node-port=INGRESS_HTTPS_NODE_PORT \
    --static-ip-config-ip-blocks='gateway=GATEWAY,netmask=NETMASK,ips=IP_ADDRESS_1 HOST_1;IP_ADDRESS_2 HOST_2;IP_ADDRESS_3 HOST_3;IP_ADDRESS_4 HOST_4' \
    --dns-servers=DNS_SERVER_1 \
    --ntp-servers=NTP_SERVER_1

Haz los cambios siguientes:

USER_CLUSTER_NAME: el nombre que elijas para el clúster de usuarios. El nombre no se puede cambiar después de crear el clúster. El nombre debe cumplir las condiciones siguientes:
- Contener un máximo de 40 caracteres
- Contener únicamente caracteres alfanuméricos en minúscula o un guion (-)
- Empezar por un carácter alfabético
- terminar con un carácter alfanumérico
FLEET_HOST_PROJECT_ID: el ID del proyecto en el que quieres crear el clúster. El proyecto especificado también se usa como proyecto host de la flota. Debe ser el mismo proyecto en el que está registrado el clúster de administrador. Una vez creado 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 una vez creado el clúster.
ADMIN_CLUSTER_NAME: el nombre del clúster de administrador que gestiona el clúster de usuario. En la marca --admin-cluster-membership, puedes usar el nombre de clúster totalmente especificado, que tiene el siguiente formato:
```
    projects/FLEET_HOST_PROJECT_ID/locations/ADMIN_CLUSTER_REGION/memberships/ADMIN_CLUSTER_NAME
```
También puedes definir --admin-cluster-membership con el nombre del clúster de administrador, como en el comando de ejemplo. Si solo usas el nombre del clúster de administrador, define 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 Google Cloud región. Si necesitas encontrar la región, ejecuta gcloud container fleet memberships list.
REGION: la región en la que se ejecutan la API de GKE On-Prem ( Google Cloud ), el servicio Fleet (gkeonprem.googleapis.com) y el servicio Connect (gkehub.googleapis.com).gkeconnect.googleapis.com Especifica us-west1 u otra región admitida. La región no se puede cambiar después de crear el clúster. Este ajuste 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 gestionar 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 identifican de forma única el clúster en Google Cloud.

Importante: Si tienes previsto instalar Cloud Service Mesh, debes instalar la versión 1.19.3 o una posterior. Esto es necesario porque los servicios Fleet y Connect se ejecutan en una región.
VERSION: la versión de Google Distributed Cloud de tu 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 concederán privilegios de administrador del clúster de forma predeterminada. Sin embargo, si incluyes --admin-users para designar a otro usuario como administrador, se anulará el valor predeterminado y deberás incluir tanto tu dirección de correo como la del otro administrador. Por ejemplo, para añadir dos administradores, sigue estos pasos:
```
    --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 concederte 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 control de acceso basado en roles (RBAC) de Kubernetes, debes asignar algunos roles de gestión de identidades y accesos (IAM) a los usuarios que no sean propietarios del proyecto. Para obtener más información sobre cómo conceder los roles de gestión de identidades y accesos, consulta el artículo Conceder los roles necesarios.

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

CONTROL_PLANE_VIP: la dirección IP que has elegido para configurar en el balanceador de carga del 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 has elegido para configurar en el balanceador de carga del proxy de entrada.

Ejemplo: --ingress-vip=203.0.113.4
INGRESS_HTTP_NODE_PORT: un valor de nodePort para el tráfico HTTP al proxy de entrada (como 30243).
INGRESS_HTTPS_NODE_PORT: un valor de nodePort para el tráfico HTTPS al proxy de entrada (como 30879).

--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 de los nodos de trabajador del 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 empiezan por las palabras clave gateway, netmask y ips. Separa los segmentos con una coma.

Ten en cuenta lo siguiente:
- Escribe todo el valor entre comillas simples.
- No se permiten espacios, excepto entre una dirección IP y un nombre de host.
En la lista de direcciones IP:
- Puedes especificar una dirección IP individual o un bloque CIDR de direcciones IP.
- Separa cada dirección IP o bloque CIDR con un punto y coma.
- En el caso de una dirección IP concreta, puedes 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 no especificas un nombre de host, Google Distributed Cloud usará el nombre de la máquina virtual de vSphere como nombre de host.
- Si especifica un bloque CIDR, no especifique ningún 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: lista separada por comas de las direcciones IP de los servidores DNS de las VMs.
DNS_SEARCH_DOMAIN: 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: lista separada por comas de las direcciones IP de los servidores de tiempo que usarán las VMs.

Marcas del plano de control

Si quieres usar valores no predeterminados para la configuración del plano de control, incluye una o varias de las siguientes marcas:

--cpus=vCPUS: número de vCPUs (mínimo 4) de cada nodo del plano de control de tu clúster de usuario. Si no se especifica, el valor predeterminado es 4 vCPUs.
--memory=MEMORY: tamaño de la memoria en mebibytes (MiB) de cada plano de control de tu clúster de usuario. El valor mínimo es 8192 y debe ser un múltiplo de 4. Si no se especifica, el valor predeterminado es 8192.
--replicas=NODES: número de nodos del plano de control de tu clúster de usuarios. 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.
--enable-auto-resize: si quieres habilitar el cambio de tamaño automático de los nodos del plano de control del clúster de usuarios, incluye --enable-auto-resize. Cambiar el tamaño significa que los recursos de vCPU y memoria asignados a un nodo se ajustan automáticamente. Si está habilitada, los nodos del plano de control del clúster de usuarios se redimensionan en función del número de nodos de trabajador del clúster de usuarios. Por lo tanto, a medida que añadas más nodos de trabajador al clúster de usuarios, aumentará el tamaño de los nodos de plano de control.
--enable-control-plane-v2: Para habilitar Controlplane V2, que es la opción que recomendamos, incluye esta marca. Cuando Controlplane V2 está habilitado, el plano de control de un clúster de usuarios se ejecuta en uno o varios nodos del propio clúster de usuarios. En la versión 1.30 y posteriores, se requiere Controlplane V2.

Cuando habilites Controlplane V2, también debes especificar las siguientes marcas:
- --dns-servers=DNS_SERVER_1,...: lista separada por comas de las direcciones IP de los servidores DNS de las máquinas virtuales.
- --ntp-servers=NTP_SERVER_1,...: lista separada por comas de las direcciones IP de los servidores de tiempo que deben usar las VMs.
- --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 empiezan por las palabras clave gateway, netmask y ips. Separa los segmentos con una coma.
  
  Ten en cuenta lo siguiente:
  - Escribe 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:
  - Puedes especificar una dirección IP individual o un bloque de direcciones IP CIDR.
  - Separa cada dirección IP o bloque CIDR con un punto y coma.
  - En el caso de una dirección IP concreta, puede 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 especifica un bloque CIDR, no especifique ningún 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,...: 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
```
Para ver una lista completa de las marcas y sus descripciones, consulta la referencia de la herramienta de línea de comandos gcloud.

Marcas de vSphere

Si es necesario, especifique las siguientes marcas opcionales:
--disable-aag-config: Si no incluye esta marca, se crearán automáticamente las reglas de antiafinidad de Distributed Resource Scheduler (DRS) de VMware para los nodos de su clúster de usuario, lo que hará que se distribuyan en al menos 3 hosts físicos de su centro de datos. Asegúrate de que tu entorno de vSphere cumpla los requisitos. Si tu clúster no cumple los requisitos, incluye esta marca.

Nota: Si ha seguido los pasos de Configurar la infraestructura mínima, solo tendrá un host ESXi, así que asegúrese 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 desplegado en vSphere para aprovisionar volúmenes persistentes en el almacenamiento de vSphere. Para obtener más información, consulta Usar el controlador de la interfaz de almacenamiento de contenedores de vSphere. Si no quieres desplegar los componentes de CSI, incluye esta marca.

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

Monitorizar el progreso de la creación de clústeres

El resultado del comando de creación del clúster 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 cadena operation-1679543737105-5f7893fd5bae9-942b3f97-75e59179 es el OPERATION_ID de la operación de larga duración. Puedes consultar 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 usuarios tarda 15 minutos o más. Puedes ver el clúster en la consola, en la página Clústeres de GKE. Google Cloud

Crear un grupo de nodos

Una vez creado el clúster, debes crear al menos un grupo de nodos antes de desplegar 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
```
Haz los cambios siguientes:
NODE_POOL_NAME: el nombre que quieras darle al grupo de nodos. El nombre debe cumplir los siguientes requisitos:
- Contener un máximo de 40 caracteres
- Contener únicamente caracteres alfanuméricos en minúscula o un guion (-)
- Empezar por un carácter alfabético
- terminar con un carácter alfanumérico
USER_CLUSTER_NAME: nombre del clúster de usuarios recién creado.
FLEET_HOST_PROJECT_ID: el ID del proyecto en el que está registrado el clúster.
REGION: la región Google Cloud que especificaste al crear el clúster.
IMAGE_TYPE: el tipo de imagen de SO que se ejecutará en las VMs del grupo de nodos. Puede tener uno de los siguientes valores: ubuntu_containerd o cos.
BOOT_DISK_SIZE: tamaño del disco de arranque en gibibytes (GiB) de cada nodo del grupo. El mínimo es de 40 GiB.
vCPUs: número de vCPUs de cada nodo del grupo de nodos. El mínimo es 4.
MEMORY: tamaño de la memoria en mebibytes (MiB) de cada nodo del grupo. El mínimo es de 8192 MiB por nodo de trabajador del clúster de usuarios y el valor debe ser un múltiplo de 4.
NODES: número de nodos del grupo de nodos. El mínimo es 3.
Si usas MetalLB como balanceador de carga, puedes incluir --enable-load-balancer si quieres permitir que el altavoz 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 usarlo con MetalLB.

Para obtener información sobre las marcas opcionales, consulta Añadir un grupo de nodos y la referencia de la CLI de gcloud.

Comandos de gcloud de ejemplo

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/us-west1/memberships/admin-cluster-1 \
    --version=1.32.300-gke.85 \
    --admin-users=sara@example.com \
    --admin-users=amal@example.com \
    --enable-dhcp \
    --service-address-cidr-blocks=10.96.0.0/20 \
    --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=192.0.2.0/26;pool=lb-ingress-vip-pool,manual-assign=True,addresses=198.51.100.1/32' \
    --enable-control-plane-v2 \
    --control-plane-vip=203.0.113.1 \
    --ingress-vip=198.51.100.1

MetalLB e IPs estáticas

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.32.300-gke.85 \
    --admin-users=sara@example.com \
    --admin-users=amal@example.com \
    --static-ip-config-ip-blocks='gateway=192.0.2.254,netmask=255.255.255.0,ips=192.0.2.10 user-vm-1;192.0.2.11 user-vm-2' \
    --static-ip-config-ip-blocks='gateway=192.0.2.254,netmask=255.255.255.0,ips=192.0.2.12 user-vm-3;192.0.2.13 extra-vm' \
    --dns-servers=203.0.113.1,203.0.113.2  \
    --dns-search-domains=example.com,altostrat.com \
    --ntp-servers=203.0.113.3,203.0.113.4 \
    --service-address-cidr-blocks=10.96.0.0/20 \
    --pod-address-cidr-blocks=192.168.0.0/16 \
    --enable-control-plane-v2 \
    --control-plane-ip-block 'gateway=192.0.2.254,netmask=255.255.255.0,ips=198.51.100.1 cp-vm-1;198.51.100.2 cp-vm-2;198.51.100.3 cp-vm-3' \
    --replicas=3 \
    --metal-lb-config-address-pools='pool=lb-pool-1,manual-assign=False,avoid-buggy-ips=True,addresses=192.0.2.0/26;lb-ingress-vip-pool,manual-assign=True,addresses=198.51.100.1/32' \
    --control-plane-vip=172.16.20.61 \
    --ingress-vip=172.16.20.62

Balanceo de carga manual e IPs 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/asia-east1/memberships/admin-cluster-1 \
    --version=1.32.300-gke.85 \
    --admin-users=sara@example.com \
    --admin-users=amal@example.com \
    --static-ip-config-ip-blocks='gateway=192.0.2.254,netmask=255.255.255.0,ips=192.0.2.10 user-vm-1;192.0.2.11 user-vm-2';ips=192.0.2.12 user-vm-3;192.0.2.13 extra-vm'\
    --dns-servers=203.0.113.1,203.0.113.2  \
    --ntp-servers=203.0.113.3,203.0.113.4 \
    --service-address-cidr-blocks=10.96.0.0/20 \
    --pod-address-cidr-blocks=192.168.0.0/16 \
    --enable-control-plane-v2 \
    --control-plane-ip-block 'gateway=192.0.2.254,netmask=255.255.255.0,ips=198.51.100.1 cp-vm-1;198.51.100.2 cp-vm-2;198.51.100.3 cp-vm-3' \
    --replicas=3 \
    --control-plane-vip=192.0.2.60 \
    --ingress-vip=192.0.2.50 \
    --ingress-http-node-port=30243 \
    --ingress-https-node-port=30879

Terraform

Antes de empezar

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

El resultado debería ser 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 gestionan mediante los servicios globales de flota y de conexión. En la versión 1.28 y posteriores, puedes especificar global o una Google Cloud región al crear el clúster.
Para obtener una lista de las versiones disponibles, haz lo siguiente:
```
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
```
Haz los cambios siguientes:
- ADMIN_CLUSTER_NAME: nombre del clúster de administrador.
- FLEET_HOST_PROJECT_ID: ID del proyecto en el que está registrado el clúster de administrador.
- ADMIN_CLUSTER_REGION: la región de pertenencia a la flota del clúster de administrador. Puede ser global o de una Google Cloud región. Usa la ubicación del clúster de administradores de la salida de gcloud container fleet memberships list.
- REGION: la Google Cloud región que usarás al crear el clúster. Es la región en la que se ejecutan la API de GKE On-Prem y los servicios Fleet y Connect. Especifica us-west1 u otra región admitida.
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
```
El comando también muestra una explicación de las versiones que puedes usar para crear o actualizar un clúster de usuarios. Las versiones permitidas se anotan con isInstalled: true, lo que significa que el clúster de administrador tiene los componentes específicos de la versión que necesita para gestionar los clústeres de usuario de esa versión. Si quieres usar una versión que esté instalada en el clúster de administrador, ve a la sección Ejemplo para crear el clúster de usuario.

Instalar otra versión

gcloud container vmware admin-clusters update ADMIN_CLUSTER_NAME \
    --project=FLEET_HOST_PROJECT_ID \
    --location=REGION \
    --required-platform-version=VERSION

Sustituye VERSION por una de las versiones que aparecen en el resultado del comando query-version-config.

Si vuelves a ejecutar gcloud container vmware clusters query-version-config, la versión que hayas especificado se anotará con isInstalled: true.

Ejemplo

Puede usar la siguiente configuración básica de ejemplo para crear un clúster de usuario con el balanceador de carga MetalLB incluido 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.

Definir variables en `terraform.tfvars`

El ejemplo proporciona un archivo de variables de ejemplo que se debe pasar a main.tf, que muestra cómo configurar el balanceador de carga MetalLB incluido y cómo habilitar los nodos del clúster para que obtengan sus direcciones IP de un servidor DHCP que proporciones.

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

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

Haz 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 quieres crear el clúster. El proyecto especificado también se usa como proyecto host de la flota. Debe ser el mismo proyecto en el que está registrado el clúster de administrador. Una vez creado 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 crear el clúster.
- region: la región en la que se ejecutan la API GKE On-Prem (gkeonprem.googleapis.com), el servicio de flota (gkehub.googleapis.com) y el servicio Connect (gkeconnect.googleapis.com). Google Cloud Especifica us-west1 u otra región admitida.
- admin_cluster_name: nombre del clúster de administrador que gestiona el clúster de usuario. En el ejemplo se da por supuesto que el clúster de administrador usa global como región. Si tienes un clúster de administradores regional:
  1. Abre main.tf en un editor de texto.
  2. Busca admin_cluster_membership, que tiene este aspecto:
```
admin_cluster_membership = "projects/${var.project_id}/locations/global/memberships/${var.admin_cluster_name}"
```
  1. Cambia global por la región que usa el clúster de administrador y guarda el archivo.
- on_prem_version: la versión de Google Distributed Cloud de tu clúster de usuario.
- admin_user_emails: lista de direcciones de correo de los usuarios a los que se les concederán privilegios de administrador en el clúster. Asegúrate de añadir tu dirección de correo si tienes intención de 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 roles (RBAC) de Kubernetes al clúster para conceder a los 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. También permite a los usuarios iniciar sesión en la consola con su identidad de Google.
- cluster_name: el nombre que elijas para el clúster de usuarios. El nombre no se puede cambiar después de crear el clúster. El nombre debe cumplir los siguientes requisitos:
  - Contener un máximo de 40 caracteres
  - Contener únicamente caracteres alfanuméricos en minúscula o un guion (-)
  - Empezar por un carácter alfabético
  - terminar con un carácter alfanumérico
- control_plane_node_cpus: número de vCPUs de cada nodo del plano de control de tu clúster de usuario. El mínimo es de 4 vCPUs.
- control_plane_node_memory: tamaño de la memoria en mebibytes (MiB) de cada plano de control de tu clúster de usuario. El valor mínimo es 8192 y debe ser un múltiplo de 4.
- control_plane_node_replicas: número de nodos del plano de control de tu clúster de usuarios. Por ejemplo, puede introducir 1 nodo del plano de control para un entorno de desarrollo y 3 nodos del plano de control para entornos de producción de alta disponibilidad.
- control_plane_vip: la dirección IP virtual (VIP) que has elegido para configurar en el balanceador de carga del servidor de la API de Kubernetes del clúster de usuario.
- ingress_vip: la dirección IP que has elegido para configurar en el balanceador de carga del proxy de entrada.
- lb_address_pools: lista de mapas que definen los grupos de direcciones que utilizará el balanceador de carga de MetalLB. El VIP de entrada debe estar en uno de estos pools. Especifica lo siguiente:
  - name: nombre del grupo.
  - addresses: un intervalo de direcciones en notación CIDR o en formato de intervalo con guiones. Para especificar una sola dirección IP en un pool (por ejemplo, para la IP virtual de entrada), usa /32 en la notación CIDR. Por ejemplo: 192.0.2.1/32.
  Sustituye las direcciones IP de ejemplo por tus valores y añade grupos de direcciones adicionales si es necesario.
Guarda los cambios en terraform.tfvars. Si no quieres hacer ningún cambio opcional en main.tf, ve a la sección siguiente, Crea el clúster y un grupo de nodos.

Configurar Controlplane V2

En la versión 1.30 y posteriores, debes habilitar Controlplane V2. El archivo main.tf del ejemplo no habilita Controlplane V2. Debes cambiar main.tf para habilitar Controlplane V2 y añadir las direcciones IP de la pasarela, la máscara de red y los nodos del plano de control. Antes de hacer cambios, crea una copia de seguridad de main.tf:

  cp main.tf main.tf.bak

Para configurar Controlplane V2, haz los siguientes cambios en main.tf:

Añade la siguiente línea al bloque resource:
```
  enable_control_plane_v2 = "true"
```

Añade un mapa de 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"
      }
    }
  }

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

Opcional: Habilitar clúster avanzado

De forma predeterminada, en la versión 1.32 y posteriores, los clústeres de usuarios creados con Terraform no tienen habilitada la función de clúster avanzado. Si quieres habilitar el clúster avanzado, añade el siguiente campo de nivel superior a main.tf:

enable_advanced_cluster = true

Consulta las diferencias al ejecutar clústeres avanzados antes de habilitar esta opción.

Opcional: Modo de direccionamiento IP de los nodos de trabajo

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

cp main.tf main.tf.bak

De forma predeterminada, main.tf configura el clúster para que use un servidor DHCP que proporciones para asignar direcciones IP a los nodos de trabajador del clúster. DHCP se configura incluyendo el mapa dhcp_config en el bloque network_config. Si quieres proporcionar direcciones IP estáticas a tus nodos de trabajo, haz los siguientes cambios en main.tf:

Sustituye 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"
        }
      }
    }
  }

Sustituye los siguientes valores por los tuyos:
- service_address_cidr_blocks: intervalo de direcciones IP en formato CIDR que se usará para los servicios de tu clúster. Debe ser al menos un intervalo /24.
- pod_address_cidr_blocks: intervalo de direcciones IP en formato CIDR que se usará para los pods de tu clúster. Debe ser al menos un intervalo /18.
- dns_servers: lista de las direcciones IP de los servidores DNS de las máquinas virtuales.
- ntp_servers: lista de las direcciones IP de los servidores de tiempo que deben usar las VMs.
- En el bloque static_ip_config, sustituya los valores de netmask y gateway por las direcciones de su red. Sustituye ip y hostname por las direcciones IP y los nombres de host de tus nodos de trabajo.

Crear el clúster y un grupo de nodos

Inicializa y crea el plan de Terraform:
```
terraform init
```
Terraform instala las bibliotecas necesarias, como el Google Cloud proveedor.
Revisa la configuración y haz los cambios necesarios:
```
terraform plan
```
Aplica el plan de Terraform para crear el clúster de usuarios:
```
terraform apply
```
La creación del clúster de usuarios tarda unos 15 minutos o más, y la del grupo de nodos, otros 15 minutos. Puedes ver el clúster en la consola, en la página Clústeres de GKE. Google Cloud

Opcional: Ejecutar herramientas de línea de comandos antes de crear recursos

Si es necesario, puedes ejecutar herramientas de línea de comandos, como la CLI de gcloud y gkectl, para llevar a cabo tareas de configuración antes de crear recursos. Puedes definir las líneas de comandos que se van a ejecutar en el archivo de configuración de Terraform mediante el provisionador local-exec, que te permite reutilizar las variables de Terraform definidas.

En el ejemplo siguiente se muestra cómo modificar main.tf para ejecutar el comando gkectl prepare antes de crear el clúster:

resource "null_resource" "gkectl_prepare" {
  provisioner "local-exec" {
    command = "gkectl prepare --kubeconfig=${var.kubeconfig} --cluster-name=${var.cluster_name} --vcenter-username=${var.vcenter_username} --vcenter-password=${var.vcenter_password} --vcenter-address=${var.vcenter_address} --datacenter=${var.datacenter} --datastore=${var.datastore} --network=${var.network} --os-image=${var.os_image} --service-account-key-file=${var.service_account_key_file} --location=${var.location}"
    working_dir = path.module  # Important: Set working directory
    environment = {
        # Optional: set environment variables if needed.
        # Example: GOOGLE_APPLICATION_CREDENTIALS = "/path/to/your/credentials.json"
    }
  }
}

resource "google_gkeonprem_vmware_cluster" "cluster" {
  # ... your cluster configuration ...
  # Ensure this depends on the null_resource
  depends_on = [null_resource.gkectl_prepare]

  # ... rest of your cluster configuration ...
  location = var.location
  name = var.cluster_name
  # ... other required fields ...
}

Solución de problemas

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

Crear clúster de usuarios Organízate con las colecciones Guarda y clasifica el contenido según tus preferencias.

Antes de empezar

Crear un clúster de usuarios con la herramienta que prefieras

gkectl

Descripción general del procedimiento

Rellena los archivos de configuración

name

gkeOnPremVersion

enableAdvancedCluster

enableControlplaneV2

kubeception

enableDataplaneV2

vCenter

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

Usar clústeres de vSphere independientes

Usar centros de datos de vSphere independientes

Usar cuentas de vCenter independientes

Usar instancias independientes de vCenter Server

network

loadBalancer

advancedNetworking

multipleNetworkInterfaces

storage

masterNode

nodePools

antiAffinityGroups

stackdriver

gkeConnect

gkeOnPremAPI

cloudAuditLogging

Ejemplo de archivos de configuración rellenados

user-ipblock.yaml

user-cluster.yaml

Validar el archivo de configuración

(Opcional) Importar imágenes de SO a vSphere y enviar imágenes de contenedor a un registro privado

Crear clúster de usuarios

Buscar el archivo kubeconfig del clúster de usuarios

Verificar que el clúster de usuarios esté en funcionamiento

Consola

Empezar

Información básica de los clústeres

Plano de control

Redes

Balanceador de carga

Incluido con MetalLB

F5 BIG-IP

Manual

Funciones

Grupos de nodos

CLI de gcloud

Recoger información

Instalar otra versión

Ejemplos

MetalLB y DHCP

MetalLB e IPs estáticas

Balanceo de carga manual e IPs estáticas

Marcas del plano de control

Marcas de vSphere

Monitorizar el progreso de la creación de clústeres

Crear un grupo de nodos

Comandos de gcloud de ejemplo

MetalLB y DHCP

MetalLB e IPs estáticas

Balanceo de carga manual e IPs estáticas

Terraform

Antes de empezar

Instalar otra versión

Ejemplo

Definir variables en terraform.tfvars

Configurar Controlplane V2

Opcional: Habilitar clúster avanzado

Opcional: Modo de direccionamiento IP de los nodos de trabajo

Crear el clúster y un grupo de nodos

Opcional: Ejecutar herramientas de línea de comandos antes de crear recursos

Solución de problemas

Siguientes pasos

Crear clúster de usuarios

`name`

`gkeOnPremVersion`

`enableAdvancedCluster`

`enableControlplaneV2`

`enableDataplaneV2`

`vCenter`

`network`

`loadBalancer`

`advancedNetworking`

`multipleNetworkInterfaces`

`storage`

`masterNode`

`nodePools`

`antiAffinityGroups`

`stackdriver`

`gkeConnect`

`gkeOnPremAPI`

`cloudAuditLogging`

Definir variables en `terraform.tfvars`