Crear un clúster de usuarios para usarlo con dominios de topología

En Google Distributed Cloud, tus cargas de trabajo se ejecutan en uno o varios clústeres de usuario. En esta página se muestra cómo crear un clúster de usuario para usarlo en los dominios de topología de Google Distributed Cloud. Para usar dominios de topología, se necesita la versión 1.31 o posterior de Google Distributed Cloud.

Para configurar un dominio de topología, debes habilitar el clúster avanzado. Ten en cuenta las siguientes limitaciones de la vista previa de clústeres avanzados:

  • Solo puedes habilitar clústeres avanzados al crear clústeres 1.31 nuevos.
  • Una vez que se haya habilitado el clúster avanzado, no podrás actualizarlo a la versión 1.32. Habilita el clúster avanzado solo en un entorno de prueba.

Esta página está dirigida a administradores, arquitectos y operadores que configuran, monitorizan y gestionan la infraestructura tecnológica. Para obtener más información sobre los roles habituales y las tareas de ejemplo a las que hacemos referencia en el contenido, consulta Roles y tareas habituales de los usuarios de GKE. Google Cloud

Antes de empezar

Descripción general del procedimiento

Para crear un clúster de usuarios con gkectl, sigue estos pasos principales:

  1. Rellena el archivo de configuración del clúster de usuarios
    Especifica los detalles del nuevo clúster en el archivo de configuración del clúster de usuarios.
  2. Rellena el archivo de bloque de IP
    Especifica las direcciones IP de la pasarela, la máscara de subred, los nodos del plano de control y, opcionalmente, los nodos de trabajador en un archivo de bloque de IPs.
  3. Crear clúster de usuarios
    Ejecuta gkectl create cluster para crear un clúster tal como se especifica en los archivos de configuración.
  4. Verificar que el clúster de usuarios esté en funcionamiento
    Usa kubectl para ver los nodos del clúster.

Al final de este procedimiento, tendrás un clúster de usuarios en funcionamiento en el que podrás desplegar tus cargas de trabajo.

Rellena el archivo de configuración del clúster de usuarios

Si has usado gkeadm para crear tu estación de trabajo de administrador, gkeadm habrá generado una plantilla para el archivo de configuración de tu clúster de usuarios llamado user-cluster.yaml. Además, gkeadm ha rellenado algunos campos por ti.

Si no has usado gkeadm para crear tu estación de trabajo de administrador, puedes usar gkectl para generar una plantilla para el archivo de configuración de tu clúster de usuarios.

Para generar una plantilla para el archivo de configuración de tu clúster de usuarios, sigue estos pasos:

gkectl create-config cluster --config=OUTPUT_FILENAME --gke-on-prem-version=VERSION

Haz los cambios siguientes:

OUTPUT_FILENAME: la ruta que quieras para la plantilla generada. Si omite esta marca, gkectl asigna el nombre user-cluster.yaml al archivo y lo coloca en el directorio actual.

VERSION: el número de versión que quieras. Por ejemplo: gkectl create-config cluster --gke-on-prem-version=1.33.100-gke.89.

Familiarízate con el archivo de configuración consultando el documento Archivo de configuración de clúster de usuarios. Te recomendamos que mantengas este documento abierto en otra pestaña o ventana, ya que lo consultarás cuando completes los pasos siguientes.

name

Asigna al campo name el nombre que quieras para el clúster de usuario.

gkeOnPremVersion

Este campo ya está rellenado. Especifica la versión de Google Distributed Cloud. Por ejemplo, 1.33.100-gke.89.

enableAdvancedCluster

Asigna el valor true a enableAdvancedCluster.

enableControlplaneV2

Se requiere Controlplane V2 para todos los clústeres de usuarios 1.30 y versiones posteriores. Asigna el valor true a enableControlplaneV2.

Cuando Controlplane V2 está habilitado, el plano de control del clúster de usuarios se ejecuta en los nodos del propio clúster de usuarios.

