Cette page a été traduite par l'API Cloud Translation.

Mettre à jour les clusters

Une fois le cluster créé, vous pouvez modifier certains aspects de sa configuration. Par exemple :

Ajoutez, supprimez ou remplacez des nœuds.
Ajoutez ou supprimez des annotations dans le cluster.
Modifiez les valeurs des champs modifiables dans les ressources de cluster et de pool de nœuds.
Modifiez d'autres ressources personnalisées.

Vous pouvez utiliser bmctl ou la Google Cloud CLI pour modifier un cluster. Si vous avez créé un cluster d'administrateur ou d'utilisateur à l'aide de Terraform, vous pouvez l'utiliser pour le mettre à jour. Veuillez noter les points suivants :

De nombreux aspects de la configuration de votre cluster sont immuables et ne peuvent pas être mis à jour après la création du cluster. Pour obtenir la liste complète des champs modifiables et immuables, consultez la documentation de référence sur les champs de configuration de cluster. La référence de champ est une table triable. Cliquez sur les en-têtes de colonne pour modifier l'ordre de tri. Cliquez sur un nom de champ pour afficher sa description.
La gcloud CLI et Terraform ne permettent de mettre à jour que les clusters d'administrateur et d'utilisateur. Vous devez utiliser bmctl pour mettre à jour d'autres types de clusters.
La gcloud CLI et Terraform ne permettent de modifier que les ressources de cluster et de pool de nœuds. Vous devez utiliser kubectl ou bmctl pour mettre à jour les autres ressources personnalisées qui affectent le cluster.

La modification de l'espace de noms d'un cluster existant dans le fichier de configuration du cluster est not a supported operation et peut entraîner une instabilité du cluster et des échecs potentiels. Pour éviter ces problèmes, n'essayez pas de modifier l'espace de noms du cluster après sa création.

Cette page est destinée aux administrateurs, aux architectes et aux opérateurs qui gèrent le cycle de vie de l'infrastructure technologique sous-jacente. Pour en savoir plus sur les rôles courants et les exemples de tâches que nous citons dans le contenu Google Cloud , consultez Rôles utilisateur et tâches courantes de GKE Enterprise.

Mettre à jour les clusters

En général, vous effectuez la séquence d'actions suivante pour mettre à jour un cluster :

`bmctl`

Modifiez les valeurs des champs applicables dans le fichier de configuration du cluster, qui se trouve par défaut ici :
bmctl-workspace/CLUSTER-NAME/CLUSTER-NAME.yaml
Mettez à jour le cluster en exécutant la commande bmctl update :
```
bmctl update cluster -c CLUSTER_NAME --kubeconfig=KUBECONFIG
```
Remplacez les éléments suivants :
- CLUSTER_NAME : nom du cluster que vous souhaitez mettre à jour.
- KUBECONFIG : pour les clusters d'administrateur, hybrides ou autonomes, saisissez le chemin d'accès au fichier kubeconfig du cluster. Pour un cluster d'utilisateur, saisissez le chemin d'accès au fichier kubeconfig du cluster d'administrateur.

N'utilisez pas bmctl update et kubectl apply -f de manière interchangeable lorsque vous modifiez le fichier de configuration du cluster. Lorsque ces commandes sont utilisées de manière interchangeable, le contenu renseigné par l'en-tête de la spécification du cluster peut être supprimé involontairement. Par exemple, vous pouvez utiliser bmctl update pour mettre à jour le fichier de configuration du cluster afin de configurer un miroir de registre. Le cluster est ensuite renseigné dans spec.nodeConfig.registryMirrors après la réconciliation.

Si vous essayez ensuite de modifier le cluster à l'aide de la configuration du cluster avec la commande kubectl apply -f, le spec.nodeConfig.registryMirrors renseigné par le réconciliateur sur le cluster est supprimé. Ce comportement se produit, car la configuration n'existe pas dans la spécification de configuration du cluster, mais elle existe dans le cluster.

gcloud CLI

Spécifiez uniquement les indicateurs de la configuration que vous souhaitez modifier.
Exécutez la commande de mise à jour applicable :
- Clusters d'administrateurs : gcloud container bare-metal admin-clusters update
- Clusters d'utilisateurs : gcloud container bare-metal clusters update.
- Pools de nœuds sur un cluster d'utilisateur : gcloud container bare-metal node-pools update

Terraform

Modifiez les valeurs des champs applicables dans le fichier de configuration Terraform que vous avez utilisé pour créer le cluster ou le pool de nœuds. Pour obtenir des descriptions détaillées des champs, consultez la documentation de référence Terraform :
Mettez à jour la configuration en exécutant la commande terraform apply.

Les sections suivantes décrivent quelques exemples courants de mise à jour d'un cluster existant.

Ajouter ou supprimer des nœuds dans un cluster

Un pool de nœuds est un groupe de nœuds au sein d'un cluster qui possèdent tous la même configuration. N'oubliez pas qu'un nœud appartient toujours à un pool de nœuds. Pour ajouter un nœud à un cluster, vous devez l'ajouter à un pool de nœuds spécifique. Supprimer un nœud d'un pool de nœuds revient à supprimer le nœud du cluster.

Dans Google Distributed Cloud, il existe trois types de pools de nœuds : plan de contrôle, équilibreur de charge et pools de nœuds de calcul. Les sections suivantes décrivent comment ajouter ou supprimer des nœuds de chaque type de pool de nœuds.

