TL;DR: Nous avons tout juste terminé de mettre à jour nos clusters Kube vers EKS 1.25. Si vous allez le faire chez vous, voici des informations qui pourraient vous être utiles.
On a poste ouvert pour Devops/SRE ; Si vous voulez être l’ingénieur de l’équipe qui fera la prochaine mise à jour vers EKS 1.26 😉 n’hésitez pas à candidater!
Pour rappel, on ne fait qu’une mise à jour mineure à la fois sur Kubernetes (et oui, même en managé sous EKS !), cet article suppose que vous opérez donc en EKS 1.24.
Pré-requis AVANT la mise à jour
Lisez avec attention les prérequis, car il n’y a pas de roll-back possible une fois que vous avez accompli une migration vers une version supérieure d’EKS.
AWS LoadBalancer
Il est indispensable de mettre à jour le AWS LoadBalancer Controler en 2.4.7 AVANT de commencer l’upgrade vers EKS 1.25. La documentation officielle AWS l’indique ici.
Mettre à jour la policy du role IAM rattaché
Il faut aussi mettre à jour le role IAM attaché au LoadBalancer Controler, car celui-ci opère maintenant en tagguant certaines ressources.
Le Policy Statement mis à jour se trouve dans la documentation et les évolutions ne continennent que des ajouts. Vous pouvez mettre à jour cette policy sans crainte d’effets de bords
Mettre à jour le Helm Chart de AWS LoadBalancer Controller
Profitez-en pour mettre à jour le helm chart de AWS Loadbalancer. La dernière version du chart est la 1.4.7 du chart, attention, elle pointe de base vers le AWS LoadBalancer Controller 2.4.6, pensez à mettre à jour la valeur dans votre helm
Deprecations dans Kubernetes 1.25
La liste des changements exhaustive entre la 1.24 et la 1.25 se trouve ici.
Pensez à lire les “Urgent Upgrades Notes” qui contiennent les principales évolutions qui peuvent provoquer des interruptions de service. Quelque soit la mise à jour de kubernetes, c’est un bon reflexe.
Voici ce qui pourrait vous affecter :
Pod_Disruption_Budgets n’est plus servi par l’API v1beta1
Vous devez migrer l’API endpoint pour les Pod_Disruption_Budgets vers l’api policy/v1, car l’ancien endpoint policy/v1beta1 ne les sert plus.
Comment détecter les resources à mettre à jour ?
Malheureusement, il est impossible de savoir si ces “Pod_Disruption_Budgets” ont été créés via l’endpoint de déprécié, à cause de la manière dont est faite la création des objets dans Kube.
Même si un objet est créé avec une API Beta, il sera toujours référencé comme créé par la dernière version stable (v1). Plus d’informations à ce lien, mais en gros voici l’explication (copier/coller de la documentation) :
Vous devez donc scanner l’intégralité de vos manifests kubernetes, mais aussi les Helm Charts que vous utilisez pour vous assurer que l’endpoint déprécié n’est pas invoqué.
Cas spécifique pour les ressources kubernetes managées via Terraform
La ressource Terraform kubernetes_pod_disruption_budget utilise l’endpoint déprécié, il faudra migrer votre state vers des objets de type kubernetes_pod_disruption_budget_v1.
Et pas moyen d’envisager un Terraform State Move, les objets sont de type différent, il faut donc les supprimer du state et les importer manuellement sous la forme V1.
L’opération d’import n’est pas documentée dans la documentation du provider Terraform mais fonctionne quand même ainsi :
terraform import module.commons.kubernetes_pod_disruption_budget_v1.datadog-kube-state-metrics kube-system/datadog-kube-state-metricsDeprecation impérative des PodSecurityPolicy
Les Pods Security Policies sont supprimées au profit des Pod Security Associations. Vous ne devez pas avoir des PodSecurityPolicy en exploitation dans votre cluster EKS avant de commencer la mise à jour vers 1.25.
Pour savoir si vous en avez encore, c’est aisé :
kubectl get psp
Si votre client kubectl est à jour, la réponse devrait même contenir un avertissement en bonne et due forme.
A noter qu’il existe une PodSecurityPolicy par défaut (nommée eks.privilegied). Vous pouvez la laisser telle quelle, elle mourira de sa belle mort avec l’upgrade vers EKS 1.25.
Il existe une FAQ bien rédigée d’Amazon EKS sur cette fin de support, elle est disponible ici.
1.23 ≥ EKS addon Kube-Proxy < 1.25
Il n’est pas possible d’avoir un décalage de plus de deux versions mineures entre le Kube-Proxy et le controle plane. Cela est inscrit dans la documentation d’EKS.
Il faut mettre à jour le composant en 1.23 ou 1.24 avant de débuter la mise à jour. Attention, ne pas mettre à jour l’EKS addon vers 1.25 avant d’avoir mis à jour le cluster en 1.25
Autres EKS Addons
Il n’y a pas d’exigence de mettre à jour les autres EKS addons avant la mise à jour, même si c’est préférable de suivre les versions au fur et à mesure.
Attention, les mises à jour de l’EKS Addon VPC-CNI ne peuvent se réaliser qu’une seule version mineure à la fois !
La mise à jour à proprement parler
Mise à jour du EKS Control Plane vers la 1.25
Nous avons réalisé l’opération par notre stack Terraform. L’opération s’est bien déroulée, avec un basculement des nodes vers une nouvelle AMI.
La version du controle plane mise à disposition par EKS est le 1.25.6.
Une fois le Control Plane à jour, ce n’est pas fini, il faut mettre à jour les autres composants.
Mise à jour du Kubernetes Cluster Autoscaler vers 1.25
Il faut suivre le train de version du Controle Plane, donc migrer le Cluster Autoscaler en 1.25.
Voici les notes de version de la branche 1.25 du Cluster AutoScaler. Parmi les trucs chouettes figurent :
- Prise en charge des instances Graviton 7ème génération (bien qu’elles ne soient pas encore en General Availability et disponibles dans quelques régions seulement)
- Prise en charge d’instances intel de 6ème génération
- Renforcement de la fiablilité du Cluster AutoScaler.
Opération de mise à jour du Cluster AutoScaler
Mettre à jour le helm chart (prendre le dernier disponible) et forcer l’AppVersion à 1.25 si nécessaire.
Au démarrage du Cluster AutoScaler, s’assurer de la bonne election du leader.
Mise à jour des EKS Cluster Addons
Les deux EKS Cluster Addons cités peuvent être mis à jour simultanément, leur opération en prend que quelques secondes.
Attention à ne PAS faire ces mises à jour en même temps que le Control Plane, mais dans un second temps.
CoreDNS 1.9
CoreDNS est proposé en version 1.9 par AWS. Le principal changement réside dans les requêtes DNS wildcard : celles-ci ne sont plus supportées et renvoient un enregistrement vide.
A prendre en compte dans le cas où des services d’auto-discovery utiliseraient un tel type de requête DNS (plutôt rare).
Kube-Proxy 1.25
Il est recommandé — mais pas obligatoire — de mettre à jour Kube-Proxy en version 1.25 suite à la mise à jour du controle plane.
Pas de documentation spécifique disponible sur cette mise à jour.
Conclusion
Cette mise à jour s’est bien déroulée sur l’intégralité de nos clusters.
Le processus de mise à jour de la partie managée de Kubernetes (EKS) est toujours aussi fiable et agréable à mettre en oeuvre, dès lors que les prérequis sont bien remplis.
Avec cet article, vous devriez être bien préparé !
