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

Version 1.13 

• Más reciente
• Versión 1.16
• Versiones anteriores (no compatibles)

Vista previa

Esta función está sujeta a las "Condiciones de las Ofertas de Fase Previa a la DG" de la sección Condiciones Generales del Servicio de las Condiciones Específicas del Servicio. Las funciones de fase previa a la DG están disponibles “tal cual” y podrían tener asistencia limitada. Para obtener más información, consulta las descripciones de la etapa de lanzamiento.

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

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

La API de Anthos On-Prem es una API alojada en Google Cloud que te permite administrar el ciclo de vida de los clústeres locales mediante Terraform y las aplicaciones estándar de Google Cloud. La API de Anthos On-Prem se ejecuta en la infraestructura de Google Cloud. Terraform, la consola y 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 Anthos On-Prem debe almacenar los metadatos sobre el estado del clúster en Google Cloud mediante la región de Google Cloud que especifiques cuando crees el clúster. Estos metadatos permiten que la API administre el ciclo de vida del clúster y no incluye datos específicos de la carga de trabajo.

Cuando creas un clúster con un cliente de la API de Anthos On-Prem, especificas un proyecto de Google Cloud. Después de crear el clúster, se registra automáticamente en la flota del proyecto especificado. Este proyecto se conoce como proyecto host de flota. El proyecto host de la flota no se puede cambiar 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 deseas usar Terraform, la consola o gcloud CLI para administrar el ciclo de vida de los clústeres que se crearon con bmctl, consulta Configura un clúster de usuario para que lo administre la API de Anthos On-Prem.

Antes de comenzar

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

Otorga permisos de IAM

Si no eres propietario del proyecto, debes tener la función roles/gkeonprem.admin.

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

• roles/container.viewer
• roles/gkehub.viewer.

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

• roles/gkehub.gatewayAdmin: Esta función te permite acceder a la API de Connect Gateway. Si solo necesitas acceso de solo lectura al clúster, el roles/gkehub.gatewayReader es suficiente.

• roles/gkehub.viewer: esta función te permite recuperar credenciales de 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 vas a usar gcloud CLI para crear el clúster, debes habilitar la API de Anthos On-Prem. Si usas la consola para crear el clúster, se habilita la API de Anthos On-Prem de forma automática.

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 hacer lo siguiente:

• 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 usuario después de crearlo

• 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 proyecto host de flota, debe ser el mismo proyecto en el que crearás el clúster de usuario.

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

Revisa los requisitos previos de la máquina de nodo de 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 Connect 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.

Nota: Si usas Cloud Shell como entorno de shell para interactuar con Google Cloud, estas herramientas están instaladas.

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

Crea un clúster de usuario

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

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

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.

Consola

La mayor parte de la configuración de la consola corresponde a los campos del archivo de configuración del clúster.

1. En la consola de Google Cloud, ve a la página Clústeres de Anthos.

   Ir a la página Clústeres de Anthos

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 Crear clúster.

4. En el cuadro de diálogo, haz clic en Local.

5. Junto a Bare metal, haz clic en Configure.

6. Revisa los requisitos previos y la arquitectura de muestra. Cuando estés listo, 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 Anthos On-Prem y la región en la que se almacena lo siguiente:

   • Los metadatos del clúster de usuario que la API de Anthos 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 identifican de forma única el clúster en Google Cloud.

4. Selecciona los clústeres de Anthos en la versión Bare Metal para el 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 ella.

5. Como creador del clúster, se te otorgan privilegios de administrador de clúster. De manera opcional, ingresa la dirección de correo electrónico de otro usuario que administrará el clúster en el campo Usuario de administración.

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

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

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

   • Cantidad máxima de Pods por nodo: Ingresa la cantidad máxima de Pods que se pueden ejecutar en un solo nodo. Los valores permitidos están entre 32 y 250, 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 a la cantidad máxima de Pods por nodo. Para obtener más información sobre la configuración del número máximo de Pods por nodo, consulta Herramientas de redes de Pods.

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

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

Herramientas de redes

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

