Actualizar clústeres

Después de crear un clúster, puedes cambiar algunos aspectos de su configuración. Por ejemplo, puedes:

  • Añadir, quitar o sustituir nodos.
  • Añade o elimina anotaciones del clúster.
  • Modifica los valores de los campos mutables de los recursos de clúster y de grupo de nodos.
  • Modificar otros recursos personalizados.

Puedes usar bmctl o Google Cloud CLI para actualizar un clúster. Si has creado un clúster de administrador o de usuario con Terraform, puedes usar Terraform para actualizarlo. Ten en cuenta lo siguiente:

  • Muchos aspectos de la configuración de tu clúster son inmutables y no se pueden actualizar después de crear el clúster. Para ver una lista completa de los campos mutables e inmutables, consulta la referencia de los campos de configuración de clústeres. La referencia de campo es una tabla ordenable. Haz clic en los encabezados de las columnas para cambiar el orden. Haga clic en el nombre de un campo para ver su descripción.

  • La CLI de gcloud y Terraform solo admiten la actualización de clústeres de administrador y de usuario. Para actualizar otros tipos de clústeres, debes usar bmctl.

  • gcloud CLI y Terraform solo admiten cambios en los recursos de clúster y de grupo de nodos. Debes usar kubectl o bmctl para actualizar otros recursos personalizados que afecten al clúster.

Esta página está dirigida a administradores, arquitectos y operadores que gestionan el ciclo de vida de la infraestructura tecnológica subyacente. 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 Enterprise. Google Cloud

Cómo actualizar clústeres

Por lo general, se sigue esta secuencia de acciones para actualizar un clúster:

bmctl

  1. Cambia los valores de los campos correspondientes en el archivo de configuración del clúster, que se encuentra en esta ubicación de forma predeterminada:
    bmctl-workspace/CLUSTER-NAME/CLUSTER-NAME.yaml.

  2. Para actualizar el clúster, ejecuta el comando bmctl update:

    bmctl update cluster -c CLUSTER_NAME --kubeconfig=KUBECONFIG
    

    Haz los cambios siguientes:

    • CLUSTER_NAME: el nombre del clúster que quieras actualizar.
    • KUBECONFIG: en el caso de los clústeres de administrador, híbridos o independientes, introduce la ruta al archivo kubeconfig del clúster. En el caso de un clúster de usuario, introduce la ruta al archivo kubeconfig del clúster admin.

CLI de gcloud

  1. Especifica solo las marcas de la configuración que quieras modificar.

  2. Ejecuta el comando de actualización correspondiente:

Terraform

  1. Cambia los valores de los campos correspondientes del archivo de configuración de Terraform que has usado para crear el clúster o el grupo de nodos. Consulta la documentación de referencia de Terraform para ver descripciones detalladas de los campos:

  2. Actualiza la configuración ejecutando el comando terraform apply.

En las siguientes secciones se describen algunos ejemplos habituales para actualizar un clúster.

Añadir o quitar nodos en un clúster

Un grupo de nodos es un conjunto de nodos de un clúster que tienen la misma configuración. Ten en cuenta que un nodo siempre pertenece a un pool de nodos. Para añadir un nuevo nodo a un clúster, debes añadirlo a un grupo de nodos concreto. Eliminar un nodo de un grupo de nodos equivale a eliminar el nodo del clúster por completo.

Hay tres tipos de grupos de nodos en Google Distributed Cloud: plano de control, balanceador de carga y nodo de trabajador. En las siguientes secciones se describe cómo añadir o quitar nodos de cada tipo de grupo de nodos.

bmctl

Para añadir o quitar un nodo de un grupo de nodos, debes añadir o quitar la dirección IP del nodo en una sección específica del archivo de configuración del clúster. En la siguiente lista se muestra qué sección se debe editar para un grupo de nodos determinado:

  • Grupo de nodos de trabajo: añade o elimina la dirección IP del nodo en la sección spec.nodes de la especificación NodePool.
  • Grupo de nodos del plano de control: añade o elimina la dirección IP del nodo en la sección spec.controlPlane.nodePoolSpec.nodesCluster de la especificación.
  • Grupo de nodos del balanceador de carga: añade o elimina la dirección IP del nodo en la sección spec.loadBalancer.nodePoolSpec.nodesCluster de la especificación.

Ejemplo: eliminar un nodo de trabajador

A continuación, se muestra un archivo de configuración de clúster de ejemplo que muestra las especificaciones de dos nodos de trabajador:

---
apiVersion: baremetal.cluster.gke.io/v1
kind: NodePool
metadata:
  name: nodepool1
  namespace: cluster-cluster1
spec:
  clusterName: cluster1
  nodes:
  - address: 192.0.2.1
  - address: 192.0.2.2

Para quitar un nodo:

  1. (Opcional) Si el nodo que vas a quitar ejecuta pods críticos, primero ponlo en modo de mantenimiento.

    Puedes monitorizar el proceso de drenaje de nodos de los nodos de trabajo consultando los campos status.nodesDrained y status.nodesDraining del recurso NodePool.

  2. Edita el archivo de configuración del clúster para eliminar la entrada de la dirección IP del nodo.

  3. Actualiza el clúster:

    bmctl update cluster1 \
        --kubeconfig=ADMIN_KUBECONFIG
    

CLI de gcloud

Para añadir o quitar nodos, se usa el comando update. El comando update que utilices y la marca en la que especifiques la dirección IP dependen del tipo de grupo de nodos que quieras actualizar:

  • Grupo de nodos de trabajador: ejecuta gcloud container bare-metal node-pools update y especifica la dirección IP en la marca --node-configs 'node-ip=IP_ADDRESS'.

  • Grupo de nodos del plano de control en un clúster de administrador: ejecuta gcloud container bare-metal admin-clusters update y especifica la dirección IP en la marca --control-plane-node-configs 'node-ip=IP_ADDRESS'.

  • Pool de nodos del plano de control de un clúster de usuarios: ejecuta gcloud container bare-metal clusters update y especifica la dirección IP en la marca --control-plane-node-configs 'node-ip=IP_ADDRESS'.

  • Grupo de nodos del balanceador de carga: ejecuta gcloud container bare-metal clusters update y especifica la dirección IP en la marca --metal-lb-load-balancer-node-configs 'node-ip=IP_ADDRESS' o
    --bgp-load-balancer-node-configs 'node-ip=IP_ADDRESS'.

