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

Version 1.15 

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

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 con un archivo de configuración y un gkectl, como se describe en Crea un clúster de usuario con gkectl.

Si quieres usar Terraform, la consola o gcloud CLI para administrar el ciclo de vida de los clústeres que se crearon con gkectl, 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 GKE Enterprise y Google Kubernetes Engine en la consola, también debes tener los siguientes roles:

• 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 la puerta de enlace de Connect. 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 los roles, consulta Administra el acceso a los proyectos, las carpetas y las organizaciones.

Registra el clúster de administrador

Debes tener un clúster de administrador y estar registrado en una flota antes de que puedas crear clústeres de usuario con clientes de la API de GKE On-Prem.

• Si aún no creaste un clúster de administrador, completa la sección gkeConnect en el archivo de configuración de tu clúster de administrador.

• Si tienes un clúster de administrador, pero no lo registraste, consulta Registra un clúster de administrador.

Habilita los registros de auditoría de actividad del administrador para el clúster de administrador

El registro de actividad del administrador en los registros de auditoría de Cloud debe estar habilitado en el clúster de administrador.

• Si aún no creaste un clúster de administrador, completa la sección cloudAuditLogging en el archivo de configuración de tu clúster de administrador.

• Para actualizar un clúster de administrador existente, consulta Habilita o inhabilita el registro en los registros de auditoría de Cloud del clúster de administrador.

Habilita el registro y la supervisión a nivel del sistema para el clúster de administrador

Cloud Logging y Cloud Monitoring deben estar habilitados en el clúster de administrador.

• Si aún no creaste un clúster de administrador, completa la sección stackdriver en el archivo de configuración de tu clúster de administrador.

• Para actualizar un clúster de administrador existente, consulta Habilita o inhabilita el registro y la supervisión para el clúster de administrador.

APIs de Google obligatorias

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

Además, debes habilitar la API de GKE On-Prem:

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

Acceso a la línea de comandos

Después de crear el clúster, si deseas usar la puerta de enlace de Connect para conectarte al clúster de usuario mediante la línea de comandos, haz lo siguiente:

Asegúrate de tener instaladas las siguientes herramientas de línea de comandos:

• 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

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

Versiones disponibles para instalaciones nuevas

Cuando creas un clúster de usuario, por lo general, debes instalar la versión de GKE en VMware que coincide con el clúster de administrador. Pero puedes instalar una versión posterior del parche o una versión secundaria posterior. Por ejemplo, es posible que desees instalar la versión de parche más reciente cuando crees un clúster de usuario para recoger las correcciones de errores. Una vez que se realiza un lanzamiento de GKE en VMware, se necesitan entre 7 y 10 días para que la versión esté disponible en la API de GKE On-Prem.

Si deseas crear un clúster de usuario que sea una versión posterior a la del clúster de administrador, primero descarga un paquete específico de la versión de los componentes que el clúster de administrador necesita para administrar los clústeres de usuario en esa versión y, luego, implementa los componentes. Para obtener más información, consulta Instala una versión posterior a la versión del clúster de administrador.

Elegir una herramienta para crear el clúster

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 VMware, es posible que la consola te resulte 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.

Crea un clúster de usuario

Console

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

1. En la consola de Google Cloud, ve a la página Crea un clúster de GKE on VMware.

   Ir a Crea un clúster de GKE en VMware

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.

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. Si no especificaste un nombre para el clúster de administrador cuando lo creaste, el nombre se genera con el formato gke-admin-[HASH]. Si no reconoces el nombre del clúster de administrador, ejecuta el siguiente comando en tu estación de trabajo de administrador:

   KUBECONFIG=ADMIN_CLUSTER_KUBECONFIG
   kubectl get OnPremAdminCluster -n kube-system -o=jsonpath='{.items[0].metadata.name}'
   

   Si no se muestra el clúster de administrador que deseas usar, consulta la sección de solución de problemas El clúster de administrador no se muestra en la lista desplegable aspectos básicos del clúster.

3. En el campo Ubicación de la API de GCP, 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 a Google Cloud.

4. Selecciona la versión de GKE en VMware para tu clúster de usuario.

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 del clúster en la sección Autorización.

   Cuando se crea el clúster, la API de GKE On-Prem aplica las políticas de control de acceso basado en funciones (RBAC) de Kubernetes al clúster para otorgarte a ti y 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.

   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. Haz clic en Siguiente para ir a la sección Plano de control.

Plano de control

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

1. En el campo CPU virtuales del nodo del plano de control, ingresa la cantidad de CPU virtuales (4 como mínimo) para cada nodo del plano de control del clúster de usuario.
2. En el campo Memoria de nodo del plano de control, ingresa el tamaño de la memoria en MiB (8,192 como mínimo y debe ser un múltiplo de 4) de cada plano de control del clúster de usuario.
3. En Nodos del plano de control, selecciona la cantidad de nodos del plano de control para el clúster de usuario. Por ejemplo, puedes seleccionar 1 nodo de plano de control para un entorno de desarrollo y 3 nodos de plano de control para entornos de producción y alta disponibilidad (HA).
4. De forma opcional, selecciona Cambio de tamaño automático de nodos. Cambiar el tamaño significa que la CPU virtual y los recursos de memoria asignados a un nodo se ajustan automáticamente. Cuando se habilita, se cambia el tamaño de los nodos del plano de control para el clúster de usuario según la cantidad de nodos trabajadores en el clúster de usuario. Por lo tanto, a medida que agregas más nodos trabajadores al clúster de usuario, aumenta el tamaño de los nodos del plano de control.

5. De forma opcional, selecciona Habilitar plano de control v2. Habilitar el plano de control V2 significa que el plano de control de un clúster de usuario se ejecuta en uno o más nodos en el clúster de usuario, en lugar de hacerlo en el clúster de administrador (denominado modelo de kubeception).

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

   Cuando el plano de control V2 está habilitado, los campos de CPU virtual y memoria se aplican a los nodos del plano de control en el clúster de usuario. La cantidad de nodos se determina por la cantidad de direcciones IP que ingreses. Cuando el plano de control V2 no está habilitado, los campos de CPU virtual, memoria y cantidad de nodos del plano de control se aplican a los nodos del clúster de administrador. Asegúrate de reservar suficientes direcciones IP para el clúster de administrador.

