Mettre à niveau un cluster Kubernetes Azure Operator Nexus

Article
08/22/2024

Cet article fournit des instructions sur la mise à niveau d’un cluster Operator Nexus Kubernetes pour obtenir les dernières fonctionnalités et les derniers correctifs de sécurité. Une partie du cycle de vie du cluster Kubernetes implique l’exécution de mises à niveau périodiques vers la dernière version de Kubernetes. Il est important d’appliquer les dernières mises à jour ou mises à niveau de sécurité pour obtenir les fonctionnalités les plus récentes. Cet article explique comment vérifier, configurer et appliquer des mises à niveau à votre cluster Kubernetes.

Limites

Le processus de mise à niveau par défaut du cluster est une approche Scale-out, ce qui signifie qu’au moins un nœud supplémentaire est ajouté (ou autant de nœuds que configurés en augmentation maximale). Si la capacité est insuffisante, la mise à niveau échoue.
Lorsque de nouvelles versions de Kubernetes deviennent disponibles, les clusters clients ne subissent pas de mises à niveau automatiques. Les utilisateurs doivent lancer la mise à niveau lorsque toutes les fonctions réseau du cluster sont prêtes à prendre en charge la nouvelle version de Kubernetes. Pour plus d’informations, consultez Mettre à niveau le cluster.
Operator Nexus offre des mises à niveau à l’échelle du cluster, ce qui garantit la cohérence entre tous les pools de nœuds. La mise à niveau d’un pool à nœud unique n’est pas prise en charge. En outre, l’image de nœud est mise à niveau dans le cadre de la mise à niveau du cluster lorsqu’une nouvelle version est disponible.
Les personnalisations apportées aux nœuds d’agent seront perdues pendant les mises à niveau du cluster. Il est recommandé de placer ces personnalisations dans DaemonSet au lieu d’apporter des modifications manuelles à la configuration de nœud afin de les conserver après la mise à niveau.
Les modifications apportées aux configurations de module complémentaire principales sont restaurées dans la configuration du module complémentaire par défaut dans le cadre du processus de mise à niveau du cluster. Évitez de personnaliser la configuration de module complémentaire (par exemple, Calico, etc.) pour éviter les échecs de mise à niveau potentiels. Si la restauration de la configuration de module complémentaire rencontre des problèmes, cela peut entraîner des échecs de mise à niveau.
Lorsque vous mettez à niveau le cluster Operator Nexus Kubernetes, les versions mineures de Kubernetes ne peuvent pas être ignorées. Vous devez effectuer toutes les mises à niveau séquentiellement par numéro de version principale. Par exemple, les mises à niveau 1.14.x ->1.15.x ou 1.15.x ->1.16.x sont autorisées, mais pas 1.14.x ->1.16.x. Si votre version est antérieure à plusieurs versions majeures, vous devez effectuer plusieurs mises à niveau séquentielles.
Les valeurs d’augmentation maximale et/ou de maximal non disponible doivent être définies lors de la création du cluster. Vous ne pouvez pas les modifier une fois le cluster créé. Pour plus d’informations, consultez upgradeSettings dans Créer un cluster Azure Operator Nexus Kubernetes.

Prérequis

Un cluster Azure Operator Nexus Kubernetes déployé dans un groupe de ressources de votre abonnement Azure.
Si vous utilisez Azure CLI, cet article nécessite que vous exécutiez la dernière version d’Azure CLI. Si vous devez effectuer une installation ou une mise à niveau, consultez Installer Azure CLI.
Version minimale requise de l’extension networkcloud az-cli : 2.0.b3
Comprendre le concept de bundles de versions. Pour plus d’informations, consultez Bundles de versions Nexus Kubernetes.

Rechercher les mises à niveau disponibles

Vérifiez les versions de Kubernetes disponibles pour votre cluster en procédant comme suit :

Utiliser l’interface de ligne de commande Microsoft Azure

La commande Azure CLI suivante renvoie les mises à niveau disponibles pour votre cluster :

az networkcloud kubernetescluster show --name <NexusK8sClusterName> --resource-group <ResourceGroup> --output json --query availableUpgrades

Exemple de sortie :

[
  {
    "availabilityLifecycle": "GenerallyAvailable",
    "version": "v1.25.4-4"
  },
  {
    "availabilityLifecycle": "GenerallyAvailable",
    "version": "v1.25.6-1"
  },
  {
    "availabilityLifecycle": "GenerallyAvailable",
    "version": "v1.26.3-1"
  }
]

Utilisation du portail Azure

Connectez-vous au portail Azure.
Accédez à votre cluster Operator Nexus Kubernetes.
Sous Vue d’ensemble, sélectionnez l’onglet Mises à niveau disponibles.

Choisir une version vers laquelle mettre à niveau