La marca en la que especifiques la dirección IP solo acepta un node-ip. Incluye la marca de cada dirección IP del grupo de nodos.

Los comandos update sustituyen todas las direcciones IP por las que especifiques. Para añadir un nodo, incluye las direcciones IP de los nodos existentes y la dirección IP del nuevo nodo en el comando update. Del mismo modo, puedes eliminar nodos incluyendo solo las direcciones IP de los nodos que quieras conservar.

Ejemplo: eliminar un nodo de trabajador

En esta sección se muestra cómo eliminar un nodo de trabajo de un grupo de nodos con datos de ejemplo. En los pasos siguientes también se incluyen otros comandos de gcloud CLI que pueden resultarte útiles.

  1. (Opcional) Si el nodo que vas a quitar ejecuta pods críticos, primero ponlo en modo de mantenimiento.

    Puedes monitorizar el proceso de drenaje de nodos de los nodos de trabajo consultando los campos status.nodesDrained y status.nodesDraining del recurso NodePool.

  2. Ejecuta el comando list para enumerar todos los grupos de nodos del clúster:

    gcloud container bare-metal node-pools list \
        --cluster=abm-user-cluster1 \
        --project=example-project-12345 \
        --location=us-central1
    

    El resultado debería ser similar al siguiente:

    NAME         LOCATION     STATE
    node-pool-1  us-central1  RUNNING
    node-pool-2  asia-east1   RUNNING
    
  3. Ejecuta el comando describe para enumerar todas las direcciones IP del grupo de nodos:

    gcloud container bare-metal node-pools describe node-pool-1 \
        --cluster=abm-user-cluster1 \
        --project=example-project-12345 \
        --location=us-central1
    

    El siguiente ejemplo de salida se ha truncado para que sea más fácil de leer:

    annotations:
      ...
      baremetal.cluster.gke.io/version: 1.33
    ...
    name: projects/example-project-12345/locations/us-central1/bareMetalClusters/abm-user-cluster1/bareMetalNodePools/node-pool-1
    nodePoolConfig:
      nodeConfigs:
      - nodeIp: 192.0.2.1
      - nodeIp: 192.0.2.2
      operatingSystem: LINUX
    state: RUNNING
    ...
    

    En el ejemplo de salida, ten en cuenta lo siguiente:

    • El campo name contiene el nombre completo del grupo de nodos. Cuando especifiques el nombre del grupo de nodos en un comando, puedes indicar el nombre completo o el nombre del grupo de nodos, por ejemplo, node-pool-1, junto con las marcas --cluster, --project y --location.

    • La sección nodeConfigs contiene dos campos nodeIp con las direcciones IP de los nodos.

  4. Ejecuta el siguiente comando para quitar el nodo con la dirección IP 192.0.2.1:

    gcloud container bare-metal node-pools update node-pool-1 \
        --cluster=abm-user-cluster1 \
        --project=example-project-12345 \
        --location=us-central1 \
        --node-configs='node-ip=192.0.2.2'
    

    El comando update sustituye todas las direcciones IP por las que especifiques. Como 192.0.2.1 no está incluida, el nodo se elimina.

    El resultado del comando es similar al siguiente:

    Waiting for operation [projects/example-project-12345/locations/us-central1/operations/operation-1697154681749-6078d9def4030-76686d6e-9fcb1de9] to complete
    

    En el resultado de ejemplo, la cadena operation-1697154681749-6078d9def4030-76686d6e-9fcb1de9 es el OPERATION_ID de la operación de larga duración. Para consultar el estado de la operación, ejecuta el siguiente comando en otra ventana de terminal:

    gcloud container bare-metal operations describe operation-1697154681749-6078d9def4030-76686d6e-9fcb1de9 \
        --project= example-project-12345 \
        --location=us-central1
    

    Puedes volver a ejecutar el comando de vez en cuando para comprobar el estado.

Si no se puede quitar el nodo, puedes forzar su eliminación del clúster. Para obtener más información, consulta el artículo Restablecer un nodo fallido en Google Distributed Cloud.

Sustituir nodos del plano de control de alta disponibilidad

bmctl

Puedes usar bmctl para sustituir los nodos del plano de control de alta disponibilidad en todos los tipos de clústeres.

Para sustituir un nodo de un clúster, sigue estos pasos:

  1. Quita la dirección IP del nodo del archivo de configuración del clúster.
  2. Actualiza el clúster.
  3. Comprueba el estado de los nodos del clúster.
  4. Añade la dirección IP del nuevo nodo al mismo archivo de configuración del clúster.
  5. Actualiza el clúster.

Ejemplo: sustituir un nodo del plano de control de alta disponibilidad

Este es un archivo de configuración de clúster de ejemplo que muestra tres nodos del plano de control en un clúster de usuario:

---
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
name: user-cluster
namespace: cluster-user-cluster
spec:
  controlPlane:
  nodePoolSpec:
    nodes:
    - address: 192.0.2.11
    - address: 192.0.2.12
    - address: 192.0.2.13

