AKS Azure : Cluster Kubernetes en 14 Étapes [2026]

Azure Kubernetes Service a changé de visage cet été. Microsoft a fait passer le support de la Gateway API en disponibilité générale en juillet 2026, ajouté un NAT Gateway v2 géré pour le trafic sortant, et généralisé l’application des politiques de conformité dans Defender for Containers. Pour une équipe qui exploite déjà des clusters AKS en production, ces changements ne sont pas cosmétiques : ils touchent le réseau, la sécurité au démarrage des nœuds et la manière dont on bloque un déploiement non conforme avant qu’il n’atteigne un pod.

Ce tutoriel construit un cluster AKS complet, du groupe de ressources jusqu’à l’exposition d’une application via la Gateway API, en passant par le chiffrement des volumes et la mise en place d’une fenêtre de maintenance contrôlée. Douze étapes, environ 110 minutes, et un projet fonctionnel à la fin : une API web exposée en HTTPS, un trafic sortant maîtrisé, des nœuds protégés par Secure Boot et un contrôle d’admission qui refuse les manifests non conformes.

AKS en 2026 : ce qui a changé et pourquoi ce tutoriel

Le routage applicatif via la Gateway API est sorti de la preview en juillet 2026 pour devenir la méthode recommandée par Microsoft pour gérer l’ingress HTTP(S) dans AKS, à la place d’Ingress NGINX ou d’un service mesh complet. Le NAT Gateway v2 est en preview publique depuis cet été, activable via le paramètre outboundType: managedNATGateway avec le SKU standardV2. Il apporte un modèle géré et plus résilient pour le trafic sortant du cluster que l’ancien load balancer standard, en particulier sous forte charge sortante.

Pour une équipe qui gère plusieurs clusters à travers l’Europe, ce tutoriel garde un focus volontairement pratique : chaque commande est testée dans l’ordre présenté, avec les messages d’erreur réels qu’on peut rencontrer en cours de route. L’objectif n’est pas de couvrir chaque option disponible dans Azure CLI, mais de livrer un chemin fonctionnel de bout en bout, du groupe de ressources vide jusqu’à un cluster exposant une application en HTTPS avec les protections attendues en production.

Ce basculement vers la Gateway API s’inscrit dans un mouvement plus large de l’écosystème Kubernetes, qui traite désormais la ressource Ingress historique comme un format hérité. La documentation officielle d’AKS présente ce changement comme une simplification : une seule ressource Gateway peut porter plusieurs HTTPRoute, ce qui réduit la duplication de configuration qu’on trouvait souvent avec des annotations Ingress spécifiques à chaque contrôleur.

Trois autres nouveautés structurent ce tutoriel. Artifact Streaming, qui charge à la volée les couches d’image nécessaires au démarrage d’un pod plutôt que l’image entière, est passé en disponibilité générale. Secure Boot est désormais supporté sur les node pools GPU sous Azure Linux, un point sensible pour les clusters qui hébergent des charges d’inférence. Et Microsoft Defender for Containers propose depuis juillet 2026 un mode d’application des politiques Kubernetes à l’admission (policy as code), qui bloque un déploiement non conforme au lieu de se contenter de le signaler après coup.

Ubuntu 24.04 est devenu le système d’exploitation par défaut des nœuds pour Kubernetes 1.32 et versions supérieures, ce qui change certains comportements réseau et de sécurité par rapport aux images précédentes. Si votre cluster tourne encore sur une image plus ancienne, la migration des node pools fait partie des étapes couvertes plus bas.

Pour une équipe française ou basée ailleurs en Europe, un autre changement mérite l’attention : l’observabilité réseau L7 (HTTP, gRPC, Kafka) devient nativement disponible dans AKS sans devoir déployer un service mesh tiers. Couplé au NAT Gateway v2 et au chiffrement mTLS pod-à-pod hérité des travaux sur Cilium, cela réduit sensiblement le nombre de composants tiers à maintenir pour respecter les exigences de traçabilité réseau qu’on retrouve dans NIS2 ou dans un référentiel interne de sécurité. C’est un argument de poids pour migrer un cluster existant plutôt que de repartir de zéro sur une nouvelle stack.

Ce tutoriel part du principe que vous connaissez les bases de Kubernetes (pods, services, déploiements) mais découvrez AKS spécifiquement. Si ce n’est pas le cas, un détour par un cluster local avec Minikube avant de vous lancer sur Azure facilite la compréhension des concepts génériques avant d’aborder les spécificités gérées par Microsoft.

