IT Toolbox AI
Kubernetes · Architecture Kubernetes

Architecture Kubernetes

Comprenez les composants d’un cluster Kubernetes et vérifiez toujours le contexte ciblé par kubectl.

Leçon disponible
20 min

Objectifs

  • Distinguer cluster, control plane, worker node, namespace et Pod.
  • Comprendre le rôle des principaux composants du control plane.
  • Relier kubelet, kube-proxy et container runtime au fonctionnement d’un nœud.
  • Identifier le cluster et le contexte courant avant toute opération kubectl.

Comprendre l’architecture Kubernetes

Kubernetes orchestre des applications containerisées en maintenant un état désiré. Un cluster comprend un control plane qui prend les décisions et un ou plusieurs worker nodes qui exécutent les workloads.

kubectl ne contacte pas directement les containers : il utilise le kubeconfig pour envoyer des requêtes à l’API Server du contexte sélectionné. Les contrôleurs et agents du cluster convergent ensuite vers l’état demandé.

Les composants du control plane

Le control plane expose l’API et maintient l’état global du cluster. Ses composants peuvent être répliqués ou gérés différemment selon la distribution Kubernetes.

  • kube-apiserver : point d’entrée HTTP de l’API Kubernetes et validation des requêtes.
  • etcd : magasin clé-valeur cohérent contenant les données de l’API du cluster.
  • kube-scheduler : choisit un nœud adapté pour les Pods qui n’en ont pas encore.
  • kube-controller-manager : exécute des boucles de contrôle qui rapprochent l’état réel de l’état désiré.
Afficher les informations générales du cluster
kubectl cluster-info
kubectl get nodes

Les composants d’un worker node

Un nœud est une machine physique ou virtuelle enregistrée dans le cluster. Il fournit CPU, mémoire, réseau et stockage aux Pods qui lui sont assignés.

  • kubelet : agent qui veille à l’exécution des containers décrits dans les PodSpecs du nœud.
  • kube-proxy : composant optionnel qui implémente des règles réseau pour les Services lorsqu’un autre mécanisme ne le remplace pas.
  • container runtime : logiciel compatible CRI, comme containerd ou CRI-O, qui exécute les containers.

Cluster, nœud, namespace et Pod

Le cluster est l’ensemble administré. Un nœud fournit la capacité d’exécution. Un namespace sépare logiquement des ressources portant des noms similaires. Un Pod est l’unité de calcul déployable placée sur un nœud.

  • Cluster : périmètre complet du control plane et des nœuds.
  • Node : machine membre qui exécute des Pods.
  • Namespace : périmètre logique pour de nombreuses ressources namespaced.
  • Pod : un ou plusieurs containers co-localisés et partageant notamment le réseau.
Lister namespaces et Pods de tous les namespaces
kubectl get namespaces
kubectl get pods -A

Toutes les ressources ne sont pas namespaced : les Nodes, PersistentVolumes et StorageClasses sont par exemple visibles au niveau du cluster.

Kubeconfig et contexte courant

Un kubeconfig contient des clusters, des identités et des contextes qui les associent, éventuellement avec un namespace par défaut. Le contexte courant détermine la cible implicite de kubectl.

Vérifier la cible avant toute action
kubectl config current-context
kubectl config get-contexts
Flux général d’une demande
kubectl → API Server → Scheduler/Controllers → Node/Kubelet → Container

Bonnes pratiques

Vérifiez systématiquement contexte, namespace et ressource avant une commande de modification. Utilisez des droits RBAC limités et des noms de contexte explicites pour réduire les erreurs entre développement et production.

  • Commencer par des commandes get et describe en lecture seule.
  • Afficher explicitement le namespace lorsque le contexte est ambigu.
  • Ne pas partager un kubeconfig contenant des identifiants sensibles.

Mini résumé

  • Le control plane expose l’API et maintient l’état désiré.
  • Les worker nodes exécutent les Pods grâce au kubelet et au container runtime.
  • Les namespaces organisent des ressources sans créer de nouveaux clusters.
  • Le kubeconfig et son contexte courant déterminent la cible de kubectl.

Mini quiz

Trois questions pour vérifier les notions essentielles de la leçon.

1. Quel composant choisit le nœud d’un Pod qui attend un placement ?
2. Quel rôle le kubelet joue-t-il sur un worker node ?
3. Pourquoi vérifier current-context avant une modification ?