`bmctl`

Pour ajouter ou supprimer un nœud d'un pool de nœuds, vous devez ajouter ou supprimer l'adresse IP du nœud dans une section spécifique du fichier de configuration du cluster. La liste suivante indique la section à modifier pour un pool de nœuds donné :

Pool de nœuds de calcul : ajoutez ou supprimez l'adresse IP du nœud dans la section spec.nodes de la spécification NodePool.
Pool de nœuds du plan de contrôle : ajoutez ou supprimez l'adresse IP du nœud dans la section spec.controlPlane.nodePoolSpec.nodes de la spécification Cluster.
Pool de nœuds d'équilibreur de charge : ajoutez ou supprimez l'adresse IP du nœud dans la section spec.loadBalancer.nodePoolSpec.nodes de la spécification Cluster.

Exemple : supprimer un nœud de calcul

Voici un exemple de fichier de configuration de cluster qui montre les spécifications de deux nœuds de calcul :

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

Pour supprimer un nœud :

(Facultatif) Si le nœud que vous supprimez exécute des pods critiques, commencez par le passer en mode maintenance.

Vous pouvez surveiller le processus de vidange des nœuds de calcul en affichant les champs status.nodesDrained et status.nodesDraining sur la ressource NodePool.
Modifiez le fichier de configuration du cluster pour supprimer l'entrée d'adresse IP du nœud.

Mettez à jour le cluster :

bmctl update cluster1 \
    --kubeconfig=ADMIN_KUBECONFIG

gcloud CLI

Vous utilisez une commande update pour ajouter ou supprimer des nœuds. La commande update que vous utilisez et l'indicateur dans lequel vous spécifiez l'adresse IP dépendent du type de pool de nœuds que vous souhaitez mettre à jour :

Pool de nœuds de calcul : exécutez gcloud container bare-metal node-pools update et spécifiez l'adresse IP dans l'indicateur --node-configs 'node-ip=IP_ADDRESS'.
Pool de nœuds du plan de contrôle sur un cluster d'administrateur : exécutez gcloud container bare-metal admin-clusters update et spécifiez l'adresse IP dans l'indicateur --control-plane-node-configs 'node-ip=IP_ADDRESS'.
Pool de nœuds du plan de contrôle sur un cluster d'utilisateur : exécutez gcloud container bare-metal clusters update et spécifiez l'adresse IP dans l'indicateur --control-plane-node-configs 'node-ip=IP_ADDRESS'.
Pool de nœuds de l'équilibreur de charge : exécutez gcloud container bare-metal clusters update et spécifiez l'adresse IP dans l'indicateur --metal-lb-load-balancer-node-configs 'node-ip=IP_ADDRESS' ou
.--bgp-load-balancer-node-configs 'node-ip=IP_ADDRESS'

L'indicateur dans lequel vous spécifiez l'adresse IP n'accepte qu'un seul node-ip. Vous devez inclure le flag pour chaque adresse IP du pool de nœuds.

Les commandes update remplacent toutes les adresses IP par celles que vous spécifiez. Pour ajouter un nœud, incluez les adresses IP des nœuds existants et celle du nouveau nœud dans la commande update. De même, vous supprimez des nœuds en n'incluant que les adresses IP des nœuds que vous souhaitez conserver.

Exemple : supprimer un nœud de calcul

Cette section explique comment supprimer un nœud de calcul d'un pool de nœuds à l'aide d'exemples de données. D'autres commandes gcloud CLI qui pourraient vous être utiles sont également incluses dans les étapes suivantes.

(Facultatif) Si le nœud que vous supprimez exécute des pods critiques, commencez par le passer en mode maintenance.

Vous pouvez surveiller le processus de vidange des nœuds de calcul en affichant les champs status.nodesDrained et status.nodesDraining sur la ressource NodePool.

Exécutez la commande list pour lister tous les pools de nœuds du cluster :

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

Le résultat ressemble à ce qui suit :

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

Exécutez la commande describe pour lister toutes les adresses IP du pool de nœuds :
```
gcloud container bare-metal node-pools describe node-pool-1 \
    --cluster=abm-user-cluster1 \
    --project=example-project-12345 \
    --location=us-central1
```
L'exemple de résultat suivant est tronqué pour des raisons de lisibilité :
```
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
...
```
Notez les points suivants dans l'exemple de résultat :
- Le champ name contient le nom complet du pool de nœuds. Lorsque vous spécifiez le nom du pool de nœuds dans une commande, vous pouvez indiquer le nom complet ou le nom du pool de nœuds, par exemple node-pool-1, ainsi que les indicateurs --cluster, --project et --location.
- La section nodeConfigs contient deux champs nodeIp avec les adresses IP des nœuds.
Exécutez la commande suivante pour supprimer le nœud avec l'adresse 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'
```
La commande update remplace toutes les adresses IP par celles que vous spécifiez. Comme 192.0.2.1 n'est pas inclus, le nœud est supprimé.

La sortie de la commande ressemble à ceci :
```
Waiting for operation [projects/example-project-12345/locations/us-central1/operations/operation-1697154681749-6078d9def4030-76686d6e-9fcb1de9] to complete
```
Dans l'exemple de résultat, la chaîne operation-1697154681749-6078d9def4030-76686d6e-9fcb1de9 est le OPERATION_ID de l'opération de longue durée. Vous pouvez vérifier l'état de l'opération en exécutant la commande suivante dans une autre fenêtre de terminal :
```
gcloud container bare-metal operations describe operation-1697154681749-6078d9def4030-76686d6e-9fcb1de9 \
    --project= example-project-12345 \
    --location=us-central1
