Azure Kubernetes Service

GUIDE FAISANT AUTORITÉ — CONFORMITÉ OBLIGATOIRE

Cette compétence produit une configuration de cluster AKS recommandée basée sur les exigences de l'utilisateur, en distinguant les décisions Day-0 (mise en réseau, serveur API — difficiles à modifier ultérieurement) des fonctionnalités Day-1 (activables après création). Consultez la référence CLI pour les commandes.

Référence rapide

Quand utiliser cette compétence

Activez cette compétence quand l'utilisateur souhaite :

• Créer un nouveau cluster AKS
• Planifier la configuration d'un cluster AKS pour des charges de travail de production
• Concevoir la mise en réseau AKS (accès au serveur API, modèle IP de pod, sortie)
• Configurer la gestion des identités et secrets AKS
• Configurer la gouvernance AKS (Azure Policy, Deployment Safeguards)
• Activer l'observabilité AKS (Container Insights, Managed Prometheus, Grafana)
• Définir la stratégie de mise à niveau et de correctifs AKS
• Comprendre les différences entre AKS Automatic et Standard SKU
• Obtenir une liste de contrôle Day-0 pour la configuration initiale d'un cluster AKS

Règles

1. Commencez par les exigences de l'utilisateur concernant le provisionnement du calcul, la mise en réseau, la sécurité et autres paramètres.
2. Utilisez le serveur MCP azure et sélectionnez d'abord mcp_azure_mcp_aks pour découvrir les outils MCP spécifiques à AKS exposés par le client. Choisissez le plus petit outil AKS découvert qui correspond à la tâche, et ne basculez sur Azure CLI (az aks) que si la fonctionnalité requise n'est pas exposée par la surface MCP AKS.
3. Déterminez si AKS Automatic ou Standard SKU est plus approprié selon le besoin de l'utilisateur en matière de contrôle par rapport à la commodité. Préférez AKS Automatic par défaut, sauf si des personnalisations spécifiques sont requises.
4. Documentez les décisions et la justification des choix de configuration du cluster, en particulier pour les décisions Day-0 difficiles à modifier ultérieurement (mise en réseau, accès au serveur API).

Entrées requises (Ne demandez que ce qui est nécessaire)

Si l'utilisateur est incertain, utilisez les valeurs par défaut sûres.

