Aggiorna cluster

La modifica delle configurazioni dei cluster esistenti consente di regolare la capacità dell'infrastruttura e le impostazioni operative man mano che i workload si evolvono. Puoi aggiungere, rimuovere o sostituire nodi, aggiornare le annotazioni e modificare le impostazioni modificabili nel tuo ambiente utilizzando bmctl, Google Cloud CLI o Terraform. Per un elenco completo dei campi supportati, consulta il riferimento dei campi di configurazione del cluster.

Il supporto degli strumenti dipende dal tipo di cluster e dalle risorse che stai modificando:

  • gcloud CLI e Terraform supportano solo l'aggiornamento dei cluster di amministrazione e utente. Per aggiornare altri tipi di cluster, devi utilizzare bmctl.
  • gcloud CLI e Terraform supportano solo le modifiche alle risorse Cluster e NodePool. Per aggiornare altre risorse personalizzate che influiscono sul cluster, devi utilizzare kubectl o bmctl.

Come aggiornare i cluster

Molti aspetti della configurazione del cluster sono immutabili e non possono essere aggiornati dopo la creazione del cluster. Per un elenco completo dei campi modificabili e immutabili, consulta il riferimento dei campi di configurazione del cluster. Il riferimento ai campi è una tabella ordinabile. Fai clic sulle intestazioni delle colonne per modificare l'ordinamento. Fai clic sul nome di un campo per visualizzarne la descrizione.

In genere, per aggiornare un cluster, devi eseguire la seguente sequenza di azioni:

bmctl

  1. Modifica i valori dei campi applicabili nel file di configurazione del cluster, che per impostazione predefinita si trova qui:
    bmctl-workspace/CLUSTER-NAME/CLUSTER-NAME.yaml

  2. Aggiorna il cluster eseguendo il comando bmctl update:

    bmctl update cluster -c CLUSTER_NAME --kubeconfig=KUBECONFIG

    Sostituisci quanto segue:

    • CLUSTER_NAME: il nome del cluster che vuoi aggiornare.
    • KUBECONFIG: per i cluster di amministrazione, ibridi o autonomi, inserisci il percorso del file kubeconfig del cluster. Per un cluster utente, inserisci il percorso del file kubeconfig del cluster amministratore.

gcloud CLI

  1. Specifica solo i flag per la configurazione che vuoi modificare.

  2. Eseguire il comando di aggiornamento appropriato:

Terraform

  1. Modifica i valori dei campi applicabili nel file di configurazione Terraform che hai utilizzato per creare il cluster o il pool di nodi. Consulta la documentazione di riferimento di Terraform per descrizioni dettagliate dei campi:

  2. Aggiorna la configurazione eseguendo il comando terraform apply.

Le sezioni seguenti descrivono alcuni esempi comuni di aggiornamento di un cluster esistente.

Aggiungi o rimuovi nodi in un cluster

Un node pool è un gruppo di nodi all'interno di un cluster che condividono la stessa configurazione. Tieni presente che un nodo appartiene sempre a un pool di nodi. Per aggiungere un nuovo nodo a un cluster, devi aggiungerlo a un pool di nodi specifico. La rimozione di un nodo da un pool di nodi equivale alla rimozione del nodo dal cluster.

In Google Distributed Cloud esistono tre tipi di pool di nodi: control plane, bilanciatore del carico e pool di nodi worker. Le sezioni seguenti descrivono come aggiungere o rimuovere nodi da ogni tipo di pool di nodi.

bmctl

Puoi aggiungere o rimuovere un nodo da un pool di nodi aggiungendo o rimuovendo l'indirizzo IP del nodo in una sezione specifica del file di configurazione del cluster. Il seguente elenco mostra quale sezione modificare per un determinato pool di nodi:

  • Pool di nodi worker: aggiungi o rimuovi l'indirizzo IP del nodo nella sezione spec.nodes della specifica NodePool.
  • Pool di nodi del control plane: aggiungi o rimuovi l'indirizzo IP del nodo nella sezione spec.controlPlane.nodePoolSpec.nodes della specifica Cluster.
  • Pool di nodi del bilanciatore del carico: aggiungi o rimuovi l'indirizzo IP del nodo nella sezione spec.loadBalancer.nodePoolSpec.nodes della specifica Cluster.

Esempio: rimuovi un nodo worker

Ecco un file di configurazione del cluster di esempio che mostra le specifiche di due nodi worker:

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

