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.

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

Crea un clúster de usuario

En Google Distributed Cloud, tus cargas de trabajo se ejecutan en uno o más clústeres de usuario. En este documento, se muestra cómo crear un clúster de usuario. Si deseas usar dominios de topología, consulta Crea un clúster de usuario para usarlo con dominios de topología.

Esta página está destinada a administradores, arquitectos y operadores que configuran, supervisan y administran la infraestructura tecnológica. Para obtener más información sobre los roles comunes y las tareas de ejemplo a las que hacemos referencia en el contenido de Google Cloud , consulta Tareas y roles comunes de los usuarios de GKE Enterprise.

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

gkectl
Consola de Google Cloud
Google Cloud CLI
Terraform

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

Si habilitas el clúster avanzado, debes usar gkectl para crearlo.

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

Antes de comenzar

Si planeas usar gkectl para crear el clúster de usuarios, asegúrate de haber configurado tu estación de trabajo de administrador y de poder acceder a ella, como se describe en Crea una estación de trabajo de administrador. Si usas gkectl, la estación de trabajo de administrador tiene las herramientas que necesitas para crear el clúster de usuario.
Si aún no lo hiciste, configura tus recursos de Google Cloud como se describe en estos documentos:
Cuando configures tu proyecto host de flota, ten en cuenta la herramienta que elegiste, ya que, si elegiste uno de los clientes de la API de GKE On-Prem, hay APIs adicionales que debes habilitar. Para obtener la lista de APIs, consulta Habilita las APIs en el proyecto host de tu flota.
Antes de crear un clúster de usuario, debes tener un clúster de administrador para administrarlo. Si aún no lo hiciste, crea una estación de trabajo de administrador y un clúster de administrador.
Determina la versión del clúster de usuarios que deseas instalar. Cuando creas un clúster de usuario, por lo general, instalas la versión que coincide con la del clúster de administrador. Si deseas instalar una versión diferente en un clúster de usuario, consulta Reglas de versión.
Te recomendamos que habilites Controlplane V2. Cuando Controlplane V2 está habilitado, el plano de control del clúster de usuario se ejecuta en uno o más nodos del clúster de usuario. Si planeas instalar la versión 1.30 o una superior, se requiere Controlplane V2. La alternativa es crear un clúster de usuarios que use kubeception. En el caso de kubeception, el plano de control del clúster de usuario se ejecuta en uno o más nodos del clúster de administrador.
Revisa el documento de planificación de direcciones IP y asegúrate de tener suficientes direcciones IP disponibles.
Revisa la descripción general del balanceo de cargas y revisa la decisión sobre el tipo de balanceador de cargas que deseas usar. Puedes usar el balanceador de cargas de MetalLB incluido en el paquete o configurar manualmente el que elijas. Para el balanceo de cargas manual, debes configurar el balanceador de cargas antes de crear el clúster de usuario.
Piensa en la cantidad de grupos de nodos que necesitas y en qué sistema operativo deseas ejecutar cada uno de ellos.
Piensa si deseas usar clústeres de vSphere separados para los clústeres de administrador y de usuario, y si deseas usar centros de datos diferentes. También piensa si deseas usar instancias separadas de vCenter Server.
En la versión 1.29 y versiones posteriores, las verificaciones previas del servidor están habilitadas de forma predeterminada. Las verificaciones previas al vuelo del servidor requieren reglas de firewall adicionales. En Reglas de firewall para clústeres de administrador, busca "Verificaciones previas al vuelo" y asegúrate de que todas las reglas de firewall requeridas estén configuradas.

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

Crea un clúster de usuario con la herramienta que elijas

En esta sección, se proporcionan los pasos para crear un clúster de usuarios con gkectl, la console, gcloud CLI y Terraform.

gkectl

Descripción general del procedimiento

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

Completa los archivos de configuración

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

Ejecutar gkectl prepare.
Crea un clúster de usuario

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

Usa kubectl para ver los nodos del clúster.

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

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

Completa los archivos de configuración

Si usaste gkeadm para crear tu estación de trabajo de administrador, gkeadm generó una plantilla para tu archivo de configuración de clústeres de usuarios llamada user-cluster.yaml. Además, gkeadm completó algunos de los campos por ti.

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

Si deseas generar una plantilla para el archivo de configuración de clústeres de usuarios, haz lo siguiente:

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

Reemplaza lo siguiente:

OUTPUT_FILENAME: una ruta de acceso que elijas para la plantilla generada. Si omites esta marca, gkectl asigna un nombre al archivo user-cluster.yaml y lo coloca en el directorio actual.

