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)