Per rimuovere un nodo:

  1. (Facoltativo) Se il nodo che stai rimuovendo esegue pod critici, metti prima il nodo in modalità di manutenzione.

    Puoi monitorare il processo di svuotamento dei nodi worker visualizzando i campi status.nodesDrained e status.nodesDraining nella risorsa NodePool.

  2. Modifica il file di configurazione del cluster per eliminare la voce dell'indirizzo IP del nodo.

  3. Aggiorna il cluster:

    bmctl update cluster1 \
    --kubeconfig=ADMIN_KUBECONFIG

gcloud CLI

Utilizza un comando update per aggiungere o rimuovere nodi. Il comando update che utilizzi e il flag in cui specifichi l'indirizzo IP dipendono dal tipo di pool di nodi che vuoi aggiornare:

  • Pool di nodi worker: esegui gcloud container bare-metal node-pools update e specifica l'indirizzo IP nel flag --node-configs 'node-ip=IP_ADDRESS'.

  • Pool di nodi del control plane su un cluster di amministrazione: esegui gcloud container bare-metal admin-clusters update e specifica l'indirizzo IP nel flag --control-plane-node-configs 'node-ip=IP_ADDRESS'.

  • Pool di nodi del control plane su un cluster utente: esegui gcloud container bare-metal clusters update e specifica l'indirizzo IP nel flag --control-plane-node-configs 'node-ip=IP_ADDRESS'.

  • Pool di nodi del bilanciatore del carico: esegui gcloud container bare-metal clusters update e specifica l'indirizzo IP nel flag --metal-lb-load-balancer-node-configs 'node-ip=IP_ADDRESS' o
    --bgp-load-balancer-node-configs 'node-ip=IP_ADDRESS'

Il flag in cui specifichi l'indirizzo IP accetta un solo node-ip. Includi il flag per ogni indirizzo IP nel pool di nodi.

I comandi update sostituiscono tutti gli indirizzi IP con quelli che specifichi. Per aggiungere un nodo, includi gli indirizzi IP dei nodi esistenti e l'indirizzo IP del nuovo nodo nel comando update. Analogamente, puoi rimuovere i nodi includendo solo gli indirizzi IP dei nodi che vuoi conservare.

Esempio: rimuovi un nodo worker

Questa sezione mostra come rimuovere un nodo worker da un pool di nodi utilizzando dati di esempio. Nei passaggi seguenti sono inclusi anche altri comandi gcloud CLI che potresti trovare utili.

  1. (Facoltativo) Se il nodo che stai rimuovendo esegue pod critici, metti prima il nodo in modalità di manutenzione.

    Puoi monitorare il processo di svuotamento dei nodi worker visualizzando i campi status.nodesDrained e status.nodesDraining nella risorsa NodePool.

  2. Esegui il comando list per elencare tutti i node pool nel cluster:

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

    L'output è simile al seguente:

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

  3. Esegui il comando describe per elencare tutti gli indirizzi IP nel pool di nodi:

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

    L'output di esempio seguente è troncato per una migliore leggibilità:

    annotations:
  ...
  baremetal.cluster.gke.io/version: 1.36
...
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
...

    Nell'output di esempio, tieni presente quanto segue:

    • Il campo name contiene il nome completo del pool di nodi. Quando specifichi il nome pool di nodi in un comando, puoi specificare il nome completo o il nome pool di nodi, ad esempio node-pool-1, insieme ai flag --cluster, --project e --location.

    • La sezione nodeConfigs contiene due campi nodeIp con gli indirizzi IP dei nodi.

  4. Esegui questo comando per rimuovere il nodo con l'indirizzo 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'

    Il comando update sostituisce tutti gli indirizzi IP con quelli che specifichi. Poiché 192.0.2.1 non è incluso, il nodo viene rimosso.

    L'output di questo comando è simile al seguente:

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

    Nell'output di esempio, la stringa operation-1697154681749-6078d9def4030-76686d6e-9fcb1de9 è il OPERATION_ID dell'operazione a lunga esecuzione. Puoi scoprire lo stato dell'operazione eseguendo questo comando in un'altra finestra del terminale:

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

    Puoi eseguire nuovamente il comando di tanto in tanto per controllare lo stato.

Se la rimozione del nodo non va a buon fine, puoi forzarla dal cluster. Per maggiori dettagli, consulta Reimposta un nodo con errori in Google Distributed Cloud.

Sostituisci i nodi del control plane ad alta affidabilità

bmctl

Puoi utilizzare bmctl per sostituire i nodi del control plane ad alta affidabilità (HA) in tutti i tipi di cluster.

Per sostituire un nodo in un cluster, segui questi passaggi:

  1. Rimuovi l'indirizzo IP del nodo dal file di configurazione del cluster.
  2. Aggiorna il cluster.
  3. Controlla lo stato dei nodi nel cluster.
  4. Aggiungi l'indirizzo IP di un nuovo nodo allo stesso file di configurazione del cluster.
  5. Aggiorna il cluster.