VERSION: El número de versión deseado. Por ejemplo: gkectl create-config cluster --gke-on-prem-version=1.31.0-gke.889

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

`name`

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

`gkeOnPremVersion`

Ya se completó este campo. Especifica la versión de Google Distributed Cloud. Por ejemplo, 1.31.0-gke.889.

`enableAdvancedCluster`

Si deseas habilitar la función de vista previa avanzada del clúster, configura enableAdvancedCluster como true. Este campo se debe establecer en true si el clúster de administrador tiene habilitado el clúster avanzado.

Ten en cuenta las siguientes limitaciones de la vista previa del clúster avanzado:

Puedes habilitar el clúster avanzado en el momento de la creación del clúster solo para clústeres nuevos de 1.31.
Una vez que se habilite el clúster avanzado, no podrás actualizarlo a la versión 1.32. Habilita solo el clúster avanzado en un entorno de prueba.

`enableControlplaneV2`

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

Si habilitas el clúster avanzado, debes configurar enableControlplaneV2 como true.

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

kubeception

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

Para un clúster de kubeception:

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

`enableDataplaneV2`

Establece enableDataplaneV2 en true.

`vCenter`

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

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

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

En particular, es posible que desees usar clústeres de vSphere independientes para el clúster de administrador y los clústeres de usuario, y también puedes usar centros de datos independientes para el clúster de administrador y los clústeres de usuario.

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

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

Usa clústeres de vSphere independientes

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

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

Usa centros de datos de vSphere independientes

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

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

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

Usa cuentas de vCenter independientes

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

Usa instancias independientes de vCenter Server

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

Por ejemplo, en una ubicación perimetral, es posible que desees tener una máquina física que ejecute vCenter Server y una o más máquinas físicas que ejecuten ESXi. Luego, podrías 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.

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

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

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

`network`

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

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

Si decidiste usar direcciones IP estáticas para los nodos de trabajo, completa el campo network.ipMode.ipBlockFilePath.

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

Para especificar los servidores DNS y NTP, completa 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 trabajo, estos servidores DNS y NTP también son para los nodos de trabajo.

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

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

`loadBalancer`

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

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

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

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

`advancedNetworking`

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

`multipleNetworkInterfaces`

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

`storage`

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

`masterNode`

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

Si habilitas el clúster avanzado, solo se admiten clústeres de alta disponibilidad (HA). Establece el campo replicas en 3 para especificar que el clúster tendrá tres nodos del plano de control.

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

`nodePools`

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

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

Si habilitas el clúster avanzado, configura nodePools[i]osImageType como ubuntu_cgroupv2 o ubuntu_containerd.

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

`antiAffinityGroups`

Establece antiAffinityGroups.enabled en true o false.

En este campo, se especifica si Google Distributed Cloud crea reglas de antiafinidad de Distributed Resource Scheduler (DRS) para los nodos trabajadores, de modo que se distribuyen en al menos tres hosts físicos en tu centro de datos.

`stackdriver`

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

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

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

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

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

`gkeConnect`

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

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

En la versión 1.28 y versiones posteriores, puedes especificar de forma opcional una región en la que se ejecutan los servicios de la flota y de conexión en gkeConnect.location. Si no incluyes este campo, el clúster usará las instancias globales de estos servicios.

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

`gkeOnPremAPI`

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

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

`usageMetering`

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

`cloudAuditLogging`

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

Ten en cuenta los siguientes requisitos:

# advanced-cluster-change #

Si habilitas el clúster avanzado, establece cloudAuditLogging.serviceAccountKeyPath en la misma ruta de acceso que stackdriver.serviceAccountKeyPath.

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

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

Ejemplo de archivos de configuración completados

Este es un ejemplo de un archivo de bloque de IP y un archivo de configuración de clúster de usuario.

user-ipblock.yaml

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

user-cluster.yaml

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

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

