Inspektor Gadget : boîte à outils eBPF pour Kubernetes

Inspektor Gadget répond à une question que bpftrace ne sait pas poser : quel conteneur, quel pod a produit cet appel système ? C'est une collection d'outils eBPF, les gadgets, qui tracent les syscalls, le réseau et les fichiers en rattachant chaque événement au conteneur ou au pod Kubernetes qui l'a provoqué. Cette page montre l'outil au travail en mode autonome sur un hôte, puis avec un runtime de conteneurs, avec des sorties réelles capturées sur une VM Ubuntu 24.04 (noyau 6.8, Inspektor Gadget v0.54.1). Pour le socle eBPF, voir le hub eBPF.

Ce que vous allez apprendre

Comprendre ce qu'Inspektor Gadget ajoute à eBPF « brut »
Installer l'outil autonome ig (sans Kubernetes)
Tracer les exécutions de l'hôte, puis d'un conteneur
Lire la corrélation événement / conteneur, la vraie valeur de l'outil
Situer le mode Kubernetes et les autres gadgets

Le problème : eBPF voit des PID, pas des conteneurs

Les outils eBPF de base, comme bpftrace, montrent des processus : un nom, un PID. C'est parfait sur une machine classique. Mais dans un monde de conteneurs et de pods, cette information ne suffit plus : savoir que « le PID 26251 a lancé id » n'aide pas si vous cherchez quel conteneur se comporte anormalement.

Inspektor Gadget comble ce vide. Il prend les mêmes techniques eBPF et y ajoute la corrélation : chaque événement est étiqueté avec le conteneur, et sous Kubernetes, avec le pod, l'espace de noms et le nœud. C'est la différence entre un traceur système et un outil d'observabilité pensé pour les conteneurs.

Installer l'outil autonome `ig`

Inspektor Gadget existe en deux formes : kubectl gadget (dans un cluster Kubernetes) et ig, un binaire autonome qui trace un hôte et ses conteneurs sans Kubernetes. On commence par ig, plus simple pour apprendre. On télécharge le binaire depuis la page des versions, sans script d'installation opaque.

IG=v0.54.1
curl -sSL -o ig.tar.gz \
  "https://github.com/inspektor-gadget/inspektor-gadget/releases/download/${IG}/ig-linux-amd64-${IG}.tar.gz"
tar xzf ig.tar.gz
sudo mv ig /usr/local/bin/
ig version

v0.54.1

Premier gadget : tracer l'hôte

Un gadget est une unité de traçage, distribuée comme une image (au format OCI, comme une image de conteneur). Le gadget trace_exec affiche chaque exécution de programme. En mode autonome, sans runtime de conteneurs, on ajoute --host pour tracer directement la machine :

sudo ig run trace_exec:latest --host

Sortie réelle (pendant que des commandes tournent) :

RUNTIME.CONTAINERNAME    COMM      PID      TID      ARGS
                         uname     25286    25286    /usr/bin/uname -r
                         id        25287    25287    /usr/bin/id
                         sleep     25288    25288    sleep 0.25

À ce stade, la colonne RUNTIME.CONTAINERNAME est vide : rien ne tourne dans un conteneur, on trace l'hôte comme le ferait bpftrace. L'intérêt d'Inspektor Gadget apparaît dès qu'un conteneur entre en jeu.

La corrélation conteneur : la vraie valeur

Lançons un conteneur qui exécute des commandes en boucle, puis relançons le même gadget, cette fois sans --host pour qu'Inspektor Gadget interroge le runtime :

# un conteneur qui s'agite
sudo docker run -d --name demo busybox sh -c 'while true; do id; ls /; sleep 0.4; done'

# le même gadget, avec corrélation conteneur
sudo ig run trace_exec:latest

Sortie réelle :

RUNTIME.CONTAINERNAME    COMM      PID      TID      ARGS
demo                     id        26251    26251    id
demo                     ls        26252    26252    ls /
demo                     sleep     26253    26253    sleep 0.4
demo                     id        26254    26254    id

La colonne RUNTIME.CONTAINERNAME affiche maintenant demo : chaque exécution est attribuée au conteneur qui l'a produite. Voilà ce qu'Inspektor Gadget apporte et qu'un traceur brut ne donne pas : l'événement noyau plus son contexte applicatif. Sur un hôte qui fait tourner des dizaines de conteneurs, c'est la différence entre un mur de PID anonymes et une lecture immédiate.