Esempio: sostituzione di un nodo del control plane ad alta affidabilità

Ecco un file di configurazione del cluster di esempio che mostra tre nodi del control plane in un cluster utente:

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

Per sostituire l'ultimo nodo elencato nella sezione spec.controlPlane.nodePoolSpec.nodes, segui questi passaggi:

  1. Rimuovi il nodo eliminando la voce dell'indirizzo IP nel file di configurazione del cluster. Dopo aver apportato questa modifica, il file di configurazione del cluster dovrebbe avere un aspetto simile al seguente:

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

  2. Aggiorna il cluster eseguendo il seguente comando:

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

    Apporta le seguenti modifiche:

    • Sostituisci CLUSTER_NAME con il nome del cluster che vuoi aggiornare.
    • Se il cluster è un cluster autogestito (ad esempio un cluster di amministrazione o autonomo), sostituisci KUBECONFIG con il percorso del file kubeconfig del cluster. Se il cluster è un cluster utente, come in questo esempio, sostituisci KUBECONFIG con il percorso del file kubeconfig del cluster amministratore.

  3. Dopo l'esecuzione del comando bmctl update, è necessario un po' di tempo per completare i job machine-preflight e machine-init. Puoi visualizzare lo stato dei nodi e dei rispettivi pool di nodi eseguendo i comandi descritti nella sezione Verifica gli aggiornamenti di questo documento. Dopo che il pool di nodi e i nodi sono in stato Pronto, puoi procedere al passaggio successivo.

  4. Aggiungi un nuovo nodo del control plane al pool di nodi aggiungendo l'indirizzo IP del nuovo nodo del control plane alla sezione spec.controlPlane.nodePoolSpec.nodes del file di configurazione del cluster. Dopo aver apportato questa modifica, il file di configurazione del cluster dovrebbe avere il seguente aspetto:

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

  5. Aggiorna il cluster eseguendo il seguente comando:

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

gcloud CLI

Puoi utilizzare gcloud CLI per sostituire i nodi del control plane ad alta affidabilità (HA) nei cluster di amministrazione e utente.

Per sostituire un nodo in un cluster, segui questi passaggi:

  1. Rimuovi l'indirizzo IP del nodo eseguendo il comando update applicabile:

    • Cluster utente: gcloud container bare-metal clusters update
    • Cluster di amministrazione: gcloud container bare-metal admin-clusters update

  2. Controlla lo stato della rimozione dei nodi nel cluster eseguendo gcloud container bare-metal operations describe OPERATION_ID.

  3. Aggiungi l'indirizzo IP del nuovo nodo eseguendo il comando update applicabile.

Esempio: sostituzione di un nodo del control plane ad alta affidabilità

Questa sezione mostra come sostituire un control plane di un cluster utilizzando dati di esempio. Nei passaggi seguenti sono inclusi anche altri comandi gcloud CLI che potresti trovare utili.

  1. Esegui il comando list per elencare tutti i cluster utente in un progettoGoogle Cloud :

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

    Se imposti --location=-, verranno elencati tutti i cluster in tutte le regioni. Se devi restringere l'elenco, imposta --location su una regione specifica.

    L'output è simile al seguente:

    NAME                 LOCATION      VERSION   ADMIN_CLUSTER        STATE
abm-user-cluster1a   us-central1   1.36      abm-admin-cluster1   RUNNING
abm-user-cluster1b   europe-west1  1.36      abm-admin-cluster1   RUNNING

  2. Esegui il comando describe sul cluster:

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

    L'output di esempio è troncato per una migliore leggibilità:

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

    Nell'output di esempio, tieni presente quanto segue:

    • Il campo name contiene il nome completo del cluster. Quando specifichi il nome del cluster in un comando, puoi specificare il nome completo o il nome del cluster, ad esempio abm-user-cluster1a, insieme a --project e --location flags.

    • La sezione nodeConfigs contiene tre campi nodeIp con gli indirizzi IP dei nodi del control plane.

  3. Rimuovi il nodo con l'indirizzo 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'

    L'output di questo comando è simile al seguente:

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

    Nell'output di esempio, la stringa operation-1956154681749-6078d9def4030-76686d6e-9fcb1de7 è il OPERATION_ID dell'operazione a lunga esecuzione. Puoi scoprire lo stato dell'operazione eseguendo questo comando in un'altra finestra del terminale:

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

    Puoi eseguire nuovamente il comando di tanto in tanto per controllare lo stato.

  4. Aggiungi il nuovo nodo con l'indirizzo 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 gli aggiornamenti

kubectl

