Se usó la API de Cloud Translation para traducir esta página.

Actualiza clústeres

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

Agregar, quitar o reemplazar nodos
Agregar anotaciones al clúster o quitarlas.
Modificar los valores de los campos mutables en los recursos del clúster y del grupo de nodos.
Modificar otros recursos personalizados.

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

Muchos aspectos de la configuración del clúster son inmutables y no se pueden actualizar después de crear el clúster. Para obtener una lista completa de los campos inmutables y mutables, consulta la referencia del campo de configuración del clúster. La referencia del campo es una tabla ordenable. Haz clic en los encabezados de las columnas para cambiar el orden de clasificación. Haz clic en el nombre de un campo para ver su descripción.
gcloud CLI y Terraform solo admiten la actualización de clústeres de administrador y de usuario. Debes usar bmctl para actualizar otros tipos de clústeres.
gcloud CLI y Terraform solo admiten cambios en los recursos del clúster y del grupo de nodos. Debes usar kubectl o bmctl para actualizar otros recursos personalizados que afecten al clúster.

Modificar el espacio de nombres de un clúster existente en el archivo de configuración del clúster es not a supported operation y puede provocar inestabilidad en el clúster y posibles fallas. Para evitar estos problemas, no intentes modificar el espacio de nombres del clúster después de su creación.

Esta página está destinada a administradores, arquitectos y operadores que administran el ciclo de vida de la infraestructura tecnológica subyacente. 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 de usuario y tareas comunes de GKE Enterprise.

Cómo actualizar clústeres

Por lo general, debes seguir esta secuencia de acciones para actualizar un clúster:

`bmctl`

Cambia los valores de los campos aplicables en el archivo de configuración del clúster, que, de forma predeterminada, se encuentra aquí:
bmctl-workspace/CLUSTER-NAME/CLUSTER-NAME.yaml
Actualiza el clúster ejecutando el comando bmctl update:
```
bmctl update cluster -c CLUSTER_NAME --kubeconfig=KUBECONFIG
```
Reemplaza lo siguiente:
- CLUSTER_NAME: Es el nombre del clúster que deseas actualizar.
- KUBECONFIG: Para los clústeres de administrador, híbridos o independientes, ingresa la ruta de acceso al archivo kubeconfig del clúster. Para un clúster de usuario, ingresa la ruta de acceso al archivo kubeconfig del clúster de administrador.

No uses bmctl update y kubectl apply -f de forma indistinta cuando edites el archivo de configuración del clúster. Cuando estos comandos se usan de forma indistinta, es posible que se quite sin querer el contenido propagado por el encabezado de la especificación del clúster. Por ejemplo, puedes usar bmctl update para actualizar el archivo de configuración del clúster para configurar una duplicación de registro. Luego, el clúster tiene spec.nodeConfig.registryMirrors propagado después de la conciliación.

Si, luego, intentas realizar cambios en el clúster con la configuración del clúster con el comando kubectl apply -f, se quitará el spec.nodeConfig.registryMirrors propagado por el agente de conciliación en el clúster. Este comportamiento se produce porque la configuración no existe en la especificación de configuración del clúster, pero sí en el clúster.

gcloud CLI

Especifica solo las marcas de la configuración que deseas modificar.
Ejecuta el comando de actualización correspondiente:
- Clústeres de administrador: gcloud container bare-metal admin-clusters update
- Clústeres de usuarios: gcloud container bare-metal clusters update.
- Grupos de nodos en un clúster de usuario: gcloud container bare-metal node-pools update

Terraform

Cambia los valores de los campos correspondientes en el archivo de configuración de Terraform que usaste para crear el clúster o el grupo de nodos. Consulta la documentación de referencia de Terraform para obtener descripciones detalladas de los campos:
Actualiza la configuración ejecutando el comando terraform apply.

En las siguientes secciones, se describen algunos ejemplos comunes para actualizar un clúster existente.