Para sustituir el último nodo que aparece en la sección spec.controlPlane.nodePoolSpec.nodes, sigue estos pasos:

  1. Elimina el nodo suprimiendo su entrada de dirección IP en el archivo de configuración del clúster. Después de hacer este cambio, el archivo de configuración del clúster debería tener un aspecto similar a este:

    ---
    apiVersion: baremetal.cluster.gke.io/v1
    kind: Cluster
    metadata:
    name: user-cluster
    namespace: cluster-user-cluster
    spec:
      controlPlane:
      nodePoolSpec:
        nodes:
        - address: 192.0.2.11
        - address: 192.0.2.12
    
  2. Para actualizar el clúster, ejecuta el siguiente comando:

    bmctl update cluster -c CLUSTER_NAME \
      --kubeconfig=KUBECONFIG
    

    Haz los siguientes cambios:

    • Sustituye CLUSTER_NAME por el nombre del clúster que quieras actualizar.
    • Si el clúster es un clúster autogestionado (como un clúster de administrador o independiente), sustituye KUBECONFIG por la ruta al archivo kubeconfig del clúster. Si el clúster es un clúster de usuarios, como en este ejemplo, sustituye KUBECONFIG por la ruta del archivo kubeconfig del clúster de administrador.
  3. Una vez que se haya ejecutado correctamente el comando bmctl update, se tardará un tiempo en completar los trabajos machine-preflight y machine-init. Para ver el estado de los nodos y sus respectivos grupos de nodos, ejecuta los comandos que se describen en la sección Verificar las actualizaciones de este documento. Cuando el pool de nodos y los nodos estén en estado Ready, puedes continuar con el siguiente paso.

  4. Añade un nuevo nodo de plano de control al grupo de nodos añadiendo la dirección IP del nuevo nodo de plano de control a la sección spec.controlPlane.nodePoolSpec.nodes del archivo de configuración del clúster. Después de hacer este cambio, el archivo de configuración del clúster debería tener un aspecto similar a este:

    ---
    apiVersion: baremetal.cluster.gke.io/v1
    kind: Cluster
    metadata:
    name: user-cluster
    namespace: cluster-user-cluster
    spec:
      controlPlane:
      nodePoolSpec:
        nodes:
        - address: 192.0.2.11
        - address: 192.0.2.12
        - address: 192.0.2.14
    
  5. Para actualizar el clúster, ejecuta el siguiente comando:

    bmctl update cluster -c CLUSTER_NAME \
      --kubeconfig=KUBECONFIG
    

CLI de gcloud

Puedes usar la CLI de gcloud para sustituir los nodos del plano de control de alta disponibilidad en clústeres de administrador y de usuario.

Para sustituir un nodo de un clúster, sigue estos pasos:

  1. Elimina la dirección IP del nodo ejecutando el comando update correspondiente:

    • Clúster de usuarios: gcloud container bare-metal clusters update
    • Clúster de administrador: gcloud container bare-metal admin-clusters update
  2. Comprueba el estado de la eliminación del nodo en el clúster ejecutando gcloud container bare-metal operations describe OPERATION_ID.

  3. Añade la dirección IP del nuevo nodo ejecutando el comando update correspondiente.

Ejemplo: sustituir un nodo del plano de control de alta disponibilidad

En esta sección se muestra cómo sustituir un plano de control de un clúster con datos de ejemplo. En los pasos siguientes también se incluyen otros comandos de gcloud CLI que pueden resultarte útiles.

  1. Ejecuta el comando list para enumerar todos los clústeres de usuario de un proyecto:Google Cloud

    gcloud container bare-metal clusters list \
        --project=example-project-12345 \
        --location=-
    

    Si define --location=-, se mostrarán todos los clústeres de todas las regiones. Si necesitas acotar la lista, define --location en una región específica.

    El resultado debería ser similar al siguiente:

    NAME                 LOCATION      VERSION   ADMIN_CLUSTER        STATE
    abm-user-cluster1a   us-central1   1.33      abm-admin-cluster1   RUNNING
    abm-user-cluster1b   europe-west1  1.33      abm-admin-cluster1   RUNNING
    
  2. Ejecuta el comando describe en el clúster:

    gcloud container bare-metal clusters describe abm-user-cluster1  \
        --project=example-project-12345 \
        --location=us-central1
    

    El ejemplo se ha acortado para facilitar la lectura:

    ...
    controlPlane:
      controlPlaneNodePoolConfig:
        nodePoolConfig:
          nodeConfigs:
          - nodeIp: 192.0.2.11
          - nodeIp: 192.0.2.12
          - nodeIp: 192.0.2.13
          operatingSystem: LINUX
    ...
    name: projects/example-project-1234567/locations/us-central1/bareMetalClusters/abm-user-cluster1a
    ...
    

    En el ejemplo de salida, ten en cuenta lo siguiente:

    • El campo name contiene el nombre completo del clúster. Cuando especifiques el nombre del clúster en un comando, puedes indicar el nombre completo o el nombre del clúster (por ejemplo, abm-user-cluster1a), junto con --project y --location flags.

    • La sección nodeConfigs contiene tres campos nodeIp con las direcciones IP de los nodos del plano de control.

  3. Elimina el nodo con la dirección IP 192.0.2.13:

    gcloud container bare-metal cluster update abm-user-cluster1a \
        --project=example-project-12345 \
        --location=us-central1 \
        --control-plane-node-configs 'node-ip=192.0.2.11'
        --control-plane-node-configs 'node-ip=192.0.2.12'
    

    El resultado del comando es similar al siguiente:

    Waiting for operation [projects/example-project-12345/locations/us-central1/operations/operation-1956154681749-6078d9def4030-76686d6e-9fcb1d7] to complete
    

    En el resultado de ejemplo, la cadena operation-1956154681749-6078d9def4030-76686d6e-9fcb1de7 es el OPERATION_ID de la operación de larga duración. Para consultar el estado de la operación, ejecuta el siguiente comando en otra ventana de terminal:

    gcloud container bare-metal operations describe operation-1956154681749-6078d9def4030-76686d6e-9fcb1de7 \
        --project= example-project-12345 \
        --location=us-central1
    

    Puedes volver a ejecutar el comando de vez en cuando para comprobar el estado.

  4. Añade el nuevo nodo con la dirección IP 192.0.2.14:

    gcloud container bare-metal cluster update abm-user-cluster1a \
        --project=example-project-12345 \
        --location=us-central1 \
        --control-plane-node-configs 'node-ip=192.0.2.11'
        --control-plane-node-configs 'node-ip=192.0.2.12'
        --control-plane-node-configs 'node-ip=192.0.2.14'
    

