tuto: Update k8s

tutorial/k8s/Makefile

@@ -1,6 +1,6 @@
 include ../pandoc-opts.mk
 
-SOURCES_TUTO	= tutorial-el.md setup.md intro-srs.md intro.md overview.md discover.md discover-cmd-virli.md discover2.md run.md run-cmd-virli.md run2.md scaling.md rendu.md
+SOURCES_TUTO	= tutorial-el.md chapter.md overview.md setup.md intro-srs.md intro.md discover.md discover-cmd-virli.md discover2.md run.md run-cmd-virli.md run2.md scaling.md rendu.md
 
 
 all: tutorial.pdf

tutorial/k8s/chapter.md

@@ -0,0 +1,29 @@
+Tour d'horizon de Kubernetes
+============================
+
+Nous avons abordé plusieurs aspects des conteneurs qui les rendent
+particulièrement attrayants dans un environnement de production :
+principalement le fait de cloisonner les environnements de telle sorte
+qu’un développeur peut concevoir lui-même l’environnement d’exécution
+de son application, laissant à l’équipe d’administrateurs système le
+soin de gérer les machines et le système de base.
+
+Docker est désormais considéré comme un projet mature et est digne
+d’être utilisé en production.  Bien qu’il soit acceptable de déployer
+des conteneurs via des outils de provisionnement tels qu’Ansible ou
+Salt, on peut faire beaucoup mieux.
+
+Kubernetes se place comme un orchestrateur de conteneur : il peut
+piloter, sur une grappe de machines, le lancement, le monitoring et la
+mise à jour de conteneurs. On peut ajouter ou retirer des machines au
+cluster, il va toujours faire en sorte de garder l’équilibre qu’on lui
+a demandé de conserver.
+
+C’est une solution qui est particulièrement adaptée au monde des
+entreprises géantes, mais elle vient avec une courbe d’apprentissage
+particulièrement abrupte. Il faut bien veiller à jauger les avantages
+et les inconvénients d’une telle solution avant de la choisir, car si
+l’outil promet de résoudre des problèmes que vont rencontrer des très
+gros sites web à fort trafic, cela peut demander aussi beaucoup
+d’investissements tant humains que financiers pour des entreprises qui
+voudraient juste profiter de l’outil sans réel besoin.

tutorial/k8s/discover-cmd-alpo.md

@@ -1,3 +1,3 @@
 ```bash
-kubectl create -f https://supplements.alpo.tf/493960009/insecure-dashboard.yaml
+kubectl create -f https://supplements.alpo.tf/493960009/dashboard-insecure.yaml
 ```

tutorial/k8s/discover-cmd-virli.md

@@ -1,3 +1,3 @@
 ```bash
-kubectl create -f https://virli.nemunai.re/insecure-dashboard.yaml
+kubectl create -f https://virli.nemunai.re/dashboard-insecure.yaml
 ```

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 à
+::::: {.warning}
-voir avec les *namespaces* de Linux. Regardons par exemple les conteneurs d'un
+
-autre espace de noms :
+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
+Eh oui ! De nombreux services de base de Kubernetes tournent dans des
-conteneurs, gérés par lui-même... notamment :
+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

tutorial/k8s/discover2.md

@@ -10,7 +10,7 @@ on n'utilisera pas cette recette.
 Regardons où nous pouvons contacter notre dashboard :
 
 ```bash
-$ kubectl get svc
+$ kubectl -n kubernetes-dashboard get svc
 NAME         TYPE        CLUSTER-IP    EXTERNAL-IP   PORT(S)        AGE
 dashboard    NodePort    10.96.78.69   <none>        80:31505/TCP   3m10s
 kubernetes   ClusterIP   10.96.0.1     <none>        443/TCP        6m51s
@@ -33,11 +33,12 @@ mais dans différents conteneurs Docker, nous ne pouvons pas accéder à
 configuration. Il va donc falloir indiquer à Kubernetes que l'on désire
 utiliser un port spécifique pour exposer le tableau de bord.
 
-Pour ce faire, éditons le fichier `insecure-dashboard.yaml`, pour ajouter, dans
+Pour ce faire, éditons le fichier `dashboard-insecure.yaml`, pour ajouter, dans
 la partie `Service` un *node port* plus spécifique :
 
 ```yaml
