Crea un clúster de usuario para usarlo con dominios de topología

En Google Distributed Cloud, tus cargas de trabajo se ejecutan en uno o más 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. Se requiere la versión 1.31 o una posterior de Google Distributed Cloud para usar dominios de topología.

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

  • Puedes habilitar el clúster avanzado en el momento de la creación del clúster solo para los clústeres nuevos de la versión 1.31.
  • Después de habilitar el clúster avanzado, no podrás actualizarlo a la versión 1.32. Solo habilita el clúster avanzado en un entorno de prueba.

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

Antes de comenzar

Descripción general del procedimiento

Estos son los pasos principales para usar gkectl y crear un clúster de usuario:

  1. Completa el archivo de configuración del clúster de usuario
    Especifica los detalles de tu clúster nuevo en el archivo de configuración del clúster de usuario.
  2. Completa tu archivo de bloqueo de IP
    Especifica las direcciones IP de la puerta de enlace, la máscara de red, los nodos del plano de control y, de manera opcional, los nodos trabajadores en un archivo de bloque de IP.
  3. Crea un clúster de usuario
    Ejecuta gkectl create cluster para crear un clúster como se especifica en los archivos de configuración.
  4. Verifica que el clúster de usuario esté en ejecución
    Usa kubectl para ver los nodos del clúster.

Al final de este procedimiento, tendrás un clúster de usuario en ejecución en el que podrás implementar las cargas de trabajo.

Completa el archivo de configuración del clúster de usuario

Si usaste gkeadm para crear tu estación de trabajo de administrador, gkeadm generó una plantilla para tu archivo de configuración de clústeres de usuarios llamado user-cluster.yaml. Además, gkeadm completó algunos de los campos por ti.

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

Si deseas generar una plantilla para el archivo de configuración de clústeres de usuarios, haz lo siguiente:

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

Reemplaza lo siguiente:

OUTPUT_FILENAME: una ruta de acceso que elijas para la plantilla generada. Si omites esta marca, gkectl asigna un nombre al archivo user-cluster.yaml y lo coloca en el directorio actual.

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

Familiarízate con el archivo de configuración mediante el análisis del documento del archivo de configuración del clúster de usuario. Se recomienda mantener este documento abierto en una pestaña o ventana separada, ya que harás referencia a él a medida que completes los siguientes pasos.

name

Configura el campo name con el nombre que desees para el clúster de usuarios.

gkeOnPremVersion

Ya se completó este campo. Especifica la versión de Google Distributed Cloud. Por ejemplo, 1.33.100-gke.89.

enableAdvancedCluster

Establece enableAdvancedCluster en true.

enableControlplaneV2

Controlplane V2 es obligatorio para todos los clústeres de usuario de la versión 1.30 y posteriores. Configura enableControlplaneV2 como true.

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

enableDataplaneV2

Establece enableDataplaneV2 en true.

vCenter

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

network

  • Quita 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 puerta de enlace, la máscara de red y los nodos del plano de control se configuran en un archivo de bloque de IP.

  • Establece network.ipMode.ipBlockFilePath en la ruta de acceso al archivo de bloque de IP.

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

    • Desde un servidor DHCP que configures con anticipación. Configura network.ipMode.type como "dhcp".

    • De una lista de direcciones IP estáticas que proporciones en el archivo de bloque de IP. Establece network.ipMode.type en "static".

    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 proporcionas en el archivo de bloque de IP. Esto es así incluso si los nodos trabajadores obtienen sus direcciones de un servidor DHCP.

    Sin importar si dependes de un servidor DHCP o especificas una lista de direcciones IP estáticas, debes tener suficientes direcciones IP disponibles para el clúster de usuario. Para obtener una explicación de cuántas direcciones IP necesitas, consulta Planifica tus direcciones IP.

  • network.podCIDR y network.serviceCIDR tienen valores prepropagados que puedes dejar sin modificar, a menos que entren en conflicto con direcciones que ya se usan en tu red. Kubernetes usa estos rangos para asignar direcciones IP a Pods y objetos Service en tu clúster.

loadBalancer

advancedNetworking

Si planeas crear una puerta de enlace NAT de salida, configura advancedNetworking como true.

multipleNetworkInterfaces

Configura multipleNetworkInterfaces como false. No se admiten varias interfaces de red para Pods con dominios de topología.

storage

Configura storage.vSphereCSIDisabled como true para inhabilitar la implementación de los componentes de CSI de vSphere.

masterNode

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

  • Solo se admiten clústeres con alta disponibilidad (HA). Configura el campo replicas como 3 para especificar que el clúster tendrá tres nodos de plano de control.

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

  • Quita toda la sección masterNode.vsphere.

  • Completa el campo masterNode.topologyDomains con el nombre del dominio de topología en el que deseas que se encuentren los nodos del plano de control.

nodePools

Un grupo de nodos es un conjunto de nodos trabajadores en un clúster que tienen la misma configuración. Por ejemplo, es posible que desees configurar un dominio de topología independiente para cada grupo de nodos. Debes especificar al menos un grupo de nodos completando la sección nodePools.

Para cada grupo de nodos que especifiques, haz lo siguiente:

  • Completa el campo nodePools[i].topologyDomains con el nombre del dominio de topología en el que deseas que se encuentre el grupo de nodos.

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

  • Establece nodePools[i].osImageType en ubuntu_cgroupv2 o ubuntu_containerd.

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

antiAffinityGroups

Configura antiAffinityGroups.enabled como false. Las reglas de anti-afinidad del Distributed Resource Scheduler (DRS) no son compatibles con los dominios de topología.

stackdriver

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

Ten en cuenta los siguientes requisitos:

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

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

Si los IDs de proyecto y las regiones no son los mismos, la creación del clúster fallará.

