Crear un clúster de usuarios con clientes de la API GKE On-Prem

En esta página se describe cómo crear un clúster de usuario con la Google Cloud consola, la interfaz de línea de comandos de Google Cloud (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 gestionar el ciclo de vida de tus clústeres on-premise mediante Terraform y aplicaciones estándar deGoogle Cloud . La API GKE On-Prem se ejecuta en la infraestructura de Google Cloud. Terraform, la consola y la CLI de gcloud son clientes de la API y la usan para crear clústeres en tu centro de datos.

Para gestionar el ciclo de vida de tus clústeres, la API de GKE On-Prem debe almacenar metadatos sobre el estado de tu clúster en Google Cloud, usando la regiónGoogle Cloud que especifiques al crear el clúster. Estos metadatos permiten que la API gestione el ciclo de vida del clúster y no incluyen datos específicos de la carga de trabajo.

Cuando creas un clúster con un cliente de la API de GKE On-Prem, especificas unGoogle Cloud proyecto. Una vez creado el clúster, se registra automáticamente en la flota del proyecto especificado. Este proyecto se denomina proyecto host de la flota. El proyecto host de la flota no se puede cambiar después de crear el clúster.

Si lo prefieres, puedes crear un clúster de usuarios creando un archivo de configuración de clúster de usuarios y usando bmctl, tal como se describe en Crear un clúster de usuarios.

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

Antes de empezar

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

Conceder permisos de gestión de identidades y accesos

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

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

Una vez creado el clúster, si no eres el propietario del proyecto y quieres conectarte al clúster de usuario mediante la línea de comandos a través de la pasarela de conexión, necesitas los siguientes roles:

  • roles/gkehub.gatewayAdmin: este rol te permite acceder a la API Connect Gateway. Si solo necesitas acceso de lectura al clúster, el 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 conceder los roles, consulta el artículo Gestionar acceso a proyectos, carpetas y organizaciones.

APIs de Google obligatorias

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

Si vas a usar la CLI de gcloud para crear el clúster, debes habilitar la API de GKE On-Prem. Si usas la consola para crear el clúster, la API GKE On-Prem se habilita 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 los siguientes requisitos:

  • Tener acceso al servidor de la API de Kubernetes en el clúster de usuario después de crearlo.

  • Tener conectividad de red con todos los nodos del clúster de usuarios después de crearlo.

  • Debe estar registrado en una flota. El ID de proyecto configurado en el campo gkeConnect.projectID del clúster de administrador, que se conoce como proyecto de host de flota, debe ser el mismo proyecto en el que vas a crear el clúster de usuarios.

Requisitos previos de los equipos de los nodos de clúster

Consulta los requisitos de las máquinas de los nodos del clúster para asegurarte de que las máquinas que ejecutarán el clúster de usuario cumplen los requisitos.

Acceso a la línea de comandos

Una vez creado el clúster, si quieres usar la pasarela de conexión para ejecutar kubectl en el clúster de usuario en ordenadores que no sean la estación de trabajo de administrador, instala las siguientes herramientas de línea de comandos en el ordenador que quieras usar.

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

Crear clúster de usuarios

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

Cuando te hayas familiarizado con la información que debes proporcionar para crear clústeres, puede que te resulte más práctico usar Terraform o la CLI de gcloud, sobre todo si vas a crear más de un clúster. Terraform es una herramienta de infraestructura como código estándar del sector. Si tu organización ya usa Terraform, probablemente quieras usarlo para crear clústeres y gestionar su ciclo de vida.

Con la interfaz de línea de comandos gcloud, puedes guardar el comando con sus argumentos en un archivo de texto y hacer los cambios que necesites para crear más clústeres. Si usas una herramienta de CI/CD, como Cloud Build, puedes usar los comandos gcloud para crear un clúster y un pool de nodos, y especificar la marca --impersonate-service-account para automatizar la creación.

Consola

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

  1. En la consola, ve a la página Crear un clúster de metal desnudo.

    Ir a Crear un clúster de metal desnudo

  2. Selecciona el Google Cloud proyecto en el que quieras crear el clúster. El proyecto seleccionado también se usa como proyecto host de la flota. Debe ser el mismo proyecto en el que está registrado el clúster de administrador. Una vez creado el clúster de usuarios, se registra automáticamente en la flota del proyecto seleccionado.

  3. Haz clic en Siguiente para empezar a configurar el clúster.

En las siguientes secciones se explica cómo configurar el clúster de usuarios.

Información básica de los clústeres

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

  1. Introduce un nombre para el clúster de usuario.

  2. En Clúster de administrador, selecciona el clúster de administrador de la lista.

  3. En el campo Ubicación de la API de Google Cloud, selecciona la Google Cloud región de la lista. Este ajuste especifica la región en la que se ejecutan las siguientes APIs y servicios:

    • API de GKE On-Prem (gkeonprem.googleapis.com)
    • Servicio de flota (gkehub.googleapis.com)
    • Conectar servicio (gkeconnect.googleapis.com)

    Este ajuste también controla la región en la que se almacenan los siguientes elementos:

    • Los metadatos del clúster de usuario que necesita la API de GKE On-Prem para gestionar el ciclo de vida del clúster
    • Los datos de Cloud Logging y Cloud Monitoring de los componentes del sistema
    • El registro de auditoría de administrador creado por los registros de auditoría de Cloud

    El nombre, el proyecto y la ubicación del clúster identifican de forma única el clúster en Google Cloud.

  4. Selecciona la versión de tu clúster de usuario. Los clústeres de usuarios deben tener la misma versión secundaria que el clúster de administrador o una versión secundaria inferior a la del clúster de administrador.

  5. Como creador del clúster, tienes privilegios de administrador del clúster. Opcionalmente, introduce la dirección de correo de otro usuario que vaya a 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 roles (RBAC) de Kubernetes al clúster para concederte a ti y a otros usuarios administradores el rol clusterrole/cluster-admin de Kubernetes, que proporciona acceso completo a todos los recursos del clúster en todos los espacios de nombres.

  6. En la sección Configuración de nodos, especifique lo siguiente:

    • Número máximo de pods por nodo: introduce el número máximo de pods que se pueden ejecutar en un solo nodo. Los valores permitidos están entre 32 y 250, ambos incluidos. 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 cómo definir el número máximo de pods por nodo, consulta Red de pods.

    • Entorno de ejecución de contenedores: containerd es el único entorno de ejecución de contenedores disponible para tu clúster.

  7. Haz clic en Siguiente para ir a la sección Redes.

Redes

En esta sección, se especifican las direcciones IP de los nodos, los pods y los servicios del clúster. Si usas el balanceo de carga agrupado con MetalLB, también debes configurarlo.

  1. En la sección de nodos Plano de control, introduce la dirección IPv4 de cada nodo del plano de control. Los nodos del plano de control ejecutan la carga de trabajo del sistema. Normalmente, se trata de una sola máquina si se usa una implementación mínima o de tres máquinas si se usa una implementación de alta disponibilidad. Especifica un número impar de nodos para que haya un quórum mayoritario en la alta disponibilidad. Este campo se puede cambiar cada vez que actualices o mejores un clúster.

    Haz clic en + Añadir dirección IP según sea necesario para introducir más direcciones IP.

  2. En la sección Balanceador de carga, selecciona el balanceador de carga de la lista Modo para configurarlo en tu clúster. Para obtener más información, consulta la información general sobre los balanceadores de carga.

    Incluido con MetalLB

    Configura el balanceo de carga con el balanceador de carga MetalLB agrupado. Con esta opción, Google Distributed Cloud implementa balanceadores de carga de capa 4 que se ejecutan en un grupo dedicado de nodos de trabajador o en los mismos nodos que el plano de control.

    1. En la sección Grupos de nodos del balanceador de carga, seleccione una de las siguientes opciones:

      • Usar nodos del plano de control: elige esta opción para ejecutar los balanceadores de carga en los mismos nodos que el plano de control.

      • Crear grupo de nodos del balanceador de carga: elige esta opción avanzada si necesitas ejecutar los balanceadores de carga en un grupo de nodos de trabajo específico. Todos los nodos del grupo de nodos del balanceador de carga deben estar en la misma subred de capa 2 que las IPs virtuales (VIPs) del balanceador de carga que configure en la sección Grupos de direcciones del balanceador de carga.

        1. En el campo IP 1 del grupo de nodos del balanceador de carga, introduce una dirección IPv4 para un nodo de tu grupo de nodos del balanceador de carga.

        2. Haz clic en + Añadir dirección IP según sea necesario para introducir más direcciones IP.

    2. En la sección Grupos de direcciones del balanceador de carga, añade uno o varios grupos de direcciones para que el controlador de MetalLB elija y asigne a los servicios de tipo LoadBalancer. El VIP de entrada, que se especifica en la sección IPs virtuales, debe estar en uno de estos pools.

      1. Introduce un nombre para el grupo de direcciones.

      2. Introduce un intervalo de direcciones IP en notación CIDR (por ejemplo, 192.0.2.0/26) o en notación de intervalo (por ejemplo, 192.0.2.64-192.0.2.72). Para especificar una sola dirección IP en un pool, usa /32 en la notación CIDR (por ejemplo, 192.0.2.1/32).

      3. Si el VIP de entrada no está en el intervalo de direcciones, selecciona + Añadir intervalo de direcciones IP e introduce otro intervalo de direcciones que incluya el VIP de entrada.

        Las direcciones IP de cada grupo no pueden solaparse y deben estar en la misma subred que los nodos del clúster.

      4. En Asignación de direcciones IP, seleccione una de las siguientes opciones:

        • Automático: elige esta opción si quieres que el controlador de MetalLB asigne automáticamente direcciones IP del pool de direcciones a los servicios de tipo LoadBalancer.
        • Manual: elige esta opción si quieres usar direcciones del grupo para especificar manualmente las direcciones de los servicios de tipo LoadBalancer.

      5. Haz clic en Evitar direcciones IP con errores si quieres que el controlador de MetalLB no use direcciones del grupo que terminen en .0 o .255. De esta forma, se evita el problema de que los dispositivos de consumo con errores descarten por error el tráfico enviado a esas direcciones IP especiales.

      6. Cuando hayas terminado, haz clic en Hecho.

      7. Si es necesario, haz clic en Añadir grupo de direcciones.

    Balanceador de carga manual

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

  3. En la sección IPs virtuales, introduce lo siguiente:

    • VIP del plano de control: la dirección IP de destino que se usará para el tráfico enviado al servidor de la API de Kubernetes del clúster de usuario. El VIP del plano de control debe estar en la misma subred que los nodos del balanceador de carga y no debe estar en ninguno de los intervalos de direcciones utilizados para los pools de direcciones del balanceador de carga.

    • Puerto: el puerto de destino que se usa para el tráfico enviado al servidor de la API de Kubernetes. El valor predeterminado es 443.

    • IP virtual de entrada: la dirección IP que se configurará en el balanceador de carga para el proxy de entrada. Introduce una dirección de uno de los grupos de direcciones del balanceador de carga.

  4. En la sección Service and Pod CIDRs (CIDRs de servicios y pods), especifica los intervalos de direcciones IP de los servicios y los pods de Kubernetes con notación CIDR. No deben solaparse entre sí ni con ninguna dirección fuera del clúster a la que quieras acceder desde dentro del clúster. Le recomendamos que utilice los intervalos de direcciones IP privadas definidos en RFC 1918. La consola proporciona los siguientes intervalos de direcciones predeterminados, pero puedes cambiarlos:

    • CIDR de servicio: 10.96.0.0/20 si no aceptas el valor predeterminado, introduce un intervalo CIDR entre /24 y /12. /12 proporciona el mayor número de direcciones IP.

    • CIDR de los pods: 192.168.0.0/16 si no aceptas el valor predeterminado, introduce un intervalo CIDR entre /18 y /8. /8 proporciona el mayor número de direcciones IP.

  5. En la sección de atributos Atributos avanzados, especifica lo siguiente (opcional):

    • URL del proxy: la dirección HTTP de tu servidor proxy. Incluye el número de puerto aunque sea el mismo que el puerto predeterminado del esquema. Por ejemplo: http://my-proxy.example.local:80

    • URLs: lista separada por comas de direcciones IP, intervalos 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 directamente.

  6. Haz clic en Siguiente.

Almacenamiento

El software de Google Distributed Cloud solo proporciona interfaces de almacenamiento de bloques y de archivos. Tienen opciones predeterminadas, pero puedes personalizar las configuraciones. Para obtener más información, consulta Configurar el almacenamiento local.

  1. También puedes configurar lo siguiente:

    • Montajes de nodos de aprovisionador de volúmenes locales: especifica la configuración de PersistentVolumes (PVs) locales respaldados por discos montados. Debes formatear y montar estos discos, lo que puedes hacer antes o después de crear el clúster.

    • Recursos compartidos del aprovisionador de volúmenes locales: especifica la configuración de PersistentVolumes locales respaldados por subdirectorios de un sistema de archivos compartido. Estas subcarpetas se crean automáticamente durante la creación del clúster.

  2. Haz clic en Siguiente.

Funciones

Para ayudarte a monitorizar, solucionar problemas y operar tu clúster, se habilitan automáticamente las siguientes opciones, que no se pueden inhabilitar:

Crear un grupo de nodos en la consola

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

En la consola, configura al menos un grupo de nodos (o acepta los valores predeterminados) y, a continuación, crea el clúster. Puedes añadir grupos de nodos adicionales después de crear el clúster. Con la CLI de gcloud, primero creas el clúster y, a continuación, añades uno o varios grupos de nodos al clúster recién creado.

  1. En la barra de navegación de la izquierda, haga clic en grupo predeterminado.

  2. En la sección Valores predeterminados del grupo de nodos, introduzca el Nombre del grupo de nodos o acepte "default-pool" como nombre.

  3. En la sección Nodos de trabajo, introduce las direcciones IP de las máquinas en las que se ejecutará el clúster.

  4. En la sección Metadatos del grupo de nodos (opcional), si quieres añadir etiquetas y taints de Kubernetes, haz lo siguiente:

    1. Haz clic en + Añadir etiquetas de Kubernetes. Introduce la clave y el valor de la etiqueta. Repite el proceso tantas veces como sea necesario.
    2. Haz clic en + Añadir Taint. Introduce la clave, el valor y el efecto de la contaminación. Repite el proceso tantas veces como sea necesario.

  5. Haz clic en Verificar y completar para crear el clúster de usuarios. La creación del clúster de usuarios tarda 15 minutos o más. La consola muestra mensajes de estado mientras verifica la configuración y crea el clúster en tu centro de datos.

    Si hay algún problema con la configuración, la consola mostrará un mensaje de error que debería ser lo suficientemente claro para que puedas solucionar el problema de configuración e intentar crear el clúster de nuevo.

CLI de gcloud

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

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 se corresponden con los campos del archivo de configuración del clúster de usuarios. Para ayudarte a empezar, 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 la referencia de la CLI gcloud.

Antes de empezar

La versión que selecciones al crear un clúster de usuarios debe ser una versión compatible con tu clúster de administradores. Además, las últimas versiones secundarias o de parche 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 versiones de clúster compatibles que puedes instalar.

  1. Asegúrate de actualizar los componentes:

    gcloud components update

  2. Obtén el nombre y la ubicación de la pertenencia a la flota de tu clúster de administrador:

    gcloud container fleet memberships list \
  --project=FLEET_HOST_PROJECT_ID

    Sustituye FLEET_HOST_PROJECT_ID por el ID del proyecto en el que está registrado el clúster de administrador.

    El resultado debería ser similar al siguiente:

    NAME             EXTERNAL_ID                           LOCATION
admin-cluster-1  bb7803b4-8438-4b22-859f-4559b4b29072  global
admin-cluster-2  ee16ee2b-6ec0-49fc-9413-3c89cbc70854  global
admin-cluster-3  fc2b7ef5-39ff-4b63-b919-04c5adc67be4  us-west1

    La ubicación especifica dónde se ejecutan los servicios Fleet y Connect. Los clústeres de administrador creados antes de la versión 1.28 se gestionan mediante los servicios globales de flota y de conexión. En la versión 1.28 y posteriores, puedes especificar global o una Google Cloud región al crear el clúster de administrador. En los comandos de ejemplo que se muestran a continuación, se especifica la región con la marca --admin-cluster-membership-location.

  3. Obtén una lista de las versiones disponibles para instalar en el clúster de usuario:

    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

    Haz los cambios siguientes:

    • ADMIN_CLUSTER_NAME: nombre del clúster de administrador.

    • FLEET_HOST_PROJECT_ID: ID del proyecto en el que está registrado el clúster de administrador.

    • ADMIN_CLUSTER_REGION: la región de pertenencia a la flota del clúster de administrador. Puede ser global o de una Google Cloud región. Usa la ubicación del clúster de administradores de la salida de gcloud container fleet memberships list.

    • REGION: la Google Cloud región que usarás al crear el clúster. Es la región en la que se ejecutan la API de GKE On-Prem y los servicios Fleet y Connect. Especifica us-west1 u otra región admitida.

    El resultado del comando es similar al siguiente:

    versions:
- 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 recomendamos que uses la versión más alta compatible para obtener las últimas correcciones y mejoras.

Ejemplos

En esta sección se muestra un ejemplo de un comando que crea un clúster con el balanceador de carga MetalLB y otro ejemplo con un balanceador de carga manual. La información que especifiques variará en función del tipo de balanceador de carga que vayas a usar. Consulta la información general sobre los balanceadores de carga 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 funcionamiento, debes añadir un grupo de nodos antes de desplegar las cargas de trabajo.

MetalLB

En este ejemplo se muestra cómo crear un clúster de usuarios con el balanceador de carga MetalLB incluido.

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

Haz los cambios siguientes:

  • USER_CLUSTER_NAME: el nombre que elijas para el clúster de usuarios. El nombre no se puede cambiar después de crear el clúster. El nombre debe cumplir las condiciones siguientes:
    • Contener un máximo de 40 caracteres
    • Contener únicamente caracteres alfanuméricos en minúscula o un guion (-)
    • Empezar por un carácter alfabético
    • terminar con un carácter alfanumérico
  • FLEET_HOST_PROJECT_ID: el ID del proyecto en el que quieres crear el clúster. El proyecto especificado también se usa como proyecto host de la flota. Debe ser el mismo proyecto en el que está registrado el clúster de administrador. Una vez creado el clúster de usuario, se registra automáticamente en la flota del proyecto seleccionado. El proyecto host de la flota no se puede cambiar una vez creado el clúster.
  • ADMIN_CLUSTER_NAME: el nombre del clúster de administrador que gestiona el clúster de usuario. En la marca --admin-cluster-membership, puedes usar el nombre de clúster totalmente especificado, que tiene el siguiente formato: 
        projects/FLEET_HOST_PROJECT_ID/locations/ADMIN_CLUSTER_REGION/memberships/ADMIN_CLUSTER_NAME

    También puedes definir --admin-cluster-membership con el nombre del clúster de administrador, como en el comando de ejemplo. Si solo usas el nombre del clúster de administrador, define el ID del proyecto del clúster de administrador con --admin-cluster-membership-project y la ubicación con --admin-cluster-membership-location. La ubicación del clúster de administrador es global o una Google Cloud región. Si necesitas encontrar la región, ejecuta gcloud container fleet memberships list.

  • REGION: la región en la que se ejecutan la API de GKE On-Prem ( Google Cloud ), el servicio Fleet (gkeonprem.googleapis.com) y el servicio Connect (gkehub.googleapis.com).gkeconnect.googleapis.com Especifica us-west1 u otra región admitida. La región no se puede cambiar después de crear el clúster. Este ajuste especifica la región en la que se almacenan los siguientes elementos:
    • Los metadatos del clúster de usuario que necesita la API de GKE On-Prem para gestionar el ciclo de vida del clúster
    • Los datos de Cloud Logging y Cloud Monitoring de los componentes del sistema
    • El registro de auditoría de administrador creado por los registros de auditoría de Cloud

    El nombre, el proyecto y la ubicación del clúster identifican de forma única el clúster en Google Cloud.

  • VERSION: la versión de Google Distributed Cloud de tu clúster de usuario.
  • YOUR_EMAIL_ADDRESS y ANOTHER_EMAIL_ADDRESS: Si no incluyes la marca --admin-users, como creador del clúster, se te concederán privilegios de administrador del clúster de forma predeterminada. Sin embargo, si incluyes --admin-users para designar a otro usuario como administrador, se anulará el valor predeterminado y deberás incluir tanto tu dirección de correo como la del otro administrador. Por ejemplo, para añadir dos administradores, sigue estos pasos: 
        --admin-users=sara@example.com \
    --admin-users=amal@example.com

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

Grupos de direcciones de MetalLB

  • --metal-lb-address-pools: especifica la configuración de los grupos de direcciones que utilizará el balanceador de carga 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 empiezan por las palabras clave pool, avoid-buggy-ip, manual-assign y addresses. Separa cada segmento con una coma.

  • pool: el nombre que elijas para el grupo.

  • avoid-buggy-ips: Si lo defines como True, el controlador de MetalLB no asigna direcciones IP que terminen en .0 o .255 a los servicios. De esta forma, se evita el problema de que los dispositivos de consumo con errores descarten por error el tráfico enviado a esas direcciones IP especiales. Si no se especifica ningún valor, se utiliza False de forma predeterminada.

  • manual-assign: Si no quieres que el controlador de MetalLB asigne automáticamente direcciones IP de este grupo a los servicios, define este valor como True. Después, un desarrollador puede crear un servicio de tipo LoadBalancer y especificar manualmente una de las direcciones del grupo. Si no se especifica, manual-assign se define como False.

  • En la lista de addresses, cada dirección debe ser un intervalo en formato CIDR o en formato de intervalo con guion. Para especificar una sola dirección IP en un pool (por ejemplo, para la IP virtual de entrada), usa /32 en la notación CIDR (por ejemplo, 192.0.2.1/32).

Ten en cuenta las siguientes reglas de sintaxis:

  • Escribe todo el valor entre comillas simples.
  • No se permiten espacios.
  • Separe cada intervalo 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 carga se ejecuta en los mismos nodos que el plano de control. Si necesitas ejecutar el balanceador de carga en un grupo de nodos de trabajo específico, especifica esta marca para cada nodo. Todos los nodos del grupo de nodos del balanceador de carga deben estar en la misma subred de capa 2 que las IPs virtuales (VIPs) del balanceador de carga.

    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 empiezan por las palabras clave node-ip y labels. Separa cada segmento con una coma.

    • node-ip: la dirección IP de un nodo del grupo de nodos de tu balanceador de carga. Solo puedes especificar un node-ip por cada marca. Si necesitas especificar más de un nodo, incluye la marca de nuevo para cada nodo.

    • labels: uno o varios pares clave-valor asociados al nodo.

    Ten en cuenta las siguientes reglas de sintaxis:

    • Escribe todo el valor entre comillas simples.
    • No se permiten espacios.
    • Separa cada par clave=valor del segmento labels con un punto y coma.

    Si especificas --metal-lb-load-balancer-node-configs, puedes incluir opcionalmente las siguientes marcas:

    • --metal-lb-load-balancer-node-labels: usa esta marca para añadir etiquetas a todos los nodos del grupo de nodos del balanceador de carga. Separa la lista de pares 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 añadir intolerancias a todos los nodos del grupo de nodos del balanceador de carga. Cada taint es un par clave-valor asociado a 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 añaden tres nodos al grupo de nodos del balanceador de carga. Todos los nodos están etiquetados con lb-pool-key=lb-pool-value y tienen el taint 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 del plano de control

  • --control-plane-node-configs: 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 en cada nodo del plano de control. Normalmente, tienes una sola máquina si usas una implementación mínima o tres máquinas si usas una implementación de alta disponibilidad. Especifica un número impar de nodos para que haya un quórum mayoritario en la alta disponibilidad. Puedes cambiar estas direcciones cada vez que actualices o mejores 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 empiezan por las palabras clave node-ip y labels. Separa cada segmento con una coma.

  • node-ip: la dirección IP de un nodo del plano de control. Solo puedes especificar un node-ip por marca. Si necesitas especificar más de un nodo, incluye la marca de nuevo para cada nodo.
  • labels: uno o varios pares clave-valor asociados al nodo.

    Ten en cuenta las siguientes reglas de sintaxis:

    • Escribe todo el valor entre comillas simples.
    • No se permiten espacios.
    • Separa cada par clave=valor del segmento labels con un punto y coma.

    Opcionalmente, incluye las siguientes marcas:

  • --control-plane-node-labels: usa esta marca para añadir 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 añadir intolerancias a todos los nodos del plano de control. Cada taint es un par clave-valor asociado a un efecto, que debe ser uno de los siguientes: PreferNoSchedule, NoSchedule o NoExecute.

    En el siguiente ejemplo se añaden 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 el taint 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 \

IPs virtuales

  • CONTROL_PLANE_VIP: la dirección IP que has elegido para configurar en el balanceador de carga del servidor de la API de Kubernetes del clúster de usuario.

    Ejemplo: --control-plane-vip=203.0.113.3

  • CONTROL_PLANE_LB_PORT: puerto en el que el balanceador de carga sirve al servidor de la API de Kubernetes.

    Ejemplo: -control-plane-load-balancer-port=443

  • INGRESS_VIP: la dirección IP que has elegido para configurar en el balanceador de carga del proxy de entrada.

    Ejemplo: --ingress-vip=10.251.134.80

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

CIDRs de servicio y de pod

  • SERVICE_CIDR_BLOCK: un intervalo de direcciones IP en formato CIDR que se usará para los servicios de tu clúster. El intervalo CIDR debe estar entre /24 y /12, donde /12 proporciona el mayor número de direcciones IP.

    Ejemplo: --island-mode-service-address-cidr-blocks=10.96.0.0/20

  • POD_CIDR_BLOCK: intervalo de direcciones IP en formato CIDR que se usará para los pods de tu clúster. El intervalo CIDR debe estar entre /18 y /8, donde /8 proporciona el mayor número de direcciones IP.

    Ejemplo: --island-mode-pod-address-cidr-blocks=192.168.0.0/16

Almacenamiento

  1. --lvp-share-path: es la ruta de la máquina host en la que se pueden crear subdirectorios. Se crea un PersistentVolume (PV) local para cada subdirectorio.
  2. --lvp-share-storage-class: es el StorageClass que se usa para crear volúmenes persistentes. StorageClass se crea durante la creación del clúster.
  3. --lvp-node-mounts-config-path: es la ruta de la máquina host donde se pueden descubrir los discos montados. Se crea un PersistentVolume (PV) local para cada montaje.
  4. --lvp-node-mounts-config-storage: la clase de almacenamiento con la que se crean los PVs durante la creación del clúster.

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

Manual

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

Si es necesario, desplázate para rellenar el marcador de posición ADMIN_CLUSTER_NAME de 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

Haz los cambios siguientes:

  • USER_CLUSTER_NAME: el nombre que elijas para el clúster de usuarios. El nombre no se puede cambiar después de crear el clúster. El nombre debe cumplir las condiciones siguientes:
    • Contener un máximo de 40 caracteres
    • Contener únicamente caracteres alfanuméricos en minúscula o un guion (-)
    • Empezar por un carácter alfabético
    • terminar con un carácter alfanumérico
  • FLEET_HOST_PROJECT_ID: el ID del proyecto en el que quieres crear el clúster. El proyecto especificado también se usa como proyecto host de la flota. Debe ser el mismo proyecto en el que está registrado el clúster de administrador. Una vez creado el clúster de usuario, se registra automáticamente en la flota del proyecto seleccionado. El proyecto host de la flota no se puede cambiar una vez creado el clúster.
  • ADMIN_CLUSTER_NAME: el nombre del clúster de administrador que gestiona el clúster de usuario. En la marca --admin-cluster-membership, puedes usar el nombre de clúster totalmente especificado, que tiene el siguiente formato: 
        projects/FLEET_HOST_PROJECT_ID/locations/ADMIN_CLUSTER_REGION/memberships/ADMIN_CLUSTER_NAME

    También puedes definir --admin-cluster-membership con el nombre del clúster de administrador, como en el comando de ejemplo. Si solo usas el nombre del clúster de administrador, define el ID del proyecto del clúster de administrador con --admin-cluster-membership-project y la ubicación con --admin-cluster-membership-location. La ubicación del clúster de administrador es global o una Google Cloud región. Si necesitas encontrar la región, ejecuta gcloud container fleet memberships list.

  • REGION: la región en la que se ejecutan la API de GKE On-Prem ( Google Cloud ), el servicio Fleet (gkeonprem.googleapis.com) y el servicio Connect (gkehub.googleapis.com).gkeconnect.googleapis.com Especifica us-west1 u otra región admitida. La región no se puede cambiar después de crear el clúster. Este ajuste especifica la región en la que se almacenan los siguientes elementos:
    • Los metadatos del clúster de usuario que necesita la API de GKE On-Prem para gestionar el ciclo de vida del clúster
    • Los datos de Cloud Logging y Cloud Monitoring de los componentes del sistema
    • El registro de auditoría de administrador creado por los registros de auditoría de Cloud

    El nombre, el proyecto y la ubicación del clúster identifican de forma única el clúster en Google Cloud.

  • VERSION: la versión de Google Distributed Cloud de tu clúster de usuario.
  • YOUR_EMAIL_ADDRESS y ANOTHER_EMAIL_ADDRESS: Si no incluyes la marca --admin-users, como creador del clúster, se te concederán privilegios de administrador del clúster de forma predeterminada. Sin embargo, si incluyes --admin-users para designar a otro usuario como administrador, se anulará el valor predeterminado y deberás incluir tanto tu dirección de correo como la del otro administrador. Por ejemplo, para añadir dos administradores, sigue estos pasos: 
        --admin-users=sara@example.com \
    --admin-users=amal@example.com

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

Nodos del plano de control

  • --control-plane-node-configs: 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 en cada nodo del plano de control. Normalmente, tienes una sola máquina si usas una implementación mínima o tres máquinas si usas una implementación de alta disponibilidad. Especifica un número impar de nodos para que haya un quórum mayoritario en la alta disponibilidad. Puedes cambiar estas direcciones cada vez que actualices o mejores 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 empiezan por las palabras clave node-ip y labels. Separa cada segmento con una coma.

  • node-ip: la dirección IP de un nodo del plano de control. Solo puedes especificar un node-ip por marca. Si necesitas especificar más de un nodo, incluye la marca de nuevo para cada nodo.
  • labels: uno o varios pares clave-valor asociados al nodo.

    Ten en cuenta las siguientes reglas de sintaxis:

    • Escribe todo el valor entre comillas simples.
    • No se permiten espacios.
    • Separa cada par clave=valor del segmento labels con un punto y coma.

    Opcionalmente, incluye las siguientes marcas:

  • --control-plane-node-labels: usa esta marca para añadir 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 añadir intolerancias a todos los nodos del plano de control. Cada taint es un par clave-valor asociado a un efecto, que debe ser uno de los siguientes: PreferNoSchedule, NoSchedule o NoExecute.

    En el siguiente ejemplo se añaden 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 el taint 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 \

IPs virtuales

  • CONTROL_PLANE_VIP: la dirección IP que has elegido para configurar en el balanceador de carga del servidor de la API de Kubernetes del clúster de usuario.

    Ejemplo: --control-plane-vip=203.0.113.3

  • CONTROL_PLANE_LB_PORT: puerto en el que el balanceador de carga sirve al servidor de la API de Kubernetes.

    Ejemplo: -control-plane-load-balancer-port=443

  • INGRESS_VIP: la dirección IP que has elegido para configurar en el balanceador de carga del proxy de entrada.

    Ejemplo: --ingress-vip=10.251.134.80

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

CIDRs de servicio y de pod

  • SERVICE_CIDR_BLOCK: un intervalo de direcciones IP en formato CIDR que se usará para los servicios de tu clúster. El intervalo CIDR debe estar entre /24 y /12, donde /12 proporciona el mayor número de direcciones IP.

    Ejemplo: --island-mode-service-address-cidr-blocks=10.96.0.0/20

  • POD_CIDR_BLOCK: intervalo de direcciones IP en formato CIDR que se usará para los pods de tu clúster. El intervalo CIDR debe estar entre /18 y /8, donde /8 proporciona el mayor número de direcciones IP.

    Ejemplo: --island-mode-pod-address-cidr-blocks=192.168.0.0/16

Almacenamiento

  1. --lvp-share-path: es la ruta de la máquina host en la que se pueden crear subdirectorios. Se crea un PersistentVolume (PV) local para cada subdirectorio.
  2. --lvp-share-storage-class: es el StorageClass que se usa para crear volúmenes persistentes. StorageClass se crea durante la creación del clúster.
  3. --lvp-node-mounts-config-path: es la ruta de la máquina host donde se pueden descubrir los discos montados. Se crea un PersistentVolume (PV) local para cada montaje.
  4. --lvp-node-mounts-config-storage: la clase de almacenamiento con la que se crean los PVs durante la creación del clúster.

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

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

La salida del comando es similar a la siguiente:

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

En el resultado de ejemplo, la cadena operation-1679543737105-5f7893fd5bae9-942b3f97-75e59179 es el OPERATION_ID de la operación de larga duración. Puedes consultar el estado de la operación con el siguiente comando:

gcloud container bare-metal operations describe OPERATION_ID \
  --project=FLEET_HOST_PROJECT_ID \
  --location=REGION

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

Para ver una lista completa de las marcas y sus descripciones, consulta la referencia de la herramienta de línea de comandos gcloud.

Crear un grupo de nodos

Una vez creado el clúster, debes crear al menos un grupo de nodos antes de desplegar las cargas de trabajo. Un grupo de nodos es una plantilla para los grupos de nodos de trabajo creados en este clúster. Con la CLI de gcloud, primero creas el clúster y, a continuación, añades uno o varios grupos de nodos al clúster recién creado.

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;...'

Haz los cambios siguientes:

  • NODE_POOL_NAME: el nombre que quieras darle al grupo de nodos. El nombre debe cumplir los siguientes requisitos:

    • Contener un máximo de 40 caracteres
    • Contener únicamente caracteres alfanuméricos en minúscula o un guion (-)
    • Empezar por un carácter alfabético
    • terminar con un carácter alfanumérico

  • USER_CLUSTER_NAME: nombre del clúster de usuarios recién creado.

  • FLEET_HOST_PROJECT_ID: el ID del proyecto en el que está registrado el clúster.

  • REGION: la región Google Cloud que especificaste al crear el clúster.

  • --node-configs: 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 empiezan por las palabras clave node-ip y labels. Separa cada segmento con una coma.

    • node-ip: la dirección IP de un nodo de trabajo. Solo puedes especificar un node-ip por cada marca. Añade esta marca de nuevo en cada nodo del grupo de nodos.

    • labels: uno o varios pares clave-valor asociados al nodo.

    Ten en cuenta las siguientes reglas de sintaxis:

    • Escribe todo el valor entre comillas simples.
    • No se permiten espacios.
    • Separa cada par clave=valor del segmento labels con un punto y coma.

    También puedes especificar lo siguiente:

    • --node-labels=KEY=VALUE,...: una lista separada por comas de etiquetas de Kubernetes (pares clave-valor) que se aplica a cada nodo del grupo.

    • --node-taints=KEY=VALUE:EFFECT,... Lista separada por comas de taints de Kubernetes aplicados a cada nodo del grupo. Los taints son pares clave-valor asociados a un efecto. Las intolerancias se usan con las tolerancias para programar pods. Especifique uno de los siguientes valores para EFFECT: NoSchedule, PreferNoSchedule o NoExecute.

En el siguiente ejemplo se crea un grupo de nodos llamado default-pool en user-cluster- y se añaden dos nodos al grupo. Ambos nodos tienen la etiqueta node-pool-key=node-pool-value y el taint 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 empezar

La versión de Google Distributed Cloud (solo software) en hardware desnudo que selecciones al crear un clúster de usuarios debe ser una versión compatible con 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-14 días después del lanzamiento. Puedes ejecutar el comando gcloud para obtener una lista de las versiones compatibles que puedes usar para instalar el clúster de usuario.

  1. Asegúrate de actualizar los componentes:

    gcloud components update

  2. Obtén el nombre y la ubicación de la pertenencia a la flota de tu clúster de administrador:

    gcloud container fleet memberships list \
  --project=FLEET_HOST_PROJECT_ID

    Sustituye FLEET_HOST_PROJECT_ID por el ID del proyecto en el que está registrado el clúster de administrador.

    El resultado debería ser similar al siguiente:

    NAME             EXTERNAL_ID                           LOCATION
admin-cluster-1  bb7803b4-8438-4b22-859f-4559b4b29072  global
admin-cluster-2  ee16ee2b-6ec0-49fc-9413-3c89cbc70854  global
admin-cluster-3  fc2b7ef5-39ff-4b63-b919-04c5adc67be4  us-west1

    La ubicación especifica dónde se ejecutan los servicios Fleet y Connect. Los clústeres de administrador creados antes de la versión 1.28 se gestionan mediante los servicios globales de flota y de conexión. En la versión 1.28 y posteriores, puedes especificar global o una Google Cloud región al crear el clúster de administrador. En los comandos de ejemplo que se muestran a continuación, se especifica la región con la marca --admin-cluster-membership-location.

  3. Obtén una lista de las versiones disponibles para instalar en el clúster de usuario:

    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

    Haz los cambios siguientes:

    • ADMIN_CLUSTER_NAME: nombre del clúster de administrador.

    • FLEET_HOST_PROJECT_ID: ID del proyecto en el que está registrado el clúster de administrador.

    • ADMIN_CLUSTER_REGION: la región de pertenencia a la flota del clúster de administrador. Puede ser global o de una Google Cloud región. Usa la ubicación del clúster de administradores de la salida de gcloud container fleet memberships list.

    • REGION: la Google Cloud región que usarás al crear el clúster. Es la región en la que se ejecutan la API de GKE On-Prem y los servicios Fleet y Connect. Especifica us-west1 u otra región admitida.

    El resultado del comando es similar al siguiente:

    versions:
- 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 recomendamos que uses la versión más alta compatible para obtener las últimas correcciones y mejoras.

Ejemplo

Puedes usar la siguiente configuración básica de ejemplo para crear un clúster de usuarios con el balanceador de carga MetalLB incluido. Para obtener más información, consulta la documentación de referencia de google_gkeonprem_bare_metal_cluster.

Definir variables en terraform.tfvars

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

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

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

    La muestra proporciona un archivo de variables de ejemplo que se debe pasar a main.tf.

  2. Haz una copia del archivo terraform.tfvars.sample:

    cp terraform.tfvars.sample terraform.tfvars

  3. 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: el ID del proyecto en el que quieres crear el clúster. El proyecto especificado también se usa como proyecto host de la flota. Debe ser el mismo proyecto en el que está registrado el clúster de administrador. Una vez creado el clúster de usuario, se registra automáticamente en la flota del proyecto seleccionado. El proyecto host de la flota no se puede cambiar después de crear el clúster.

    • region: la región en la que se ejecutan la API de GKE On-Prem ( Google Cloud ), el servicio de flota (gkeonprem.googleapis.com) y el servicio Connect (gkehub.googleapis.com). (gkeconnect.googleapis.com) Especifica us-west1 u otra región admitida.

    • admin_cluster_name: nombre del clúster de administrador que gestiona el clúster de usuario. En el ejemplo se da por supuesto que el clúster de administrador usa global como región. Si tienes un clúster de administradores regional:

      1. Abre main.tf en un editor de texto.

      2. Busca admin_cluster_membership, que tiene este aspecto:

        admin_cluster_membership = "projects/${var.project_id}/locations/global/memberships/${var.admin_cluster_name}"

      3. Cambia global a la región que usa el clúster de administrador y guarda el archivo.

    • bare_metal_version: la versión de Google Distributed Cloud de 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 a la del clúster de administrador.

    • admin_user_emails: lista de direcciones de correo de los usuarios a los que se les concederán privilegios de administrador en el clúster. Asegúrate de añadir tu dirección de correo si tienes intención de administrar el clúster.

      Cuando se crea el clúster, la API de GKE On-Prem aplica las políticas de control de acceso basado en roles (RBAC) de Kubernetes al clúster para conceder a los usuarios administradores el rol clusterrole/cluster-admin de Kubernetes, que proporciona acceso completo a todos los recursos del clúster en todos los espacios de nombres. También permite a los usuarios iniciar sesión en la consola con su identidad de Google.

    • cluster_name: el nombre que elijas para el clúster de usuarios. El nombre no se puede cambiar después de crear el clúster. El nombre debe cumplir los siguientes requisitos:

      • Contener un máximo de 40 caracteres
      • Contener únicamente caracteres alfanuméricos en minúscula o un guion (-)
      • Empezar por un carácter alfabético
      • terminar con un carácter alfanumérico

    • control_plane_ips: lista de una o varias direcciones IPv4 de los nodos del plano de control. Los nodos del plano de control ejecutan la carga de trabajo del sistema. Normalmente, tienes una sola máquina si usas una implementación mínima o tres máquinas si usas una implementación de alta disponibilidad. Especifica un número impar de nodos para tener un quórum mayoritario para la alta disponibilidad. Puedes cambiar estas direcciones siempre que actualices o mejores un clúster.

    • worker_node_ips: lista de una o varias direcciones IPv4 de las máquinas de los nodos de trabajo.

    • control_plane_vip: la dirección IP virtual (VIP) que has elegido para configurar en el balanceador de carga del servidor de la API de Kubernetes del clúster de usuario.

    • ingress_vip: la dirección IP que has elegido para configurar en el balanceador de carga del proxy de entrada.

    • lb_address_pools: lista de mapas que definen los grupos de direcciones que va a usar el balanceador de carga de MetalLB. El VIP de entrada debe estar en uno de estos grupos.

  4. Guarda los cambios en terraform.tfvars.

  5. Inicializa y crea el plan de Terraform:

    terraform init

    Terraform instala las bibliotecas necesarias, como el Google Cloud proveedor.

  6. Revisa la configuración y haz los cambios necesarios:

    terraform plan

  7. Aplica el plan de Terraform para crear el clúster de usuarios:

    terraform apply

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

Conectarse al clúster de usuarios

Cuando creas un clúster de usuario en la consola, se configura con las políticas de control de acceso basado en roles (RBAC) de Kubernetes para que puedas iniciar sesión en el clúster con tu Google Cloud identidad. Cuando creas un clúster de usuario con gcloud CLI, se te conceden estas políticas de RBAC de forma predeterminada si no incluyes la marca --admin-users. Si incluyes --admin-users para designar a otro usuario como administrador, anulas el valor predeterminado y debes incluir tanto tu dirección de correo como la del otro administrador. Para obtener más información sobre las políticas de IAM y RBAC obligatorias, consulta el artículo Configurar la autenticación de identidad de Google.

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

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

  • Usa la pasarela de conexión para acceder al clúster desde un ordenador que tenga instalada la CLI de Google Cloud. En este caso, kubectl usa el kubeconfig de Connect gateway, que reenvía de forma segura el tráfico al endpoint privado en tu nombre.

  • Para acceder directamente a los endpoints privados, crea un archivo kubeconfig en tu estación de trabajo de administrador y gestiona el clúster desde ella.

Espera hasta que la consola de Google Cloud indique que el estado del clúster de usuarios es correcto.

Pasarela de conexión

  1. Inicializa gcloud CLI para usarlo con el proyecto host de la flota o ejecuta los siguientes comandos para iniciar sesión con tu cuenta de Google, definir el proyecto host de la flota como predeterminado y actualizar los componentes:

    gcloud auth login
gcloud config set project PROJECT_ID
gcloud components update

  2. Obtiene las credenciales del clúster que se usan para interactuar con la pasarela de conexión. En el siguiente comando, sustituye MEMBERSHIP_NAME por el nombre de tu clúster. En Google Distributed Cloud (solo software) en bare metal, el nombre del grupo de miembros es el mismo que el nombre del clúster.

    gcloud container fleet memberships get-credentials MEMBERSHIP_NAME

    Este comando devuelve un comando kubeconfig específico de la pasarela de conexión que te permite conectarte al clúster a través de la pasarela.

Una vez que tengas las credenciales necesarias, podrás ejecutar comandos con kubectl como lo harías normalmente en cualquier clúster de Kubernetes. No es necesario que especifiques el nombre del archivo kubeconfig. Por ejemplo:

kubectl get namespaces

Estación de trabajo de administrador

Usa el comando bmctl get credentials para obtener un archivo kubeconfig del clúster de usuario recién creado.

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

Haz los cambios siguientes:

  • CLUSTER_NAME: el nombre del clúster de usuarios objetivo.

  • ADMIN_KUBECONFIG_PATH: la ruta al archivo kubeconfig del clúster de administrador.

Se escribe un kubeconfig con las credenciales del clúster de usuarios en un archivo, bmctl-workspace/CLUSTER_NAME/CLUSTER_NAME-TIMESTAMP-kubeconfig. El TIMESTAMP del nombre del archivo indica la fecha y la hora en las que se creó el archivo.

Como este archivo contiene las credenciales de autenticación de tu clúster, debes almacenarlo en una ubicación segura con acceso restringido.

Siguientes pasos