1. En la sección Nodo 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, esta es 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 de MetalLB empaquetado Con esta opción, los clústeres de Anthos alojados en Bare Metal implementan 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:

      • Usar 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 configuras en la sección Grupos de direcciones del balanceador de cargas.

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

        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 los servicios de tipo LoadBalancer y asígnalos a ellos. La VIP de Ingress, 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 rangos (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 Ingress no está en el rango de direcciones, selecciona + Agregar rango de direcciones IP y, luego, ingresa otro rango que incluya la VIP de entrada.

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

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

         • Automático: Elige esta opción si quieres que el controlador de MetalLB asigne automáticamente direcciones IP del grupo de direcciones a los servicios de tipo LoadBalancer.
         • Manual: Elige esta opción si 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 separado del 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: Es la dirección IP de destino que se usará para el tráfico que se envía 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 en 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 Service and Pod CIDRs, especifica los rangos de direcciones IP del servicio y de los Pods 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 dentro del clúster. Te recomendamos que uses los rangos de direcciones IP privadas definidos por RFC 1918. La consola proporciona los siguientes rangos de direcciones predeterminados, pero puedes cambiarlos:

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

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

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

   • URL de proxy: Es la dirección HTTP de tu servidor proxy. Incluye el número de puerto incluso si es el mismo que el puerto predeterminado del esquema, por ejemplo: http://my-proxy.example.local:80.

   • URL: una lista separada por comas de direcciones IP, rangos de direcciones IP, nombres de host y nombres de dominio que no deben pasar por el servidor proxy. Cuando los clústeres de Anthos alojados en Bare Metal envían una solicitud a una de estas direcciones, hosts o dominios, la solicitud se envía directamente.

6. Haz clic en Siguiente.

Almacenamiento

Los clústeres de Anthos alojados en Bare Metal proporcionan interfaces de almacenamiento en bloque y de archivos. Tienen opciones predeterminadas, pero puedes personalizar la configuración. 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 PersistentVolumes (PV) locales respaldados por discos activados. Debes formatear y activar estos discos antes o después de la creación del clúster.

   • Uso compartido del aprovisionador local de volumen: Especifica la configuración del PersistentVolumes local respaldado por los 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, los siguientes elementos se habilitan de forma automática y no se pueden inhabilitar:

• Cloud Logging de servicios del sistema
• Cloud Monitoring de servicios del sistema
• El registro de auditoría de actividad del administrador

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 crean 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 debes crear el clúster y, luego, agregar uno o más grupos de nodos al clúster creado recientemente.

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

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

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 deseas agregar etiquetas y taints de Kubernetes, sigue estos pasos:

   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 a medida que verifica la configuración y crea el clúster en tu centro de datos.

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

CLI de gcloud

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

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

Antes de comenzar

1. Accede con tu Cuenta de Google.

   gcloud auth login
   

2. Asegúrate de actualizar los componentes:

   gcloud components update
   

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 especifiques varía según el tipo de balanceador de cargas que usarás. Consulta la Descripción general de los balanceadores de cargas para obtener más información.

Los ejemplos crean el clúster sin grupos de nodos. Una vez que el clúster esté en ejecución, 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 de la marca --admin-cluster-membership.

gcloud beta 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 que se crea el clúster. El nombre debe cumplir con los siguientes requisitos:
  • Contener 40 caracteres como máximo.
  • Contener solo caracteres alfanuméricos en minúscula o un guiones (-).
  • Comenzar con un carácter alfabético
  • Terminar con un carácter alfanumérico
• FLEET_HOST_PROJECT_ID: Es el ID del proyecto en el que 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 administra el clúster de usuario. El nombre del clúster de administrador es el último segmento del nombre completo que identifica al clúster de forma única en Google Cloud: projects/FLEET_HOST_PROJECT_ID/locations/global/memberships/ADMIN_CLUSTER_NAME
• REGION: Es la región de Google Cloud en la que se ejecuta la API de Anthos On-Prem. Especifica us-west1 o una región compatible. No se puede cambiar la región después de que se crea el clúster. Esta 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 Anthos 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

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

• VERSION: Son los clústeres de Anthos alojados en Bare Metal para tu clúster de usuario.
• YOUR_EMAIL_ADDRESS y ANOTHER_EMAIL_ADDRESS: Si no incluyes la marca --admin-users, como creador del clúster, se te otorgan privilegios de administrador del 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:

      --admin-users=[e-mail] \
      --admin-users=[e-mail]

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

  Nota: Además de las políticas de RBAC de Kubernetes, debes otorgar algunas funciones deIdentity and Access Managements (IAM) a los usuarios que no son propietarios del proyecto. Para obtener más información sobre cómo otorgar los roles de IAM, consulta Otorga los roles obligatorios.

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. Separe cada segmento con una coma.

• pool: Es el nombre que elijas para el grupo.

• avoid-buggy-ips: Si estableces esto en True, el controlador de MetalLB no asignará a los servicios direcciones IP que terminen en .0 o .255. Esto evita el problema de que los dispositivos de consumidores con errores caigan 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 automáticamente direcciones IP de este grupo a los servicios, establece esto en True. Luego, un desarrollador puede crear un Service de tipo LoadBalancer y especificar manualmente una de las direcciones del grupo. Si no se especifica, se configura manual-assign como False.

• En la lista de addresses, cada dirección debe ser un rango en CIDR o formato de rango con guiones. Para especificar una sola dirección IP en un grupo (como para la VIP de entrada), usa /32 en la notación CIDR (p. ej., 192.0.2.1/32).

Ten en cuenta las siguientes reglas de sintaxis:

• Rodea el valor completo con 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.

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

  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. Separe cada segmento con una coma.

  • node-ip: La dirección IP de un nodo en tu grupo de nodos del balanceador de cargas. Solo puedes especificar un node-ip por marca. Si necesitas especificar más de un nodo, vuelve a incluir la marca para cada uno de ellos.

  • labels: Uno o más pares clave=valor adjuntos al nodo.

  Ten en cuenta las siguientes reglas de sintaxis:

  • Rodea el valor completo con 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, tienes la opción de incluir 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 se etiquetan 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: 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 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. Separe 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, vuelve a incluir la marca para cada uno de ellos.
• labels: Uno o más pares clave=valor adjuntos al nodo.

  Ten en cuenta las siguientes reglas de sintaxis:

  • Rodea el valor completo con 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 se etiquetan 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: Es la dirección IP que elegiste configurar en el balanceador de cargas para el servidor de la API de Kubernetes del clúster de usuario.

  Ejemplo: --control-plane-vip=203.0.113.3

• CONTROL_PLANE_LB_PORT: Es el puerto en el que el balanceador de cargas entrega al 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 de la VIP de Ingress debe estar en uno de los grupos de direcciones de MetalLB.

CIDR de Service y Pod

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

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

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

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

Almacenamiento

1. --lvp-share-path: Esta es la ruta de acceso de la máquina anfitrión en la que se pueden crear subdirectorios. Se crea un PersistentVolume local (PV) 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 local (PV) para cada activación.
4. --lvp-node-mounts-config-storage: Es la clase de almacenamiento con la que se crean los PV durante la creación del clúster.

Para obtener más información sobre el almacenamiento, consulta 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 separado del 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 de la marca --admin-cluster-membership.

gcloud beta 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 que se crea el clúster. El nombre debe cumplir con los siguientes requisitos:
  • Contener 40 caracteres como máximo.
  • Contener solo caracteres alfanuméricos en minúscula o un guiones (-).
  • Comenzar con un carácter alfabético
  • Terminar con un carácter alfanumérico
• FLEET_HOST_PROJECT_ID: Es el ID del proyecto en el que 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 administra el clúster de usuario. El nombre del clúster de administrador es el último segmento del nombre completo que identifica al clúster de forma única en Google Cloud: projects/FLEET_HOST_PROJECT_ID/locations/global/memberships/ADMIN_CLUSTER_NAME
• REGION: Es la región de Google Cloud en la que se ejecuta la API de Anthos On-Prem. Especifica us-west1 o una región compatible. No se puede cambiar la región después de que se crea el clúster. Esta 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 Anthos 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

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

• VERSION: Son los clústeres de Anthos alojados en Bare Metal para tu clúster de usuario.
• YOUR_EMAIL_ADDRESS y ANOTHER_EMAIL_ADDRESS: Si no incluyes la marca --admin-users, como creador del clúster, se te otorgan privilegios de administrador del 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:

      --admin-users=[e-mail] \
      --admin-users=[e-mail]

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

  Nota: Además de las políticas de RBAC de Kubernetes, debes otorgar algunas funciones deIdentity and Access Managements (IAM) a los usuarios que no son propietarios del proyecto. Para obtener más información sobre cómo otorgar los roles de IAM, consulta Otorga los roles obligatorios.

Nodos de plano de control

• --control-plane-node-configs: 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 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. Separe 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, vuelve a incluir la marca para cada uno de ellos.
• labels: Uno o más pares clave=valor adjuntos al nodo.

  Ten en cuenta las siguientes reglas de sintaxis:

  • Rodea el valor completo con 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 se etiquetan 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: Es la dirección IP que elegiste configurar en el balanceador de cargas para el servidor de la API de Kubernetes del clúster de usuario.

  Ejemplo: --control-plane-vip=203.0.113.3

• CONTROL_PLANE_LB_PORT: Es el puerto en el que el balanceador de cargas entrega al 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 de la VIP de Ingress debe estar en uno de los grupos de direcciones de MetalLB.

CIDR de Service y Pod

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

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

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

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

Almacenamiento

1. --lvp-share-path: Esta es la ruta de acceso de la máquina anfitrión en la que se pueden crear subdirectorios. Se crea un PersistentVolume local (PV) 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 local (PV) para cada activación.
4. --lvp-node-mounts-config-storage: Es la clase de almacenamiento con la que se crean los PV durante la creación del clúster.

Para obtener más información sobre el almacenamiento, consulta 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 para el 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 Anthos.

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 debes crear el clúster y, luego, agregar uno o más grupos de nodos al clúster creado recientemente.

gcloud beta 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 el 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: Es 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: 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. Separe 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 nuevamente 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:

  • Rodea el valor completo con 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,...: Una lista separada por comas de las etiquetas de Kubernetes (pares clave-valor) aplicadas a cada nodo en el grupo.

  • --node-taints=KEY=VALUE:EFFECT,... Es una lista separada por comas de los 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, 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 beta 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

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

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

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

   cp terraform.tfvars.sample terraform.tfvars
   

   Anthos-onprem-terraform/abm_user_cluster_metallb/terraform.tfvars.sample

   Ver en GitHub

   
   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: Es el ID del proyecto en el que deseas crear el clúster. El proyecto especificado también se usa como 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 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: Es la región de Google Cloud en la que se ejecuta la API de Anthos On-Prem. Especifica us-west1 o una región compatible.

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

   • bare_metal_version: Son los clústeres de Anthos alojados 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 menor que la del clúster de administrador.

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

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

   • control_plane_ips: 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 o actualices un clúster.

   • worker_node_ips: Una lista de una o más direcciones IPv4 para las máquinas de nodo trabajador.

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

   • lb_address_pools: Es una lista de mapas que definen los grupos de direcciones que usará el balanceador de cargas de MetalLB. La VIP de Ingress 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 administrativos 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 Anthos 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 cada recurso en el clúster en todos los espacios de nombres. Esto también permite a los usuarios acceder a la consola con 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 los cambios necesarios:

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

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, de forma predeterminada, se te otorgan estas políticas de RBAC si no incluyes la marca --admin-users. Si incluyes --admin-users para designar a otro usuario como administrador, anulas 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 necesarias, 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 tu 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 el tráfico de forma segura al extremo privado en tu nombre.

• Para obtener acceso directo a extremos privados, crea un archivo kubeconfig en tu estación de trabajo de administrador y administra el clúster desde allí.

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. Inicializa 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 los clústeres de Anthos alojados 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 con cualquier clúster de Kubernetes, y no necesitas especificar el nombre del archivo kubeconfig, por ejemplo:

kubectl get namespaces

Estación de trabajo de administrador

Usa el comando bmctl get credentials a fin de recuperar un archivo kubeconfig para el 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?

• Protege tus contenedores con SELinux
• Administra clústeres desde la consola de Google Cloud