```
Vous pouvez réexécuter la commande de temps en temps pour vérifier l'état.

Si la suppression du nœud échoue, vous pouvez forcer sa suppression du cluster. Pour en savoir plus, consultez Réinitialiser un nœud défaillant dans Google Distributed Cloud.

Remplacer les nœuds du plan de contrôle à haute disponibilité

`bmctl`

Vous pouvez utiliser bmctl pour remplacer les nœuds de plan de contrôle à haute disponibilité (HA) dans tous les types de clusters.

Pour remplacer un nœud dans un cluster, procédez comme suit :

Supprimez l'adresse IP du nœud du fichier de configuration du cluster.
Mettez à jour le cluster.
Vérifiez l'état des nœuds du cluster.
Ajoutez l'adresse IP d'un nouveau nœud au même fichier de configuration du cluster.
Mettez à jour le cluster.

Exemple : remplacer un nœud de plan de contrôle à haute disponibilité

Voici un exemple de fichier de configuration de cluster qui montre trois nœuds de plan de contrôle dans un cluster d'utilisateur :

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

Pour remplacer le dernier nœud listé dans la section spec.controlPlane.nodePoolSpec.nodes, procédez comme suit :

Supprimez le nœud en supprimant son entrée d'adresse IP dans le fichier de configuration du cluster. Une fois cette modification effectuée, le fichier de configuration du cluster doit se présenter comme suit :

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

Mettez à jour le cluster en exécutant la commande suivante :
```
bmctl update cluster -c CLUSTER_NAME \
  --kubeconfig=KUBECONFIG
```
Apportez les modifications suivantes :
- Remplacez CLUSTER_NAME par le nom du cluster que vous souhaitez mettre à jour.
- Si le cluster est un cluster autogéré (tel qu'un cluster d'administrateur ou autonome), remplacez KUBECONFIG par le chemin d'accès au fichier kubeconfig du cluster. Si le cluster est un cluster d'utilisateur, comme dans cet exemple, remplacez KUBECONFIG par le chemin d'accès au fichier kubeconfig du cluster d'administrateur.
Une fois la commande bmctl update exécutée, les jobs machine-preflight et machine-init prennent un certain temps à se terminer. Vous pouvez afficher l'état des nœuds et de leurs pools de nœuds respectifs en exécutant les commandes décrites dans la section Vérifier vos mises à jour de ce document. Une fois que le pool de nœuds et les nœuds sont prêts, vous pouvez passer à l'étape suivante.
Ajoutez un nœud de plan de contrôle au pool de nœuds en ajoutant l'adresse IP du nouveau nœud de plan de contrôle à la section spec.controlPlane.nodePoolSpec.nodes du fichier de configuration du cluster. Une fois cette modification effectuée, le fichier de configuration du cluster doit se présenter comme suit :
```
---
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
```

Mettez à jour le cluster en exécutant la commande suivante :

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

gcloud CLI

Vous pouvez utiliser gcloud CLI pour remplacer les nœuds de plan de contrôle à haute disponibilité dans les clusters d'administrateur et d'utilisateur.

Pour remplacer un nœud dans un cluster, procédez comme suit :

Supprimez l'adresse IP du nœud en exécutant la commande update applicable :
- Cluster d'utilisateur : gcloud container bare-metal clusters update
- Cluster d'administrateur : gcloud container bare-metal admin-clusters update
Vérifiez l'état de la suppression du nœud dans le cluster en exécutant gcloud container bare-metal operations describe OPERATION_ID.
Ajoutez l'adresse IP du nouveau nœud en exécutant la commande update applicable.

Exemple : remplacer un nœud de plan de contrôle à haute disponibilité

Cette section explique comment remplacer un plan de contrôle d'un cluster à l'aide d'exemples de données. D'autres commandes gcloud CLI qui pourraient vous être utiles sont également incluses dans les étapes suivantes.

Exécutez la commande list pour lister tous les clusters d'utilisateur dans un projetGoogle Cloud :
```
gcloud container bare-metal clusters list \
    --project=example-project-12345 \
    --location=-
```
Lorsque vous définissez --location=-, cela signifie que vous souhaitez lister tous les clusters de toutes les régions. Si vous devez limiter la liste, définissez --location sur une région spécifique.

Le résultat ressemble à ce qui suit :
```
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
```
Exécutez la commande describe sur le cluster :
```
gcloud container bare-metal clusters describe abm-user-cluster1  \
    --project=example-project-12345 \
    --location=us-central1