Verificar las actualizaciones

kubectl

Puedes ver el estado de los nodos y sus respectivos grupos de nodos con el comando kubectl get.

Por ejemplo, el siguiente comando muestra el estado de los grupos de nodos en el espacio de nombres del clúster cluster-my-cluster:

kubectl -n cluster-my-cluster get nodepools.baremetal.cluster.gke.io

El sistema devuelve resultados similares a los siguientes:

NAME                    READY   RECONCILING   STALLED   UNDERMAINTENANCE   UNKNOWN
cluster-my-cluster      3       0             0         0                  0
cluster-my-cluster-lb   2       0             0         0                  0
np1                     3       0             0         0                  0

Reconciling=1 significa que el paso de conciliación aún está en curso. Debes esperar a que el estado cambie a Reconciling=0.

También puedes comprobar el estado de los nodos de un clúster ejecutando el siguiente comando:

kubectl get nodes --kubeconfig=KUBECONFIG

CLI de gcloud

Como se ha descrito anteriormente, después de ejecutar un comando update, puedes consultar el estado de la operación con gcloud container bare-metal operations describe OPERATIONS_ID. El resultado del comando muestra el estado de los nodos. Por ejemplo:

  ...
  metrics:
  - intValue: '1'
    metric: NODES_RECONCILING
  - intValue: '2'
    metric: NODES_HEALTHY
  - intValue: '0'
    metric: NODES_FAILED
  - intValue: '0'
    metric: NODES_IN_MAINTENANCE
  - intValue: '3'
    metric: NODES_TOTAL
  stage: HEALTH_CHECK
...

Independientemente de la herramienta que uses para actualizar un grupo de nodos, puedes obtener el estado actual de un grupo de nodos ejecutando el comando describe aplicable, tal como se ha mostrado anteriormente.

Si necesitas más información sobre cómo diagnosticar tus clústeres, consulta el artículo Crear capturas para diagnosticar clústeres.

Grupos de direcciones del balanceador de carga

bmctl

La sección addressPools contiene campos para especificar los grupos de balanceo de carga de los balanceadores de carga agrupados de MetalLB y del protocolo de puerta de enlace de frontera (BGP). Puedes añadir más grupos de direcciones de balanceo de carga en cualquier momento, pero no puedes eliminar los grupos de direcciones que ya tengas. A partir de la versión 1.16.0 de Google Distributed Cloud, puedes modificar los valores de addressPools.avoidBuggyIPs y addressPools.manualAssign en cualquier momento.

addressPools:
- name: pool1
  addresses:
  - 198.51.100.0-198.51.100.4
  - 198.51.100.240/28
- name: pool2
  addresses:
  - 198.51.100.224/28

CLI de gcloud

Puedes añadir más grupos de direcciones de balanceo de carga en cualquier momento para los balanceadores de carga agrupados, pero no puedes eliminar ningún grupo de direcciones. La marca que especifiques en gcloud container bare-metal clusters update para añadir un grupo de direcciones depende del tipo de balanceador de carga agrupado:

  • MetalLB (capa 2): usa la marca --metal-lb-address-pools.
  • Protocolo de pasarela fronteriza (BGP): usa la marca --bgp-address-pools.

El valor de las marcas tiene el siguiente formato:

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

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

  • pool: el nombre que elijas para el grupo.

  • avoid-buggy-ips: si lo configuras como True, el controlador de gestión de direcciones IP (IPAM) no asignará direcciones IP que terminen en .0 o .255 a los servicios. De esta forma, se evita el problema de que los dispositivos de consumo con errores descarten por error el tráfico enviado a esas direcciones IP especiales. Si no se especifica ningún valor, se utiliza False de forma predeterminada. A partir de la versión 1.16.0 de Google Distributed Cloud, puedes modificar este valor en un pool de direcciones.

  • manual-assign: Si no quieres que el controlador de IPAM asigne automáticamente direcciones IP de este grupo a los servicios, define este valor como True. Después, un desarrollador puede crear un servicio de tipo LoadBalancer y especificar manualmente una de las direcciones del grupo. Si no se especifica, manual-assign se define como False. A partir de la versión 1.16.0 de Google Distributed Cloud, puedes modificar este valor en un pool de direcciones.

  • En la lista de addresses, cada dirección debe ser un intervalo en formato CIDR o en formato de intervalo con guion. Para especificar una sola dirección IP en un pool (por ejemplo, para la IP virtual de entrada), usa /32 en la notación CIDR (por ejemplo, 192.0.2.1/32).

Ten en cuenta las siguientes reglas de sintaxis:

  • Escribe todo el valor entre comillas simples.
  • No se permiten espacios.
  • Separe cada intervalo de direcciones IP con un punto y coma.

Puedes especificar más de una instancia de la marca, como se muestra en el siguiente ejemplo:

--metal-lb-address-pools='pool=pool2,avoid-buggy-ips=False,manual-assign=True,addresses=198.51.100.0/30;198.51.100.64-198.51.100.72'
--metal-lb-address-pools='pool=pool3,avoid-buggy-ips=True,manual-assign=True,addresses=203.0.113.0/28'

Para obtener más información sobre los grupos de direcciones de balanceadores de carga, consulta loadBalancer.addressPools en Configurar el balanceo de carga agrupado.

Evitar la eliminación inadvertida de clústeres

bmctl

Si añade la anotación baremetal.cluster.gke.io/prevent-deletion: "true" al archivo de configuración del clúster, no podrá eliminar el clúster. Por ejemplo, si ejecutas kubectl delete cluster o bmctl reset cluster, se produce un error.

apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: ci-10c3c6f4d9c698e
  namespace: cluster-ci-10c3c6f4d9c698e
  annotations:
    baremetal.cluster.gke.io/prevent-deletion: "true"
spec:
  clusterNetwork:

CLI de gcloud

