Il est possible de baisser la conso mémoire d’un control-plane k3s, au prix d’une légère dégradation de performances
Mon control-plane k3s tourne sur une machine physique qui a 2 Go de RAM (un Olinuxino A64), et je fais tourner pas mal de choses dans mon cluster.
Je n’ai qu’un seul control-plane car en mettre plusieurs m’obligerait (dans la version actuelle de k3s: 1.27) à utiliser etcd comme BDD (au lieu de SQLite). Or etcd consomme plus de ressources et d’I/Os disques, ce qui serait incompatible avec les cartes SD de ces petits serveurs (d’après le « caution » de cette doc de k3s: https://docs.k3s.io/datastore/ha-embedded)
Il m’arrivait fréquemment, lors d’un « helm upgrade » d’un gros chart Helm (notamment https://github.com/prometheus-community/helm-charts/tree/main/charts/kube-prometheus-stack/), que la machine manque de mémoire vive. Dans ce cas, la machine ne répond plus, tout se fige, c’est la cata.
Après recherche, j’ai trouvé la possibilité de configurer le garbage collector de Go, de sorte qu’il se lance plus tôt quand la consommation de mémoire vive augmente. Source: https://github.com/k3s-io/k3s/issues/1944
Pour cela, j’ai modifié le fichier /etc/systemd/system/k3s.service.env, pour y ajouter:
# To avoid OutOfMemory on the control-plane
GOGC=50
Il suffit ensuite de redémarrer k3s: sudo systemctl restart k3s
Avec ce paramétrage, le processus k3s-server consomme (dans mon cas de figure) en moyenne autour de 700Mo, au lieu d’environ 1Go. Mais surtout, c’est les pics d’utilisation de la mémoire qui sont bien moins hauts. J’ai trouvé une explication claire avec notamment un joli graphique d’utilisation de la mémoire, qu’on peut régler en fonction du GOGC: https://tip.golang.org/doc/gc-guide#GOGC.
En voici des captures d’écran, avec un GOGC à 100 (sa valeur par défaut), et un GOGC à 50:
Notez bien que l’échelle n’est pas la même sur la gauche.
En bref, sur leur exemple on gagne environ 25% de mémoire, en contrepartie de presque deux fois plus de temps passé dans le garbage collector.
Ca n’est donc pas toujours « rentable »: c’est un compromis entre consommation de mémoire et de CPU, à ajuster en fonction des besoins.
Dans mon cas de figure, ça m’a permis d’éviter les blocages de mon control-plane, avec un k3s qui consomme moins de mémoire vive (partie en vert foncé en bas):
Et une consommation CPU à peine plus importante:
