Mettre à niveau les clusters

Lorsque vous installez une nouvelle version de bmctl, vous pouvez mettre à niveau les clusters existants créés avec une version antérieure. La mise à niveau d'un cluster vers la dernière version de GKE sur Bare Metal apporte des fonctionnalités et des correctifs supplémentaires à votre cluster. Cela garantit également que votre cluster reste compatible. Vous pouvez mettre à niveau des clusters d'administrateur, hybrides, autonomes ou d'utilisateur à l'aide de la commande bmctl upgrade cluster.

Remarques relatives aux mises à niveau

Les sections suivantes décrivent les règles et les bonnes pratiques à prendre en compte avant de mettre à jour un cluster.

Fonctionnalités en mode bêta

Les fonctionnalités en mode bêta sont susceptibles d'être modifiées et ne sont fournies qu'à des fins de test et d'évaluation. N'utilisez pas les fonctionnalités en mode bêta sur vos clusters de production. Nous ne garantissons pas que les clusters utilisant les fonctionnalités en mode bêta puissent être mis à niveau. Dans certains cas, nous bloquons explicitement les mises à niveau des clusters utilisant les fonctionnalités en mode bêta.

Pour en savoir plus sur les modifications majeures liées à la mise à niveau, consultez les notes de version.

SELinux

Si vous souhaitez activer SELinux pour sécuriser vos conteneurs, vous devez vous assurer que SELinux est activé en mode Enforced sur toutes vos machines hôtes. À partir de la version 1.9.0 ou ultérieure de GKE sur Bare Metal, vous pouvez activer ou désactiver SELinux avant ou après la création ou la mise à niveau du cluster. SELinux est activé par défaut sur Red Hat Enterprise Linux (RHEL) et CentOS. Si SELinux est désactivé sur vos machines hôtes ou si vous n'êtes pas sûr, consultez la section Sécuriser vos conteneurs à l'aide de SELinux pour savoir comment l'activer.

GKE sur Bare Metal n'est compatible qu'avec SELinux sur les systèmes RHEL et CentOS.

Mettre à niveau les vérifications préliminaires

Les vérifications préliminaires sont exécutées lors de la mise à niveau du cluster, pour valider l'état des nœuds. La mise à niveau du cluster s'interrompt si les vérifications préliminaires échouent. Pour en savoir plus sur les vérifications préliminaires, consultez la page Comprendre les vérifications préliminaires.

Pour vérifier si les clusters sont prêts pour une mise à niveau, exécutez la vérification préliminaire avant de procéder à la mise à niveau. Pour en savoir plus, consultez la section Vérifications préliminaires pour les mises à niveau.

Nombre de nœuds

Si votre cluster comporte plus de 51 nœuds, l'opération de mise à niveau standard, qui utilise un cluster d'amorçage, est sujette à des échecs. Les échecs sont dus à la quantité limitée d'adresses IP de pods allouées au cluster d'amorçage. La plage d'adresses IP par défaut disponible pour les pods du cluster d'amorçage utilise un masque de /24 en notation de blocs CIDR.

Dans ce cas, il existe deux solutions:

(Recommandé) Utilisez l'option --use-bootstrap=false avec la commande bmctl upgrade cluster pour effectuer une mise à niveau sur place. Cet indicateur oblige la mise à niveau à contourner complètement le cluster d'amorçage et la limite d'adresse de pod associée. Veuillez noter qu'il existe un problème connu de mise à niveau sur place pour les clusters version 1.13.0. Si votre cluster utilise la version 1.13.0, consultez le problème connu pour obtenir une solution de contournement et des informations supplémentaires.
Utilisez l'option --bootstrap-cluster-pod-cidr avec la commande bmctl upgrade cluster pour augmenter la quantité d'adresses IP de pods allouées au cluster d'amorçage. Par exemple, lorsque vous spécifiez --bootstrap-cluster-pod-cidr=192.168.122.0/23 les pods exécutés pour l'opération de mise à niveau peuvent utiliser des adresses IP provenant de 192.168.122.0/23 (512 adresses), au lieu du CIDR 192.168.122.0/24 par défaut (256 adresses). Ces adresses ajoutées devraient débloquer les mises à niveau pour les clusters comportant jusqu'à 52 nœuds.

Le nombre maximal de pods exécutés simultanément lors d'une mise à niveau peut être de cinq fois le nombre de nœuds. Pour vous assurer que la mise à niveau aboutit, spécifiez un bloc CIDR contenant une quantité d'adresses IP égale à cinq fois le nombre de nœuds. Cette option nécessite des adresses IP internes.
Si vous ne souhaitez utiliser aucune des options précédentes, vous pouvez utiliser l'indicateur --skip-bootstrap-cidr-check pour contourner la validation. Toutefois, la transmission de cet argument signifie que la mise à niveau peut échouer en raison d'un nombre insuffisant d'adresses IP disponibles dans le CIDR des pods pour le cluster d'amorçage.