Agrega o quita nodos en un clúster

Un grupo de nodos es un conjunto de nodos dentro de un clúster que tienen la misma configuración. Ten en cuenta que un nodo siempre pertenece a un grupo de nodos. Para agregar un nodo nuevo a un clúster, debes agregarlo a un grupo de nodos específico. Quitar un nodo de un grupo de nodos equivale a quitar el nodo del clúster por completo.

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

`bmctl`

Para agregar o quitar un nodo de un grupo de nodos, debes agregar 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 editar para un grupo de nodos determinado:

Grupo de nodos trabajadores: Agrega o quita la dirección IP del nodo en la sección spec.nodes de la especificación NodePool.
Grupo de nodos del plano de control: Agrega o quita la dirección IP del nodo en la sección spec.controlPlane.nodePoolSpec.nodes de la especificación Cluster.
Grupo de nodos del balanceador de cargas: Agrega o quita la dirección IP del nodo en la sección spec.loadBalancer.nodePoolSpec.nodes de la especificación Cluster.

Ejemplo: Quita un nodo 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, haz lo siguiente:

(Opcional) Si el nodo que quitas ejecuta Pods fundamentales, primero coloca el nodo en modo de mantenimiento.

Puedes supervisar el proceso de vaciado de nodos trabajadores si consultas los campos status.nodesDrained y status.nodesDraining en el recurso NodePool.
Edita el archivo de configuración del clúster para borrar la entrada de la dirección IP del nodo.

Actualiza el clúster:

bmctl update cluster1 \
    --kubeconfig=ADMIN_KUBECONFIG

gcloud CLI

Usas un comando update para agregar o quitar nodos. El comando update que uses y la marca en la que especifiques la dirección IP dependerán del tipo de grupo de nodos que quieras actualizar:

Grupo de nodos trabajadores: 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'.
Grupo de nodos del plano de control en un clúster de usuario: 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 cargas: 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 especificas la dirección IP solo acepta un node-ip. Debes incluir la marca para cada dirección IP del grupo de nodos.

Los comandos update reemplazan todas las direcciones IP por las que especifiques. Para agregar un nodo, incluye las direcciones IP de los nodos existentes y la dirección IP del nodo nuevo en el comando update. Del mismo modo, para quitar nodos, solo debes incluir las direcciones IP de los nodos que deseas conservar.

Ejemplo: Quita un nodo trabajador

En esta sección, se muestra cómo quitar un nodo trabajador de un grupo de nodos con datos de ejemplo. También se incluyen comandos adicionales de gcloud CLI que pueden resultarte útiles en los siguientes pasos.

(Opcional) Si el nodo que quitas ejecuta Pods fundamentales, primero coloca el nodo en modo de mantenimiento.

Puedes supervisar el proceso de vaciado de nodos trabajadores si consultas los campos status.nodesDrained y status.nodesDraining en el recurso NodePool.

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 es similar a este:

NAME         LOCATION     STATE
node-pool-1  us-central1  RUNNING
node-pool-2  asia-east1   RUNNING

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 resultado se trunca para facilitar la lectura:
```
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
...
```
Ten en cuenta lo siguiente en el resultado de ejemplo:
- El campo name contiene el nombre completamente calificado del grupo de nodos. Cuando especificas el nombre del grupo de nodos en un comando, puedes especificar el nombre completamente calificado 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.
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 reemplaza todas las direcciones IP por las que especifiques. Como no se incluye 192.0.2.1, se quita el nodo.

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 averiguar 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 cada cierto tiempo para verificar el estado.

Si falla la eliminación del nodo, puedes forzar su eliminación del clúster. Para obtener más detalles, consulta Restablece un nodo con errores en Google Distributed Cloud.

Reemplaza los nodos del plano de control de HA

`bmctl`

Puedes usar bmctl para reemplazar los nodos del plano de control de alta disponibilidad (HA) en todos los tipos de clústeres.