6. 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. Un clúster de usuario debe tener una dirección IP para cada nodo y una dirección IP adicional para un nodo temporal que se necesita durante las actualizaciones del clúster, las actualizaciones y las reparaciones automáticas. Para obtener más información, consulta ¿Cuántas direcciones IP necesita un clúster de usuario?

1. En la sección IP de nodo, selecciona el modo de IP para el clúster de usuario. Selecciona una de las siguientes opciones:

   • DHCP: Elige DHCP si deseas que los nodos del clúster obtengan la dirección IP de un servidor DHCP.

   • Estática: Elige Estática si deseas proporcionar direcciones IP estáticas para los nodos del clúster o si deseas configurar el balanceo de cargas manual.

2. Si seleccionaste DHCP, continúa con el siguiente paso para especificar los CIDR de Service y Pod. En Static IP mode, proporciona la siguiente información:

   1. Ingresa la dirección IP de la Puerta de enlace para el clúster de usuario.

   2. Ingresa la Máscara de subred para los nodos del clúster de usuario.

   3. En la sección Direcciones IP, ingresa las direcciones IP y, de forma opcional, los nombres de host para los nodos del clúster de usuario. Puedes ingresar una dirección IP v4 individual (como 192.0.2.1) o un bloque CIDR de direcciones IPv4 (como 192.0.2.0/24).

      • Si ingresas un bloque CIDR, no ingreses un nombre de host.
      • Si ingresas una dirección IP individual, puedes ingresar un nombre de host de forma opcional. Si no ingresas un nombre de host, GKE en VMware usa el nombre de la VM de vSphere como nombre de host.

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

3. En la sección CIDR de servicios y Pods, la consola proporciona los siguientes rangos de direcciones para tu servicio y pod de Kubernetes:

   • CIDR de Service: 10.96.0.0./20
   • CIDR de Pod: 192.168.0.0/16

   Si prefieres ingresar tus propios rangos de direcciones, consulta Direcciones IP para pods y Service a fin de obtener prácticas recomendadas.

4. Si seleccionaste Modo de IP estática o Habilitar el plano de control v2, especifica la siguiente información en la sección Configuración del host:

   1. Ingresa las direcciones IP de los servidores DNS.
   2. Ingresa las direcciones IP de los servidores NTP.
   3. También puedes ingresar los dominios de búsqueda de DNS.

5. Haz clic en Siguiente para ir a la sección Balanceador de cargas.

Balanceador de cargas

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

Selecciona el Tipo de balanceador de cargas de la lista.

Incluido con MetalLB

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

1. En la sección Grupos de direcciones, configura al menos un grupo de direcciones de la siguiente manera:

   1. Ingresa un Nombre para el grupo de direcciones.

   2. Ingresa un rango de direcciones IP que contenga la VIP de Ingress en cualquier notación CIDR (p. ej., 192.0.2.0/26) o la notación de rangos (p. ej., 192.0.2.64-192.0.2.72). Para especificar una sola dirección IP en un grupo, usa /32 en la notación CIDR (p. ej., 192.0.2.1/32).

   3. Si las direcciones IP de los Services de tipo LoadBalancer no están en el mismo rango de direcciones IP que la VIP de Ingress, haz clic en + Agregar un rango de direcciones IP y, luego, ingresa otra dirección.

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

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

      • Automática: Elige esta opción si quieres que el controlador de MetalLB asigne de forma automática direcciones IP del grupo de direcciones a Services de tipo LoadBalancer.
      • Manual: Elige esta opción si tienes la intención de usar direcciones del grupo a fin de especificar manualmente direcciones para servicios de tipo LoadBalancer.

   5. Haz clic en Evita las direcciones IP con errores si deseas que el controlador de MetalLB no use direcciones del grupo que terminan en .0 o .255. Esto evita el problema de los dispositivos consumidores con errores que descartan por error el tráfico enviado a esas direcciones IP especiales.

   6. Cuando hayas terminado, haz clic en Listo.

2. Si es necesario, haz clic en Agregar grupo de direcciones.

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. El servidor de la API de Kubernetes para el clúster de usuario se ejecuta en un nodo en el clúster de administrador. Esta dirección IP debe estar en el mismo dominio L2 que los nodos del clúster de administrador. No agregues esta dirección en la sección Grupos de direcciones.

   • VIP de Ingress: La dirección IP que se configurará en el balanceador de cargas para el proxy de Ingress. Debes agregar esto a un grupo de direcciones en la sección Grupos de direcciones.

4. Haz clic en Continuar.

Balanceador de cargas de BIG-IP de F5

Puedes usar F5 para el clúster de usuario solo si el clúster de administrador usa F5. Asegúrate de instalar y configurar el ADC de BIG-IP de F5 antes de integrarlo con GKE en VMware.

1. En la sección IP virtuales, ingresa lo siguiente:

   • VIP del plano de control: La dirección IP del destino que se usará para el tráfico enviado al servidor de la API de Kubernetes.

   • VIP de Ingress: La dirección IP que se configurará en el balanceador de cargas para el proxy de Ingress.

2. En el campo Dirección, ingresa la dirección de tu balanceador de cargas BIG-IP de F5.

3. En el campo Partición, ingresa el nombre de una partición de BIG-IP que creaste para el clúster de usuario.

4. En el campo nombre del grupo de SNAT, ingresa el nombre de tu grupo de SNAT, si corresponde.

5. Haz clic en Continuar.

Balanceador de cargas manual

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

1. En la sección IP virtuales, ingresa lo siguiente:

   • VIP del plano de control: La dirección IP del destino que se usará para el tráfico enviado al servidor de la API de Kubernetes.

   • VIP de Ingress: La dirección IP que se configurará en el balanceador de cargas para el proxy de Ingress.

2. En el campo Control-plan node port, ingresa un valor nodePort para el servidor de la API de Kubernetes. El servidor de la API de Kubernetes de un clúster de usuario se ejecuta en el clúster de administrador.

3. En el campo Puerto del nodo HTTP de Ingress, ingresa un valor nodePort para el tráfico HTTP al proxy de Ingress.

