New spelling fixes

tutorial/k8s/discover.md

@@ -26,7 +26,7 @@ Les `type`s que vous pouvez découvrir sont ceux que l'on a vu à la
 section précédente : `node`, `pod`, ...
 
 La commande `describe` permet d'afficher l'état tel qu'il est attendu
-et tel qu'il est actuellement (cela permet de se rendre lorsque les
+et tel qu'il est actuellement (cela permet de se rendre compte lorsque les
 deux divergent).
 
 
@@ -110,7 +110,7 @@ kindnet-2gwlp                                1/1     Running   0          13m
 ```
 
 Eh oui ! De nombreux services de base de Kubernetes tournent dans des
-conteneurs... qu'il gèren lui-même ! Notamment :
+conteneurs... qu'il gère lui-même ! Notamment :
 
 - `etcd` : notre base de données clef/valeur,
 - `kube-apiserver` : l'API REST avec qui communique `kubectl`,
@@ -166,7 +166,7 @@ kubectl logs -f pingpong
 Notez ici l'option -f qui permet de suivre les logs en direct.
 
 
-Notre premier test ayant réussi, nous pouvons arrêter de DDos Cloudflare :
+Notre premier test ayant réussi, nous pouvons arrêter de DDoS Cloudflare :
 
 ```bash
 kubectl delete pods pingpong
@@ -211,16 +211,16 @@ haut niveau et sont là pour s'assurer que les migrations se font en douceur :
 elles vont permettre de basculer progressivement les *pod*s d'une version X à une
 version Y (par exemple si l'on change notre ping d'alpine 3.16 vers alpine
 edge), mais éventuellement de revenir sur la version X si besoin, en cours de
-migration. Elles délèguent ensuite aux *replicatsets* la gestion des *pod*s.
+migration. Elles délèguent ensuite aux *replicasets* la gestion des *pod*s.
 
-Le *replicatset* est là pour indiquer le nombre de *pod*s que l'on désire et
+Le *replicaset* est là pour indiquer le nombre de *pod*s que l'on désire et
 s'assurer que le nombre de *pod*s actuellement lancé est bien en adéquation avec
 le nombre de *pod*s attendu.
 \
 
 Pour résumer : `kubectl` a créé une tâche de déploiement
-`deploy/pingpong`. Cette tâche de déploiement a créé elle-même un *replicatset*
-`rs/pingpong-xxxx`. Ce *replicatset* a créé un *pod* `po/pingpong-yyyy`.
+`deploy/pingpong`. Cette tâche de déploiement a créé elle-même un *replicaset*
+`rs/pingpong-xxxx`. Ce *replicaset* a créé un *pod* `po/pingpong-yyyy`.
 
 
 #### Passage à l'échelle : facile ?
@@ -232,8 +232,8 @@ kubectl scale deploy/pingpong --replicas 3
 ```
 
 À ce stade, comme nous ne modifions que le nombre de replicats, Kubernetes va
-tout simplement propager ce nombre au *replicatset* existant. Puis, le
-*replicatset* voyant un décalage entre le nombre de *pod*s attendus et le nombre
+tout simplement propager ce nombre au *replicaset* existant. Puis, le
+*replicaset* voyant un décalage entre le nombre de *pod*s attendus et le nombre
 de *pod*s en cours d'exécution, il va en lancer de nouveaux, afin de répondre à
 la demande.
 \
@@ -245,11 +245,11 @@ kubectl delete pod pingpong-yyyy-zzz
 ```
 
 Cela supprime bien un *pod*, mais un autre est relancé instantanément car le
-*replicatset* constate une différence dans le nombre attendu.
+*replicaset* constate une différence dans le nombre attendu.
 
 Si nous voulons arrêter de DDoS Google/Cloudflare, il ne s'agit pas de tuer
 chacun des *pod*s un par un, car de nouveaux seraient créés par le
-*replicatset*. Si l'on supprime le *replicatset*, la tâche de déploiement en
+*replicaset*. Si l'on supprime le *replicaset*, la tâche de déploiement en
 recréera un similaire (avec de nouveaux *pod*s).
 
 Pour arrêter nos conteneurs, il convient donc de supprimer la tâche de

tutorial/k8s/overview.md

@@ -4,7 +4,7 @@ Vue d'ensemble de Kubernetes
 *Kubernetes* (prononcé Ku-ber-né-tice[^prononciation-k8s] en grec) est un
 système *open source* d'orchestration et de gestion de conteneurs. C'est-à-dire
 qu'il se charge de faire coller constamment la liste des conteneurs qu'il voit
