Mettre à jour les clusters

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

• Ajoutez, supprimez ou remplacez des nœuds.
• Ajoutez ou supprimez des annotations au 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 mettre à jour un cluster. Si vous avez créé un cluster administrateur ou 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 du 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 CLI gcloud et Terraform ne permettent de mettre à jour que les clusters administrateur et utilisateur. Vous devez utiliser bmctl pour mettre à jour d'autres types de clusters.

• La CLI gcloud et Terraform n'acceptent que les modifications apportées aux ressources de cluster et de pool de nœuds. Vous devez utiliser kubectl ou bmctl pour mettre à jour d'autres ressources personnalisées qui affectent le cluster.

Mettre à jour des clusters

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

bmctl

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

2. 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, les contenus renseignés par l'en-tête de la spécification du cluster peuvent être supprimés par inadvertance. 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é avec 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.

CLI gcloud

1. Spécifiez uniquement les indicateurs de la configuration que vous souhaitez modifier.

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

1. 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 une description détaillée des champs, consultez la documentation de référence Terraform:

   • google_gkeonprem_bare_metal_admin_cluster

   • google_gkeonprem_bare_metal_cluster

   • google_gkeonprem_bare_metal_node_pool

2. 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 particulier. Supprimer un nœud d'un pool de nœuds revient à le supprimer complètement 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, ajoutez ou supprimez 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 de l'é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 indique les spécifications de deux nœuds de travail:

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

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

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

2. Modifiez le fichier de configuration du cluster pour supprimer l'entrée d'adresse IP du nœud.

3. Mettez à jour le cluster :

   bmctl update cluster1 \
       --kubeconfig=ADMIN_KUBECONFIG
   

CLI gcloud

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 l'indicateur 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 l'adresse IP 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. Des commandes de CLI gcloud supplémentaires que vous pourriez trouver utiles sont également incluses dans les étapes suivantes.

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

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

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

3. 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 sortie suivant est tronqué pour des raisons de lisibilité:

   annotations:
     ...
     baremetal.cluster.gke.io/version: 1.31
   ...
   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 spécifier le nom complet ou le nom du pool de nœuds, par exemple node-pool-1, avec les options --cluster, --project et --location.

   • La section nodeConfigs contient deux champs nodeIp avec les adresses IP des nœuds.

4. 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 le supprimer de force 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 HA

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:

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

Exemple: remplacer un nœud de plan de contrôle HA

Voici un exemple de fichier de configuration de cluster qui affiche 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:

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