El campo nodePools.replicas está configurado como 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á configurado en "static".
Las direcciones IP estáticas de los nodos trabajadores se especifican en un archivo de bloque de IP. El archivo de bloque de IP tiene cuatro direcciones, aunque solo hay tres nodos de trabajo. La dirección IP adicional es necesaria durante las actualizaciones y la reparación automática del clúster.
Los servidores DNS y NTP se especifican en la sección hostConfig. En este ejemplo, estos servidores DNS y NTP son para los nodos del plano de control y los nodos trabajadores. Esto se debe a que los nodos trabajadores tienen direcciones IP estáticas. Si los nodos trabajadores obtuvieran sus direcciones IP de un servidor DHCP, estos servidores DNS y NTP serían solo para los nodos del plano de control.
Las direcciones IP estáticas 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 usuarios. No es necesario tener una dirección IP adicional en este bloque.
Se habilitó Controlplane V2.
El campo masterNode.replicas está configurado como 3, por lo que el clúster tendrá un plano de control de alta disponibilidad.
La VIP del plano de control y la VIP de entrada están en la misma VLAN que los nodos de trabajo y los nodos del plano de control.
Las VIP que se reservan 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 VIP están en la misma VLAN que los nodos trabajadores y los nodos del plano de control. El conjunto de VIPs especificado en esta sección debe incluir la VIP de entrada y no debe incluir la VIP del plano de control.
El archivo de configuración del clúster de usuario no incluye una sección vCenter. Por lo tanto, el clúster de usuario usa los mismos recursos de vSphere que el clúster de administrador.

Valida tu archivo de configuración

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

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

Reemplaza lo siguiente:

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

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

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

(Opcional) Importa imágenes de SO a vSphere y, luego, envía imágenes de contenedores a un registro privado

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

Tu clúster de usuario está en un centro de datos de vSphere diferente al de tu clúster de administrador.
Tu clúster de usuario tiene un servidor de vCenter diferente del clúster de administrador.
Tu clúster de usuario tiene una carpeta de vCenter diferente a la del clúster de administrador.
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

Reemplaza lo siguiente:

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

Crea un clúster de usuario

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

gkectl create cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG --config USER_CLUSTER_CONFIG

Ubica el archivo kubeconfig del clúster de usuario

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

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

kubectl config get-clusters --kubeconfig USER_CLUSTER_KUBECONFIG

En el resultado, se muestra el nombre del clúster. Por ejemplo:

NAME
my-user-cluster

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

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

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

kubectl get nodes --kubeconfig USER_CLUSTER_KUBECONFIG

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

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

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

Console

Comenzar

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

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

Aspectos básicos del clúster

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

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

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

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

Plano de control

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

En el campo CPU virtuales del nodo del plano de control, ingresa la cantidad de CPU virtuales (4 como mínimo) para cada nodo del plano de control de tu clúster de usuarios.
En el campo Memoria de nodo del plano de control, ingresa el tamaño de la memoria en MiB (8,192 como mínimo y debe ser un múltiplo de 4) para cada plano de control de tu clúster de usuario.
En Nodos del plano de control, selecciona la cantidad de nodos del plano de control para tu clúster de usuario. Por ejemplo, puedes seleccionar 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 (HA).
De manera opcional, selecciona Cambiar automáticamente el tamaño de los nodos. Cambiar el tamaño significa que los recursos de CPU y memoria virtuales asignados a un nodo se ajustan automáticamente. Cuando se habilita, se cambia el tamaño de los nodos del plano de control del clúster de usuario según la cantidad de nodos de trabajo en el clúster de usuario. Por lo tanto, a medida que agregas más nodos trabajadores al clúster de usuario, los nodos del plano de control aumentan de tamaño.
De manera opcional, selecciona Habilitar el plano de control v2. Si habilitas Controlplane V2, el plano de control de un clúster de usuario se ejecuta en uno o más nodos del clúster de usuario y no en el clúster de administrador (denominado kubeception).

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

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

Herramientas de redes

En esta sección, debes especificar las direcciones IP para los nodos, los Pods y los objetos Service del clúster. Un clúster de usuario debe tener una dirección IP por cada nodo y una dirección IP adicional para un nodo temporal que se necesita durante 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 usuario?

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

Balanceador de cargas

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

Selecciona el Tipo de balanceador de cargas de la lista.

Incluido con MetalLB

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

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

BIG-IP de F5

Puedes usar BIG-IP de F5 para el clúster de usuario solo si el clúster de administrador usa BIG-IP de F5. Asegúrate de instalar y configurar el ADC de BIG-IP de F5 antes de integrarlo a Google Distributed Cloud.

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

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

Manual

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

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

Funciones

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

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

Grupos de nodos

Tu 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 Crea y administra grupos de nodos.

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

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

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

gcloud CLI

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

gcloud container vmware clusters create

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

gcloud container vmware node-pools create

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

Recopila información

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

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