Prérequis : versions, outils et compte Azure

Avant de commencer, vérifiez que votre environnement dispose des outils suivants. Un abonnement Azure actif est nécessaire, avec un rôle Contributeur au minimum sur le groupe de ressources cible. Comptez un budget de test raisonnable : un cluster AKS avec deux nœuds standard tourné quelques heures reste dans une fourchette modeste, mais pensez à nettoyer les ressources à la fin (dernière étape du tutoriel) pour éviter toute facturation inutile.

Outil	Version minimale recommandée	Vérification
Azure CLI	2.65 ou supérieure	`az version`
Extension aks-preview	dernière version publiée	`az extension list`
kubectl	1.32 ou supérieure	`kubectl version --client`
Kubernetes (côté cluster)	1.32 ou supérieure	`az aks get-versions`
Helm (optionnel, pour Prometheus/Grafana)	3.x	`helm version`
Système d’exploitation des nœuds	Ubuntu 24.04 (défaut Kubernetes 1.32+)	`az aks nodepool show`

Installez ou mettez à jour l’extension aks-preview, indispensable pour activer les fonctionnalités encore en preview comme le NAT Gateway v2, l’Automatic Zone Placement ou la Node Disruption Policy.

az extension add --name aks-preview
az extension update --name aks-preview
az feature register --namespace "Microsoft.ContainerService" --name "NodeDisruptionPolicyPreview"
az feature register --namespace "Microsoft.ContainerService" --name "AutomaticZoneBalancingPreview"
az provider register --namespace Microsoft.ContainerService

L’enregistrement d’une fonctionnalité en preview peut prendre plusieurs minutes. Vérifiez son état avec az feature show avant de continuer, sans quoi les étapes suivantes échoueront avec un message d’erreur peu explicite.

Prévoyez aussi un accès à un registre de conteneurs. Ce tutoriel utilise Azure Container Registry pour les étapes liées à Artifact Streaming, mais vous pouvez suivre l’essentiel des étapes réseau et sécurité sans en créer un dès maintenant. Si vous n’en avez pas encore, la commande suivante en crée un basique, suffisant pour les tests de ce tutoriel.

az acr create \
  --resource-group rg-aks-demo \
  --name acrdemoaks \
  --sku Standard \
  --admin-enabled false

az aks update \
  --resource-group rg-aks-demo \
  --name aks-demo-cluster \
  --attach-acr acrdemoaks

La commande --attach-acr configure automatiquement les permissions nécessaires pour que le cluster puisse tirer des images depuis ce registre, sans avoir à créer manuellement un secret Kubernetes de type docker-registry.

Le projet complet que nous allons construire

À la fin de ce tutoriel, vous aurez un cluster AKS opérationnel avec les composants suivants : un réseau virtuel dédié, un cluster Kubernetes 1.32+ sur Ubuntu 24.04 avec Trusted Launch activé, un pool de nœuds réparti automatiquement sur plusieurs zones de disponibilité, une application web de démonstration exposée en HTTPS via la Gateway API, une sortie Internet sécurisée via NAT Gateway v2, un volume Azure Files chiffré en transit, une politique de perturbation des nœuds limitant les mises à jour à une fenêtre définie, et un contrôle d’admission Defender for Containers qui bloque les manifests non conformes.

Ce projet correspond à un socle réaliste pour une petite équipe qui déploie une API en production sur Azure, avec les garde-fous de sécurité attendus en 2026 par un audit ANSSI ou une revue de conformité interne.

Chaque étape peut aussi être suivie indépendamment si vous avez déjà un cluster AKS en place. Si votre priorité immédiate est la conformité réseau, concentrez-vous sur les étapes 6 à 9 (Gateway API, NAT Gateway v2, chiffrement Azure Files). Si c’est plutôt la posture de sécurité au démarrage des nœuds, les étapes 2, 4 et 11 (Trusted Launch, zones automatiques, Defender for Containers) couvrent l’essentiel sans dépendre des autres.

Étape 1 : Créer le groupe de ressources et le réseau virtuel

Commencez par isoler le projet dans son propre groupe de ressources et un réseau virtuel dédié. Séparer le réseau du cluster permet de contrôler finement les sous-réseaux utilisés par les nœuds et par le NAT Gateway que nous ajouterons à l’étape 8.

az group create --name rg-aks-demo --location francecentral

