diff --git a/tutorial/k8s/Makefile b/tutorial/k8s/Makefile index 2ac0da8..9fc4a76 100644 --- a/tutorial/k8s/Makefile +++ b/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 diff --git a/tutorial/k8s/rendu.md b/tutorial/k8s/rendu.md index 83780ba..b1574c5 100644 --- a/tutorial/k8s/rendu.md +++ b/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 . 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 : - -
-``` -login_x-TP5/cmpns.sh -login_x-TP5/mydocker_exec.sh -login_x-TP5/myswitch_root.sh -``` -
+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. diff --git a/tutorial/k8s/run.md b/tutorial/k8s/run.md index 5aa825f..79db735 100644 --- a/tutorial/k8s/run.md +++ b/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 ! diff --git a/tutorial/k8s/scaling.md b/tutorial/k8s/scaling.md new file mode 100644 index 0000000..c06e26d --- /dev/null +++ b/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 !