enableDataplaneV2

Asigna el valor true a enableDataplaneV2.

vCenter

Elimina toda esta sección. En su lugar, debe configurar la información de vCenter en el archivo de configuración de la infraestructura de vSphere por dominio de topología.

network

  • Elimina lo siguiente del archivo de configuración:

    • Toda la sección network.hostConfig. Esta información se configura en el archivo de configuración de la infraestructura de vSphere por dominio de topología.
    • El campo network.vCenter.networkName. Este campo se configura en el archivo de configuración de la infraestructura de vSphere por dominio de topología.
    • Toda la sección network.controlPlaneIPBlock. Las direcciones IP de la pasarela, la máscara de red y los nodos del plano de control se configuran en un archivo de bloque de IPs.

  • Asigna a network.ipMode.ipBlockFilePath la ruta al archivo de bloque de IP.

  • Decide cómo quieres que obtengan sus direcciones IP los nodos de trabajo. Las opciones son las siguientes:

    • Desde un servidor DHCP que hayas configurado previamente. Asigna el valor "dhcp" a network.ipMode.type.

    • A partir de una lista de direcciones IP estáticas que proporciones en el archivo de bloque de IP. Asigna el valor "static" a network.ipMode.type.

    Los nodos del plano de control de tu clúster de usuario deben obtener sus direcciones IP de una lista de direcciones estáticas que proporciones en el archivo de bloque de IPs. Esto ocurre aunque tus nodos de trabajador obtengan sus direcciones de un servidor DHCP.

    Independientemente de si utilizas un servidor DHCP o especificas una lista de direcciones IP estáticas, debes tener suficientes direcciones IP disponibles para tu clúster de usuarios. Para saber cuántas direcciones IP necesitas, consulta Planificar las direcciones IP.

  • Los campos network.podCIDR y network.serviceCIDR tienen valores predefinidos que puedes dejar sin modificar, a menos que entren en conflicto con direcciones que ya se estén usando en tu red. Kubernetes usa estos intervalos para asignar direcciones IP a los pods y servicios de tu clúster.

loadBalancer

advancedNetworking

Si tienes previsto crear una pasarela de NAT de salida, asigna el valor true a advancedNetworking.

multipleNetworkInterfaces

Asigna el valor false a multipleNetworkInterfaces. No se admiten varias interfaces de red para pods con dominios de topología.

storage

Asigna el valor true a storage.vSphereCSIDisabled para inhabilitar la implementación de componentes de CSI de vSphere.

masterNode

  • Si quieres especificar la CPU y la memoria de los nodos del plano de control del clúster de usuario, rellena los campos cpus y memoryMB de la sección masterNode.

  • Solo se admiten clústeres de alta disponibilidad. Define el campo replicas como 3 para especificar que el clúster tendrá tres nodos del plano de control.

  • Para habilitar el cambio de tamaño automático de los nodos del plano de control, defina autoResize.enabled en true.

  • Elimina toda la sección masterNode.vsphere.

  • Rellena el campo masterNode.topologyDomains con el nombre del dominio de topología en el que quieres que estén los nodos del plano de control.

nodePools

Un grupo de nodos de trabajo de un clúster que tienen la misma configuración. Por ejemplo, puede configurar un dominio de topología independiente para cada grupo de nodos. Debes especificar al menos un grupo de nodos rellenando la sección nodePools.

En cada grupo de nodos que especifiques:

  • Rellena el campo nodePools[i].topologyDomains con el nombre del dominio de topología en el que quieres que esté el grupo de nodos.

  • Elimina todos los campos de la sección nodePools[i].vsphere, excepto nodePools[i].vsphere.tags. Esta información se especifica en el archivo de configuración de la infraestructura de vSphere por dominio de topología.

  • Define nodePools[i].osImageType como ubuntu_cgroupv2 o ubuntu_containerd.

