Los clústeres de Anthos en Bare Metal ahora son Google Distributed Cloud (solo software) para Bare Metal. 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 con clientes de la API de GKE On-Prem

En esta página, se describe cómo crear un clúster de usuarios con la consola de Google Cloud, Google Cloud CLI (gcloud CLI) o Terraform.

¿Qué es la API de GKE On-Prem?

La API de GKE On-Prem es una API alojada en Google Cloudque te permite administrar el ciclo de vida de tus clústeres locales con Terraform y aplicaciones estándares deGoogle Cloud . La API de GKE On-Prem se ejecuta en la infraestructura de Google Cloud. Terraform, la consola y la gcloud CLI son clientes de la API y la usan para crear clústeres en tu centro de datos.

Para administrar el ciclo de vida de tus clústeres, la API de GKE On-Prem debe almacenar los metadatos sobre el estado de tu clúster en Google Cloud, en la región deGoogle Cloud que especificas cuando creas el clúster. Estos metadatos permiten que la API administre el ciclo de vida del clúster y no incluya datos específicos de la carga de trabajo.

Cuando creas un clúster con un cliente de API de GKE On-Prem, especificas un proyecto deGoogle Cloud . Después de crear el clúster, se registra automáticamente en la flota del proyecto especificado. Este proyecto se conoce como el proyecto host de la flota. No se puede cambiar el proyecto host de la flota después de crear el clúster.

Si lo prefieres, puedes crear un clúster de usuario si creas un archivo de configuración de clúster de usuario y usas bmctl, como se describe en Crea un clúster de usuario.

Si deseas usar Terraform, la consola o gcloud CLI para administrar el ciclo de vida de los clústeres que se crearon con bmctl, consulta Configura un clúster de usuario para que lo administre la API de GKE On-Prem.

Antes de comenzar

En esta sección, se describen los requisitos para crear un clúster de usuarios con clientes de la API de GKE On-Prem.

Otorga permisos de IAM

Si no eres propietario de un proyecto, debes tener el rol roles/gkeonprem.admin.

Si deseas acceder a las páginas de Google Kubernetes Engine en la consola, también debes tener los siguientes roles:

Después de crear el clúster, si no eres propietario del proyecto y deseas usar la puerta de enlace de Connect para conectarte al clúster de usuario mediante la línea de comandos, se requieren los siguientes roles:

roles/gkehub.gatewayAdmin: Esta función te permite acceder a la API de la puerta de enlace de Connect. Si solo necesitas acceso de solo lectura al clúster, roles/gkehub.gatewayReader es suficiente.
roles/gkehub.viewer: Este rol te permite recuperar las credenciales del clúster.

Para obtener información sobre cómo otorgar roles, consulta Administración del acceso a proyectos, carpetas y organizaciones.

APIs de Google obligatorias

Asegúrate de que las APIs de Google obligatorias estén habilitadas en el proyecto host de la flota.

Si usarás gcloud CLI para crear el clúster, debes habilitar la API de GKE On-Prem. Si usas la consola para crear el clúster, esta habilita la API de GKE On-Prem automáticamente.

gcloud services enable --project FLEET_HOST_PROJECT_ID \
    gkeonprem.googleapis.com

Requisitos previos del clúster de administrador

Necesitas un clúster de administrador que funcione para poder crear un clúster de usuario. El clúster de administrador debe cumplir con los siguientes requisitos:

Tener acceso al servidor de la API de Kubernetes en el clúster de usuario después de su creación
Tener conectividad de red a todos los nodos del clúster de usuario después de su creación
Debe estar registrado en una flota. El ID del proyecto que se configura en el campo gkeConnect.projectID de ese clúster de administrador, que se conoce como el proyecto host de la flota, debe ser el mismo proyecto en el que crearás el clúster de usuario.

Requisitos previos de la máquina del nodo del clúster

Revisa los requisitos previos de las máquinas de nodo del clúster para asegurarte de que las máquinas que ejecutarán el clúster de usuarios cumplan con los requisitos previos.

Acceso a la línea de comandos

Después de crear el clúster, si deseas usar la puerta de enlace de Connect para ejecutar kubectl en el clúster de usuario en computadoras que no sean la estación de trabajo del administrador, instala las siguientes herramientas de línea de comandos en la computadora que planeas usar.

La versión más reciente de la CLI de gcloud
kubectl para ejecutar comandos en clústeres de Kubernetes. Si necesitas instalar kubectl, sigue estas instrucciones

Crea un clúster de usuario

Puedes usar Terraform, la consola de Google Cloud o la CLI de Google Cloud (gcloud CLI) para crear un clúster que administre la API de GKE On-Prem. Si es la primera vez que instalas Google Distributed Cloud, es posible que la consola sea la herramienta más fácil de usar.

Una vez que te familiarices con la información que debes proporcionar para crear clústeres, es posible que Terraform o la gcloud CLI te resulten más convenientes, en especial si crearás más de un clúster. Terraform es una herramienta de infraestructura como código estándar de la industria. Si tu organización ya usa Terraform, es probable que quieras usarlo para crear clústeres y administrar su ciclo de vida.

Con la gcloud CLI, puedes guardar el comando con sus argumentos en un archivo de texto y realizar los cambios necesarios para crear clústeres adicionales. Si usas una herramienta de CI/CD, como Cloud Build, puedes usar los comandos gcloud para crear un clúster y un grupo de nodos, y especificar la marca --impersonate-service-account para automatizar la creación.