La sortie de mise à niveau disponible indique qu’il existe plusieurs versions au choix pour la mise à niveau. Dans ce scénario spécifique, le cluster actuel fonctionne sur la version v1.25.4-3.. En conséquence, les options de mise à niveau disponibles incluent v1.25.4-4 et la dernière version de correctif v1.25.6-1.. En outre, une nouvelle version mineure est également disponible.

Vous avez la possibilité de procéder à une mise à niveau vers l’une des versions disponibles. Toutefois, la marche à suivre recommandée consiste à effectuer la mise à niveau vers la version major-minor-patch-versionbundle la plus récente disponible.

Remarque

Le format d’entrée de la version est major.minor.patch ou major.minor.patch-versionbundle. L’entrée de version doit être l’une des versions de mise à niveau disponibles. Par exemple, si la version actuelle du cluster est 1.1.1-1, les entrées de version valides sont 1.1.1-2 ou 1.1.1-x. Bien que 1.1.1 soit un format valide, il ne déclenche aucune mise à jour, car la version actuelle est déjà 1.1.1. Pour lancer une mise à jour, vous pouvez spécifier la version complète avec le bundle de versions, par exemple 1.1.1-2. Toutefois, 1.1.2 et 1.2.x sont une entrée valide et utilisent le dernier bundle de versions disponible pour 1.1.2 ou 1.2.x.

Mettre à niveau le cluster

Pendant le processus de mise à niveau du cluster, Operator Nexus effectue les opérations suivantes :

Ajoutez un nouveau nœud de plan de contrôle avec la version de Kubernetes spécifiée au cluster.
Une fois le nouveau nœud ajouté, isolez et videz l’un des anciens nœuds du plan de contrôle, ce qui garantit que les charges de travail en cours d’exécution sont correctement déplacées vers d’autres nœuds de plan de contrôle sains.
Une fois l’ancien nœud du plan de contrôle vidé, il est supprimé et un nouveau nœud de plan de contrôle est ajouté au cluster.
Ce processus se répète jusqu’à ce que tous les nœuds du plan de contrôle du cluster aient été mis à niveau.
Si vous mettez à niveau des nœuds Worker via une augmentation (par défaut) :
- Pour chaque pool d’agents dans le cluster, ajoutez un nouveau nœud Worker (ou autant de nœuds que configurés en augmentation maximale) avec la version de Kubernetes spécifiée. Plusieurs pools d’agents sont mis à niveau simultanément.
- Il effectue l’isolation et le vidage de l’un des anciens nœuds Worker afin de limiter la perturbation des applications en cours d’exécution. Si vous utilisez l’augmentation maximale (max surge), elle isole et vide autant de nœuds Worker que le nombre de nœuds de tampon spécifiés.
- Une fois que l’ancien nœud Worker a été vidé, il est supprimé et un nouveau nœud Worker avec la nouvelle version de Kubernetes est ajouté au cluster (ou autant de nœuds que configurés en augmentation maximale)
Si vous mettez à niveau des nœuds Worker sans augmentation :
- Pour chaque pool d’agents du cluster, un ancien nœud Worker (ou autant de nœuds que configurés par maximal non disponible maximal) est isolé, vidé, puis supprimé, avant d’être remplacé par un nouveau nœud Worker avec la version de Kubernetes spécifiée. Plusieurs pools d’agents sont mis à niveau simultanément.
- Pendant la mise à niveau, il y aura une réduction temporaire de la capacité du cluster, car les pods vidés à partir de l’ancien nœud Worker n’auront pas immédiatement un nouveau nœud vers lequel migrer. Cela peut entraîner l’entrée de pods dans un état en attente s’il n’y a pas suffisamment de capacité. Par conséquent, il est essentiel de concevoir votre cluster pour répondre aux exigences de capacité des applications, en particulier pendant les mises à niveau sans augmentation.
Ce processus se répète jusqu’à ce que tous les nœuds Worker du cluster soient mis à niveau.

Remarque

La mise à niveau du cluster ne crée pas de nœuds et remplace les anciens si la version de l’image du système d’exploitation et la version Kubernetes restent identiques entre les bundles de versions. Ce comportement est attendu, car la mise à niveau peut inclure uniquement les mises à jour des versions de modules complémentaires plutôt que les nouvelles versions du système d’exploitation ou Kubernetes. Étant donné qu’il n’y a pas de mise à niveau propagée, il n’y a pas d’isolation et de vidage sur les nœuds, de sorte que les pods ne présentent pas d’interruptions.

Important

Assurez-vous que les PodDisruptionBudgets (PDB) permettent de déplacer au moins un réplica de pod à la fois, sinon l’opération de vidage/d’exclusion échouera. Si l’opération de vidage échoue, l’opération de mise à niveau échouera également afin de garantir que les applications ne soient pas interrompues. Corrigez ce qui a provoqué l’arrêt de l’opération (c’est-à-dire les PDB incorrects, le manque de quota, etc.), puis recommencez l’opération. Il est également possible de configurer un délai d’expiration de vidage par pool de nœuds Worker, après quoi le nœud sera supprimé même si les pods n’ont pas encore terminé le vidage. Cela peut empêcher les mises à niveau d’être bloquées par des fichiers PDB mal configurés. Le paramètre de délai d’expiration du vidage est configuré en secondes et est défini par défaut sur 1800.