Mises à niveau sur place pour les clusters autogérés

À partir de la version 1.13.1 de GKE sur Bare Metal, vous pouvez effectuer des mises à niveau sur place sur des clusters d'administrateur, hybrides et autonomes. Une mise à niveau sur place élimine le besoin de créer un cluster d'amorçage, ce qui simplifie le processus et réduit les besoins en ressources pour une mise à niveau. Pour pouvoir effectuer une mise à niveau sur place de votre cluster autogéré, vous devez disposer de la version 1.13.0 ou d'une version ultérieure.

Pour effectuer une mise à niveau sur place, vous pouvez utiliser bmctl ou kubectl :

`bmctl`

Le processus de mise à niveau est identique au processus de mise à niveau standard, à l'exception de la commande bmctl upgrade cluster.

Pour lancer la mise à niveau sur place, utilisez l'option --use-bootstrap=false avec la commande de mise à niveau :
```
bmctl upgrade cluster -c CLUSTER_NAME --use-bootstrap=false \
    --kubeconfig ADMIN_KUBECONFIG
```
Remplacez les éléments suivants :
- CLUSTER_NAME : nom du cluster à mettre à niveau.
- ADMIN_KUBECONFIG : chemin d'accès au fichier kubeconfig du cluster d'administrateur.

Comme pour le processus de mise à niveau standard, les vérifications préliminaires sont exécutées dans le cadre de la mise à niveau du cluster pour valider l'état du cluster et l'état du nœud. Si les vérifications préliminaires échouent, la mise à niveau du cluster est interrompue. Pour résoudre les échecs, examinez le cluster et les journaux associés, car aucun cluster d'amorçage n'est créé.

`kubectl`

Pour mettre à niveau un cluster autogéré avec kubectl, procédez comme suit :

Modifiez le fichier de configuration du cluster pour définir anthosBareMetalVersion sur la version cible de la mise à niveau.
Pour lancer la mise à niveau, exécutez la commande suivante :
```
kubectl apply -f CLUSTER_CONFIG_PATH
```
Remplacez CLUSTER_CONFIG_PATH par le chemin d'accès au fichier de configuration du cluster.

Densité des pods

GKE sur Bare Metal accepte la configuration de 250 pods maximum par nœud avec nodeConfig.PodDensity.MaxPodsPerNode. Vous ne pouvez configurer la densité des pods que lors de la création du cluster. Vous ne pouvez pas mettre à jour les paramètres de densité des pods pour les clusters existants.

Problèmes connus

Pour en savoir plus sur les problèmes potentiels liés aux mises à niveau des clusters, consultez la section Mettre à jour Anthos clusters on bare metal sur la page "Problèmes connus".

Mettre à niveau des clusters d'administrateur, autonomes, hybrides ou d'utilisateur

Lorsque vous téléchargez et installez une nouvelle version de bmctl, vous pouvez mettre à niveau vos clusters d'administrateur, hybrides, autonomes et d'utilisateur créés avec une version antérieure. Pour une version donnée de bmctl, un cluster ne peut être mis à jour que vers la même version.

Pour commencer, téléchargez la dernière version de bmctl, modifiez les fichiers de configuration de cluster appropriés, puis exécutez la commande bmctl upgrade cluster pour lancer la mise à niveau.

Téléchargez la dernière version de bmctl depuis le bucket Cloud Storage et utilisez chmod pour accorder l'autorisation d'exécution de bmctl à tous les utilisateurs :
```
gsutil cp gs://anthos-baremetal-release/bmctl/1.14.11/linux-amd64/bmctl bmctl
chmod a+x bmctl
```

Modifiez le fichier de configuration du cluster pour remplacer la version 1.13.2 du cluster GKE sur Bare Metal par 1.14.11. Voici un exemple à partir d'une configuration de cluster d'administrateur:

---
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: cluster1
  namespace: cluster-cluster1
spec:
  # Cluster type. This can be:
  #   1) admin:  to create an admin cluster. This can later be used to create user clusters.
  #   2) user:   to create a user cluster. Requires an existing admin cluster.
  #   3) hybrid: to create a hybrid cluster that runs admin cluster components and user workloads.
  #   4) standalone: to create a cluster that manages itself, runs user workloads, but does not manage other clusters.
  type: admin
  # Anthos cluster version.
  # Change the following line from 1.13.2 to 1.14.11, shown below
  anthosBareMetalVersion: 1.14.11