Para obtener información más general sobre los grupos de nodos, consulta Grupos de nodos y Crear y gestionar grupos de nodos.

antiAffinityGroups

Asigna el valor false a antiAffinityGroups.enabled. Las reglas de antiafinidad de Distributed Resource Scheduler (DRS) no se admiten con dominios de topología.

stackdriver

Rellena la sección stackdriver para habilitar Cloud Logging y Cloud Monitoring en tu clúster.

Ten en cuenta los siguientes requisitos:

  • El ID de stackdriver.projectID debe ser el mismo que el de gkeConnect.projectID y cloudAuditLogging.projectID.

  • La región definida en stackdriver.clusterLocation debe ser la misma que la definida en cloudAuditLogging.clusterLocation y gkeConnect.location. Google Cloud Además, si gkeOnPremAPI.enabled es true, se debe definir la misma región en gkeOnPremAPI.location.

Si los IDs de proyecto y las regiones no son los mismos, no se podrá crear el clúster.

gkeConnect

Tu clúster de usuario debe estar registrado en una Google Cloud flota.

Rellena la sección gkeConnect para especificar un proyecto del host de la flota y una cuenta de servicio asociada. El ID de gkeConnect.projectID debe ser el mismo que el ID definido en stackdriver.projectID y cloudAuditLogging.projectID. Si los IDs de proyecto no son los mismos, se produce un error al crear el clúster.

También puedes especificar una región en la que se ejecuten los servicios de flota y de conexión en gkeConnect.location. Si no incluye este campo, el clúster usará las instancias globales de estos servicios.

Si incluyes gkeConnect.location en tu archivo de configuración, la región que especifiques debe ser la misma que la configurada en cloudAuditLogging.clusterLocation, stackdriver.clusterLocation y gkeOnPremAPI.location. Si las regiones no son las mismas, no se podrá crear el clúster.

gkeOnPremAPI

En esta sección se describe cómo se registran los clústeres en la API de GKE On-Prem.

La herramienta de línea de comandos gkectl es la única herramienta de gestión del ciclo de vida de clústeres disponible para clústeres que usan dominios de topología. Aunque la consola, la CLI de Google Cloud y Terraform no son compatibles con los clústeres que usan dominios de topología, puedes registrar el clúster en la API de GKE On-Prem cuando se cree. Google Cloud

Si la API de GKE On-Prem está habilitada en tuGoogle Cloud proyecto, todos los clústeres del proyecto se registrarán automáticamente en la API de GKE On-Prem en la región configurada en stackdriver.clusterLocation. La región gkeOnPremAPI.location debe ser la misma que la especificada en cloudAuditLogging.clusterLocation, gkeConnect.location y stackdriver.clusterLocation.

  • Si quieres registrar todos los clústeres del proyecto en la API de GKE On-Prem, sigue los pasos que se indican en la sección Antes de empezar para activar y usar la API de GKE On-Prem en el proyecto.

  • Si no quieres registrar el clúster en la API GKE On-Prem, incluye esta sección y asigna el valor false a gkeOnPremAPI.enabled. Si no quieres registrar ningún clúster en el proyecto, inhabilita gkeonprem.googleapis.com (el nombre del servicio de la API de GKE On-Prem) en el proyecto. Para obtener instrucciones, consulta Inhabilitar servicios.

cloudAuditLogging

Si quieres integrar los registros de auditoría del servidor de la API de Kubernetes de tu clúster con Cloud Audit Logs, rellena la sección cloudAuditLogging.

Ten en cuenta los siguientes requisitos:

# advanced-cluster-change #

Define cloudAuditLogging.serviceAccountKeyPath con la misma ruta que stackdriver.serviceAccountKeyPath.

  • El ID de cloudAuditLogging.projectID debe ser el mismo que el de gkeConnect.projectID y stackdriver.projectID.

  • La región de cloudAuditLogging.clusterLocation debe ser la misma que la región definida en gkeConnect.location (si el campo se incluye en el archivo de configuración) y stackdriver.clusterLocation. Además, si gkeOnPremAPI.enabled es true, se debe definir la misma región en gkeOnPremAPI.location.

