Le Stack Harbor PaaS livre régulièrement de nouvelles versions du paquet Kubernetes Cluster. Un cluster existant n’a pas besoin d’être reconstruit pour prendre une version plus récente — un module de mise à niveau dédié fait avancer le cluster en place, avançant à la fois la version mineure de Kubernetes et les composants empaquetés (contrôleur d’ingress, dashboard, metrics server, etc.) comme un tout.
Cette page couvre comment déclencher cette mise à niveau et à quoi s’attendre.
Déclencher la mise à niveau
- Ouvrez l’environnement dans le tableau de bord.
- Survolez le palier Master et cliquez sur Add-Ons.
- Trouvez le panneau Kubernetes Cluster Configuration et cliquez sur Upgrade.
- Confirmez l’action dans la fenêtre.
La plateforme applique la mise à niveau automatiquement — draine et remplace les nœuds maîtres un à la fois, roule les workers en tour, valide chaque étape. La durée exacte dépend de la taille et de la topologie du cluster ; un petit cluster development se met à niveau en quelques minutes, un cluster production avec plusieurs nœuds control-plane et workers prend plus de temps.
Si le cluster est déjà à la dernière version publiée du paquet, le tableau de bord affiche une notification — aucune action ne se lance.
Ce que la mise à niveau roule
Une mise à niveau de paquet avance la version Kubernetes du cluster d’une mineure à la fois (ou applique un patch dans la mineure courante, selon ce qui est disponible) et met à jour les composants empaquetés livrés avec le paquet :
- Le contrôleur d’ingress.
- Le dashboard.
- Le metrics server.
- Le plugin CNI.
- Tout module installé (Prometheus, Grafana, Jaeger, cert-manager, etc.).
Le module ne saute pas de mineure. Pour aller de 1.28 à 1.30, la mise à niveau tourne deux fois — d’abord vers 1.29, puis vers 1.30. Le tableau de bord affiche la prochaine version disponible à chaque fois.
Avant la mise à niveau
Deux choses à faire avant de cliquer sur Upgrade :
- Lire les release notes de la version du paquet vers laquelle vous allez. Le support Stack Harbor peut vous indiquer la source courante. Surveillez :
- Les versions d’API retirées dans la nouvelle mineure Kubernetes. Les charges utilisant Ingress en
extensions/v1beta1ou d’autres API dépréciées de longue date ne s’appliqueront pas dans la nouvelle version. - Les changements de composants empaquetés qui pourraient affecter les annotations d’ingress, les URL du dashboard ou les scrapers de monitoring.
- Les versions d’API retirées dans la nouvelle mineure Kubernetes. Les charges utilisant Ingress en
- Vérifier la santé du cluster. Lancez
kubectl get pods --all-namespacesetkubectl get nodes. Ne commencez pas une mise à niveau avec des charges bloquées enCrashLoopBackOffou des nœudsNotReady— la mise à niveau aggravera le problème existant plutôt que de le corriger.
Pendant la mise à niveau
Les mises à niveau Kubernetes sont conçues pour ne pas perturber les charges actives sur un cluster correctement configuré :
- Le control-plane se met à niveau un nœud à la fois. Avec la topologie production (trois nœuds control-plane derrière des répartiteurs d’API), l’API reste disponible tout du long.
- Les workers sont drainés, mis à niveau et décordonnés un à un. Les charges avec
PodDisruptionBudgetdéfini survivent proprement ; celles sans peuvent voir de brefs redémarrages. - Les volumes persistants et les storage classes ne sont pas affectés.
Si vous êtes en topologie development avec un seul nœud control-plane, la mise à niveau du control-plane implique une courte fenêtre d’indisponibilité de l’API. Prévoyez-la.
Après la mise à niveau
Quand le module rapporte le succès :
- Relancez
kubectl get pods --all-namespacespour confirmer que tout estRunning. - Relisez
/var/log/k8s-health-check.logsur le nœud maître (cat /var/log/k8s-health-check.log) pour confirmer que les composants empaquetés sont sains dans la nouvelle version. - Testez les surfaces externes du cluster — Ingress, dashboard, point d’extrémité de métriques.
Si l’un de ces tests échoue, voir Dépannage Kubernetes pour le chemin diagnostique.