Architecture K8s et premières commandes kubectl

Tu sais maintenant pourquoi Kubernetes existe. Mais pour l’utiliser efficacement — et surtout pour débugger quand ça casse — tu dois comprendre comment il est construit. L’architecture de K8s, c’est pas un détail théorique : c’est la carte que tu lis quand ton pod refuse de démarrer à 3h du matin.

Dans ce chapitre, on décortique les composants du cluster, on lance nos premières commandes kubectl, et on connecte le tout avec un cas concret.

Pourquoi comprendre l’architecture est essentiel

Beaucoup de débutants apprennent kubectl apply sans savoir ce qui se passe derrière. Résultat : dès qu’un pod reste en Pending ou qu’un service ne répond pas, c’est la panique.

Comprendre l’architecture te permet de :

• Localiser un problème en quelques secondes (c’est le scheduler ? le kubelet ? l’API server ?)
• Dimensionner ton cluster intelligemment (combien de workers ? quelle taille pour etcd ?)
• Passer les certifications (CKA/CKAD) — l’architecture représente ~25% des questions

🔥 Cas réel : Une startup fintech avait des pods qui restaient bloqués en Pending pendant 10 minutes. L’équipe cherchait un bug dans leur YAML. Le vrai problème ? Le kube-scheduler était surchargé car ils avaient 3000 pods avec des règles d’affinité complexes sur un control plane sous-dimensionné. Connaître l’architecture = identifier la cause en minutes, pas en heures.

Comprendre l’architecture de Kubernetes

Un cluster Kubernetes se divise en deux parties : le control plane (le cerveau) et les worker nodes (les muscles).

Le Control Plane

Le control plane prend les décisions. Il ne fait tourner aucune application métier — il orchestre.

• kube-apiserver — Le point d’entrée unique. Chaque commande kubectl, chaque action passe par lui. C’est le seul composant qui parle à etcd.
• etcd — La base de données clé-valeur distribuée. Elle stocke TOUT l’état du cluster : configs, secrets, état des pods. Si etcd meurt, ton cluster est aveugle.
• kube-scheduler — Il décide où placer un nouveau pod. Il analyse les ressources disponibles, les contraintes (affinité, tolérations) et assigne le pod à un node.
• kube-controller-manager — Le gardien de l’état désiré. Si tu demandes 3 réplicas et qu’un pod crash, c’est lui qui détecte l’écart et ordonne la recréation.

💡 Tip DevOps : En production, etcd doit tourner sur un nombre impair de nœuds (3 ou 5) pour le quorum. Un etcd à 2 nœuds, c’est pire qu’un seul — tu perds le consensus si un tombe.

Les Worker Nodes

Les workers font le travail réel : ils exécutent tes conteneurs.

• kubelet — L’agent sur chaque node. Il reçoit les instructions de l’API server et s’assure que les conteneurs tournent comme demandé.
• kube-proxy — Gère les règles réseau. Il route le trafic vers les bons pods quand tu utilises un Service.
• Container runtime — L’outil qui lance les conteneurs (containerd dans 99% des cas aujourd’hui).

🧠 À retenir : Le flux complet quand tu tapes kubectl apply : kubectl → API server → etcd (stockage) → scheduler (placement) → kubelet (exécution sur le node). Chaque étape peut échouer indépendamment.

Commandes kubectl essentielles

kubectl est ton interface quotidienne avec le cluster. Voici les commandes qui couvrent 90% de tes besoins.

Pour inspecter l’état du cluster et de ses composants :

# Voir les nœuds et leur état
kubectl get nodes -o wide

# Lister les pods système (control plane)
kubectl get pods -n kube-system

# Détails complets d'un nœud (capacité, conditions, pods assignés)
kubectl describe node <nom-du-noeud>

Pour déployer et gérer des applications :

# Créer un déploiement rapide
kubectl create deployment nginx-demo --image=nginx:1.27 --replicas=3

# Voir tous les objets liés à une app
kubectl get all -l app=nginx-demo

# Scaler à chaud
kubectl scale deployment nginx-demo --replicas=5

Pour débugger quand quelque chose ne marche pas :

# Logs d'un pod (les 50 dernières lignes, en temps réel)
kubectl logs <nom-du-pod> --tail=50 -f

# Shell interactif dans un pod
kubectl exec -it <nom-du-pod> -- /bin/sh

# Événements triés par date (goldmine pour le debug)
kubectl get events --sort-by=.metadata.creationTimestamp

⚠️ Attention : kubectl describe pod est ton meilleur ami pour le debug. La section Events en bas de la sortie te dit exactement pourquoi un pod ne démarre pas : image introuvable, resources insuffisantes, volume non monté…

Pour travailler avec les namespaces et le YAML déclaratif :

# Créer un namespace et y déployer
kubectl create namespace staging
kubectl apply -f mon-app.yaml -n staging

# Changer de namespace par défaut (évite les -n à répétition)
kubectl config set-context --current --namespace=staging

# Appliquer tout un dossier de manifestes
kubectl apply -f manifests/

💡 Tip DevOps : Utilise toujours kubectl apply -f (déclaratif) plutôt que kubectl create (impératif) en production. Le déclaratif est idempotent — tu peux le relancer sans casser ce qui existe déjà.

Cas concret : déploiement d’une app d’entreprise