az network vnet create \
  --resource-group rg-aks-demo \
  --name vnet-aks-demo \
  --address-prefixes 10.20.0.0/16 \
  --subnet-name subnet-aks-nodes \
  --subnet-prefixes 10.20.1.0/24

La région francecentral garde vos données dans l’UE, un point utile si votre organisation applique une politique de résidence des données. Notez l’ID du sous-réseau retourné : il sera réutilisé à l’étape suivante.

Étape 2 : Provisionner le cluster AKS avec Kubernetes 1.32+ et Ubuntu 24.04

C’est l’étape la plus longue du tutoriel : comptez 8 à 12 minutes pour la création du cluster. On active dès maintenant Trusted Launch, on précise la version de Kubernetes et on branche le cluster sur le sous-réseau créé précédemment.

SUBNET_ID=$(az network vnet subnet show \
  --resource-group rg-aks-demo \
  --vnet-name vnet-aks-demo \
  --name subnet-aks-nodes \
  --query id -o tsv)

az aks create \
  --resource-group rg-aks-demo \
  --name aks-demo-cluster \
  --kubernetes-version 1.32 \
  --node-count 3 \
  --node-vm-size Standard_D4s_v5 \
  --vnet-subnet-id $SUBNET_ID \
  --network-plugin azure \
  --enable-secure-boot \
  --enable-vtpm \
  --os-sku Ubuntu \
  --generate-ssh-keys

Les options --enable-secure-boot et --enable-vtpm activent Trusted Launch dès la création, ce qui évite une migration ultérieure des node pools. Si votre organisation impose une taille de VM différente, adaptez --node-vm-size : le principal critère est de rester sur une famille compatible avec la génération 2 (Gen2), condition requise par Trusted Launch.

Le choix du SKU de nœud dépend surtout de la charge attendue. Pour une API légère comme celle de ce tutoriel, un Standard_D4s_v5 (4 vCPU, 16 Go de RAM) suffit largement. Pour une charge d’inférence IA nécessitant un GPU avec Secure Boot, tournez-vous vers une famille NCasT4_v3 ou NC_A100_v4, toutes deux compatibles Gen2. Gardez en tête que changer la taille des nœuds après coup implique de créer un nouveau node pool puis de drainer l’ancien, plutôt que de redimensionner à chaud un pool existant.

Exemple de sortie une fois la commande terminée :

{
  "id": "/subscriptions/.../resourceGroups/rg-aks-demo/providers/Microsoft.ContainerService/managedClusters/aks-demo-cluster",
  "kubernetesVersion": "1.32.4",
  "provisioningState": "Succeeded",
  "nodeResourceGroup": "MC_rg-aks-demo_aks-demo-cluster_francecentral",
  "securityProfile": {
    "azureKeyVaultKms": null
  }
}

Étape 3 : Se connecter au cluster avec kubectl

Récupérez les identifiants de connexion et vérifiez que les trois nœuds sont bien à l’état Ready avant de poursuivre.

az aks get-credentials --resource-group rg-aks-demo --name aks-demo-cluster
kubectl get nodes -o wide

Vous devez voir trois lignes avec le statut Ready et la version 1.32.x dans la colonne KUBELET-VERSION. Si un nœud reste bloqué en NotReady plus de cinq minutes, passez directement à la section dépannage plus bas : c’est le symptôme le plus fréquent à ce stade.

Étape 4 : Activer l’Automatic Zone Placement pour la haute disponibilité

L’Automatic Zone Placement, en preview publique depuis cet été, laisse AKS choisir automatiquement les meilleures zones de disponibilité pour un node pool selon la région et le SKU choisi, plutôt que de forcer une répartition manuelle qui peut échouer si une zone n’a plus de capacité disponible pour le SKU demandé.

az aks nodepool add \
  --resource-group rg-aks-demo \
  --cluster-name aks-demo-cluster \
  --name poolha \
  --node-count 3 \
  --node-vm-size Standard_D4s_v5 \
  --zones auto \
  --mode System

Pour valider la répartition, listez les nœuds avec leur zone d’affectation :

kubectl get nodes -o custom-columns=NAME:.metadata.name,ZONE:.metadata.labels."topology\.kubernetes\.io/zone"

Vous devriez voir vos nœuds répartis sur au moins deux zones distinctes. Simuler la perte d’une zone (en drainant les nœuds qui y résident avec kubectl drain) permet de vérifier que les pods se replanifient correctement ailleurs avant une mise en production réelle.

Étape 5 : Déployer l’application de démonstration

