04 · AKS pour le support : lire les objets, suivre l'identité, diagnostiquer

Version : 1.0 · Date : 2026-10-23 · Parcours SUPPORT-IA (support N2/N3 de chatbots sur Azure)

En une phrase : sur AKS, une panne de chatbot se trouve presque toujours en lisant dans l'ordre le chemin d'une requête (Ingress → Service → endpoints → pod), l'état du pod (describe, logs --previous), puis ses dépendances Azure (image dans ACR, jeton Workload ID, secrets Key Vault montés par le Secrets Store CSI Driver).

Ce chapitre prend l'angle support : reconnaître un symptôme, savoir où regarder, prouver la cause, proposer la correction. Les choix d'architecture sont traités dans le parcours AKS : identités et secrets dans AKS/03-identite-securite, observabilité et runbooks dans AKS/05-exploitation-gitops, réseau et Ingress dans AKS/02-reseau. La chaîne de déploiement (Azure DevOps, ACR, Argo CD) est dans 05-gitops-argocd-azure-devops-acr, la Web App for Containers dans 06-web-app-for-containers-privee.

Les noms d'objets, de fonctionnalités et de rôles restent en anglais, comme dans kubectl et le portail.

Ce que tu dois savoir expliquer en entretien#

1. Les objets à savoir lire#

1.1 La carte des objets#

1.2 Deployment, ReplicaSet et rollout#

• Un rollout n'est déclenché que si le template de pod (.spec.template) change (image, variable, label…). Changer replicas ne crée pas de révision. Corollaire support : pousser une nouvelle image sous le même tag ne change rien au template, donc ne déclenche rien.
• Stratégie par défaut RollingUpdate : maxUnavailable 25 % et maxSurge 25 %.
• progressDeadlineSeconds (600 s par défaut) : passé ce délai sans progrès, la condition Progressing devient False avec la raison ProgressDeadlineExceeded. Le controller continue d'essayer, mais l'état est signalé (et Argo CD passe en Degraded).
• revisionHistoryLimit (10 par défaut) : nombre d'anciens ReplicaSets gardés, donc de retours arrière possibles.
• Causes de rollout bloqué listées par Kubernetes : quota insuffisant, readiness en échec, erreur de pull d'image, droits insuffisants, LimitRange, mauvaise configuration applicative.

kubectl rollout status deployment/chat-api -n chatbot          # attend la fin, code retour ≠ 0 si échec
kubectl rollout history deployment/chat-api -n chatbot         # révisions
kubectl rollout undo deployment/chat-api -n chatbot            # revient à la révision précédente
kubectl rollout restart deployment/chat-api -n chatbot         # recrée les pods (annotation restartedAt dans le template)
kubectl get rs -n chatbot -l app=chat-api                      # ancien et nouveau ReplicaSet, replicas de chacun

Piège GitOps : rollout undo ou rollout restart modifient le cluster sans passer par Git. Avec Argo CD et selfHeal, la modification est annulée ; sans selfHeal, l'application passe OutOfSync. Le vrai retour arrière se fait dans Git (chapitre 05). En incident, undo reste un geste d'urgence à signaler et à reporter dans Git.

1.3 Service et endpoints#

Le Service sélectionne des pods par labels ; Kubernetes publie leurs adresses dans des EndpointSlices, et seuls les pods Ready reçoivent le trafic.

kubectl get svc chat-api -n chatbot -o wide                                  # selector et ports
kubectl get endpointslices -n chatbot -l kubernetes.io/service-name=chat-api  # adresses réellement servies
kubectl get pods -n chatbot -l app=chat-api --show-labels                    # les labels collent-ils au selector ?

Endpoints vides : selector qui ne correspond à aucun label (faute de frappe après un refactoring Helm), ou pods existants mais pas Ready (readiness probe). targetPort différent du port d'écoute du conteneur : endpoints présents, mais connexion refusée.