Lorsque vous mettez à jour des clusters vers la version 1.14.11, vous devez enregistrer les clusters avec Connect dans le parc de votre projet, si ce n'est pas déjà fait.
1. Créez manuellement des comptes de service et récupérez les fichiers de clé JSON, comme décrit dans la section Configurer des comptes de service à utiliser avec Connect de la page "Activer les services Google et les comptes de service".
2. Référencez les clés JSON téléchargées dans les champs gkeConnectAgentServiceAccountKeyPath et gkeConnectRegisterServiceAccountKeyPath associés du fichier de configuration du cluster.
Exécutez la commande bmctl upgrade cluster pour effectuer la mise à niveau :
```
bmctl upgrade cluster -c CLUSTER_NAME --kubeconfig ADMIN_KUBECONFIG
```
Remplacez les éléments suivants :
- CLUSTER_NAME : nom du cluster à mettre à niveau.
- ADMIN_KUBECONFIG : chemin d'accès au fichier kubeconfig du cluster d'administrateur.
Les vérifications préliminaires sont exécutées lors de la mise à niveau du cluster, pour valider l'état des nœuds. La mise à niveau du cluster s'interrompt si les vérifications préliminaires échouent.

Mises à niveau de nœuds en parallèle

Lors d'une mise à niveau de cluster classique, chaque nœud de cluster est mis à niveau de manière séquentielle, l'un après l'autre. Cette section explique comment configurer votre cluster afin que plusieurs nœuds soient mis à niveau en parallèle lorsque vous mettez à niveau votre cluster.

La mise à niveau des nœuds en parallèle accélère les mises à niveau des clusters, en particulier pour les clusters comportant des centaines de nœuds. Les mises à niveau parallèles des nœuds sont configurées au niveau d'un pool de nœuds. Seuls les nœuds d'un pool de nœuds de calcul peuvent être mis à niveau en parallèle. Les nœuds des pools de nœuds du plan de contrôle ou de l'équilibreur de charge ne peuvent être mis à niveau qu'un seul à la fois.

Les mises à niveau parallèles des nœuds de calcul sont disponibles en version preview. N'utilisez donc pas cette fonctionnalité sur vos clusters de production.

Effectuer une mise à niveau en parallèle

Pour effectuer une mise à niveau parallèle des nœuds d'un pool de nœuds de calcul, procédez comme suit:

Ajoutez l'annotation preview.baremetal.cluster.gke.io/parallel-upgrade: "enable" au fichier de configuration du cluster:

---
gcrKeyPath: /path/to/gcr-sa
gkeConnectAgentServiceAccountKeyPath: /path/to/gke-connect
gkeConnectRegisterServiceAccountKeyPath: /path/to/gke-register
sshPrivateKeyPath: /path/to/private-ssh-key
cloudOperationsServiceAccountKeyPath: /path/to/logging-sa
---
apiVersion: v1
kind: Namespace
metadata:
  name: cluster-cluster1
---
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: cluster1
  namespace: cluster-cluster1
  annotations:
    baremetal.cluster.gke.io/maintenance-mode-deadline-seconds: "180"
    preview.baremetal.cluster.gke.io/parallel-upgrade: "enable"
    ...

Ajoutez une section upgradeStrategy au fichier manifeste du pool de nœuds de calcul. Ce fichier doit se trouver dans le fichier de configuration du cluster. Si elle apparaît dans un fichier manifeste distinct, la commande bmctl upgrade cluster n'agira pas sur celui-ci. Exemple :
```
---
apiVersion: baremetal.cluster.gke.io/v1
kind: NodePool
metadata:
  name: np1
  namespace: cluster-ci-bf8b9aa43c16c47
spec:
  clusterName: ci-bf8b9aa43c16c47
  nodes:
  - address:  10.200.0.7
  - address:  10.200.0.8
  - address:  10.200.0.9
  upgradeStrategy:
    parallelUpgrade:
      concurrentNodes: 5
  
```
Dans cet exemple, la valeur du champ concurrentNodes est 5, ce qui signifie que cinq nœuds seront mis à niveau en parallèle. La valeur minimale (et par défaut) de ce champ est 1, et la valeur maximale autorisée correspond au nombre de nœuds dans le pool de nœuds de calcul. Toutefois, nous vous recommandons de ne pas définir cette valeur supérieure à 3% du nombre total de nœuds de votre cluster. Si la valeur de concurrentNodes est trop élevée, les charges de travail peuvent être compromises lors d'une mise à niveau en parallèle.
Mettez à niveau le cluster comme décrit dans la section précédente Mettre à niveau des clusters d'administrateur, autonomes, hybrides ou d'utilisateur.

Comment désactiver les mises à niveau parallèles des nœuds

Pour désactiver les mises à niveau parallèles des nœuds, définissez l'annotation preview.baremetal.cluster.gke.io/parallel-upgrade sur disable dans le fichier de configuration du cluster.