```
L'exemple de résultat est tronqué pour des raisons de lisibilité :
```
...
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
...
```
Notez les points suivants dans l'exemple de résultat :
- Le champ name contient le nom complet du cluster. Lorsque vous spécifiez le nom du cluster dans une commande, vous pouvez indiquer le nom complet ou le nom du cluster, par exemple abm-user-cluster1a, ainsi que --project et --location flags.
- La section nodeConfigs contient trois champs nodeIp avec les adresses IP des nœuds du plan de contrôle.

Supprimez le nœud avec l'adresse 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'

La sortie de la commande ressemble à ceci :

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

Dans l'exemple de résultat, la chaîne operation-1956154681749-6078d9def4030-76686d6e-9fcb1de7 est le OPERATION_ID de l'opération de longue durée. Vous pouvez vérifier l'état de l'opération en exécutant la commande suivante dans une autre fenêtre de terminal :

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

Vous pouvez réexécuter la commande de temps en temps pour vérifier l'état.

Ajoutez le nouveau nœud avec l'adresse 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'

Vérifier vos modifications

`kubectl`

Vous pouvez afficher l'état des nœuds et de leurs pools de nœuds respectifs à l'aide de la commande kubectl get.

Par exemple, la commande suivante affiche l'état des pools de nœuds dans l'espace de noms du cluster cluster-my-cluster :

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

Le système renvoie des résultats semblables à ceux-ci :

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 signifie que l'étape de rapprochement est toujours en cours. Vous devez attendre que l'état passe à Reconciling=0.

Vous pouvez également vérifier l'état des nœuds d'un cluster en exécutant la commande suivante :

kubectl get nodes --kubeconfig=KUBECONFIG

gcloud CLI

Comme décrit précédemment, après avoir exécuté une commande update, vous pouvez vérifier l'état de l'opération à l'aide de gcloud container bare-metal operations describe OPERATIONS_ID. Le résultat de la commande indique l'état des nœuds. Par exemple :

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

Quel que soit l'outil que vous utilisez pour mettre à jour un pool de nœuds, vous pouvez obtenir l'état actuel d'un pool de nœuds en exécutant la commande describe applicable, comme indiqué précédemment.

Si vous avez besoin d'informations supplémentaires sur le diagnostic de vos clusters, consultez la page Créer des instantanés pour diagnostiquer les clusters.

Pools d'adresses de l'équilibreur de charge

bmctl

La section addressPools contient des champs permettant de spécifier des pools d'équilibrage de charge pour les équilibreurs de charge groupés MetalLB et BGP (Border Gateway Protocol). Vous pouvez ajouter d'autres pools d'adresses d'équilibrage de charge à tout moment, mais vous ne pouvez pas supprimer les pools d'adresses existants. À partir de la version 1.16.0 de Google Distributed Cloud, vous pouvez modifier les valeurs de addressPools.avoidBuggyIPs et addressPools.manualAssign à tout moment.

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

Vous pouvez ajouter d'autres pools d'adresses d'équilibrage de charge à tout moment pour les équilibreurs de charge groupés, mais vous ne pouvez pas supprimer les pools d'adresses existants. L'indicateur que vous spécifiez dans gcloud container bare-metal clusters update pour ajouter un pool d'adresses dépend du type d'équilibreur de charge groupé :

MetalLB (couche 2) : utilisez l'option --metal-lb-address-pools.
Border Gateway Protocol (BGP) : utilisez l'option --bgp-address-pools.

La valeur des indicateurs est au format suivant :

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

La valeur comporte des segments qui commencent par les mots clés pool, avoid-buggy-ip, manual-assign et addresses. Séparez chaque segment par une virgule.

pool : Nom de votre choix pour le pool de nœuds.
avoid-buggy-ips : Si vous définissez cette valeur sur True, le contrôleur de gestion des adresses IP (IPAM) n'attribue pas les adresses IP se terminant par .0 ou .255 aux services. Cela évite le problème des bugs avec les appareils grand public qui suppriment par erreur le trafic envoyé à ces adresses IP spéciales. Si aucune valeur n'est spécifiée, la valeur par défaut est False. À partir de la version 1.16.0 de Google Distributed Cloud, vous pouvez modifier cette valeur dans un pool d'adresses existant.
manual-assign : Si vous ne souhaitez pas que le contrôleur IPAM attribue automatiquement les adresses IP de ce pool aux services, définissez ce paramètre sur True. Un développeur peut ensuite créer un service de type LoadBalancer et spécifier manuellement l'une des adresses du pool. Si aucune valeur n'est spécifiée, manual-assign est défini sur False. À partir de la version 1.16.0 de Google Distributed Cloud, vous pouvez modifier cette valeur dans un pool d'adresses existant.
Dans la liste addresses : chaque adresse doit être une plage au format CIDR ou au format de plage avec trait d'union. Pour spécifier une seule adresse IP dans un pool (par exemple, pour l'adresse IP virtuelle d'entrée), utilisez /32 au format CIDR (par exemple, 192.0.2.1/32).

Notez les règles de syntaxe suivantes :

Placez l'intégralité de la valeur entre guillemets simples.
Les espaces ne sont pas autorisés.
Séparez chaque plage d'adresses IP par un point-virgule.

Vous pouvez spécifier plusieurs instances de l'indicateur, comme illustré dans l'exemple suivant :

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

Pour en savoir plus sur les pools d'adresses de l'équilibreur de charge, consultez loadBalancer.addressPools dans "Configurer un équilibrage de charge groupé".

Empêcher la suppression accidentelle d'un cluster

`bmctl`

Si vous ajoutez l'annotation baremetal.cluster.gke.io/prevent-deletion: "true" au fichier de configuration de votre cluster, vous ne pourrez pas supprimer le cluster. Par exemple, l'exécution de kubectl delete cluster ou bmctl reset cluster génère une erreur.

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 vous spécifiez l'option --add-annotations avec la valeur baremetal.cluster.gke.io/prevent-deletion="true", vous ne pouvez pas supprimer le cluster. Exemple :

Ajoutez l'annotation pour éviter la suppression accidentelle du 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"

Essayez de supprimer le cluster d'utilisateur :

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

La réponse de la commande ressemble à ce qui suit :

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

Pour supprimer l'annotation, spécifiez --remove-annotations=baremetal.cluster.gke.io/prevent-deletion="true" dans la commande update.

Contourner les vérifications préliminaires

Cette fonctionnalité n'est disponible qu'avec bmctl update.

La valeur par défaut du champ bypassPreflightCheck est false. Si vous définissez ce champ sur true dans le fichier de configuration du cluster, les vérifications internes préliminaires sont ignorées lorsque vous appliquez les ressources aux clusters existants.

  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

Ajouter ou supprimer des administrateurs de cluster

`bmctl`

Vous pouvez ajouter ou supprimer un utilisateur ou un compte de service en tant qu'administrateur de cluster pour un cluster d'utilisateur en spécifiant des adresses e-mail dans la section clusterSecurity.authorization.clusterAdmin.gcpAccounts du fichier de configuration du cluster. Les comptes se voient attribuer le rôle cluster-admin sur le cluster, ce qui leur donne un accès complet au 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.iam.gserviceaccount.com

Lorsque vous mettez à jour un cluster d'utilisateur pour ajouter un compte, veillez à inclure tous les comptes dans la liste (comptes existants et nouveaux comptes), car bmctl update remplace la liste par ce que vous spécifiez dans le fichier de configuration. Pour supprimer un compte, supprimez-le du fichier de configuration du cluster et exécutez bmctl update.

gcloud CLI

Vous pouvez ajouter ou supprimer un utilisateur ou un compte de service en tant qu'administrateur de cluster en spécifiant une adresse e-mail dans l'indicateur --admin-users. L'indicateur n'accepte qu'une seule adresse e-mail. Pour ajouter plusieurs utilisateurs, spécifiez un compte dans chaque indicateur. Par exemple :

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

La commande update remplace l'intégralité de la liste des attributions. Spécifiez tous les utilisateurs existants et nouveaux que vous souhaitez désigner comme administrateurs du cluster.

Définir un utilisateur pour la connexion

Vous pouvez spécifier un nom d'utilisateur non racine que vous souhaitez utiliser pour accéder aux machines de nœud de votre cluster (fonctionnalité sudo sans mot de passe). Votre clé SSH, sshPrivateKeyPath, doit fonctionner pour l'utilisateur spécifié. Les opérations de création et de mise à jour du cluster vérifient que les machines de nœud sont accessibles avec l'utilisateur et la clé SSH spécifiés.

`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

