1. INTERVENANTS
DJEBBOURI Younes
Architecte Azure et DevOps 🚀💻✨
2. PROBLÉMATIQUE
☸ AKS, c’est un écosystème vivant. Pas juste un Kubernetes managé, mais des dizaines de briques qui bougent en même temps
Derrière l’apparente simplicité, tu as un cluster Kubernetes managé par Azure… mais avec des dizaines de briques qui évoluent en permanence :
👉 CNI pour le réseau, CSI pour le stockage, autoscaler, gestion des secrets, observabilité, snapshots, identité, etc.
Et quand tu cliques sur “Upgrade” dans le portail Azure, ce n’est pas seulement Kubernetes qui évolue.
C’est tout l’écosystème AKS qui peut basculer… avec parfois des effets de bord
Un exemple parmi tant d’autres
Tu veux faire une mise à jour de ton cluster ?
Tu fais confiance à Azure, tu cliques sur “Upgrade”.
Quelques minutes plus tard, des pods ne redémarrent plus.
Tu regardes les logs : tes volumes persistants ne se montent plus.
Problème : le CSI Driver a changé de comportement. C’est un breaking change.
Tu aurais pu l’anticiper.
👉 Il était documenté dans le Release Tracker AKS => colonne “Breaking Changes”.
Mais comme souvent, tu ne l’as pas regardé.
Et maintenant, tu gères une crise au lieu d’un upgrade.
La grande problématique
1. Comment garantir un niveau de service clair et assumé ?
👉 SLA (Service Level Agreement) → Quel contrat de disponibilité ? Quel coût ? Quelle garantie réelle ?
3. SERVICE LEVEL AGREEMENT (SLA)
3.1 Comprendre les SLA dans AKS
👉Dans AKS, tout ne repose pas sur un seul bloc.
Tu as deux zones de responsabilité distinctes :
- Le Control Plane, géré par Microsoft
- Le Worker Plane, que tu maîtrises
Et les garanties de service ne sont pas les mêmes des deux côtés
3.2 SLA du Control Plane
Par défaut, le Control Plane est gratuit un choix simple, mais pas neutre.
Gratuit veut dire aucun SLA contractuel, donc pas de remboursement en cas d’incident.
🛑 Tu n’as pas payé → Microsoft ne te doit rien
Même si l’architecture Microsoft est censée être résiliente (Availability Zones, redondance interne), tu assumes le risque sans contrat.
Pour aller plus loin, Microsoft propose deux options payantes :
| Tier AKS | SLA garanti | Prix mensuel |
|---|---|---|
| Free Tier | Aucun | 0 € |
| Standard Tier | 99,95 % (avec AZ) / 99,9 % (sans AZ) | 65,37 €/cluster/mois |
| Premium Tier | 99,95 % (avec AZ) / 99,9 % (sans AZ) | 392,24 €/cluster/mois |
💡 Le Standard Tier est souvent le bon compromis pour la prod.
💡 Le Premium Tier ajoute un support Long-Term (LTS) pour Kubernetes mais à un coût non négligeable
Retour d’expérience terrain :
“Sur plusieurs années d’exploitation, rares sont les cas où le Control Plane a réellement posé problème”
Cette stabilité constatée par beaucoup pousse à faire des choix pragmatiques :
- Clusters de dev ➡️ Free Tier
- Clusters de prod ➡️ Standard Tier
- Clusters critiques ou avec contraintes LTS ➡️ Premium Tier
| ⚠️ À savoir avant de choisir : Le Premium Tier coûte cher – Il peut être utile si tu veux garder une version Kubernetes figée pendant 2 ans (support LTS), mais ce n’est pas indispensable dans tous les cas – Le Free Tier n’est pas disponible dans toutes les régions Par exemple, West Europe ne le propose pas. Il faudra alors forcément basculer vers le Standard Tier |
3.3 SLA du Worker Plane
Le Worker Plane, c’est ton terrain de jeu
Tes VM, ton réseau, tes disques, ton stockage : tout ça, c’est toi qui les déploies, les paies, les maintiens.
Tu veux un vrai SLA ?
👉 Il faut le construire à partir des briques Azure :
- Des VMSS pour assurer le scaling automatique
- Des Availability Zones pour répartir les nœuds
- Des architectures redondantes, pensées pour encaisser la panne
Cela te permet de viser un SLA composite basé sur les engagements de disponibilité de chaque ressource (VM, disque, réseau…).
Mais n’oublie pas :
🔁 Plus de résilience = plus de complexité + plus de coûts.
3.4 Cycle de vie des versions Kubernetes
🎯 Kubernetes évolue vite. Trop vite, parfois.
Quand tu travailles avec AKS, tu n’as pas le luxe de rester figé sur une version pendant 3 ans.
Et pourtant, c’est un réflexe courant dans l’IT.
Mais ici, le rythme est imposé, que tu le veuilles ou non.
Un cycle cadencé… et à respecter
- Kubernetes publie 3 versions mineures par an (au lieu de 4 à l’origine)
- Microsoft s’engage à les rendre disponibles sur AKS dans les 90 jours
- Et ne supporte que les versions N, N-1, N-2
👉 En clair :
Si ton cluster reste sur une version trop ancienne (N-3 ou au-delà),
le support Microsoft te renverra à la case départ :
“Repasse sur une version supportée, et on en reparle”
Une montée de version par an : le minimum vital
Techniquement, tu pourrais suivre chaque release.
Mais dans la réalité, faire une upgrade complète d’AKS, ça ne s’improvise pas.
Ce n’est pas du “next next finish”.
- Il faut lire les notes de version
- Identifier les breaking changes
- Tester les impacts sur ton environnement (composants, workloads, CSI, CNI, Secret Provider…)
💡 Une upgrade bien préparée vaut mieux que trois upgrades à l’aveugle.
C’est pour ça que la bonne pratique, c’est de faire une mise à jour par an, dans la fenêtre de support Microsoft.
Le piège des sous-versions
Tu verras dans le AKS Release Tracker que certaines versions ont des sous-versions (1.31.3, 1.32.4, etc.).
💡 Pas besoin de suivre chaque patch sauf cas critique.
Microsoft backporte la majorité des correctifs importants directement dans les versions supportées.
⚠️ Upgrade ≠ mise à jour sans impact
À chaque version, le cluster entier évolue :
- kubelet, kube-proxy, DNS, CSI, CNI, Metrics Server…
- Certains modules changent de comportement
- D’autres introduisent des incompatibilités
Et c’est là que tu réalises que cliquer sur “Upgrade” dans le portail, c’est pas un acte anodin.
Comment anticiper les problèmes ?
Avant chaque upgrade, consulte le Release Tracker AKS (GitHub officiel de Microsoft)
https://github.com/Azure/AKS/releases
Lis la colonne “Breaking Changes”, regarde les add-ons que tu utilises (CSI, Secret Provider, KEDA…), et prends une décision en connaissance de cause.
3.5 Long-Term Support (LTS) pour AKS
Objectifs du LTS
🎯 Et si on arrêtait de courir après les versions ?
C’est exactement ce que propose Microsoft avec le Long-Term Support (LTS) pour AKS :
👉 Prolonger la durée de vie d’une version Kubernetes jusqu’à 2 ans de support garanti
Concrètement :
- Tu bloques ton cluster sur une version LTS (par ex. 1.27, 1.30…)
- Microsoft te fournit les patchs de sécurité backportés
- Tu évites de faire 2 à 3 upgrades par an
💡 Une vraie bouffée d’air pour les plateformes critiques qui n’aiment pas les changements fréquent
Limitations actuelles du LTS
⚠️ Mais attention, le rêve a des conditions.
Le LTS, c’est bien. Mais aujourd’hui, ce n’est pas un support complet de l’écosystème AKS.
Voici les limitations majeures à connaître :
- Le LTS ne couvre que le moteur Kubernetes.
❌Pas les add-ons comme :- 🔴 Azure CNI
- 🔴 CSI Drivers
- 🔴 Azure Monitor for Containers
- 🔴 Metrics Server, Calico, Dapr…
- Ces composants peuvent évoluer indépendamment du cluster, avec ou sans compatibilité LTS.
Et si un jour tu dois ouvrir un ticket sur un bug dans un add-on… il se peut que la réponse soit : “Cette version n’est plus supportée, même si votre cluster est en LTS.”
Et donc… on le prend ou pas ?
💡 L’intérêt du LTS, c’est de gagner du temps.
Mais ce temps, tu le paies très cher (via le Premium Tier), et tu repousses surtout le problème.
Car après 2 ans sans upgrade, tu te retrouves à faire :
- Un grand saut technique (de 1.27 à 1.30 par exemple)
- Avec une longue liste de breaking changes à rattraper d’un coup
- Et parfois, des composants qui ne sont même plus maintenus par leurs propres éditeurs
👉 Résultat : tu gagnes du temps… mais tu accumules du risque technique.
Et tu risques de prendre plus cher plus tard.
4. CONCLUSION
Un SLA, ce n’est pas un chiffre marketing.
C’est un choix d’architecture, de coûts, et de responsabilités.
Tu dois décider :
- Est-ce que le LTS est une bouée de sauvetage ou un piège ?
- Quel SLA tu veux (et peux) financer ?
- Quel rythme d’upgrade tu es prêt à assumer ?
| 💡 En clair : pas de SLA sans design. Et chaque choix d’option (gratuit, standard, premium, LTS) est un arbitrage entre risque, coût et responsabilité. |
PROCHAIN ARTICLE
👉 La Partie 2 sera dédiée à la résilience et aux backups
On parlera de scalabilité intelligente, autoscaling, NAP, HPA, Dapr, Istio… et de sauvegarde multi-niveaux (IaC, état Kubernetes, volumes persistants)
Bref, tout ce qu’il faut pour que ton AKS survive aux pannes et que tes applis continuent à tourner.