-  - port: 80
+  - name: shared
+    port: 80
     protocol: TCP
     targetPort: 80
     nodePort: 30002
@@ -47,7 +48,7 @@ Maintenant, nous n'allons pas recréer un nouveau dashboard : nous allons
 simplement « appliquer » la nouvelle configuration :
 
 ```bash
-kubectl apply -f my-insecure-dashboard.yaml
+kubectl apply -f my-dashboard-insecure.yaml
 ```
 
 En voyant la divergence entre la réalité et la configuration demandée,

tutorial/k8s/intro-book.md

@@ -1,5 +1,3 @@
-\newpage
-
 Présentation du fil rouge
 -------------------------
 

tutorial/k8s/intro.md

@@ -48,7 +48,7 @@ docker-compose up
 </div>
 
 Une fois le `docker-compose` lancé, nous devrions pouvoir accéder à l'interface
-de chronograf pour voir l'avancement de recherche de pépites :
+de `chronograf` pour voir l'avancement de recherche de pépites :
 
 <http://localhost:8888/sources/1/dashboards/1>
 

tutorial/k8s/overview.md

@@ -1,14 +1,14 @@
 Vue d'ensemble de Kubernetes
 ----------------------------
 
-*Kubernetes* (prononcé Ku-ber-né-tice[^prononciation-k8s] en grec) est
+*Kubernetes* (prononcé Ku-ber-né-tice[^prononciation-k8s] en grec) est un
-un système open source d'orchestration et de gestion de
+système *open source* d'orchestration et de gestion de conteneurs. C'est-à-dire
-conteneurs. C'est-à-dire qu'il se charge de coller constamment aux
+qu'il se charge de faire coller constamment la liste des conteneurs qu'il voit
-spécifications qu'on lui aura demandées.
+vivant aux spécifications qu'on lui aura demandées.
 
 [^prononciation-k8s]: <https://github.com/kubernetes/kubernetes/issues/44308>
 
-Ce projet est l'aboutissement de plus d'une dizaine d'années
+Ce projet est l'aboutissement de plus d'une quinzaine d'années
 d'expérience de gestion de conteneurs applicatifs chez Google
 (rappelons que c'est eux qui ont poussé de nombreuses technologies
 dans le noyau Linux, notamment les *cgroups*, ...).
@@ -32,9 +32,15 @@ différentes méthodes ...
 
 ![Architecture de Kubernetes](k8s-archi.png)
 
-Un cluster Kubernetes est composé d’un (ou plusieurs) nœuds *master*, et d’une série de *workers*.
+Un cluster Kubernetes est composé d’un (ou plusieurs) nœuds *control-plane*, et
+d’une série de nœuds *workers*.
 
-Sur le(s) *master(s)*, on retrouve les composants suivants :
+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
+réponse, ...
+
+On retrouve sur ces nœuds centraux les composants suivants :
 
 API HTTP
 : On distingue plusieurs API, elles sont toutes utilisées pour communiquer avec
@@ -42,11 +48,15 @@ API HTTP
 
 L'ordonnanceur
 : Il a la responsabilité de monitorer les ressources utilisées sur chaque nœud
-  et de répartir les conteneurs en fonction des ressources disponibles.
+  et de répartir les nouveaux conteneurs en fonction des ressources
+  disponibles.
 
-Le contrôleur
+Les contrôleurs
-: Il va contrôler l'état des applications déployées au sein du cluster, pour
+: Ils vont contrôler l'état des différents composants déployées au sein du
-  s'assurer d'être dans l'état désiré.
+  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
+  chez un hébergeur cloud compatibles.
 
 **`etcd`**
 : Il s'agit d'une base de données clef/valeur, supportant la
@@ -60,56 +70,24 @@ via deux composants :
 
 `kubelet`
 : C'est l'agent qui va se charger de créer les conteneurs et les manager, afin