Imaginons que tu bosses chez une boîte e-commerce. L’équipe veut déployer un nouveau service de recommandations produits sur le cluster K8s existant.

Voici le manifeste YAML que tu appliques :

apiVersion: apps/v1
kind: Deployment
metadata:
  name: reco-service
  namespace: production
  labels:
    app: reco-service
    team: data
spec:
  replicas: 3
  selector:
    matchLabels:
      app: reco-service
  template:
    metadata:
      labels:
        app: reco-service
    spec:
      containers:
        - name: reco
          image: registry.internal/reco-service:v2.1.0
          ports:
            - containerPort: 8080
          resources:
            requests:
              cpu: "250m"
              memory: "256Mi"
            limits:
              cpu: "500m"
              memory: "512Mi"
---
apiVersion: v1
kind: Service
metadata:
  name: reco-service
  namespace: production
spec:
  selector:
    app: reco-service
  ports:
    - port: 80
      targetPort: 8080
  type: ClusterIP

Ce qui se passe dans le cluster quand tu lances kubectl apply -f reco-service.yaml :

1. L’API server valide le YAML et stocke l’état désiré dans etcd
2. Le controller manager détecte qu’il faut 3 réplicas mais 0 existent
3. Le scheduler choisit 3 workers avec assez de CPU/RAM disponibles
4. Les kubelets des 3 nodes téléchargent l’image et démarrent les conteneurs
5. kube-proxy configure les règles réseau pour que le Service route vers les 3 pods

🔥 Cas réel : Le pod reste en ImagePullBackOff ? C’est le kubelet qui n’arrive pas à télécharger l’image. Vérifie : l’image existe-t-elle ? Le registry est-il accessible ? Y a-t-il un imagePullSecret configuré ?

Pièges fréquents et comment les éviter

❌ Pod en Pending qui ne bouge pas Le scheduler ne trouve pas de node compatible. Causes courantes : pas assez de CPU/RAM disponible, nodeSelector qui ne matche aucun node, ou PersistentVolumeClaim non satisfait. Vérifie avec kubectl describe pod → section Events.

❌ CrashLoopBackOff infini Le conteneur démarre et crash en boucle. Le kubelet le redémarre avec un backoff exponentiel (10s, 20s, 40s…). Regarde les logs avec kubectl logs <pod> --previous pour voir la sortie du conteneur avant le crash.

❌ Service qui ne route vers rien Les labels du Service selector ne matchent pas les labels des pods. C’est l’erreur la plus fourbe car aucune erreur n’apparaît — le Service existe, mais kubectl get endpoints <service> montre une liste vide.

⚠️ Attention : Ne confonds pas requests et limits dans les resources. Les requests servent au scheduler pour placer le pod. Les limits sont enforced par le kubelet. Un pod sans requests peut être schedulé sur un node déjà saturé.

❌ Modifier etcd directement Jamais. Tout passe par l’API server. Toucher etcd directement peut corrompre l’état du cluster de façon irréversible.

Exercice pratique

Mets en place un cluster et explore son architecture :

1. Crée un cluster Kind avec 1 control plane et 2 workers
2. Liste les nœuds et identifie leurs rôles
3. Explore les pods du namespace kube-system — retrouve chaque composant du control plane
4. Déploie nginx avec 3 réplicas, puis supprime un pod manuellement
5. Observe la recréation automatique et identifie quel composant l’a déclenchée

Pour vérifier le comportement d’auto-healing, tu peux utiliser cette commande qui surveille les pods en temps réel :

# Terminal 1 : watch les pods
kubectl get pods -w

# Terminal 2 : supprime un pod et observe le Terminal 1
kubectl delete pod <nom-du-pod>

🧠 À retenir : C’est le controller manager qui détecte l’écart entre l’état désiré (3 réplicas) et l’état réel (2 après suppression), puis le scheduler qui place le nouveau pod, et le kubelet qui le démarre.

Ce qu’il faut retenir

• L’architecture K8s se divise en control plane (cerveau) et worker nodes (muscles)
• etcd est la source de vérité — tout l’état du cluster y vit
• Le flux kubectl apply traverse 5 composants : API server → etcd → controller → scheduler → kubelet
• kubectl describe et kubectl get events sont tes outils de debug #1
• Toujours déclarer resources requests/limits — sans ça, le scheduler travaille à l’aveugle
• Les labels connectent tout : Deployments → Pods, Services → Pods. Une typo dans un label = un service cassé silencieusement

Dans le prochain chapitre, on attaque les ConfigMaps, Secrets et Persistent Volumes — la gestion de la configuration et des données dans Kubernetes.

Cet article fait partie de la série Apprendre Kubernetes. Retrouvez tous les chapitres sur devopslab.ch.

🧪 Lab pratique

Mets en pratique ce que tu viens d’apprendre dans un environnement interactif, directement dans ton navigateur. Pas besoin d’installer quoi que ce soit !

🚀 Lancer le lab sur Killercoda →

🎓 Examen de fin de chapitre

Teste tes connaissances avec cet examen de 10 questions. Il faut 70% de bonnes réponses pour obtenir le badge du chapitre.

📤 Soumettre ton travail

Tu as terminé le chapitre ? Soumets ton code ou ta configuration pour obtenir un review automatique par IA.