Hubble : observer le réseau Kubernetes avec eBPF

Hubble donne à voir ce qui est habituellement invisible : chaque flux réseau du cluster, avec son verdict (autorisé ou bloqué), en temps réel et sans rien installer dans les pods. C'est le volet observabilité de Cilium : là où Cilium applique les politiques, Hubble montre leur effet. Cette page l'utilise pour suivre les flux et voir une politique réseau bloquer une connexion, avec des sorties capturées sur un cluster k3d (Cilium/Hubble v1.19.5). Pour le socle eBPF, voir le hub eBPF.

Ce que vous allez apprendre

Comprendre ce que Hubble apporte à un cluster Cilium
Activer Hubble et lire le flux d'événements réseau
Distinguer un flux autorisé d'un flux bloqué
Relier un blocage à la politique qui l'a causé
Situer la ligne de commande et l'interface graphique

Le problème : le réseau du cluster est une boîte noire

Sur un cluster Kubernetes, savoir « qui parle à qui » relève souvent de la devinette. Les adresses IP changent, le trafic traverse plusieurs couches, et quand une connexion échoue, rien ne dit pourquoi : mauvaise configuration, politique réseau, panne ?

Hubble répond à cette question. Comme il s'appuie sur les mêmes programmes eBPF que Cilium, il voit tous les flux au niveau du noyau, sans sonde applicative ni sidecar (un conteneur d'assistance ajouté à côté de l'application). Chaque connexion apparaît avec son origine, sa destination et surtout son verdict : le trafic a-t-il été autorisé ou bloqué, et par quoi.

Prérequis

Un cluster avec Cilium comme CNI (voir Cilium).
Hubble activé (option de l'installation Cilium).
kubectl configuré.

Activer Hubble

Hubble s'active à l'installation de Cilium, avec le relais (qui agrège les flux de tous les nœuds) et l'interface graphique :

helm install cilium cilium/cilium -n kube-system \
  --set hubble.relay.enabled=true \
  --set hubble.ui.enabled=true

Une fois en place, cilium status confirme que Hubble tourne et compte les flux :

Hubble:   Ok   Current/Max Flows: 2010/4095 (49.08%), Flows/s: 12.22

Lire les flux réseau

La commande centrale est hubble observe. Elle affiche les connexions en temps réel, avec leur verdict. Regardons le trafic d'un espace de noms :

kubectl exec -n kube-system ds/cilium -c cilium-agent -- hubble observe --namespace default

Sortie réelle (ici des résolutions DNS, toutes autorisées) :

default/client:45002 -> kube-system/coredns:53  to-endpoint  FORWARDED (UDP)
default/client:45002 <- kube-system/coredns:53  to-overlay   FORWARDED (UDP)

Le mot clé est FORWARDED : le flux a été acheminé, donc autorisé. Chaque ligne dit qui parle à qui, sur quel port, et le sens de la connexion. Déjà, la boîte noire s'éclaircit.

Voir une politique bloquer

C'est là que Hubble devient indispensable. Reprenons la politique Cilium qui n'autorise le backend qu'aux pods role: frontend. Un client dépourvu de cette étiquette tente de joindre le backend. Sa requête expire, mais pourquoi ? Hubble le dit, à condition d'interroger l'agent du nœud qui héberge le backend :

kubectl exec -n kube-system <cilium-du-noeud-backend> -c cilium-agent -- hubble observe --verdict DROPPED

Sortie réelle :

default/client:37928 <> default/backend:80  policy-verdict:none DENIED (TCP Flags: SYN)
default/client:37928 <> default/backend:80  Policy denied DROPPED (TCP Flags: SYN)

Le verdict n'est plus FORWARDED mais DROPPED, avec la raison explicite : Policy denied. On voit même le paquet concerné (TCP Flags: SYN, la première tentative de connexion). En une ligne, Hubble transforme un « ça ne marche pas » opaque en « la politique réseau a refusé cette connexion ». C'est la différence entre subir un blocage et le comprendre.

Ligne de commande ou interface graphique

Hubble se consulte de deux façons complémentaires.

La ligne de commande (hubble observe) est parfaite pour filtrer, scripter, chercher un flux précis : par espace de noms, par pod, par verdict. C'est l'outil du diagnostic ciblé.

L'interface graphique (Hubble UI) dessine une carte des services : chaque composant, chaque flux, mis à jour en direct, avec les connexions autorisées et bloquées visualisées. On l'ouvre par un accès local :

kubectl port-forward -n kube-system svc/hubble-ui 12000:80
# puis http://localhost:12000

La carte est précieuse pour explorer une architecture qu'on ne connaît pas, ou montrer d'un coup d'œil l'effet d'une politique. La ligne de commande reste, elle, l'outil du diagnostic précis.

Sécurité et points de vigilance

Les flux révèlent beaucoup. Hubble expose qui communique avec qui, sur quels ports, parfois avec des métadonnées applicatives. C'est une donnée sensible : l'accès au relais et à l'interface doit être contrôlé.
Coût mémoire. Hubble conserve un tampon de flux en mémoire (visible dans cilium status, Current/Max Flows). Sur un cluster très actif, dimensionner ce tampon et, si besoin, exporter vers un collecteur externe.
Observabilité, pas application. Hubble montre les verdicts ; c'est Cilium qui applique les politiques. Pour changer un comportement, on édite la politique, pas Hubble.

Dépannage

Symptôme	Cause probable	Solution
`hubble observe` ne montre rien	Hubble non activé	Réinstaller Cilium avec `hubble.relay.enabled=true`
Un flux bloqué n'apparaît pas	Interrogation du mauvais nœud	Cibler l'agent du nœud hébergeant le pod, ou le relais
Interface vide	Pas de trafic, ou mauvais espace de noms	Générer du trafic, sélectionner le bon namespace
Verdict `DROPPED` inattendu	Politique trop restrictive	Identifier la politique, ajuster ses `fromEndpoints`

À retenir

Hubble montre chaque flux réseau du cluster et son verdict, au niveau du noyau, sans sidecar.
hubble observe affiche les connexions ; FORWARDED = autorisé, DROPPED = bloqué.
Un blocage est expliqué (Policy denied), ce qui relie l'échec à la politique en cause.
Un agent ne voit que son nœud ; le relais donne la vue globale du cluster.
L'interface graphique dessine la carte des services ; la ligne de commande sert au diagnostic ciblé.
Hubble observe, Cilium applique : les deux sont complémentaires.

Prochaines étapes

Cilium : le CNI eBPF L'outil qui applique les politiques que Hubble donne à voir.

Les NetworkPolicies Kubernetes Écrire les politiques dont Hubble affiche les verdicts.

Le hub eBPF La technologie derrière cette visibilité réseau.

Inspektor Gadget : eBPF pour Kubernetes L'observabilité eBPF au-delà du réseau : syscalls, fichiers.