Si los IDs de proyecto y las regiones no son los mismos, no se podrá crear el clúster.

preparedSecrets

Elimina el campo preparedSecrets. Las credenciales preparadas no se admiten cuando los dominios de topología están habilitados.

schedulerConfiguration

Si quieres configurar opciones adicionales que se enviarán a kube-scheduler, añade la sección schedulerConfiguration a tu archivo de configuración.

Ejemplo de archivos de configuración rellenados

A continuación, se muestran ejemplos de un archivo de bloque de IP y de un archivo de configuración de clúster de usuarios:

user-ipblock.yaml

blocks:
  - netmask: 255.255.255.0
    gateway: 172.16.21.1
    ips:
    - ip: 172.16.21.2
      hostname: worker-vm-1
    - ip: 172.16.21.3
      hostname: worker-vm-2
    - ip: 172.16.21.4
      hostname: worker-vm-3
    - ip: 172.16.21.5
      hostname: worker-vm-4
  - netmask: 255.255.255.0
    gateway: 100.115.223.254
    ips:
    - ip: 100.115.222.205
      hostname: cp-1
      isControlPlane: true
    - ip: 100.115.222.206
      hostname: cp-2
      isControlPlane: true
    - ip: 100.115.222.207
      hostname: cp-3
      isControlPlane: true

user-cluster.yaml

cat user-cluster.yaml
apiVersion: v1
kind: UserCluster
name: "my-user-cluster"
gkeOnPremVersion: 1.33.100-gke.89
enableAdvancedCluster: true
enableControlplaneV2: true
enableDataplaneV2: true
network:
  ipMode:
    type: "static"
    ipBlockFilePath: "user-ipblock.yaml"
  serviceCIDR: 10.96.0.0/20
  podCIDR: 192.168.0.0/16
loadBalancer:
  vips:
    controlPlaneVIP: "100.115.222.200"
    ingressVIP: "172.16.21.30"
  kind: "ManualLB"
  manualLB:
    ingressHTTPNodePort: 32527
    ingressHTTPSNodePort: 30139
    controlPlaneNodePort: 30968
masterNode:
  cpus: 4
  memoryMB: 8192
  replicas: 3
nodePools:
- name: "worker-node-pool1"
  cpus: 4
  memoryMB: 8192
  replicas: 3
  topologyDomains:
  - "domain1"
antiAffinityGroups:
  enabled: false
gkeConnect:
  projectID: "my-project-123"
  location: "us-central1"
  registerServiceAccountKeyPath: "connect-register-sa-2203040617.json"
stackdriver:
  projectID: "my-project-123"
  clusterLocation: "us-central1"
  enableVPC: false
  serviceAccountKeyPath: "log-mon-sa-2203040617.json"
autoRepair:
  enabled: true

Estos son los puntos importantes que debes tener en cuenta en el ejemplo anterior:

  • El campo nodePools.replicas tiene el valor 3, lo que significa que hay tres nodos de trabajo en "worker-node-pool". Todos los nodos de trabajo usan direcciones IP estáticas porque network.ipMode.type está definido como "static".

  • Las direcciones IP de los nodos del plano de control y de los nodos de trabajador se especifican en un archivo de bloque de IP. El archivo de bloque de IPs tiene cuatro direcciones para nodos de trabajo, aunque solo haya tres. La dirección IP del nodo de trabajo adicional es necesaria durante la actualización, la actualización y la reparación automática del clúster. Las direcciones IP de los nodos del plano de control tienen la marca isControlPlane: true.

  • Los clústeres avanzados, Controlplane V2 y Dataplane V2 están habilitados.

  • El campo masterNode.replicas se define como 3, por lo que el clúster tendrá un plano de control de alta disponibilidad.

  • La IP virtual del plano de control está en la misma VLAN que los nodos del plano de control, y la IP virtual de entrada está en la misma VLAN que los nodos de trabajador.