Para reemplazar un nodo en un clúster, realiza los siguientes pasos:

Quita la dirección IP del nodo del archivo de configuración del clúster.
Actualiza el clúster.
Verifica el estado de los nodos en el clúster.
Agrega la dirección IP de un nodo nuevo al mismo archivo de configuración del clúster.
Actualiza el clúster.

Ejemplo: Reemplaza un nodo del plano de control de HA

A continuación, se muestra 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 reemplazar el último nodo que aparece en la sección spec.controlPlane.nodePoolSpec.nodes, realiza los siguientes pasos:

Para quitar el nodo, borra su entrada de dirección IP en el archivo de configuración del clúster. Después de realizar este cambio, el archivo de configuración del clúster debería verse de la siguiente manera:

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

Actualiza el clúster ejecutando el siguiente comando:
```
bmctl update cluster -c CLUSTER_NAME \
  --kubeconfig=KUBECONFIG
```
Realiza los siguientes cambios:
- Reemplaza CLUSTER_NAME por el nombre del clúster que deseas actualizar.
- Si el clúster es autoadministrado (como un clúster independiente o de administrador), reemplaza KUBECONFIG por la ruta de acceso al archivo kubeconfig del clúster. Si el clúster es de usuario, como en este ejemplo, reemplaza KUBECONFIG por la ruta de acceso al archivo kubeconfig del clúster de administrador.
Una vez que el comando bmctl update se ejecute de forma correcta, los trabajos machine-preflight y machine-init tardarán un tiempo en completarse. Puedes ver el estado de los nodos y sus respectivos grupos de nodos ejecutando los comandos que se describen en la sección Verifica tus actualizaciones de este documento. Una vez que el grupo de nodos y los nodos estén en estado listo, puedes continuar con el siguiente paso.
Agrega un nodo del plano de control nuevo al grupo de nodos. Para ello, agrega la dirección IP del nodo del plano de control nuevo a la sección spec.controlPlane.nodePoolSpec.nodes del archivo de configuración del clúster. Después de realizar este cambio, el archivo de configuración del clúster debería verse de la siguiente manera:
```
---
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
```

Actualiza el clúster ejecutando el siguiente comando:

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

gcloud CLI

Puedes usar gcloud CLI para reemplazar los nodos del plano de control de alta disponibilidad (HA) en los clústeres de administrador y de usuario.

Para reemplazar un nodo en un clúster, realiza los siguientes pasos:

Quita la dirección IP del nodo ejecutando el comando update aplicable:
- Clúster de usuario: gcloud container bare-metal clusters update
- Clúster de administrador: gcloud container bare-metal admin-clusters update
Para verificar el estado de la eliminación del nodo en el clúster, ejecuta gcloud container bare-metal operations describe OPERATION_ID.
Ejecuta el comando update aplicable para agregar la dirección IP del nodo nuevo.

Ejemplo: Reemplaza un nodo del plano de control de HA

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

Ejecuta el comando list para enumerar todos los clústeres de usuarios en un proyectoGoogle Cloud :
```
gcloud container bare-metal clusters list \
    --project=example-project-12345 \
    --location=-
```
Cuando configuras --location=-, significa que se deben enumerar todos los clústeres en todas las regiones. Si necesitas reducir el alcance de la lista, configura --location en una región específica.