4. En el campo Puerto del nodo HTTPS de Ingress, ingresa un valor nodePort para el tráfico HTTPS al proxy de Ingress.

5. En el campo Puerto del nodo del servidor de Konnectivity, ingresa un valor nodePort para el servidor de Konnectivity.

6. Haz clic en Continuar.

Funciones

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

Los siguientes elementos se habilitan de forma automática y no se pueden inhabilitar:

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

1. Las siguientes opciones están habilitadas de forma predeterminada, pero puedes inhabilitarlas:

   • Habilita el controlador CSI de vSphere: También se denomina complemento de almacenamiento de vSphere. El controlador de Container Storage Interface (CSI) se ejecuta en un clúster nativo de Kubernetes implementado en vSphere para aprovisionar volúmenes persistentes en el almacenamiento de vSphere. Para obtener más información, consulta Usa el controlador de interfaz de almacenamiento de contenedores de vSphere.
   • Habilita las reglas de antiafinidad: Las reglas antiafinidad de Distributed Resource Scheduler (DRS) de VMware se crean automáticamente para los nodos del clúster de usuario, lo que hace que se distribuyan en al menos 3 hosts físicos del centro de datos. Asegúrate de que el entorno de vSphere cumpla con los requisitos.
   Nota: Si seguiste las instrucciones en Configura la infraestructura mínima, solo tienes un host ESXi, así que asegúrate de borrar la opción Habilitar grupos de antiafinidad.

2. Haz clic en Siguiente para configurar un grupo de nodos.

Grupos de nodos

Tu clúster se creará con al menos un grupo de nodos. Un grupo de nodos es una plantilla para los conjuntos de nodos creados en este clúster. Para obtener más información, consulta Crea y administra grupos de nodos.

1. En la sección Node pool defaults, completa lo siguiente:

   1. Ingresa el nombre del grupo de nodos o acepta “default-pool” como el nombre.
   2. Ingresa la cantidad de vCPUs para cada nodo del grupo (mínimo 4 por trabajador del clúster de usuario).
   3. Ingresa el tamaño de memoria en mebibytes (MiB) para cada nodo en el grupo (mínimo 8,192 MiB por nodo trabajador del clúster de usuario y debe ser un múltiplo de 4).
   4. En el campo Nodos, ingresa la cantidad de nodos en el grupo (mínimo 3). Si ingresaste direcciones IP estáticas para las IP de nodos en la sección Herramientas de redes, asegúrate de haber ingresado suficientes direcciones IP para alojar estos nodos del clúster de usuario.
   5. Selecciona el Tipo de imagen de SO: Ubuntu, Ubuntu Containerd o COS.
   6. Ingresa el Tamaño del disco de arranque en gibibytes (GiB) (mínimo 40 GiB).
   7. Si usas MetalLB como balanceador de cargas, este debe estar habilitado en al menos un grupo de nodos. Deja seleccionada la opción Usar este grupo de nodos para el balanceo de cargas de MetalLB o agrega otro grupo de nodos para usarlo con MetalLB.

2. En la sección Metadatos del grupo de nodos (opcional), si deseas agregar etiquetas y taints de Kubernetes, haz lo siguiente:

   1. Haz clic en + Add Kubernetes Labels. Ingresa la Clave y el Valor de la etiqueta. Repite la acción según sea necesario.
   2. Haz clic en + Agregar taint. Ingresa la Clave, el Valor y el Efecto para el taint. Repite la acción según sea necesario.

3. 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 se produce un error cuando se verifica la configuración, la consola mostrará un mensaje de error que debe ser lo suficientemente claro como para solucionar el problema de configuración y volver a crear el clúster.

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

gcloud CLI

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

gcloud container vmware clusters create

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

gcloud container vmware node-pools create

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

Antes de comenzar

1. Accede con tu Cuenta de Google.

   gcloud auth login
   

2. Asegúrate de actualizar los componentes:

   gcloud components update
   

3. Obtén una lista de las versiones disponibles:

   gcloud container vmware clusters query-version-config \
     --admin-cluster-membership=ADMIN_CLUSTER_NAME \
     --admin-cluster-membership-project=FLEET_HOST_PROJECT_ID \
     --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.

   El resultado del comando es similar al siguiente:

   versions:
   - isInstalled: true
     version: 1.14.3-gke.25
   - version: 1.14.4-gke.54
   - version: 1.15.0-gke.581
   

Las versiones que puedes usar para crear un clúster de usuario tienen anotaciones con isInstalled=true, lo que significa que el clúster de administrador tiene los componentes específicos de la versión que necesita para administrar los clústeres de usuario de esa versión. Si deseas crear un clúster de usuario con otra versión disponible, consulta Instala una versión posterior a la versión del clúster de administrador.

Ejemplos

En los siguientes ejemplos, se muestra cómo crear un clúster de usuario con diferentes balanceadores de cargas. Para obtener información sobre las opciones de balanceo de cargas disponibles, consulta Descripción general del balanceador de cargas.

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

Después de que el clúster se ejecuta, debes agregar un grupo de nodos antes de implementar las cargas de trabajo, como se describe en la sección Crea un grupo de nodos.

MetalLB y DHCP

En este ejemplo, se muestra cómo crear un clúster de usuario con el balanceador de cargas en paquetes de MetalLB y cómo usar tu servidor DHCP para obtener direcciones IP para los nodos del clúster.

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

Asegúrate de desplazarte si es necesario para completar el marcador de posición ADMIN_CLUSTER_NAME para la marca --admin-cluster-membership. En este ejemplo, se usa el nombre del clúster de administrador especificado por completo, por lo que no necesitas incluir --admin-cluster-membership-location ni --admin-cluster-membership-project.

gcloud container vmware 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 \
  --service-address-cidr-blocks=SERVICE_CIDR_BLOCK \
  --pod-address-cidr-blocks=POD_CIDR_BLOCK \
  --metal-lb-config-address-pools='pool=NAME,avoid-buggy-ips=True|False,manual-assign=True|False,addresses=IP_ADDRESS_RANGE_1;IP_ADDRESS_RANGE_2;...' \
  --control-plane-vip=CONTROL_PLANE_VIP \
  --ingress-vip=INGRESS_VIP \
  --enable-dhcp

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

  Importante: Si planeas instalar Anthos Service Mesh, debes instalar la versión 1.19.3 o posterior. Esto es necesario porque los servicios Fleet y Connect se ejecutan en una región.