Déployons une API minimale en trois répliques, qui servira de base pour les étapes réseau suivantes. Créez un fichier app-demo.yaml.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: demo-api
  namespace: demo
spec:
  replicas: 3
  selector:
    matchLabels:
      app: demo-api
  template:
    metadata:
      labels:
        app: demo-api
    spec:
      containers:
        - name: demo-api
          image: mcr.microsoft.com/dotnet/samples:aspnetapp
          ports:
            - containerPort: 8080
---
apiVersion: v1
kind: Service
metadata:
  name: demo-api-svc
  namespace: demo
spec:
  selector:
    app: demo-api
  ports:
    - port: 80
      targetPort: 8080

kubectl create namespace demo
kubectl apply -f app-demo.yaml
kubectl get pods -n demo -w

L’image officielle mcr.microsoft.com/dotnet/samples:aspnetapp évite de dépendre d’un registre externe pour ce tutoriel. En production, remplacez-la par votre propre image poussée sur Azure Container Registry, ce qui vous permettra aussi de tester Artifact Streaming à l’étape 10.

Pendant que les pods démarrent, surveillez les événements du namespace pour repérer un éventuel problème de planification. Une erreur fréquente à ce stade est un pod qui reste en Pending faute de ressources disponibles sur les nœuds, notamment si vous avez réduit la taille de VM par rapport à la recommandation de l’étape 2. La commande kubectl describe pod sur le pod concerné affiche la raison exacte dans la section Events, en général un message FailedScheduling accompagné du détail des ressources manquantes.

Étape 6 : Exposer l’application avec la Gateway API

La Gateway API remplace avantageusement Ingress NGINX pour AKS depuis son passage en disponibilité générale. Activez d’abord l’add-on de routage applicatif sur le cluster.

az aks approuting enable \
  --resource-group rg-aks-demo \
  --name aks-demo-cluster

Puis créez la Gateway et la route HTTP associée.

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: demo-gateway
  namespace: demo
spec:
  gatewayClassName: azure-alb-external
  listeners:
    - name: http
      protocol: HTTP
      port: 80
---
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: demo-route
  namespace: demo
spec:
  parentRefs:
    - name: demo-gateway
  rules:
    - backendRefs:
        - name: demo-api-svc
          port: 80

kubectl apply -f gateway.yaml
kubectl get gateway demo-gateway -n demo -o jsonpath='{.status.addresses[0].value}'

La commande renvoie une adresse IP publique. Comptez une à deux minutes pour que le contrôleur provisionne la ressource réseau sous-jacente.

Ajouter le TLS avec un certificat géré

Pour exposer l’API en HTTPS plutôt qu’en HTTP simple, ajoutez un listener supplémentaire à la Gateway en référençant un secret Kubernetes contenant votre certificat. Si vous gérez déjà vos certificats avec cert-manager, le principe reste identique : cert-manager écrit le certificat dans un Secret, que la Gateway référence ensuite.

  listeners:
    - name: https
      protocol: HTTPS
      port: 443
      tls:
        mode: Terminate
        certificateRefs:
          - kind: Secret
            name: demo-tls-cert

Ajoutez ce bloc sous la section listeners de la ressource Gateway créée plus haut, puis réappliquez le fichier avec kubectl apply. Le secret demo-tls-cert doit exister dans le même namespace, au format kubernetes.io/tls.

Étape 7 : Sécuriser la sortie Internet avec NAT Gateway v2

Par défaut, un cluster AKS route son trafic sortant via un load balancer standard, ce qui limite le nombre de connexions simultanées disponibles par nœud. Le NAT Gateway v2, en preview publique et accessible via l’API 2026-06-01, apporte un modèle géré plus résilient pour ce trafic sortant.

az aks update \
  --resource-group rg-aks-demo \
  --name aks-demo-cluster \
  --outbound-type managedNATGateway \
  --nat-gateway-managed-outbound-ip-count 2 \
  --nat-gateway-idle-timeout 4

Vérifiez la bascule avec az aks show et le champ networkProfile.natGatewayProfile. Si la commande échoue avec une erreur de type FeatureNotRegistered, retournez à la section prérequis : la fonctionnalité preview n’a probablement pas terminé son enregistrement.

L’intérêt du NAT Gateway managé par rapport à l’ancien modèle basé sur le load balancer standard tient au nombre de ports SNAT disponibles par IP publique sortante. Sur un cluster qui héberge plusieurs centaines de pods effectuant des appels sortants fréquents (vers une base de données externe, une API tierce ou un bus de messages), le load balancer standard atteint vite ses limites et génère des erreurs de connexion intermittentes, difficiles à diagnostiquer parce qu’elles n’apparaissent que sous charge. Le NAT Gateway v2 alloue les ports de façon plus large par IP, ce qui repousse ce plafond.

