Que se passe-t-il sur un kubectl apply ?

Du manifest au pod Ready, sur ce cluster EKS. Le même chemin est suivi quand c'est ArgoCD qui applique.

Les trois phases

1. Synchrone : API server → authentification → RBAC → admission → écriture dans etcd → created. Le client a fini : kubectl rend la main alors qu'aucun pod n'existe encore.
2. Asynchrone : le contrôleur Deployment crée un ReplicaSet, qui crée des Pods sans nœud. Chaque Pod repasse l'admission (LimitRange, ResourceQuota, Pod Security Admission). Le scheduler choisit ensuite un nœud.
3. Sur le nœud : le kubelet demande une IP à Cilium (plage overlay 10.42.x), tire l'image depuis ECR, lance l'init container migrations, puis le conteneur applicatif, jusqu'à Ready.

Deux pièges de lecture

• etcd arrive avant le scheduler : l'objet est écrit, puis seulement placé.
• created ne veut pas dire « qui tourne » : c'est la même famille que « créé n'est pas prêt » (#236, #237).

Le schéma interactif

Ouvrir le schéma en plein écran