Puoi visualizzare lo stato dei nodi e dei rispettivi node pool con il comando kubectl get.

Ad esempio, il comando seguente mostra lo stato dei node pool nello spazio dei nomi del cluster cluster-my-cluster:

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

Il sistema restituisce risultati simili ai seguenti:

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 indica che la fase di riconciliazione è ancora in corso. Devi attendere che lo stato cambi in Reconciling=0.

Puoi anche controllare lo stato dei nodi in un cluster eseguendo questo comando:

kubectl get nodes --kubeconfig=KUBECONFIG

gcloud CLI

Come descritto in precedenza, dopo aver eseguito un comando update, puoi controllare lo stato dell'operazione utilizzando gcloud container bare-metal operations describe OPERATIONS_ID. L'output del comando fornisce lo stato dei nodi, ad esempio:

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

Indipendentemente dallo strumento utilizzato per aggiornare un pool di nodi, puoi ottenere lo stato attuale di un pool di nodi eseguendo il comando describe applicabile, come mostrato in precedenza.

Se hai bisogno di ulteriori informazioni su come diagnosticare i cluster, consulta Crea snapshot per la diagnostica dei cluster.

Pool di indirizzi del bilanciatore del carico

bmctl

La sezione addressPools contiene i campi per specificare i pool di bilanciamento del carico per i bilanciatori del carico in bundle MetalLB e Border Gateway Protocol (BGP). Puoi aggiungere altri pool di indirizzi di bilanciamento del carico in qualsiasi momento, ma non puoi rimuovere i pool di indirizzi esistenti. A partire dalla versione 1.16.0 di Google Distributed Cloud, puoi modificare i valori di addressPools.avoidBuggyIPs e addressPools.manualAssign in qualsiasi 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

Puoi aggiungere altri pool di indirizzi di bilanciamento del carico in qualsiasi momento per i bilanciatori del carico in bundle, ma non puoi rimuovere i pool di indirizzi esistenti. Il flag che specifichi in gcloud container bare-metal clusters update per aggiungere un pool di indirizzi dipende dal tipo di bilanciatore del carico in bundle:

  • MetalLB (livello 2): utilizza il flag --metal-lb-address-pools.
  • Border Gateway Protocol (BGP): utilizza il flag --bgp-address-pools.

Il valore dei flag ha il seguente formato:

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

Il valore contiene segmenti che iniziano con le parole chiave pool, avoid-buggy-ip, manual-assign e addresses. Separa ogni segmento con una virgola.

  • pool: un nome a tua scelta per il pool.

  • avoid-buggy-ips: se imposti questo valore su True, il controller di gestione degli indirizzi IP (IPAM) non assegnerà ai servizi indirizzi IP che terminano con .0 o .255. In questo modo si evita il problema dei dispositivi consumer con bug che eliminano erroneamente il traffico inviato a questi indirizzi IP speciali. Se non specificato, il valore predefinito è False. A partire dalla versione 1.16.0 di Google Distributed Cloud, puoi modificare questo valore in un pool di indirizzi esistente.

  • manual-assign: se non vuoi che il controller IPAM assegni automaticamente gli indirizzi IP di questo pool ai servizi, imposta questo valore su True. In seguito, uno sviluppatore può creare un servizio di tipo LoadBalancer e specificare manualmente uno degli indirizzi del pool. Se non specificato, manual-assign viene impostato su False. A partire dalla versione 1.16.0 di Google Distributed Cloud, puoi modificare questo valore in un pool di indirizzi esistente.

  • Nell'elenco di addresses: ogni indirizzo deve essere un intervallo in formato CIDR o intervallo con trattino. Per specificare un singolo indirizzo IP in un pool (ad esempio per il VIP Ingress), utilizza /32 nella notazione CIDR (ad esempio, 192.0.2.1/32).

Tieni presente le seguenti regole di sintassi:

  • Racchiudi l'intero valore tra virgolette singole.
  • Lo spazio vuoto non è consentito.
  • Separa ogni intervallo di indirizzi IP con un punto e virgola.

Puoi specificare più di un'istanza del flag, come mostrato nell'esempio seguente:

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

Per saperne di più sui pool di indirizzi del bilanciatore del carico, consulta loadBalancer.addressPools in Configura il bilanciamento del carico in bundle.

Impedisci l'eliminazione involontaria del cluster

bmctl

Se aggiungi l'annotazione baremetal.cluster.gke.io/prevent-deletion: "true" al file di configurazione del cluster, non potrai eliminare il cluster. Ad esempio, l'esecuzione di kubectl delete cluster o bmctl reset cluster genera un errore.

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

