tuto: Update k8s

tutorial/k8s/discover.md

@@ -75,26 +75,42 @@ Pour le moment, nous n'avons qu'un seul service, il s'agit de l'API Kubernetes.
 
 Jetons un œil aux conteneurs actifs :
 
-```bash
-kubectl get pods
+```
+42sh$ kubectl get pods
+No resources found in default namespace.
 ```
 
-Regardons maintenant les `namespaces` :
+A priori, nous n'avons rien lancé, donc cette commande ne nous
+retourne effectivement rien. Mais on nous précise que notre vue est
+limitée à l'espace par défaut.
+
+Voyons s'il n'y a pas d'autres `namespaces` :
 
 ```bash
 kubectl get namespaces
 ```
 
-On l'a vu, les *namespaces* ici désignent des espaces de noms qui n'ont rien à
-voir avec les *namespaces* de Linux. Regardons par exemple les conteneurs d'un
-autre espace de noms :
+::::: {.warning}
+
+Les *namespaces* ici désignent des espaces de noms qui n'ont rien à voir avec
+les *namespaces* de Linux. Il s'agit pour Kubernetes d'un groupe d'objets, qui
+permet notamment de mieux s'y retrouver.
+
+:::::
+
+Regardons par exemple les conteneurs d'un autre espace de noms :
 
 ```bash
-kubectl -n kube-system get pods
+42sh$ kubectl -n kube-system get pods
+NAME                                         READY   STATUS    RESTARTS   AGE
+coredns-565d847f94-6f7ln                     1/1     Running   0          14m
+etcd-kind-control-plane                      1/1     Running   0          14m
+kindnet-2gwlp                                1/1     Running   0          13m
+...
 ```
 
-Eh oui ! De nombreux services de base pour Kubernetes tournent dans des
-conteneurs, gérés par lui-même... notamment :
+Eh oui ! De nombreux services de base de Kubernetes tournent dans des
+conteneurs... qu'il gèren lui-même ! Notamment :
 
 - `etcd` : notre base de données clef/valeur,
 - `kube-apiserver` : l'API REST avec qui communique `kubectl`,
@@ -119,9 +135,9 @@ Nous devons lancer un *pod* (qui ne contiendra qu'un seul conteneur).
 kubectl run pingpong --image alpine ping 1.1.1.1
 ```
 
-`kubectl` doit nous indiquer nous qu'un *pod* a été créé.
+`kubectl` doit nous indiquer en retour qu'un *pod* a été créé.
 
-Si l'on affiche la liste des *pod*s, vous devriez avoir quelque chose qui
+Si l'on affiche la liste des *pod*s, nous devrions avoir quelque chose qui
 ressemble à cela :
 
 ```
@@ -193,7 +209,7 @@ Pas de panique, on peut très facilement le décortiquer :
 Les tâches de déploiement (*deployment.apps*) sont des ressources de
 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.14 vers alpine
+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.
 
@@ -225,7 +241,7 @@ la demande.
 Et que se passe-t-il alors, si l'on tue un *pod* ?
 
 ```bash
-kubectl delete pod pingpong-yyyy
+kubectl delete pod pingpong-yyyy-zzz
 ```
 
 Cela supprime bien un *pod*, mais un autre est relancé instantanément car le