• Type d'environnement AKS : dev/test ou production
• Région(s), zones de disponibilité, tailles de VM de nœud préférées
• Échelle attendue (nombre de nœuds/clusters, taille des charges de travail)
• Exigences de mise en réseau (accès au serveur API, modèle IP de pod, contrôle de l'entrée/sortie)
• Exigences de sécurité et d'identité, y compris le registre d'images
• Préférences de mise à niveau et d'observabilité
• Contraintes de coûts

Flux de travail

1. Type de cluster

• AKS Automatic (par défaut) : Idéal pour la plupart des charges de travail de production, offre une expérience sélectionnée avec les meilleures pratiques préconfigurées pour la sécurité, la fiabilité et les performances. À utiliser sauf si vous avez des besoins de personnalisation spécifiques pour la mise en réseau, l'autoscaling ou les configurations de pool de nœuds non supportées par Node Auto-Provisioning (NAP).
• AKS Standard : À utiliser si vous avez besoin d'un contrôle total sur la configuration de l'environnement, ce qui nécessite des frais généraux supplémentaires pour la configuration et la gestion.

2. Mise en réseau (IP de pod, Sortie, Entrée, Plan de données)

Modèle IP de pod (Décision Day-0 clé) :

• Azure CNI Overlay (recommandé) : les adresses IP de pod proviennent d'une plage d'overlay privée, non routables via VNet, se met à l'échelle dans les grands environnements et convient bien à la plupart des charges de travail
• Azure CNI (routables par VNet) : les adresses IP de pod proviennent directement du VNet (sous-réseau de pod ou sous-réseau de nœud), à utiliser quand les pods doivent être directement adressables à partir du VNet ou sur site
  • Documentation : https://learn.microsoft.com/azure/aks/azure-cni-overlay

Plan de données et stratégie réseau :

• Azure CNI powered by Cilium (recommandé) : basé sur eBPF pour le traitement des paquets haute performance, les stratégies réseau et l'observabilité

Sortie :

• Passerelle Egress statique pour des adresses IP sortantes stables et prévisibles
• Pour une sortie restreinte : UDR + Azure Firewall ou NVA

Entrée :

• Module complémentaire App Routing avec Gateway API — recommandé par défaut pour les charges de travail HTTP/HTTPS
• Maille de service Istio avec Gateway API - pour la gestion avancée du trafic, mTLS, les versions canary
• Application Gateway for Containers — pour l'équilibrage de charge L7 avec intégration WAF

DNS :

• Activez LocalDNS sur tous les pools de nœuds pour une résolution DNS fiable et performante

3. Sécurité

• Utilisez Microsoft Entra ID partout (plan de contrôle, Workload Identity pour les pods, accès aux nœuds). Évitez les credentials statiques.
• Azure Key Vault via Secrets Store CSI Driver pour les secrets
• Activez Azure Policy + Deployment Safeguards
• Activez Encryption at rest pour etcd/serveur API ; in-transit pour la communication nœud-à-nœud
• Autorisez uniquement les images signées approuvées par stratégie (Azure Policy + Ratify), préférez Azure Container Registry
• Isolation : Utilisez les espaces de noms, les stratégies réseau, la journalisation scoped

4. Observabilité

• Utilisez Managed Prometheus et Container Insights avec Grafana pour l'observabilité AKS (journaux + métriques).
• Activez les paramètres de diagnostic pour collecter les journaux du plan de contrôle et les journaux d'audit dans un espace de travail Log Analytics pour la surveillance de la sécurité et le dépannage.
• Pour les autres outils de surveillance et de dépannage, utilisez des fonctionnalités comme l'Agentic CLI pour AKS, Application Insights, Resource Health Center, les détecteurs AppLens et Azure Advisors.

5. Mises à niveau et correctifs

• Configurez les fenêtres de maintenance pour un timing de mise à niveau contrôlé
• Activez les mises à niveau automatiques pour le plan de contrôle et le système d'exploitation des nœuds pour rester à jour avec les correctifs de sécurité et les versions Kubernetes
• Envisagez les versions LTS pour la stabilité en entreprise (support de 2 ans) en mettant à niveau votre environnement AKS vers le niveau Premium
• Mises à niveau en flotte : Utilisez AKS Fleet Manager pour un déploiement échelonné entre les environnements de test et de production

6. Performance

• Utilisez les disques OS éphémères (--node-osdisk-type Ephemeral) pour un démarrage des nœuds plus rapide
• Sélectionnez Azure Linux comme système d'exploitation des nœuds (empreinte plus petite, démarrage plus rapide)
• Activez KEDA pour l'autoscaling basé sur les événements au-delà de HPA

7. Pools de nœuds et calcul

• Pool de nœuds système dédié : Au moins 2 nœuds, avec tainte pour les charges de travail système uniquement (CriticalAddonsOnly)
• Activez Node Auto Provisioning (NAP) sur tous les pools pour les économies de coûts et la mise à l'échelle réactive
• Utilisez les SKU de dernière génération (v5/v6) pour les optimisations au niveau de l'hôte
• Évitez les VM de série B — les SKU burst causent des problèmes de performance/fiabilité
• Utilisez des SKU avec au moins 4 vCPU pour les charges de travail de production
• Définissez les contraintes de propagation de topologie pour distribuer les pods entre les hôtes/zones selon le SLO

8. Fiabilité

• Déployez sur 3 zones de disponibilité (--zones 1 2 3)
• Utilisez le niveau Standard pour un plan de contrôle redondant dans les zones + SLA de 99,95 % pour la disponibilité du serveur API
• Activez Microsoft Defender for Containers pour la protection au runtime
• Configurez les PodDisruptionBudgets pour toutes les charges de travail de production
• Utilisez les contraintes de propagation de topologie pour assurer la distribution des pods dans les domaines de défaillance

9. Contrôles de coûts

• Utilisez les pools de nœuds Spot pour les charges de travail batch/interruptibles (jusqu'à 90 % d'économies)
• Arrêter/Démarrer les clusters dev/test : az aks stop/start
• Envisagez les instances réservées ou les plans d'économies pour les charges de travail en état stable

Scénarios approfondis — chargez uniquement le fichier de référence pertinent :

Désambiguïsation : Si un message correspond à plusieurs lignes (par ex., « nœuds moins chers » pourrait suggérer à la fois Spot et l'autoscaler), préférez le match le plus spécifique. En cas d'ambiguïté, demandez à l'utilisateur de clarifier son intention avant de charger un fichier de référence.

Garde-fous / Sécurité

• Ne demandez ni ne produisez de secrets (tokens, clés).
• Ne demandez pas à l'utilisateur de coller les ID d'abonnement. Découvrez l'abonnement et la portée des ressources via les outils MCP (par ex., lister les abonnements, lister les groupes de ressources) ou az account show / az account list afin que l'agent puisse résoudre le contexte sans exposer les identifiants.
• Si les exigences sont ambiguës pour les décisions critiques Day-0, posez des questions de clarification à l'utilisateur. Pour les fonctionnalités activées Day-1, proposez 2–3 options sûres avec leurs compromis et choisissez une valeur par défaut conservatrice.
• Ne promettez pas un temps d'arrêt zéro ; conseillez les protections de charge de travail (PDB, sondes, répliques) et les mises à niveau échelonnées ainsi que les meilleures pratiques pour la fiabilité et la performance.

Outils MCP

Gestion des erreurs