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

En esta página, se describe cómo crear un clúster de usuario 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 Cloud que te permite administrar el ciclo de vida de tus clústeres locales con Terraform y las aplicaciones estándar de Google 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 los clústeres, la API de GKE On-Prem debe almacenar metadatos sobre el estado de tu clúster en Google Cloud mediante la región de Google Cloud que especificas cuando creas el clúster. Estos metadatos permiten que la API administre 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, debes especificar un proyecto de Google Cloud. Una vez que se crea 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 que se crea 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 quieres 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 usuario con los clientes de la API de GKE On-Prem.

Otorgar permisos de IAM

Si no eres propietario de un proyecto, se te debe otorgar roles/gkeonprem.admin.

Si quieres acceder a las páginas de Google Kubernetes Engine (GKE) Enterprise y 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 quieres usar la puerta de enlace de conexión para conectarte al clúster de usuario mediante la línea de comandos, se requieren las siguientes funciones:

  • roles/gkehub.gatewayAdmin: Esta función te permite acceder a la API de la puerta de enlace de conexión. Si solo necesitas acceso de solo 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 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, se habilitará 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 crearlo

  • Tener conectividad de red a todos los nodos en el 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 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 la máquina del nodo del clúster para asegurarte de que las máquinas que ejecutarán el clúster de usuario 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 conexión para ejecutar kubectl en el clúster de usuario en computadoras que no sean la estación de trabajo de 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 instructions

Crea un clúster de usuario

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

Una vez que estés más familiarizado con la información que necesitas proporcionar para crear clústeres, es posible que Terraform o 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 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 de gcloud para crear un clúster y un grupo de nodos, y especificar la marca --impersonate-service-account a fin de 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 de clúster.

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

    Ir a Crea un clúster de GKE en Bare Metal

  2. 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.

  3. 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.

Conceptos básicos del clúster

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

  1. Ingresa un Nombre para el clúster de usuarios.

  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 región de Google Cloud de la lista. Esta configuración especifica la región en la que se ejecuta la API de GKE On-Prem y 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.

  4. Selecciona la versión de GKE en Bare Metal para tu clúster de usuario. Los clústeres de usuario deben ser 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 de clústeres, se te otorgan privilegios de administrador de clúster. De forma opcional, ingresa la dirección de correo electrónico de otro usuario que administrará el clúster en el campo Usuario administrador.

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

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

    • Máximo 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 a la cantidad máxima de Pods por nodo. Para obtener más información sobre la configuración de la cantidad máxima de Pods por nodo, consulta las 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.

  7. Haz clic en Siguiente para ir a la sección Herramientas de redes.

Redes

En esta sección, debes especificar las direcciones IP para los nodos, los Pods y los objetos Service del clúster. Si usas el balanceo de cargas en paquetes con MetalLB, también debes configurarlo.

  1. En la sección del nodo 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, se trata de una sola máquina si se usa una implementación mínima o tres máquinas si se usa una implementación de alta disponibilidad (HA). Especifica una cantidad impar de nodos a fin de tener la mayoría de quórum para la alta disponibilidad. Este campo se puede cambiar cada vez que actualizas o actualizas un clúster.

    Haz clic en + Agregar dirección IP según sea necesario para ingresar más direcciones IP.

  2. En la sección Balanceador de cargas, selecciona el balanceador de cargas de la lista Modo para configurarlo en el clúster. Consulta la Descripción general de los balanceadores de cargas para obtener más información.

    Incluido con MetalLB

    Configurar el balanceo de cargas con el balanceador de cargas en paquetes de MetalLB Con esta opción, GKE en Bare Metal 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 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 configuraste en la sección Grupos de direcciones del balanceador de cargas.

        1. En el campo IP del grupo de nodos del balanceador de cargas, ingresa una dirección IPv4 para un nodo en el grupo de nodos del balanceador de cargas.

        2. 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 asígnalos a los servicios de tipo LoadBalancer. La VIP de entrada, que especificas en la sección IP 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 la notación CIDR (por ejemplo: 192.0.2.0/26) o en la 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á dentro del rango de direcciones, selecciona + Agregar 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:

        • Automatic: Elige esta opción si deseas que el controlador de MetalLB asigne automáticamente las direcciones IP del grupo de direcciones a los servicios de tipo LoadBalancer.
        • Manual: Elige esta opción si deseas usar direcciones del grupo a fin de especificar de forma manual direcciones para los 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 del 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 independiente para el plano de datos. Para obtener más información, consulta Configura el balanceo de cargas manual.

  3. 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: 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.

  4. En la sección CIDR de servicio y pod, especifica los rangos de direcciones IP del servicio y del pod 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 dentro del 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:

    • CIDR del servicio: 10.96.0.0/20 Si no aceptas el valor predeterminado, ingresa un rango CIDR entre /24 y /12, en el que /12 proporcione la mayor cantidad de direcciones IP.

    • CIDR del pod: 192.168.0.0/16 Si no aceptas el valor predeterminado, ingresa un rango de CIDR entre /18 y /8, en el que /8 proporcione la mayor cantidad de direcciones IP.

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

    • URL proxy: Es la dirección HTTP del 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: Lista separada por comas de las direcciones IP, los rangos de direcciones IP, los nombres de host y los nombres de dominio que no deben pasar por el servidor proxy. Cuando GKE en Bare Metal envía una solicitud a una de estas direcciones, hosts o dominios, la solicitud se envía directamente.

  6. Haz clic en Siguiente.