El resultado es similar a este:
```
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
```
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 resultado de ejemplo se trunca 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
...
```
Ten en cuenta lo siguiente en el resultado de ejemplo:
- El campo name contiene el nombre completamente calificado del clúster. Cuando especificas el nombre del clúster en un comando, puedes especificar el nombre completamente calificado o el nombre del clúster, por ejemplo, abm-user-cluster1a, junto con --project y las --location flags.
- La sección nodeConfigs contiene tres campos nodeIp con las direcciones IP de los nodos del plano de control.

Quita 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 averiguar 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 cada cierto tiempo para verificar el estado.

Agrega el nodo nuevo 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'

Verifica tus 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 muestra resultados similares al siguiente:

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 progreso. Debes esperar hasta que el estado cambie a Reconciling=0.

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

kubectl get nodes --kubeconfig=KUBECONFIG

gcloud CLI

Como se describió anteriormente, después de ejecutar un comando update, puedes verificar el estado de la operación con gcloud container bare-metal operations describe OPERATIONS_ID. El resultado del comando proporciona 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
...

Sin importar qué herramienta uses para actualizar un grupo de nodos, puedes obtener el estado actual de un grupo de nodos ejecutando el comando describe aplicable, como se mostró anteriormente.

Si necesitas más información para diagnosticar tus clústeres, consulta Crea instantáneas para diagnosticar clústeres.

Grupos de direcciones del balanceador de cargas

bmctl

La sección addressPools contiene campos para especificar grupos de balanceo de cargas para los balanceadores de cargas de MetalLB y del protocolo de puerta de enlace de frontera (BGP). Puedes agregar más grupos de direcciones de balanceo de cargas en cualquier momento, pero no puedes quitar ningún grupo de direcciones existente. 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

gcloud CLI

Puedes agregar más grupos de direcciones de balanceo de cargas en cualquier momento para los balanceadores de cargas agrupados, pero no puedes quitar ningún grupo de direcciones existente. La marca que especificas en gcloud container bare-metal clusters update para agregar un grupo de direcciones depende del tipo de balanceador de cargas en paquete:

MetalLB (capa 2): Usa la marca --metal-lb-address-pools.
Protocolo de puerta de enlace de frontera (BGP): Usa la marca --bgp-address-pools.

Los valores de las marcas tienen el siguiente formato:

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

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

pool: Un nombre de tu elección para el grupo de nodos.
avoid-buggy-ips: Si configuras este parámetro como True, el controlador de administración de direcciones IP (IPAM) no asignará direcciones IP que terminen en .0 o .255 a los Services. Esto evita el problema de los dispositivos consumidores con errores que descartan por error el tráfico enviado a esas direcciones IP especiales. Si no se especifica, el valor predeterminado es False. A partir de la versión 1.16.0 de Google Distributed Cloud, puedes modificar este valor en un grupo de direcciones existente.
manual-assign: Si no quieres que el controlador de IPAM asigne de forma automática direcciones IP de este grupo a objetos Service, configura esto como True. Luego, un desarrollador puede crear un objeto 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. A partir de la versión 1.16.0 de Google Distributed Cloud, puedes modificar este valor en un grupo de direcciones existente.
En la lista de addresses: Cada dirección debe ser un rango en formato CIDR o con guiones. Para especificar una sola dirección IP en un grupo (por ejemplo, para la VIP de entrada), usa /32 en la notación CIDR (por ejemplo, 192.0.2.1/32).

Ten en cuenta las siguientes reglas de sintaxis:

Encierra todo el valor entre comillas simples.
No se permiten espacios en blanco.
Separa cada rango de direcciones IP con un punto y coma.

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

--metal-lb-address-pools='pool=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 del balanceador de cargas, consulta loadBalancer.addressPools en Configura el balanceo de cargas en paquetes.

Evita la eliminación accidental del clúster

`bmctl`

Si agregas la anotación baremetal.cluster.gke.io/prevent-deletion: "true" al archivo de configuración del clúster, no podrás borrarlo. Por ejemplo, ejecutar kubectl delete cluster o bmctl reset cluster 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:

gcloud CLI

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

Agrega la anotación para evitar la eliminación accidental del clúster:

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"

Intenta borrar 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.

Omite las comprobaciones preliminares

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

El valor predeterminado del campo bypassPreflightCheck es false. Si estableces este campo en true en el archivo de configuración del clúster, se ignoran las comprobaciones preliminares internas si aplicas recursos a los clústeres existentes.

  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

Cómo agregar o quitar administradores de clústeres

`bmctl`

Puedes agregar o quitar un usuario o una cuenta de servicio como administrador del clúster para un clúster de usuario. Para ello, especifica las direcciones de correo electrónico en la sección clusterSecurity.authorization.clusterAdmin.gcpAccounts del archivo de configuración del clúster. A las cuentas se les otorga el rol de administrador de clúster en el clúster, lo que proporciona acceso completo al clúster.

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 usuario para agregar una cuenta, asegúrate de incluir todas las cuentas en la lista (tanto las existentes como las nuevas), ya que bmctl update sobrescribe la lista con lo que especifiques en el archivo de configuración. Para quitar una cuenta, quítala del archivo de configuración del clúster y ejecuta bmctl update.

gcloud CLI

Puedes agregar o quitar un usuario o una cuenta de servicio como administrador del clúster especificando direcciones de correo electrónico en la marca --admin-users. La marca solo acepta una dirección de correo electrónico. Para agregar 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 reemplaza toda la lista de otorgamientos. Especifica todos los usuarios existentes y nuevos que deseas que sean administradores del clúster.

Cómo configurar un usuario de acceso

Puedes especificar un nombre de usuario no raíz que quieras usar para acceder a las máquinas de nodo en tu clúster con la capacidad sudo sin contraseña. Tu clave SSH, sshPrivateKeyPath, debe funcionar para el usuario especificado. Las operaciones de creación y actualización de clústeres verifican que se pueda acceder a las máquinas de nodo 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

gcloud CLI

Especifica el usuario que deseas usar para acceder a las máquinas de nodo 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 sudo sin contraseña para un usuario, sigue estos pasos en cada máquina de nodo del clúster:

Usa sudo visudo para abrir el archivo de sudoers para editarlo:
```
sudo visudo -f /etc/sudoers
```
El comando visudo bloquea el archivo de sudoers para evitar ediciones simultáneas y valida la sintaxis del archivo cuando se guarda.
Para tu usuario de acceso, agrega una entrada al archivo de sudoers como la siguiente:
```
USERNAME ALL=(ALL) NOPASSWD: ALL
```
Cierra y guarda el archivo.
Para ejecutar comandos con los privilegios de tu usuario de acceso, ejecuta el siguiente comando:
```
su - USERNAME
```
Para verificar que no se requiere una contraseña para que el usuario de acceso ejecute comandos de sudo, ejecuta el siguiente comando de sudo:
```
sudo ip a
```

Herramientas de redes avanzadas

Configuras las funciones de redes avanzadas en varios recursos personalizados después de crear el clúster. Para usar los recursos personalizados y las funciones de redes relacionadas, debes habilitar las redes avanzadas cuando crees tu clúster.

`bmctl`

Establece clusterNetwork.advancedNetworking en true en la configuración del clúster cuando lo crees:

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

gcloud CLI

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

Después de crear el clúster con las redes avanzadas habilitadas, puedes configurar los recursos personalizados que se describen en esta sección con kubectl apply.

`NetworkGatewayGroup`

El recurso personalizado NetworkGatewayGroup se usa para proporcionar direcciones IP flotantes para funciones avanzadas de redes, como la puerta de enlace NAT de salida o el balanceo de cargas en paquetes 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 cargas de BGP

Configura el balanceo de cargas del protocolo de puerta de enlace de frontera (BGP) en el recurso del clúster y otros recursos personalizados. Los comandos gcloud container bare-metal clusters create y update admiten la configuración de BGP en el recurso del clúster, pero no en los recursos personalizados.

Cuando configuras balanceadores de cargas en paquetes con BGP, el balanceo de cargas del plano de datos usa de forma predeterminada los mismos pares externos que se especificaron para el intercambio de tráfico del plano de control. Como alternativa, puedes configurar el balanceo de cargas del plano de datos por separado mediante el recurso personalizado BGPLoadBalancer y el recurso personalizado BGPPeer. Para obtener más información, consulta Configura balanceadores de cargas en paquetes 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

Aumenta el rango de la red de servicios

Para crear más servicios que el límite inicial, puedes reducir la máscara de CIDR del servicio IPv4 para aumentar la red de servicios de tu clúster. Reducir la máscara (el valor después de "/") da como resultado un rango de red más grande. Solo puedes aumentar el rango del CIDR del servicio IPv4. El rango de red no se puede reducir, lo que significa que la máscara (el valor 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
  ...

gcloud CLI

Para aumentar el rango del CIDR de servicio IPv4 en un clúster de usuario, especifica el nuevo rango 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

Configura los parámetros de extracción de imágenes de kubelet

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

Actualizar manualmente la configuración de kubelet y mantenerla sincronizada en todos los nodos del clúster puede ser un desafío. Para empeorar las cosas, los cambios manuales en la configuración de kubelet en tus nodos se pierden cuando actualizas tu clúster.

Para facilitar y mantener las actualizaciones sincronizadas, Google Distributed Cloud te permite especificar algunos parámetros de configuración de kubelet para cada uno de los grupos de nodos de tu clúster: nodos del plano de control, nodos del balanceador de cargas y nodos trabajadores. La configuración se aplica a todos los nodos de un grupo determinado y persiste durante las actualizaciones del clúster. Los campos de estos parámetros de configuración son mutables, por lo que puedes actualizarlos en cualquier momento, no solo durante la creación del clúster.

`bmctl`

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

registryBurst (el valor predeterminado es 10)
registryPullQPS (el valor predeterminado es 5)
serializeImagePulls (el valor predeterminado es verdadero)

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

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

Especificación del clúster:
Nodos del plano de control spec.controlPlane.nodePoolSpec.kubeletConfig
Nodos del balanceador de cargas spec.loadBalancer.nodePoolSpec.kubeletConfig
Especificación de NodePool:
Nodos trabajadores spec.kubeletConfig

En el siguiente ejemplo, se muestran los campos agregados 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 cada caso, el parámetro de configuración se aplica a todos los nodos del grupo.

gcloud CLI

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

Cómo usarla

Estas son algunas consideraciones para ajustar las extracciones de imágenes:

Dado que las imágenes se extraen en serie de forma predeterminada, una extracción de imágenes que tarda 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 (en especial, cuando se deben implementar imágenes nuevas de Google Distributed Cloud en un nodo). Si te afectan las demoras 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 tienes errores de limitación de extracción de imágenes, como pull QPS exceeded, es posible que desees aumentar *-registry-pull-qps y *-registry-burst para aumentar la capacidad de procesamiento de 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 proporciona cierta personalización de la configuración de Keepalived. Con el balanceo de cargas agrupado, el balanceador de cargas del plano de control entrega 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 cargas para anunciar la VIP del plano de control. Keepalived usa el protocolo de redundancia de router virtual (VRRP) en los nodos del balanceador de cargas para obtener alta disponibilidad.

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

En el caso de los planos de control de alta disponibilidad, Google Distributed Cloud configura automáticamente la configuración de Keepalived VRRP para que el comportamiento de conmutación por error sea determinístico y evitar la intercalación de 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 principal.
Google Distributed Cloud te permite especificar la cantidad de mensajes de ARP gratuitos (GARP) que se enviarán a la vez después de que un nodo del plano de control realice la transición al rol de servidor principal. Para cambiar la cantidad de mensajes de GARP que se envían, agrega el campo controlPlane.loadBalancer.keepalivedVRRPGARPMasterRepeat al archivo de configuración del clúster, configúralo con el valor nuevo y actualiza el clúster. Este valor se asigna al parámetro de configuración vrrp_garp_master_repeat para Keepalived. El valor predeterminado es 5.

En el siguiente ejemplo, 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
  ...
```