Vous spécifiez l'utilisateur que vous souhaitez utiliser pour accéder aux machines de nœud dans l'indicateur --login-user, par exemple :

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

Pour activer l'accès sudo sans mot de passe pour un utilisateur, procédez comme suit sur chaque machine de nœud de cluster :

Utilisez sudo visudo pour ouvrir le fichier sudoers et le modifier :
```
sudo visudo -f /etc/sudoers
```
La commande visudo verrouille le fichier sudoers pour empêcher les modifications simultanées et valide la syntaxe du fichier lors de l'enregistrement.
Pour votre utilisateur de connexion, ajoutez une entrée au fichier sudoers comme suit :
```
USERNAME ALL=(ALL) NOPASSWD: ALL
```
Fermez le fichier et enregistrez-le.
Pour exécuter des commandes avec les droits de votre utilisateur de connexion, exécutez la commande suivante :
```
su - USERNAME
```
Pour vérifier qu'aucun mot de passe n'est requis pour que votre utilisateur de connexion exécute les commandes sudo, exécutez la commande sudo suivante :
```
sudo ip a
```

Paramètres réseau avancés

Vous configurez les fonctionnalités de mise en réseau avancées dans différentes ressources personnalisées après la création du cluster. Pour utiliser les ressources personnalisées et les fonctionnalités de mise en réseau associées, vous devez activer la mise en réseau avancée lorsque vous créez votre cluster.

`bmctl`

Définissez clusterNetwork.advancedNetworking sur true dans la configuration du cluster lorsque vous le créez :

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

gcloud CLI

Incluez l'option --enable-advanced-networking dans la commande gcloud container bare-metal clusters create lorsque vous créez votre cluster.

Une fois le cluster créé avec la mise en réseau avancée activée, vous pouvez configurer les ressources personnalisées décrites dans cette section à l'aide de kubectl apply.

`NetworkGatewayGroup`

La ressource personnalisée NetworkGatewayGroup permet de fournir des adresses IP flottantes pour les fonctionnalités de mise en réseau avancées, telles que la passerelle NAT de sortie ou l'équilibrage de charge groupé avec BGP.

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

Équilibrage de charge BGP

Vous configurez l'équilibrage de charge du protocole BGP (Border Gateway Protocol) dans la ressource de cluster et d'autres ressources personnalisées. Les commandes gcloud container bare-metal clusters create et update permettent de configurer BGP dans la ressource de cluster, mais pas dans les ressources personnalisées.