2. 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é (par exemple, un cluster d'administration 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.

3. Une fois la commande bmctl update exécutée, les tâches machine-preflight et machine-init prennent un certain temps à 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.

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

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

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

CLI gcloud

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

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

1. Supprimez l'adresse IP du nœud en exécutant la commande update appropriée:

   • Cluster d'utilisateur : gcloud container bare-metal clusters update
   • Cluster d'administrateur : gcloud container bare-metal admin-clusters update

2. Vérifiez l'état de la suppression du nœud dans le cluster en exécutant gcloud container bare-metal operations describe OPERATION_ID.

3. Ajoutez l'adresse IP du nouveau nœud en exécutant la commande update appropriée.

Exemple: remplacer un nœud de plan de contrôle HA

Cette section explique comment remplacer un plan de contrôle d'un cluster à l'aide d'exemples de données. Des commandes de CLI gcloud supplémentaires que vous pourriez trouver utiles sont également incluses dans les étapes suivantes.

1. Exécutez la commande list pour répertorier tous les clusters d'utilisateurs d'un projet Google 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.31      abm-admin-cluster1   RUNNING
   abm-user-cluster1b   europe-west1  1.31      abm-admin-cluster1   RUNNING
   

2. 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 sortie 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 spécifier le nom complet ou le nom du cluster, par exemple abm-user-cluster1a, avec les --project et --location flags.

   • La section nodeConfigs contient trois champs nodeIp avec les adresses IP des nœuds du plan de contrôle.

3. Supprimez le nœud dont l'adresse IP est 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.

4. 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 mises à jour

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

CLI gcloud

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 son état actuel 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

CLI gcloud

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'indicateur --bgp-address-pools.

La valeur des indicateurs a le 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 commençant 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:

• Entourez l'ensemble de la valeur entre guillemets simples.
• Les espaces blancs 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 l'é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" à votre fichier de configuration de cluster, vous ne pouvez 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:

CLI gcloud

Si vous spécifiez l'indicateur --add-annotations avec la valeur baremetal.cluster.gke.io/prevent-deletion="true", vous ne pouvez pas supprimer le cluster. Exemple :

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

2. 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 est semblable à la suivante:

   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 préliminaires internes sont ignorées lorsque vous appliquez des 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 compte utilisateur ou 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. Ils disposent ainsi d'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:
        - [e-mail]
        - [e-mail]
        - [e-mail]

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

CLI gcloud

Vous pouvez ajouter ou supprimer un compte utilisateur ou 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=[e-mail] \
    --admin-users=[e-mail]
    --admin-users=[e-mail]

La commande update écrase l'ensemble de la liste des autorisations. Spécifiez tous les utilisateurs existants et nouveaux que vous souhaitez voir devenir administrateurs de cluster.

Définir un utilisateur de 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 avec la 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

CLI gcloud

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:

1. Utilisez sudo visudo pour ouvrir le fichier sudoers pour le modifier:

   sudo visudo -f /etc/sudoers
   

   La commande visudo verrouille le fichier sudoers pour éviter les modifications simultanées et valide la syntaxe du fichier lors de l'enregistrement.

2. Pour votre utilisateur de connexion, ajoutez une entrée au fichier sudoers comme suit:

   USERNAME ALL=(ALL) NOPASSWD: ALL
   

3. Fermez le fichier et enregistrez-le.

4. Pour exécuter des commandes avec les droits de votre utilisateur de connexion, exécutez la commande suivante:

   su - USERNAME
   

5. Pour vérifier qu'un mot de passe n'est pas requis pour que votre utilisateur de connexion puisse exécuter des 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 diverses 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
    ...

CLI gcloud

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.

Remarque :La commande gcloud container bare-metal clusters update ne permet pas de configurer ces ressources personnalisées.

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 service

Pour créer plus de services que la limite initiale, vous pouvez réduire le masque de service CIDR IPv4 afin d'augmenter le réseau de service de votre cluster. Réduire le masque (la valeur après "/") étend la plage de réseau. Vous ne pouvez augmenter que la plage du CIDR du service IPv4. La plage de 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
  ...

CLI gcloud

Pour augmenter la plage du service CIDR IPv4 sur un cluster d'utilisateurs, 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. Le kubelet est chargé de surveiller les conteneurs sur un nœud et de s'assurer qu'ils sont opérationnels. Si nécessaire, le kubelet interroge et extrait des images de Container Registry.

La mise à jour manuelle de vos configurations kubelet et leur synchronisation sur tous les nœuds de votre cluster peut s'avérer difficile. Pour aggraver la situation, les modifications manuelles de la configuration du kubelet sur vos nœuds sont perdues lorsque vous mettez à niveau votre cluster.

Pour faciliter et pérenniser les mises à jour synchronisées, Google Distributed Cloud vous permet de spécifier certains paramètres kubelet pour chacun de vos pools de nœuds de cluster : nœuds de 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 de récupération de Container Registry pour kubelet:

Avertissement :Définir registryBurst ou registryPullQPS sur une valeur négative entraîne l'échec des tâches de mise à jour pour la configuration du kubelet. Pour résoudre le problème, définissez ces champs sur des valeurs positives ou supprimez-les de la spécification. Si la tâche de mise à jour est laissée en échec pendant une longue période, elle peut remplir l'espace disque de la machine avec des fichiers de sauvegarde de configuration kubelet. Vous trouverez ces fichiers de sauvegarde dans /var/lib/kubelet/config.yaml.bkup.*. Si ces fichiers de sauvegarde occupent trop d'espace disque, vous pouvez les supprimer.

• 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 du 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 du pool de nœuds 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 du pool de nœuds:
• 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.

CLI gcloud

Les indicateurs suivants contrôlent les opérations de récupération de Container Registry pour kubelet:

• Nœuds du plan de contrôle

  • --control-plane-registry-burst
  • --control-plane-registry-pull-qps
  • --disable-control-plane-serialize-image-pulls
  • --enable-control-plane-serialize-image-pulls

• Nœuds d'équilibrage de charge

  • --bgp-load-balancer-registry-burst
  • --bgp-load-balancer-registry-pull-qps
  • --disable-bgp-load-balancer-serialize-image-pulls
  • --enable-bgp-load-balancer-serialize-image-pulls
  • --metal-lb-load-balancer-registry-burst
  • --metal-lb-load-balancer-registry-pull-qps
  • --disable-metal-lb-load-balancer-serialize-image-pull
  • --enable-metal-lb-load-balancer-serialize-image-pulls

• Nœuds de calcul

  • --registry-burst
  • --registry-pull-qps
  • --disable-serialize-image-pulls
  • --enable-serialize-image-pulls

Avertissement :Définir les indicateurs *-registryburst ou *-registry-pull-qps sur une valeur négative entraîne l'échec des tâches de mise à jour pour la configuration du kubelet. Pour résoudre le problème, remplacez ces valeurs par des valeurs positives. Si la tâche de mise à jour est laissée en échec pendant une longue période, elle peut remplir l'espace disque de la machine avec des fichiers de sauvegarde de la configuration kubelet. Vous trouverez ces fichiers de sauvegarde dans /var/lib/kubelet/config.yaml.bkup.*. Si ces fichiers de sauvegarde occupent trop d'espace disque, vous pouvez les supprimer.

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 retardé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 affecté par des retards de récupération d'images, vous pouvez désactiver la sérialisation des récupérations d'images pour autoriser les récupérations 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 débit de pull et la taille de la file d'attente, et peuvent aider à résoudre d'autres problèmes liés au débit limité. Les valeurs négatives ne sont pas autorisées.

Documentation de référence

bmctl

• Documentation de référence sur les commandes bmctl

• Documentation de référence sur les champs de configuration de cluster

CLI gcloud

• gcloud container bare-metal clusters

• gcloud container bare-metal node-pools

• gcloud container bare-metal admin-clusters

Terraform

• google_gkeonprem_bare_metal_cluster

• google_gkeonprem_bare_metal_node_pool

• google_gkeonprem_bare_metal_admin_cluster