Azure Kubernetes Service (AKS) est le Kubernetes managé de Microsoft. Networking, identité, auto-scaling, monitoring, coûts : tout ce qu'il faut savoir pour un cluster AKS solide en production.
Pourquoi AKS plutôt qu'un cluster autogéré ?
Azure Kubernetes Service délègue à Microsoft la gestion du control plane (API server, etcd, scheduler, controller manager). Vous ne payez que les nodes workers — le control plane est gratuit. En contrepartie, vous bénéficiez de mises à jour automatiques, d'une SLA de 99,95 % sur l'API server avec les Availability Zones, et d'une intégration native avec l'écosystème Azure (Azure AD, Azure Monitor, Azure Container Registry, Azure Load Balancer).
AKS convient particulièrement aux équipes qui veulent Kubernetes sans la charge opérationnelle d'un cluster kubeadm ou kops. Il est disponible dans toutes les régions Azure, y compris France Central pour les contraintes de souveraineté.
Architecture de référence AKS
Une architecture production typique sur AKS s'articule autour de ces composants :
- VNet dédié avec un subnet pour les nodes et un subnet pour les pods (Azure CNI)
- System node pool : 3 nodes Standard_D4s_v5 répartis sur 3 Availability Zones pour le control plane applicatif (CoreDNS, konnectivity)
- User node pools : pools dédiés par type de charge (general, GPU, spot)
- Azure Container Registry (ACR) : attaché au cluster avec le rôle AcrPull sur la managed identity
- Azure Key Vault : secrets injectés via le CSI driver sans passer par les secrets Kubernetes natifs
- Azure Application Gateway (AGIC) ou NGINX Ingress Controller pour l'exposition HTTP/HTTPS
Networking : Azure CNI vs Kubenet
C'est l'un des premiers choix à faire et il est difficile à changer après déploiement.
| Critère | Azure CNI | Kubenet |
|---|---|---|
| IP par pod | IP VNet réelle | IP privée (NAT) |
| Planification IP | Critique (1 IP/pod) | Libre |
| Peering VNet | ✅ Natif | ⚠️ Routes manuelles |
| Network Policy | Azure / Calico | Calico uniquement |
| Recommandé pour | Production | Dev / petits clusters |
En production, choisissez Azure CNI Overlay (disponible depuis 2023) qui combine les avantages d'Azure CNI sans la contrainte de planification IP stricte — les pods reçoivent une IP d'un espace d'adressage overlay non-routé dans le VNet.
Identité et sécurité : Workload Identity
L'ancienne approche AAD Pod Identity est dépréciée. En 2025, la référence est Azure Workload Identity, basé sur OIDC federation :
- AKS émet un token OIDC pour chaque ServiceAccount
- Une Managed Identity Azure est configurée avec une federated credential pointant vers l'OIDC issuer AKS
- Le pod monte le token OIDC via un volume projeté
- Le SDK Azure échange automatiquement ce token contre un access token Azure AD
Résultat : aucune clé d'API dans les secrets Kubernetes, aucune rotation manuelle. Le pod accède à Key Vault, Blob Storage, ou n'importe quel service Azure avec une identité gérée.
Auto-scaling : Cluster Autoscaler et KEDA
AKS intègre deux mécanismes d'auto-scaling complémentaires :
- Horizontal Pod Autoscaler (HPA) : scale les pods selon CPU/mémoire ou métriques custom
- Cluster Autoscaler : ajoute ou supprime des nodes selon les pods en attente (Pending). Configurez
--scale-down-delay-after-add=10mpour éviter le flapping - KEDA (Kubernetes Event-Driven Autoscaling) : scale sur des métriques externes — longueur d'une queue Azure Service Bus, nombre de messages Event Hub, métriques Prometheus. KEDA peut scaler jusqu'à 0 pods (utile pour les workers batch)
Combiné aux Spot Node Pools (jusqu'à 90 % moins chers), KEDA sur Spot est idéal pour les traitements asynchrones non-critiques.
Monitoring : Azure Monitor + Prometheus managé
AKS propose depuis 2023 un Prometheus managé (Azure Monitor Workspace) et Grafana managé comme alternative à l'auto-hébergement. L'activation se fait en une commande :
az aks update --resource-group rg-prod --name aks-prod --enable-azure-monitor-metrics --azure-monitor-workspace-resource-id /subscriptions/.../azuremonitorworkspaces/amw-prod --grafana-resource-id /subscriptions/.../grafana/grafana-prodLes dashboards Kubernetes standards (Nodes, Pods, Namespaces, API server) sont préconfigurés. Pour les logs, Container Insights envoie les logs stdout/stderr vers Log Analytics Workspace avec une rétention configurable.
Mises à jour et maintenance
AKS supporte N-2 versions Kubernetes. La stratégie recommandée :
- Activez les auto-upgrades en mode
patchpour les correctifs de sécurité automatiques - Configurez une maintenance window (ex: dimanche 2h-5h) pour contrôler quand les upgrades s'appliquent
- Utilisez node image auto-upgrade séparément pour les images OS des nodes (CVE patchées sans changer la version K8s)
- Pour les upgrades de version mineure, testez d'abord sur un cluster de staging avec le même profil de charge
Optimisation des coûts
- Reserved Instances sur les nodes system pool (3 ans = ~55 % de réduction)
- Spot Node Pools pour les workers batch et les environnements de dev
- Start/Stop cluster : arrêtez les clusters de dev en dehors des heures de bureau (économie ~70 %)
- Azure Cost Management : tags
environmentetteamsur les node pools pour le showback - Activez le Vertical Pod Autoscaler (VPA) en mode "Off" (recommandations sans action automatique) pour identifier les pods sur-provisionnés
Conclusion
AKS est un service Kubernetes mature, particulièrement adapté aux entreprises déjà dans l'écosystème Microsoft Azure. Son intégration native avec Azure AD (Workload Identity), Azure Monitor, et l'outillage IaC (Bicep, Terraform) en fait une option solide pour les équipes qui veulent Kubernetes sans compromis sur la sécurité et l'observabilité.
Move2Cloud accompagne ses clients dans la conception et la mise en production de clusters AKS, de l'architecture réseau à la mise en place des pipelines GitOps avec ArgoCD ou Flux.