El resultado es similar a este:
```
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 de la flota y de conexión. Los clústeres de administrador creados antes de la versión 1.28 son administrados por los servicios globales de la flota y de Connect. En la versión 1.28 y versiones posteriores, puedes especificar global o una región Google Cloud cuando creas el clúster de administración. Especificas la región en la marca --admin-cluster-membership-location en los comandos de ejemplo que se muestran a continuación.
Obtén una lista de las versiones disponibles:
```
gcloud container vmware clusters query-version-config \
    --admin-cluster-membership=ADMIN_CLUSTER_NAME \
    --admin-cluster-membership-project=FLEET_HOST_PROJECT_ID \
    --admin-cluster-membership-location=ADMIN_CLUSTER_REGION \
    --location=REGION
```
Reemplaza lo siguiente:
- ADMIN_CLUSTER_NAME: Es el nombre del clúster de administrador.
- FLEET_HOST_PROJECT_ID: El ID del proyecto en el que está registrado el clúster de administración.
- ADMIN_CLUSTER_REGION: Es la región de membresía de la flota del clúster de administrador. Puede ser global o una región Google Cloud. Usa la ubicación del clúster de administrador del resultado de gcloud container fleet memberships list.
- REGION: Es la Google Cloud región que usarás cuando crees el clúster de usuarios. Esta es la región en la que se ejecuta la API de GKE On-Prem y se almacenan sus metadatos.
  - Si el clúster de administrador está inscrito en la API de GKE On-Prem, usa la misma región que el clúster de administrador. Para conocer 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á inscrito en la API de GKE On-Prem, especifica us-west1 o alguna otra región compatible. Si, posteriormente, inscribes el clúster de administrador en la API de GKE On-Prem, usa la misma región en la que se encuentra el clúster de usuario.
El resultado del comando gcloud container vmware clusters query-version-config es similar al 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 la creación o actualización de clústeres de usuario. Las versiones que puedes usar para crear o actualizar un clúster de usuario 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 administrar los clústeres de usuario de esa versión. Si deseas 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.

Instala una versión diferente

Un clúster de administrador puede administrar clústeres de usuario en diferentes versiones. El resultado del comando query-version-config enumera otras versiones que puedes usar cuando creas el clúster. Si deseas crear un clúster de usuario que sea una versión diferente del clúster de administrador, debes descargar e implementar los componentes que el clúster de administrador necesita para administrar clústeres de usuario de esa versión, de la siguiente manera:

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

Reemplaza VERSION por una de las versiones que se enumeran en el resultado del comando query-version-config.

El comando descarga la versión de los componentes que especificas en --required-platform-version al clúster de administrador y, luego, 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 especificaste se anotará con isInstalled: true.

Ejemplos

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

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

Antes de ejecutar el comando gcloud para crear el clúster, puedes incluir --validate-only para validar la configuración que especificaste en las marcas del comando gcloud. Cuando tengas todo listo para crear el clúster, quita esta marca y ejecuta el comando.

Si recibes un error después de que el comando gcloud container vmware clusters create se haya ejecutado durante un minuto o más, ejecuta el siguiente comando para verificar si el clúster se creó de forma parcial:

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, bórralo con el siguiente comando:

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

Luego, corrige el error y vuelve a ejecutar gcloud container vmware clusters create.

Después de que el clúster esté en ejecución, debes agregar un grupo de nodos antes de implementar las cargas de trabajo, como se describe en la sección Cómo 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 cargas de MetalLB en paquetes y usar tu servidor DHCP para obtener direcciones IP para los nodos trabajadores del clúster.

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

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

Marcar	Descripción
`--admin-users`	Te otorga a ti y a otro usuario derechos administrativos completos en el clúster.
`--enable-control-plane-v2`	Habilita Controlplane V2, que se recomienda y es obligatorio en la versión 1.30 y versiones posteriores.
`--control-plane-ip-block`	Una dirección IP para el nodo del plano de control. Para crear un clúster de usuario con alta disponibilidad (HA), especifica tres direcciones IP y agrega la marca `--replicas=3`.
`--metal-lb-config-address-pools`	Dos grupos de direcciones para el balanceador de cargas de MetalLB Necesitas al menos un grupo de direcciones y puedes especificar más si es necesario. Para mayor comodidad, el ejemplo contiene un grupo de direcciones con el nombre "ingress-vip-pool" como recordatorio de que la dirección IP de la VIP de entrada debe estar en uno de los grupos de direcciones. Para especificar el CIDR de una sola dirección IP, agrega `/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

Reemplaza lo siguiente:

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