Si especifica la marca --add-annotations con el valor baremetal.cluster.gke.io/prevent-deletion="true", no podrá eliminar el clúster. Por ejemplo:

  1. Añade la anotación para evitar que se elimine el clúster por error:

    gcloud container bare-metal clusters update abm-user-cluster1a \
        --project=example-project-12345 \
        --location=us-central1 \
        --add-annotations=baremetal.cluster.gke.io/prevent-deletion="true"
    
  2. Intenta eliminar el clúster de usuarios:

    gcloud container bare-metal clusters delete abm-user-cluster1a \
        --project=example-project-12345 \
        --location=us-central1 \
        --force \
        --allow-missing
    

    La respuesta del comando es similar a la siguiente:

    ERROR: (gcloud.container.bare-metal.clusters.delete) INVALID_ARGUMENT:
    invalid request: admission webhook "vcluster.kb.io" denied the request:
    annotations[baremetal.cluster.gke.io/prevent-deletion]: Invalid value:
    "true": Annotation "baremetal.cluster.gke.io/prevent-deletion" should be
    removed in order to delete this cluster
    

    Para quitar la anotación, especifica --remove-annotations=baremetal.cluster.gke.io/prevent-deletion="true" en el comando update.

Omitir comprobaciones preparatorias

Esta función solo está disponible con bmctl update.

El valor predeterminado del campo bypassPreflightCheck es false. Si asignas el valor true a este campo en el archivo de configuración del clúster, se ignorarán las comprobaciones internas previas al lanzamiento cuando apliques recursos a clústeres ya creados.

  apiVersion: baremetal.cluster.gke.io/v1
  kind: Cluster
  metadata:
    name: cluster1
    namespace: cluster-cluster1
    annotations:
      baremetal.cluster.gke.io/private-mode: "true"
  spec:
    bypassPreflightCheck: true

Añadir o quitar administradores de clústeres

bmctl

Para añadir o quitar un usuario o una cuenta de servicio como administrador de un clúster de usuarios, especifica las direcciones de correo en la sección clusterSecurity.authorization.clusterAdmin.gcpAccounts del archivo de configuración del clúster. A las cuentas se les asigna el rol cluster-admin en el clúster, lo que les proporciona acceso completo a él.

apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: cluster1
  namespace: cluster-cluster1
spec:
  clusterSecurity:
    authorization:
      clusterAdmin:
        gcpAccounts:
        - alex@example.com
        - hao@example.com
        - my-sa@example-project-12345.iam.gserviceaccount.com

Cuando actualices un clúster de usuarios para añadir una cuenta, asegúrate de incluir todas las cuentas en la lista (tanto las que ya están como las nuevas), ya que bmctl update sobrescribe la lista con lo que especifiques en el archivo de configuración. Para eliminar una cuenta, quítala del archivo de configuración del clúster y ejecuta bmctl update.

CLI de gcloud

Para añadir o quitar un usuario o una cuenta de servicio como administrador de un clúster, especifica una dirección de correo en la marca --admin-users. La marca solo acepta una dirección de correo. Para añadir varios usuarios, especifica una cuenta en cada marca. Por ejemplo:

gcloud container bare-metal clusters update abm-user-cluster1a \
    --project=example-project-12345 \
    --location=us-central1 \
    --admin-users=alex@example.com \
    --admin-users=hao@example.com
    --admin-users=my-sa@example-project-12345.iam.gserviceaccount.com

El comando update sobrescribe toda la lista de concesiones. Especifica todos los usuarios actuales y nuevos que quieras que sean administradores del clúster.

Definir un usuario de inicio de sesión

Puedes especificar un nombre de usuario que no sea root para usarlo en el acceso a la capacidad sudo sin contraseña a las máquinas de nodo de tu clúster. Tu clave SSH, sshPrivateKeyPath, debe funcionar para el usuario especificado. Las operaciones de creación y actualización de clústeres comprueban que se pueda acceder a las máquinas de los nodos con el usuario y la clave SSH especificados.

bmctl

apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: cluster1
  namespace: cluster-cluster1
  annotations:
    baremetal.cluster.gke.io/private-mode: "true"
spec:
  nodeAccess:
    loginUser: abm

CLI de gcloud

Especifica el usuario que quieres usar para acceder a las máquinas de nodos en la marca --login-user, por ejemplo:

gcloud container bare-metal clusters update abm-user-cluster1a \
    --project=example-project-12345 \
    --location=us-central1 \
    --login-user=abm

Para habilitar el acceso sin contraseña sudo para un usuario, sigue estos pasos en cada máquina de nodo de clúster:

  1. Usa sudo visudo para abrir el archivo sudoers y editarlo:

    sudo visudo -f /etc/sudoers
    

    El comando visudo bloquea el archivo sudoers para evitar que se edite simultáneamente y valida la sintaxis del archivo al guardarlo.

  2. Añade una entrada al archivo sudoers para el usuario de inicio de sesión, como la siguiente:

    USERNAME ALL=(ALL) NOPASSWD: ALL
    
  3. Guarda el archivo y ciérralo.

  4. Para ejecutar comandos con los privilegios de tu usuario de inicio de sesión, ejecuta el siguiente comando:

    su - USERNAME
    
  5. Para comprobar que no se necesita una contraseña para que tu usuario de inicio de sesión ejecute comandos de sudo, ejecuta el siguiente comando de sudo:

    sudo ip a
    

Ajustes de red avanzados

Puede configurar funciones de redes avanzadas en varios recursos personalizados después de crear el clúster. Para usar los recursos personalizados y las funciones de red relacionadas, debes habilitar la red avanzada al crear el clúster.

bmctl

Asigna el valor true a clusterNetwork.advancedNetworking en la configuración del clúster al crearlo:

apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: cluster1
  namespace: cluster-cluster1
spec:
  clusterNetwork:
    ...
    advancedNetworking: true
    ...

CLI de gcloud

Incluye la marca --enable-advanced-networking en el comando gcloud container bare-metal clusters create al crear el clúster.

Una vez que se haya creado el clúster con la opción de redes avanzadas habilitada, puedes configurar los recursos personalizados descritos en esta sección mediante kubectl apply.