Se specifichi il flag --add-annotations con il valore baremetal.cluster.gke.io/prevent-deletion="true", non puoi eliminare il cluster. Ad esempio:

  1. Aggiungi l'annotazione per evitare l'eliminazione accidentale del cluster:

    gcloud container bare-metal clusters update abm-user-cluster1a \
    --project=example-project-12345 \
    --location=us-central1 \
    --add-annotations=baremetal.cluster.gke.io/prevent-deletion="true"

  2. Prova a eliminare il cluster utente:

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

    La risposta del comando è simile alla seguente:

    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

    Per rimuovere l'annotazione, specifica --remove-annotations=baremetal.cluster.gke.io/prevent-deletion="true" nel comando update.

Ignora i controlli preflight

Questa funzionalità è disponibile solo con bmctl update.

Il valore predefinito del campo bypassPreflightCheck è false. Se imposti questo campo su true nel file di configurazione del cluster, i controlli preflight interni vengono ignorati quando applichi le risorse ai cluster esistenti.

  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

Aggiungi o rimuovi amministratori del cluster

bmctl

Puoi aggiungere o rimuovere un utente o un account di servizio come amministratore del cluster per un cluster utente specificando gli indirizzi email nella sezione clusterSecurity.authorization.clusterAdmin.gcpAccounts del file di configurazione del cluster. Agli account viene concesso il ruolo cluster-admin sul cluster, che permette di avere l'accesso completo al cluster.

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.

Quando aggiorni un cluster utente per aggiungere un account, assicurati di includere tutti gli account nell'elenco (sia quelli esistenti sia quelli nuovi) perché bmctl update sovrascrive l'elenco con quello specificato nel file di configurazione. Per rimuovere un account, rimuovilo dal file di configurazione del cluster ed esegui bmctl update.

gcloud CLI

Puoi aggiungere o rimuovere un utente o un account di servizio come amministratore del cluster specificando un indirizzo email nel flag --admin-users. Il flag accetta un solo indirizzo email. Per aggiungere più utenti, specifica un account in ogni flag, ad esempio:

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.

Il comando update sovrascrive l'intero elenco di autorizzazioni. Specifica tutti gli utenti esistenti e nuovi che vuoi che siano amministratori del cluster.

Imposta un utente di accesso

Puoi specificare un nome utente non root che vuoi utilizzare per l'accesso alle funzionalità sudo senza password alle macchine nodo del tuo cluster. La chiave SSH, sshPrivateKeyPath, deve funzionare per l'utente specificato. Le operazioni di creazione e aggiornamento del cluster controllano che sia possibile accedere alle macchine nodo con l'utente e la chiave SSH specificati.

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

Specifica l'utente che vuoi utilizzare per accedere alle macchine dei nodi nel flag --login-user, ad esempio:

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

Per attivare l'accesso sudo senza password per un utente, segui questi passaggi su ogni macchina nodo del cluster:

  1. Utilizza sudo visudo per aprire il file sudoers per la modifica:

    sudo visudo -f /etc/sudoers

    Il comando visudo blocca il file sudoers per impedire modifiche simultanee e convalida la sintassi del file al momento del salvataggio.

  2. Per l'utente di accesso, aggiungi una voce al file sudoers come la seguente:

    USERNAME ALL=(ALL) NOPASSWD: ALL

  3. Chiudi e salva il file.

  4. Per eseguire i comandi con i privilegi del tuo utente di accesso, esegui questo comando:

    su - USERNAME

  5. Per verificare che non sia richiesta una password per l'utente di accesso per eseguire i comandi sudo, esegui questo comando sudo:

    sudo ip a

Networking avanzato

Puoi configurare funzionalità di networking avanzate in varie risorse personalizzate dopo la creazione del cluster. Per utilizzare le risorse personalizzate e le funzionalità di networking correlate, devi abilitare il networking avanzato quando crei il cluster.

bmctl

Imposta clusterNetwork.advancedNetworking su true nella configurazione del cluster quando crei il cluster:

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

gcloud CLI

Includi il flag --enable-advanced-networking nel comando gcloud container bare-metal clusters create quando crei il cluster.

Dopo aver creato il cluster con il networking avanzato abilitato, puoi configurare le risorse personalizzate descritte in questa sezione utilizzando kubectl apply.

NetworkGatewayGroup

La risorsa personalizzata NetworkGatewayGroup viene utilizzata per fornire indirizzi IP mobili per funzionalità di networking avanzate, come il gateway NAT in uscita o la funzionalità di bilanciamento del carico in bundle con BGP.

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

Bilanciamento del carico BGP

Puoi configurare il bilanciamento del carico del Border Gateway Protocol (BGP) nella risorsa cluster e in altre risorse personalizzate. I comandi gcloud container bare-metal clusters create e update supportano la configurazione di BGP nella risorsa cluster, ma non nelle risorse personalizzate.

