9 — Containers

Azure propose 4 services principaux pour héberger des containers + 1 registry pour les stocker. Choisir selon : besoin de control K8s, scale-to-zero, durée du workload.

A. Décider quel service utiliser#

Pour AZ-104 : retenir quand utiliser quoi (questions scénario fréquentes). Pas besoin de connaître K8s en profondeur.

B. Azure Container Registry (ACR)#

Registry Docker privé managé. Stocke et distribue les images de containers (et autres OCI artifacts : Helm charts, etc.).

SKUs#

Le SKU est modifiable à chaud (sauf que pour passer Premium → Standard/Basic il faut d'abord supprimer geo-replications + private endpoints).

Auth#

• Admin user : compte unique avec username/password (déconseillé, à désactiver).
• Service Principal : pour CI/CD pipelines.
• Managed Identity : recommandé. AKS / VM / App Service avec MI accède à l'ACR via RBAC.
• Entra ID + RBAC : AcrPull, AcrPush, AcrDelete, AcrImageSigner (Premium).

ACR Tasks#

Build des images dans Azure (pas besoin de Docker local). 3 modes :

• Quick Task : build one-shot (az acr build).
• Triggered Task : build auto sur git push, base image update, ou schedule.
• Multi-step Task : pipeline (build → test → push) en YAML.

Avantage Tasks : build cross-architecture (ARM64), patching base image auto.

Features Premium importantes#

• Geo-replication : 1 registry, N regions, accès local depuis chaque region (pull rapide).
• Private Endpoint : registry uniquement accessible depuis VNet.
• Content Trust : signature des images (Docker Notary).
• Customer-Managed Keys (CMK) pour encryption.
• Repository-scoped tokens : auth granulaire par repo (au lieu d'auth tenant entier).

C. Azure Container Instances (ACI)#

Le plus simple : un container (ou un container group) qui tourne, billing à la seconde.

À retenir#

• Container group = unité de déploiement (1+ containers partageant le même hostname, IPs, storage). Équivalent d'un pod K8s.
• OS : Linux ou Windows. ⚠️ Tous les containers d'un même group = MÊME OS (pas de mix Linux + Windows).
• Networking :
  • Public IP par défaut (avec FQDN optionnel <label>.<region>.azurecontainer.io) → DNS name label = public networking obligatoire (privé = pas de FQDN public).
  • Possibilité de déployer dans un VNet (subnet dédié, IP privée)
• Storage :
  • Volumes : Azure File Shares (SMB), Empty Dir, Git repo, Secrets
• Restart policy : Always / OnFailure / Never
• Hyper-V isolation par défaut (chaque pod dans une VM légère).

Use cases AZ-104#

• Build agents (CI/CD)
• Batch jobs ponctuels
• Backend léger d'une queue (KEDA-style)
• POC/démos

Limites#

• ❌ Pas de scaling auto
• ❌ Pas de load balancing natif
• ❌ Pas de stateful (stockage persistant via Files mount uniquement)
• ❌ Pas de monitoring avancé natif

D. Azure Container Apps (ACA)#

Plateforme serverless pour microservices containerisés. Tourne sur AKS managé par MS — tu n'as pas accès à K8s directement.

Concepts clés#

• Environment : équivalent du cluster, contient les apps (1 environment = 1 VNet / Log Analytics).
• Container App : 1 application = N revisions.
• Revision : version immutable d'une app (snapshot du container + config).
• Scaling rules (KEDA) : scale-to-zero, HTTP, CPU/RAM, custom (queue length, etc.).
• Ingress : interne ou externe (HTTPS auto, custom domains, mTLS).
• Dapr intégré nativement (pour microservices distribués).

Plans / Environment types#

🚨 Piège exam : si la question demande "smallest subnet pour ACA workload profiles" → /27. Si /27 n'est pas dans les choix proposés (cas tutorialdojo), prendre la taille immédiatement plus grande disponible (ex /26). Pour Consumption only : /23 minimum (donc /22, /21… acceptables).

Choix de l'environment type est figé à la création (irréversible). Pour migrer Consumption → Workload profiles : recréer.

Connexion à un VNet existant :

• Subnet dédié à l'environment (pas partagé avec autre chose).
• Subnet vide au moment de la création de l'environment.
• 1 environment = 1 VNet (et 1 Log Analytics workspace).

Comparé à AKS#

• ✅ Plus simple (pas de gestion nodes, pas de YAML K8s)
• ✅ Scale-to-zero natif
• ❌ Moins de contrôle (pas d'accès K8s API natif)
• ❌ Pas pour workloads très spécifiques (DaemonSets, CRDs custom, etc.)

E. Azure Kubernetes Service (AKS)#

K8s managé : MS gère le control plane (gratuit ou payant selon SKU), tu gères les worker nodes.

Architecture#

• Cluster : 1 control plane + N node pools.
• Node pool : groupe de VMs (System pool obligatoire pour les services system + User pools pour tes apps).
• Pod : unité de déploiement K8s (1+ containers).
• kubectl : CLI K8s pour interagir avec le cluster.

SKUs (Tier)#

Auth & Networking#

• Auth : Entra ID (recommandé) ou local accounts. RBAC K8s + Azure RBAC.
• Networking models :
  • Kubenet : NAT, IPs pods invisibles depuis VNet — 🚨 retiré le 31 mars 2028 → migrer vers Azure CNI Overlay (migration one-way irréversible)
  • Azure CNI : pods avec IP du VNet, plus performant, IP plus consommé
  • Azure CNI Overlay : compromis (pods en /24 superposé, IPs économisées) — recommandé MS pour la plupart des scénarios
• Network policies : Calico ou Azure Network Policy.
• Ingress : Application Gateway Ingress Controller (AGIC), ou Nginx, ou Application Routing.

Cluster ops#

• Upgrade K8s : control plane d'abord, puis nodes (rolling).
• Auto-upgrade channel : none, patch, stable, rapid, node-image.
• Cluster Autoscaler : scale automatique du nb de nodes.
• HPA (Horizontal Pod Autoscaler) : scale du nb de pods. ⚠️ Nécessite Kubernetes Metrics Server (récupère CPU/RAM des pods pour HPA) — installé par défaut sur AKS.
• VPA (Vertical Pod Autoscaler) : ajuste CPU/RAM des pods (supporté Linux et Windows sur AKS).

Storage K8s#

• PV / PVC (Persistent Volume / Claim).
• Storage classes : Azure Disk, Azure Files, Azure NetApp Files, Blob (CSI drivers).

Pour AZ-104#

Niveau d'attente AZ-104 = basique :

• Comprendre la hiérarchie (cluster, node pool, pod, deployment, service).
• Savoir créer un cluster + connecter kubectl (az aks get-credentials).
• Notion de node pool system vs user.
• Notion d'auto-scale.
• Pas de questions K8s pures (CRDs, operators, etc.).

🏢 Scénarios d'entreprise (CAF/WAF)#

Scenario 1 : Plateforme fintech microservices régulée (néobanque, paiement)#

Contexte business : Une néobanque fait tourner ~40 microservices (paiements, KYC, comptabilité) en 24/7, avec une latence exigeante et des règles strictes (PCI-DSS, DORA). Équipe SRE expérimentée. Choix architectural : AKS Standard tier (SLA 99.95% sur l'API K8s) car l'équipe maîtrise Kubernetes et a besoin de contrôle fin. Images dans un ACR Premium géo-répliqué. Mise à l'échelle par HPA (pods) + Cluster Autoscaler (nodes). Architecture / pattern :

• ACR Premium répliqué sur 2 régions EU → chaque cluster télécharge ses images en local (rapide + résilient).
• --attach-acr : les nodes s'authentifient à l'ACR via Managed Identity, aucun secret dans le pipeline.
• 1 cluster par région, Front Door en amont.
• Node pools séparés : system (services K8s) + user-default (apps) + user-memory (moteur ledger) + user-spot (batch nocturne).
• HPA partout avec min 3 (anti-fragile), Cluster Autoscaler 3-50 nodes.
• Network policy Calico + Azure Policy for AKS pour interdire les containers privilégiés et exiger des images signées. Trade-offs assumés :
• Gain : contrôle total et conformité réglementaire.
• Perte : AKS est complexe à opérer → justifié seulement avec une équipe SRE solide. Pièges à éviter :
• AKS Free tier en prod : pas de SLA financier sur l'API → un outage et l'audit DORA tombe.
• Mélanger system et user dans un seul node pool : un workload buggy peut affamer les services K8s. Séparer.
• Pas de ResourceQuota + LimitRange par namespace → un Deployment sans limites peut OOMKiller les voisins. Jamais un namespace sans quota.
• ACR Basic en multi-région : pas de géo-réplication → latence et point de panne unique.
• Question exam : "scaler les pods" = HPA (ni Cluster Autoscaler, ni VPA, ni Dashboard).

📐 Réf. — AKS landing zone accelerator (WAF) : System/User node pools séparés, Azure CNI Overlay, Entra ID + RBAC, ACR Premium geo-répliqué + --attach-acr via MI, Azure Policy for AKS sont les pratiques de l'architecture de référence AKS. Lien

Scenario 2 : Plateforme événementielle / e-commerce serverless (retailer DTC)#

Contexte business : Une marque grand public a un trafic très saisonnier (Noël, soldes) et presque rien le reste de l'année. Son backend est fait de microservices stateless. Objectif : payer 0€ la nuit. Choix architectural : Azure Container Apps (serverless) car il sait descendre à zéro instance (KEDA) quand il n'y a pas de trafic, sans gérer de cluster. On prend le type Workload profiles pour pouvoir router la sortie via un firewall. Architecture / pattern :

• 1 Container Apps Environment en Workload profiles (nécessaire pour avoir UDR + NAT Gateway, car un partenaire paiement whiteliste des IPs fixes).
• Apps "front" : scale sur le nombre de requêtes (min 0 la nuit, max 30).
• Apps "worker" : scale sur la longueur d'une file Service Bus (KEDA), min 0, démarre dès le 1er message.
• Déploiement canary via revisions + traffic split 90/10.
• ACR Standard (1 région), accès via Managed Identity. Ingress HTTPS + cert managé gratuit. Trade-offs assumés :
• Gain : on ne paie quasiment rien hors saison, et zéro cluster à gérer.
• Perte : le scale-to-zero crée un cold start, gênant sur les parcours sensibles. Pièges à éviter :
• Créer en Consumption puis vouloir router via firewall (UDR) → le type d'environnement est figé à la création, il faut tout recréer en Workload profiles.
• Subnet trop petit : /27 min en Workload profiles, /23 min en Consumption. Prévoir large.
• Scale-to-zero sur le checkout = cold start de quelques secondes = panier perdu. Sur ces apps "argent" : min 1 ou 2.
• Pas d'accès à l'API K8s : si on a besoin d'un CRD ou DaemonSet précis → migrer AKS (rare ici).

📐 Réf. — Azure Container Apps (serverless microservices) + WAF Cost : KEDA scale-to-zero, revisions + traffic split canary, Dapr et Workload profiles (UDP/NAT GW egress) sont les patterns recommandés pour des microservices serverless à coût optimisé. Lien

Scenario 3 : CI/CD build agents + batch jobs ponctuels (ESN, intégrateur)#

Contexte business : Une ESN de 50 devs lance des builds, tests et scripts de migration ponctuels. Pas besoin d'orchestrateur permanent : juste "lance un container, attends qu'il finisse, paie ce qui est consommé". Choix architectural : Azure Container Instances (ACI) car c'est facturé à la seconde et le container s'arrête quand le job finit (restart policy Never). Images dans un ACR, état partagé via Azure Files. Architecture / pattern :

• Image "ci-runner" (terraform + az CLI + node + .NET) construite via ACR Tasks (az acr build) → pas de Docker sur les laptops.
• GitHub Actions lance az container create (secrets injectés depuis Key Vault) → le job tourne, sort, et la facturation s'arrête.
• Restart policy Never : un crash doit être visible, pas masqué par un retry.
• Volume Azure Files monté pour passer des artefacts entre jobs d'un même pipeline.
• Container groups quand un job a besoin d'un sidecar (ex: app + nginx pour un test e2e). Trade-offs assumés :
• Gain : coût à l'usage, démarrage simple, zéro infra permanente.
• Perte : pas de load balancer ni d'autoscale → inadapté à une app qui tourne en continu. Pièges à éviter :
• Mélanger Linux + Windows dans le même container group → interdit, échec. Faire 2 groups.
• Exposer un DNS public sans restriction → endpoint scanné en quelques minutes. Subnet privé ou pas d'exposition.
• Utiliser ACI pour une app web 24/7 → pas de LB, pas de scale, et plus cher qu'App Service Basic. Pour du long-running : Container Apps ou App Service.
• ACR Basic = 10 GB → saturé vite avec beaucoup d'images/tags. Passer Standard (100 GB).

📐 Réf. — Azure Container Instances (use cases) : ACI pour les jobs ponctuels/batch/build-agents (billing à la seconde, restart policy Never, container groups avec sidecar) est le bon choix vs un orchestrateur permanent. Lien

DEMO — chemins portail#

ACR — créer + push une image#

Portail :

1. Container registries > Create → SKU Basic/Standard/Premium, region, name (DNS unique : <name>.azurecr.io)
2. Optionnel : Networking (Public/Selected/Private) + Encryption (CMK)

CLI :

# Login
az acr login --name myacr

# Tag + push une image locale
docker tag myapp:v1 myacr.azurecr.io/myapp:v1
docker push myacr.azurecr.io/myapp:v1

# Lister les repos / tags
az acr repository list --name myacr -o table
az acr repository show-tags --name myacr --repository myapp -o table

ACR Tasks — build dans Azure#

# Quick build (sans Docker local)
az acr build --registry myacr --image myapp:v1 .

# Triggered task sur push GitHub
az acr task create --registry myacr --name buildmyapp \
  --image myapp:{{.Run.ID}} --context https://github.com/user/repo \
  --branch main --git-access-token <PAT> --file Dockerfile

ACI — déployer un container#

Portail :

1. Container instances > Create → image (Quickstart, ACR, Docker Hub)
2. Onglet Networking : Public IP (avec DNS label) ou Private (VNet/subnet)
3. Onglet Advanced : restart policy, env vars (avec secrets), volumes (Azure Files)

CLI :

az container create -g myrg --name mycontainer \
  --image myacr.azurecr.io/myapp:v1 \
  --cpu 1 --memory 1.5 \
  --registry-username <user> --registry-password <pwd> \
  --dns-name-label mycontainer-prod \
  --ports 80

Container Apps — créer + déployer#

Portail :

1. Container Apps Environment > Create (region, Log Analytics workspace, VNet optionnel)
2. Container App > Create dans cet environment :
   • Image source : ACR / Docker Hub / quickstart
   • Ingress : External (HTTPS public) ou Internal
   • Scaling : min replicas, max replicas, rules (HTTP, CPU, custom)

CLI :

# Créer environment
az containerapp env create -g myrg --name myenv -l eastus

# Créer container app avec scale rules
az containerapp create -g myrg --name myapp \
  --environment myenv \
  --image myacr.azurecr.io/myapp:v1 \
  --target-port 80 --ingress external \
  --min-replicas 0 --max-replicas 10

AKS — créer un cluster basique#

Portail :

1. Kubernetes services > Create > Kubernetes cluster
2. Choisir : tier (Free/Standard), version K8s, node pool system (taille + count)
3. Onglet Node pools : ajouter user pool si besoin
4. Onglet Auth : Entra ID + RBAC (recommandé)
5. Onglet Networking : Azure CNI Overlay, NSG, Application Routing

CLI :

# Créer cluster
az aks create -g myrg -n myaks \
  --node-count 2 --enable-managed-identity \
  --enable-cluster-autoscaler --min-count 1 --max-count 5 \
  --network-plugin azure --network-plugin-mode overlay \
  --enable-aad

# Récupérer kubeconfig pour kubectl
az aks get-credentials -g myrg -n myaks

# Tester
kubectl get nodes
kubectl get pods -A

AKS — attacher un ACR#

# Pour que les nodes AKS puissent pull depuis l'ACR sans creds
az aks update -g myrg -n myaks --attach-acr myacr

Containers — administering hosting (à savoir)#

• Logs :
  • ACI : az container logs ou Log Analytics workspace
  • ACA : az containerapp logs show ou Logs blade (KQL)
  • AKS : kubectl logs <pod> ou Container Insights (Log Analytics)
• Metrics : Azure Monitor (CPU/RAM/network) pour tous
• Scaling :
  • ACI : ❌ pas de scale natif
  • ACA : KEDA rules (HTTP, CPU, queue, custom)
  • AKS : HPA (pods) + Cluster Autoscaler (nodes)