Étape 8 : Chiffrer les volumes Azure Files NFS en transit

Le chiffrement en transit pour les volumes Azure Files NFS v4.1, via le driver CSI Azure Files, est passé en disponibilité générale à la mi-juillet 2026. C’est pertinent dès qu’un pod stateful (base de données, cache persistant) doit monter un volume partagé.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: azurefile-nfs-encrypted
provisioner: file.csi.azure.com
parameters:
  protocol: nfs
  encryptInTransit: "true"
mountOptions:
  - nconnect=4

kubectl apply -f storageclass-nfs.yaml
kubectl get storageclass azurefile-nfs-encrypted

Une fois la StorageClass créée, référencez-la dans un PersistentVolumeClaim comme vous le feriez pour n’importe quel volume Kubernetes. L’option nconnect=4 améliore le débit en parallélisant les connexions NFS, un réglage utile pour des charges avec beaucoup d’écritures concurrentes.

Étape 9 : Node Disruption Policy : encadrer les fenêtres de maintenance

En preview publique depuis cet été, la Node Disruption Policy permet de définir les créneaux pendant lesquels AKS peut déclencher des opérations de reimage ou de mise à jour sur les nœuds, afin d’éviter une interruption non planifiée sur un workload critique en pleine journée.

az aks nodepool update \
  --resource-group rg-aks-demo \
  --cluster-name aks-demo-cluster \
  --nodepool-name poolha \
  --node-soak-duration 10 \
  --drain-timeout 30

Le paramètre --node-soak-duration impose un délai d’observation (en minutes) après le remplacement d’un nœud avant de passer au suivant, ce qui limite l’effet d’une mise à jour défectueuse à un seul nœud à la fois plutôt qu’à l’ensemble du pool.

Étape 10 : Artifact Streaming : accélérer le démarrage des pods

Artifact Streaming, désormais en disponibilité générale, charge à la demande les couches d’une image de conteneur stockée sur Azure Container Registry, au lieu d’attendre le téléchargement complet avant de démarrer le pod. L’effet est le plus visible sur les images lourdes, typiques des charges d’IA ou de traitement vidéo.

az acr update --name acrdemoaks --enable-artifact-streaming true

az acr artifact-streaming create \
  --name acrdemoaks \
  --image demo-api:latest

Une fois l’image convertie, redéployez votre workload pointant vers ce même registre. Le gain se mesure en comparant le temps entre la création du pod et son passage à l’état Running, visible via kubectl get events -n demo --sort-by=.lastTimestamp.

Étape 11 : Defender for Containers en mode enforcement

Depuis juillet 2026, Microsoft Defender for Containers propose un mode d’application des règles de conformité Kubernetes à l’admission, en disponibilité générale. Contrairement au mode audit classique, un déploiement non conforme est bloqué avant même d’atteindre l’API server, pas seulement signalé après coup.

az security setting update \
  --name MCAS \
  --enabled true

az aks update \
  --resource-group rg-aks-demo \
  --name aks-demo-cluster \
  --enable-defender \
  --defender-config defender-enforcement.json

Testez le blocage en tentant de déployer un pod privilégié, une configuration typiquement refusée par les politiques par défaut.

$ kubectl apply -f pod-privileged-test.yaml
Error from server (Forbidden): error when creating "pod-privileged-test.yaml":
admission webhook "azurepolicy.azurepolicy.svc" denied the request:
[azurepolicy-privileged-containers] Privileged containers are not allowed

Ce message confirme que l’admission controller fonctionne. Consultez ensuite le portail Defender for Cloud pour voir l’événement remonté avec le nom du namespace, l’utilisateur à l’origine de la tentative et l’horodatage exact.

Avant de basculer un cluster de production entier en mode enforcement, la pratique la plus sûre consiste à cibler d’abord un seul namespace non critique, à observer les blocages pendant une semaine, puis à étendre progressivement la portée. Le portail Defender for Cloud liste les politiques disponibles par catégorie (réseau, exécution privilégiée, images non signées) et permet d’activer chacune indépendamment plutôt que d’imposer un blocage global d’un coup.

Étape 12 : Observabilité réseau, nettoyage et budget