Importante Si planeas instalar Cloud Service Mesh, debes instalar la versión 1.19.3 o una posterior. Esto es obligatorio porque los servicios de la flota y de Connect se ejecutan en una región.
VERSION: La versión de Google Distributed Cloud para 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 otorgarán privilegios de administrador del clúster de forma predeterminada. Sin embargo, si incluyes --admin-users para designar a otro usuario como administrador, anulas la configuración predeterminada y debes incluir tu dirección de correo electrónico y la del otro administrador. Por ejemplo, para agregar dos administradores, haz lo siguiente:
```
    --admin-users=sara@example.com \
    --admin-users=amal@example.com
```
Cuando se crea el clúster, la API de GKE On-Prem aplica las políticas de control de acceso basado en roles (RBAC) de Kubernetes al clúster para otorgarte a ti y aotros usuarios administradores el rol clusterrole/cluster-admin de Kubernetes, que proporciona acceso completo a cada recurso en el clúster en todos los espacios de nombres.

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

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

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

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

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

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

MetalLB y direcciones IP estáticas

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

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

Marcar	Descripción
`--admin-users`	Te otorga a ti y a otro usuario derechos administrativos completos en el clúster.
`--enable-control-plane-v2`	Habilita Controlplane V2, que se recomienda y es obligatorio en la versión 1.30 y versiones posteriores.
`--control-plane-ip-block`	Una dirección IP para el nodo del plano de control. Para crear un clúster de usuario con alta disponibilidad (HA), especifica tres direcciones IP y agrega la marca `--replicas=3`.
`--metal-lb-config-address-pools`	Dos grupos de direcciones para el balanceador de cargas de MetalLB Necesitas al menos un grupo de direcciones y puedes especificar más si es necesario. Para mayor comodidad, el ejemplo contiene un grupo de direcciones con el nombre "ingress-vip-pool" como recordatorio de que la dirección IP de la VIP de entrada debe estar en uno de los grupos de direcciones. Para especificar el CIDR de una sola dirección IP, agrega `/32` a la dirección IP.
`--static-ip-config-ip-blocks`	Cuatro direcciones IP para los nodos de trabajo en los clústeres. Esto incluye una dirección para un nodo adicional que se puede usar durante la actualización. Si es necesario, puedes especificar más direcciones IP. 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

Reemplaza lo siguiente:

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

Importante Si planeas instalar Cloud Service Mesh, debes instalar la versión 1.19.3 o una posterior. Esto es obligatorio porque los servicios de la flota y de Connect se ejecutan en una región.
VERSION: La versión de Google Distributed Cloud para 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 otorgarán privilegios de administrador del clúster de forma predeterminada. Sin embargo, si incluyes --admin-users para designar a otro usuario como administrador, anulas la configuración predeterminada y debes incluir tu dirección de correo electrónico y la del otro administrador. Por ejemplo, para agregar dos administradores, haz lo siguiente:
```
    --admin-users=sara@example.com \
    --admin-users=amal@example.com
```
Cuando se crea el clúster, la API de GKE On-Prem aplica las políticas de control de acceso basado en roles (RBAC) de Kubernetes al clúster para otorgarte a ti y aotros usuarios administradores el rol clusterrole/cluster-admin de Kubernetes, que proporciona acceso completo a cada recurso en el clúster en todos los espacios de nombres.

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

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

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

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

La dirección IP 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 para los nodos trabajadores en el clúster de usuario. El valor de la marca tiene el siguiente formato:
```
--static-ip-config-ip-blocks 'gateway=GATEWAY,netmask=NETMASK,ips=IP_ADDRESS_1;IP_ADDRESS_2 HOST_2;...'
```
El valor tiene segmentos que comienzan con las palabras clave gateway, netmask y ips. Separa los segmentos con una coma.

Ten en cuenta lo siguiente:
- Encierra todo el valor entre comillas simples.
- No se permiten espacios en blanco, excepto entre una dirección IP y un nombre de host.
En la lista de direcciones IP, haz lo siguiente:
- 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.
- Para una dirección IP individual, puedes especificar un nombre de host después de la dirección IP de forma opcional. Separa la dirección IP y el nombre de host con un espacio. Cuando no especificas un nombre de host, Google Distributed Cloud usa el nombre de la VM de vSphere como el nombre de host.
- Si especificas un bloque CIDR, no especifiques un valor para el nombre de host.
Por ejemplo:
```
--static-ip-config-ip-blocks 'gateway=172.16.23.254,netmask=255.255.252.0,ips=172.16.20.10;172.16.20.11 host2;172.16.20.12/30'
```
DNS_SERVER: Es una lista separada por comas de las direcciones IP de los servidores DNS de las VMs.
DNS_SEARCH_DOMAIN: Es una lista de dominios de búsqueda de DNS separados por comas que los hosts deben usar. Estos dominios se usan como parte de una lista de búsqueda de dominios.
Por ejemplo:
```
--dns-search-domains example.com,examplepetstore.com
```
NTP_SERVER: Es una lista separada por comas de las direcciones IP de los servidores de tiempo que deben usar las VMs.

