Mettre à jour les clusters

Après avoir créé un cluster, vous pouvez modifier certains aspects de sa configuration. Vous pouvez par exemple:

• Ajoutez, supprimez ou remplacez des nœuds.
• Ajoutez ou supprimez des annotations sur le cluster.
• Modifiez les valeurs des champs modifiables dans les ressources du cluster et du pool de nœuds.
• Modifier 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 d'administrateur ou d'utilisateur à l'aide de Terraform, vous pouvez l'utiliser pour mettre à jour le cluster. Veuillez noter les points suivants :

• De nombreux aspects de la configuration de votre cluster sont immuables et ne peuvent pas être mis à jour une fois le cluster créé. 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 le nom d'un champ pour afficher sa description.

• 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 prennent en charge que les modifications apportées aux 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.

Mettre à jour des clusters

En règle générale, vous procédez comme suit 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 à l'emplacement suivant:
   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 admin.

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 de 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. spec.nodeConfig.registryMirrors est ensuite renseigné dans le cluster après le rapprochement.

Si vous essayez ensuite de modifier le cluster à l'aide de sa configuration à l'aide de la commande kubectl apply -f, la valeur spec.nodeConfig.registryMirrors renseignée par le rapprochement sur le cluster est supprimée. Ce comportement est dû au fait que la configuration n'existe pas dans la spécification de configuration du cluster, mais que c'est le cas dans le cluster.

gcloud CLI

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

2. Exécutez la commande de mise à jour applicable:

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

   • Clusters d'utilisateur : 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. Consultez la documentation de référence de Terraform pour obtenir une description détaillée des champs:

   • 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 présentent 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 ont la même configuration. Gardez à l'esprit qu'un nœud appartient toujours à un pool de nœuds. Pour ajouter un nouveau nœud à un cluster, vous devez l'ajouter à un pool de nœuds particulier. Retirer un nœud d'un pool de nœuds revient à supprimer complètement le nœud du cluster.

Il existe trois types de pools de nœuds dans Google Distributed Cloud: le plan de contrôle, l'équilibreur de charge et les pools de nœuds de calcul. Les sections suivantes décrivent comment ajouter ou supprimer des nœuds dans 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 affiche 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:

1. (Facultatif) Si le nœud que vous supprimez exécute des pods critiques, passez d'abord en mode maintenance.

   Vous pouvez surveiller le processus de drainage des 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 afin de supprimer l'entrée d'adresse IP du nœud.

3. Mettez à jour le cluster :

   bmctl update cluster1 \
       --kubeconfig=ADMIN_KUBECONFIG
   

gcloud CLI

Utilisez une commande update pour ajouter ou supprimer des nœuds. La commande update que vous utilisez et l'option dans laquelle 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'option --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'option --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'option --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'option --metal-lb-load-balancer-node-configs 'node-ip=IP_ADDRESS' ou
  --bgp-load-balancer-node-configs 'node-ip=IP_ADDRESS'.

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

Les commandes update remplacent toutes les adresses IP par les adresses IP 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. D'autres commandes de gcloud CLI qui pourraient vous être utiles sont également incluses dans les étapes suivantes.

1. (Facultatif) Si le nœud que vous supprimez exécute des pods critiques, passez d'abord en mode maintenance.

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

2. Exécutez la commande list pour répertorier 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 répertorier 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é par souci de lisibilité:

   annotations:
     ...
     baremetal.cluster.gke.io/version: 1.29
   ...
   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 les adresses IP que vous spécifiez. Comme la version 192.0.2.1 n'est pas incluse, 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 correspond au 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 la section Forcer la suppression des nœuds défaillants.

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

bmctl

Vous pouvez utiliser bmctl pour remplacer les nœuds du plan de contrôle à haute disponibilité 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 dans le 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 de cluster.
5. 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 répertorié dans la section spec.controlPlane.nodePoolSpec.nodes, procédez comme suit:

1. Supprimer 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 auto-géré (par exemple, 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 admin.

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

gcloud CLI

Vous pouvez utiliser la gcloud CLI pour remplacer les nœuds du 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:

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

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

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

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

1. Exécutez la commande list pour répertorier tous les clusters d'utilisateur d'un projet Google Cloud:

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

   Lorsque vous définissez --location=-, cela signifie que tous les clusters de toutes les régions sont listés. Si vous devez limiter le champ d'application de 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.29      abm-admin-cluster1   RUNNING
   abm-user-cluster1b   europe-west1  1.29      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, 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.

3. 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 correspond au 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'
   

Valider 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

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 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 pour l'é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'option 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'indicateur --metal-lb-address-pools.
• Protocole BGP (Border Gateway Protocol): utilisez l'option --bgp-address-pools.

La valeur des options 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 inclut 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.

• avoid-buggy-ips: si vous définissez ce paramètre sur True, le contrôleur de gestion des adresses IP n'attribue pas les adresses IP se terminant par .0 ou .255 aux services. Cela permet d'éviter que les appareils grand public présentant des bugs 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 de addresses: chaque adresse doit être une plage au format CIDR ou à plage traitée. Pour spécifier une adresse IP unique 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 la valeur entière de 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'option, 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 la section loadBalancer.addressPools de la page "Configurer l'équilibrage de charge groupé".

Empêcher la suppression accidentelle de clusters

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:

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 :

1. Ajoutez l'annotation pour empêcher 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 à celle-ci:

   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 à des 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 d'un cluster d'utilisateur en spécifiant les 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 fournit 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'utilisateur pour ajouter un compte, veillez à inclure tous les comptes de la liste (existants et nouveaux), 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'option --admin-users. L'indicateur n'accepte qu'une seule adresse e-mail. Pour ajouter plusieurs utilisateurs, spécifiez un compte dans chaque option, 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 d'autorisations. Spécifiez tous les utilisateurs existants et nouveaux que vous souhaitez désigner comme administrateurs de cluster.

Définir un utilisateur de connexion

Vous pouvez spécifier un nom d'utilisateur non racine que vous souhaitez utiliser pour l'accès sans mot de passe sudo aux machines de nœud de votre cluster. 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

Spécifiez l'utilisateur que vous souhaitez utiliser pour accéder aux machines de nœud dans l'option --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 empêcher 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'aucun mot de passe n'est requis pour que votre utilisateur de connexion puisse exécuter les commandes sudo, exécutez la commande sudo suivante:

   sudo ip a
   

Paramètres réseau avancés

Une fois le cluster créé, vous pouvez configurer des fonctionnalités de mise en réseau avancées dans différentes ressources personnalisées. 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 créez votre cluster:

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.

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 BGP (Border Gateway Protocol) dans la ressource du cluster et dans d'autres ressources personnalisées. Les commandes gcloud container bare-metal clusters create et update sont compatibles avec la configuration de 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, à l'aide de la ressource personnalisée BGPLoadBalancer et de 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 portée du réseau de services

Pour créer un nombre de services supérieur à la limite initiale, vous pouvez réduire le masque CIDR du service IPv4 afin d'augmenter le réseau de services de votre cluster. Réduire le masque (la valeur après "/") permet d'élargir la plage réseau. Vous pouvez uniquement augmenter la plage CIDR du service IPv4. La plage du 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 du CIDR de service IPv4 sur un cluster d'utilisateur, spécifiez la nouvelle plage dans l'option --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 d'extraction d'image du kubelet

Le kubelet s'exécute sur chaque nœud du cluster. Le kubelet est chargé de surveiller les conteneurs d'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.

Il peut être difficile de mettre à jour manuellement vos configurations kubelet et de les maintenir synchronisées sur tous les nœuds de votre cluster. Pire encore, les modifications manuelles de la configuration du kubelet sur vos nœuds sont perdues lors de la mise à niveau du cluster.

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

bmctl

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

Avertissement :Si vous définissez registryBurst ou registryPullQPS sur une valeur négative, le job de mise à jour échouera pour la configuration du kubelet. Pour résoudre le problème, mettez à jour ces champs avec des valeurs positives ou supprimez-les de la spécification. Si la tâche de mise à jour échoue 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 (valeur 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 du cluster.

Vous pouvez spécifier ces champs dans les sections kubeletConfig des spécifications du cluster et de la spécification de 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.

gcloud CLI

Les options suivantes contrôlent les opérations d'extraction Container Registry pour le 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 :Si vous définissez les options *-registryburst ou *-registry-pull-qps sur une valeur négative, la tâche de mise à jour de la configuration du kubelet échouera. Pour résoudre le problème, mettez à jour ces champs avec des valeurs positives. Si la tâche de mise à jour échoue 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.

Comment l'utiliser ?

Voici quelques points à prendre en compte pour le réglage des extractions d'images:

• Étant donné que les images sont extraites par défaut en série, 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 les délais d'extraction d'image, vous pouvez désactiver l'extraction d'images sérialisée pour autoriser l'extraction d'images parallèles.

• Si vous rencontrez des erreurs de limitation de l'extraction d'image, telles que pull QPS exceeded, vous pouvez augmenter *-registry-pull-qps et *-registry-burst pour augmenter le débit d'extraction d'image. 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. Les valeurs négatives ne sont pas autorisées.

Documentation de référence

bmctl

• Documentation de référence sur la commande bmctl

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

gcloud CLI

• 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