NetworkGatewayGroup

El recurso personalizado NetworkGatewayGroup se usa para proporcionar direcciones IP flotantes para funciones de redes avanzadas, como la puerta de enlace NAT de salida o la función de balanceo de carga agrupada con BGP.

apiVersion: networking.gke.io/v1
kind: NetworkGatewayGroup
  name: default
  namespace: cluster-bm
spec:
  floatingIPs:
  - 10.0.1.100
  - 10.0.2.100

Balanceo de carga de BGP

El balanceo de carga del protocolo de puerta de enlace de frontera (BGP) se configura en el recurso de clúster y en otros recursos personalizados. Los comandos gcloud container bare-metal clusters create y update permiten configurar BGP en el recurso de clúster, pero no en los recursos personalizados.

Cuando configuras balanceadores de carga agrupados con BGP, el balanceo de carga del plano de datos usa, de forma predeterminada, los mismos peers externos que se especificaron para el peering del plano de control. También puedes configurar el balanceo de carga del plano de datos por separado mediante el recurso personalizado BGPLoadBalancer y el recurso personalizado BGPPeer. Para obtener más información, consulta el artículo sobre cómo configurar balanceadores de carga agrupados con BGP.

BGPLoadBalancer

apiVersion: networking.gke.io/v1
kind: BGPLoadBalancer
metadata:
  name: default
  namespace: cluster-bm
spec:
  peerSelector:
    cluster.baremetal.gke.io/default-peer: "true"

BGPPeer

apiVersion: networking.gke.io/v1
kind: BGPPeer
metadata:
  name: bgppeer1
  namespace: cluster-bm
  labels:
    cluster.baremetal.gke.io/default-peer: "true"
spec:
  localASN: 65001
  peerASN: 65002
  peerIP: 10.0.3.254
  sessions: 2

Aumentar la cobertura de la red de servicio

Para crear más servicios que el límite inicial, puedes reducir la máscara CIDR del servicio IPv4 para aumentar la red de servicios de tu clúster. Si se reduce la máscara (el valor que va después de "/"), el intervalo de la red será mayor. Solo puedes aumentar el intervalo de CIDR del servicio IPv4. El intervalo de red no se puede reducir, lo que significa que la máscara (el valor que va después de "/") no se puede aumentar.

bmctl

apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: cluster1
  namespace: cluster-cluster1
spec:
  ...
  clusterNetwork:
    services:
      cidrBlocks:
        - 192.0.2.0/14
  ...

CLI de gcloud

Para aumentar el intervalo de CIDR del servicio IPv4 en un clúster de usuario, especifica el nuevo intervalo en la marca --island-mode-service-address-cidr-blocks.

gcloud container bare-metal clusters update cluster1 \
    --project=example-project-12345 \
    --location=us-central1 \
    --island-mode-service-address-cidr-blocks=192.0.2.0/14

Configurar los ajustes de extracción de imágenes de kubelet

Kubelet se ejecuta en cada nodo de tu clúster. Kubelet se encarga de monitorizar los contenedores de un nodo y de asegurarse de que estén en buen estado. Cuando es necesario, el kubelet consulta y extrae imágenes de Artifact Registry.

Actualizar manualmente las configuraciones de kubelet y mantenerlas sincronizadas en todos los nodos del clúster puede ser complicado. Para empeorar las cosas, los cambios manuales en la configuración de kubelet de tus nodos se pierden al actualizar el clúster.

Para que las actualizaciones sincronizadas sean más fáciles y persistentes, Google Distributed Cloud te permite especificar algunos ajustes de kubelet para cada uno de los grupos de nodos de tu clúster: nodos del plano de control, nodos del balanceador de carga y nodos de trabajador. Los ajustes se aplican a todos los nodos de un grupo determinado y se conservan durante las actualizaciones del clúster. Los campos de estos ajustes son mutables, por lo que puedes actualizarlos en cualquier momento, no solo durante la creación del clúster.

bmctl

Los siguientes campos admitidos controlan las operaciones de extracción de Artifact Registry para kubelet:

  • registryBurst (valor predeterminado: 10)
  • registryPullQPS (predeterminado: 5)
  • serializeImagePulls (valor predeterminado: true)

Para obtener más información sobre cada uno de los campos de configuración de kubelet, consulta la referencia de los campos de configuración de clústeres.

Puede especificar estos campos en las secciones kubeletConfig de la especificación de clúster y de la especificación de NodePool para los siguientes grupos de nodos:

En el ejemplo siguiente se muestran los campos añadidos con sus valores predeterminados en el archivo de configuración del clúster. Ten en cuenta que la anotación preview.baremetal.cluster.gke.io/custom-kubelet: "enable" es obligatoria.

apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: cluster1
  namespace: cluster-cluster1
  annotations:
    preview.baremetal.cluster.gke.io/custom-kubelet: "enable"
spec:
  ...
  controlPlane:
    nodePoolSpec:
      kubeletConfig:
        registryBurst: 10
        registryPullQPS: 5
        serializeImagePulls: true
  ...
  loadBalancer:
    nodePoolSpec:
      kubeletConfig:
        registryBurst: 10
        registryPullQPS: 5
        serializeImagePulls: true
  ...
apiVersion: baremetal.cluster.gke.io/v1
kind: NodePool
metadata:
  name: node-pool-new
  namespace: cluster-cluster1
spec:
  clusterName: cluster1
  ...
  kubeletConfig:
    registryBurst: 10
    registryPullQPS: 5
    serializeImagePulls: true

En ambos casos, la opción se aplica a todos los nodos del grupo.

CLI de gcloud

Las siguientes marcas controlan las operaciones de extracción de Artifact Registry para kubelet:

Cómo se puede utilizar