Lorsque vous configurez des équilibreurs de charge groupés avec BGP, l'équilibrage de charge du plan de données utilise par défaut les mêmes pairs externes que ceux spécifiés pour l'appairage de plans de contrôle. Vous pouvez également configurer l'équilibrage de charge du plan de données séparément, en utilisant la ressource personnalisée BGPLoadBalancer et la ressource personnalisée BGPPeer. Pour en savoir plus, consultez la section Configurer des équilibreurs de charge groupés avec 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

Augmenter la couverture du réseau de services

Pour créer plus de services que la limite initiale, vous pouvez réduire le masque CIDR du service IPv4 afin d'augmenter le réseau de services de votre cluster. Si vous réduisez le masque (la valeur après "/"), la plage réseau sera plus étendue. Vous ne pouvez qu'augmenter la plage du CIDR de service IPv4. La plage réseau ne peut pas être réduite, ce qui signifie que le masque (la valeur après "/") ne peut pas être augmenté.

`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

Pour augmenter la plage CIDR du service IPv4 sur un cluster d'utilisateur, spécifiez la nouvelle plage dans l'indicateur --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

Configurer les paramètres de récupération d'images kubelet

Le kubelet s'exécute sur chaque nœud de votre cluster. kubelet est chargé de surveiller les conteneurs sur un nœud et de s'assurer qu'ils sont en bon état. Si nécessaire, le kubelet interroge et extrait les images d'Artifact Registry.

Il peut être difficile de mettre à jour manuellement vos configurations kubelet et de les synchroniser sur tous les nœuds de votre cluster. Pire encore, les modifications manuelles de la configuration kubelet sur vos nœuds sont perdues lorsque vous mettez à niveau votre cluster.

Pour faciliter les mises à jour synchronisées et persistantes, Google Distributed Cloud vous permet de spécifier certains paramètres kubelet pour chacun de vos pools de nœuds de cluster : nœuds du plan de contrôle, nœuds d'équilibreur de charge et nœuds de calcul. Les paramètres s'appliquent à tous les nœuds d'un pool donné et persistent lors des mises à niveau du cluster. Les champs de ces paramètres sont modifiables. Vous pouvez donc les mettre à jour à tout moment, et pas seulement lors de la création du cluster.

`bmctl`

Les champs compatibles suivants contrôlent les opérations d'extraction Artifact Registry pour kubelet :

registryBurst (par défaut : 10)
registryPullQPS (par défaut : 5)
serializeImagePulls (par défaut : true)

Pour en savoir plus sur chacun des champs de configuration de kubelet, consultez la documentation de référence sur les champs de configuration de cluster.

Vous pouvez spécifier ces champs dans les sections kubeletConfig de la spécification du cluster et de la spécification NodePool pour les pools de nœuds suivants :

Spécification du cluster :
Nœuds du plan de contrôle spec.controlPlane.nodePoolSpec.kubeletConfig
Nœuds d'équilibrage de charge spec.loadBalancer.nodePoolSpec.kubeletConfig
Spécification NodePool :
Nœuds de calcul spec.kubeletConfig

L'exemple suivant montre les champs ajoutés avec leurs valeurs par défaut dans le fichier de configuration du cluster. Notez que l'annotation preview.baremetal.cluster.gke.io/custom-kubelet: "enable" est obligatoire.

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

Dans chaque cas, le paramètre s'applique à tous les nœuds du pool.

gcloud CLI

Les indicateurs suivants contrôlent les opérations d'extraction Artifact Registry pour kubelet :

Utilisation

Voici quelques points à prendre en compte pour ajuster les extractions d'images :

Étant donné que les images sont extraites en série par défaut, une extraction d'image qui prend beaucoup de temps peut retarder toutes les autres extractions d'images planifiées sur un nœud. Les extractions d'images différées peuvent bloquer le processus de mise à niveau (en particulier lorsque de nouvelles images Google Distributed Cloud doivent être déployées sur un nœud). Si vous êtes concerné par des retards d'extraction d'images, vous pouvez désactiver la sérialisation des extractions d'images pour autoriser les extractions d'images parallèles.
Si vous rencontrez des erreurs de limitation de l'extraction d'images, telles que pull QPS exceeded, vous pouvez augmenter *-registry-pull-qps et *-registry-burst pour augmenter le débit d'extraction d'images. Ces deux champs ajustent le taux d'extraction et la taille de la file d'attente, et peuvent aider à résoudre d'autres problèmes liés à la limitation du débit. Les valeurs négatives ne sont pas autorisées.

Personnalisation de Keepalived

À partir de la version 1.32, Google Distributed Cloud permet de personnaliser la configuration Keepalived. Avec l'équilibrage de charge groupé, l'équilibreur de charge du plan de contrôle diffuse l'adresse IP virtuelle (VIP) du plan de contrôle. Google Distributed Cloud exécute Keepalived et HAProxy en tant que pods statiques Kubernetes sur les nœuds de l'équilibreur de charge pour annoncer l'adresse IP virtuelle du plan de contrôle. Keepalived utilise le protocole VRRP (Virtual Router Redundancy Protocol) sur les nœuds d'équilibrage de charge, pour une haute disponibilité.

Les clusters de la version 1.32 et ultérieures présentent les personnalisations Keepalived suivantes :

Pour les plans de contrôle à haute disponibilité, Google Distributed Cloud configure automatiquement la configuration Keepalived VRRP afin de rendre le comportement de basculement déterministe et d'empêcher l'entrelacement des réponses ARP avec différentes adresses MAC :
- Chaque instance Keepalived est configurée automatiquement avec une valeur priority différente dans le routeur VRRP.
- Chaque instance Keepalived est configurée automatiquement avec nopreempt pour éviter les élections lorsqu'une instance non principale est redémarrée.
Google Distributed Cloud vous permet de spécifier le nombre de messages ARP gratuits (GARP) à envoyer à la fois après qu'un nœud de plan de contrôle est devenu le serveur maître. Pour modifier le nombre de messages GARP à envoyer, ajoutez le champ controlPlane.loadBalancer.keepalivedVRRPGARPMasterRepeat au fichier de configuration du cluster, définissez-le sur la nouvelle valeur, puis mettez à jour votre cluster. Cette valeur correspond au paramètre vrrp_garp_master_repeat pour Keepalived. La valeur par défaut est 5.

L'exemple suivant montre comment spécifier keepalivedVRRPGARPMasterRepeat dans le fichier de configuration du 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.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
  ...
```

