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

Question

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

rousseau-charlotte · Answer

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 · Answer

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 · Answer

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 · Answer

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 · Answer

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 · Answer

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 · Answer

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 · Answer

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 · Answer

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 · Answer

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 · Answer

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 · Answer

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 · Answer

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 · Answer

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 · Answer

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

alexandria-benard · Answer

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 !

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

16 commentaires

Laisser une réponse

Les pointeurs dans le langage de programmation Go

Les variables Input et Output

Ce que n'est pas le DevOps

Améliorer la productivité du modèle DevOps (DORA)

Faciliter le déploiements k8s avec Kustomize

Rejoindre la communauté