Rellena el archivo de bloque de IP

Copia la plantilla del archivo de bloque de IPs en el archivo del directorio que hayas especificado en el campo network.ipMode.ipBlockFilePath del archivo de configuración del clúster de usuarios. Crea archivos de bloqueo de IP independientes para el clúster de administrador y para cada clúster de usuario.

Añade las direcciones IP de la pasarela, la máscara de red y los nodos del plano de control al archivo de bloqueo de IP. Por cada dirección IP de nodo del plano de control, añade isControlPlane: true, tal como se muestra en el ejemplo anterior. Si quieres un clúster de usuario de alta disponibilidad, especifica tres direcciones IP. De lo contrario, especifica una dirección IP. El número de direcciones IP que especifiques para los nodos del plano de control debe coincidir con el número del campo masterNode.replicas del archivo de configuración del clúster de usuarios.

Si network.ipMode.type tiene el valor "static", añade las direcciones IP de los nodos de trabajo al archivo de bloque de IP. Asegúrate de especificar una dirección IP adicional para usarla durante la actualización del clúster, la actualización y la reparación automática.

Cada dirección de la pasarela del archivo de bloque de IPs debe coincidir con la dirección especificada en un campo topologyDomains[i].network.gateway del archivo de configuración de la infraestructura de vSphere. Para obtener más información, consulta el ejemplo de dominios de topología.

Crear clúster de usuarios

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

gkectl create cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG --config USER_CLUSTER_CONFIG

Buscar el archivo kubeconfig del clúster de usuarios

El comando gkectl create cluster crea un archivo kubeconfig llamado USER_CLUSTER_NAME-kubeconfig en el directorio actual. Necesitarás este archivo kubeconfig más adelante para interactuar con tu clúster de usuario.

El archivo kubeconfig contiene el nombre de tu clúster de usuario. Para ver el nombre del clúster, puedes ejecutar el siguiente comando:

kubectl config get-clusters --kubeconfig USER_CLUSTER_KUBECONFIG

El resultado muestra el nombre del clúster. Por ejemplo:

NAME
my-user-cluster

Si quieres, puedes cambiar el nombre y la ubicación del archivo kubeconfig.

Verificar que el clúster de usuarios esté en funcionamiento

Verifica que tu clúster de usuario esté en funcionamiento:

kubectl get nodes --kubeconfig USER_CLUSTER_KUBECONFIG

Sustituye USER_CLUSTER_KUBECONFIG por la ruta del archivo kubeconfig de tu clúster de usuario.

El resultado muestra los nodos del clúster de usuarios. Por ejemplo:

cp-vm-1       Ready    control-plane,master   18m
cp-vm-2       Ready    control-plane,master   18m
cp-vm-3       Ready    control-plane,master   18m
worker-vm-1   Ready                           6m7s
worker-vm-2   Ready                           6m6s
worker-vm-3   Ready                           6m14s

Configurar tu PodTemplate

La etiqueta de topología se rellena con las etiquetas de los nodos del dominio de topología. A menos que la configuración del dominio de tu topología haya usado la restricción predeterminada, "topology.kubernetes.io/zone" como clave de topología, debes configurar la clave de topología en la plantilla de pod de tu Deployment, StatefulSet o ReplicaSet, según corresponda.

Por ejemplo, supongamos que ha definido la clave en la etiqueta de topología como "topology.examplepetstore.com/zone". En PodTemplate, especifica la clave como valor del campo topologySpreadConstraints.topologyKey. Esto permite que el programador de Kubernetes distribuya los pods en el dominio de topología para asegurar la alta disponibilidad y evitar la concentración excesiva en una sola zona en caso de fallo.

Solución de problemas

Consulta Solucionar problemas de creación y actualización de clústeres.

Siguientes pasos