gkeConnect

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

Completa la sección gkeConnect para especificar un proyecto host de flota y una cuenta de servicio asociada. El ID en gkeConnect.projectID debe ser el mismo que el ID establecido en stackdriver.projectID y cloudAuditLogging.projectID. Si los IDs de proyecto no son los mismos, la creación del clúster fallará.

De forma opcional, puedes especificar una región en la que se ejecutan los servicios de la flota y de Connect en gkeConnect.location. Si no incluyes 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 región configurada en cloudAuditLogging.clusterLocation, stackdriver.clusterLocation y gkeOnPremAPI.location. Si las regiones no son las mismas, la creación del clúster fallará.

gkeOnPremAPI

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

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

Si la API de GKE On-Prem está habilitada en tu proyecto deGoogle Cloud , todos los clústeres del proyecto se inscriben 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 región especificada en cloudAuditLogging.clusterLocation, gkeConnect.location y stackdriver.clusterLocation.

  • Si deseas inscribir todos los clústeres del proyecto en la API de GKE On-Prem, asegúrate de seguir los pasos que se indican en Antes de comenzar para activar y usar la API de GKE On-Prem en el proyecto.

  • Si no deseas inscribir el clúster en la API de GKE On-Prem, incluye esta sección y configura gkeOnPremAPI.enabled como false. Si no deseas inscribir ningún clúster en el proyecto, inhabilita gkeonprem.googleapis.com (el nombre del servicio para la API de GKE On-Prem) en el proyecto. Para obtener instrucciones, consulta Inhabilita servicios.

cloudAuditLogging

Si deseas integrar los registros de auditoría del servidor de la API de Kubernetes del clúster a los Registros de auditoría de Cloud, completa la sección cloudAuditLogging.

Ten en cuenta los siguientes requisitos:

# advanced-cluster-change #

Establece cloudAuditLogging.serviceAccountKeyPath en la misma ruta que stackdriver.serviceAccountKeyPath.

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

  • La región en cloudAuditLogging.clusterLocation debe ser la misma que la región establecida 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 configurar la misma región en gkeOnPremAPI.location.

Si los IDs de proyecto y las regiones no son los mismos, la creación del clúster fallará.

preparedSecrets

Quita el campo preparedSecrets. Las credenciales preparadas no se admiten cuando se habilitan los dominios de topología.

schedulerConfiguration

Si deseas configurar parámetros adicionales que se pasarán a kube-scheduler, agrega la sección schedulerConfiguration a tu archivo de configuración.

Ejemplo de archivos de configuración completados

Este es un ejemplo de un archivo de bloque de IP y un archivo de configuración de clúster de usuario.

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 comprender en el ejemplo anterior:

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

  • Las direcciones IP de los nodos del plano de control y los nodos trabajadores se especifican en un archivo de bloque de IP. El archivo de bloque de IP tiene cuatro direcciones para los nodos trabajadores, aunque solo hay tres nodos trabajadores. La dirección IP adicional del nodo trabajador 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 marcaisControlPlane: true.

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

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

  • La VIP del plano de control está en la misma VLAN que los nodos del plano de control, y la VIP de entrada está en la misma VLAN que los nodos trabajadores.

Completa tu archivo de bloqueo de IP

Copia la plantilla del archivo de bloque de IP en el archivo del directorio que especificaste en el campo network.ipMode.ipBlockFilePath del archivo de configuración del clúster de usuario. Crea archivos de bloque de IP separados para el clúster de administrador y para cada clúster de usuario.

Agrega las direcciones IP de la puerta de enlace, la máscara de red y los nodos del plano de control al archivo de bloque de IP. Para cada dirección IP del nodo del plano de control, agrega isControlPlane: true, como se muestra en el ejemplo anterior. Si deseas un clúster de usuario con alta disponibilidad (HA), especifica tres direcciones IP. De lo contrario, especifica una dirección IP. La cantidad de direcciones IP que especifiques para los nodos del plano de control debe coincidir con la cantidad del campo masterNode.replicas en el archivo de configuración del clúster de usuario.

Si network.ipMode.type está configurado como "static", agrega las direcciones IP de los nodos trabajadores al archivo de bloque de IP. Asegúrate de especificar una dirección IP adicional para usar durante la actualización, la actualización y la reparación automática del clúster.

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

Crea un clúster de usuario

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

gkectl create cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG --config USER_CLUSTER_CONFIG

Ubica el archivo kubeconfig del clúster de usuario

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

En el resultado, se muestra el nombre del clúster. Por ejemplo:

NAME
my-user-cluster

Si lo deseas, puedes cambiar el nombre y la ubicación de tu archivo kubeconfig.

Verifica que el clúster de usuario esté en ejecución

Verifica que el clúster de usuario esté en ejecución:

kubectl get nodes --kubeconfig USER_CLUSTER_KUBECONFIG

Reemplaza USER_CLUSTER_KUBECONFIG con la ruta de tu archivo kubeconfig del clúster de usuario.

En el resultado, se muestran los nodos del clúster de usuario. 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

Configura tu PodTemplate

La etiqueta de topología se propaga a las etiquetas de los nodos en el dominio de topología. A menos que la configuración de tu dominio de 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 del pod de tu Deployment, StatefulSet o ReplicaSet, según corresponda.

Por ejemplo, supongamos que definiste la clave en la etiqueta de topología como "topology.examplepetstore.com/zone". En PodTemplate, especifica la clave como el valor del campo topologySpreadConstraints.topologyKey. Esto permite que el programador de Kubernetes distribuya los Pods en todo el dominio de topología para garantizar una alta disponibilidad y evitar una concentración excesiva en cualquier área en caso de falla.

Soluciona problemas

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

¿Qué sigue?