Instala o desinstala el operador de GPU de 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 de NVIDIA para proporcionar una solución administrada para controlar los componentes de software de NVIDIA necesarios para aprovisionar las GPU en los nodos de trabajo del clúster.

Requisitos previos

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

Clúster operativo: Tienes un clúster de equipos físicos funcional creado con Google Distributed Cloud.
GPUs de NVIDIA: Las GPUs de NVIDIA están instaladas en los nodos de trabajador del clúster. En la siguiente sección para instalar el operador de GPU de NVIDIA, se incluyen pasos para verificar que las GPUs estén instaladas correctamente y que el sistema operativo las reconozca.
Versión del controlador de NVIDIA compatible: La versión del controlador de NVIDIA que uses debe ser compatible con tu GPU, tu sistema operativo y la versión de CUDA que usan tus aplicaciones. Para obtener más información, consulta Información de la versión.

Tienes las siguientes opciones de instalación del controlador NVIDIA:
- Usa el controlador de NVIDIA preinstalado en la imagen del sistema operativo.
- Sigue las instrucciones de la Guía de inicio rápido para la instalación de controladores de NVIDIA para instalar el controlador de NVIDIA de forma manual.
El controlador de GPU de NVIDIA debe estar instalado y listo antes de que habilites el operador de GPU de NVIDIA incluido.

