Mettre à jour les clusters

Après avoir créé un cluster avec bmctl, vous pouvez modifier certains aspects de sa configuration en effectuant la séquence d'actions suivante:

Modifiez les valeurs de certains champs dans le fichier de configuration du cluster, qui se trouve par défaut à cet emplacement : bmctl-workspace/CLUSTER-NAME/CLUSTER-NAME.yaml.
Mettez à jour le cluster en exécutant la commande bmctl update.

De cette manière, vous pouvez, par exemple, ajouter ou supprimer des nœuds dans un cluster, ou remplacer les nœuds d'un cluster. Ce document explique comment effectuer ces mises à jour et d'autres sur un cluster.

Toutefois, il est important de noter que de nombreux aspects de la configuration de votre cluster sont immuables et ne peuvent pas être mis à jour après la création de votre cluster. Pour obtenir une 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.

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. 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 spécifique. Supprimer un nœud d'un pool de nœuds revient à le supprimer complètement du cluster.

Il existe trois types de pools de nœuds dans GKE sur Bare Metal: le plan de contrôle, l'équilibreur de charge et les pools de nœuds de calcul.

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

Pool de nœuds de calcul: ajoutez ou supprimez l'adresse IP du nœud dans la section spec.nodes de la spécification NodePool.
Pool de nœuds du plan de contrôle: ajoutez ou supprimez l'adresse IP du nœud dans la section spec.controlPlane.nodePoolSpec.nodes de la spécification Cluster.
Pool de nœuds 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 présente 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: 172.18.0.5
  - address: 172.18.0.6

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 drainage des nœuds de calcul en affichant les champs status.nodesDrained et status.nodesDraining de la ressource NodePool.
Modifiez le fichier de configuration du cluster pour supprimer l'entrée d'adresse IP du nœud.
Mettez à jour le cluster :
```
bmctl update cluster -c CLUSTER_NAME \
    --kubeconfig=ADMIN_KUBECONFIG
```
Remplacez les éléments suivants :
- CLUSTER_NAME: nom du cluster que vous souhaitez mettre à jour.
- ADMIN_KUBECONFIG : chemin d'accès au fichier kubeconfig du cluster d'administrateur.
Une fois la commande bmctl update exécutée, les tâches machine-preflight et machine-init peuvent prendre un certain temps. Pour afficher l'état des nœuds et de leurs pools de nœuds respectifs, exécutez les commandes décrites dans la section Vérifier vos mises à jour de ce document.

Forcer la suppression d'un nœud

Si la commande bmctl update ne parvient pas à supprimer un nœud, vous devrez peut-être forcer sa suppression du cluster. Pour en savoir plus, consultez la section Supprimer de force la suppression des nœuds défaillants.

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

Vous pouvez remplacer les nœuds du plan de contrôle à haute disponibilité dans des clusters d'administrateur, d'utilisateur, autonomes et hybrides.

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 de cluster.
Mettez à jour le cluster.

Le reste de cette section prend un exemple.

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: 10.200.0.11
     - address: 10.200.0.12
     - address: 10.200.0.13

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

Pour supprimer le nœud, supprimez son entrée d'adresse IP dans le fichier de configuration du cluster. Une fois la 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: 10.200.0.11
     - address: 10.200.0.12

