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
obmctl
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
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
.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
Especifica solo las marcas de la configuración que quieras 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 usuarios:
gcloud container bare-metal node-pools update
Terraform
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:
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ónNodePool
. - Grupo de nodos del plano de control: añade o elimina la dirección IP del nodo en la sección
spec.controlPlane.nodePoolSpec.nodes
Cluster
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.nodes
Cluster
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:
(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
ystatus.nodesDraining
del recursoNodePool
.Edita el archivo de configuración del clúster para eliminar la entrada de la dirección IP del nodo.
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.
(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
ystatus.nodesDraining
del recursoNodePool
.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
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 camposnodeIp
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
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 elOPERATION_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:
- Quita la dirección IP del nodo del archivo de configuración del clúster.
- Actualiza el clúster.
- Comprueba el estado de los nodos del clúster.
- Añade la dirección IP del nuevo nodo al mismo archivo de configuración del clúster.
- 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:
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
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.
Una vez que se haya ejecutado correctamente el comando
bmctl update
, se tardará un tiempo en completar los trabajosmachine-preflight
ymachine-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.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
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:
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
- Clúster de usuarios:
Comprueba el estado de la eliminación del nodo en el clúster ejecutando
gcloud container bare-metal operations describe OPERATION_ID
.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.
Ejecuta el comando
list
para enumerar todos los clústeres de usuario de un proyecto:Google Cloudgcloud 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
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 camposnodeIp
con las direcciones IP de los nodos del plano de control.
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 elOPERATION_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.
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 comoTrue
, 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 utilizaFalse
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 comoTrue
. Después, un desarrollador puede crear un servicio de tipoLoadBalancer
y especificar manualmente una de las direcciones del grupo. Si no se especifica,manual-assign
se define comoFalse
. 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:
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"
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 comandoupdate
.
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:
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.Añade una entrada al archivo sudoers para el usuario de inicio de sesión, como la siguiente:
USERNAME ALL=(ALL) NOPASSWD: ALL
Guarda el archivo y ciérralo.
Para ejecutar comandos con los privilegios de tu usuario de inicio de sesión, ejecuta el siguiente comando:
su - USERNAME
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 desudo
: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:
- Especificación del clúster:
- Nodos del plano de control
spec.controlPlane.nodePoolSpec.kubeletConfig
- Nodos de balanceador de carga
spec.loadBalancer.nodePoolSpec.kubeletConfig
- Especificación de NodePool:
- Nodos de trabajador
spec.kubeletConfig
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:
Nodos del plano de control
Nodos de balanceador de carga
- --bgp-load-balancer-registry-burst
- --bgp-load-balancer-registry-pull-qps
- --disable-bgp-load-balancer-serialize-image-pulls
- --enable-bgp-load-balancer-serialize-image-pulls
- --metal-lb-load-balancer-registry-burst
- --metal-lb-load-balancer-registry-pull-qps
- --disable-metal-lb-load-balancer-serialize-image-pull
- --enable-metal-lb-load-balancer-serialize-image-pulls
Nodos de trabajador
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 ajustevrrp_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:
Usa el controlador de NVIDIA preinstalado en la imagen de tu sistema operativo.
Sigue las instrucciones de la guía de inicio rápido de instalación de controladores de NVIDIA para instalar manualmente el controlador 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:
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ñadeDynamicResourceAllocation: true
enfeatureGates
en la secciónkubeletConfig
: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
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 entreTrue
yFalse
varias veces. Espera a que el campoREADY
se estabilice enTrue
antes de continuar.Para habilitar el feature gate
DynamicResourceAllocation
en grupos de nodos que tengan nodos con GPUs, asigna el valortrue
aDynamicResourceAllocation
en la secciónfeatureGates
de la secciónkubeletConfig
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
.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 abiertov1
ofrece más funciones y una mayor estabilidad que el grupo de APIsv1beta1
.
Siguientes pasos
Para usar la asignación dinámica de recursos con tus cargas de trabajo de GPU, consulta Gestionar 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 el artículo Asignación dinámica de recursos de la documentación de Kubernetes.