Balanceador de cargas manual y direcciones IP estáticas

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

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

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

Marcar	Descripción
`--admin-users`	Te otorga a ti y a otro usuario derechos administrativos completos en el clúster.
`--enable-control-plane-v2`	Habilita Controlplane V2, que se recomienda y es obligatorio en la versión 1.30 y versiones posteriores.
`--control-plane-ip-block`	Una dirección IP para el nodo del plano de control. Para crear un clúster de usuario con alta disponibilidad (HA), especifica tres direcciones IP y agrega la marca `--replicas=3`.
`--static-ip-config-ip-blocks`	Cuatro direcciones IP para los nodos de trabajo en los clústeres. Esto incluye una dirección para un nodo adicional que se puede usar durante la actualización. Si es necesario, puedes especificar más direcciones IP. 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

Reemplaza lo siguiente:

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

Importante Si planeas instalar Cloud Service Mesh, debes instalar la versión 1.19.3 o una posterior. Esto es obligatorio porque los servicios de la flota y de Connect se ejecutan en una región.
VERSION: La versión de Google Distributed Cloud para 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 otorgarán privilegios de administrador del clúster de forma predeterminada. Sin embargo, si incluyes --admin-users para designar a otro usuario como administrador, anulas la configuración predeterminada y debes incluir tu dirección de correo electrónico y la del otro administrador. Por ejemplo, para agregar dos administradores, haz lo siguiente:
```
    --admin-users=sara@example.com \
    --admin-users=amal@example.com
```
Cuando se crea el clúster, la API de GKE On-Prem aplica las políticas de control de acceso basado en roles (RBAC) de Kubernetes al clúster para otorgarte a ti y aotros usuarios administradores el rol clusterrole/cluster-admin de Kubernetes, que proporciona acceso completo a cada recurso en el clúster en todos los espacios de nombres.

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

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

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

Ejemplo: --control-plane-vip=203.0.113.3
INGRESS_VIP: Es la dirección IP que elegiste configurar en el balanceador de cargas para el proxy de entrada.

Ejemplo: --ingress-vip=203.0.113.4
INGRESS_HTTP_NODE_PORT: Un valor nodePort para el tráfico HTTP al proxy de entrada (como 30243).
INGRESS_HTTPS_NODE_PORT: Un valor 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 para los nodos trabajadores en el clúster de usuario. El valor de la marca tiene el siguiente formato:
```
--static-ip-config-ip-blocks 'gateway=GATEWAY,netmask=NETMASK,ips=IP_ADDRESS_1;IP_ADDRESS_2 HOST_2;...'
```
El valor tiene segmentos que comienzan con las palabras clave gateway, netmask y ips. Separa los segmentos con una coma.

Ten en cuenta lo siguiente:
- Encierra todo el valor entre comillas simples.
- No se permiten espacios en blanco, excepto entre una dirección IP y un nombre de host.
En la lista de direcciones IP, haz lo siguiente:
- 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.
- Para una dirección IP individual, puedes especificar un nombre de host después de la dirección IP de forma opcional. Separa la dirección IP y el nombre de host con un espacio. Cuando no especificas un nombre de host, Google Distributed Cloud usa el nombre de la VM de vSphere como el nombre de host.
- Si especificas un bloque CIDR, no especifiques un valor para el nombre de host.
Por ejemplo:
```
--static-ip-config-ip-blocks 'gateway=172.16.23.254,netmask=255.255.252.0,ips=172.16.20.10;172.16.20.11 host2;172.16.20.12/30'
```
DNS_SERVER: Es una lista separada por comas de las direcciones IP de los servidores DNS de las VMs.
DNS_SEARCH_DOMAIN: Es una lista de dominios de búsqueda de DNS separados por comas que los hosts deben usar. Estos dominios se usan como parte de una lista de búsqueda de dominios.
Por ejemplo:
```
--dns-search-domains example.com,examplepetstore.com
```
NTP_SERVER: Es una lista separada por comas de las direcciones IP de los servidores de tiempo que deben usar las VMs.

Marcas del plano de control

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