Almacenamiento

GKE en Bare Metal proporciona interfaces de almacenamiento en bloque y de archivos. Tienen opciones predeterminadas, pero puedes personalizar las configuraciones. Para obtener más información, consulta Cómo configurar el almacenamiento local.

  1. De manera opcional, puedes configurar lo siguiente:

    • Activaciones de nodos del aprovisionador de volumen local: Especifica la configuración de los PersistentVolumes (PV) locales respaldados por discos activados. Debes formatear y activar estos discos antes o después de crear el clúster.

    • Recurso compartido del aprovisionador de volumen local: Especifica la configuración de PersistentVolumes local, respaldada por subdirectorios en un sistema de archivos compartidos. Estos subdirectorios se crean automáticamente durante la creación del clúster.

  2. Haz clic en Siguiente.

Funciones

Para ayudarte a supervisar, solucionar problemas y operar tu clúster, las siguientes opciones están habilitadas de forma automática y no se pueden inhabilitar:

Crear un grupo de nodos

Tu clúster debe tener al menos un grupo de nodos para los nodos trabajadores. Un grupo de nodos es una plantilla para los grupos de nodos trabajadores que se crearon en este clúster.

En la consola, configura al menos un grupo de nodos (o acepta los valores predeterminados) y, luego, crea 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 recién creado.

  1. Haz clic en grupo predeterminado en la barra de navegación izquierda.

  2. En la sección Valores predeterminados del grupo de nodos, ingresa el Nombre del grupo de nodos o acepta “default-pool” como nombre.

  3. En la sección Nodos trabajadores, ingresa 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 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.

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

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

gcloud CLI

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

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 de GKE en Bare Metal que seleccionas cuando creas un clúster de usuario debe ser una versión que admita el clúster de administrador. Además, las versiones secundarias o de parche más recientes no estarán disponibles en la API de GKE On-Prem hasta 7 a 10 días después del lanzamiento. Puedes ejecutar un comando gcloud para obtener una lista de las versiones compatibles que puedes instalar en el clúster de usuario.

  1. Asegúrate de actualizar los componentes:

    gcloud components update

  2. 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=global \
  --location=REGION

    Reemplaza lo siguiente:

    • ADMIN_CLUSTER_NAME: Es el nombre del clúster de administrador.

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

    • REGION: Es la región de Google Cloud que especificaste cuando inscribiste el clúster en la API de GKE On-Prem.

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 de MetalLB y un ejemplo con un balanceador de cargas manual. La información que especificas varía según el tipo de balanceador de cargas que uses. 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 se esté ejecutando, debes agregar un grupo de nodos antes de implementar las cargas de trabajo.