Les gadgets disponibles

trace_exec n'est qu'un gadget parmi d'autres. Chacun est une image que l'on télécharge et exécute. Les plus utiles au quotidien :

Gadget	Ce qu'il trace
`trace_exec`	Les exécutions de programmes
`trace_open`	Les ouvertures de fichiers
`trace_tcp`	Les connexions TCP
`trace_dns`	Les requêtes DNS
`trace_signal`	Les signaux envoyés aux processus
`top_file`	Les fichiers les plus actifs (façon `top`)

Les images en cache sont visibles avec ig image list :

sudo ig image list

REPOSITORY    TAG      DIGEST          CREATED
trace_exec    latest   sha256:a1b3b5…  2026-07-14T09:08:14Z

Le mode Kubernetes

Dans un cluster, on n'installe pas ig sur chaque nœud à la main : on déploie Inspektor Gadget une fois, et on l'interroge avec le greffon kubectl gadget. Le principe est identique, mais la corrélation monte d'un cran : chaque événement porte le pod, l'espace de noms et le nœud.

# déploiement dans le cluster
kubectl gadget deploy

# tracer les exécutions, filtré sur un espace de noms
kubectl gadget run trace_exec:latest -n mon-appli

On obtient alors, pour chaque exécution, le pod et le conteneur exact, sur l'ensemble des nœuds, depuis un seul poste. C'est le cas d'usage pour lequel Inspektor Gadget a été conçu : déboguer et surveiller un cluster sans installer d'agent dans chaque image applicative.

Sécurité et points de vigilance

Opération privilégiée. ig charge des programmes eBPF : il exige root ou CAP_BPF + CAP_PERFMON. En cluster, le déploiement tourne avec des privilèges élevés sur chaque nœud, à traiter comme un composant sensible.
Observation, pas modification. Les gadgets de traçage lisent l'état du système. Le risque n'est pas la casse mais la fuite : chemins de fichiers, requêtes DNS, arguments de commande peuvent contenir des données sensibles. Traitez les sorties comme des journaux sensibles.
Coût sous forte charge. Tracer un événement très fréquent sur un nœud chargé ajoute un surcoût. Filtrez par espace de noms ou par conteneur, et évitez de laisser un gadget tourner en continu sans raison.

Inspektor Gadget ou un simple traceur

Le choix se résume à une question : avez-vous besoin du contexte conteneur ?

Sur une machine classique, sans conteneurs, bpftrace est plus direct et plus souple.
Sur un hôte à conteneurs ou un cluster Kubernetes, Inspektor Gadget évite le travail fastidieux de relier un PID à un conteneur, et le fait sur tous les nœuds à la fois.

Pour la sécurité runtime (détecter et bloquer des comportements, pas seulement observer), l'outil bascule vers Tetragon ou Tracee.

Dépannage

Symptôme	Cause probable	Solution
`container-collection isn't available`	Mode autonome sans runtime	Ajouter `--host` pour tracer l'hôte
Colonne conteneur vide	Aucun conteneur, ou `--host` actif	Normal sur l'hôte ; retirer `--host` avec un runtime
`permission denied`	Lancé sans privilège	`sudo`, ou `CAP_BPF` + `CAP_PERFMON`
Échec au chargement du gadget	BTF absent (vieux noyau)	Vérifier `/sys/kernel/btf/vmlinux`

À retenir

Inspektor Gadget ajoute à eBPF la corrélation de chaque événement avec le conteneur ou le pod.
L'outil autonome ig trace un hôte et ses conteneurs sans Kubernetes ; --host cible l'hôte seul.
La colonne RUNTIME.CONTAINERNAME est la vraie valeur : l'événement noyau plus son contexte applicatif.
Les gadgets (trace_exec, trace_open, trace_dns...) sont des images que l'on télécharge et exécute.
En Kubernetes, kubectl gadget étend la corrélation au pod, à l'espace de noms et au nœud, depuis un seul poste.
C'est une opération privilégiée dont les sorties peuvent être sensibles.

Prochaines étapes

bpftrace : tracer le noyau en une ligne Le traçage eBPF sans la corrélation conteneur, plus direct sur un hôte.

Tetragon : observer et bloquer à l'exécution Passer de l'observation à l'application de politiques de sécurité.

Tracee : détection runtime par signatures Détecter les comportements suspects, pas seulement les tracer.

Le hub eBPF Le socle : comment fonctionne la technologie derrière les gadgets.