--cpus=vCPUS: Es la cantidad de CPU virtuales (4 como mínimo) para cada nodo del plano de control de tu clúster de usuarios. Si no se especifica, el valor predeterminado es de 4 vCPU.
--memory=MEMORY: Es el tamaño de la memoria en mebibytes (MiB) para cada plano de control de tu clúster de usuarios. El valor mínimo es 8,192 y debe ser un múltiplo de 4. Si no se especifica, el valor predeterminado es 8192.
--replicas=NODES: Es la cantidad de nodos del plano de control para este clúster de usuario Por ejemplo, puedes seleccionar 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 (HA).
--enable-auto-resize: Si deseas habilitar el cambio de tamaño automático de los nodos del plano de control para el clúster de usuario, incluye --enable-auto-resize. Cambiar el tamaño significa que los recursos de CPU y memoria virtuales asignados a un nodo se ajustan automáticamente. Cuando se habilita, se cambia el tamaño de los nodos del plano de control del clúster de usuario según la cantidad de nodos trabajadores en el clúster de usuario. Por lo tanto, a medida que agregas más nodos trabajadores al clúster de usuario, los nodos del plano de control aumentan de tamaño.
--enable-control-plane-v2: Para habilitar Controlplane V2, que te recomendamos, incluye esta marca. Cuando Controlplane V2 está habilitado, el plano de control del clúster de usuario se ejecuta en uno o más nodos del clúster de usuario. En la versión 1.30 y versiones posteriores, se requiere Controlplane V2.

Cuando habilites ControlPlane V2, también debes especificar las siguientes marcas:
- --dns-servers=DNS_SERVER_1,...: Es una lista de direcciones IP de los servidores DNS de las VMs separadas por comas.
- --ntp-servers=NTP_SERVER_1,...: Es una 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 comienzan con las palabras clave gateway, netmask y ips. Separa los segmentos con una coma.
  
  Ten en cuenta lo siguiente:
  - Encierra todo el valor entre comillas simples.
  - No se permiten espacios en blanco, excepto entre una dirección IP y un nombre de host.
    
    En la lista de direcciones IP, haz lo siguiente:
  - 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.
  - Para una dirección IP individual, puedes especificar un nombre de host después de la dirección IP de forma opcional. Separa la dirección IP y el nombre de host con un espacio.
  - Si especificas un bloque CIDR, no especifiques un valor para el nombre de host.
    
    Por ejemplo:
    --control-plane-ip-block 'gateway=192.168.0.1,netmask=255.0.0.0,ips=192.168.1.1;192.168.1.2 hostname-2;192.168.2.2/28`
- Opcional: --dns-search-domains=DNS_SEARCH_DOMAIN_1,...: Es una lista de dominios de búsqueda de DNS separada por comas que los hosts deben usar. Estos dominios se usan como parte de una lista de búsqueda de dominios.
  
  Por ejemplo:
```
--dns-search-domains example.com,examplepetstore.com
```
Para obtener una lista completa de las marcas y sus descripciones, consulta la referencia de la gcloud CLI.

Marcas de vSphere

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

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

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

Hacer un seguimiento del progreso de la creación del clúster

El resultado del comando cluster create 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 averiguar el estado de la operación con el siguiente comando:
```
gcloud container vmware operations describe OPERATION_ID \
  --project=FLEET_HOST_PROJECT_ID \
  --location=REGION
```
Para obtener más información, consulta gcloud container vmware operations.

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

Crea un grupo de nodos

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

Para obtener información sobre las marcas opcionales, consulta Cómo agregar un grupo de nodos y la referencia de la gcloud CLI.

Ejemplos de comandos de gcloud

MetalLB y DHCP

gcloud container vmware clusters create user-cluster-1 \
    --project=example-project-12345 \
    --location=us-west1 \
    --admin-cluster-membership=projects/example-project-12345/locations/us-west1/memberships/admin-cluster-1 \
    --version=1.31.0-gke.889 \
    --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 y direcciones IP 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.31.0-gke.889 \
    --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

Balanceador de cargas manual y direcciones IP estáticas

gcloud container vmware clusters create user-cluster-4 \
    --project=example-project-12345 \
    --location=asia-east1 \
    --admin-cluster-membership=projects/example-project-12345/locations/asia-east1/memberships/admin-cluster-1 \
    --version=1.31.0-gke.889 \
    --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 comenzar

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