MetalLB

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=projects/FLEET_HOST_PROJECT_ID/locations/global/memberships/ADMIN_CLUSTER_NAME \
  --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: Es el nombre que elijas para el clúster de usuario. No se puede cambiar el nombre después de crear el clúster. El nombre debe cumplir con los siguientes requisitos:
    • Contener 40 caracteres como máximo.
    • Contener solo caracteres alfanuméricos en minúscula o un guiones (-).
    • Comenzar con un carácter alfabético
    • Terminar con un carácter alfanumérico
  • FLEET_HOST_PROJECT_ID: El ID del proyecto en el que deseas crear el clúster. El proyecto especificado también se usa como el proyecto host de la flota. Debe ser el mismo proyecto en el que está registrado el clúster de administrador. Después de crear el clúster de usuario, se registra automáticamente en la flota del proyecto seleccionado. El proyecto host de la flota no se puede cambiar después de que se crea el clúster.
  • ADMIN_CLUSTER_NAME: Es el nombre del clúster de administrador que gestiona el clúster de usuario. En la marca --admin-cluster-membership, puedes usar el nombre del clúster especificado por completo, que tiene el siguiente formato: 
        projects/FLEET_HOST_PROJECT_ID/locations/ADMIN_CLUSTER_REGION/memberships/ADMIN_CLUSTER_NAME

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

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

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

  • VERSION: Es la versión de GKE en Bare Metal para el clúster de usuario.
  • YOUR_EMAIL_ADDRESS y ANOTHER_EMAIL_ADDRESS: Si no incluyes la marca --admin-users, como creador del clúster, se te otorgarán privilegios de administrador de clúster de forma predeterminada. Sin embargo, si incluyes --admin-users para designar a otro usuario como administrador, anulas el valor predeterminado y debes incluir tu dirección de correo electrónico y la del otro administrador. Por ejemplo, para agregar dos administradores, 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 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 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: Es un nombre que elijas para el grupo.

  • avoid-buggy-ips: Si estableces esto como True, el controlador de MetalLB no asignará las direcciones IP que terminan en .0 o .255 a los servicios. De esta manera, se evita el problema de que los dispositivos de consumidores con errores dejan de lado por error el tráfico enviado a esas direcciones IP especiales. Si no se especifica, el valor predeterminado es False.

  • manual-assign: Si no quieres que el controlador de MetalLB asigne de forma automática las direcciones IP de este grupo a los servicios, establece esto en True. Luego, un desarrollador puede crear un Service de tipo LoadBalancer y especificar de forma manual una de las direcciones del grupo. Si no se especifica, manual-assign se establece en False.

  • En la lista de addresses: Cada dirección debe ser un rango en formato CIDR o de rango con guion. Si quieres especificar una sola dirección IP en un grupo (como para la VIP de entrada), usa /32 en la notación CIDR (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 los 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 trabajadores, 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.

    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 nodo.

    • 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 los 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 de forma opcional las siguientes marcas:

    • --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 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 agregar taints a todos los nodos del grupo de nodos del balanceador de cargas. Cada taint 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 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 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 a fin de tener la mayoría de quórum para la alta disponibilidad. Puedes cambiar estas direcciones cada vez que actualices o 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 un node-ip por marca. Si necesitas especificar más de un nodo, vuelve a incluir la marca para cada nodo.
  • 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 los espacios en blanco.
    • Separa cada par clave=valor en el segmento labels con un punto y coma.

    De manera opcional, puedes incluir 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 taints a todos los nodos del plano de control. Cada taint 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 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 \

IP virtuales

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

    Ejemplo: --control-plane-vip=203.0.113.3

  • CONTROL_PLANE_LB_PORT: 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: La dirección IP que elegiste configurar en el balanceador de cargas para el proxy de entrada.

    Ejemplo: --ingress-vip=10.251.134.80

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

CIDR de Service y Pod

  • SERVICE_CIDR_BLOCK: Es un rango de direcciones IP, en formato CIDR, que se usará para los servicios del clúster. El rango CIDR debe estar entre /24 y /12, en el que /12 proporciona la mayor cantidad de direcciones IP.

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

  • POD_CIDR_BLOCK: Es un rango de direcciones IP, en formato CIDR, que se usará para los Pods del clúster. El rango CIDR debe estar entre /18 y /8, en el que /8 proporciona la mayor cantidad de direcciones IP.

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

Almacenamiento

  1. --lvp-share-path: Esta es la ruta de la máquina anfitrión en la que se pueden crear los subdirectorios. Se crea un PersistentVolume (PV) local para cada subdirectorio.
  2. --lvp-share-storage-class: Esta es la StorageClass que se usará para crear volúmenes persistentes. StorageClass se crea durante la creación del clúster.
  3. --lvp-node-mounts-config-path: Esta es la ruta 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.
  4. --lvp-node-mounts-config-storage: 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 Cómo configurar 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 del 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 independiente 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=projects/FLEET_HOST_PROJECT_ID/locations/global/memberships/ADMIN_CLUSTER_NAME \
  --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: Es el nombre que elijas para el clúster de usuario. No se puede cambiar el nombre después de crear el clúster. El nombre debe cumplir con los siguientes requisitos:
    • Contener 40 caracteres como máximo.
    • Contener solo caracteres alfanuméricos en minúscula o un guiones (-).
    • Comenzar con un carácter alfabético
    • Terminar con un carácter alfanumérico
  • FLEET_HOST_PROJECT_ID: El ID del proyecto en el que deseas crear el clúster. El proyecto especificado también se usa como el proyecto host de la flota. Debe ser el mismo proyecto en el que está registrado el clúster de administrador. Después de crear el clúster de usuario, se registra automáticamente en la flota del proyecto seleccionado. El proyecto host de la flota no se puede cambiar después de que se crea el clúster.
  • ADMIN_CLUSTER_NAME: Es el nombre del clúster de administrador que gestiona el clúster de usuario. En la marca --admin-cluster-membership, puedes usar el nombre del clúster especificado por completo, que tiene el siguiente formato: 
        projects/FLEET_HOST_PROJECT_ID/locations/ADMIN_CLUSTER_REGION/memberships/ADMIN_CLUSTER_NAME

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

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

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

  • VERSION: Es la versión de GKE en Bare Metal para el clúster de usuario.
  • YOUR_EMAIL_ADDRESS y ANOTHER_EMAIL_ADDRESS: Si no incluyes la marca --admin-users, como creador del clúster, se te otorgarán privilegios de administrador de clúster de forma predeterminada. Sin embargo, si incluyes --admin-users para designar a otro usuario como administrador, anulas el valor predeterminado y debes incluir tu dirección de correo electrónico y la del otro administrador. Por ejemplo, para agregar dos administradores, 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 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 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 a fin de tener la mayoría de quórum para la alta disponibilidad. Puedes cambiar estas direcciones cada vez que actualices o 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 un node-ip por marca. Si necesitas especificar más de un nodo, vuelve a incluir la marca para cada nodo.
  • 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 los espacios en blanco.
    • Separa cada par clave=valor en el segmento labels con un punto y coma.

    De manera opcional, puedes incluir 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 taints a todos los nodos del plano de control. Cada taint 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 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 \

IP virtuales

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

    Ejemplo: --control-plane-vip=203.0.113.3

  • CONTROL_PLANE_LB_PORT: 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: La dirección IP que elegiste configurar en el balanceador de cargas para el proxy de entrada.

    Ejemplo: --ingress-vip=10.251.134.80

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

CIDR de Service y Pod

  • SERVICE_CIDR_BLOCK: Es un rango de direcciones IP, en formato CIDR, que se usará para los servicios del clúster. El rango CIDR debe estar entre /24 y /12, en el que /12 proporciona la mayor cantidad de direcciones IP.

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

  • POD_CIDR_BLOCK: Es un rango de direcciones IP, en formato CIDR, que se usará para los Pods del clúster. El rango CIDR debe estar entre /18 y /8, en el que /8 proporciona la mayor cantidad de direcciones IP.

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

Almacenamiento

  1. --lvp-share-path: Esta es la ruta de la máquina anfitrión en la que se pueden crear los subdirectorios. Se crea un PersistentVolume (PV) local para cada subdirectorio.
  2. --lvp-share-storage-class: Esta es la StorageClass que se usará para crear volúmenes persistentes. StorageClass se crea durante la creación del clúster.
  3. --lvp-node-mounts-config-path: Esta es la ruta 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.
  4. --lvp-node-mounts-config-storage: 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 Cómo configurar el almacenamiento local.

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

La creación del clúster de usuario tarda 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 CLI de gcloud.

Crear un grupo de nodos

Después de crear el clúster, debes crear al menos un grupo de nodos antes de implementar las cargas de trabajo. Un grupo de nodos es una plantilla para los grupos de nodos trabajadores creados 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 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;...'

Reemplaza lo siguiente:

  • NODE_POOL_NAME: Es un nombre que elijas para el grupo de nodos. El nombre debe cumplir con los siguientes requisitos:

    • Contener 40 caracteres como máximo.
    • Contener solo caracteres alfanuméricos en minúscula o un guiones (-).
    • Comenzar con un carácter alfabético
    • Terminar con un carácter alfanumérico

  • USER_CLUSTER_NAME: Es el nombre del clúster de usuario recién creado.

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

  • REGION: Es la región de Google Cloud que especificaste cuando creaste el clúster.

  • --node-configs: Es la dirección IPv4 de una máquina de nodo trabajador. 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: La dirección IP de un nodo trabajador. Solo puedes especificar un node-ip por marca. Agrega esta marca otra vez para cada nodo en el 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 los 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,...: Es una lista separada por comas de etiquetas de Kubernetes (pares clave=valor) que se aplican a cada nodo del grupo.

    • --node-taints=KEY=VALUE:EFFECT,...Una lista separada por comas de taints de Kubernetes aplicados a cada nodo en el 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 o NoExecute.

En el siguiente ejemplo, se crea un grupo de nodos llamado default-pool en user-cluster- y se agregan dos nodos al grupo. Todos los nodos están etiquetados con node-pool-key=node-pool-value y tienen 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 comenzar

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

  1. Asegúrate de actualizar los componentes:

    gcloud components update

  2. 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=global \
  --location=REGION

    Reemplaza lo siguiente:

    • ADMIN_CLUSTER_NAME: Es el nombre del clúster de administrador.

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

    • REGION: Es la región de Google Cloud que especificaste cuando inscribiste el clúster en la API de GKE On-Prem.

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

Ejemplo

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

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

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

    En la muestra, se proporciona un archivo de variables de ejemplo para pasar a main.tf.

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

    cp terraform.tfvars.sample terraform.tfvars

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

  3. Modifica los valores de los parámetros en terraform.tfvars y guarda el archivo.

    En la siguiente lista, se describen las variables:

    • project_id: El ID del proyecto en el que deseas crear el clúster. El proyecto especificado también se usa como el proyecto host de la flota. Este debe ser el mismo proyecto en el que está registrado el clúster de administrador. Después de crear el clúster de usuario, se registra de forma automática en la flota del proyecto seleccionado. No se puede cambiar el proyecto host de la flota después de que se cree el clúster.

    • region: Es la región de Google Cloud en la que se ejecuta la API de GKE On-Prem. Especifica us-west1 o alguna otra región compatible.

    • admin_cluster_name: Es el nombre del clúster de administrador que gestiona el clúster de usuario.

    • bare_metal_version: Es la versión de GKE en Bare Metal para el clúster de usuario. Especifica la misma versión que el clúster de administrador o una versión que no tenga más de una versión secundaria anterior que el clúster de administrador.

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

      • Contener 40 caracteres como máximo.
      • Contener solo caracteres alfanuméricos en minúscula o un guiones (-).
      • Comenzar con un carácter alfabético
      • Terminar con un carácter alfanumérico

    • control_plane_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 a fin de 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 nodos trabajadores.

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

    • ingress_vip: La dirección IP que elegiste configurar en el balanceador de cargas para el proxy de entrada

    • lb_address_pools: Una lista de mapas que definen los grupos de direcciones que usará el balanceador de cargas de MetalLB. La VIP de entrada debe estar en uno de estos grupos.

    • admin_user_emails: Una lista de direcciones de correo electrónico de los usuarios a los que se les otorgarán privilegios de administrador en el clúster. Asegúrate de agregar tu dirección de correo electrónico si quieres administrar el clúster.

    Cuando se crea el clúster, la API de GKE On-Prem aplica las políticas de control de acceso basado en funciones (RBAC) de Kubernetes al clúster para otorgar a los usuarios administradores la función clusterrole/cluster-admin de Kubernetes, que proporciona acceso completo a todos los recursos del clúster en todos los espacios de nombres. Esto también permite a los usuarios acceder a la consola mediante su identidad de Google.

  4. Guarda los cambios en terraform.tfvars.

  5. Inicializa y crea terraform plan:

    terraform init

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

  6. Revisa la configuración y realiza cambios si es necesario:

    terraform plan

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

    terraform apply

    La creación del clúster de usuario tarda 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 usuario con gcloud CLI, se te otorgan 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 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 Configura 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 del clúster a través de la VPC, puedes conectarte directamente al extremo privado y generar un archivo kubeconfig de forma directa. De lo contrario, puedes usar Conectar puerta de enlace.

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 obtener acceso directo 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

  1. initialize la CLI de gcloud para usarla con el proyecto host de la flota o ejecuta los siguientes comandos a fin de 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

  2. 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 GKE 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 con kubectl como lo harías normalmente para 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 del clúster de usuario recién creado.

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. El TIMESTAMP en el nombre del archivo indica 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.

¿Qué sigue?