La mise à niveau d'un cluster GKE réserve parfois de mauvaises surprises. Cet article décortique un cas concret où une montée de version vers la 1.27, en apparence anodine, s'est retrouvée bloquée par un appel à une API dépréciée.
GKE suspend les mises à niveau automatiques
Lorsque GKE détecte l'utilisation d'une fonctionnalité ou d'une API dépréciée, il suspend les mises à niveau automatiques pour éviter que votre cluster ne bascule dans un état défaillant. Les passages à la version mineure suivante de Kubernetes sont mis en pause, mais GKE continue de livrer les correctifs sur la version mineure en cours.
Si GKE ne détecte plus aucun usage de la fonctionnalité dépréciée ni d'appel aux API obsolètes pendant 30 jours, le cluster est automatiquement mis à niveau dès lors que la version mineure suivante correspond à la version par défaut du release channel du cluster.
Si GKE continue de détecter l'usage de la fonctionnalité dépréciée, le cluster reste sur sa version mineure actuelle jusqu'à sa date de fin de vie. Une fois cette date — disponible dans le Release Schedule — atteinte, le cluster passe automatiquement à la version mineure suivante, et son environnement risque d'être dégradé puisque la fonctionnalité supprimée est toujours utilisée.
Mise à niveau GKE bloquée
Dans ce cas précis, GKE a identifié un appel à une API dépréciée comme motif du blocage de la mise à niveau depuis la version 1.26. Malgré une recherche approfondie dans le cluster, impossible de mettre la main sur le coupable — un horizontalPodAutoscaler reposant sur une API dépréciée.
Démarche d'investigation
GKE Insights : GKE Insights a bien révélé l'appel à l'API dépréciée (
horizontalPodAutoscalerv2beta2) ainsi qu'un user agent (\"v2.3.0\"), mais ce dernier n'apportait aucune information exploitable.API dépréciée : en consultant la liste des API dépréciées en 1.27, on constate que HPA v2beta2 ne sera plus disponible sur les clusters Kubernetes 1.26.
Admin Activity Audit Logs : la première piste recommandée consiste à repérer les clients API effectuant des appels en écriture vers l'API dépréciée à l'aide de la requête de logs ci-dessous. Le rôle roles/logging.viewer est requis.
resource.type="k8s_cluster"
labels."k8s.io/removed-release"="1.26"
protoPayload.authenticationInfo.principalEmail:("system:serviceaccount" OR "@")
protoPayload.authenticationInfo.principalEmail!~("system:serviceaccount:kube-system:")
- Data Access Audit Logs : l'étape suivante consiste à identifier les clients API effectuant des appels en lecture vers les API dépréciées. Il faut d'abord activer Kubernetes data read et Admin read. Le rôle roles/logging.privateLogViewer peut également être nécessaire pour consulter les logs.
Le coupable démasqué
Une fois les logs alimentés, le coupable est apparu : une version obsolète (2.3.0) de kube-state-metrics ! Ce service de monitoring des objets Kubernetes effectuait des appels list vers l'API dépréciée v2beta2, ce qui déclenchait le blocage. Une bonne illustration du degré d'interconnexion des environnements cloud.
Le code source permet de retrouver précisément l'origine de l'appel.
La résolution
Mettre à jour kube-state-metrics vers une version qui n'utilise plus l'API dépréciée a réglé le problème et ouvert la voie à une mise à niveau GKE sans accroc.
Conclusion
- Filtre d'exclusion du bucket de logs : vérifiez ce filtre pour vous assurer que les data access audit logs ne sont pas écartés, afin d'accélérer l'investigation.
- Suivez les évolutions des API : gardez un œil sur les changements d'API Kubernetes pour anticiper les blocages éventuels lors des mises à niveau.
- Versions statiques ou release channels : pesez le compromis entre versions statiques (stabilité) et release channels (correctifs de sécurité automatiques) pour définir votre stratégie de mise à niveau.
- Pilotez vos mises à niveau avec méthode : tirez parti de l'auto-upgrade et des fenêtres d'exclusion de maintenance pour maîtriser le calendrier, tout en envisageant d'autoriser les patchs pour les correctifs de sécurité critiques.
- Surveillez le coût des logs : activer les data access audit logs peut générer des coûts supplémentaires. Évaluez vos besoins avant de les laisser actifs sur de longues périodes.
En appliquant ces conseils, vous aborderez vos mises à niveau GKE plus sereinement et limiterez les perturbations sur vos opérations cloud.
Si vous ne connaissez pas encore DoiT International, c'est le moment de nous découvrir. Notre équipe est à l'écoute de vos besoins en cloud engineering. Composée exclusivement d'Engineers seniors, elle est spécialisée dans le conseil cloud avancé, la conception d'architectures et le debugging. Contactez-nous, échangeons !
J'espère que cet article vous aura été utile ! Si vous avez des questions, n'hésitez pas à laisser un commentaire ci-dessous.