virli/tutorial/k8s/scaling.md

134 lines
3.4 KiB
Markdown
Raw Normal View History

2022-02-24 19:43:43 +00:00
### Montée en charge
2019-11-26 17:20:26 +00:00
2022-02-24 19:43:43 +00:00
Commençons facilement, en augmentant le nombre de `workers` :
2019-11-26 17:20:26 +00:00
```bash
kubectl scale deploy/worker --replicas=10
```
Tout comme cela fonctionnait en partie avec `docker-compose`, on obtient ici le
2022-02-24 19:43:43 +00:00
même résultat. Ouf ... c'était pas trop tôt !
2019-11-26 17:20:26 +00:00
2022-02-24 19:43:43 +00:00
Nous pouvons profiter de regarder l'augmentation en direct, via la commande :
2019-11-26 17:20:26 +00:00
```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.
2022-02-24 19:43:43 +00:00
#### Daemon sets
2019-11-26 17:20:26 +00:00
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
2021-11-19 23:00:30 +00:00
nœud quitte le cluster, le *pod* est nettoyé.
2019-11-26 17:20:26 +00:00
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`, ...)
2022-02-24 19:43:43 +00:00
Pour créer un *daemon sets*, il est nécessaire d'écrire un fichier YAML :
2019-11-26 17:20:26 +00:00
```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
```
2022-02-24 19:43:43 +00:00
Ensuite, on crée le *DaemonSet* en appliquant la nouvelle spécification :
2019-11-26 17:20:26 +00:00
```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/).
2022-02-24 19:43:43 +00:00
##### *DaemonSet* `rng`
2019-11-26 17:20:26 +00:00
2021-11-19 23:00:30 +00:00
Pour réaliser le *DaemonSet* de notre *pod* `rng`, le plus simple est de partir
2022-02-24 19:43:43 +00:00
d'un export de la ressource existante :
2019-11-26 17:20:26 +00:00
```bash
2021-09-11 12:41:43 +00:00
kubectl get deploy/rng -o yaml > rng.yml
2019-11-26 17:20:26 +00:00
```
La première chose que l'on peut faire, c'est changer le type décrit dans le
2022-02-24 19:43:43 +00:00
champ `kind` :
2019-11-26 17:20:26 +00:00
```yaml
kind: DaemonSet
```
Vous pouvez essayer d'appliquer cette spec, pour voir et essayer de tâtonner
2021-09-11 12:41:43 +00:00
grâce aux erreurs renvoyées par l'API.
2019-11-26 17:20:26 +00:00
Il vous faudra également retirer le champ `replicas` (qui n'a pas de sens ici,
2021-09-11 12:41:43 +00:00
vu que la réplication est basée sur les nœuds), les champs `strategy`,
2019-11-26 17:20:26 +00:00
`progressDeadlineSeconds`, ainsi que la ligne `status: {}`.
2022-02-24 19:43:43 +00:00
###### Force ! {-}
2019-11-26 17:20:26 +00:00
En fait, plutôt que de corriger ces erreurs, on aurait aussi très bien pu
2022-02-24 19:43:43 +00:00
désactiver la validation comme ceci :
2019-11-26 17:20:26 +00:00
```bash
kubectl apply -f rng.yml --validate=false
```
2022-02-24 19:43:43 +00:00
##### Trop de *pods* `rng` {-}
2019-11-26 17:20:26 +00:00
2021-11-19 23:00:30 +00:00
Après avoir appliqué la nouvelle spec, on constate qu'il y a beaucoup de *pod*s
`rng`. En effet, l'ancien *pod* déployé avec la ressource *deployment* est
2019-11-26 17:20:26 +00:00
toujours là.
2022-02-24 19:43:43 +00:00
##### Botleneck résolu ? {-}
2019-11-26 17:20:26 +00:00
Admirez maintenant dans Chronograf si vous avez réussi à augmenter votre nombre
2022-02-24 19:43:43 +00:00
de pépites !