Module 1 – Architecture et API de Kubernetes

Cartographiez le plan de contrôle, suivez le cycle de vie d’un manifeste et apprenez à interroger l’API Kubernetes comme un pro.

Ce module décortique l’architecture interne de Kubernetes et vous apprend à naviguer dans l’API. C’est la base pour comprendre ce que font les commandes kubectl et pour réussir les questions d’examen demandant de “décrire le cycle de vie d’un objet”.

Roadmap du module

  1. Cartographier le control plane et le data plane.
  2. Suivre le cycle de vie d’un manifeste YAML.
  3. Explorer l’API : discovery, ressources namespaced VS cluster-scoped.
  4. Laboratoire d’introspection détaillé.

1. Control plane vs data plane

Le control plane prend les décisions (schedulage, admission, convergence). Il regroupe :

  • kube-apiserver : point d’entrée unique, expose l’API REST.
  • etcd : base de données clé/valeur qui persiste l’état désiré.
  • kube-scheduler : assigne les Pods aux nœuds en fonction des ressources disponibles et des affinities.
  • kube-controller-manager : exécute les controllers natifs (deployment, job, replicaset, endpoint, etc.).
  • cloud-controller-manager (clusters managés) : interagit avec l’IaaS (LB, volumes, nœuds).

Le data plane applique les décisions :

  • kubelet : agent par nœud, s’assure que les Pods déclarés tournent vraiment.
  • container runtime (containerd, cri-o, Docker shim) : lance les conteneurs.
  • kube-proxy ou CNI eBPF : gère le trafic réseau vers les services.

Production Watch : sur EKS/GKE/AKS vous ne gérez pas etcd ni kube-apiserver mais vous devez surveiller leurs quotas API, latences et limites de taille d’objet.

2. Cycle de vie d’un objet

  1. Le manifeste est envoyé à l’API (kubectl apply ou appel REST).
  2. Admission : validation, conversions (mutating webhook), vérifications (validating webhook).
  3. Persistance : l’objet est écrit dans etcd avec un resourceVersion.
  4. Controllers : la boucle de réconciliation compare spec et status puis agit (création de Pod, update de endpoints…).
  5. Scheduler : pour les Pods, il assigne spec.nodeName et les kubelet appliquent les changements.

3. Explorer l’API

Commencez par découvrir les versions et les ressources disponibles.

kubectl api-versions
kubectl api-resources --namespaced=false
kubectl api-resources --namespaced=true | head

Utilisez kubectl explain pour naviguer dans les champs :

kubectl explain deployment
kubectl explain deployment.spec.strategy
kubectl explain deployment.spec.template.spec.containers --recursive | head

Rappelez-vous de la structure group/version/resource :

  • apps/v1 → resources : deployments, statefulsets, daemonsets.
  • batch/v1 → jobs, cronjobs.
  • core/v1 (alias groupe vide) → pods, services, configmaps.

4. Lab d’introspection

Exécutez ces commandes et documentez vos observations dans ~/k8s-training/journal.md.

  1. Inventorier le control plane : 
    kubectl get pods -n kube-system -l tier=control-plane -o wide
kubectl -n kube-system describe pod kube-apiserver-$(kubectl get nodes -o jsonpath='{.items[0].metadata.name}')
  2. Inspecter les handlers d’admission : 
    kubectl get --raw '/api/v1/namespaces/kube-system/configmaps/extension-apiserver-authentication' | jq '.data'
  3. Explorer l’API brute : 
    kubectl get --raw / | jq '.paths' | head
kubectl get --raw /apis/apps/v1 | jq '.resources[] | {name, namespaced, verbs}' | head
  4. Comprendre resourceVersion : 
    kubectl get deployment webapp -o jsonpath='{.metadata.resourceVersion}'

    Modifiez un champ (ex. spec.replicas) et vérifiez que le resourceVersion change.

5. Quiz express

  • Quelle différence entre kubectl apply et kubectl create ?
  • Quel composant écrit dans etcd lorsqu’un Pod est supprimé ?
  • Quel est l’impact d’un webhook mutating qui ajoute un sidecar ?

Pièges observés en production

  • Confondre kubectl get pods --all-namespaces et kubectl get pods -A : le premier est plus verbeux mais identique, gagnez du temps pendant l’examen.
  • Oublier que certaines ressources (RBAC, StorageClass, Nodes) sont cluster-scoped : inutile de fournir un namespace dans les manifestes.
  • Ne pas vérifier la compatibilité API : sur un cluster récent, batch/v1beta1 ou extensions/v1beta1 sont supprimés.

Ressources complémentaires

Checklist de fin de module

  • ✅ Vous pouvez expliquer le rôle des composants du control plane et du data plane.
  • ✅ Vous savez utiliser kubectl explain, kubectl api-resources et kubectl get --raw.
  • ✅ Vous tenez un journal de bord avec les commandes exécutées et vos observations.

Solution détaillée

  1. Inventaire du control plane
    kubectl get pods -n kube-system -l tier=control-plane doit montrer kube-apiserver, kube-controller-manager, kube-scheduler.
    Utilisez kubectl -n kube-system describe pod kube-apiserver-… pour retrouver les arguments (--etcd-servers, --authorization-mode).
  2. Cycle de vie
    Editez un Deployment : kubectl patch deployment webapp -p '{"spec":{"replicas":4}}'.
    Exécutez kubectl get deployment webapp -o jsonpath='{.metadata.resourceVersion}' avant/après pour observer l’incrément.
  3. Exploration API
    kubectl api-resources --namespaced=false | head doit lister nodes, namespaces, persistentvolumes.
    kubectl get --raw /apis/apps/v1 révèle toutes les ressources du groupe apps.
  4. Handlers d’admission
    kubectl get --raw '/api/v1/namespaces/kube-system/configmaps/extension-apiserver-authentication' | jq '.data' doit retourner les clusters CA utilisés par les webhooks.
  5. Journal d’introspection
    Ajoutez une entrée datée reprenant : composants visibles, webhooks présents, resourceVersion observé. Exemple :

    [2025-10-20] Control-plane OK, API expose 273 paths. Deployment webapp revision=4.

Ces vérifications confirment que vous savez naviguer dans l’API et que vous êtes prêt pour les modules workloads/réseau.

Étiquettes

Publications similaires