A continuación, se indican algunos aspectos que debes tener en cuenta para optimizar las extracciones de imágenes:

  • Como las imágenes se extraen en serie de forma predeterminada, una extracción de imágenes que tarde mucho tiempo puede retrasar todas las demás extracciones de imágenes programadas en un nodo. Las extracciones de imágenes retrasadas pueden bloquear el proceso de actualización (sobre todo cuando se deben desplegar imágenes nuevas de Google Distributed Cloud en un nodo). Si te afectan los retrasos en la extracción de imágenes, puedes inhabilitar la serialización de la extracción de imágenes para permitir la extracción de imágenes en paralelo.

  • Si se producen errores de limitación de la extracción de imágenes, como pull QPS exceeded, puede aumentar *-registry-pull-qps y *-registry-burst para aumentar el rendimiento de la extracción de imágenes. Estos dos campos ajustan la tasa de extracción y el tamaño de la cola, y pueden ayudar a solucionar otros problemas relacionados con la limitación. No se permiten valores negativos.

Personalización de Keepalived

A partir de la versión 1.32, Google Distributed Cloud ofrece algunas opciones de personalización de la configuración de Keepalived. Con el balanceo de carga agrupado, el balanceador de carga del plano de control sirve la dirección IP virtual (VIP) del plano de control. Google Distributed Cloud ejecuta Keepalived y HAProxy como pods estáticos de Kubernetes en los nodos del balanceador de carga para anunciar el VIP del plano de control. Keepalived usa el protocolo Virtual Router Redundancy Protocol (VRRP) en los nodos del balanceador de carga para ofrecer alta disponibilidad.

Los clústeres de la versión 1.32 y posteriores tienen las siguientes personalizaciones de Keepalived:

  • En los planos de control de alta disponibilidad, Google Distributed Cloud configura automáticamente la configuración de VRRP de Keepalived para que el comportamiento de conmutación por error sea determinista y evitar que se intercalen respuestas ARP con diferentes direcciones MAC:

    • Cada instancia de Keepalived se configura automáticamente con un valor de priority diferente en el router VRRP.

    • Cada instancia de Keepalived se configura automáticamente con nopreempt para evitar elecciones cuando se reinicia una instancia que no es maestra.

  • Google Distributed Cloud te permite especificar el número de mensajes ARP gratuitos (GARP) que se enviarán a la vez después de que un nodo del plano de control pase a ser el servidor principal. Para cambiar el número de mensajes GARP que se van a enviar, añade el campo controlPlane.loadBalancer.keepalivedVRRPGARPMasterRepeat al archivo de configuración del clúster, asigna el nuevo valor y actualiza el clúster. Este valor se asigna al ajuste vrrp_garp_master_repeat de Keepalived. El valor predeterminado es 5.

    En el ejemplo siguiente se muestra cómo especificar keepalivedVRRPGARPMasterRepeat en el archivo de configuración del clúster:

    apiVersion: baremetal.cluster.gke.io/v1
    kind: Cluster
    metadata:
      name: hybrid-ha-lb
      namespace: cluster-hybrid-ha-lb
    spec:
      type: hybrid
      profile: default
      anthosBareMetalVersion: 1.33
      gkeConnect:
        projectID: project-fleet
      controlPlane:
        loadBalancer:
          keepalivedVRRPGARPMasterRepeat: 1
        nodePoolSpec:
          nodes:
          - address: 10.200.0.2
          - address: 10.200.0.3
          - address: 10.200.0.4
      ...
    

Instalar o desinstalar el operador de GPU NVIDIA incluido

El operador de GPU de NVIDIA te permite ejecutar cargas de trabajo relacionadas con la GPU en tus clústeres. A partir de la versión 1.33.0 de Google Distributed Cloud, los clústeres se incluyen con una pila completa del operador de GPU NVIDIA para proporcionar una solución gestionada para controlar los componentes de software de NVIDIA necesarios para aprovisionar GPUs en los nodos de trabajo de tu clúster.

Requisitos previos

Antes de instalar el operador de GPU NVIDIA incluido, asegúrate de que tu entorno cumpla los siguientes requisitos:

  • Clúster operativo: has creado un clúster de hardware desnudo funcional con Google Distributed Cloud.

  • GPUs NVIDIA: las GPUs NVIDIA están instaladas en los nodos de trabajo del clúster. En la siguiente sección sobre cómo instalar el operador de GPU NVIDIA se incluyen los pasos para verificar que las GPUs se han instalado correctamente y que el sistema operativo las reconoce.

  • Versión compatible del controlador de NVIDIA: la versión del controlador de NVIDIA que utilices debe ser compatible con tu GPU, tu sistema operativo y la versión de CUDA que usen tus aplicaciones. Para obtener más información, consulta Información sobre la versión.

    Tienes las siguientes opciones de instalación de controladores de NVIDIA:

    El controlador de la GPU NVIDIA debe estar instalado y listo antes de habilitar el operador de GPU NVIDIA incluido.

Información de la versión

Esta sección contiene información sobre la versión del software del operador de GPU de NVIDIA incluido.

Versiones de componentes de software

La versión 1.33 de Google Distributed Cloud incluye la versión 25.3.1 del operador de GPU de NVIDIA. En Google Distributed Cloud, el paquete contiene las siguientes imágenes:

  • Versión v1.17.8 del kit de herramientas de contenedor de NVIDIA
  • NVIDIA DCGM Exporter v3.3.9-3.6.1
  • NVIDIA Kubernetes Device Plugin v0.17.1
  • Node Feature Discovery v0.17.2

Es posible que las versiones de imagen incluidas en la versión 1.33 de Google Distributed Cloud no coincidan exactamente con las versiones de los componentes de software que se indican en las notas de la versión 25.3.1.

Compatibilidad de controladores

Consulta la compatibilidad de plataformas con la versión 25.3.1 en el centro de documentación de NVIDIA para obtener información sobre la compatibilidad de los controladores.

Actualizar el operador de GPU NVIDIA incluido

Si has instalado NVIDIA GPU Operator en tu clúster, al actualizar a una nueva versión secundaria, se instalará la versión más reciente de NVIDIA GPU Operator.

Instalar el operador incluido

