Aller au contenu
Lecteurs bêta recherchés. L’édition française est traduite. Elle sortira quand j’aurai les retours de quelques lecteurs bêta. Si tu veux en faire partie, dis-le-moi : ouvre une issue sur GitHub · écris-moi sur X.
Couverture de Kubernetes 101 : fond bleu presque noir, le titre en blanc, le nombre 101 en bleu Kubernetes et le nom de Javier Vela Aylón en bas.

Livre · Édition française · 2026

Kubernetes 101 — le guide pratique pour comprendre Kubernetes en partant de zéro

15 chapitres, 5 annexes et une partie pratique de 55 laboratoires sur un vrai cluster, sans rien installer. Tu lis le concept et tu l’essaies aussitôt.

375 pages · Édition 2026 · Kubernetes 1.37 · Kindle et papier

Lire gratuitement le début du livre

Pour qui

À qui s’adresse ce livre ?

À toute personne qui veut vraiment apprendre Kubernetes, qu’elle vienne ou non du monde de l’IT. Aussi — et surtout — à ceux qui travaillent déjà avec la technologie au quotidien et n’arrivent pas tout à fait à comprendre ce qui se passe en dessous.

C’est le livre que j’aurais aimé lire il y a quelques années : avec des diagrammes qui expliquent qui fait quoi, et une partie pratique où casser des choses sans peur.

Le prologue

Lecteurs

Ce qu’en disent ceux qui l’ont déjà lu

Programme

Ce que tu vas apprendre

Chaque chapitre a son laboratoire, et l’annexe D aussi. S’y ajoute un bloc qui n’existe que comme laboratoire : le défi final.

  • Chapitre du livre
  • Laboratoire pratique
Chapitre 01

Introduction aux conteneurs et à l’orchestration

Image, conteneur, contrôleur et nœud expliqués avant même de nommer Kubernetes. Comment se construit l’image qui se déploie dans tout le livre : Dockerfile multistage, base distroless et un processus qui ne tourne pas en root. Et les vrais avantages et inconvénients des conteneurs, avec ce qui se complique quand on les orchestre à grande échelle.

Son laboratoire est le module Conteneurs : tu construis l’image tienda/api et tu la publies dans le registre.

  • Chapitre du livre
  • Laboratoire pratique
Chapitre 02

Architecture de Kubernetes

Le kube-apiserver et le kubelet, et la communication hub-and-spoke : pourquoi tout passe par l’API server et pourquoi lui seul parle à etcd. Les autres composants sont racontés là où on en a vraiment besoin — kube-proxy dans Réseau, le scheduler dans Scheduling — et tous ensemble, à la fin, dans l’annexe D.

Son laboratoire est le module « Le cluster vu de l’intérieur », sur un vrai cluster kubeadm, avec l’annexe D.

  • Chapitre du livre
  • Laboratoire pratique
Chapitre 03

Parler au cluster

Pourquoi kubectl n’est pas Kubernetes mais un client HTTP qui parle à l’API server, et comment le voir avec --v. Le Namespace tienda vide, le premier Pod web dedans, regarder à l’intérieur, lire ses logs et le supprimer. C’est le chapitre où il n’est pas encore grave de ne pas tout à fait comprendre ce que tu déploies.

Partage son laboratoire avec le chapitre 04, dans le module Fondamentaux.

  • Chapitre du livre
  • Laboratoire pratique
Chapitre 04

Objets de Kubernetes

Le premier Pod, les Namespaces, les labels et les selectors, et les annotations : comment se nomme et se regroupe ce qui vit dans le cluster. Et pourquoi la liste des types qu’un cluster comprend n’est pas figée, ce qui ouvre la porte au chapitre Extensibilité.

Partage son laboratoire avec le chapitre 03, dans le module Fondamentaux.

  • Chapitre du livre
  • Laboratoire pratique
Chapitre 05

Workloads

Des Pods avec probes, requests, limits et QoS. ReplicaSets, Deployments avec rollout et rollback, StatefulSets, DaemonSets, Jobs et CronJobs.

  • Chapitre du livre
  • Laboratoire pratique
Chapitre 06

Mise à l’échelle

Mise à l’échelle automatique des nœuds (Cluster Autoscaler et Karpenter) et des Pods : Horizontal Pod Autoscaler et Vertical Pod Autoscaler, ce que mesure chacun et quand ils se gênent.

  • Chapitre du livre
  • Laboratoire pratique
Chapitre 07

Réseau

kube-proxy et les règles qui font que l’IP d’un Service finit sur un Pod. Services et DNS interne avec CoreDNS, Ingress, Gateway API — on jette l’Ingress et on le refait — et NetworkPolicy pour fermer le trafic aux couches 3 et 4.

  • Chapitre du livre
  • Laboratoire pratique
Chapitre 08

Configuration

Des ConfigMaps pour ce qui n’est pas confidentiel et des Secrets pour ce qui l’est, consommés comme variables d’environnement ou comme fichiers montés dans le Pod. imagePullSecrets pour télécharger des images depuis un registre privé, et la Downward API pour que le Pod sache qui il est et où il tourne.

  • Chapitre du livre
  • Laboratoire pratique
Chapitre 09

Stockage

StorageClass, PersistentVolume et PersistentVolumeClaim avec des provisioners CSI, comment un Pod finit par monter le disque qu’il ne peut pas perdre, et VolumeSnapshot pour les sauvegardes.

  • Chapitre du livre
  • Laboratoire pratique
Chapitre 10

Sécurité

Authentification et autorisation auprès de l’API, RBAC et ServiceAccounts, la chaîne d’admission, securityContext et les Pod Security Standards que PSA applique par Namespace. Et ce que le securityContext ne protège pas : la supply chain, avec SBOM et signature avec cosign.

  • Chapitre du livre
  • Laboratoire pratique
Chapitre 11

Policies

ResourceQuota et LimitRange : le budget de CPU et de mémoire d’un Namespace et les valeurs par défaut de chaque conteneur.

  • Chapitre du livre
  • Laboratoire pratique
Chapitre 12

Scheduling

Taints et tolerations, nodeSelector, affinités et nodeName ; priorité et préemption, PodDisruptionBudgets et Dynamic Resource Allocation.

  • Chapitre du livre
  • Laboratoire pratique
Chapitre 13

Travailler avec le cluster

Contextes et Namespaces, le fichier de préférences kuberc, quatre pièges qui reviennent, ce qu’apporte Kustomize et ce qu’apporte Helm, GitOps avec Argo CD et Flux, et quoi regarder quand quelque chose casse dans la tienda, le système d’exemple du livre. La référence complète des commandes vit dans l’annexe E.

  • Chapitre du livre
  • Laboratoire pratique
Chapitre 14

Extensibilité

La CRD qui apprend au cluster un mot nouveau — la Promocion de la tienda — et l’opérateur qui lui donne un sens : la boucle de réconciliation, ce que raconte le status et quand ne pas écrire d’opérateur. Dans le laboratoire, tu l’écris en entier, en Go et avec controller-runtime.

  • Chapitre du livre
  • Laboratoire pratique
Chapitre 15

Observabilité

Les Events du cluster, métriques, logs et traces — Prometheus, Loki, Grafana —, lequel des quatre regarder en premier et l’observabilité émergente avec eBPF.

  • Chapitre du livre
  • Laboratoire pratique

Et un bloc qui n’existe que comme laboratoire

Il est inclus dans la partie pratique et il est en accès gratuit, mais il n’a pas de chapitre correspondant dans le livre. Pas besoin : il n’y a rien de nouveau à apprendre, c’est l’examen de tout ce qui précède.

Seulement dans la partie pratique

Défi final : éteins le scheduler

Diagnostique le cluster à cœur ouvert, sans scheduler, et ramène-le à la vie. Ce qui cesse de fonctionner et ce qui continue de fonctionner, et presque personne ne s’attend à la réponse.

Et cinq annexes

Annexe A

Glossaire des sigles

Les 74 sigles qui apparaissent dans le livre, réunis dans un tableau pour les consulter d’un coup d’œil. Publié en entier dans le glossaire du site (en espagnol).

Annexe B

Le système complet

Tout ce qui est construit chapitre par chapitre, réuni et dans l’ordre d’application : plus de six cents lignes de YAML qui ne se tapent pas depuis une feuille de papier, mais qui vivent dans le dépôt de code.

Annexe C

Depuis quand fonctionne chaque pièce

Chapitre par chapitre, quelles fonctionnalités le livre date et depuis quelle version elles existent, pour vérifier d’un coup d’œil si ce que tu lis est encore valable dans ton cluster. Le tout rapporté à Kubernetes 1.37.

Annexe D

Le cluster vu de l’intérieur

La salle des machines, à la fin et non au début : etcd, le controller-manager, le cloud-controller-manager, comment s’exécutent vraiment les conteneurs — CRI, runtimes et OCI — et les Leases. C’est la seule annexe avec son propre laboratoire, sur un vrai cluster kubeadm.

  • Laboratoire pratique