Quando configuri i bilanciatori del carico in bundle con BGP, il bilanciamento del carico del piano dati utilizza, per impostazione predefinita, gli stessi peer esterni specificati per il peering del control plane. In alternativa, puoi configurare il bilanciamento del carico del piano dati separatamente, utilizzando la risorsa personalizzata BGPLoadBalancer e la risorsa personalizzata BGPPeer. Per saperne di più, consulta Configura i bilanciatori del carico in bundle 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 l'intervallo di rete dei servizi

Per creare più servizi rispetto al limite iniziale, puoi ridurre la maschera CIDR del servizio IPv4 per aumentare la rete di servizi del cluster. Se riduci la maschera (il valore dopo "/"), l'intervallo di rete aumenta. Puoi solo aumentare l'intervallo del CIDR del servizio IPv4. L'intervallo di rete non può essere ridotto, il che significa che la maschera (il valore dopo "/") non può essere aumentata.

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

Per aumentare l'intervallo del CIDR del servizio IPv4 in un cluster utente, specifica il nuovo intervallo nel flag --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

A partire dalla versione 1.34, vedrai nuove risorse ServiceCIDR nel tuo cluster. Queste risorse vengono utilizzate dal control plane Kubernetes per gestire gli intervalli di indirizzi IP per i tuoi servizi.

Non tentare di creare o modificare manualmente le risorse ServiceCIDR. Sono gestiti automaticamente dall'operatore del cluster in base ai valori nella risorsa personalizzata Cluster. Per evitare problemi di networking, tutte le modifiche manuali dirette vengono bloccate e riceverai un messaggio di errore simile al seguente:

The servicecidrs "my-cidr" is invalid: : This resource is managed by cluster
operator and cannot be modified directly by users.

Configura le impostazioni di pull delle immagini kubelet

Il kubelet viene eseguito su ogni nodo del cluster. Il kubelet è responsabile del monitoraggio dei container su un nodo e di garantire che siano integri. Quando necessario, kubelet esegue query ed estrae immagini da Artifact Registry.

L'aggiornamento manuale delle configurazioni di kubelet e la loro sincronizzazione su tutti i nodi del cluster può essere difficile. A peggiorare le cose, le modifiche manuali alla configurazione di kubelet sui nodi vengono perse quando esegui l'upgrade del cluster.

Per semplificare e rendere persistenti gli aggiornamenti sincronizzati, Google Distributed Cloud ti consente di specificare alcune impostazioni di kubelet per ciascuno dei node pool del cluster: nodi del control plane, nodi del bilanciatore del carico e nodi worker. Le impostazioni si applicano a tutti i nodi di un determinato pool e rimangono invariate durante gli upgrade del cluster. I campi per queste impostazioni sono modificabili, quindi puoi aggiornarli in qualsiasi momento, non solo durante la creazione del cluster.

bmctl

I seguenti campi supportati controllano le operazioni di pull di Artifact Registry per kubelet:

  • registryBurst (valore predefinito: 10)
  • registryPullQPS (valore predefinito: 5)
  • serializeImagePulls (valore predefinito: true)

Per saperne di più su ciascuno dei campi di configurazione di kubelet, consulta il riferimento ai campi di configurazione del cluster.

Puoi specificare questi campi nelle sezioni kubeletConfig della specifica del cluster e della specifica NodePool per i seguenti pool di nodi:

L'esempio seguente mostra i campi aggiunti con i relativi valori predefiniti nel file di configurazione del cluster. Tieni presente che l'annotazione preview.baremetal.cluster.gke.io/custom-kubelet: "enable" è obbligatoria.

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

In ogni caso, l'impostazione si applica a tutti i nodi del pool.

gcloud CLI

I seguenti flag controllano le operazioni di pull di Artifact Registry per kubelet:

Come utilizzarlo

Ecco alcune considerazioni per l'ottimizzazione dei pull di immagini:

  • Poiché per impostazione predefinita il pull delle immagini viene eseguito in serie, un pull di immagini che richiede molto tempo può ritardare tutti gli altri pull di immagini pianificati su un nodo. I pull delle immagini ritardati possono bloccare il processo di upgrade (soprattutto quando è necessario eseguire il deployment di nuove immagini Google Distributed Cloud su un nodo). Se riscontri ritardi nei pull di immagini, puoi disattivare i pull di immagini serializzati per consentire i pull di immagini paralleli.

  • Se riscontri errori di limitazione del pull delle immagini, ad esempio pull QPS exceeded, ti consigliamo di aumentare *-registry-pull-qps e *-registry-burst per aumentare il throughput del pull delle immagini. Questi due campi regolano la frequenza di pull e le dimensioni della coda e possono aiutare a risolvere altri problemi relativi alla limitazione. I valori negativi non sono consentiti.