• VERSION: Es la versión de GKE en VMware 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=[e-mail] \
      --admin-users=[e-mail]

  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.

  Nota: Además de las políticas de RBAC de Kubernetes, debes otorgar algunos 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 Otorga los roles necesarios.

• SERVICE_CIDR_BLOCK: Es un rango de direcciones IP, en formato CIDR, que se usará para los servicios del clúster. Debe ser al menos un rango de /24.

  Ejemplo: --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. Debe ser al menos un rango /18.

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

• --metal-lb-config-address-pools: Incluye esta marca para especificar la configuración de los grupos de direcciones que usará el balanceador de cargas de MetalLB. El valor de la marca tiene el siguiente formato:

  --metal-lb-config-address-pool 'pool=NAME,avoid-buggy-ips=True|False,manual-assign=True|False,addresses=IP_ADDRESS_RANGE_1;IP_ADDRESS_RANGE_2;...' \

  El valor tiene segmentos que comienzan con las palabras clave pool, avoid-buggy-ip, manual-assign y addresses. Separa cada segmento con una coma.

  • pool: Es un nombre que elijas para el grupo.
  • avoid-buggy-ips1: Si estableces esto como True, el controlador de MetalLB no asignará las direcciones IP que terminen en .0 o .255 a los servicios. De esta forma, se evita el problema de que los dispositivos de consumidores con errores dejen de enviar 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 notación CIDR o en formato 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, por ejemplo: 192.0.2.1/32.

  Ten en cuenta lo siguiente:

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

  Por ejemplo:

  --metal-lb-config-address-pool 'pool=pool1,avoid-buggy-ips=True,manual-assign=True,addresses=10.251.134.80/32;192.168.1.0/26;192.168.1.2-192.168.1.3'

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

  Ejemplo: --control-plane-vip=203.0.113.3

• INGRESS_VIP: 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.

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

IP estáticas y MetalLB

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

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

Asegúrate de desplazarte si es necesario para completar el marcador de posición ADMIN_CLUSTER_NAME para la marca --admin-cluster-membership. En este ejemplo, se usa el nombre del clúster de administrador especificado por completo, por lo que no necesitas incluir --admin-cluster-membership-location ni --admin-cluster-membership-project.

gcloud container vmware 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 \
  --service-address-cidr-blocks=SERVICE_CIDR_BLOCK \
  --pod-address-cidr-blocks=POD_CIDR_BLOCK \
  --metal-lb-config-address-pools='pool=NAME,avoid-buggy-ips=True|False,manual-assign=True|False,addresses=IP_ADDRESS_RANGE_1;IP_ADDRESS_RANGE_2;...' \
  --control-plane-vip=CONTROL_PLANE_VIP \
  --ingress-vip=INGRESS_VIP \
  --static-ip-config-ip-blocks='gateway=GATEWAY,netmask=NETMASK,ips=IP_ADDRESS_1;IP_ADDRESS_2 HOST_2;...' \
  --dns-servers=DNS_SERVER,... \
  --dns-search-domains=DNS_SEARCH_DOMAIN,... \
  --ntp-servers=NTP_SERVER,...

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.

  Importante: Si planeas instalar Anthos Service Mesh, debes instalar la versión 1.19.3 o posterior. Esto es necesario porque los servicios Fleet y Connect se ejecutan en una región.
• VERSION: Es la versión de GKE en VMware 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=[e-mail] \
      --admin-users=[e-mail]

  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.

  Nota: Además de las políticas de RBAC de Kubernetes, debes otorgar algunos 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 Otorga los roles necesarios.

• SERVICE_CIDR_BLOCK: Es un rango de direcciones IP, en formato CIDR, que se usará para los servicios del clúster. Debe ser al menos un rango de /24.

  Ejemplo: --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. Debe ser al menos un rango /18.

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

• --metal-lb-config-address-pools: Incluye esta marca para especificar la configuración de los grupos de direcciones que usará el balanceador de cargas de MetalLB. El valor de la marca tiene el siguiente formato:

  --metal-lb-config-address-pool 'pool=NAME,avoid-buggy-ips=True|False,manual-assign=True|False,addresses=IP_ADDRESS_RANGE_1;IP_ADDRESS_RANGE_2;...' \

  El valor tiene segmentos que comienzan con las palabras clave pool, avoid-buggy-ip, manual-assign y addresses. Separa cada segmento con una coma.

  • pool: Es un nombre que elijas para el grupo.
  • avoid-buggy-ips1: Si estableces esto como True, el controlador de MetalLB no asignará las direcciones IP que terminen en .0 o .255 a los servicios. De esta forma, se evita el problema de que los dispositivos de consumidores con errores dejen de enviar 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 notación CIDR o en formato 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, por ejemplo: 192.0.2.1/32.

  Ten en cuenta lo siguiente:

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

  Por ejemplo:

  --metal-lb-config-address-pool 'pool=pool1,avoid-buggy-ips=True,manual-assign=True,addresses=10.251.134.80/32;192.168.1.0/26;192.168.1.2-192.168.1.3'

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

  Ejemplo: --control-plane-vip=203.0.113.3

• INGRESS_VIP: 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.