-  de répondre aux spécifications.
+  de répondre aux spécifications demandées par les *control-planes*.
 
 `kube-proxy`
-: Ce programme va servir de load-balancer pour se connecter aux pods.
+: Ce programme va servir de load-balancer pour se connecter aux conteneurs. Il
+  se base généralement sur le système de filtrage de paquet du système et est
+  donc amené à l'altérer.
 
-Sans oublier le moteur de conteneurs (généralement Docker), qui va
+Sans oublier le moteur de conteneurs (généralement [CRI-O](https://cri-o.io/)),
-effectivement se charger de lancer les conteneurs demandés par `kubelet`.
+qui va effectivement se charger de lancer les conteneurs demandés par
+`kubelet`.
 \
 
 
 Évidemment, chaque élément de l'architecture est malléable à souhait, c'est la
 raison pour laquelle il peut être très difficile de mettre en place une
-architecture Kubernetes : avec ou sans haute-disponibilité, un nœud master
+architecture Kubernetes : avec ou sans haute-disponibilité, avec le bon nombre
-dédié au contrôle, avec un moteur de conteneur exotique (`rkt`, `ctr`, ...).
+de nœuds décideurs, avec un gestionnaire de réseau qui correspond aux besoins,
-
+avec un moteur de conteneur exotique (`rkt`, `ctr`, ...), etc.
-
-### *Resources*
-
-Avec Docker, nous avons eu l'habitude de travailler avec des objets (images,
-containers, networks, volumes, secrets, ...). Au sein de Kubernetes, cela
-s'appelle des *resources* et elles sont très nombreuses.
-
-Parmi les plus courantes, citons les types (désignés *Kind* dans l'API, rien à
-voir avec le projet `kind` au début du sujet) suivants :
-
-node
-: il s'agit d'une machine de notre cluster (elle peut être physique ou
-  virtuelle).
-
-pod
-: un groupe de conteneurs travaillant ensemble. Il s'agit de la ressource que
-  l'on déploie sur un *node*. Les conteneurs au sein d'un *pod* ne peuvent pas
-  être séparés pour travailler sur deux *nodes* différents.
-
-service
-: c'est un point de terminaison (*endpoint*), stable dans le temps, sur lequel
-  on peut se connecter pour accéder à un ou plusieurs
-  conteneurs. Historiquement, appelés portails/*portals*, on les retrouve
-  encore quelques fois désignés ainsi dans de vieux articles.
-
-namespace
-: à ne pas confondre avec les *namespaces* Linux. Ici il s'agit d'espaces de
-  noms divers, pour Kubernetes.
-
-secret
-: comme `docker secret`, il s'agit d'un moyen de passer des données sensibles à
-  un conteneur.
-
-Pour voir la liste complète des *resources*, on utilise : `kubectl
-api-resources`.
 
 
 ### Modèle réseau
@@ -120,22 +98,66 @@ tous les conteneurs. Il ne doit pas y avoir de NAT, que ce soit entre les
 élément, sans qu'il y ait de routage.
 
 C'est un modèle assez simpliste au premier abord, mais en raison de la
-nécessité de faire un minimum de filtrage, de nombreuses extensions viennent
+diversité des infrastructures et des besoins différents de chacun, de
-compléter ce schéma...
+nombreuses extensions viennent compléter ce schéma.
 
-Chaque plugin implémente la [spécification
+La [spécification
 CNI](https://github.com/containernetworking/cni/blob/master/SPEC.md#network-configuration)
-(Container Network Interface). On trouve donc autant de plugins qu'il y a de
+(pour Container Network Interface) définit l'interface commune que les plugins
-besoins en termes de réseau.
+doivent gérer : il s'agit de pouvoir ajouter et configurer une interface, la
+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'allouer l'adresse IP, d'ajouter les interfaces réseaux adéquates, de
+loisir d'ajouter les interfaces réseaux adéquates, d'allouer l'adresse IP, de
-configurer les routes, les règles de pare-feu, ...
+configurer les routes, les règles de pare-feu, ... quelque 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
+cela, mais cette tâche est généralement assurée par
+[CoreDNS](https://coredns.io/).
+
+
+### *Resources*
+
+Avec Docker, nous avons eu l'habitude de travailler avec des objets (images,
+containers, networks, volumes, secrets, ...). Au sein de Kubernetes, cela
+s'appelle des *resources* et elles sont très nombreuses.
+
+Parmi les plus courantes, citons les types (désignés *Kind* dans l'API, rien à
+voir avec le projet `kind` dont on va parler par ailleurs) suivants :
+
+node
+: il s'agit d'une machine de notre cluster (elle peut être physique ou
+  virtuelle).
+
+pod
+: un groupe de conteneurs travaillant ensemble. C'est la ressource que l'on
+  déploie sur un *node*. Les conteneurs au sein d'un *pod* ne peuvent pas être
+  séparés pour travailler sur deux *nodes* différents.
+
+service
+: c'est un point de terminaison (*endpoint*), stable dans le temps, sur lequel
+  on peut se connecter pour accéder à un ou plusieurs
+  conteneurs. Historiquement, appelés portails/*portals*, on les retrouve
+  encore quelques fois désignés ainsi dans de vieux articles.
+
+namespace
+: à ne pas confondre avec les *namespaces* Linux. Ici il s'agit d'espaces
+  nommés que Kubernetes va utiliser pour regrouper des objets ensembles.
+
+secret
+: comme `docker secret`, il s'agit d'un moyen de passer des données sensibles à
+  un conteneur.
+
+Pour voir la liste complète des *resources*, on utilise : `kubectl
+api-resources`.
 
 
 ### Pour aller plus loin
 
 * La documentation de Kubernetes : <https://kubernetes.io/docs/>
-* A Reference Architecture for Deploying WSO2 Middleware on Kubernetes :\
+* Les spécifications CNI : <https://github.com/containernetworking/cni/blob/main/SPEC.md>
-  <https://medium.com/containermind/a-reference-architecture-for-deploying-wso2-middleware-on-kubernetes-d4dee7601e8e>
-* Les spécifications CNI : <https://github.com/containernetworking/cni/blob/master/SPEC.md#network-configuration>

tutorial/k8s/rendu.md

@@ -3,41 +3,21 @@
 Rendu
 =====
 
-Modalités de rendu
+Arborescence attendue
-------------------
-
-Un service automatique s'occupe de réceptionner vos rendus, de faire des
-vérifications élémentaires et de vous envoyer un accusé de réception (ou de
-rejet).
-
-Ce service écoute sur l'adresse <ανδροππήςρε@nemunai.re>. C'est donc à cette adresse
-et exclusivement à celle-ci que vous devez envoyer vos rendus. Tout rendu
-envoyé à une autre adresse et/ou non signé et/ou reçu après la correction ne
-sera pas pris en compte.
-
-Afin d'orienter correctement votre rendu, ajoutez une balise `[TP6]` au sujet
-de votre courriel. N'hésitez pas à indiquer dans le corps du courriel votre
-ressenti et vos difficultés ou bien alors écrivez votre meilleure histoire
-drôle si vous n'avez rien à dire.
-
-Mais n'oubliez pas de répondre au [sondage](https://virli.nemunai.re/quiz/16)
-pour me permettre d'améliorer ce cours.
-
-
-Tarball
 -------
 
-Tous les exercices de ce TP sont à placer dans une tarball (pas d'archive ZIP,
+Tous les fichiers identifiés comme étant à rendre sont à placer dans un dépôt
-RAR, ...).
+Git privé, que vous partagerez avec [votre
+professeur](https://gitlab.cri.epita.fr/nemunaire/).
 
-Voici une arborescence type :
+Voici une arborescence type (vous pourriez avoir des fichiers supplémentaires) :
 
 <div lang="en-US">
 ```
-login_x-TP6/my-cluster.yml
+./my-kind-cluster.yml
-login_x-TP6/my-dashboard.yaml
+./my-dashboard.yaml
-login_x-TP6/influxdb.yml       # values.yml avec Helm ou le fichier passé à kubectl -f
+./influxdb.yml       # values.yml avec Helm ou le fichier passé à kubectl -f
-login_x-TP6/chronograph.yml
+./chronograph.yml
-login_x-TP6/daemonset-rng.yml
+./daemonset-rng.yml
 ```
 </div>

tutorial/k8s/setup.md

@@ -1,21 +1,23 @@
 Mise en place
 -------------
 
-La mise en place d'un cluster Kuernetes est une opération qui peut s'avérer
+La mise en place d'un cluster Kubernetes est une opération qui peut s'avérer
-très longue et complexe, car elle nécessite l'installation et la configuration
+très longue et complexe, car comme nous l'avons vu, elle nécessite
-de nombreux composants avant de pouvoir être utilisé pleinement.
+l'installation et la configuration de nombreux composants avant de pouvoir être
+utilisé pleinement.
 
-Cette opération n'étant pas très palpitante (c'est beaucoup de lecture de
+Cette installation n'étant pas très palpitante (c'est beaucoup de lecture de
 documentations et d'heures passées à essayer de faire tomber en marche tous les
 composants d'un seul coup), nous ne la verrons pas ici.
 
-D'ailleurs, dans le milieu professionnel, il est plutôt rare de voir des
+D'ailleurs, dans les milieux professionnels, il est plutôt rare de voir des
 entreprises investir dans la gestion de leur propre cluster Kubernetes. La
-plupart des entreprises qui font le choix d'utiliser Kubernetes pour gérer leurs
+plupart des entreprises qui font le choix d'utiliser Kubernetes pour gérer
-infrastructures, choisissent de passer par un prestataire. L'entreprise délègue
+leurs infrastructures, choisissent de passer par un prestataire. L'entreprise
-donc la gestion de son/ses cluster(s) à une autre entreprise, dont c'est le cœur de
+délègue donc la gestion de son/ses cluster(s) à une autre entreprise, dont
-métier. La plupart du temps, il va s'agir d'Amazon (via [Elastic Kubernetes
+c'est le cœur de métier. La plupart du temps, il va s'agir d'Amazon (via
-Service](https://aws.amazon.com/fr/eks/)), d'Azure [Kubernetes
+[Elastic Kubernetes Service](https://aws.amazon.com/fr/eks/)), d'Azure
+[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
@@ -23,14 +25,39 @@ d'autres acteurs plus petits existent aussi
 
 ::::: {.more}
 
+Lorsque l'on veut créer son cluster, on a le choix d'assembler tous les
+composants de *Kubernetes* soi-même (*vanilla*), ou alors de partir d'une
+distribution existante. On parle de *distribution* dans le même sens que l'on
+connaît les distributions GNU/Linux : chacun peut aller récupérer les sources
+du noyau Linux et des différents programmes nécessaires au démarrage et à
+l'exécution d'un système d'exploitation fonctionnel, ou alors on peut utiliser
+une distribution qui met à notre disposition un noyau Linux et tout un
+écosystème de programmes qui forment un système d'exploitation cohérent et qui
+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,
+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.\
+
+Devant la complexité de conception et le nombre grandissant de distributions,
+une certification est délivrée aux distributions sérieuses. On en dénombre tout
+de même plus d'une cinquantaine[^k8s-distributions-certified].\
+
+[^k8s-distributions-certified]: Voir la liste sur
+    <https://www.cncf.io/certification/software-conformance/>.
+
 Pour l'IoT ou l'Edge Computing, sur du matériel léger, il existe le projet
 k3s[^k3s] : il s'agit d'une distribution Kubernetes beaucoup plus simple à
 déployer, et parfaitement adaptée à la production sur Raspberry Pi et autres.
 
-:::::
-
 [^k3s]: Lightweight Kubernetes : <https://k3s.io/>
 
+:::::
+
 Pour jouer, plusieurs solutions s'offrent à nous pour commencer à
 utiliser Kubernetes facilement :
 
@@ -56,8 +83,8 @@ Une fois que tout sera opérationnel, nous devrions obtenir :
 <div lang="en-US">
 ```
 42sh$ kubectl version
-Client Version: version.Info{Major:"1", minor:"22", GitVersion:"v1.22.2", [...]
+Client Version: version.Info{Major:"1", minor:"25", GitVersion:"v1.25.3", [...]
-Server Version: version.Info{Major:"1", minor:"21", GitVersion:"v1.21.5", [...]
+Server Version: version.Info{Major:"1", minor:"21", GitVersion:"v1.25.3", [...]
 ```
 </div>
 
@@ -77,9 +104,9 @@ votre `$PATH`.
 
 
 Notre prochaine étape est de décrire le cluster que l'on souhaite avoir : 1
-master et 2 workers, ça fera l'affaire. Attention tout de même de ne pas être
+*control-plane* et 2 *workers*, ça fera l'affaire. Attention tout de même à ne
-trop extravagant, car chaque nœud consomme pas mal de RAM ! Et puis nous
+pas être trop extravagant, car chaque nœud consomme pas mal de RAM ! Et puis
-pourrons facilement changer cette configuration plus tard.
+nous pourrons facilement changer cette configuration plus tard.
 
 <div lang="en-US">
 ```bash
@@ -105,7 +132,7 @@ kind create cluster --config my-cluster.yml
 La création du cluster peut prendre quelques minutes.
 
 Profitons-en pour télécharger `kubectl` :\
-<https://storage.googleapis.com/kubernetes-release/release/v1.22.2/bin/linux/amd64/kubectl>
+<https://storage.googleapis.com/kubernetes-release/release/v1.25.3/bin/linux/amd64/kubectl>
 
 C'est principalement grâce à cette commande que nous interagirons avec l'API de
 Kubernetes.
@@ -115,8 +142,8 @@ Une fois que tout sera opérationnel, nous devrions obtenir :
 <div lang="en-US">
 ```
 42sh$ kubectl version
-Client Version: Version.Info{Major:"1", Minor:"22", GitVersion:"v1.22.2", [...]
+Client Version: Version.Info{Major:"1", Minor:"22", GitVersion:"v1.25.3", [...]
-Server Version: Version.Info{Major:"1", Minor:"21", GitVersion:"v1.21.5", [...]
+Server Version: Version.Info{Major:"1", Minor:"21", GitVersion:"v1.25.3", [...]
 ```
 </div>
 
@@ -136,16 +163,16 @@ cluster Kubernetes selon les autres méthodes décrites.
 
 De la même manière que pour les exercices utilisant Docker, si vous avez des
 difficultés pour réaliser les exercices sur vos machines, vous pouvez utiliser
-le projet [Play With K8s](https://play-with-k8s.com/) qui vous donnera accès à
+le projet [Play With K8s](https://labs.play-with-k8s.com/) qui vous donnera
-un bac à sable avec lequel vous pourrez réaliser tous les exercices.
+accès à un bac à sable avec lequel vous pourrez réaliser tous les exercices.
 
 Il nous faut créer plusieurs instances, disons 3 : parmi elles, 1 instance sera
-la master, nous l'utiliserons principalement, les deux autres ne feront
+pour notre *control-plane*, que nous utiliserons principalement, les deux
-qu'exécuter des conteneurs, nous pourrons les oublier dès qu'on les aura
+autres ne feront qu'exécuter des conteneurs, nous pourrons les oublier dès
-connectées au master.
+qu'on les aura connectées à notre nœud principal.
 
-Pour initialiser notre cluster Kubernetes, nous allons devoir créer notre
+Pour initialiser notre cluster Kubernetes, nous allons commencer par créer
-master. Pour cela, dans notre première instance, nous allons taper :
+le contrôleur. Pour cela, dans notre première instance, nous allons taper :
 
 <div lang="en-US">
 ```bash
@@ -182,14 +209,13 @@ nos deux autres instances. Cela permettra aux machines de se connecter au
 master.
 
 Dernière étape pour la mise en place de notre cluster, il s'agit de définir un
-profil de politique réseau, sur le master (nous n'exécuterons plus de commande
+plugin de modèle réseau, sur le nœud principal (nous n'exécuterons plus de
-sur les autres workers) :
+commande sur les autres *workers*) :
 
 <div lang="en-US">
 ```bash
-kubectl apply -n kube-system -f \
+kubectl apply -f \
-  "https://cloud.weave.works/k8s/net?k8s-version=$(kubectl version | \
+  https://raw.githubusercontent.com/cloudnativelabs/kube-router/master/daemonset/kubeadm-kuberouter.yaml
-  base64 | tr -d '\n')"
 ```
 </div>
 

tutorial/k8s/tutorial-el.md

@@ -3,13 +3,11 @@ title: Ελαφριά εικονικοποίηση -- Πρακτική δουλ
 subtitle: κυβερνήτης
 author: Πιέρ-Ολιβιέ *νεμυναιρε* [ῥαφοπώλης]{.smallcaps}
 institute: ΣΠκΠΤ
-date: Παρασκευή 19 Νοεμβρίου 2021
+date: Τετάρτη 30 Νοεμβρίου 2022
 abstract: |
   Ο στόχος αυτού του τελευταίου εργαστηρίου είναι να κατανοήσει το κυβερνήτης και την ενορχήστρωση εμπορευματοκιβωτίων.
 
   \vspace{1em}
 
-  Οι ασκήσεις για αυτό το πρακτικό έργο μπορούν να επιστραφούν στη διεύθυνση <ανδροππήςρε@nemunai.re> το αργότερο την Παρασκευή 3 Δεκεμβρίουz 2021 στις 11:42 μ.μ., οι ερωτήσεις των μαθημάτων πρέπει επίσης να ολοκληρωθούν πριν από αυτήν την ημερομηνία. Δείτε το τελευταίο μέρος αυτού του εργαστηρίου για λεπτομέρειες.
+  Οι ασκήσεις για αυτό το μάθημα πρέπει να υποβληθούν μέχρι την Τετάρτη 7 Δεκεμβρίου 2022 στις 23:42 μ.μ., εκτός αν γράψετε στο <ανδροππήςρε@nemunai.re>. Ανατρέξτε στα τμήματα που επισημαίνονται με κίτρινη ταινία και γρανάζι για περισσότερες πληροφορίες σχετικά με τα οφειλόμενα.
-
-  Καθώς οι άνθρωποι γνωρίζουν την ασφάλεια των ηλεκτρονικών ανταλλαγών, πρέπει να μου στείλετε τις υπογεγραμμένες αποδόσεις σας με το κλειδί PGP. Θυμηθείτε να [με](https://keys.openpgp.org/search?q=nemunaire%40nemunai.re) υπογράψετε το κλειδί σας και μην διστάσετε [να υπογράψετε το δικό σας](https://www.meetup.com/fr/Paris-certification-de-cles-PGP-et-CAcert/).
 ...

tutorial/k8s/tutorial.md

@@ -10,14 +10,8 @@ abstract: |
 
   \vspace{1em}
 
-  Les exercices de ce TP peuvent être rendus à <virli@nemunai.re> au plus tard
+  Les exercices de ce cours sont à rendre au plus tard le mercredi 7
-  le jeudi 26 novembre 2020 à 23 h 42, des questions de cours sont également à
+  décembre 2022 à 23 h 42. Consultez les sections matérialisées par un
-  compléter avant cette date. Consultez la dernière partie de ce TP pour les
+  bandeau jaunes et un engrenage pour plus d'informations sur les
-  modalités.
+  éléments à rendre.
-
-  En tant que personnes sensibilisées à la sécurité des échanges électroniques,
-  vous devrez m'envoyer vos rendus signés avec votre clef PGP. Pensez à
-  [me](https://keys.openpgp.org/search?q=nemunaire%40nemunai.re) faire signer
-  votre clef et n'hésitez pas à [faire signer la
-  vôtre](https://www.meetup.com/fr/Paris-certification-de-cles-PGP-et-CAcert/).
 ...