Información de la versión

En esta sección, se incluye información sobre la versión del software del operador de GPU de NVIDIA incluido.

Versiones de los 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 de NVIDIA Container Toolkit
NVIDIA DCGM Exporter v3.3.9 a 3.6.1
Complemento de dispositivo de Kubernetes de NVIDIA v0.17.1
Node Feature Discovery v0.17.2

Es posible que las versiones de imágenes 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 con el controlador

Consulta Compatibilidad de la plataforma con la versión 25.3.1 en NVIDIA Docs Hub para obtener información sobre la compatibilidad de los controladores.

Actualiza el operador de GPU de NVIDIA incluido

Si instalaste el operador de GPU de NVIDIA en tu clúster, cuando actualices a una nueva versión secundaria, se instalará la versión más reciente del operador de GPU de NVIDIA.

Instala el operador incluido

Mientras que el operador de GPU de NVIDIA incluido se encuentra en versión preliminar, puedes instalarlo con bmctl update para agregar la siguiente anotación al clúster que tiene 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 de NVIDIA se instala en el clúster cuando se aplica la anotación.

Desinstala el operador incluido

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

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

Cuando se quita la anotación, se quitan del clúster todos los componentes de la pila del operador de GPU de NVIDIA.

Habilita 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 administran estos recursos. Esta capacidad te ayuda a ejecutar cargas de trabajo de IA asignando de forma dinámica y precisa los recursos de GPU dentro de tus clústeres de equipos físicos, lo que mejora el uso de recursos y el rendimiento para las cargas de trabajo exigentes.

