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