tuto5: in progress

tutorial/k8s/Makefile

@@ -1,6 +1,6 @@
 include ../pandoc-opts.mk
 
-SOURCES_TUTO	= tutorial.md setup.md intro.md overview.md discover.md run.md rendu.md
+SOURCES_TUTO	= tutorial.md setup.md intro.md overview.md discover.md run.md scaling.md rendu.md
 
 
 all: tutorial.pdf

tutorial/k8s/rendu.md

@@ -3,34 +3,8 @@
 Rendu
 =====
 
-Modalités de rendu
-------------------
+Il n'y a rien à rendre pour ce TP. Profitez-en pour avancer sur le projet !
 
-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 <virli@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.
-
-Par ailleurs, n'oubliez pas de répondre à
-[l'évaluation du cours](https://www.epitaf.fr/moodle/mod/quiz/view.php?id=309).
-
-
-Tarball
--------
-
-Tous les exercices de ce TP sont à placer dans une tarball (pas d'archive ZIP,
-RAR, ...).
-
-Voici une arborescence type :
-
-<div lang="en-US">
-```
-login_x-TP5/cmpns.sh
-login_x-TP5/mydocker_exec.sh
-login_x-TP5/myswitch_root.sh
-```
-</div>
+Mais n'oubliez pas de répondre au
+[sondage](https://www.epitaf.fr/moodle/mod/feedback/view.php?id=305) pour me
+permettre d'améliorer ce cours.

tutorial/k8s/run.md

@@ -96,12 +96,19 @@ done
 
 #### Exposer les ports
 
+Pour trois des applications, des ClusterIP font l'affaire, car ils n'ont pas
+besoin d'être exposés en dehors du cluster.
+
 ```bash
 kubectl expose deployment influxdb --port 8088
 kubectl expose deployment rng --port 80
 kubectl expose deployment hasher --port 80
 ```
 
+Par contre, notre Chronograf doit être exposé, on lui alloue donc un NodePort :
+
 ```bash
 kubectl create service nodeport chronograf --tcp=8888 --node-port=30001
 ```
+
+À ce stade, nous devrions pouvoir accéder à l'interface de Chronograf !

tutorial/k8s/scaling.md

@@ -0,0 +1,137 @@
+\newpage
+
+Montée en charge
+================
+
+Commençons facilement, en augmentant le nombre de `workers` :
+
+```bash
+kubectl scale deploy/worker --replicas=10
+```
+
+Tout comme cela fonctionnait en partie avec `docker-compose`, on obtient ici le
+même résultat. Ouf ... c'était pas trop tôt !
+
+Nous pouvons profiter de regarder l'augmentation en direct, via la commande :
+
+```bash
+kubectl get pods -w
+```
+
+Par contre, ce ne sera pas aussi simple d'augmenter le nombre de `rng`. En
+effet, il nous faut répartir les services entre plusieurs machines.
+
+
+Daemon sets
+-----------
+
+Une ressource *daemon sets* va s'assurer que tous les nœuds (ou une partie)
+vont exécuter une instance d'un *pod*. Ainsi, si un nouveau nœud rejoint le
+cluster, le *pod* sera automatiquement lancé dessus. Inversement, lorsqu'un
+nœud quitte le cluster, le pod est nettoyé.
+
+On s'en sert principalement pour exécuter une instance de daemon de stockage
+(tel que Ceph, `glusterd`, ...) ou pour la collecte de logs (`fluentd`,
+`logstash`, ...), voire du monitoring (Prometheus, `collectd`, ...)
+
+Pour créer un *daemon sets*, il est nécessaire d'écrire un fichier YAML :
+
+```yaml
+apiVersion: apps/v1
+kind: DaemonSet
+metadata:
+  name: fluentd-elasticsearch
+  namespace: kube-system
+  labels:
+	k8s-app: fluentd-logging
+spec:
+  selector:
+	matchLabels:
+	  name: fluentd-elasticsearch
+  template:
+	metadata:
+	  labels:
+	    name: fluentd-elasticsearch
+	spec:
+	  tolerations:
+	  - key: node-role.kubernetes.io/master
+	    effect: NoSchedule
+	  containers:
+	  - name: fluentd-elasticsearch
+		image: quay.io/fluentd_elasticsearch/fluentd:v2.5.2
+		resources:
+		  limits:
+		    memory: 200Mi
+		  requests:
+		    cpu: 100m
+			memory: 200Mi
+		volumeMounts:
+		- name: varlog
+		  mountPath: /var/log
+	    - name: varlibdockercontainers
+		  mountPath: /var/lib/docker/containers
+		  readOnly: true
+	  terminationGracePeriodSeconds: 30
+	  volumes:
+	  - name: varlog
+	    hostPath:
+		  path: /var/log
+	  - name: varlibdockercontainers
+	    hostPath:
+          path: /var/lib/docker/containers
+```
+
+Ensuite, on crée le *DaemonSet* en appliquant la nouvelle spécification :
+
+```bash
+kubectl apply -f https://k8s.io/examples/controllers/daemonset.yaml
+```
+
+Pour plus d'informations, consultez [la
+documentation](https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/).
+
+
+### *DaemonSet* `rng`
+
+Pour réaliser le *DaemonSet* de notre pod `rng`, le plus simple est de partir
+d'un export de la ressource existante :
+
+```bash
+kubectl get deploy/rng -o yaml --export > rng.yml
+```
+
+La première chose que l'on peut faire, c'est changer le type décrit dans le
+champ `kind` :
+
+```yaml
+kind: DaemonSet
+```
+
+Vous pouvez essayer d'appliquer cette spec, pour voir et essayer de tâtonner
+grâce aux erreurs renvoyés par l'API.
+
+Il vous faudra également retirer le champ `replicas` (qui n'a pas de sens ici,
+vu que la réplication est basé sur les nœuds), les champs `strategy`,
+`progressDeadlineSeconds`, ainsi que la ligne `status: {}`.
+
+#### Force !
+
+En fait, plutôt que de corriger ces erreurs, on aurait aussi très bien pu
+désactiver la validation comme ceci :
+
+```bash
+kubectl apply -f rng.yml --validate=false
+```
+
+
+### Trop de *pods* `rng`
+
+Après avoir appliqué la nouvelle spec, on constate qu'il y a beaucoup de *pods*
+`rng`. En effet, l'ancien *pod* déployé avec la resource *deployment* est
+toujours là.
+
+
+### Bootleneck résolu ?
+
+Admirez maintenant dans Chronograf si vous avez réussi à augmenter votre nombre
+de pépites !