Mettez à jour le cluster en exécutant la commande suivante:
```
bmctl update cluster -c CLUSTER_NAME \
    --kubeconfig=KUBECONFIG
```
Apportez les modifications suivantes :
- Remplacez CLUSTER_NAME par le nom du cluster que vous souhaitez mettre à jour.
- Si le cluster est un cluster autogéré (tel qu'un cluster 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.
Une fois la commande bmctl update exécutée, les tâches machine-preflight et machine-init prennent un certain temps. Pour afficher l'état des nœuds et de leurs pools de nœuds respectifs, exécutez 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 la 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: 10.200.0.11
     - address: 10.200.0.12
     - address: 10.200.0.14
```
Mettez à jour le cluster en exécutant la commande suivante:
```
bmctl update cluster -c CLUSTER_NAME \
    --kubeconfig=KUBECONFIG
```
Apportez les modifications suivantes :
- Remplacez CLUSTER_NAME par le nom du cluster que vous souhaitez mettre à jour.
- Si le cluster est un cluster autogéré (tel qu'un cluster 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.

Valider vos mises à jour

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

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.

Fonctionnalités pouvant être modifiées lors d'une mise à jour

En plus d'ajouter, de supprimer ou de remplacer des nœuds, vous pouvez utiliser la commande bmctl update pour modifier certaines valeurs de champs modifiables, des ressources personnalisées (CR) et des annotations dans le fichier de configuration du cluster.

Pour mettre à jour une ressource de cluster, modifiez le fichier de configuration du cluster et appliquez les modifications à l'aide de bmctl update.

Les sections suivantes décrivent quelques exemples courants de mise à jour d'un cluster existant en modifiant une valeur de champ, une RS ou une annotation.

`loadBalancer.addressPools`

La section addressPools contient des champs permettant de spécifier des pools d'équilibrage de charge pour des équilibreurs de charge groupés. Vous pouvez ajouter d'autres pools d'adresses d'équilibrage de charge à tout moment, mais vous ne pouvez pas supprimer ni modifier les pools d'adresses existants.

addressPools:
- name: pool1
  addresses:
  - 192.168.1.0-192.168.1.4
  - 192.168.1.240/28
- name: pool2
  addresses:
  - 192.168.1.224/28

Empêcher la suppression accidentelle du cluster

Si vous ajoutez l'annotation baremetal.cluster.gke.io/prevent-deletion: "true" au fichier de configuration du cluster, vous ne pourrez pas le supprimer. 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:

`bypassPreflightCheck`

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

apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: cluster1
  namespace: cluster-cluster1
  annotations:
    baremetal.cluster.gke.io/private-mode: "true"
spec:
  bypassPreflightCheck: true

`loginUser`

Vous pouvez définir le champ loginUser sous la configuration de l'accès aux nœuds. Ce champ est compatible avec la fonctionnalité sudo sans mot de passe pour la connexion à la machine.

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

`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. Pour utiliser la ressource personnalisée NetworkGatewayGroup et les fonctionnalités de mise en réseau associées, vous devez définir clusterNetwork.advancedNetworking sur true lorsque vous créez vos clusters.

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

`BGPLoadBalancer`

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.

apiVersion: networking.gke.io/v1
kind: BGPLoadBalancer
metadata:
  name: default
  namespace: cluster-bm
spec:
  peerSelector:
    cluster.baremetal.gke.io/default-peer: "true"

`BGPPeer`

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 BGPPeer (et la ressource personnalisée BGPLoadBalancer). Pour en savoir plus, consultez la section Configurer des équilibreurs de charge groupés avec BGP.

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

`NetworkAttachmentDefinition`

Vous pouvez utiliser la commande bmctl update pour modifier les ressources personnalisées NetworkAttachmentDefinition correspondant au réseau.

apiVersion: "k8s.cni.cncf.io/v1"
kind: NetworkAttachmentDefinition
metadata:
  name: gke-network-1
  namespace: cluster-my-cluster
spec:
  config: '{
  "type": "ipvlan",
  "master": "enp2342",
  "mode": "l2",
  "ipam": {
    "type": "whereabouts",
    "range": "172.120.0.0/24"

Après avoir modifié le fichier de configuration, mettez à jour le cluster en exécutant la commande bmctl update suivante:

bmctl update cluster -c CLUSTER_NAME --kubeconfig=KUBECONFIG

Apportez les modifications suivantes :

Remplacez CLUSTER_NAME par le nom du cluster que vous souhaitez mettre à jour.
Si le cluster est un cluster autogéré (tel qu'un cluster administrateur ou autonome), remplacez KUBECONFIG par le chemin d'accès au fichier kubeconfig du cluster. Si le cluster est un cluster d'utilisateur, remplacez KUBECONFIG par le chemin d'accès au fichier kubeconfig du cluster admin.

Désactiver le port en lecture seule du kubelet

À partir de la version 1.15.0, GKE sur Bare Metal désactive par défaut le port 10255, qui correspond au port en lecture seule du kubelet. Toutes les charges de travail des clients configurées pour lire les données de ce port de kubelet non sécurisé 10255 doivent migrer vers le port sécurisé 10250 de kubelet.

Ce port est désactivé par défaut uniquement pour les clusters créés avec la version 1.15.0 ou une version ultérieure. Le port en lecture seule 10255 du kubelet reste accessible pour les clusters créés avec une version antérieure à 1.15.0, même après une mise à niveau vers la version 1.15.0 ou une version ultérieure.

Cette modification a été effectuée, car le kubelet divulgue des informations de faible sensibilité sur le port 10255, qui n'est pas authentifié. Elles incluent les informations de configuration complètes pour tous les pods exécutés sur un nœud, ce qui peut être précieux pour un pirate informatique. Il expose également des métriques et des informations d'état, qui peuvent fournir des insights sensibles pour l'entreprise.

La désactivation du port en lecture seule du kubelet est recommandée par le benchmark CIS de Kubernetes. Pour désactiver manuellement le port dans la version 1.14, procédez comme suit:

Modifiez le fichier de configuration de votre cluster et ajoutez l'annotation suivante:

baremetal.cluster.gke.io/enable-kubelet-read-only-port: "false"

L'exemple de fichier de configuration de cluster suivant montre que cette annotation a été ajoutée:

[...]
---
apiVersion: v1
kind: Namespace
metadata:
  name: cluster-my-cluster
---
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  annotations:
    baremetal.cluster.gke.io/enable-kubelet-read-only-port: "false"
  name: my-cluster
  namespace: cluster-my-cluster
[...]

Modifiez la ressource de cluster de validation du webhook de cluster:

kubectl edit validatingwebhookconfigurations lcm-validating-webhook-configuration

Désactivez temporairement la validation du webhook en supprimant la ligne contenant le verbe UPDATE:

- admissionReviewVersions:
- v1
clientConfig:
  caBundle: …
  service:
    name: lcm-webhook-service
    namespace: kube-system
    path: /validate-baremetal-cluster-gke-io-v1-cluster
    port: 443
failurePolicy: Fail
matchPolicy: Equivalent
name: vcluster.kb.io
namespaceSelector: {}
objectSelector: {}
rules:
- apiGroups:
  - baremetal.cluster.gke.io
  apiVersions:
  - v1
  operations:
  - CREATE
  - UPDATE # <- DELETE THIS LINE
  - DELETE
  resources:
  - clusters
  scope: '*'
sideEffects: None
timeoutSeconds: 10

Ajoutez l'annotation à la ressource personnalisée de cluster:
```
kubectl edit clusters CLUSTER_NAME --kubeconfig KUBECONFIG_PATH
```
Apportez les modifications suivantes :
- Remplacez CLUSTER_NAME par le nom du cluster que vous souhaitez mettre à jour.
- Remplacez KUBECONFIG_PATH par le chemin d'accès au fichier kubeconfig du cluster.

Ajoutez l'annotation, comme indiqué dans l'exemple de ressource personnalisée de cluster mise à jour suivant:

apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  annotations:
    baremetal.cluster.gke.io/enable-kubelet-read-only-port: "false"
[...]

Enregistrez et fermez la ressource personnalisée de cluster.

Réactivez la validation du webhook en ajoutant à nouveau le verbe UPDATE à la ressource de cluster de validation du webhook:

kubectl edit validatingwebhookconfigurations lcm-validating-webhook-configuration

Dans la ressource personnalisée, ajoutez à nouveau le verbe UPDATE dans la section operations:

- admissionReviewVersions:
- v1
clientConfig:
  caBundle: …
  service:
    name: lcm-webhook-service
    namespace: kube-system
    path: /validate-baremetal-cluster-gke-io-v1-cluster
    port: 443
failurePolicy: Fail
matchPolicy: Equivalent
name: vcluster.kb.io
namespaceSelector: {}
objectSelector: {}
rules:
- apiGroups:
  - baremetal.cluster.gke.io
  apiVersions:
  - v1
  operations:
  - CREATE
  - UPDATE # <- ADD THIS LINE BACK
  - DELETE
  resources:
  - clusters
  scope: '*'
sideEffects: None
timeoutSeconds: 10

Enregistrez et fermez la ressource personnalisée de cluster.

Ces modifications sont conservées lors de la mise à niveau vers la version 1.15.0 ou ultérieure.