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 des clusters Anthos sur bare metal offre 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 des clusters Anthos sur solution Bare Metal, vous pouvez activer ou désactiver SELinux avant ou après la création des clusters, ou leurs mises à niveau. 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.

Les clusters Anthos sur solution Bare Metal ne sont compatibles avec SELinux que dans les systèmes RHEL et CentOS.

Règles de version pour les mises à niveau

Lorsque vous téléchargez et installez une nouvelle version de bmctl, vous pouvez mettre à jour vos clusters d'administrateur, vos clusters hybrides, vos clusters autonomes et vos clusters d'utilisateur créés ou mis à jour avec une version antérieure de bmctl. Les clusters ne peuvent pas revenir à une version antérieure.

Vous ne pouvez mettre à jour un cluster que vers une version qui correspond à la version de bmctl que vous utilisez. Autrement dit, si vous utilisez la version 1.13.10 de bmctl, vous pouvez uniquement mettre à niveau un cluster vers la version 1.13.10.

Mises à niveau de versions de correctif

Pour une version mineure donnée, vous pouvez passer à n'importe quelle version de correctif supérieure. Autrement dit, vous pouvez mettre à jour un cluster de version 1.13.X vers la version 1.13.Y tant que Y est supérieur à X. Par exemple, vous pouvez passer de la version 1.12.0 à la version 1.12.1 et de la version 1.12.1 à la version 1.12.3. Nous vous recommandons, autant que possible, de procéder à la mise à niveau vers la dernière version du correctif, afin de vous assurer que vos clusters disposent des derniers correctifs de sécurité.

Mises à niveau de versions mineures

Vous pouvez mettre à jour les clusters d'une version mineure à la suivante, quelle que soit la version de correctif. Autrement dit, vous pouvez passer de la version 1.N.X à la version 1.N+1.Y, où 1.N.X est la version de votre cluster et N+1 est la prochaine version mineure disponible. Dans ce cas, les versions de correctif, X et Y, n'ont pas d'incidence sur la logique de mise à niveau. Par exemple, vous pouvez passer de la version 1.12.3 à la version 1.13.10.

Vous ne pouvez pas ignorer les versions mineures lors de la mise à niveau des clusters. Si vous essayez de passer à une version mineure qui est supérieure d'au moins deux versions mineures à la version du cluster, bmctl renvoie une erreur. Par exemple, vous ne pouvez pas mettre à jour un cluster de version 1.11.0 vers la version 1.13.0.

Un cluster d'administrateur peut gérer des clusters d'utilisateur qui correspondent à la même version mineure, ou à une version mineure précédente. La version d'un cluster d'utilisateur géré ne peut pas être inférieure de plus d'une version mineure à celle du cluster d'administrateur. Avant de mettre à jour un cluster d'administrateur vers une nouvelle version mineure, assurez-vous donc que tous les clusters d'utilisateur gérés correspondent à la même version mineure que le cluster d'administrateur.

Les exemples figurant dans les instructions de mise à niveau suivantes indiquent le processus de mise à niveau depuis la version 1.12.2 vers Anthos clusters on bare metal 1.13.10.

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

À partir de la version 1.13.1 des clusters Anthos sur bare metal, vous pouvez effectuer des mises à niveau sur place 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

Anthos clusters on bare metal permet de configurer jusqu'à 250 pods 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.13.10/linux-amd64/bmctl bmctl
chmod a+x bmctl
```

Modifiez le fichier de configuration de cluster afin de modifier la version du cluster Anthos sur Bare Metal (passage de la version 1.12.2 à la version 1.13.10). Voici un exemple issu 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.12.2 to 1.13.10, shown below
  anthosBareMetalVersion: 1.13.10

Lorsque vous mettez à jour des clusters vers la version 1.13.10, 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 sur la page "Activer des services Google et des 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 de 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.