• --static-ip-config-ip-blocks: Especifica la puerta de enlace predeterminada, la máscara de subred y una lista de las direcciones IP estáticas para los nodos trabajadores en el clúster de usuario. El valor de la marca tiene el siguiente formato:

  --static-ip-config-ip-blocks 'gateway=GATEWAY,netmask=NETMASK,ips=IP_ADDRESS_1;IP_ADDRESS_2 HOST_2;...'

  El valor tiene segmentos que comienzan con las palabras clave gateway, netmask y ips. Separa los segmentos con una coma.

  Ten en cuenta lo siguiente:

  • Encierra todo el valor entre comillas simples.
  • No se permiten espacios en blanco, excepto entre una dirección IP y un nombre de host.

  En la lista de direcciones IP, sigue estos pasos:

  • Puedes especificar una dirección IP individual o un bloque CIDR de direcciones IP.
  • Separa cada dirección IP o bloque de CIDR con un punto y coma.
  • Para una dirección IP individual, tienes la opción de especificar un nombre de host después de la dirección IP. Separa la dirección IP y el nombre de host con un espacio. Cuando no especificas un nombre de host, GKE on VMware usa el nombre de la VM de vSphere como nombre de host.
  • Si especificas un bloque CIDR, no especifiques un valor para el nombre de host.

  Por ejemplo:

  --static-ip-config-ip-blocks 'gateway=172.16.23.254,netmask=255.255.252.0,ips=172.16.20.10;172.16.20.11 host2;172.16.20.12/30'

• DNS_SERVER: Es una lista separada por comas de las direcciones IP de los servidores DNS para las VM.
• DNS_SEARCH_DOMAIN: Es una lista separada por comas de los dominios de búsqueda de DNS que usarán los hosts. Estos dominios se usan como parte de una lista de búsqueda de dominios.

  Por ejemplo:

  --dns-search-domains example.com,examplepetstore.com

• NTP_SERVER: Es una lista separada por comas de las direcciones IP de los servidores de tiempo para que usen las VM.

BIG-IP y DHCP de F5

En este ejemplo, se muestra cómo crear un clúster de usuario con el balanceador de cargas BIG-IP de F5 y usar el servidor DHCP con el fin de obtener direcciones IP para los nodos del clúster.

Puedes usar F5 para el clúster de usuario solo si el clúster de administrador usa F5. Asegúrate de instalar y configurar el ADC de BIG-IP de F5 antes de integrarlo con GKE en VMware. Consulta la guía de instalación de BIG-IP ADC de F5 para obtener más información. El nombre de usuario y la contraseña de F5 se heredan del clúster de administrador.

Asegúrate de desplazarte si es necesario para completar el marcador de posición ADMIN_CLUSTER_NAME para la marca --admin-cluster-membership. En este ejemplo, se usa el nombre del clúster de administrador especificado por completo, por lo que no necesitas incluir --admin-cluster-membership-location ni --admin-cluster-membership-project.

gcloud container vmware 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 \
  --service-address-cidr-blocks=SERVICE_CIDR_BLOCK \
  --pod-address-cidr-blocks=POD_CIDR_BLOCK \
  --f5-config-address=F5_CONFIG_ADDRESS \
  --f5-config-partition=F5_CONFIG_PARTITION \
  --f5-config-snat-pool=F5_CONFIG_SNAT_POOL \
  --control-plane-vipCONTROL_PLANE_VIP \
  --ingress-vip=INGRESS_VIP \
  --enable-dhcp

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

  Importante: Si planeas instalar Anthos Service Mesh, debes instalar la versión 1.19.3 o posterior. Esto es necesario porque los servicios Fleet y Connect se ejecutan en una región.
• VERSION: Es la versión de GKE en VMware 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=[e-mail] \
      --admin-users=[e-mail]

  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.

  Nota: Además de las políticas de RBAC de Kubernetes, debes otorgar algunos 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 Otorga los roles necesarios.

• SERVICE_CIDR_BLOCK: Es un rango de direcciones IP, en formato CIDR, que se usará para los servicios del clúster. Debe ser al menos un rango de /24.

  Ejemplo: --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. Debe ser al menos un rango /18.

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

• F5_CONFIG_ADDRESS: Es la dirección del balanceador de cargas de BIG-IP de F5.

• F5_CONFIG_PARTITION:Es el nombre de una partición de BIG-IP que creaste para el clúster de usuario.

• F5_CONFIG_SNAT_POOL: Es el nombre del grupo de SNAT, si corresponde.

• 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

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

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

Balanceador de cargas manual e IP estáticas

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

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

Asegúrate de desplazarte si es necesario para completar el marcador de posición ADMIN_CLUSTER_NAME para la marca --admin-cluster-membership. En este ejemplo, se usa el nombre del clúster de administrador especificado por completo, por lo que no necesitas incluir --admin-cluster-membership-location ni --admin-cluster-membership-project.

gcloud container vmware 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 \
  --service-address-cidr-blocks=SERVICE_CIDR_BLOCK \
  --pod-address-cidr-blocks=POD_CIDR_BLOCK \
  --control-plane-vip=CONTROL_PLANE_VIP \
  --control-plane-node-port=CONTROL_PLANE_NODE_PORT \
  --ingress-vip=INGRESS_VIP \
  --ingress-http-node-port=INGRESS_HTTP_NODE_PORT \
  --ingress-https-node-port=INGRESS_HTTPS_NODE_PORT \
  --konnectivity-server-node-port=KONNECTIVITY_SERVER_NODE_PORT

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.

  Importante: Si planeas instalar Anthos Service Mesh, debes instalar la versión 1.19.3 o posterior. Esto es necesario porque los servicios Fleet y Connect se ejecutan en una región.
• VERSION: Es la versión de GKE en VMware 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=[e-mail] \
      --admin-users=[e-mail]

  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.

  Nota: Además de las políticas de RBAC de Kubernetes, debes otorgar algunos 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 Otorga los roles necesarios.

• SERVICE_CIDR_BLOCK: Es un rango de direcciones IP, en formato CIDR, que se usará para los servicios del clúster. Debe ser al menos un rango de /24.

  Ejemplo: --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. Debe ser al menos un rango /18.

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

• 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_NODE_PORT: Es un valor nodePort para el servidor de la API de Kubernetes.

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

  Ejemplo: --ingress-vip=203.0.113.4

• INGRESS_HTTP_NODE_PORT: Es un valor nodePort para el tráfico HTTP al proxy de entrada.

• INGRESS_HTTPS_NODE_PORT: Es un valor nodePort para el tráfico HTTPS al proxy de entrada.

• KONNECTIVITY_SERVER_NODE_PORT: Un valor nodePort para el servidor de Konnectivity.