Annexe E

Antisèche kubectl

Toute la référence des commandes, classée par ce que tu veux faire et non par verbe : se situer, regarder le cluster, regarder dans un Pod, changer à la main, changer avec des fichiers, nœuds et maintenance, permissions et audit, et Helm.

Inclus avec le livre

La partie pratique : 55 laboratoires en 15 modules

15 modules, 53 unités et 7 challenges : des tutoriels pas à pas avec le YAML expliqué, et des challenges où l’on te livre un cluster avec quelque chose de cassé et où tu dois le réparer.

Un vrai cluster Kubernetes dans le navigateur, prêt en quelques secondes. Rien à installer, rien à configurer et aucun coût supplémentaire. La partie pratique est publique et gratuite : pas de code, pas de coupon, rien à valider. Pas besoin d’avoir le livre pour commencer : les laboratoires s’expliquent tout seuls. Ce que le livre ajoute, c’est le pourquoi — d’où vient chaque décision et ce qui échoue en silence quand tu ne la prends pas — plus les 54 diagrammes et les cinq annexes, qui ne tiennent pas dans un terminal.

Voir la partie pratique

Un coup d’œil à l’intérieur

Diagrammes du livre

Chaque concept s’explique avec un diagramme qui montre qui fait quoi et pourquoi. Six des cinquante-quatre que tu trouveras dedans ; clique sur n’importe lequel pour le voir en taille réelle.

  • Diagramme de l’architecture d’un cluster : à gauche le control plane avec kube-apiserver, etcd, kube-scheduler et kube-controller-manager ; à droite les nœuds worker avec kubelet, kube-proxy et le runtime de conteneurs. Toutes les flèches des nœuds pointent vers le kube-apiserver, et seul le kube-apiserver parle à etcd.

    Fondamentaux · diagramme 1 sur 6

    Architecture du cluster

    Control plane et nœuds worker : qui parle à qui, et pourquoi le kube-apiserver est la seule porte d’entrée vers etcd.

  • Diagramme hiérarchique : un Deployment en haut, en dessous deux ReplicaSets (l’ancienne révision se réduisant à zéro et la nouvelle grandissant) et, sous chacun, ses Pods. Les flèches montrent le rolling update et le retour à la révision précédente.

    Workloads · diagramme 2 sur 6

    Deployments, rollout et rollback

    Un Deployment gère un ReplicaSet par révision : c’est ainsi qu’il fait des rolling updates et revient en arrière sans downtime.

  • Diagramme comparatif des types de Service : ClusterIP, NodePort et LoadBalancer. Il montre le chemin du trafic depuis l’extérieur jusqu’aux Pods, en passant par kube-proxy et les EndpointSlices qui indiquent quels Pods sont prêts.

    Réseau · diagramme 3 sur 6

    Services et routage

    ClusterIP, NodePort et LoadBalancer : comment le trafic arrive aux Pods via kube-proxy et les EndpointSlices.

  • Diagramme avec plusieurs nœuds marqués de taints et des Pods avec et sans tolerations. Il indique le résultat de chaque combinaison selon l’effet du taint : NoSchedule, PreferNoSchedule et NoExecute.

    Scheduling · diagramme 4 sur 6

    Taints et tolerations

    Comment diriger des Pods vers — ou loin de — certains nœuds, avec les trois effets possibles d’un taint.

  • Diagramme de l’architecture d’observabilité : les Pods exposent des métriques que Prometheus collecte en mode pull, les logs voyagent en mode push vers Loki et les traces se regroupent en spans. Les trois flux convergent vers Grafana comme couche de visualisation.

    Observabilité · diagramme 5 sur 6

    Métriques, logs et traces

    Les trois piliers se collectent séparément et convergent vers Grafana, avec Prometheus, Loki et les traces.

  • Diagramme de la boucle de réconciliation d’un opérateur : le watch notifie un changement dans la ressource, l’opérateur relit l’état désiré et l’état réel, agit pour les rapprocher et écrit le résultat dans le status. La notification et la lecture de l’état sont deux flèches distinctes.

    Extensibilité · diagramme 6 sur 6

    La boucle de réconciliation

    Pourquoi un opérateur n’agit pas sur la notification mais relit : peu importe que deux notifications arrivent ensemble ou que l’un se perde.

1 / 6

Comment se lit une page

239 questions, au pied du YAML

