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.11.8 de bmctl, vous ne pouvez mettre à niveau un cluster que vers la version 1.11.8.

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.11.X vers la version 1.11.Y tant que Y est supérieur à X. Par exemple, vous pouvez passer de la version 1.10.0 à la version 1.10.1 et de la version 1.10.1 à la version 1.10.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.10.3 à la version 1.11.8.

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.9.0 vers la version 1.11.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.10.2 vers Anthos clusters on bare metal 1.11.8.

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.

  1. 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.11.8/linux-amd64/bmctl bmctl
    chmod a+x bmctl
    
  2. Modifiez le fichier de configuration de cluster afin de modifier la version du cluster Anthos sur Bare Metal (passage de la version 1.10.2 à la version 1.11.8). 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.10.2 to 1.11.8, shown below
      anthosBareMetalVersion: 1.11.8
    
  3. Lorsque vous mettez à jour des clusters vers la version 1.11.8, 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.
  4. 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.