Les concepts clés de Kubernetes pour bien démarrer

Kubernetes ne lance pas simplement des conteneurs : il orchestre des applications sur un ensemble de machines. Vous ne démarrez pas un conteneur directement sur un serveur. Vous déclarez un état souhaité au cluster, et Kubernetes se charge d'y parvenir. Pour comprendre ce fonctionnement sans vous perdre, vous devez maîtriser six notions fondamentales : le Cluster, les Nodes, les Namespaces, les Pods, les Deployments et les Services.

Prérequis

Un cluster de test et kubectl configuré. Si vous n'en avez pas encore, montez-en un en vingt minutes avec votre premier cluster, puis revenez ici. Les commandes de cette page se contentent de lire l'état du cluster : elles ne créent rien et ne peuvent rien casser.

Ce que vous allez apprendre

Cluster et Nodes : l'infrastructure sur laquelle tout repose
Namespace : comment organiser et isoler vos ressources
Pod : l'unité de base qui exécute vos conteneurs
Deployment : le contrôleur qui maintient vos applications en vie
Service : le point d'accès réseau stable vers vos pods
Comment tout s'articule : le modèle mental complet

Pourquoi ces concepts sont essentiels

Sans ce vocabulaire, ni la documentation officielle ni les tutoriels ne sont lisibles : tous les emploient en permanence, sans jamais les redéfinir. Les apprendre maintenant fait gagner du temps sur tout le reste du parcours.

Vue d'ensemble : nature de chaque concept

Avant de détailler chaque notion, voici comment les situer :

Concept	Nature	Rôle
Cluster	Ensemble	Regroupe toutes les ressources
Node	Machine	Exécute les workloads
Namespace	Organisation logique	Isole et range les objets
Pod	Unité d'exécution	Fait tourner les conteneurs
Deployment	Contrôleur	Maintient et met à jour les pods
Service	Abstraction réseau	Fournit un accès stable

Le Cluster : votre infrastructure Kubernetes

Un cluster est un ensemble de machines qui travaillent ensemble pour exécuter vos applications. Il se compose de deux types de machines :

Type	Rôle
Control plane	Cerveau du cluster : décide où placer les pods, surveille l'état
Worker nodes	Muscles du cluster : exécutent réellement les conteneurs

Vous interagissez avec le cluster via kubectl, l'outil en ligne de commande.

kubectl cluster-info

Kubernetes control plane is running at https://127.0.0.1:39195
CoreDNS is running at https://127.0.0.1:39195/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy

Cette commande confirme que votre machine peut communiquer avec le control plane. Le port varie d'un cluster à l'autre : seule compte la réponse.

Les Nodes : les serveurs de votre cluster

Un node est une machine (physique ou virtuelle) qui fait partie du cluster. Chaque node peut exécuter plusieurs pods.

kubectl get nodes

NAME                    STATUS   ROLES           AGE   VERSION
doc-k8s-control-plane   Ready    control-plane   9m    v1.37.0
doc-k8s-worker          Ready    <none>          9m    v1.37.0

Dans cet exemple :

doc-k8s-control-plane est le control plane, ce que dit la colonne ROLES
doc-k8s-worker est un worker node : <none> signifie qu'il ne porte aucun rôle particulier, pas qu'il est mal configuré

La colonne STATUS est celle à surveiller. Un node Ready est opérationnel et peut recevoir des pods. Un NotReady signale un problème, le plus souvent le réseau, des ressources épuisées ou un kubelet arrêté. Nuance utile juste après une création de cluster : NotReady y est normal pendant quelques secondes, le temps que le réseau se mette en place.

Les Namespaces : organiser le cluster

Un namespace est un espace de noms qui isole logiquement les ressources. Avant de créer des pods, il faut savoir où les ranger.

kubectl get namespaces

NAME                 STATUS   AGE
default              Active   9m
kube-node-lease      Active   9m
kube-public          Active   9m
kube-system          Active   9m
local-path-storage   Active   9m

Namespace	Usage
`default`	Vos applications si vous ne spécifiez rien
`kube-system`	Composants internes de Kubernetes
`kube-public`	Ressources lisibles par tous
`kube-node-lease`	Gestion interne des heartbeats des nodes
`local-path-storage`	Ajouté par Kind pour fournir du stockage local

En production, créez un namespace par application ou par équipe. Au-delà du rangement, c'est ce découpage qui rend possible tout le reste : un namespace sert de périmètre aux quotas de ressources et aux droits d'accès. Sans lui, ces politiques s'appliqueraient au cluster entier ou à rien.

Les Pods : l'unité de base

Un Pod est l'unité minimale que Kubernetes déploie. Dans la majorité des cas, il contient un seul conteneur applicatif. Plusieurs conteneurs dans un même Pod partagent le même réseau (même IP) et peuvent partager des volumes.

kubectl get pods -A

NAMESPACE     NAME                                            READY   STATUS    RESTARTS   AGE
kube-system   coredns-559f6c778d-4wr5k                        1/1     Running   0          9m
kube-system   etcd-doc-k8s-control-plane                      1/1     Running   0          9m
kube-system   kube-apiserver-doc-k8s-control-plane            1/1     Running   0          9m
kube-system   kube-controller-manager-doc-k8s-control-plane   1/1     Running   0          9m
kube-system   kube-proxy-8rrws                                1/1     Running   0          9m
kube-system   kube-scheduler-doc-k8s-control-plane            1/1     Running   0          9m

Chaque ligne est un pod. La colonne READY indique le nombre de conteneurs prêts sur le total (1/1 = 1 conteneur prêt sur 1).

Regardez les noms : Kubernetes se gère lui-même avec ses propres pods. etcd, kube-apiserver et kube-scheduler sont les composants du control plane, et ils tournent comme n'importe quelle autre application du cluster. Vous n'avez rien à en faire aujourd'hui : ils sont gérés par Kubernetes, et les connaître n'est utile qu'au moment d'administrer un cluster.

En production, ne créez jamais de pod seul. Un pod créé directement avec kubectl run n'est surveillé par personne : s'il plante ou si son nœud tombe, il disparaît définitivement, et rien ne le recrée. C'est la différence qui justifie l'existence des contrôleurs. Pour toute application durable, passez par un Deployment. Les pods seuls gardent leur utilité pour apprendre, tester ou diagnostiquer, ce que fait d'ailleurs ce guide.

Le Deployment : le contrôleur qui maintient vos applications

Un Deployment est le contrôleur le plus courant pour faire tourner une application. Il ne se contente pas de "créer des pods" : il maintient le bon nombre de répliques, remplace ceux qui tombent et pilote les mises à jour progressives.

Ce que vous déclarez	Ce que le Deployment fait
`replicas: 3`	Crée et maintient 3 pods
Image `nginx:1.29`	S'assure que tous les pods utilisent cette image
Un pod plante	En relance un automatiquement
Nouvelle version d'image	Rolling update sans coupure de service

kubectl get deployments -A

NAMESPACE            NAME                     READY   UP-TO-DATE   AVAILABLE   AGE
kube-system          coredns                  2/2     2            2           9m
local-path-storage   local-path-provisioner   1/1     1            1           9m

La colonne READY montre pods-prêts/pods-désirés. CoreDNS affiche 2/2 : deux répliques demandées, deux en service. C'est le Deployment qui maintient ce compte, pas vous.

Le Service : l'accès réseau stable

Un Service fournit un point d'accès stable à un groupe de pods. Comme les pods sont éphémères (ils peuvent être recréés avec une nouvelle IP), on ne les contacte pas directement : on passe par le Service, qui garde une adresse stable et répartit le trafic.

Problème	Solution du Service
Les pods changent d'IP quand ils redémarrent	Le Service garde une IP fixe
Plusieurs pods font le même travail	Le Service répartit le trafic (load balancing)
Besoin d'un nom DNS pour l'application	Le Service expose un nom stable

kubectl get services -A

NAMESPACE     NAME         TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)                  AGE
default       kubernetes   ClusterIP   10.96.0.1    <none>        443/TCP                  9m
kube-system   kube-dns     ClusterIP   10.96.0.10   <none>        53/UDP,53/TCP,9153/TCP   9m

Types de services les plus courants :

ClusterIP (défaut) : accessible uniquement depuis l'intérieur du cluster
LoadBalancer : accessible depuis l'extérieur via une adresse dédiée

Un cluster neuf n'a que des ClusterIP, comme ci-dessus. Le type LoadBalancer suppose que quelqu'un fournisse l'adresse : un fournisseur cloud en production, un composant à installer en local. Vous en créerez un plus tard dans le parcours.

Comment tout s'articule

Voici comment ces objets travaillent ensemble dans un scénario typique :

Dans un cluster, le control plane décide et observe l'état, tandis que les worker nodes hébergent le namespace demo : le Deployment web maintient trois Pods (web-abc12, web-def34, web-ghi56) que le Service web de type ClusterIP route vers ces trois pods

Je crée un namespace demo pour ranger mes ressources
Je déclare un Deployment web avec 3 répliques
Le Deployment crée 3 Pods qui tournent sur les worker nodes
Je crée un Service web qui cible ces pods
Les autres applications appellent le Service, pas les pods directement

Ce modèle déclaratif est la clé de Kubernetes : vous décrivez l'état souhaité, le cluster s'assure de l'atteindre.

Ce que vous n'avez pas besoin de comprendre tout de suite

Vous croiserez ces composants plus tard dans votre parcours. Pour bien démarrer, concentrez-vous d'abord sur les objets que vous manipulez directement :

Composant	Quand l'apprendre
etcd	Administration avancée
Scheduler	Administration avancée
kube-proxy	Réseau avancé
CNI (Calico, Cilium...)	Réseau avancé
Admission controllers	Sécurité avancée

Maîtrisez d'abord Pod, Deployment et Service. Ces trois objets suffisent à déployer la grande majorité des applications, et tout le reste s'y rattache : les ConfigMaps et Secrets alimentent le Pod, l'Ingress se pose devant le Service, les contrôleurs plus spécialisés remplacent le Deployment sur des cas précis.

À retenir

Concept	Définition en une phrase
Cluster	Ensemble de machines qui exécutent Kubernetes
Node	Une machine du cluster
Namespace	Isolation logique pour ranger les ressources
Pod	Unité minimale qui exécute un ou plusieurs conteneurs
Deployment	Contrôleur qui maintient et met à jour les pods
Service	Point d'accès réseau stable vers un groupe de pods

Les 4 idées fondamentales à retenir :

Je ne déploie pas mon application directement sur un node, je la déclare au cluster
Je déploie des pods, généralement via un Deployment
Je passe par un Service pour joindre mes pods
Le cluster répartit tout cela sur les machines disponibles

Les commandes essentielles :

kubectl cluster-info            # Vérifier la connexion
kubectl get nodes               # Lister les machines
kubectl get namespaces          # Lister les espaces de noms
kubectl get pods -A             # Lister tous les pods
kubectl get deployments -A      # Lister tous les deployments
kubectl get services -A         # Lister tous les services

Pour aller plus loin

Votre premier déploiement : La mise en pratique de ce vocabulaire sur une application exposée sur le réseau.
Les ressources Kubernetes : La carte des objets de l'API, du Pod au StatefulSet, et leurs liens de parenté.
Les Pods : L'anatomie et le cycle de vie de l'unité que tous les autres objets manipulent.