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
oubmctl
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
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.
CLI gcloud
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 une description détaillée 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 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écificationNodePool
. - 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écificationCluster
. - 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écificationCluster
.
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:
(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
etstatus.nodesDraining
sur la ressourceNodePool
.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
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.
(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
etstatus.nodesDraining
sur la ressourceNodePool
.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 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 exemplenode-pool-1
, avec les options--cluster
,--project
et--location
.La section
nodeConfigs
contient deux champsnodeIp
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 leOPERATION_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:
- 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 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:
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é (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.
Une fois la commande
bmctl update
exécutée, les tâchesmachine-preflight
etmachine-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.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
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:
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
- Cluster d'utilisateur :
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
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.
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
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 exempleabm-user-cluster1a
, avec les--project
et--location flags
.La section
nodeConfigs
contient trois champsnodeIp
avec les adresses IP des nœuds du plan de contrôle.
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 leOPERATION_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 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 surTrue
, 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 estFalse
. À 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 surTrue
. Un développeur peut ensuite créer un service de typeLoadBalancer
et spécifier manuellement l'une des adresses du pool. Si aucune valeur n'est spécifiée,manual-assign
est défini surFalse
. À 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 :
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 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 commandeupdate
.
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:
- alex@example.com
- hao@example.com
- my-sa@example-project-12345.iam.gserviceaccount.com
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=alex@example.com \
--admin-users=hao@example.com
--admin-users=my-sa@example-project-12345.iam.gserviceaccount.com
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:
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.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'un mot de passe n'est pas requis pour que votre utilisateur de connexion puisse exécuter des commandes
sudo
, exécutez la commandesudo
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
.
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:
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
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
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.