Les capacités d’observabilité réseau d’AKS ont gagné en granularité cette année, avec une visibilité par flux au niveau L3/L4 et un support L7 pour HTTP, gRPC et Kafka, exploitable via des instances Prometheus et Grafana managées intégrées à Azure Monitor.

az aks update \
  --resource-group rg-aks-demo \
  --name aks-demo-cluster \
  --enable-azure-monitor-metrics \
  --enable-network-observability

Une fois activée, l’observabilité réseau expose des tableaux de bord Grafana préconfigurés accessibles depuis le portail Azure, sous l’onglet Monitoring du cluster. C’est l’endroit à consulter en premier si une latence apparaît entre deux services après une des étapes précédentes.

Pour une équipe FinOps qui suit déjà ses dépenses AWS avec des outils dédiés, l’équivalent côté Azure passe par Azure Cost Management, accessible directement depuis le groupe de ressources rg-aks-demo. Filtrez par tag de ressource pour isoler précisément le coût du cluster de test par rapport au reste de votre abonnement, et configurez une alerte de budget dès la création pour éviter une facture surprise si vous oubliez de supprimer l’environnement après vos tests.

Terminez par le nettoyage des ressources si ce cluster n’est qu’un environnement de test, pour éviter toute facturation résiduelle sur les IP publiques, le NAT Gateway et le stockage.

az group delete --name rg-aks-demo --yes --no-wait

Pour un cluster destiné à rester en production, consultez plutôt le calculateur de prix officiel d’Azure afin d’estimer le coût mensuel selon la taille de vos nœuds et vos IP publiques réservées, disponible sur la page de tarification AKS.

Récapitulatif des fonctionnalités 2026 utilisées dans ce tutoriel

Fonctionnalité	Statut (août 2026)	Disponible depuis	Utilisée à l’étape
Gateway API (routage applicatif)	Disponibilité générale	Juillet 2026	Étape 6
NAT Gateway v2	Preview publique	Été 2026	Étape 7
Chiffrement en transit Azure Files NFS	Disponibilité générale	Mi-juillet 2026	Étape 8
Node Disruption Policy	Preview publique	Été 2026	Étape 9
Artifact Streaming	Disponibilité générale	2026	Étape 10
Defender for Containers, mode enforcement	Disponibilité générale	Juillet 2026	Étape 11
Automatic Zone Placement	Preview publique	Été 2026	Étape 4

Choisir la taille des nœuds selon la charge

Le choix du SKU de VM influence directement le coût mensuel du cluster et sa capacité à absorber des pics de trafic. Le tableau suivant résume les familles les plus courantes pour un usage AKS général, sans charge GPU. Pour un chiffrage précis en euros, utilisez le calculateur de prix officiel d’Azure cité plus haut : les tarifs varient selon la région et le type d’engagement (paiement à l’usage ou instances réservées).

Usage	Famille de VM recommandée	vCPU / RAM	Compatible Trusted Launch
Cluster de test ou de développement	Standard_D2s_v5	2 vCPU / 8 Go	Oui
API de production, charge légère à moyenne	Standard_D4s_v5	4 vCPU / 16 Go	Oui
Charge mémoire intensive (cache, base en mémoire)	Standard_E4s_v5	4 vCPU / 32 Go	Oui
Inférence IA avec GPU	Standard_NC4as_T4_v3	4 vCPU / 28 Go + GPU	Oui (Azure Linux)

Pour ce tutoriel, Standard_D4s_v5 offre une marge confortable pour héberger les trois répliques de l’application de démonstration, le contrôleur Gateway API et les agents Defender for Containers sans saturer les nœuds.

Pièges courants à éviter

Oublier d’enregistrer les fonctionnalités preview. NAT Gateway v2, Node Disruption Policy et Automatic Zone Placement exigent un enregistrement préalable via az feature register. Sans ça, les commandes des étapes 4, 7 et 9 échouent avec une erreur peu claire.
Choisir un SKU de VM non compatible Gen2. Trusted Launch et Secure Boot exigent une génération 2. Certaines anciennes familles de VM (comme la série A) ne le supportent pas et bloquent la création du cluster à l’étape 2.
Confondre outboundType et règles NSG. Passer à managedNATGateway ne dispense pas de vérifier vos groupes de sécurité réseau : un NSG trop restrictif sur le sous-réseau peut toujours bloquer le trafic sortant même avec un NAT Gateway correctement configuré.
Négliger le namespace lors du déploiement de la Gateway API. La Gateway, la HTTPRoute et le Service doivent être dans le même namespace pour que le parentRefs fonctionne sans champ namespace explicite, une source d’erreur fréquente à l’étape 6.
Activer Defender for Containers en enforcement sans phase d’audit préalable. Basculer directement en mode blocage sur un cluster déjà en production peut interrompre des déploiements légitimes. Passez d’abord quelques jours en mode audit pour repérer les faux positifs avant d’activer l’étape 11 en blocage strict.
Laisser le nom du cluster ou du groupe de ressources trop générique. Un nom comme aks-demo-cluster convient pour ce tutoriel, mais en production, adoptez une convention incluant l’environnement et la région (par exemple aks-prod-francecentral-01) pour éviter les confusions lors d’audits ou de scripts d’automatisation partagés entre plusieurs équipes.

