Chez DoiT International, nous accompagnons des clients de toutes tailles et identifions régulièrement des problèmes récurrents, en particulier chez nos clients de grande envergure. Nous souhaitons revenir sur un incident rencontré récemment lors de la mise à niveau de GKE (Kubernetes managé de Google), au cas où d'autres équipes prépareraient leurs mises à niveau ou seraient confrontées à des soucis similaires.
Symptômes
Précisons d'emblée que tous les clients ne sont pas concernés. Voici néanmoins les symptômes que nous avons observés :
- après la mise à niveau, la CLI kubectl ne parvient plus à interagir avec le cluster (l'API-Server ne répond pas) ;
- le processus de mise à niveau semble figé et ne se termine pas après plus de 20 minutes ;
- un message d'erreur apparaît dans la console ou les logs, du type : All cluster resources were brought up, but: component "kube-apiserver" from endpoint "gke-XXXXXXXX-XXXXXXX" is unhealthy.
Diagnostic des risques
Tout le monde n'est pas concerné, mais voici les points communs que nous avons relevés :
- cluster GKE en version inférieure à 1.16 ;
- cluster zonal (master mono-zone pour le control plane) ;
- workloads particulièrement bavards qui sollicitent en continu l'API-Server, comme Istio, Flux ou ArgoCD ;
- mises à niveau entre versions majeures du type 1.12 -> 1.13, 1.13 -> 1.14, 1.14 -> 1.15, 1.15 -> 1.16 (rarement observé lors des patchs).
Qui est susceptible d'être impacté ?
Rappelons que le phénomène ne s'est manifesté que chez quelques clients à ce jour, dont la plupart correspondent à ce profil : clusters zonaux et workloads importants sollicitant l'API-Server au point de l'empêcher de passer les health checks dans les délais lors des mises à niveau, ce qui le laisse dans un état figé. Nous espérons que ces informations vous seront utiles, que ce soit pour planifier vos prochaines mises à niveau ou pour résoudre des problèmes en cours.
Remédiation
Demande auprès du support Google pour augmenter le timeout des health checks
Si vous êtes déjà confronté à ce problème mais que vos worker nodes continuent de servir le trafic (seul l'accès kubectl au control plane est perdu), vous pouvez ouvrir un ticket auprès du support Google, ou de votre partenaire de support technique (idéalement DoiT International), afin de porter le timeout des health checks à 3 minutes. L'API-Server disposera ainsi du temps nécessaire pour récupérer, évitant un enchaînement de health checks en échec.
Réduire la taille du node pool et la charge sur l'API-Server
Si vous pouvez tolérer une indisponibilité ponctuelle de vos worker nodes, vous pouvez soulager l'API-Server de deux manières : désactiver temporairement les workloads bavards et les mettre à l'échelle vers le bas, ou simplement réduire votre node pool à 0 le temps que la mise à niveau se termine, puis le redimensionner à nouveau.
Autres causes possibles
Certains de nos ingénieurs ont rencontré des cas où le control plane devenait inaccessible à cause d'une race condition liée à la table netfilter/conntrack de Linux. Ce problème a été corrigé, mais les versions plus anciennes y restent sensibles.
Solution à long terme
Les ingénieurs de Google ont identifié le problème et un correctif est prévu d'ici le mois prochain pour la version 1.16 ou ultérieure (mise à niveau manuelle). À l'heure où nous publions cet article, aucun lien public vers un issue tracker n'est disponible.
Faire passer votre cluster du mode zonal au mode régional
Malheureusement, il n'existe pas de solution clé en main pour faire passer un cluster du mode zonal au mode régional, mais l'un de nos architectes cloud a rédigé un article qui détaille une approche de migration reposant sur un outil open-source populaire : Velero.