Microsoft AZ-400: Conteneurisation et Kubernetes — Guide d'étude
Fait partie du Microsoft DevOps Engineer Expert AZ-400 — Guide d’étude. Entraînez-vous avec des réponses vérifiées dans le centre d’examens Microsoft, ou passez des tests chronométrés sur ExamRoll.io.
Vue d’ensemble
La conteneurisation et Kubernetes sont les fondements du DevOps moderne sur Azure en combinant des builds reproductibles, une distribution sécurisée et une orchestration d’exécution déclarative et auto-réparatrice. Leur maîtrise exige de comprendre comment les images sont assemblées et optimisées, comment les registres répliquent et certifient le contenu, comment AKS est conçu et mis à niveau sans interruption, comment la livraison progressive est mise en œuvre, et comment sécuriser les charges de travail de bout en bout. Au-delà de Kubernetes brut, vous utiliserez Helm pour le packaging, GitOps pour la réconciliation, et — dans l’espace serverless — Azure Container Apps avec Dapr et KEDA pour simplifier les patterns de microservices et le scaling événementiel. Les sections suivantes résument les décisions de plateforme et les pratiques opérationnelles nécessaires pour mettre en œuvre des pipelines robustes et conformes, ainsi que des clusters de production résilients.
Fondamentaux du Build et du Registre : Docker et ACR
Une image de conteneur performante commence par un Dockerfile déterministe et un contexte de build rigoureux. Les builds multi-étapes (multi-stage) vous permettent de séparer les étapes de compilation riches en outillage des images d’exécution légères. Par exemple, compilez un binaire .NET ou Go dans une étape de construction (builder stage), puis copiez uniquement l’artefact compilé dans une image de base minimale ou distroless (par ex., mcr.microsoft.com/dotnet/runtime-deps ou gcr.io/distroless/base), ce qui réduit les surfaces d’attaque et accélère les temps de téléchargement (pull). Chaque instruction
undefined
,
undefined
et
undefined
crée une couche (layer) ; restructurez les Dockerfiles pour maximiser les correspondances dans le cache de couches (layer cache hits) en plaçant les étapes qui changent rarement à la fin et en regroupant les commandes de manière logique tout en préservant la lisibilité. Incluez toujours un fichier .dockerignore pour exclure bin/obj, node_modules, les tests, la documentation et les secrets ; un contexte de build surdimensionné ralentit les téléversements (uploads) et réduit l’efficacité du cache distant. Utilisez des installations de paquets déterministes (versions épinglées, fichiers de verrouillage) et des arguments de build avec précaution ; les fichiers spécifiques à un environnement doivent être fournis via la configuration d’exécution, et non intégrés dans des images immuables.
Azure Container Registry (ACR) est l’épine dorsale du stockage et de la distribution d’images. Tirez parti des ACR Tasks pour déporter les builds sur Azure : des tâches rapides pour les builds à la demande (az acr run), des tâches automatisées déclenchées par des commits Git, des mises à jour d’images de base ou des planifications, et des fichiers YAML de tâches multi-étapes pour les images multi-architectures utilisant Buildx. La géo-réplication (SKU Premium) réplique les artefacts entre les régions, minimisant la latence de téléchargement (pull) et les coûts de sortie (egress) pour les déploiements AKS/ACA multi-régions ; combinez-la avec des points de terminaison privés (private endpoints) et un RBAC à portée de dépôt (repository-scoped) pour appliquer le principe de moindre privilège. Activez la confiance de contenu (content trust) pour signer les images et vérifier leur provenance : Docker Content Trust/Notary et les écosystèmes de signature OCI en évolution (par ex., cosign) peuvent être appliqués à l’admission via des contraintes OPA Gatekeeper qui exigent des signatures pour les espaces de noms (namespaces) protégés. Intégrez l’analyse de vulnérabilités : Microsoft Defender for Cloud analyse les images lors du push et au repos, remonte les CVE avec des recommandations de correction, et peut bloquer les déploiements via Azure Policy et des vérifications de CI ; incluez une automatisation du rafraîchissement des images de base pour réduire les couches contenant des vulnérabilités connues.
Plateforme AKS et livraison des charges de travail
Créez des clusters AKS avec des paramètres sécurisés par défaut : identité managée, intégration Azure AD pour le RBAC, Azure CNI pour l’intégration VNET, politique réseau (Azure ou Calico), fournisseur Azure Key Vault (Secrets Store CSI) pour la consommation de secrets, et clusters privés avec des plages d’adresses IP autorisées. Choisissez des pools de nœuds adaptés à la charge de travail : pools système pour les composants critiques du plan de contrôle ; pools utilisateur pour les applications ; pools GPU pour le ML ; pools spot pour les tâches sans état afin de réduire les coûts ; pools de nœuds Windows pour les conteneurs Windows. Utilisez les taints/tolerations et les contraintes de répartition topologique (topology spread constraints) pour contrôler l’ordonnancement et la résilience. Mettez à l’échelle automatiquement avec le cluster autoscaler et le Horizontal Pod Autoscaler par déploiement ; envisagez les disques de système d’exploitation éphémères et les zones de disponibilité pour la performance et la résilience.
Planifiez les mises à niveau pour minimiser les interruptions. AKS met d’abord à niveau le plan de contrôle, puis les pools de nœuds. Utilisez max-surge lors des mises à niveau de pools de nœuds pour ajouter une capacité de surcroît, drainer les nœuds de manière progressive et respecter les PodDisruptionBudgets. Adoptez des canaux de mise à niveau automatique (rapide/stable/correctifs uniquement) pour une cadence prévisible ; séparez les mises à niveau des pools système et utilisateur pour limiter le rayon d’impact. Effectuez régulièrement des mises à jour de l’image des nœuds pour bénéficier des correctifs du noyau/runtime même sans changer de version de Kubernetes, et épinglez des versions CNI/CSI compatibles. Utilisez des pools de nœuds blue-green pour des changements de plateforme sans interruption de service — isolez/drainez (cordon/drain) le pool green vers le blue et basculez via nodeSelector/affinity.
Dans Kubernetes, les Deployments prennent en charge nativement les mises à jour progressives (rolling updates) avec maxUnavailable et maxSurge pour maintenir la capacité pendant le déploiement ; associez-les à des sondes de préparation (readiness), de vivacité (liveness) et de démarrage (startup) pour empêcher le trafic prématuré. La livraison blue-green sur Kubernetes est mise en œuvre en exécutant des Deployments parallèles (blue et green) et en basculant un sélecteur de Service stable ou un objet Endpoint vers la révision cible ; cela permet un retour en arrière quasi instantané en changeant les étiquettes. La livraison canary se fait de préférence en périphérie via un ingress : NGINX Ingress prend en charge le canary pondéré via des annotations ; Application Gateway Ingress Controller (AGIC) peut répartir le trafic entre les backends ; les maillages de services (service meshes) permettent de dévier le trafic avec des politiques granulaires et de la télémétrie. Pour des pipelines robustes, validez avec des tests de fumée (smoke tests) et des tests de disponibilité App Insights avant de promouvoir les pondérations.
Helm empaquette les manifestes Kubernetes dans des charts comprenant Chart.yaml, des modèles et un fichier values.yaml par défaut. Les fichiers de valeurs se superposent de manière déterministe ; utilisez des surcouches values.<env>.yaml et un bloc « global » pour les paramètres partagés entre les sous-charts. Préférez Helm 3 avec un stockage de charts basé sur OCI dans ACR (helm registry login && helm push oci://…), ce qui permet une parité avec les images en termes de RBAC et de géo-réplication. Dans Azure Pipelines, installez Helm à une version épinglée
← Infrastructure en tant que code et gestion de la configuration · Tous les domaines · Gestion des mises en production et stratégies de déploiement →
Entraînez-vous sur ces questions → · Tests chronométrés sur ExamRoll.io →
Pass the whole exam — not just this question
You found this answer. Get every verified question and explanation in one place, and save hours of prep. Free to start.
Réussissez votre examen →