Console

La mayoría de los parámetros de configuración de la consola corresponden a los campos del archivo de configuración del clúster.

En la consola, ve a la página Crea un clúster de Bare Metal.

Ir a Crea un clúster de Bare Metal
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.
Haz clic en Siguiente para comenzar a configurar el clúster.

En las siguientes secciones, se te guiará a través de la configuración del clúster de usuario.

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.
En el campo Ubicación de la API de Google Cloud, selecciona la región de Google Cloudde 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 tu clúster de usuario. Los clústeres de usuario deben tener la misma versión secundaria que el clúster de administrador o una anterior.
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.

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.
En la sección Configuración del nodo, especifica lo siguiente:
- Cantidad máxima de Pods por nodo: Ingresa la cantidad máxima de Pods que se pueden ejecutar en un solo nodo. Los valores permitidos están entre 32 y 250 inclusive. Kubernetes asigna un bloque de enrutamiento entre dominios sin clases (CIDR) a cada nodo para que cada Pod pueda tener una dirección IP única. El tamaño del bloque CIDR corresponde al número máximo de pods por nodo. Para obtener más información sobre la configuración de la cantidad máxima de Pods por nodo, consulta Herramientas de redes de Pods.
- Entorno de ejecución del contenedor: containerd es el único entorno de ejecución de contenedores disponible para tu clúster.
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. Si usas el balanceo de cargas en paquetes con MetalLB, también debes configurarlo.

En la sección de nodos del plano de control, ingresa la dirección IPv4 de cada nodo del plano de control. Los nodos del plano de control ejecutan la carga de trabajo del sistema. Por lo general, es una sola máquina si usas una implementación mínima, o tres máquinas si usas una implementación de alta disponibilidad (HA). Especifica una cantidad impar de nodos para tener la mayoría de quórum para la alta disponibilidad. Este campo se puede cambiar cada vez que actualizas un clúster.

Haz clic en + Agregar dirección IP según sea necesario para ingresar más direcciones IP.
En la sección Balanceador de cargas, selecciona el balanceador de cargas de la lista Modo para configurarlo en tu clúster. Consulta la descripción general de los balanceadores de cargas para obtener más información.
Incluido con MetalLB
Configura el balanceo de cargas con el balanceador de cargas de MetalLB incluido. Con esta opción, Google Distributed Cloud implementa balanceadores de cargas de capa 4 que se ejecutan en un grupo dedicado de nodos trabajadores o en los mismos nodos que el plano de control.
1. En la sección Grupos de nodos del balanceador de cargas, selecciona una de las siguientes opciones:
  - Usa los nodos del plano de control: Elige esta opción para ejecutar los balanceadores de cargas en los mismos nodos que el plano de control.
  - Crear grupo de nodos del balanceador de cargas: Elige esta opción avanzada si necesitas ejecutar los balanceadores de cargas en un grupo dedicado de nodos trabajadores. Todos los nodos del grupo de nodos del balanceador de cargas deben estar en la misma subred de capa 2 que las IP virtuales (VIP) del balanceador de cargas que configures en la sección Grupos de direcciones del balanceador de cargas.
    
    En el campo IP del grupo de nodos del balanceador de cargas 1, ingresa una dirección IPv4 para un nodo de tu grupo de nodos del balanceador de cargas.
    
    Haz clic en + Agregar dirección IP según sea necesario para ingresar direcciones IP adicionales.