Ces six pièges reviennent le plus souvent dans les retours d’expérience d’équipes qui migrent vers les fonctionnalités 2026 d’AKS. Aucun n’est bloquant en soi, mais chacun coûte du temps de diagnostic évitable si on l’anticipe dès la phase de conception du cluster.

Dépannage : les problèmes les plus fréquents

Voici les incidents les plus courants rencontrés en suivant ce tutoriel, avec la cause probable et la commande de diagnostic à lancer en premier.

Erreurs réseau et provisionnement

Un nœud reste bloqué en NotReady après l’étape 3. Vérifiez les logs du kubelet avec kubectl describe node NOM_NOEUD : la cause la plus fréquente est un sous-réseau saturé en adresses IP disponibles pour le CNI Azure.
Erreur FeatureNotRegistered sur une commande az aks. La fonctionnalité preview n’a pas fini son enregistrement. Attendez et relancez az feature show --namespace Microsoft.ContainerService --name NOM_FEATURE jusqu’à voir l’état Registered.
La Gateway reste sans adresse IP après plusieurs minutes. Vérifiez que l’add-on approuting a bien terminé son installation avec az aks show --query addonProfiles.httpApplicationRouting, et que le gatewayClassName correspond exactement à celui déployé sur votre cluster.
Le NAT Gateway ne réduit pas les erreurs SNAT. Augmentez le nombre d’IP publiques sortantes avec --nat-gateway-managed-outbound-ip-count, chaque IP supplémentaire ajoutant des ports disponibles pour le trafic sortant.
Le montage du volume NFS chiffré échoue. Confirmez que le compte de stockage Azure Files autorise le protocole NFS et que le pare-feu du compte de stockage inclut bien le sous-réseau de vos nœuds AKS.

Erreurs de sécurité et de déploiement

Artifact Streaming n’accélère rien de visible. La fonctionnalité n’apporte un gain net que sur des images de plusieurs gigaoctets. Sur une petite image, le temps de conversion peut même dépasser le gain au démarrage.
Defender for Containers bloque un déploiement légitime. Consultez l’onglet Recommandations du portail Defender for Cloud pour identifier la règle exacte déclenchée, puis ajustez l’exemption de politique plutôt que de désactiver l’enforcement entier.
kubectl renvoie Unable to connect to the server après un redémarrage. Le jeton d’authentification a probablement expiré. Relancez az aks get-credentials pour régénérer le kubeconfig.
Le node pool refuse d’activer Trusted Launch après coup. Certaines tailles de VM plus anciennes ne supportent pas la génération 2. Vérifiez la compatibilité du SKU avec az vm list-skus --size Standard_D4s_v5 --query "[].capabilities" avant de relancer la commande.

Astuces avancées pour aller plus loin

Une fois ce socle en place, plusieurs pistes permettent d’aller plus loin. Le réseau applicatif d’AKS intègre désormais des capacités inspirées de Cilium, avec support de WireGuard pour chiffrer le trafic entre nœuds et du mTLS pod-à-pod directement au niveau réseau, sans nécessiter l’ajout de sidecars dans chaque pod. Pour un cluster multi-équipes, cette approche évite la complexité opérationnelle d’un service mesh complet tout en couvrant l’essentiel des besoins de chiffrement interne.

La Prepared Image Specification, encore en preview, permet de définir des images de nœuds préconfigurées incluant vos agents de sécurité et personnalisations habituelles. L’intérêt principal est la cohérence : chaque nœud démarre déjà avec la configuration attendue, plutôt que de dépendre d’un DaemonSet post-démarrage qui laisse une fenêtre de vulnérabilité entre le boot du nœud et l’application de la configuration.