Presque tous les livres techniques posent le manifeste, expliquent trois champs et passent à la suite. Les neuf autres restent là. Ici, sous chaque manifeste vient ce qu’on se demande en le lisant pour la première fois, avec la réponse : pas un test en fin de chapitre, mais la réponse là où naît le doute. Quatre pages de l’édition imprimée espagnole, telles qu’elles sortent de l’imprimerie.

  • Page 48 de l’édition imprimée espagnole. En haut, la fin du manifeste YAML du Pod web. Au milieu, l’explication champ par champ : apiVersion, kind, metadata.name, metadata.namespace, metadata.labels, spec et spec.containers. En bas, trois questions en gras avec leur réponse : pourquoi apiVersion vaut v1 et non apps/v1, ce qui se passe si le namespace n’est pas indiqué, et si deux objets peuvent avoir le même name.

    Chapitre 4 · Objets de Kubernetes · page 48

    Le premier manifeste, ligne par ligne

    Douze lignes de YAML expliquées champ par champ, puis trois questions : pourquoi apiVersion vaut v1 et non quelque chose comme apps/v1 ? · que se passe-t-il si je n’indique pas le namespace ? · puis-je avoir deux objets avec le même name ?

  • Page 49 de l’édition imprimée espagnole. En haut, deux questions avec réponse sur le status et les labels. Ensuite, la section Namespaces, avec les quatre Namespaces que Kubernetes fournit de série, le manifeste YAML du Namespace tienda, et la question de savoir quelles ressources ne sont pas namespaced.

    Chapitre 4 · Objets de Kubernetes · page 49

    Les Namespaces, et ce qu’ils n’isolent pas

    Celle sur laquelle le plus de gens se trompent est sur cette page : les Namespaces isolent-ils le trafic réseau ? Non. Ils séparent des noms et des permissions, pas des paquets ; pour isoler le trafic, il faut une NetworkPolicy, qui arrive trois chapitres plus loin.

  • Page 132 de l’édition imprimée espagnole. En haut, la fin d’un manifeste qui réserve 2 CPU et 4 GiB. Ensuite, trois questions avec réponse sur où est l’erreur si le manifeste ne donne aucune erreur, pourquoi c’est important s’il reste de la place dans le cluster, et pourquoi ne pas corriger les chiffres à la main. En bas, le manifeste YAML du VerticalPodAutoscaler du Deployment holgazan.

    Chapitre 6 · Mise à l’échelle · page 132

    Le manifeste qui ne donne aucune erreur

    Il demande 2 CPU et 4 GiB, et en utilise un dixième. Pas d’événement rouge ni de Pod en Pending : juste un tiers du quota du Namespace dépensé pour du vent. C’est l’erreur la plus chère de Kubernetes précisément parce qu’elle ne ressemble pas à une erreur.

  • Page 261 de l’édition imprimée espagnole. Manifeste YAML d’un PodDisruptionBudget pour le Deployment web, suivi de deux questions avec réponse : pourquoi le PDB ne se déclare pas dans le Deployment, et ce qui se passe si l’on met minAvailable égal au nombre de répliques.

    Chapitre 12 · Scheduling · page 261

    La protection qui bloque la maintenance

    Que se passe-t-il si je mets minAvailable: 3 avec seulement 3 répliques ? Tu bloques toute éviction volontaire, drainage des nœuds compris, et tu finis avec des mises à niveau de cluster coincées.

1 / 4

Le chapitre Workloads compte 45 questions et le chapitre Sécurité 42. Les 239 sont réparties dans les quinze chapitres, toujours collées au manifeste qui les provoque.

La partie pratique

Comment fonctionnent les laboratoires

  1. Étape 1

    Lis le chapitre

    Le concept expliqué avec son diagramme et ses exemples, sans rien tenir pour acquis.

  2. Étape 2

    Ouvre le laboratoire

    Un vrai cluster dans le navigateur, prêt en quelques secondes. Rien à installer sur ta machine.

  3. Étape 3

    Répare le cluster cassé

    Tu diagnostiques, tu répares et le laboratoire vérifie ta solution. Tu apprends en faisant, pas en mémorisant.

Une pause

Ce que disent les composants du cluster