La asignación dinámica de recursos está disponible en versión preliminar para clústeres de la versión 1.33 y posteriores. En las siguientes instrucciones, se describe cómo configurar tu clúster para usar la asignación dinámica de recursos. Después de habilitarla, 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:

Edita el archivo de configuración del clúster para incluir la anotación de vista previa preview.baremetal.cluster.gke.io/dynamic-resource-allocation: "enable" y agrega 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

Actualiza el clúster ejecutando el comando bmctl update:
```
bmctl update cluster -c CLUSTER_NAME \
    --kubeconfig=ADMIN_KUBECONFIG
```
Reemplaza lo siguiente:
- CLUSTER_NAME: Es el nombre del clúster de usuario que deseas actualizar.
- ADMIN_KUBECONFIG: la ruta del archivo kubeconfig del clúster de administrador
Después de aplicar esta configuración, es posible que el campo READY de tus máquinas de Bare Metal cambie entre True y False varias veces. Espera a que el campo READY se estabilice en True antes de continuar.
Para habilitar el acceso a la función DynamicResourceAllocation en los grupos de nodos que tienen nodos con GPU, establece DynamicResourceAllocation en true en la sección featureGates de la sección kubeletConfig de la especificación de NodePool:

Para obtener instrucciones para agregar y actualizar un grupo de nodos, consulta Administra 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 agregar o actualizar el grupo de nodos, espera a que todas las máquinas de metal desnudo del grupo de nodos alcancen el estado Ready.