Installer ou désinstaller l'opérateur GPU NVIDIA fourni

L'opérateur GPU NVIDIA vous permet d'exécuter des charges de travail liées aux GPU dans vos clusters. À partir de la version 1.33.0 de Google Distributed Cloud, les clusters sont fournis avec une pile complète d'opérateurs GPU NVIDIA pour fournir une solution gérée permettant de gérer les composants logiciels NVIDIA nécessaires au provisionnement des GPU sur les nœuds de calcul de votre cluster.

Prérequis

Avant d'installer l'opérateur de GPU NVIDIA fourni, assurez-vous que votre environnement répond aux exigences suivantes :

Cluster opérationnel : vous avez créé un cluster Bare Metal fonctionnel avec Google Distributed Cloud.
GPU NVIDIA : les GPU NVIDIA sont installés sur les nœuds de calcul de votre cluster. La section suivante sur l'installation de l'opérateur GPU NVIDIA inclut des étapes permettant de vérifier que les GPU sont correctement installés et reconnus par votre système d'exploitation.
Version du pilote NVIDIA compatible : la version du pilote NVIDIA que vous utilisez doit être compatible avec votre GPU, votre système d'exploitation et la version CUDA utilisée par vos applications. Pour en savoir plus, consultez Informations sur les versions.

Vous disposez des options d'installation de pilote NVIDIA suivantes :
- Utilisez le pilote NVIDIA préinstallé dans l'image de votre système d'exploitation.
- Suivez les instructions du Guide de démarrage rapide pour l'installation du pilote NVIDIA pour installer manuellement le pilote NVIDIA.
Le pilote de GPU NVIDIA doit être installé et prêt avant que vous n'activiez l'opérateur de GPU NVIDIA fourni.

Informations sur la version

Cette section contient des informations sur la version du logiciel de l'opérateur GPU NVIDIA fourni.

Versions des composants logiciels

La version 1.33 de Google Distributed Cloud inclut la version 25.3.1 de l'opérateur GPU NVIDIA. Dans Google Distributed Cloud, le bundle contient les images suivantes :

NVIDIA Container Toolkit version 1.17.8
NVIDIA DCGM Exporter v3.3.9-3.6.1
Plug-in d'appareil NVIDIA Kubernetes v0.17.1
Node Feature Discovery v0.17.2

Il est possible que les versions d'image fournies avec Google Distributed Cloud version 1.33 ne correspondent pas exactement aux versions des composants logiciels listées dans les notes de version 25.3.1.

Compatibilité des pilotes

Pour en savoir plus sur la compatibilité des pilotes, consultez la page Prise en charge des plates-formes pour la version 25.3.1 sur le hub de documentation NVIDIA.

Mettre à jour l'opérateur GPU NVIDIA fourni

Si vous avez installé l'opérateur GPU NVIDIA sur votre cluster, la dernière version groupée de l'opérateur GPU NVIDIA est installée lorsque vous passez à une nouvelle version mineure.

Installer l'opérateur fourni

Tant que l'opérateur GPU NVIDIA fourni est en version Preview, vous l'installez à l'aide de bmctl update pour ajouter l'annotation suivante au cluster comportant des nœuds 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 pile de l'opérateur GPU NVIDIA est installée dans le cluster lorsque l'annotation est appliquée.

Désinstaller l'opérateur fourni

Tant que l'opérateur GPU NVIDIA fourni est en version Preview, vous pouvez le désinstaller à l'aide de bmctl update pour supprimer l'annotation suivante du cluster comportant des nœuds GPU :

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

Tous les composants de la pile de l'opérateur GPU NVIDIA sont supprimés du cluster lorsque l'annotation est supprimée.

Activer l'allocation dynamique des ressources

L'allocation dynamique des ressources est une API Kubernetes qui vous permet de demander et de partager des ressources génériques, telles que des GPU, entre les pods et les conteneurs. Les pilotes tiers gèrent ces ressources. Cette fonctionnalité vous aide à exécuter des charges de travail d'IA en allouant de manière dynamique et précise les ressources GPU dans vos clusters Bare Metal, ce qui améliore l'utilisation des ressources et les performances pour les charges de travail exigeantes.

L'allocation dynamique des ressources est disponible en aperçu pour les clusters de version 1.33 et ultérieures. Les instructions suivantes décrivent comment configurer votre cluster pour utiliser l'allocation dynamique des ressources. Une fois l'allocation dynamique des ressources activée, vous pouvez configurer vos charges de travail de GPU pour qu'elles l'utilisent.