El resultado es similar a este:
```
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 de la flota y de conexión. Los clústeres de administrador creados antes de la versión 1.28 son administrados por los servicios globales de la flota y de Connect. En la versión 1.28 y versiones posteriores, puedes especificar global o una región Google Cloud cuando creas el clúster.
Obtén una lista de las versiones disponibles:
```
gcloud container vmware clusters query-version-config \
    --admin-cluster-membership=ADMIN_CLUSTER_NAME \
    --admin-cluster-membership-project=FLEET_HOST_PROJECT_ID \
    --admin-cluster-membership-location=ADMIN_CLUSTER_REGION \
    --location=REGION
```
Reemplaza lo siguiente:
- ADMIN_CLUSTER_NAME: Es el nombre del clúster de administrador.
- FLEET_HOST_PROJECT_ID: El ID del proyecto en el que está registrado el clúster de administración.
- ADMIN_CLUSTER_REGION: Es la región de membresía de la flota del clúster de administrador. Puede ser global o una región Google Cloud. Usa la ubicación del clúster de administrador del resultado de gcloud container fleet memberships list.
- REGION: Es la Google Cloud región que usarás cuando crees el clúster. Esta es la región en la que se ejecutan la API de GKE On-Prem y los servicios de la flota y Connect. Especifica us-west1 o alguna otra región compatible.
El resultado del comando es similar al siguiente:
```
versions:
- isInstalled: true
  version: 1.14.3-gke.25
- version: 1.14.4-gke.54
- version: 1.15.0-gke.581
```
Las versiones que puedes usar para crear un clúster de usuario 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 administrar los clústeres de usuario de esa versión. Si deseas crear un clúster de usuario con otra versión disponible, consulta Cómo instalar una versión posterior a la del clúster de administrador.

Ejemplo

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

Configura variables en `terraform.tfvars`

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

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

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

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

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

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

cp main.tf main.tf.bak

Modo de direccionamiento IP del nodo trabajador

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

Reemplaza el bloque network_config y, luego, incluye un bloque static_ip_config. Por ejemplo:

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

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

Configura Controlplane V2

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

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

Agrega un mapa control_plane_v2_config al bloque network_config, por ejemplo:

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

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

Crea el clúster y un grupo de nodos

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

Soluciona problemas

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

Crea un clúster de usuario

Antes de comenzar

Crea un clúster de usuario con la herramienta que elijas

gkectl

Descripción general del procedimiento

Completa los archivos de configuración

name

gkeOnPremVersion

enableAdvancedCluster

enableControlplaneV2

kubeception

enableDataplaneV2

vCenter

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

Usa clústeres de vSphere independientes

Usa centros de datos de vSphere independientes

Usa cuentas de vCenter independientes

Usa instancias independientes de vCenter Server

network

loadBalancer

advancedNetworking

multipleNetworkInterfaces

storage

masterNode

nodePools

antiAffinityGroups

stackdriver

gkeConnect

gkeOnPremAPI

usageMetering

cloudAuditLogging

# advanced-cluster-change #

Ejemplo de archivos de configuración completados

user-ipblock.yaml

user-cluster.yaml

Valida tu archivo de configuración

(Opcional) Importa imágenes de SO a vSphere y, luego, envía imágenes de contenedores a un registro privado

Crea un clúster de usuario

Ubica el archivo kubeconfig del clúster de usuario

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

Console

Comenzar

Aspectos básicos del clúster

Plano de control

Herramientas de redes

Balanceador de cargas

Incluido con MetalLB

BIG-IP de F5

Manual

Funciones

Grupos de nodos

gcloud CLI

Recopila información

Instala una versión diferente

Ejemplos

MetalLB y DHCP

MetalLB y direcciones IP estáticas

Balanceador de cargas manual y direcciones IP estáticas

Marcas del plano de control

Marcas de vSphere

Hacer un seguimiento del progreso de la creación del clúster

Crea un grupo de nodos

Ejemplos de comandos de gcloud

MetalLB y DHCP

MetalLB y direcciones IP estáticas

Balanceador de cargas manual y direcciones IP estáticas

Terraform

Antes de comenzar

Ejemplo

Configura variables en terraform.tfvars

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

Modo de direccionamiento IP del nodo trabajador

Configura Controlplane V2

Crea el clúster y un grupo de nodos

Soluciona problemas

¿Qué sigue?

`name`

`gkeOnPremVersion`

`enableAdvancedCluster`

`enableControlplaneV2`

`enableDataplaneV2`

`vCenter`

`network`

`loadBalancer`

`advancedNetworking`

`multipleNetworkInterfaces`

`storage`

`masterNode`

`nodePools`

`antiAffinityGroups`

`stackdriver`

`gkeConnect`

`gkeOnPremAPI`

`usageMetering`

`cloudAuditLogging`

Configura variables en `terraform.tfvars`

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