Personalizzazione di Keepalived

A partire dalla versione 1.32, Google Distributed Cloud offre alcune opzioni di personalizzazione della configurazione di Keepalived. Con il bilanciamento del carico integrato, il bilanciatore del carico del control plane gestisce l'indirizzo IP virtuale (VIP) del control plane. Google Distributed Cloud esegue Keepalived e HAProxy come pod statici di Kubernetes sui nodi del bilanciatore del carico per annunciare il VIP del control plane. Keepalived utilizza il protocollo VRRP (Virtual Router Redundancy Protocol) sui nodi del bilanciatore del carico per l'alta affidabilità.

I cluster versione 1.32 e successive hanno le seguenti personalizzazioni di Keepalived:

  • Per i control plane ad alta affidabilità, Google Distributed Cloud configura automaticamente la configurazione VRRP di Keepalived per rendere deterministico il comportamento di failover e impedire l'interfoliazione delle risposte ARP con indirizzi MAC diversi. Per farlo, configura ogni istanza Keepalived con un valore priority diverso.

  • Google Distributed Cloud ti consente di specificare il numero di messaggi gratuitous ARP (GARP) da inviare alla volta dopo che un nodo del control plane passa al ruolo di server master. Per modificare il numero di messaggi GARP da inviare, aggiungi il campo controlPlane.loadBalancer.keepalivedVRRPGARPMasterRepeat al file di configurazione del cluster, impostalo sul nuovo valore e aggiorna il cluster. Questo valore corrisponde all'impostazione vrrp_garp_master_repeat per Keepalived. Il valore predefinito è 5.

    L'esempio seguente mostra come specificare keepalivedVRRPGARPMasterRepeat nel file di configurazione del cluster:

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

Installa o disinstalla l'operatore GPU NVIDIA integrato

L'operatore GPU NVIDIA ti consente di eseguire workload relativi alle GPU nei tuoi cluster. A partire dalla versione 1.33.0 di Google Distributed Cloud, i cluster sono integrati con uno stack completo di operatori GPU NVIDIA per fornire una soluzione gestita per la gestione dei componenti software NVIDIA necessari per il provisioning delle GPU sui nodi worker del cluster.

Prerequisiti

Prima di installare l'operatore GPU NVIDIA in bundle, assicurati che il tuo ambiente soddisfi i seguenti requisiti:

  • Cluster operativo: hai un cluster bare metal funzionale creato con Google Distributed Cloud.

  • GPU NVIDIA: le GPU NVIDIA sono installate sui nodi worker del cluster. La sezione seguente per l'installazione dell'operatore GPU NVIDIA include i passaggi per verificare che le GPU siano installate correttamente e riconosciute dal sistema operativo.

  • Versione del driver NVIDIA compatibile: la versione del driver NVIDIA che utilizzi deve essere compatibile con la GPU, il sistema operativo e la versione di CUDA utilizzata dalle tue applicazioni. Per ulteriori informazioni, consulta Informazioni sulla versione.

    Hai a disposizione le seguenti opzioni di installazione dei driver NVIDIA:

    Il driver GPU NVIDIA deve essere installato e pronto prima di attivare l'operatore GPU NVIDIA in bundle.

Informazioni sulla versione

Questa sezione contiene informazioni sulla versione software dell'operatore GPU NVIDIA in bundle.

Versioni dei componenti software

La versione di release 1.33 di Google Distributed Cloud include la versione 25.3.1 dell'operatore GPU NVIDIA. In Google Distributed Cloud, il bundle contiene le seguenti immagini (con CDI abilitato per impostazione predefinita):

  • NVIDIA Container Toolkit versione v1.17.9
  • NVIDIA DCGM Exporter v3.3.9-3.6.1
  • Plug-in per dispositivi NVIDIA Kubernetes v0.17.1
  • Node Feature Discovery v0.17.2

Le versioni immagine incluse nella release 1.33 di Google Distributed Cloud potrebbero non corrispondere esattamente alle versioni dei componenti software elencate nelle note di rilascio 25.3.1.

Compatibilità dei driver

Consulta Supporto della piattaforma per la versione 25.3.1 nell'hub della documentazione di NVIDIA per informazioni sulla compatibilità dei driver.

Aggiornamento dell'operatore GPU NVIDIA integrato

Se hai installato NVIDIA GPU Operator sul tuo cluster, quando esegui l'upgrade a una nuova versione secondaria, viene installata l'ultima versione in bundle di NVIDIA GPU Operator.