1.4 Ingress, Ingress controller et application routing#

L'Ingress est une règle ; c'est l'Ingress controller qui reçoit le trafic et l'applique. Sur AKS, le controller géré est l'application routing add-on (NGINX managé) : son IngressClass s'appelle webapprouting.kubernetes.azure.com, ses pods tournent dans app-routing-system.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata: { name: chat-api, namespace: chatbot }
spec:
  ingressClassName: webapprouting.kubernetes.azure.com    # sans classe valide, aucun controller ne prend la règle
  rules:
  - host: chat.interne.contoso.com
    http:
      paths:
      - { path: /, pathType: Prefix, backend: { service: { name: chat-api, port: { number: 80 } } } }

À savoir en 2026 : le projet Ingress NGINX est retiré (maintenance arrêtée en mars 2026). Microsoft fournit les correctifs de sécurité critiques de l'application routing add-on NGINX jusqu'en novembre 2026 et oriente vers l'application routing Gateway API implementation (GatewayClass approuting-istio) ou Application Gateway for Containers. Kubernetes a gelé l'API Ingress (toujours prise en charge, plus d'évolution) et recommande Gateway. Bonne question à poser au client : « quel est votre plan de migration ? ».

Diagnostic d'un 502/503/504 vu par l'utilisateur : kubectl get ingress -n chatbot (classe, adresse), endpoints du Service, puis logs du controller (kubectl logs -n app-routing-system deploy/nginx, nom à vérifier avec kubectl get deploy -n app-routing-system). Pour un chatbot, une réponse LLM longue peut aussi dépasser un timeout du proxy : c'est un réglage du controller, pas une panne du pod.

1.5 ConfigMap et Secret#

• Un Secret Kubernetes est encodé en base64, pas chiffré ; ne jamais en committer un en clair dans le dépôt GitOps.
• Référencer une ConfigMap ou un Secret absent (ou une clé absente) bloque le démarrage du conteneur : état Waiting, raison CreateContainerConfigError, message explicite dans les Events. Un optional: true évite le blocage.
• immutable: true empêche toute modification (il faut recréer l'objet).

1.6 Requests, limits, quotas#

1.7 Les trois probes#

Valeurs par défaut (référence API Kubernetes) : periodSeconds 10, timeoutSeconds 1, failureThreshold 3, successThreshold 1 (obligatoirement 1 pour liveness et startup). Mécanismes : httpGet, tcpSocket, exec, grpc.

# Extrait du template de pod d'une API de chat (Python, port 8000)
containers:
- name: chat-api
  image: acrchatprd.azurecr.io/chat-api:4812        # tag unique, jamais latest
  ports: [{ containerPort: 8000 }]
  resources:
    requests: { cpu: 250m, memory: 512Mi }
    limits:   { memory: 1Gi }
  startupProbe:   { httpGet: { path: /healthz, port: 8000 }, periodSeconds: 10, failureThreshold: 30 }   # 300 s pour démarrer
  livenessProbe:  { httpGet: { path: /healthz, port: 8000 } }                                          # processus vivant, sans dépendance
  readinessProbe: { httpGet: { path: /ready,   port: 8000 } }                                          # dépendances critiques prêtes

1.8 HorizontalPodAutoscaler#

• Boucle de contrôle toutes les 15 s ; calcul desiredReplicas = ceil(currentReplicas × valeur actuelle / valeur cible).
• Pour une métrique CPU ou mémoire en utilisation, les conteneurs doivent avoir des requests : sans elles, la métrique n'est pas définie et le HPA n'agit pas (<unknown> dans kubectl get hpa).
• Comportement par défaut : montée immédiate, descente stabilisée sur 300 s.
• Le HPA modifie replicas dans le cluster : si le manifeste Git fixe aussi replicas, Argo CD voit une différence (voir ignoreDifferences au chapitre 05).

kubectl get hpa -n chatbot                    # TARGETS (actuel/cible), MINPODS, MAXPODS, REPLICAS
kubectl describe hpa chat-api -n chatbot      # conditions AbleToScale, ScalingActive, ScalingLimited et événements

2. Cycle de vie d'un pod et états des conteneurs#

2.1 Phase du pod, état du conteneur, colonne STATUS#

2.2 Les états qu'on voit en incident#

Codes de sortie fréquents (convention Unix : 128 + numéro du signal) : 0 fin normale, 1 erreur applicative, 137 = SIGKILL (OOM ou kill après le délai de grâce), 143 = SIGTERM (arrêt demandé).

Kubernetes récent : la durée du backoff CrashLoopBackOff devient configurable par node (maxContainerRestartPeriod, fonction bêta depuis 1.35) ; les valeurs 10 s / 300 s restent celles par défaut. Ne pas s'étonner d'un rythme différent sur un cluster réglé.

3. Boîte à outils kubectl#

3.1 Se connecter (lecture seule par défaut)#

az account show                                                   # bon tenant, bonne subscription (PRD ?)
az aks get-credentials -g rg-chat-prd -n aks-chat-prd             # kubeconfig utilisateur (Cluster User Role)
kubelogin convert-kubeconfig -l azurecli                          # réutilise la session az (exigé dans certains contextes)
kubectl config current-context                                    # vérifier AVANT toute commande
kubectl auth can-i --list -n chatbot                              # ce que mes droits permettent
# Cluster privé sans accès réseau : passer par l'API Azure (audité, droit runcommand requis)
az aks command invoke -g rg-chat-prd -n aks-chat-prd --command "kubectl get pods -n chatbot"

Depuis Kubernetes 1.24, AKS utilise d'office le format exec de kubelogin ; la conversion sert aux méthodes non interactives (pipeline, managed identity) ou pour forcer l'Azure CLI. Le détail des rôles (Cluster User Role, AKS RBAC Reader…) est dans AKS/03-identite-securite.

3.2 Les commandes, dans l'ordre d'un diagnostic#

Règle de prudence : exec, port-forward, debug, rollout restart, delete pod modifient ou touchent la production. En support, annoncer l'action, l'impact et le retour arrière avant de la lancer, et la tracer dans le ticket.

3.3 Lire un kubectl describe pod#

Extrait type (simplifié) d'un pod en échec, annoté :

Name:             chat-api-7d9f8c6b5-x2kqp
Namespace:        chatbot
Node:             aks-user-12345678-vmss000002/10.240.0.35     ← planifié : ce n'est pas un problème de scheduling
Labels:           app=chat-api  pod-template-hash=7d9f8c6b5   ← doit correspondre au selector du Service
Service Account:  sa-chat-api                                  ← celui qui porte l'annotation Workload ID
Containers:
  chat-api:
    Image:          acrchatprd.azurecr.io/chat-api:4812        ← le tag attendu ? (sinon problème de déploiement)
    State:          Waiting
      Reason:       CrashLoopBackOff                           ← symptôme
    Last State:     Terminated
      Reason:       OOMKilled                                  ← cause : limite mémoire
      Exit Code:    137
    Ready:          False
    Restart Count:  6
    Limits:         memory: 1Gi
    Requests:       cpu: 250m, memory: 512Mi
    Environment:
      AZURE_CLIENT_ID:             <client-id>                 ← injecté par le webhook Workload ID
      AZURE_FEDERATED_TOKEN_FILE:  /var/run/secrets/azure/tokens/azure-identity-token
Conditions:
  Type              Status
  PodScheduled      True
  Initialized       True
  ContainersReady   False
  Ready             False                                      ← hors des endpoints du Service
Events:
  Type     Reason   Age                 From     Message
  Warning  BackOff  2m (x25 over 12m)   kubelet  Back-off restarting failed container chat-api

Méthode de lecture, de haut en bas : Node (planifié ou non), Image (la bonne version ?), State / Last State (raison, code de sortie, nombre de redémarrages), Conditions (où le pod s'est arrêté dans son cycle), Events (le message exact, avec x25 over 12m = répété). Un événement n'est conservé que temporairement par l'API : pour un incident passé, aller dans Container Insights (KubeEvents, ContainerLogV2), voir AKS/05-exploitation-gitops.

flowchart TD
    A["Le chatbot ne répond pas"] --> B{"kubectl get pods : tous Running et READY 1/1 ?"}
    B -- Non --> C{"STATUS ?"}
    C -- Pending --> C1["describe pod : FailedScheduling<br/>requests, quota, taints, nodes"]
    C -- "ContainerCreating" --> C2["describe pod : FailedMount<br/>CSI Key Vault, section 5"]
    C -- "ImagePullBackOff" --> C3["Events : 401, 403, not found, timeout<br/>az aks check-acr"]
    C -- "CreateContainerConfigError" --> C4["ConfigMap ou Secret absent"]
    C -- "CrashLoopBackOff" --> C5["logs --previous + Last State<br/>OOMKilled ? exception ? jeton Entra ?"]
    C -- "Running 0/1" --> C6["Readiness probe failed<br/>dépendance, port, chemin"]
    B -- Oui --> D{"Endpoints du Service remplis ?"}
    D -- Non --> D1["selector ≠ labels, targetPort"]
    D -- Oui --> E{"Ingress : classe, adresse, logs du controller ?"}
    E -- "KO" --> E1["ingressClassName, DNS, controller"]
    E -- "OK" --> F["Problème applicatif ou dépendance Azure<br/>logs applicatifs, Application Insights"]

4. Workload Identity de bout en bout#

4.1 Le mécanisme en cinq maillons#

Le détail architecture est dans AKS/03-identite-securite. Pour le support, il faut savoir vérifier chaque maillon :

Quand les maillons 3 et 4 sont en place, le mutating webhook injecte dans chaque conteneur AZURE_CLIENT_ID, AZURE_TENANT_ID, AZURE_FEDERATED_TOKEN_FILE, AZURE_AUTHORITY_HOST et le volume du jeton projeté. Le SDK (DefaultAzureCredential ou WorkloadIdentityCredential) échange ce jeton contre un jeton Entra, avec une portée au format v2 <ressource>/.default.

apiVersion: v1
kind: ServiceAccount
metadata:
  name: sa-chat-api
  namespace: chatbot
  annotations:
    azure.workload.identity/client-id: "00000000-0000-0000-0000-000000000000"   # client ID de la managed identity (exemple)
---
apiVersion: apps/v1
kind: Deployment
metadata: { name: chat-api, namespace: chatbot }
spec:
  selector: { matchLabels: { app: chat-api } }
  template:
    metadata:
      labels:
        app: chat-api
        azure.workload.identity/use: "true"      # dans le TEMPLATE, pas sur le Deployment
    spec:
      serviceAccountName: sa-chat-api
      containers:
      - name: chat-api
        image: acrchatprd.azurecr.io/chat-api:4812

4.2 Vérifier, maillon par maillon (lecture seule)#

# 1. Cluster : OIDC issuer et Workload Identity
az aks show -g rg-chat-prd -n aks-chat-prd \
  --query "{oidc:oidcIssuerProfile.issuerUrl, wi:securityProfile.workloadIdentity.enabled}" -o table
# 2. Identité et federated credential : issuer et subject exacts ?
az identity federated-credential list --identity-name id-chat-api -g rg-chat-prd -o table
# 3. ServiceAccount annoté ?
kubectl get sa sa-chat-api -n chatbot -o jsonpath='{.metadata.annotations}'
# 4. Le pod a-t-il été muté ? (label, variables, volume)
kubectl get pod <pod> -n chatbot -o jsonpath='{.metadata.labels}'
kubectl exec <pod> -n chatbot -- env | grep AZURE_
# 5. Rôles de l'identité sur la ressource cible
az role assignment list --assignee <principalId-ou-clientId> --all -o table

4.3 Erreurs et causes#

Phrase d'entretien : « Je vérifie dans l'ordre : le pod a-t-il été muté (variables AZURE_*) ? l'échange de jeton réussit-il (erreur AADSTS ou pas) ? la ressource accepte-t-elle le jeton (403 RBAC ou 403 réseau) ? Trois questions, trois endroits différents : le cluster, Entra ID, la ressource. »

5. Secrets Store CSI Driver et Azure Key Vault provider#

5.1 Fonctionnement#

L'add-on azure-keyvault-secrets-provider installe deux DaemonSets dans kube-system : le Secrets Store CSI Driver et l'Azure Key Vault provider. Au démarrage du pod, le kubelet demande le montage du volume CSI ; le provider lit la SecretProviderClass (même namespace que le pod), obtient un jeton (Workload ID recommandé) et écrit les secrets en fichiers dans le volume. Tant que le montage échoue, le pod reste en ContainerCreating.

apiVersion: secrets-store.csi.x-k8s.io/v1
kind: SecretProviderClass
metadata: { name: kv-chat-api, namespace: chatbot }
spec:
  provider: azure
  parameters:
    usePodIdentity: "false"
    clientID: "00000000-0000-0000-0000-000000000000"     # identité Workload ID (même client ID que le ServiceAccount)
    keyvaultName: kv-chat-prd
    tenantId: "11111111-1111-1111-1111-111111111111"
    objects: |
      array:
        - |
          objectName: search-admin-key
          objectType: secret
  secretObjects:                                        # optionnel : copie en Secret Kubernetes (pour une variable d'env)
  - secretName: chat-api-secrets
    type: Opaque
    data: [{ objectName: search-admin-key, key: SEARCH_KEY }]

# Dans le template de pod
volumes:
- name: secrets
  csi:
    driver: secrets-store.csi.k8s.io
    readOnly: true
    volumeAttributes: { secretProviderClass: kv-chat-api }
containers:
- name: chat-api
  volumeMounts: [{ name: secrets, mountPath: /mnt/secrets-store, readOnly: true }]

5.2 Ce qu'il faut savoir pour le support#

5.3 Diagnostic#

az aks show -g rg-chat-prd -n aks-chat-prd --query addonProfiles.azureKeyvaultSecretsProvider     # add-on actif ?
kubectl get secretproviderclass -n chatbot                                                          # bon nom, bon namespace
kubectl describe pod <pod> -n chatbot | sed -n '/Events/,$p'                                         # FailedMount : message complet
kubectl get pod -n kube-system -l 'app in (secrets-store-provider-azure, secrets-store-csi-driver)' -o wide   # sur le même node ?
kubectl logs -n kube-system <provider-pod-du-meme-node> --since=1h | grep ^E
kubectl logs -n kube-system <csi-driver-pod-du-meme-node> -c secrets-store --since=1h | grep ^E

6. Pannes fréquentes : symptôme → cause → vérification → correction#

7. Lab : provoquer et diagnostiquer quatre pannes (45 minutes)#

À faire sur un cluster de test (jamais sur l'environnement du client), par exemple celui du lab de AKS/03-identite-securite. Pour chaque étape : appliquer, observer get pods, describe, logs --previous, puis revenir à l'état sain.

kubectl create namespace lab-support
kubectl create deployment web --image=nginx:1.27 -n lab-support --replicas=2
kubectl expose deployment web --port=80 -n lab-support
# 1. ImagePullBackOff : tag inexistant
kubectl set image deployment/web nginx=nginx:9.99-inexistant -n lab-support
kubectl get pods -n lab-support -w                     # ErrImagePull puis ImagePullBackOff ; describe → "not found"
kubectl rollout undo deployment/web -n lab-support
# 2. OOMKilled : limite mémoire ridicule
kubectl set resources deployment/web -n lab-support --limits=memory=4Mi
kubectl describe pod -n lab-support -l app=web | grep -A3 "Last State"
kubectl set resources deployment/web -n lab-support --limits=memory=128Mi
# 3. Endpoints vides : selector du Service cassé
kubectl patch svc web -n lab-support -p '{"spec":{"selector":{"app":"web-faux"}}}'
kubectl get endpointslices -n lab-support -l kubernetes.io/service-name=web
kubectl patch svc web -n lab-support -p '{"spec":{"selector":{"app":"web"}}}'
# 4. CreateContainerConfigError : ConfigMap absente
kubectl set env deployment/web -n lab-support --from=configmap/absente
kubectl get pods -n lab-support                        # CreateContainerConfigError
kubectl delete namespace lab-support                   # nettoyage

Résultat attendu : savoir dire, pour chaque cas, quelle ligne de describe ou de get donnait la cause.

8. Questions d'entretien#

1. Différence entre un pod, un ReplicaSet et un Deployment ?

Le pod est l'unité qui tourne. Le ReplicaSet garantit N pods identiques. Le Deployment pilote les ReplicaSets : à chaque changement du template de pod, il crée un nouveau ReplicaSet et fait le rollout, en gardant les anciens pour le retour arrière.

2. Un pod est en CrashLoopBackOff. Ta démarche ?

kubectl describe pod pour Last State (raison et code de sortie : 137 + OOMKilled = mémoire), puis kubectl logs --previous pour l'erreur du conteneur précédent, et les Events pour une probe en échec. Ensuite je remonte à la cause : configuration, dépendance (jeton Entra, Key Vault, OpenAI), ressources, ou liveness trop agressive sans startupProbe.

3. ImagePullBackOff sur un ACR privé ?

Le message exact des Events oriente : 401 = identité (AcrPull sur la kubelet identity, az aks check-acr), not found = tag, 403 ou timeout = réseau (Private Endpoint, zone privatelink.azurecr.io avec registre et data endpoint, firewall).

4. Liveness, readiness, startup : différence et piège ?

Liveness redémarre, readiness retire du Service sans redémarrer, startup protège un démarrage lent. Le piège : une liveness qui dépend d'Azure OpenAI ; une lenteur de la dépendance redémarre tous les pods et transforme une latence en panne.

5. Les pods sont Running mais l'utilisateur a des 503. Où regardes-tu ?

READY 0/1 ? Puis les endpoints du Service (selector, readiness, targetPort), puis l'Ingress (classe, adresse) et les logs du controller. Si tout est sain, c'est l'application ou une dépendance.

6. J'ai modifié une ConfigMap, l'appli ne voit rien. Pourquoi ?

Consommée en variable d'environnement : lue au démarrage seulement, il faut redémarrer les pods. En volume, la mise à jour arrive avec un délai, sauf en subPath. Et avec GitOps, la modification doit passer par Git, sinon Argo CD la défait.

7. Explique Workload ID de bout en bout.

Le cluster est OIDC issuer et signe des jetons de ServiceAccount. Une user-assigned managed identity porte un federated credential qui fait confiance à cet issuer pour system:serviceaccount:<ns>:<sa>. Le ServiceAccount porte l'annotation client-id, le pod le label use: "true" ; le webhook injecte les variables et le jeton, le SDK l'échange contre un jeton Entra, et la ressource applique les rôles de l'identité.

8. AADSTS70021 dans les logs : que fais-tu ?

Comparer le subject du federated credential avec le namespace et le ServiceAccount réels du pod, et l'issuer avec l'URL OIDC du cluster (un cluster recréé change d'URL). Si le credential vient d'être créé, attendre la propagation et réessayer.

9. Comment un secret Key Vault arrive-t-il dans le pod, et que se passe-t-il à la rotation ?

Le Secrets Store CSI Driver monte un volume, l'Azure provider lit les objets décrits dans la SecretProviderClass avec l'identité Workload ID. Avec l'autorotation (sondage 2 min par défaut), le fichier est mis à jour ; une variable d'environnement ou un subPath ne le sont pas, il faut redémarrer.

10. Le pod reste en ContainerCreating avec FailedMount 403 ForbiddenByConnection.

Le coffre refuse une connexion qui arrive par le réseau public : le FQDN résout vers l'IP publique depuis les nodes. Je vérifie la zone privatelink.vaultcore.azure.net, son lien avec le VNet du cluster et le peering avec le VNet du Private Endpoint.

11. Pourquoi des requests sont-elles indispensables ?

Le scheduler place les pods avec elles, et le HPA calcule l'utilisation CPU ou mémoire par rapport à elles : sans requests, le HPA n'agit pas et le placement devient imprévisible.

12. Que fais-tu avant de lancer une commande en production ?

Je vérifie le contexte (az account show, kubectl config current-context), je reste en lecture, et pour toute action (redémarrage, rollback) j'annonce l'environnement, la commande, l'impact et le retour arrière, et je la reporte dans Git si le cluster est piloté par GitOps.

9. Fiche à retenir#

• Pod (exécute) → ReplicaSet (N copies) → Deployment (rollouts) ; rollout seulement si le template change.
• maxSurge / maxUnavailable 25 %, progressDeadlineSeconds 600 (ProgressDeadlineExceeded), 10 révisions gardées.
• Service → selector → EndpointSlices ; seuls les pods Ready reçoivent le trafic.
• Ingress = règle, Ingress controller = proxy ; app routing NGINX : classe webapprouting.kubernetes.azure.com, support jusqu'en novembre 2026, cible Gateway API.
• ConfigMap en variable = redémarrage nécessaire ; subPath = pas de mise à jour ; référence absente = CreateContainerConfigError.
• Requests = scheduling et HPA ; limit mémoire = OOMKilled (137) ; limit CPU = throttling.
• Probes : startup (démarrage), liveness (redémarre), readiness (retire du trafic) ; défauts 10 s / 1 s / 3 échecs.
• HPA : boucle 15 s, descente stabilisée 300 s, requests obligatoires.
• CrashLoopBackOff : backoff 10 s → 300 s, remis à zéro après 10 min ; logs --previous.
• Lire describe : Node, Image, State / Last State, Conditions, Events.
• Workload ID : OIDC issuer, managed identity + federated credential (system:serviceaccount:ns:sa), annotation client-id, label use: "true", rôle data plane, variables AZURE_*.
• AADSTS70021/700211/700213 = fédération ; 403 après jeton = RBAC ou réseau.
• CSI Key Vault : SecretProviderClass dans le namespace du pod, FailedMount = ContainerCreating, rotation 2 min si activée, secretObjects vit avec les pods.
• Toujours vérifier le contexte avant une commande ; GitOps : toute correction finit dans Git.

Références#

Relevé du 23/10/2026.

Kubernetes (kubernetes.io) :

• Pod Lifecycle et Debug Pods
• Deployments
• Configure Liveness, Readiness and Startup Probes et Pod API (Probe)
• Service et Ingress
• ConfigMaps et Secrets
• Resource Management for Pods and Containers
• Horizontal Pod Autoscaling

Microsoft Learn :

• Use Microsoft Entra Workload ID with AKS
• Federated identity credentials : considérations (propagation, AADSTS70021)
• Azure Key Vault provider for Secrets Store CSI Driver, identité d'accès et options de configuration
• Troubleshoot Azure Key Vault Secrets Provider add-on in AKS
• Troubleshoot AKS image pull errors from ACR
• Pod stuck in CrashLoopBackOff
• Managed NGINX ingress with the application routing add-on et migration vers la Gateway API
• Use kubelogin to authenticate users in AKS
• Role-based access control for Azure OpenAI
• Verify the connection to the container registry (Architecture Center)