Chrome émulait un GPU : –35 points de CPU sur le nœud

Le symptôme

Le tableau de bord de supervision montrait un nœud à ~64 % de CPU en permanence, même la nuit, sans que rien ne semble justifier cette charge.

L’enquête

Les métriques par conteneur ont rapidement désigné un coupable : le bureau distant Kasm, un environnement de bureau Linux dans le navigateur, que j’utilise avec Chrome installé dedans.

À l’intérieur du conteneur, un processus sortait du lot : le gpu-process de Chrome, collé à 100 % d’un cœur. Il n’y a pas de GPU dans ce conteneur. Chrome en émulait un en logiciel.

La cause : l’image de base lance Chrome avec --ignore-gpu-blocklist, qui force l’accélération graphique même quand aucun GPU n’est disponible. Chrome se rabat alors sur un rendu logiciel coûteux.

La correction

Dans le Dockerfile de mon image Kasm personnalisée, on remplace l’argument dans le lanceur, et on fait échouer le build si le remplacement n’a pas eu lieu (le jour où l’image de base change son script, je le saurai) :

RUN sed -i 's/--ignore-gpu-blocklist/--disable-gpu/g' /usr/bin/google-chrome \
    && grep -q -- '--disable-gpu' /usr/bin/google-chrome \
    && ! grep -q -- '--ignore-gpu-blocklist' /usr/bin/google-chrome

L’image est reconstruite par la CI, le tag est mis à jour dans le dépôt GitOps, ArgoCD déploie.

Le résultat

	Avant	Après
CPU du pod Kasm	~1,5 cœur	~0,3 cœur
CPU du nœud	64 %	29 %

Dans la foulée, j’ai aussi allégé code-server (désactivation des fonctions IA intégrées, exclusions pour le watcher et la recherche) : sa mémoire est passée d’environ 2 Go à 0,8 Go.

À retenir

• Une supervision par conteneur transforme « le serveur rame » en un coupable nommé en quelques minutes.
• Les images de base font des choix pour vous : les arguments de lancement méritent d’être lus.

Piège de mesure au passage : kubelet expose les mêmes métriques CPU/mémoire sur deux endpoints (/metrics/cadvisor et /metrics/resource). Si les deux sont collectés, une somme naïve double les valeurs : il faut filtrer sur l’un des deux.