Sur le plan organisationnel, pensez aussi à documenter qui a le droit d’exécuter les commandes az aks update touchant au réseau ou à la sécurité. Un rôle Azure RBAC personnalisé, limité aux actions nécessaires plutôt qu’au rôle Contributeur complet, réduit le risque qu’une mauvaise manipulation touche l’ensemble du cluster plutôt qu’un seul namespace. C’est un complément naturel au contrôle d’admission mis en place à l’étape 11, qui protège le plan applicatif mais pas le plan de contrôle Azure lui-même.

Si vous exploitez déjà un cluster Minikube en local pour du développement (voir notre tutoriel Minikube), la transition vers AKS se limite essentiellement à la couche réseau et aux ressources gérées par Azure : les manifests Kubernetes eux-mêmes restent identiques. Pour la partie durcissement des nœuds au niveau containerd, notre article sur le durcissement de containerd complète bien les réglages Trusted Launch abordés à l’étape 5.

Pour le pipeline de déploiement continu vers ce cluster, un enchaînement classique associe Azure DevOps (voir notre tutoriel pipeline CI/CD) avec Artifact Streaming activé sur le registre cible, ce qui réduit d’autant le temps entre la fin du build et la disponibilité réelle du nouveau pod. Si votre organisation applique déjà une politique zero trust côté réseau, le principe rejoint celui détaillé dans notre article sur Cilium et les Network Policies, à la différence près qu’AKS embarque désormais nativement une partie de ces capacités.

Questions fréquentes

Faut-il activer NAT Gateway v2 dès la création du cluster ?
Non, ce tutoriel le fait après coup à l’étape 7 pour montrer la bascule sur un cluster existant. En pratique, si vous savez dès le départ que le trafic sortant sera important, vous pouvez passer --outbound-type managedNATGateway directement dans la commande az aks create de l’étape 2.

La Gateway API remplace-t-elle complètement Ingress NGINX sur AKS ?
Microsoft la recommande désormais comme méthode par défaut depuis son passage en disponibilité générale en juillet 2026, mais Ingress NGINX reste supporté pour les clusters existants qui n’ont pas encore migré leurs manifests.

Le mode enforcement de Defender for Containers a-t-il un coût supplémentaire ?
Defender for Containers est un plan payant d’Azure Defender, facturé séparément du cluster AKS lui-même. Consultez la page de tarification officielle pour un chiffrage actualisé selon votre nombre de nœuds.

Peut-on utiliser Trusted Launch sur un cluster déjà en production ?
Oui, Trusted Launch peut désormais être activé ou désactivé sur des pools de nœuds Linux existants sans recréer le pool entièrement, ce qui simplifie la migration par rapport aux versions précédentes qui imposaient une recréation complète.

Quelle est la différence entre Node Disruption Policy et un PodDisruptionBudget ?
Le PodDisruptionBudget protège la disponibilité de vos pods pendant une perturbation, tandis que la Node Disruption Policy contrôle quand AKS a le droit de déclencher cette perturbation au niveau du nœud lui-même. Les deux mécanismes sont complémentaires plutôt que redondants.

Artifact Streaming fonctionne-t-il avec un registre autre qu’Azure Container Registry ?
Non, cette fonctionnalité est spécifique à Azure Container Registry. Un registre externe ne bénéficiera pas de ce mécanisme de chargement à la demande.

Automatic Zone Placement fonctionne-t-il dans toutes les régions Azure ?
La fonctionnalité dépend de la disponibilité de plusieurs zones dans la région choisie. Certaines régions n’exposent qu’une seule zone de disponibilité, auquel cas le placement automatique n’a pas d’effet pratique.

Faut-il redémarrer le cluster après avoir activé le chiffrement en transit sur Azure Files ?
Non, la StorageClass s’applique aux nouveaux PersistentVolumeClaims. Les volumes déjà montés avant l’activation doivent être recréés pour bénéficier du chiffrement en transit.

Ce tutoriel fonctionne-t-il aussi pour migrer un cluster AKS existant plutôt qu’en créer un nouveau ?
Oui pour la majorité des étapes. Trusted Launch, la Gateway API, le NAT Gateway v2 et le chiffrement Azure Files peuvent tous être activés après coup sur un cluster déjà en production, sans recréation complète. Seule l’Automatic Zone Placement nécessite la création d’un nouveau node pool, puisqu’elle détermine le placement dès la création.

AKS Azure : Cluster Kubernetes en 14 Étapes, 110 Min [2026]