Les clusters ACK Lingjun prennent en charge les mises à niveau Kubernetes des versions 1.20 à 1.22 via des mises à jour sur place. Vous pouvez mettre à niveau l'ensemble du cluster en une seule opération, ou mettre à niveau séparément le plan de contrôle et les pools de nœuds.
Fonctionnement
La mise à niveau d'un cluster ACK Lingjun suit les étapes suivantes :
Exécutez une prévérification. ACK analyse le cluster pour détecter les problèmes de compatibilité avant toute modification. Corrigez tous les problèmes signalés avant de poursuivre.
Mettez à niveau le plan de contrôle. ACK met à jour kube-apiserver, kube-controller-manager et kube-scheduler. Les composants Kubernetes tels que kube-proxy sont également mis à jour. Les nouveaux nœuds ajoutés après cette étape exécutent la nouvelle version de Kubernetes.
Mettez à niveau les pools de nœuds. ACK met à jour kubelet et le runtime de conteneur sur les nœuds existants par lots. Les pools de nœuds multiples sont mis à niveau un par un.
Vérifiez. Confirmez la version du cluster, l'état des pools de nœuds et l'intégrité des applications.
Prérequis
Avant de commencer, assurez-vous d'avoir :
Accès à la console ACK
Lu les notes de version de la version Kubernetes vers laquelle vous souhaitez mettre à niveau votre cluster
-
Consulté les notes de version de la version Kubernetes cible :
Examiné la prise en charge des versions Kubernetes dans ACK Lingjun
Notes d'utilisation
Compatibilité des versions Kubernetes
Avant la mise à niveau, vérifiez la colonne Version sur la page Clusters de la console Container Service for Kubernetes dans la console ACK pour confirmer votre version actuelle de Kubernetes. Si vos charts Helm utilisent des ressources API obsolètes, mettez à jour ces manifests avant la mise à niveau. Pour plus de détails sur les API obsolètes, consultez la section API obsolètes et les notes de version correspondantes.
Pour les clusters exécutant Kubernetes 1.20 ou une version ultérieure, la prévérification analyse également l'utilisation des API obsolètes. Le résultat est informatif et ne bloque pas la mise à niveau.
Considérations spécifiques aux fonctionnalités
Si votre cluster utilise l'une des fonctionnalités suivantes, examinez les considérations avant la mise à niveau.
| Fonctionnalité | Comportement pendant la mise à niveau | Action requise |
|---|---|---|
| FlexVolume | Les volumes Object Storage Service (OSS) montés par FlexVolume 1.11.2.5 ou une version antérieure sont remontés. | Recréez les pods qui utilisent des volumes OSS après la mise à niveau. Migrez de FlexVolume vers CSI lorsque cela est possible. Consultez la section Migration de FlexVolume vers CSI. |
| Auto Scaling | Cluster Autoscaler est automatiquement mis à jour vers la dernière version. | Vérifiez que Cluster Autoscaler exécute la version attendue. Consultez la section Auto Scaling des nœuds. |
| Réservation de ressources | Après la mise à niveau vers Kubernetes 1.18, ACK configure automatiquement la réservation de ressources. Si l'utilisation des ressources des nœuds est élevée, les pods évincés peuvent échouer à être replanifiés. | Réservez au moins 50 % du CPU et 70 % de la mémoire sur chaque nœud avant la mise à niveau. Consultez la section Politique de réservation de ressources. |
LoadBalancer avec externalTrafficPolicy: Local |
Le trafic est uniquement transféré vers les pods locaux au nœud. Si les pods d'application se trouvent sur d'autres nœuds, ils deviennent inaccessibles. | Vérifiez si externalTrafficPolicy: Local est défini sur une instance Server Load Balancer (SLB). Consultez la section Que faire si le cluster ne peut pas accéder à l'adresse IP SLB. |
| Applications dépendantes du serveur API | Le serveur API peut être brièvement interrompu pendant la mise à niveau du plan de contrôle. Les applications utilisant des opérations list-and-watch sont affectées. | Configurez votre application pour qu'elle réessaie automatiquement les opérations watch en cas de déconnexion. Les applications qui n'accèdent pas au serveur API ne sont pas affectées. |
| kubectl | Après la mise à niveau, kubectl sur votre machine locale peut être incompatible avec la nouvelle version du serveur API, ce qui provoque des erreurs invalid object doesn't have additional properties. |
Mettez à jour kubectl après la mise à niveau du cluster. Consultez la section Installation de kubectl. |
Considérations relatives aux configurations personnalisées
| Élément | Considération |
|---|---|
| Réseau | La mise à niveau utilise yum pour télécharger les packages. Si votre cluster utilise une configuration réseau personnalisée, vérifiez que yum fonctionne correctement en exécutant yum makecache. |
| Image OS | Les images OS personnalisées ne sont pas validées par ACK. La réussite de la mise à niveau n'est pas garantie pour les clusters utilisant des images OS personnalisées. |
| Autres configurations personnalisées | Les partitions swap, les paramètres kubelet modifiés via CLI ou d'autres configurations non standard peuvent entraîner l'échec de la mise à niveau ou la perte de ces paramètres. |
Mise à niveau du cluster
ACK exécute une prévérification avant chaque mise à niveau, mais celle-ci ne peut pas garantir l'identification de toutes les API, fonctionnalités ou configurations incompatibles. Dans le cadre du modèle de responsabilité partagée, examinez toutes les notes de version et les instructions de mise à niveau pertinentes avant de poursuivre.
Effectuez la mise à niveau pendant les heures creuses afin de minimiser l'impact sur l'activité.
Étape 1 : Mise à niveau du plan de contrôle
Connectez-vous à la console ACK. Dans le volet de navigation de gauche, cliquez sur Clusters.
Sur la page Clusters , cliquez sur le nom du cluster que vous souhaitez mettre à niveau. Dans le volet de gauche, choisissez Operations > Upgrade Cluster.
-
Sur la page Upgrade Cluster , définissez la Destination Version et cliquez sur Precheck . Une fois la prévérification terminée, examinez les résultats dans la section Pre-check Results :
Aucun problème : Le cluster a passé la prévérification. Passez à l'étape suivante.
Problèmes détectés : Le cluster continue de fonctionner normalement. Corrigez les problèmes signalés en suivant les suggestions de la console, puis exécutez à nouveau la prévérification. Consultez la section Éléments de vérification du cluster et méthodes de correction.
Cliquez sur Start Update et suivez les instructions à l'écran. Affichez l'historique des mises à niveau dans le coin supérieur droit de la page Upgrade Cluster . Une fois la mise à niveau du plan de contrôle terminée, accédez à la page Clusters et vérifiez la version Kubernetes dans la colonne Version .
Actions effectuées par ACK lors de la mise à niveau du plan de contrôle :
Met à jour les composants du plan de contrôle : kube-apiserver, kube-controller-manager et kube-scheduler.
Met à jour les composants Kubernetes tels que kube-proxy.
Étape 2 : Mise à niveau des pools de nœuds
Une fois le plan de contrôle mis à niveau, mettez à niveau les pools de nœuds existants dès que possible. Les nœuds d'un pool qui n'ont pas été mis à niveau exécutent toujours la version précédente de Kubernetes.
Consultez les sections Mise à jour d'un pool de nœuds et Mise à jour d'un pool de nœuds Lingjun pour obtenir les étapes détaillées.
Actions effectuées par ACK lors de la mise à niveau d'un pool de nœuds :
Met à jour kubelet et le runtime de conteneur sur chaque nœud.
Migration de Docker vers containerd : Si vous changez le runtime de conteneur de Docker vers containerd, ACK remplace le disque système de chaque nœud, ce qui met également à jour le système d'exploitation et réinstalle les applications. Sauvegardez toutes les données présentes sur les disques système avant de commencer ce type de mise à niveau.
Dans tous les autres scénarios, ACK effectue des mises à jour sur place.
Règles de mise à jour par lots :
Plusieurs pools de nœuds sont mis à niveau un par un.
Au sein d'un pool de nœuds, les nœuds sont mis à niveau par lots : 1 nœud dans le premier lot, puis le nombre double à chaque lot suivant (1 → 2 → 4 → 8...).
Définissez la taille maximale du lot sur la page Node Pool Upgrade . Une taille maximale de lot de 10 est recommandée.
La politique de lotage continue de s'appliquer après la reprise d'une mise à niveau suspendue.
Vérification de la mise à niveau
Une fois les deux phases terminées, confirmez les points suivants :
La colonne Version sur la page Clusters affiche la nouvelle version Kubernetes.
Tous les pools de nœuds sont opérationnels et sains.
Les charges de travail applicatives dans le cluster fonctionnent comme prévu.
Confirmez la version de kubelet sur les nœuds mis à niveau pour vérifier que la mise à niveau du pool de nœuds est terminée.
Dépannage
Échec de la mise à niveau avec le message « the aliyun service is not running on the instance »
L'agent Cloud Assistant n'est pas disponible, donc la commande de mise à niveau ne peut pas être envoyée au nœud. Démarrez ou redémarrez le client Cloud Assistant, puis réessayez la mise à niveau. Consultez la section Démarrage, redémarrage, arrêt ou désinstallation de l'agent Cloud Assistant.
Erreur PLEG not healthy
Le conteneur ou le runtime de conteneur sur le nœud ne répond pas. Redémarrez les nœuds concernés, puis lancez à nouveau la mise à niveau.