• --static-ip-config-ip-blocks: Especifica la puerta de enlace predeterminada, la máscara de subred y una lista de las direcciones IP estáticas para los nodos trabajadores en el clúster de usuario. El valor de la marca tiene el siguiente formato:

  --static-ip-config-ip-blocks 'gateway=GATEWAY,netmask=NETMASK,ips=IP_ADDRESS_1;IP_ADDRESS_2 HOST_2;...'

  El valor tiene segmentos que comienzan con las palabras clave gateway, netmask y ips. Separa los segmentos con una coma.

  Ten en cuenta lo siguiente:

  • Encierra todo el valor entre comillas simples.
  • No se permiten espacios en blanco, excepto entre una dirección IP y un nombre de host.

  En la lista de direcciones IP, sigue estos pasos:

  • Puedes especificar una dirección IP individual o un bloque CIDR de direcciones IP.
  • Separa cada dirección IP o bloque de CIDR con un punto y coma.
  • Para una dirección IP individual, tienes la opción de especificar un nombre de host después de la dirección IP. Separa la dirección IP y el nombre de host con un espacio. Cuando no especificas un nombre de host, GKE on VMware usa el nombre de la VM de vSphere como nombre de host.
  • Si especificas un bloque CIDR, no especifiques un valor para el nombre de host.

  Por ejemplo:

  --static-ip-config-ip-blocks 'gateway=172.16.23.254,netmask=255.255.252.0,ips=172.16.20.10;172.16.20.11 host2;172.16.20.12/30'

• DNS_SERVER: Es una lista separada por comas de las direcciones IP de los servidores DNS para las VM.
• DNS_SEARCH_DOMAIN: Es una lista separada por comas de los dominios de búsqueda de DNS que usarán los hosts. Estos dominios se usan como parte de una lista de búsqueda de dominios.

  Por ejemplo:

  --dns-search-domains example.com,examplepetstore.com

• NTP_SERVER: Es una lista separada por comas de las direcciones IP de los servidores de tiempo para que usen las VM.

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

Marcas del plano de control

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

• --cpus=vCPUS: Es la cantidad de CPU virtuales (4 como mínimo) para cada nodo del plano de control del clúster de usuario. Si no se especifica, el valor predeterminado es de 4 CPU virtuales.

• --memory=MEMORY: Es el tamaño de la memoria en mebibytes (MiB) de cada plano de control del clúster de usuario. El valor mínimo es 8,192 y debe ser un múltiplo de 4. Si no se especifica, el valor predeterminado es 8192.

• --replicas=NODES: Es la cantidad de nodos del plano de control para el clúster de usuario. Por ejemplo, puedes seleccionar 1 nodo de plano de control para un entorno de desarrollo y 3 nodos de plano de control para entornos de producción y alta disponibilidad (HA).

• --enable-auto-resize: Si deseas habilitar el cambio de tamaño automático de los nodos del plano de control para el clúster de usuario, incluye --enable-auto-resize. Cambiar el tamaño significa que la CPU virtual y los recursos de memoria asignados a un nodo se ajustan automáticamente. Cuando se habilita, se cambia el tamaño de los nodos del plano de control para el clúster de usuario según la cantidad de nodos trabajadores en el clúster de usuario. Por lo tanto, a medida que agregas más nodos trabajadores al clúster de usuario, aumenta el tamaño de los nodos del plano de control.

• --enable-control-plane-v2: Si deseas habilitar el plano de control V2, incluye --enable-control-plane-v2. Cuando el plano de control V2 está habilitado, el plano de control de un clúster de usuario se ejecuta en uno o más nodos del clúster de usuario. De forma predeterminada, el plano de control de un clúster de usuario se ejecuta en uno o más nodos del clúster de administrador (denominado modelo de kubeception). Cuando el plano de control V2 está habilitado, los valores de --cpus y --memory se aplican a los nodos del plano de control en el clúster de usuario. La cantidad de nodos se determina según la cantidad de direcciones IP que ingreses en --control-plane-ip-block. Cuando el plano de control V2 no está habilitado, los valores de --cpus, --memory y --replicas se aplican a los nodos del plano de control en el clúster de administrador. Asegúrate de reservar suficientes direcciones IP para el clúster de administrador.

  Si habilitas el plano de control V2, también debes especificar las siguientes marcas:

  • --dns-servers=DNS_SERVER_1,...: Es una lista separada por comas de las direcciones IP de los servidores DNS para las VM.

  • --ntp-servers=NTP_SERVER_1,...: Es una lista separada por comas de las direcciones IP de los servidores de tiempo para que usen las VM.

  • --control-plane-ip-block, que tiene el siguiente formato:

    --control-plane-ip-block 'gateway=CP_GATEWAY,netmask=CP_NETMASK,ips=CP_IP_ADDRESS_1;CP_IP_ADDRESS_2 CP_HOST_2'

    El valor tiene segmentos que comienzan con las palabras clave gateway, netmask y ips. Separa los segmentos con una coma.

    Ten en cuenta lo siguiente:

    • Encierra todo el valor entre comillas simples.
    • No se permiten espacios en blanco, excepto entre una dirección IP y un nombre de host.

    En la lista de direcciones IP, sigue estos pasos:

    • Puedes especificar una dirección IP individual o un bloque CIDR de direcciones IP.

    • Separa cada dirección IP o bloque de CIDR con un punto y coma.

    • Para una dirección IP individual, tienes la opción de especificar un nombre de host después de la dirección IP. Separa la dirección IP y el nombre de host con un espacio.

    • Si especificas un bloque CIDR, no especifiques un valor para el nombre de host.

    Por ejemplo:

    --control-plane-ip-block 'gateway=192.168.0.1,netmask=255.0.0.0,ips=192.168.1.1;192.168.1.2 hostname-2;192.168.2.2/28`
    

  • Opcional: --dns-search-domains=DNS_SEARCH_DOMAIN_1,...: Una lista separada por comas de los dominios de búsqueda de DNS que deben usar los hosts. Estos dominios se usan como parte de una lista de búsqueda de dominios.

    Por ejemplo:

    --dns-search-domains example.com,examplepetstore.com

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

Marcas de vSphere

Especifica las siguientes marcas opcionales si es necesario:

• --disable-aag-config: Si no incluyes esta marca, las reglas de antiafinidad de VMware Distributed Resource Scheduler (DRS) se crean de forma automática para los nodos del clúster de usuario, lo que hace que se distribuyan en al menos 3 hosts físicos del centro de datos. Asegúrate de que tu entorno de vSphere cumpla con los requisitos. Si tu clúster no cumple con los requisitos, incluye esta marca.

  Nota: Si seguiste los pasos de Set up minimum infrastructure, solo tienes un host ESXi, así que asegúrate de incluir esta marca.

• --disable-vsphere-csi: Si no incluyes esta marca, los componentes de la interfaz de almacenamiento de contenedores (CSI) de vSphere se implementarán en el clúster de usuario. El controlador de CSI se ejecuta en un clúster de Kubernetes nativo implementado en vSphere para aprovisionar volúmenes persistentes en el almacenamiento de vSphere. Para obtener más información, consulta Usa el controlador de interfaz de almacenamiento de contenedores de vSphere. Si no quieres implementar los componentes de CSI, incluye esta marca.

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

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 Google Cloud Console en la página Clústeres de Anthos.

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.

gcloud container vmware node-pools create NODE_POOL_NAME \
--cluster=USER_CLUSTER_NAME  \
--project=FLEET_HOST_PROJECT_ID \
--location=REGION \
--image-type=IMAGE_TYPE  \
--boot-disk-size=BOOT_DISK_SIZE \
--cpus=vCPUS \
--memory=MEMORY \
--replicas=NODES \
--enable-load-balancer

Reemplaza lo siguiente:

• NODE_POOL_NAME: 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 ubicación de Google Cloud que especificaste cuando creaste el clúster.

• IMAGE_TYPE: El tipo de imagen de SO que se ejecutará en las VM del grupo de nodos. Establece una de las siguientes opciones: ubuntu_containerd o cos.

• BOOT_DISK_SIZE: El tamaño del disco de arranque en gigabytes (GiB) para cada nodo del grupo. El mínimo es 40 GiB.

• vCPUs: La cantidad de CPU virtuales para cada nodo en el grupo de nodos. El mínimo es 4.

• MEMORY: Es el tamaño de la memoria en mebibytes (MiB) para cada nodo del grupo. El mínimo es de 8,192 MiB por nodo trabajador del clúster de usuario y el valor debe ser un múltiplo de 4.

• NODES: la cantidad de nodos en el grupo de nodos. El mínimo es 3.

• Si usas MetalLB como balanceador de cargas, de manera opcional, incluye --enable-load-balancer si deseas permitir que la bocina de MetalLB se ejecute en los nodos del grupo. MetalLB debe estar habilitado en al menos un grupo de nodos. Si no incluyes esta marca, debes crear otro grupo de nodos para usar con MetalLB.

Para obtener más información sobre las marcas opcionales, consulta Agrega un grupo de nodos y 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 el balanceador de cargas en paquete de MetalLB y un grupo de nodos.

Para obtener más información y otros ejemplos, consulta la documentación de referencia de google_gkeonprem_vmware_cluster.

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/avmw_user_cluster_metallb
   

Establece variables en terraform.tfvars

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

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

   cp terraform.tfvars.sample terraform.tfvars
   

2. Modifica los valores de los parámetros en terraform.tfvars.

   project_id                  = "FLEET_HOST_PROJECT_ID"
   region                      = "REGION"
   admin_cluster_name          = "ADMIN_CLUSTER_NAME"
   on_prem_version             = "VERSION"
   admin_user_emails           = ["YOUR_EMAIL_ADDRESS", "ADMIN_2_EMAIL_ADDRESS"]
   cluster_name                = "avmw-user-cluster-metallb"
   control_plane_node_cpus     = 4
   control_plane_node_memory   = 8192
   control_plane_node_replicas = 3
   control_plane_vip           = "CONTROL_PLANE_VIP"
   ingress_vip                 = "INGRESS_VIP"
   lb_address_pools            = [
       { name = "lbpool_1", addresses = ["10.200.0.51-10.200.0.70"] }
   ]
   

   En la siguiente lista, se describen las variables:

   • project_id: 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.

   • on_prem_version: Es la versión de GKE en VMware para el clúster de usuario. Por lo general, debes especificar la misma versión que el clúster de administrador. Para especificar una versión posterior, instala una versión posterior a la del clúster de administrador. Si no conoces la versión del clúster de administrador, ejecuta gcloud container vmware clusters query-version-config, que es el primer paso en Instala una versión posterior a la del clúster de administrador.

   • 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 iniciar sesión en la consola con su identidad de Google.

   • 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_node_cpus: Es la cantidad de CPU virtuales para cada nodo del plano de control del clúster de usuario. El mínimo es 4 CPU virtuales.

   • control_plane_node_memory: Es el tamaño de la memoria en mebibytes (MiB) de cada plano de control del clúster de usuario. El valor mínimo es 8,192 y debe ser un múltiplo de 4.

   • control_plane_node_replicas: Es la cantidad de nodos del plano de control para el clúster de usuario. Por ejemplo, puedes ingresar 1 nodo de plano de control para un entorno de desarrollo y 3 nodos de plano de control para entornos de producción y alta disponibilidad (HA).

   • 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. Especifica lo siguiente:

     • name: Es un nombre para el grupo.
     • addresses: Es un rango de direcciones en formato de notación CIDR o de rango con guion. Si deseas especificar una sola dirección IP en un grupo (como para la VIP de entrada), usa /32 en la notación CIDR, por ejemplo: 192.0.2.1/32.

     Reemplaza las direcciones IP de ejemplo por tus valores y agrega grupos de direcciones adicionales si es necesario.

3. Guarda los cambios en terraform.tfvars. Si no quieres realizar cambios opcionales en main.tf, ve a la siguiente sección: Crea el clúster y un grupo de nodos.

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

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

cp main.tf main.tf.bak

Modo de direccionamiento IP del nodo trabajador

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

1. Reemplaza el bloque network_config e incluye un bloque static_ip_config. Por ejemplo:

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