Ici, pas d’avis de lecteurs : ce sont les composants de Kubernetes qui signent, et ça fait des années qu’ils en bavent. C’est une blague, mais chaque plainte est vraie.

  • « Ça fait des années que je suis la seule porte vers etcd et personne ne me comprenait. Après ce livre, même les nouveaux Pods savent me demander les choses par leur nom. »
    kube-apiserver, gardien du cluster
  • « Moi, je garde tout, mais expliquer le consensus Raft était impossible. Le chapitre des fondamentaux raconte enfin mon histoire sans perdre une seule donnée. »
    etcd, mémoire du cluster
  • « Avant, je plaçais les Pods à l’aveugle et on m’accusait de tout. Maintenant, les lecteurs comprennent mes affinités, taints et tolerations… et même le défi de m’éteindre. »
    kube-scheduler, celui qui décide où tu vis
  • « Je redémarre des conteneurs toute la nuit sans que personne me remercie. Ce livre explique si bien mes probes qu’on me traite déjà mieux. »
    kubelet, vigile de chaque nœud
  • « Traduire des noms de Services en IP était ma croix silencieuse. Avec le chapitre Réseau, ils résolvent enfin mes doutes avant que je résolve les leurs. »
    CoreDNS, le carnet d’adresses du cluster
1 / 5

Gratuit, maintenant

Télécharge le début du livre

Abonne-toi au blog et tu reçois le début du livre en entier : « Avant de commencer », le chapitre Architecture de Kubernetes et l’Annexe D : le cluster vu de l’intérieur.

Trente et une pages et les huit diagrammes, tels qu’ils apparaissent dans le livre (pour l’instant, les pages de l’édition espagnole ; le PDF français les remplacera). Ce n’est pas un extrait tronqué : c’est par là qu’on commence à le lire et là qu’on finit de comprendre la salle des machines.

C’est la façon la plus honnête de savoir si le livre te sera utile avant de payer quoi que ce soit.

Si le formulaire ne se charge pas, abonne-toi sur blog.javivela.dev.

Avant de commencer

Questions fréquentes

Non. Le livre commence par les fondamentaux des conteneurs et de l’orchestration avant de toucher à Kubernetes, et ne tient rien pour acquis.

Rien. Chaque laboratoire démarre un vrai cluster Kubernetes dans le navigateur ; il te faut seulement une connexion et un compte sur iximiuz Labs.

Oui. Il est pensé aussi pour ceux qui utilisent la technologie au quotidien et veulent vraiment comprendre ce qui se passe en dessous, avec les diagrammes et les challenges comme filet de sécurité.

Les deux. La partie pratique est la même dans les deux formats, et elle est en plus en accès public : tu peux ouvrir le guide de la partie pratique sans avoir le livre. L’édition Kindle et l’édition papier sont toutes deux sur Amazon.fr et Amazon.com ; depuis un autre pays, le papier se commande sur Amazon.com avec livraison internationale.

Non. La partie pratique est en accès public et gratuit, et n’exige aucun achat supplémentaire. Elle est hébergée sur iximiuz Labs.

Les 15 chapitres et les 5 annexes, oui. Il n’y a qu’un seul bloc qui existe uniquement comme laboratoire et n’a pas de chapitre : le défi final, et il est signalé dans le programme. L’extensibilité, elle, a bien son chapitre, le 14 : le livre définit la CRD et explique ce que fait un opérateur ; le laboratoire est l’endroit où tu l’écris en entier, en Go.

Le livre est l’édition 1.37. Kubernetes publie trois versions par an, donc aucun livre ne sera jamais sur la dernière : c’est pour ça qu’il inclut l’annexe C, qui recense chapitre par chapitre l’état de chaque fonctionnalité et depuis quelle version elle existe, pour que tu puisses vérifier d’un coup d’œil si ce que tu lis est encore valable dans ton cluster. Ce qu’apporte la 1.37 est résumé dans les nouveautés de Kubernetes 1.37 (en espagnol), et les corrections ultérieures sont publiées sur la page des errata.

À propos de l’auteur

Javier Vela Aylón

Développeur .NET devenu Senior Software & Platform Engineer, avec plus de 20 ans à construire et à maintenir des plateformes. Certifié sur Azure et dans l’écosystème CNCF, et speaker chez DotNetters.

J’écris sur DevOps, Azure, AWS, CI/CD, Kubernetes, les conteneurs et l’architecture sur blog.javivela.dev.

LinkedIn GitHub @jvela

Code

Tous les manifestes du livre, sur GitHub

Le dépôt réunit les YAML, les exemples et l’opérateur en Go tels qu’ils apparaissent dans les chapitres et dans les laboratoires. Clone-le, casse-le et envoie une pull request si tu trouves quelque chose à améliorer.

Voir le dépôt sur GitHub Partie pratique Errata du livre Bibliographie (en espagnol)

Kubernetes 101

D’un Pod isolé à un système que tu comprends

375 pages, 15 chapitres, 5 annexes et 55 laboratoires sur un vrai cluster. Bâti sur Kubernetes 1.37, la version de référence du livre.

Lire gratuitement le début du livre