Installa l'operatore in bundle

Mentre l'operatore GPU NVIDIA in bundle è in anteprima, installalo utilizzando bmctl update per aggiungere la seguente annotazione al cluster con nodi 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:
  ...

Lo stack dell'operatore GPU NVIDIA viene installato nel cluster quando viene applicata l'annotazione.

Disinstalla l'operatore in bundle

Mentre l'operatore GPU NVIDIA in bundle è in anteprima, puoi disinstallarlo utilizzando bmctl update per rimuovere la seguente annotazione dal cluster con nodi GPU:

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

Tutti i componenti dello stack dell'operatore GPU NVIDIA vengono rimossi dal cluster quando l'annotazione viene rimossa.

Attiva l'allocazione dinamica delle risorse

L'allocazione dinamica delle risorse è un'API Kubernetes che ti consente di richiedere e condividere risorse generiche, come le GPU, tra pod e container. I driver di terze parti gestiscono queste risorse. Questa funzionalità ti aiuta a eseguire i workload di AI allocando in modo dinamico e preciso le risorse GPU all'interno dei cluster bare metal, migliorando l'utilizzo delle risorse e le prestazioni per i workload più impegnativi.

L'allocazione dinamica delle risorse è disponibile in anteprima per i cluster versione 1.33 e successive. Le istruzioni riportate di seguito descrivono come configurare il cluster per utilizzare l'allocazione dinamica delle risorse. Una volta abilitata, puoi configurare i workload GPU in modo che utilizzino l'allocazione dinamica delle risorse.

Configura il cluster per abilitare l'allocazione dinamica delle risorse:

  1. Modifica il file di configurazione del cluster in modo da includere l'annotazione di anteprima preview.baremetal.cluster.gke.io/dynamic-resource-allocation: "enable" e aggiungi DynamicResourceAllocation: true in featureGates nella sezione kubeletConfig:

    apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: dra
  namespace: cluster-dra
  annotations:
    preview.baremetal.cluster.gke.io/dynamic-resource-allocation: "enable"
spec:
  controlPlane:
    nodePoolSpec:
      kubeletConfig:
        featureGates:
          DynamicResourceAllocation: true
# ... other cluster configuration

  2. Aggiorna il cluster eseguendo il comando bmctl update:

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

    Sostituisci quanto segue:

    • CLUSTER_NAME: il nome del cluster utente che stai aggiornando.

    • ADMIN_KUBECONFIG: il percorso del file kubeconfig del cluster di amministrazione.

    Dopo aver applicato questa configurazione, il campo READY per le tue macchine bare metal potrebbe passare più volte da True a False. Attendi che il campo READY si stabilizzi su True prima di procedere.

  3. Per abilitare il feature gate DynamicResourceAllocation nei node pool che hanno nodi con GPU, imposta DynamicResourceAllocation su true nella sezione featureGates della sezione kubeletConfig della specifica NodePool:

    Per istruzioni su come aggiungere e aggiornare un pool di nodi, consulta Gestisci i node pool in un cluster.

    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

    Dopo aver aggiunto o aggiornato il pool di nodi, attendi che tutte le macchine bare metal nel pool di nodi raggiungano lo stato Ready.

  4. Per controllare lo stato delle macchine bare metal del cluster, utilizza il seguente comando:

    kubectl get baremetalmachines --kubeconfig ADMIN_KUBECONFIG -A

    Quando le macchine bare metal sono pronte, la risposta dovrebbe essere simile alla seguente risposta di esempio:

    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

Limitazioni

L'operatore GPU NVIDIA in bundle presenta le seguenti limitazioni:

  • L'operatore GPU NVIDIA in bundle supporta solo i seguenti componenti software NVIDIA:

    • NVIDIA Container Toolkit
    • NVIDIA DCGM Exporter
    • Plug-in del dispositivo NVIDIA Kubernetes
    • NVIDIA MIG Manager per Kubernetes.

  • Durante l'anteprima, la configurazione dell'operatore GPU NVIDIA è fissa. Se provi a personalizzare le impostazioni, queste vengono ripristinate alle impostazioni di installazione originali.

  • L'operatore GPU NVIDIA in bundle non può essere utilizzato per installare i driver GPU NVIDIA.

  • Durante l'anteprima, questa funzionalità utilizza il gruppo di API resource.k8s.io/v1beta1, che è diverso dal gruppo di API Kubernetes open source per questa funzionalità, resource.k8s.io/v1. Il gruppo di API open source v1 offre più funzionalità e una maggiore stabilità rispetto al gruppo di API v1beta1.

Passaggi successivi

Documentazione di riferimento