2. Reemplaza lo siguiente por tus valores:

   • service_address_cidr_blocks: Es un rango de direcciones IP, en formato CIDR, que se usará para los servicios del clúster. Debe ser al menos un rango de /24.

   • pod_address_cidr_blocks: Es un rango de direcciones IP, en formato CIDR, que se usará para los Pods del clúster. Debe ser al menos un rango /18.

   • dns_servers: Una lista de las direcciones IP de servidores DNS para las VM

   • ntp_servers: Una lista de las direcciones IP de los servidores de tiempo para que usen las VM.

   • En el bloque static_ip_config, reemplaza los valores de netmask y gateway por las direcciones de tu red. Reemplaza ip y hostname por las direcciones IP y los nombres de host de tus nodos trabajadores.

Configura el plano de control V2

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

1. Agrega la siguiente línea después de la línea con admin_cluster_membership:

   enable_control_plane_v2 = "true"
   

2. Agrega un mapa control_plane_v2_config al bloque network_config, por ejemplo:

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

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

Crea el clúster y un grupo de nodos

1. Inicializa y crea terraform plan:

   terraform init
   

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

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

   terraform plan
   

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

   terraform apply
   

   La creación del clúster de usuario toma alrededor de 15 minutos o más, y el grupo de nodos tarda otros 15 minutos. Puedes ver el clúster en Google Cloud Console en la página Clústeres de Anthos.

Conéctate al clúster de usuario

Cuando creas un clúster de usuario con un cliente de la API de GKE On-Prem, tienes la opción de agregarte a ti y a otros usuarios como administradores de clúster si especificas las direcciones de correo electrónico de la cuenta de Google Cloud:

• En la consola, tu dirección de correo electrónico se agrega automáticamente en la página Aspectos básicos del clúster en la sección Autorización, y tienes la opción de agregar otros usuarios administradores del clúster.

• Con gcloud CLI, incluye la marca --admin-users configurada en tu dirección de correo electrónico. La marca no toma una lista. Agrega la marca --admin-users para cada usuario administrador del clúster.

• Con la muestra de Terraform, puedes especificarte a ti y a otros usuarios administradores en la variable admin_user_emails del archivo terraform.tvars.sample.

El clúster está configurado con las políticas de control de acceso basado en funciones (RBAC) de Kubernetes que otorgan a los usuarios administradores la función cluster-admin y les permiten acceder al clúster desde la consola mediante su identidad de Google Cloud. Para obtener más información, 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 de tu clúster a través de tu VPC, puedes conectarte directamente al extremo privado y generar un archivo kubeconfig directamente. De lo contrario, puedes usar la puerta de enlace de Connect. En este caso, kubectl usa Connect, que luego reenvía de forma segura el tráfico al extremo privado en tu nombre.

Para acceder al clúster de usuario desde la línea de comandos, necesitas un archivo kubeconfig. Hay 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. La puerta de enlace de Connect te permite administrar tus clústeres de manera fácil y segura. Para obtener más información, consulta Conéctate a clústeres registrados con la puerta de enlace de Connect.

• Para acceder directamente a los extremos privados, crea un archivo kubeconfig en la estación de trabajo de administrador y administra el clúster desde la estación de trabajo de administrador.

Asegúrate de esperar hasta que la consola 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 VMware, el nombre de la membresía es el mismo que el nombre del clúster.

   gcloud container fleet memberships get-credentials MEMBERSHIP_NAME
   

   Mediante este comando, se muestra una kubeconfig específica de la puerta de enlace de Connect especial con la que puedes conectarte al clúster a través de la puerta de enlace.

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

   kubectl get namespaces
   

Estación de trabajo de administrador

Si quieres crear el archivo kubeconfig del clúster de usuario en la estación de trabajo de administrador, ejecuta el siguiente comando a fin de guardar un nuevo archivo kubeconfig para el clúster de usuario de forma local. Reemplaza lo siguiente:

• CLUSTER_NAME: Es el nombre del clúster de usuario recién creado.
• ADMIN_CLUSTER_KUBECONFIG: Es la ruta de acceso al archivo kubeconfig del clúster de administrador.
• USER_CLUSTER_KUBECONFIG: Es el nombre del archivo kubeconfig del clúster de usuario que genera el comando.

kubectl get secret admin \
  --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
  -n CLUSTER_NAME \
  -o=jsonpath='{.data.admin\.conf}' | base64 -d > USER_CLUSTER_KUBECONFIG

Después de guardar el archivo, puedes comenzar a acceder al clúster de usuario mediante kubectl en la estación de trabajo de administrador, por ejemplo:

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get namespaces

Instala una versión posterior a la versión del clúster de administrador

Un clúster de administrador puede administrar clústeres de usuario en diferentes versiones. Si deseas crear un clúster de usuario que sea una versión posterior a la del clúster de administrador, debes descargar y, luego, implementar los componentes que el clúster de administrador necesita para administrar los clústeres de usuario de esa versión, de la siguiente manera:

1. Obtén una lista de las versiones disponibles:

   gcloud container vmware clusters query-version-config \
       --admin-cluster-membership=ADMIN_CLUSTER_NAME \
       --admin-cluster-membership-project=FLEET_HOST_PROJECT_ID \
       --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 en la que se ejecuta la API de GKE On-Prem. Esta es la región que especificarás cuando crees el clúster de usuario. Especifica us-west1 o alguna otra región compatible.

   El resultado del comando es similar al siguiente:

   versions:
   - isInstalled: true
     version: 1.14.3-gke.25
   - version: 1.14.4-gke.54
   - version: 1.15.0-gke.581
   

   Las versiones instaladas en el clúster de administrador tienen anotaciones con isInstalled=true.

2. Si aún no lo hiciste, inscribe el clúster de administrador en la API de GKE On-Prem. Después de inscribir el clúster en la API de GKE On-Prem, no es necesario que vuelvas a realizar este paso.

3. Descarga la versión nueva de los componentes y, luego, impleméntalo en el clúster de administrador:

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

   Con este comando, se descarga la versión de los componentes que especificas en --required-platform-version en el clúster de administrador y, luego, se implementan los componentes. Ahora puedes crear un clúster de usuario con la versión especificada.

¿Qué sigue?

• Implementa una aplicación
• Soluciona problemas de creación de un clúster de usuario en la consola de Cloud