tuto5: in progress
This commit is contained in:
parent
4fe5c78d9b
commit
c83406e494
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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 !
|
||||
|
|
|
|||
137
tutorial/k8s/scaling.md
Normal file
137
tutorial/k8s/scaling.md
Normal file
|
|
@ -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 !
|
||||
Loading…
Reference in New Issue
Block a user