Configurez votre cluster pour activer l'allocation dynamique des ressources :

Modifiez le fichier de configuration de votre cluster pour inclure l'annotation d'aperçu preview.baremetal.cluster.gke.io/dynamic-resource-allocation: "enable" et ajoutez DynamicResourceAllocation: true sous featureGates dans la section 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

Mettez à jour le cluster en exécutant la commande bmctl update :
```
bmctl update cluster -c CLUSTER_NAME \
    --kubeconfig=ADMIN_KUBECONFIG
```
Remplacez les éléments suivants :
- CLUSTER_NAME : nom du cluster d'utilisateur que vous mettez à jour.
- ADMIN_KUBECONFIG : chemin d'accès au fichier kubeconfig du cluster d'administrateur
Une fois cette configuration appliquée, le champ READY de vos machines Bare Metal peut basculer plusieurs fois entre True et False. Attendez que le champ READY se stabilise sur True avant de continuer.
Pour activer la fonctionnalité DynamicResourceAllocation dans les pools de nœuds comportant des nœuds avec GPU, définissez DynamicResourceAllocation sur true dans la section featureGates de la section kubeletConfig de la spécification NodePool :

Pour savoir comment ajouter et mettre à jour un pool de nœuds, consultez Gérer les pools de nœuds dans 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
```
Après avoir ajouté ou mis à jour le pool de nœuds, attendez que toutes les machines bare metal du pool de nœuds atteignent l'état Ready.

Pour vérifier l'état des machines bare metal de votre cluster, utilisez la commande suivante :

kubectl get baremetalmachines --kubeconfig ADMIN_KUBECONFIG -A

Lorsque les machines bare metal sont prêtes, la réponse doit ressembler à l'exemple suivant :

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

Limites

L'opérateur GPU NVIDIA fourni présente les limites suivantes :

L'opérateur GPU NVIDIA fourni n'est compatible qu'avec les composants logiciels NVIDIA suivants :
- NVIDIA Container Toolkit
- NVIDIA DCGM Exporter
- Plug-in d'appareil NVIDIA Kubernetes
- NVIDIA MIG Manager pour Kubernetes.
Pendant la version Preview, la configuration de l'opérateur GPU NVIDIA est fixe. Si vous essayez de personnaliser des paramètres, ils sont rétablis sur les paramètres d'installation d'origine.
L'opérateur GPU NVIDIA fourni ne peut pas être utilisé pour installer les pilotes de GPU NVIDIA.
Pendant la période de preview, cette fonctionnalité utilise le groupe d'API resource.k8s.io/v1beta1, qui diffère du groupe d'API Kubernetes Open Source pour cette fonctionnalité, resource.k8s.io/v1. Le groupe d'API Open Source v1 offre plus de fonctionnalités et une meilleure stabilité que le groupe d'API v1beta1.

Étapes suivantes

Pour utiliser l'allocation dynamique des ressources avec vos charges de travail GPU, consultez Gérer les périphériques GPU avec l'allocation dynamique des ressources.
Pour en savoir plus sur l'allocation dynamique des ressources, consultez Allocation dynamique des ressources dans la documentation Kubernetes.

Mettre à jour les clusters Restez organisé à l'aide des collections Enregistrez et classez les contenus selon vos préférences.

Mettre à jour les clusters

bmctl

gcloud CLI

Terraform

Ajouter ou supprimer des nœuds dans un cluster

bmctl

Exemple : supprimer un nœud de calcul

gcloud CLI

Exemple : supprimer un nœud de calcul

Remplacer les nœuds du plan de contrôle à haute disponibilité

bmctl

Exemple : remplacer un nœud de plan de contrôle à haute disponibilité

gcloud CLI

Exemple : remplacer un nœud de plan de contrôle à haute disponibilité

Vérifier vos modifications

kubectl

gcloud CLI

Pools d'adresses de l'équilibreur de charge

bmctl

gcloud CLI

Empêcher la suppression accidentelle d'un cluster

bmctl

gcloud CLI

Contourner les vérifications préliminaires

Ajouter ou supprimer des administrateurs de cluster

bmctl

gcloud CLI

Définir un utilisateur pour la connexion

bmctl

gcloud CLI

Paramètres réseau avancés

bmctl

gcloud CLI

NetworkGatewayGroup

Équilibrage de charge BGP

BGPLoadBalancer

BGPPeer

Augmenter la couverture du réseau de services

bmctl

gcloud CLI

Configurer les paramètres de récupération d'images kubelet

bmctl

gcloud CLI

Utilisation

Personnalisation de Keepalived

Installer ou désinstaller l'opérateur GPU NVIDIA fourni

Prérequis

Informations sur la version

Versions des composants logiciels

Compatibilité des pilotes

Mettre à jour l'opérateur GPU NVIDIA fourni

Installer l'opérateur fourni

Désinstaller l'opérateur fourni

Activer l'allocation dynamique des ressources

Limites

Étapes suivantes

Documentation de référence

bmctl

CLI gcloud

Terraform

Mettre à jour les clusters

`bmctl`

`bmctl`

`bmctl`

`kubectl`

`bmctl`

`bmctl`

`bmctl`

`bmctl`

`NetworkGatewayGroup`

`BGPLoadBalancer`

`BGPPeer`

`bmctl`

`bmctl`

`bmctl`