2. En la sección Grupos de direcciones del balanceador de cargas, agrega uno o más grupos de direcciones para que el controlador de MetalLB elija y asigne a los servicios de tipo LoadBalancer. La VIP de entrada, que especificas en la sección IPs virtuales, debe estar en uno de estos grupos.
  1. Ingresa un Nombre para el grupo de direcciones.
  2. Ingresa un rango de direcciones IP en notación CIDR (por ejemplo, 192.0.2.0/26) o notación de rango (por ejemplo, 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 (por ejemplo, 192.0.2.1/32).
  3. Si la VIP de entrada no está en el rango de direcciones, selecciona + Agregar un rango de direcciones IP y, luego, ingresa otro rango de direcciones que incluya la VIP de entrada.
    
    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 servicios de tipo LoadBalancer.
    
    Manual: Elige esta opción si tienes la intención de usar direcciones del grupo para 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.
  7. Si es necesario, haz clic en Agregar grupo de direcciones.
Balanceador de cargas manual
Con el balanceo de cargas manual, puedes configurar tus propias soluciones de balanceo de cargas para el tráfico del plano de control y el plano de datos. Debes configurar la VIP del plano de control en el balanceador de cargas externo antes de crear un clúster. El balanceador de cargas del plano de control externo también se puede usar para el tráfico del plano de datos, o puedes configurar un balanceador de cargas por separado para el plano de datos. Para obtener más información, consulta Configura el balanceo de cargas manual.
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. La VIP del plano de control debe estar en la misma subred que los nodos del balanceador de cargas y no debe estar en ninguno de los rangos de direcciones que se usan para los grupos de direcciones del balanceador de cargas.
- Puerto: Es el puerto de destino que se usa para el tráfico enviado al servidor de la API de Kubernetes. El valor predeterminado es 443.
- VIP de Ingress: La dirección IP que se configurará en el balanceador de cargas para el proxy de Ingress. Ingresa una dirección de uno de los grupos de direcciones del balanceador de cargas.
En la sección CIDR de servicios y Pods, especifica los rangos de direcciones IP del Pod y de Service de Kubernetes en la notación CIDR. No deben superponerse entre sí ni con ninguna dirección fuera del clúster a la que quieras llegar desde el clúster. Te recomendamos que uses los rangos de direcciones IP privadas que define RFC 1918. La consola proporciona los siguientes rangos de direcciones predeterminados, pero puedes cambiarlos:
- Service CIDR: 10.96.0.0/20 Si no aceptas el valor predeterminado, ingresa un rango de CIDR entre /24 y /12, donde /12 proporciona la mayor cantidad de direcciones IP.
- Pod CIDR: 192.168.0.0/16 Si no aceptas el valor predeterminado, ingresa un rango de CIDR entre /18 y /8, donde /8 proporciona la mayor cantidad de direcciones IP.
En la sección de atributos Advanced attributes, especifica lo siguiente de manera opcional:
- URL del proxy: Es la dirección HTTP de tu servidor proxy. Incluye el número de puerto incluso si es el mismo que el puerto predeterminado del esquema, por ejemplo: http://my-proxy.example.local:80
- URLs: Es una lista separada por comas de direcciones IP, rangos de direcciones IP, nombres de host y nombres de dominio que no deben pasar por el servidor proxy. Cuando Google Distributed Cloud envía una solicitud a una de estas direcciones, hosts o dominios, la solicitud se envía de manera directa.
Haz clic en Siguiente.

Almacenamiento

La versión de solo software de Google Distributed Cloud proporciona interfaces de almacenamiento en bloque y de archivos. Si bien tienen opciones predeterminadas, puedes personalizar la configuración. Para obtener más información, consulta Configura el almacenamiento local.

De manera opcional, puedes configurar lo siguiente:
- Activaciones de nodos del aprovisionador de volumen local: Especifica la configuración de PersistentVolumes (PV) locales respaldados por discos activados. Debes formatear y activar estos discos antes o después de crear el clúster.
- Uso compartido del aprovisionador de volumen local: Especifica la configuración de PersistentVolumes local respaldado por subdirectorios en un sistema de archivos compartidos. Estos subdirectorios se crean automáticamente durante la creación del clúster.
Haz clic en Siguiente.

Funciones

Para ayudarte a supervisar, solucionar problemas y operar tu clúster, los siguientes elementos se habilitan automáticamente 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

Crea un grupo de nodos en la consola

Tu clúster debe tener, al menos, un grupo de nodos para los nodos trabajadores. Un grupo de nodos es una plantilla para los conjuntos de nodos de trabajo creados en este clúster.

En la consola, configuras al menos un grupo de nodos (o aceptas los valores predeterminados) y, luego, creas el clúster. Puedes agregar grupos de nodos adicionales después de crear el clúster. Con gcloud CLI, primero creas el clúster y, luego, agregas uno o más grupos de nodos al clúster que acabas de crear.

Haz clic en grupo predeterminado en la barra de navegación izquierda.
En la sección Node pool defaults, ingresa el nombre del grupo de nodos o acepta “default-pool” como el nombre.
En la sección Nodos trabajadores, ingresa las direcciones IP de las máquinas en las que se ejecutará el clúster.
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 hay un problema con 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.

gcloud CLI

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

gcloud container bare-metal clusters create

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

gcloud container bare-metal 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 el comando completo en la sección Ejemplos. Para obtener información sobre las marcas, consulta las secciones que siguen a los ejemplos o consulta la referencia de la CLI de gcloud.

Antes de comenzar

La versión que selecciones cuando crees un clúster de usuario debe ser una versión que admita tu clúster de administrador. Además, las versiones secundarias o de parche más recientes no están disponibles en la API de GKE On-Prem hasta 7 o 14 días después del lanzamiento. Puedes ejecutar un comando gcloud para obtener una lista de las versiones de clúster compatibles que puedes instalar.

Asegúrate de actualizar los componentes:
```
gcloud components update
```
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 administrador. 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 para instalar en el clúster de usuarios:
```
gcloud container bare-metal 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:
- version: 1.16.2
- version: 1.16.1
- version: 1.16.0
- version: 1.15.7
- version: 1.15.6
- version: 1.15.5
```

Te sugerimos que uses la versión compatible más reciente para obtener las correcciones y mejoras más recientes.

Ejemplos

En esta sección, se proporciona un ejemplo de un comando que crea un clúster con el balanceador de cargas MetalLB y un ejemplo con un balanceador de cargas manual. La información que especifiques varía según el tipo de balanceador de cargas que usarás. Consulta la descripción general de los balanceadores de cargas para obtener más información.

En los ejemplos, se crea el clúster sin ningún grupo de nodos. Una vez que el clúster esté en ejecución, debes agregar un grupo de nodos antes de implementar cargas de trabajo.

MetalLB

En este ejemplo, se muestra cómo crear un clúster de usuario con el balanceador de cargas de MetalLB en paquetes.

gcloud container bare-metal 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 \
  --metal-lb-address-pools='pool=NAME,avoid-buggy-ips=True|False,manual-assign=True|False,addresses=IP_ADDRESS_RANGE_1;IP_ADDRESS_RANGE_2;...' \
  --control-plane-node-configs='node-ip=CP_IP_ADDRESS_1,labels=CP_KEY_1.1=CP_VALUE_1.1;CP_KEY_1.2=CP_VALUE_1.2;...' \
  --control-plane-vip=CONTROL_PLANE_VIP \
  --control-plane-load-balancer-port=CONTROL_PLANE_LB_PORT \
  --ingress-vip=INGRESS_VIP \
  --island-mode-service-address-cidr-blocks=SERVICE_CIDR_BLOCK \
  --island-mode-pod-address-cidr-blocks=POD_CIDR_BLOCK \
  --lvp-share-path=/mnt/localpv-share \
  --lvp-share-storage-class=local-shared \
  --lvp-node-mounts-config-path=/mnt/localpv-disk \
  --lvp-node-mounts-config-storage-class=local-disks

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.

Grupos de direcciones de MetalLB

--metal-lb-address-pools: Especifica 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:

'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-ips: Si configuras esto como True, el controlador de MetalLB no asignará direcciones IP que terminen en .0 o .255 a los servicios. 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 formato CIDR o con guiones. Para especificar una sola dirección IP en un grupo (como para la VIP de entrada), usa /32 en la notación CIDR (p. ej., 192.0.2.1/32).

Ten en cuenta las siguientes reglas de sintaxis:

Encierra todo el valor entre comillas simples.
No se permiten espacios en blanco.
Separa cada rango de direcciones IP con un punto y coma.

Puedes especificar más de una instancia de la marca, como se muestra en el siguiente ejemplo:

--metal-lb-address-pools='pool=pool1,avoid-buggy-ips=False,manual-assign=True,addresses=192.0.2.0/26;192.0.2.64-192.0.2.72'
--metal-lb-address-pools='pool=pool2,avoid-buggy-ips=True,manual-assign=True,addresses=10.251.133.0/24;10.251.134.80/32'

Nodos de MetalLB

Opcional: --metal-lb-load-balancer-node-configs: De forma predeterminada, el balanceador de cargas se ejecuta en los mismos nodos que el plano de control. Si necesitas ejecutar el balanceador de cargas en un grupo dedicado de nodos de trabajo, especifica esta marca para cada nodo. Todos los nodos del grupo de nodos del balanceador de cargas deben estar en la misma subred de capa 2 que las IP virtuales (VIP) del balanceador de cargas.

Importante: Si creas tu clúster sin un grupo de nodos dedicado al balanceador de cargas, no podrás agregarlo más adelante. En el caso de los clústeres configurados con al menos un nodo del balanceador de cargas, puedes actualizar el clúster para agregar más nodos al grupo de nodos del balanceador de cargas.

El valor de la marca tiene el siguiente formato:
```
'node-ip=LB_IP_ADDRESS_1,labels=LB_KEY_1.1=LB_VALUE_1.1;LB_KEY_1.2=LB_VALUE_1.2;...' \
```
El valor tiene segmentos que comienzan con las palabras clave node-ip y labels. Separa cada segmento con una coma.
- node-ip: Es la dirección IP de un nodo en el grupo de nodos del balanceador de cargas. Solo puedes especificar una node-ip por marca. Si necesitas especificar más de un nodo, vuelve a incluir la marca para cada uno.
- labels: Uno o más pares clave-valor adjuntos al nodo.
Ten en cuenta las siguientes reglas de sintaxis:
- Encierra todo el valor entre comillas simples.
- No se permiten espacios en blanco.
- Separa cada par clave=valor en el segmento labels con un punto y coma.
Si especificas --metal-lb-load-balancer-node-configs, puedes incluir las siguientes marcas de manera opcional:
- --metal-lb-load-balancer-node-labels: Usa esta marca para agregar etiquetas a todos los nodos del grupo de nodos del balanceador de cargas. Separa la lista de parejas clave=valor con una coma.
```
--metal-lb-load-balancer-node-labels=KEY_1=VALUE_1,KEY_2=VALUE_2
```
- --metal-lb-load-balancer-node-taints: Usa esta marca para agregar contaminaciones a todos los nodos del grupo de nodos del balanceador de cargas. Cada contaminación es un par clave-valor asociado con un efecto, que debe ser uno de los siguientes: PreferNoSchedule, NoSchedule o NoExecute.
```
--metal-lb-load-balancer-node-taints=KEY_1=VALUE_1:EFFECT_1,KEY_2=VALUE_2:EFFECT_2
```
En el siguiente ejemplo, se agregan tres nodos al grupo de nodos del balanceador de cargas. Todos los nodos están etiquetados con lb-pool-key=lb-pool-value y tienen la contaminación dedicated=experimental:PreferNoSchedule.
```
--metal-lb-load-balancer-node-configs='node-ip=192.0.2.1' \
--metal-lb-load-balancer-node-configs='node-ip=192.0.2.2,labels=key2.1=value2.1' \
--metal-lb-load-balancer-node-configs='node-ip=192.0.2.3,labels=key3.1=value3.1;key3.2=value3.2' \
--metal-lb-load-balancer-node-labels=lb-pool-key=lb-pool-value \
--metal-lb-load-balancer-node-taints=dedicated=experimental:PreferNoSchedule \
```

Nodos de plano de control

--control-plane-node-configs: Es la dirección IPv4 de un nodo del plano de control. Los nodos del plano de control ejecutan la carga de trabajo del sistema. Especifica esta marca para cada nodo del plano de control. Por lo general, tienes una sola máquina si usas una implementación mínima, o tres máquinas si usas una implementación de alta disponibilidad (HA). Especifica una cantidad impar de nodos para tener la mayoría de quórum para la alta disponibilidad. Puedes cambiar estas direcciones cada vez que actualices un clúster.
El valor de la marca tiene el siguiente formato:
```
  'node-ip=CP_IP_ADDRESS_1,labels=CP_KEY_1.1=CP_VALUE_1.1;CP_KEY_1.2=CP_VALUE_1.2;...' \
```
El valor tiene segmentos que comienzan con las palabras clave node-ip y labels. Separa cada segmento con una coma.
node-ip: Es la dirección IP de un nodo del plano de control. Solo puedes especificar una node-ip por marca. Si necesitas especificar más de un nodo, vuelve a incluir la marca para cada uno.
labels: Uno o más pares clave-valor adjuntos al nodo.
Ten en cuenta las siguientes reglas de sintaxis:
- Encierra todo el valor entre comillas simples.
- No se permiten espacios en blanco.
- Separa cada par clave=valor en el segmento labels con un punto y coma.
De manera opcional, incluye las siguientes marcas:
--control-plane-node-labels: Usa esta marca para agregar etiquetas a todos los nodos del plano de control. Separa la lista de pares clave=valor con una coma.
```
  --control-plane-node-labels=KEY_1=VALUE_1,KEY_2=VALUE_2
```
--control-plane-node-taints: Usa esta marca para agregar contaminaciones a todos los nodos del plano de control. Cada contaminación es un par clave-valor asociado con un efecto, que debe ser uno de los siguientes: PreferNoSchedule, NoSchedule o NoExecute.
En el siguiente ejemplo, se agregan tres nodos a los nodos del plano de control. Todos los nodos están etiquetados con cp-node-pool-key=cp-node-pool-value y tienen la contaminación dedicated=experimental:PreferNoSchedule.
```
  --control-plane-node-configs='node-ip=192.0.2.1' \
  --control-plane-node-configs='node-ip=192.0.2.2,labels=key2.1=value2.1' \
  --control-planer-node-configs='node-ip=192.0.2.3,labels=key3.1=value3.1;key3.2=value3.2' \
  --control-plane-node-labels=cp-node-pool-key=cp-node-pool-value \
  --control-plane-node-taints=dedicated=experimental:PreferNoSchedule \
```

IP virtuales

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
CONTROL_PLANE_LB_PORT: Es el puerto en el que el balanceador de cargas entrega el servidor de la API de Kubernetes.
Ejemplo: -control-plane-load-balancer-port=443
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.

CIDR de Service y Pod

SERVICE_CIDR_BLOCK: Un rango de direcciones IP, en formato CIDR, que se usarán para los servicios en tu clúster. El rango CIDR debe estar entre /24 y /12, donde /12 proporciona la mayor cantidad de direcciones IP.
Ejemplo: --island-mode-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. El rango CIDR debe estar entre /18 y /8, donde /8 proporciona la mayor cantidad de direcciones IP.
Ejemplo: --island-mode-pod-address-cidr-blocks=192.168.0.0/16

Almacenamiento

--lvp-share-path: Es la ruta de acceso de la máquina anfitrión en la que se pueden crear subdirectorios. Se crea un PersistentVolume (PV) local para cada subdirectorio.
--lvp-share-storage-class: Es la StorageClass que se usará para crear volúmenes persistentes. StorageClass se crea durante la creación del clúster.
--lvp-node-mounts-config-path: Esta es la ruta de acceso de la máquina anfitrión en la que se pueden descubrir los discos activados. Se crea un PersistentVolume (PV) local para cada activación.
--lvp-node-mounts-config-storage: Es la clase de almacenamiento con la que se crean los PV durante la creación del clúster.

Para obtener más información sobre el almacenamiento, consulta Configura el almacenamiento local.

Manual

Con el balanceo de cargas manual, puedes configurar tus propias soluciones de balanceo de cargas para el tráfico del plano de control y el plano de datos. Debes configurar la VIP del plano de control en el balanceador de cargas externo antes de crear un clúster. El balanceador de cargas del plano de control externo también se puede usar para el tráfico del plano de datos, o puedes configurar un balanceador de cargas por separado para el plano de datos. Para obtener más información, consulta Configura el balanceo de cargas manual.

Asegúrate de desplazarte si es necesario para completar el marcador de posición ADMIN_CLUSTER_NAME para la marca --admin-cluster-membership.

gcloud container bare-metal 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 \
  --enable-manual-lb \
  --control-plane-node-configs='node-ip=CP_IP_ADDRESS_1,labels=CP_KEY_1.1=CP_VALUE_1.1;CP_KEY_1.2=CP_VALUE_1.2;...' \
  --control-plane-vip=CONTROL_PLANE_VIP \
  --control-plane-load-balancer-port=CONTROL_PLANE_LB_PORT \
  --ingress-vip=INGRESS_VIP \
  --island-mode-service-address-cidr-blocks=SERVICE_CIDR_BLOCK \
  --island-mode-pod-address-cidr-blocks=POD_CIDR_BLOCK \
  --lvp-share-path=/mnt/localpv-share \
  --lvp-share-storage-class=local-shared \
  --lvp-node-mounts-config-path=/mnt/localpv-disk \
  --lvp-node-mounts-config-storage-class=local-disks

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.

Nodos de plano de control

--control-plane-node-configs: Es la dirección IPv4 de un nodo del plano de control. Los nodos del plano de control ejecutan la carga de trabajo del sistema. Especifica esta marca para cada nodo del plano de control. Por lo general, tienes una sola máquina si usas una implementación mínima, o tres máquinas si usas una implementación de alta disponibilidad (HA). Especifica una cantidad impar de nodos para tener la mayoría de quórum para la alta disponibilidad. Puedes cambiar estas direcciones cada vez que actualices un clúster.
El valor de la marca tiene el siguiente formato:
```
  'node-ip=CP_IP_ADDRESS_1,labels=CP_KEY_1.1=CP_VALUE_1.1;CP_KEY_1.2=CP_VALUE_1.2;...' \
```
El valor tiene segmentos que comienzan con las palabras clave node-ip y labels. Separa cada segmento con una coma.
node-ip: Es la dirección IP de un nodo del plano de control. Solo puedes especificar una node-ip por marca. Si necesitas especificar más de un nodo, vuelve a incluir la marca para cada uno.
labels: Uno o más pares clave-valor adjuntos al nodo.
Ten en cuenta las siguientes reglas de sintaxis:
- Encierra todo el valor entre comillas simples.
- No se permiten espacios en blanco.
- Separa cada par clave=valor en el segmento labels con un punto y coma.
De manera opcional, incluye las siguientes marcas:
--control-plane-node-labels: Usa esta marca para agregar etiquetas a todos los nodos del plano de control. Separa la lista de pares clave=valor con una coma.
```
  --control-plane-node-labels=KEY_1=VALUE_1,KEY_2=VALUE_2
```
--control-plane-node-taints: Usa esta marca para agregar contaminaciones a todos los nodos del plano de control. Cada contaminación es un par clave-valor asociado con un efecto, que debe ser uno de los siguientes: PreferNoSchedule, NoSchedule o NoExecute.
En el siguiente ejemplo, se agregan tres nodos a los nodos del plano de control. Todos los nodos están etiquetados con cp-node-pool-key=cp-node-pool-value y tienen la contaminación dedicated=experimental:PreferNoSchedule.
```
  --control-plane-node-configs='node-ip=192.0.2.1' \
  --control-plane-node-configs='node-ip=192.0.2.2,labels=key2.1=value2.1' \
  --control-planer-node-configs='node-ip=192.0.2.3,labels=key3.1=value3.1;key3.2=value3.2' \
  --control-plane-node-labels=cp-node-pool-key=cp-node-pool-value \
  --control-plane-node-taints=dedicated=experimental:PreferNoSchedule \
```

IP virtuales

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
CONTROL_PLANE_LB_PORT: Es el puerto en el que el balanceador de cargas entrega el servidor de la API de Kubernetes.
Ejemplo: -control-plane-load-balancer-port=443
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.

CIDR de Service y Pod

SERVICE_CIDR_BLOCK: Un rango de direcciones IP, en formato CIDR, que se usarán para los servicios en tu clúster. El rango CIDR debe estar entre /24 y /12, donde /12 proporciona la mayor cantidad de direcciones IP.
Ejemplo: --island-mode-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. El rango CIDR debe estar entre /18 y /8, donde /8 proporciona la mayor cantidad de direcciones IP.
Ejemplo: --island-mode-pod-address-cidr-blocks=192.168.0.0/16

Almacenamiento

--lvp-share-path: Es la ruta de acceso de la máquina anfitrión en la que se pueden crear subdirectorios. Se crea un PersistentVolume (PV) local para cada subdirectorio.
--lvp-share-storage-class: Es la StorageClass que se usará para crear volúmenes persistentes. StorageClass se crea durante la creación del clúster.
--lvp-node-mounts-config-path: Esta es la ruta de acceso de la máquina anfitrión en la que se pueden descubrir los discos activados. Se crea un PersistentVolume (PV) local para cada activación.
--lvp-node-mounts-config-storage: Es la clase de almacenamiento con la que se crean los PV durante la creación del clúster.

Para obtener más información sobre el almacenamiento, consulta Configura el almacenamiento local.

Antes de ejecutar el comando gcloud para crear el clúster, te recomendamos que incluyas --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.

El resultado del comando es similar al siguiente:

Waiting for operation [projects/example-project-12345/locations/us-west1/operations/operation-1679543737105-5f7893fd5bae9-942b3f97-75e59179] to complete.

En el resultado de ejemplo, la 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 bare-metal operations describe OPERATION_ID \
  --project=FLEET_HOST_PROJECT_ID \
  --location=REGION

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.

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

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. Un grupo de nodos es una plantilla para los conjuntos de nodos trabajadores que se crearon en este clúster. Con gcloud CLI, primero creas el clúster y, luego, agregas uno o más grupos de nodos al clúster que acabas de crear.

gcloud container bare-metal node-pools create NODE_POOL_NAME \
  --cluster=USER_CLUSTER_NAME \
  --project=FLEET_HOST_PROJECT_ID \
  --location=REGION \
  --node-configs='node-ip=NP_IP_ADDRESS_1,labels=NP_KEY_1.1=NP_VALUE_1.1;NP_KEY_1.2=NP_VALUE_1.2;...'

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.
--node-configs: Es la dirección IPv4 de una máquina de nodo de trabajo. Especifica esta marca para cada nodo. El valor de la marca tiene el siguiente formato:
```
'node-ip=NP_IP_ADDRESS_1,labels=NP_KEY_1.1=NP_VALUE_1.1;NP_KEY_1.2=NP_VALUE_1.2;...' \
```
El valor tiene segmentos que comienzan con las palabras clave node-ip y labels. Separa cada segmento con una coma.
- node-ip: Es la dirección IP de un nodo de trabajo. Solo puedes especificar una node-ip por marca. Vuelve a agregar esta marca para cada nodo del grupo de nodos.
- labels: Uno o más pares clave-valor adjuntos al nodo.
Ten en cuenta las siguientes reglas de sintaxis:
- Encierra todo el valor entre comillas simples.
- No se permiten espacios en blanco.
- Separa cada par clave=valor en el segmento labels con un punto y coma.
De manera opcional, puedes especificar lo siguiente:
- --node-labels=KEY=VALUE,...: Una lista separada por comas de etiquetas de Kubernetes (pares clave=valor) aplicadas a cada nodo del grupo.
- --node-taints=KEY=VALUE:EFFECT,... Una lista separada por comas de taints de Kubernetes aplicados a cada nodo del grupo. Los taints son pares clave-valor asociados con un efecto. Los taints se usan con tolerancias para la programación de Pods. Especifica una de las siguientes opciones para EFFECT: NoSchedule, PreferNoSchedule, NoExecute.

En el siguiente ejemplo, se crea un grupo de nodos llamado default-pool en user-cluster- y se agregan dos nodos al grupo. Ambos nodos están etiquetados con node-pool-key=node-pool-value y tienen la contaminación dedicated=experimental:PreferNoSchedule.

gcloud container bare-metal node-pools create default-pool \
  --cluster=user-cluster-1  \
  --project=example-project-12345 \
  --location=us-west1 \
  --node-configs='node-ip=10.200.0.10' \
  --node-configs='node-ip=10.200.0.11,labels=key2.1=value2.1' \
  --node-labels=node-pool-key=node-pool-value \
  --node-taints=dedicated=experimental:PreferNoSchedule

Para obtener más información, consulta la referencia de la CLI de gcloud.

Terraform

Antes de comenzar

La versión de Google Distributed Cloud (solo software) en Bare Metal que selecciones cuando crees un clúster de usuario debe ser una versión que admita tu clúster de administrador. Además, las versiones secundarias o de parche más recientes no están disponibles en la API de GKE On-Prem hasta 7 o 14 días después de la actualización. Puedes ejecutar un comando gcloud para obtener una lista de las versiones compatibles que puedes usar para instalar el clúster de usuarios.

Asegúrate de actualizar los componentes:
```
gcloud components update
```
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 administrador. 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 para instalar en el clúster de usuarios:
```
gcloud container bare-metal 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:
- version: 1.16.2
- version: 1.16.1
- version: 1.16.0
- version: 1.15.7
- version: 1.15.6
- version: 1.15.5
```

Te sugerimos que uses la versión compatible más reciente para obtener las correcciones y mejoras más recientes.

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. Para obtener más información, consulta la documentación de referencia de google_gkeonprem_bare_metal_cluster.

Configura variables en `terraform.tfvars`

El ejemplo proporciona un archivo de variables de ejemplo para pasar a main.tf, que muestra cómo configurar el balanceador de cargas MetalLB incluido.

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/abm_user_cluster_metallb
```
La muestra proporciona un archivo de variables de ejemplo para pasar a main.tf.
Crea una copia del archivo terraform.tfvars.sample.
```
cp terraform.tfvars.sample terraform.tfvars
```
Modifica los valores de los parámetros en terraform.tfvars y guarda el archivo.
```
project_id          = "PROJECT_ID"
region              = "ON_PREM_API_REGION"
admin_cluster_name  = "ADMIN_CLUSTER_NAME"
bare_metal_version  = "VERSION"
admin_user_emails   = ["YOUR_EMAIL_ADDRESS", "ADMIN_2_EMAIL_ADDRESS"]
cluster_name        = "abm-user-cluster-metallb"
control_plane_ips   = ["10.200.0.4"]
worker_node_ips     = ["10.200.0.5", "10.200.0.6"]
control_plane_vip   = "10.200.0.50"
ingress_vip         = "10.200.0.51"
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.
Importante: Si planeas instalar Cloud Service Mesh, debes instalar la versión 1.19.3 o una posterior. Esto es necesario porque los servicios de la flota y de conexión se ejecutan en una región.
- 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 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}"
```
  3. Cambia global a la región que usa el clúster de administrador y guarda el archivo.
- bare_metal_version: Es la versión de Google Distributed Cloud para tu clúster de usuario. Especifica la misma versión que el clúster de administrador o una versión que no sea más de una versión secundaria inferior al 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 otorgar a los 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_ips: Es una lista de una o más direcciones IPv4 para los nodos del plano de control. Los nodos del plano de control ejecutan la carga de trabajo del sistema. Por lo general, tienes una sola máquina si usas una implementación mínima, o tres máquinas si usas una implementación de alta disponibilidad (HA). Especifica una cantidad impar de nodos para tener la mayoría de quórum para la alta disponibilidad. Puedes cambiar estas direcciones cada vez que actualices un clúster.
- worker_node_ips: Es una lista de una o más direcciones IPv4 para las máquinas de los nodos de trabajo.
- 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.
Guarda los cambios en terraform.tfvars.
Inicializa y crea terraform plan:
```
terraform init
```
Terraform instala las bibliotecas necesarias, como el proveedor de Google Cloud .
Revisa la configuración y realiza cambios si es necesario:
```
terraform plan
```
Aplica el plan de Terraform para crear el clúster de usuario:
```
terraform apply
```
La creación del clúster de usuario toma 15 minutos o más. Puedes ver el clúster en la consola de Google Cloud, en la página Clústeres de GKE.

Conéctate al clúster de usuario

Cuando creas un clúster de usuario en la consola, el clúster se configura con las políticas de control de acceso basado en roles (RBAC) de Kubernetes para que puedas acceder al clúster con tu identidad de Google Cloud . Cuando creas un clúster de usuarios con la CLI de gcloud, de forma predeterminada, se te otorgan estas políticas de RBAC si no incluyes la marca --admin-users. 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. Para obtener más información sobre las políticas de IAM y RBAC requeridas, consulta Cómo configurar la autenticación de identidad de Google.

Todos los clústeres tienen un extremo canónico. El extremo expone el servidor de API de Kubernetes que kubectl y otros servicios usan para comunicarse con el plano de control del clúster en el puerto TCP 443. No se puede acceder a este extremo en la Internet pública. Si tienes acceso al extremo privado de tu clúster a través de tu VPC, puedes conectarte directamente al extremo privado y generar un archivo kubeconfig directamente. De lo contrario, puedes usar la puerta de enlace de Connect.

Para acceder al clúster de usuario desde la línea de comandos, necesitas un archivo kubeconfig. Existen dos maneras de obtener un archivo kubeconfig:

Usa la puerta de enlace de Connect para acceder al clúster desde una computadora que tenga instalado Google Cloud CLI. En este caso, kubectl usa el kubeconfig de la puerta de enlace de Connect, que reenvía de forma segura el tráfico al extremo privado en tu nombre.
Para acceder directamente a los extremos privados, crea un archivo kubeconfig en la estación de trabajo de administrador y administra el clúster desde la estación de trabajo de administrador.

Asegúrate de esperar hasta que la consola de Google Cloud indique que el estado del clúster de usuario está en buen estado.

Conecta la puerta de enlace

Inicializa la CLI de gcloud para usarla con el proyecto host de la flota o ejecuta los siguientes comandos para acceder con tu Cuenta de Google, configura el proyecto host de tu flota como el predeterminado y actualiza los componentes:
```
gcloud auth login
gcloud config set project PROJECT_ID
gcloud components update
```
Recupera las credenciales del clúster que se usan para interactuar con la puerta de enlace de Connect. En el siguiente comando, reemplaza MEMBERSHIP_NAME por el nombre de tu clúster. En el caso de Google Distributed Cloud (solo software) en Bare Metal, el nombre de la membresía es el mismo que el nombre del clúster.
```
gcloud container fleet memberships get-credentials MEMBERSHIP_NAME
```
Mediante este comando, se muestra una kubeconfig específica de la puerta de enlace de Connect especial con la que puedes conectarte al clúster a través de la puerta de enlace.

Una vez que tengas las credenciales necesarias, puedes ejecutar comandos mediante kubectl como lo harías con cualquier clúster de Kubernetes y no necesitas especificar el nombre del archivo kubeconfig, por ejemplo:

kubectl get namespaces

Estación de trabajo de administrador

Usa el comando bmctl get credentials para recuperar un archivo kubeconfig para el clúster de usuarios que se creó recientemente.

bmctl get credentials --cluster CLUSTER_NAME --admin-kubeconfig ADMIN_KUBECONFIG_PATH

Reemplaza lo siguiente:

CLUSTER_NAME: Es el nombre del clúster de usuario de destino.
ADMIN_KUBECONFIG_PATH: Es la ruta al archivo kubeconfig del clúster de administrador

Un kubeconfig con las credenciales del clúster de usuario se escribe en un archivo, bmctl-workspace/CLUSTER_NAME/CLUSTER_NAME-TIMESTAMP-kubeconfig. Los TIMESTAMP en el nombre del archivo indican la fecha y hora en que se creó el archivo.

Debido a que este archivo contiene credenciales de autenticación para tu clúster, debes almacenarlo en una ubicación segura con acceso restringido.

Crea un clúster de usuario con clientes de la API de GKE On-Prem

¿Qué es la API de GKE On-Prem?

Antes de comenzar

Otorga permisos de IAM

APIs de Google obligatorias

Requisitos previos del clúster de administrador

Requisitos previos de la máquina del nodo del clúster

Acceso a la línea de comandos

Crea un clúster de usuario

Console

Aspectos básicos del clúster

Herramientas de redes

Incluido con MetalLB

Balanceador de cargas manual

Almacenamiento

Funciones

Crea un grupo de nodos en la consola

gcloud CLI

Antes de comenzar

Ejemplos

MetalLB

Grupos de direcciones de MetalLB

Nodos de MetalLB

Nodos de plano de control

IP virtuales

CIDR de Service y Pod

Almacenamiento

Manual

Nodos de plano de control

IP virtuales

CIDR de Service y Pod

Almacenamiento

Crea un grupo de nodos

Terraform

Antes de comenzar

Ejemplo

Configura variables en terraform.tfvars

Conéctate al clúster de usuario

Conecta la puerta de enlace

Estación de trabajo de administrador

¿Qué sigue?

Configura variables en `terraform.tfvars`