Mientras la versión preliminar del operador de GPU NVIDIA incluido esté disponible, puedes instalarlo con bmctl update para añadir la siguiente anotación al clúster que tenga nodos de GPU:

apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: cluster1
  namespace: cluster-cluster1
  annotations:
    preview.baremetal.cluster.gke.io/nvidia-gpu-operator: "enable"
spec:
  ...

La pila del operador de GPU NVIDIA se instala en el clúster cuando se aplica la anotación.

Desinstalar el operador incluido

Mientras el operador de GPU NVIDIA incluido esté en versión preliminar, puedes desinstalarlo con bmctl update para quitar la siguiente anotación del clúster que tenga nodos de GPU:

preview.baremetal.cluster.gke.io/nvidia-gpu-operator: "enable"

Todos los componentes de la pila del operador de GPU de NVIDIA se eliminan del clúster cuando se quita la anotación.

Habilitar la asignación dinámica de recursos

La asignación dinámica de recursos es una API de Kubernetes que te permite solicitar y compartir recursos genéricos, como GPUs, entre pods y contenedores. Los controladores de terceros gestionan estos recursos. Esta función te ayuda a ejecutar cargas de trabajo de IA asignando de forma dinámica y precisa los recursos de GPU de tus clústeres de hardware desnudo, lo que mejora el uso de los recursos y el rendimiento de las cargas de trabajo exigentes.

La asignación dinámica de recursos está disponible en versión preliminar para clústeres con la versión 1.33 o posterior. En las siguientes instrucciones se describe cómo configurar el clúster para usar la asignación dinámica de recursos. Una vez habilitada, puedes configurar tus cargas de trabajo de GPU para que usen la asignación dinámica de recursos.

Configura tu clúster para habilitar la asignación dinámica de recursos:

  1. Edita el archivo de configuración del clúster para incluir la preview.baremetal.cluster.gke.io/dynamic-resource-allocation: "enable" anotación de vista previa y añade DynamicResourceAllocation: true en featureGates en la sección kubeletConfig:

    apiVersion: baremetal.cluster.gke.io/v1
    kind: Cluster
    metadata:
      name: dra
      namespace: cluster-dra
      annotations:
        preview.baremetal.cluster.gke.io/dynamic-resource-allocation: "enable"
    spec:
      controlPlane:
        nodePoolSpec:
          kubeletConfig:
            featureGates:
              DynamicResourceAllocation: true
    # ... other cluster configuration
    
  2. Para actualizar el clúster, ejecuta el comando bmctl update:

    bmctl update cluster -c CLUSTER_NAME \
        --kubeconfig=ADMIN_KUBECONFIG
    

    Haz los cambios siguientes:

    • CLUSTER_NAME: el nombre del clúster de usuarios que vas a actualizar.

    • ADMIN_KUBECONFIG: la ruta del archivo kubeconfig del clúster de administrador.

    Después de aplicar esta configuración, el campo READY de tus máquinas físicas puede cambiar entre True y False varias veces. Espera a que el campo READY se estabilice en True antes de continuar.

  3. Para habilitar el feature gate DynamicResourceAllocation en grupos de nodos que tengan nodos con GPUs, asigna el valor true a DynamicResourceAllocation en la sección featureGates de la sección kubeletConfig de la especificación NodePool:

    Para obtener instrucciones sobre cómo añadir y actualizar un grupo de nodos, consulta Gestionar grupos de nodos en un clúster.

    apiVersion: baremetal.cluster.gke.io/v1
    kind: NodePool
    metadata:
      name: np
      namespace: cluster-dra
    spec:
      clusterName: dra
      kubeletConfig:
        featureGates:
          DynamicResourceAllocation: true
      nodes:
    # ... other node pool configuration
    

    Después de añadir o actualizar el grupo de nodos, espera a que todas las máquinas físicas del grupo alcancen el estado Ready.

  4. Para comprobar el estado de las máquinas físicas de tu clúster, usa el siguiente comando:

    kubectl get baremetalmachines --kubeconfig ADMIN_KUBECONFIG -A
    

    Cuando las máquinas físicas estén listas, la respuesta debería ser similar a la siguiente:

    NAMESPACE          NAME         CLUSTER    READY   INSTANCEID               MACHINE      ABM VERSION        DESIRED ABM VERSION
    cluster-admin      10.200.0.2   dra        true    baremetal://10.200.0.2   10.200.0.2    1.33.0-gke.793   1.33.0-gke.793
    cluster-user-dra   10.200.0.6   user-dra   true    baremetal://10.200.0.6   10.200.0.6    1.33.0-gke.793   1.33.0-gke.793
    cluster-user-dra   10.200.0.7   user-dra   true    baremetal://10.200.0.7   10.200.0.7    1.33.0-gke.793   1.33.0-gke.793
    cluster-user-dra   10.200.0.8   user-dra   true    baremetal://10.200.0.8   10.200.0.8    1.33.0-gke.793   1.33.0-gke.793
    

Limitaciones

El operador de GPU NVIDIA incluido tiene las siguientes limitaciones:

  • El operador de GPU NVIDIA incluido solo admite los siguientes componentes de software de NVIDIA:

    • Kit de herramientas de contenedor de NVIDIA
    • Exportador de DCGM de NVIDIA
    • Complemento de dispositivo Kubernetes de NVIDIA
    • Gestor de MIG de NVIDIA para Kubernetes.
  • Durante la vista previa, la configuración del operador de GPU de NVIDIA es fija. Si intentas personalizar algún ajuste, se restaurará la configuración original.

  • El operador de GPU NVIDIA incluido no se puede usar para instalar controladores de GPU NVIDIA.

  • Durante la vista previa, esta función usa el grupo de APIs resource.k8s.io/v1beta1, que es diferente del grupo de APIs de Kubernetes de código abierto para esta función, resource.k8s.io/v1. El grupo de APIs de código abierto v1 ofrece más funciones y una mayor estabilidad que el grupo de APIs v1beta1.

Siguientes pasos

Documentación de referencia