-vivant aux spécifications qu'on lui aura demandées.
+vivants aux spécifications qu'on lui aura demandées.
 
 [^prononciation-k8s]: <https://github.com/kubernetes/kubernetes/issues/44308>
 
@@ -37,7 +37,7 @@ d’une série de nœuds *workers*.
 
 Le(s) *control-plane(s)* sont en charge de prendre des décisions globales sur
 le déroulement des opérations du cluster : cela va de la détection d'anomalies
-sur le cluster ou encore le traiter d'événements et l'organisation de leur
+sur le cluster ou encore le traitement d'événements et l'organisation de leur
 réponse, ...
 
 On retrouve sur ces nœuds centraux les composants suivants :
@@ -52,7 +52,7 @@ L'ordonnanceur
   disponibles.
 
 Les contrôleurs
-: Ils vont contrôler l'état des différents composants déployées au sein du
+: Ils vont contrôler l'état des différents composants déployés au sein du
   cluster, pour s'assurer d'être dans l'état désiré. Il y a en fait plusieurs
   contrôleurs ayant chacun la responsabilité de veiller sur une partie des
   objets, ainsi que le `cloud-controller-manager` lorsque le cluster se trouve
@@ -65,11 +65,11 @@ Les contrôleurs
 \
 
 
-Chaque nœud (généralement, le nœud *master* est également *worker*) est utilisé
+Chaque nœud (généralement, le nœud *control-plane* est également *worker*) est utilisé
 via deux composants :
 
 `kubelet`
-: C'est l'agent qui va se charger de créer les conteneurs et les manager, afin
+: C'est l'agent qui va se charger de créer les conteneurs et les gérer, afin
   de répondre aux spécifications demandées par les *control-planes*.
 
 `kube-proxy`
@@ -109,14 +109,14 @@ supprimer ou de vérifier qu'une interface va bien.
 
 Ainsi, à la création d'un conteneur, Kubernetes va laisser aux plugins CNI le
 loisir d'ajouter les interfaces réseaux adéquates, d'allouer l'adresse IP, de
-configurer les routes, les règles de pare-feu, ... quelque soit
+configurer les routes, les règles de pare-feu, ... quelle que soit
 l'infrastructure et la complexité du réseau utilisé derrière.
 \
 
 Terminons en ajoutant qu'un serveur DNS faisant autorité est nécessaire pour
 que, de la même manière que Docker, il soit possible d'accéder aux autres
 conteneurs via leur nom (sans qu'il ne soit nécessaire de le déclarer sur un
-serveur de noms public). Il n'y a pas de projet de porté par Kubernetes pour
+serveur de noms public). Il n'y a pas de projet porté par Kubernetes pour
 cela, mais cette tâche est généralement assurée par
 [CoreDNS](https://coredns.io/).
 

tutorial/k8s/setup.md

@@ -17,7 +17,7 @@ leurs infrastructures, choisissent de passer par un prestataire. L'entreprise
 délègue donc la gestion de son/ses cluster(s) à une autre entreprise, dont
 c'est le cœur de métier. La plupart du temps, il va s'agir d'Amazon (via
 [Elastic Kubernetes Service](https://aws.amazon.com/fr/eks/)), d'Azure
-[Kubernetes
+([Kubernetes
 Service](https://azure.microsoft.com/fr-fr/services/kubernetes-service/)) ou
 Google ([Kubernetes Engine](https://cloud.google.com/kubernetes-engine/)), mais
 d'autres acteurs plus petits existent aussi
@@ -38,7 +38,7 @@ fonctionne.\
 Chaque distribution de *Kubernetes* aura donc pris soin de mettre à disposition
 des composants pour un usage plus ou moins spécifique. En dehors des composants
 strictement nécessaires qui ne changent pas, on verra d'une distribution à
-l'autre des choix quant au moteur d'exécution de conteneurs (tantot CRI-O,
+l'autre des choix quant au moteur d'exécution de conteneurs (tantôt CRI-O,
 Containerd, KataContainers, ...), le réseau sera géré par une brique spécifique
 (Flannel, Calico, Canal, Wave, ...), le stockage peut également faire l'objet
 de choix.\
@@ -147,8 +147,9 @@ Server Version: Version.Info{Major:"1", Minor:"21", GitVersion:"v1.25.3", [...]
 ```
 </div>
 
-Par défaut, `kubectl` va tenter de contacter le port local 2375, `kind` aura
-pris soin de l'exposer pour vous au moment de la création du cluster.
+Par défaut, `kubectl` va utiliser le fichier `~/.kube/config` pour contacter
+l'API du cluster, `kind` aura pris soin de le configurer pour vous au moment
+de la création du cluster.
 
 ::::: {.warning}