Para verificar el estado de las máquinas físicas del clúster, usa el siguiente comando:

kubectl get baremetalmachines --kubeconfig ADMIN_KUBECONFIG -A

Cuando las máquinas de metal desnudo estén listas, la respuesta debería ser similar a la siguiente respuesta de ejemplo:

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 de NVIDIA incluido tiene las siguientes limitaciones:

El operador de GPU de NVIDIA incluido solo admite los siguientes componentes de software de NVIDIA:
- NVIDIA Container Toolkit
- NVIDIA DCGM Exporter
- Complemento de dispositivo NVIDIA Kubernetes
- Es el administrador de MIG de NVIDIA para Kubernetes.
Durante la versión preliminar, la configuración del operador de GPU de NVIDIA es fija. Si intentas personalizar algún parámetro de configuración, se conciliarán con la configuración de instalación original.
El operador de GPU de NVIDIA incluido no se puede usar para instalar controladores de GPU de NVIDIA.
Durante la versión preliminar, esta función usa el grupo de APIs resource.k8s.io/v1beta1, que difiere 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 proporciona más funciones y mejor estabilidad que el grupo de APIs de v1beta1.

¿Qué sigue?

Para usar la asignación dinámica de recursos con tus cargas de trabajo de GPU, consulta Administra dispositivos de GPU con la asignación dinámica de recursos.
Para obtener más información sobre la asignación dinámica de recursos, consulta Dynamic Resource Allocation en la documentación de Kubernetes.

Actualiza clústeres Organiza tus páginas con colecciones Guarda y categoriza el contenido según tus preferencias.

Cómo actualizar clústeres

bmctl

gcloud CLI

Terraform

Agrega o quita nodos en un clúster

bmctl

Ejemplo: Quita un nodo trabajador

gcloud CLI

Ejemplo: Quita un nodo trabajador

Reemplaza los nodos del plano de control de HA

bmctl

Ejemplo: Reemplaza un nodo del plano de control de HA

gcloud CLI

Ejemplo: Reemplaza un nodo del plano de control de HA

Verifica tus actualizaciones

kubectl

gcloud CLI

Grupos de direcciones del balanceador de cargas

bmctl

gcloud CLI

Evita la eliminación accidental del clúster

bmctl

gcloud CLI

Omite las comprobaciones preliminares

Cómo agregar o quitar administradores de clústeres

bmctl

gcloud CLI

Cómo configurar un usuario de acceso

bmctl

gcloud CLI

Herramientas de redes avanzadas

bmctl

gcloud CLI

NetworkGatewayGroup

Balanceo de cargas de BGP

BGPLoadBalancer

BGPPeer

Aumenta el rango de la red de servicios

bmctl

gcloud CLI

Configura los parámetros de extracción de imágenes de kubelet

bmctl

gcloud CLI

Cómo usarla

Personalización de Keepalived

Instala o desinstala el operador de GPU de NVIDIA incluido

Requisitos previos

Información de la versión

Versiones de los componentes de software

Compatibilidad con el controlador

Actualiza el operador de GPU de NVIDIA incluido

Instala el operador incluido

Desinstala el operador incluido

Habilita la asignación dinámica de recursos

Limitaciones

¿Qué sigue?

Documentación de referencia

bmctl

gcloud CLI

Terraform

Actualiza clústeres

`bmctl`

`bmctl`

`bmctl`

`kubectl`

`bmctl`

`bmctl`

`bmctl`

`bmctl`

`NetworkGatewayGroup`

`BGPLoadBalancer`

`BGPPeer`

`bmctl`

`bmctl`

`bmctl`