debug netpol k8s avec ebpf qqn a déjà fait ?

Posté par alexandria-benard le 26/06/2025
RÉSOLU

alexandria-benard

Membre depuis le 12/02/2025

actif

salut à tous ! j'ai un cluster K8s avec des NetPols partout. on a un service (microservice A) qui essaye de joindre un autre (microservice B) et ça passe pas. les logs applicatifs du A montrent des timeouts, et le B ne voit rien arriver. `kubectl describe netpol` est ok. `tcpdump` sur le host du pod A et B ne montre pas de packets perdus. je sèche. je me dis qu'un eBPF pourrait m'aider à voir où le paquet est droppé dans le kernel, genre par un hook netfilter ou autre. qqn a déjà fait ça proprement ?

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-a-to-b
spec:
  podSelector:
    matchLabels:
      app: microservice-b
  policyTypes:
    - Ingress
  ingress:
    - from:
        - podSelector:
            matchLabels:
              app: microservice-a
      ports:
        - protocol: TCP
          port: 8080

Commentaires

rousseau-charlotte

Membre depuis le 19/09/2024

actif secouriste

hello ! ouais eBPF c'est gold pour ça. si t'es sur Cilium t'as Hubble qui te donne tout en un clic. sinon avec Calico ou autres cni faut bricoler un peu plus mais c'est faisable. tu peux hook des points précis dans le kernel pour voir les drops.

alexandria-benard

Membre depuis le 12/02/2025

actif

on est sur Calico. pas de Hubble donc. je cherche un truc générique avec bpftrace ou bcc. l'idée c de voir le verdict avant que le paquet soit juste... parti.

simone06

Membre depuis le 16/05/2019

actif secouriste

avec bpftrace tu peux hook les fonctions netfilter. genre `nf_hook_slow` c'est le point d'entrée générique pour les hooks. tu peux voir le verdict là. ça t'indiquera quelle chaîne netfilter a droppé le paquet.

alexandria-benard

Membre depuis le 12/02/2025

actif

ah `nf_hook_slow` c'est intéressant. comment je filtre sur le paquet qui m'intéresse ? genre IP source ou dest ?

rousseau-charlotte

Membre depuis le 19/09/2024

actif secouriste

tu peux accéder aux arguments de la fonction. le `skb` (socket buffer) est dedans. donc tu peux faire des if sur `args->skb->saddr` ou `daddr`. ça va être verbeux mais super précis.

simone06

Membre depuis le 16/05/2019

actif secouriste

exactement. tu peux aussi regarder `kprobe:kfree_skb_reason` qui te donne la raison du drop si c'est le kernel qui le fait. mais si c'est netfilter, `nf_hook_slow` est mieux.

alexandria-benard

Membre depuis le 12/02/2025

actif

ok donc `kprobe:nf_hook_slow` avec un filtre sur IP, et je dump le verdict. et le nom de la chaîne netfilter ? c dispo aussi ?

rousseau-charlotte

Membre depuis le 19/09/2024

actif secouriste

le nom direct de la chaîne c'est plus compliqué à extraire d'un coup. mais tu auras le `hooknum` qui correspond au point d'accroche (ex: `nf_inet_pre_routing`, `nf_inet_forward`). avec ça et le verdict, tu peux déjà situer pas mal.

simone06

Membre depuis le 16/05/2019

actif secouriste

pour le nom de la chaîne, tu peux lister les règles iptables avec `iptables-save` et chercher les règles Calico. ensuite tu peux mapper ça avec ce que tu vois dans tes traces bpftrace.

alexandria-benard

Membre depuis le 12/02/2025

actif

d'acc. donc bpftrace sur `nf_hook_slow`, je filtre sur IP et je print le `hooknum` et le verdict. puis je croise avec `iptables-save`. je vais essayer ça. merci bcp !

bpftrace -e 'kprobe:nf_hook_slow { \
  $skb = args->skb; \
  if ($skb->mark == 0xbeef && $skb->pkt_type == 0 /* HOST */) { \
    printf("Time: %llu, Hook: %d, Verdict: %d, Saddr: %s, Daddr: %s\\n", \
           nsecs / 1000000, \
           args->hooknum, \
           args->verdict, \
           ntop($skb->saddr), \
           ntop($skb->daddr)); \
  }
}'

rousseau-charlotte

Membre depuis le 19/09/2024

actif secouriste

le `skb->mark` est intéressant si tu marques tes paquets. sinon juste `saddr` et `daddr` suffisent. attention à la compilation du BPF, ça peut être sensible à la version du kernel.

simone06

Membre depuis le 16/05/2019

actif secouriste

oui et check tes kernel headers. sinon ça pète. c'est pour ça que Cilium est plus user-friendly. mais pour du Calico, c'est la bonne méthode.

alexandria-benard

Membre depuis le 12/02/2025

actif

ouais les headers sont à jour. j'ai bien un drop sur `NF_INET_FORWARD` avec un verdict de `NF_DROP`. maintenant il faut trouver la règle iptables qui fait ça. merci pour le coup de main c'est beaucoup plus clair.

rousseau-charlotte

Membre depuis le 19/09/2024

actif secouriste

super ! ça prouve que la netpol est bien active et droppe le paquet. c'est probablement un détail dans la policy ou un ordre de règles qui pose problème.

simone06

Membre depuis le 16/05/2019

actif secouriste

vérifie bien que ton `podSelector` et tes `ingress` ou `egress` sont exacts. une petite faute peut tout casser.

alexandria-benard

Membre depuis le 12/02/2025

actif

c'était un `namespaceSelector` sur une autre netpol qui bloquait tout. une erreur bête. le bpftrace m'a bien montré que le paquet était droppé là. thx à tous !

Laisser une réponse

Vous devez être connecté pour poster un message !

Rejoindre la communauté

Recevoir les derniers articles gratuitement en créant un compte !

S'inscrire