Mettez à niveau votre cluster à l’aide de la commande networkcloud kubernetescluster update.

az networkcloud kubernetescluster update --name myNexusK8sCluster --resource-group myResourceGroup --kubernetes-version v1.26.3

Vérifiez si la mise à niveau a réussi avec la commande show.

az networkcloud kubernetescluster show --name myNexusK8sCluster --resource-group myResourceGroup --output json --query kubernetesVersion

L’exemple de sortie suivant montre que le cluster exécute à présent la version v1.26.3 :

"v1.26.3"

Vérifiez que le cluster est sain.

az networkcloud kubernetescluster show --name myNexusK8sCluster --resource-group myResourceGroup --output table

L’exemple de sortie suivant montre que le cluster est sain :

Name                 ResourceGroup          ProvisioningState    DetailedStatus    DetailedStatusMessage             Location
------------------   ---------------------  -------------------  ----------------  --------------------------------  --------------
myNexusK8sCluster    myResourceGroup        Succeeded            Available         Cluster is operational and ready  southcentralus

Personnaliser la mise à niveau d’augmentation du nœud ou d’indisponibilité

Par défaut, Operator Nexus configure les mises à niveau pour ajouter un nœud Worker. La valeur par défaut un pour les paramètres d’augmentation maximale (max-surge) permet à Operator Nexus de réduire les interruptions de la charge de travail en créant un nœud avant l’isolation ou le vidage des applications existantes pour remplacer un nœud de version antérieure. La valeur max surge peut être personnalisée par pool de nœuds pour obtenir un compromis entre la vitesse de mise à niveau et l’interruption causée par la mise à niveau. Lorsque vous augmentez la valeur de max surge, le processus de mise à niveau se termine plus rapidement. Si vous définissez une valeur élevée pour max surge, vous pouvez subir des interruptions pendant le processus de mise à niveau.

Par exemple, une valeur max surge de « 100 % » offre le processus de mise à niveau le plus rapide possible (doublant le nombre de nœuds), mais entraîne également le vidage simultané de tous les nœuds du pool de nœuds. Il est donc préférable d’utiliser des valeurs élevées telles que celle-ci pour les environnements de test. Pour les pools de nœuds de production, nous vous recommandons d’utiliser un paramètre max-surge de 33 %.

Il n’est pas toujours approprié de procéder à une mise à niveau via une augmentation, par exemple dans les environnements présentant des contraintes de ressources. Les mises à niveau peuvent également se poursuivre sans augmentation ; un nœud Worker est supprimé, puis remplacé. Cela signifie qu’aucune ressource supplémentaire n’est nécessaire, mais cela entraîne des périodes de capacité réduite pendant lesquelles les pods peuvent ne pas être planifiables sur un nœud. Ce type de mise à niveau est contrôlé par pool de nœuds par le paramètre maximal non disponible. Par défaut, le nombre maximal non disponible est défini sur 0. Cela indique qu’au maximum 0 nœud peut être indisponible, c’est-à-dire que ce type de mise à niveau ne se produit pas par défaut.

L’API accepte les valeurs entières et une valeur de pourcentage pour l’augmentation maximale et la valeur maximale non disponible. Un entier tel que 5 indique que cinq nœuds peuvent être augmentés/rendus indisponibles. La valeur « 50 % » indique une valeur d’augmentation/d’indisponibilité égale à la moitié du nombre de nœuds actuel dans le pool.

L’augmentation maximale ou le maximal non disponible doit être d’au moins 1 (ou 1 %), sinon il n’existe aucun mécanisme par lequel le cluster peut être mis à niveau. Si vous utilisez une valeur en pourcentage, le nombre de nœuds est arrondi à la valeur entière la plus proche. L’augmentation maximale et le maximal non disponible peuvent être définis sur un maximum de 100 %. Si la valeur de surtension maximale est supérieure au nombre requis de nœuds à mettre à niveau, le nombre de nœuds à mettre à niveau est utilisé pour la valeur de surtension maximale.

Vous pouvez configurer l’augmentation maximale et le maximal non disponible en même temps, auquel cas la mise à niveau se poursuit via une combinaison d’augmentations et d’indisponibilité.

Important

Les charges de travail Kubernetes standard cyclent en mode natif vers les nouveaux nœuds lorsqu’elles sont vidées des nœuds qui sont détruits. N’oubliez pas que le service Operator Nexus Kubernetes ne peut pas faire de promesses concernant la charge de travail pour les comportements Kubernetes non standard.

Étapes suivantes

En savoir plus sur les bundles de versions Nexus Kubernetes.

Partager via