Cilium und eBPF: Networking für moderne Plattformen

NetworkPolicies debuggen mit Standard-Kubernetes-Tools ist meistens ein Ratespiel. Du hast eine Policy, der Traffic kommt nicht an, und du hast keine Ahnung warum. kubectl describe networkpolicy zeigt dir die Spec, aber nicht ob sie greift. Du fängst an, Policies hin und her zu kommentieren, bis irgendwann etwas funktioniert — aber du weißt nicht wirklich warum.

Cilium macht das fundamental besser, weil es eBPF als Fundament nutzt.

eBPF erlaubt es, kleine Programme direkt im Linux-Kernel laufen zu lassen, die an Netzwerk-Events hängen — ohne Kernel-Module, ohne den klassischen iptables-Pfad. Für Network Policies hat das eine Konsequenz, die über Performance hinausgeht: Cilium erzwingt Policies nicht über IP-Adressen, sondern über Identitäten. Jede Kombination von Pod-Labels bekommt eine numerische Security-Identity, und die eBPF-Programme entscheiden anhand dieser Identity, nicht anhand der (flüchtigen) Pod-IP. Bei iptables-basierten Implementierungen muss dagegen jede Pod-Neuplanung Regelketten umschreiben — was bei großen Clustern mit viel Pod-Churn spürbar Zeit kostet. Bei Cilium ändert sich an den Regeln nichts, nur das Mapping von IP zu Identity wird aktualisiert.

Hubble: endlich sehen, was passiert

Hubble ist Ciliums Observability-Layer und der Grund, warum Policy-Debugging von Stunden auf Minuten schrumpft:

hubble observe --verdict DROPPED --namespace checkout --last 50

Die Ausgabe zeigt pro Flow Quelle, Ziel, Port, Protokoll und das Verdict — inklusive der Information, dass eine Policy gegriffen hat. Aus “irgendetwas blockiert mich” wird “Traffic von checkout nach payments auf Port 5432 wird gedroppt, weil keine Egress-Regel existiert”. Dazu kommt die Hubble UI mit einer Live-Servicemap, die sich hervorragend eignet, um vor dem Schreiben von Policies zu sehen, wer eigentlich mit wem redet.

Genau das ist auch die sichere Einführungsstrategie für Default-Deny: erst beobachten, welche Flows existieren, daraus Policies ableiten, und Cilium im Policy-Audit-Modus laufen lassen, der Verstöße loggt statt droppt. Erst wenn der Audit-Log sauber ist, wird scharfgeschaltet. Wer Default-Deny ohne diese Phase aktiviert, lernt innerhalb von Minuten, welche undokumentierten Abhängigkeiten die Plattform hat — auf die harte Tour.

L7-Policies: mächtig, mit Preisschild

CiliumNetworkPolicies gehen deutlich über den Kubernetes-Standard hinaus. Ein Beispiel, das drei Erweiterungen auf einmal zeigt:

apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: checkout-egress
  namespace: checkout
spec:
  endpointSelector:
    matchLabels:
      app: checkout
  egress:
    - toEndpoints:
        - matchLabels:
            app: payments
      toPorts:
        - ports:
            - port: "8080"
          rules:
            http:
              - method: "POST"
                path: "/api/charge"
    - toFQDNs:
        - matchName: "api.stripe.com"
      toPorts:
        - ports:
            - port: "443"

HTTP-Regeln (“nur POST auf diesen Pfad”), FQDN-basierte Egress-Regeln (“nur zu api.stripe.com”) und identitätsbasierte Selektion in einer Ressource. Für Multi-Tenant-Plattformen ist das Gold wert: “Team A redet nur mit eigenen Services plus Whitelist” lässt sich klar ausdrücken und auditieren — mehr dazu im Artikel über Namespace-Isolation für Multi-Tenancy.

Die Ehrlichkeit gehört dazu: L7-Filterung ist nicht gratis. Sobald eine Policy HTTP- oder Kafka-Regeln enthält, schleust Cilium den betroffenen Traffic durch einen Envoy-Proxy auf dem Node. Das kostet etwas Latenz und schafft eine zusätzliche Komponente, die bei Problemen mituntersucht werden muss. Und FQDN-Policies funktionieren nur, wenn der DNS-Traffic der Pods durch Ciliums DNS-Proxy läuft — eine entsprechende DNS-Regel in der Policy ist Pflicht, sonst kennt Cilium die IP-Auflösung hinter dem Namen nicht. L3/L4-Regeln bleiben dagegen komplett im eBPF-Pfad und sind praktisch kostenlos.

Kube-Proxy ersetzen — und die Randbedingungen

Cilium kann kube-proxy vollständig ersetzen und Service-Load-Balancing in eBPF abwickeln. Statt langer iptables-Ketten, die pro Paket linear durchlaufen werden, gibt es Hash-Map-Lookups — bei Clustern mit tausenden Services ist der Unterschied messbar, sowohl in Latenz als auch in der Zeit, die Service-Updates brauchen.

Die Randbedingungen: Cilium will einen aktuellen Linux-Kernel (für die volle Feature-Palette deutlich neuer als das Minimum), und die Konfigurationsfläche ist erheblich größer als bei einfachen CNIs — Tunnel- vs. Native-Routing, IPAM-Modi, Encryption via WireGuard. Jede dieser Entscheidungen ist später nur schwer korrigierbar, deshalb gehört sie an den Anfang des Cluster-Designs, nicht ans Ende. Eine Migration eines bestehenden Clusters von einem anderen CNI ist möglich, aber heikel und will geprobt sein; für neue Cluster ist Cilium dagegen heute oft die Default-Wahl, nicht zuletzt weil die großen Managed-Kubernetes-Anbieter es zunehmend selbst einsetzen.

Im Betrieb verdient der Cilium-Agent selbst Monitoring: Er läuft als DaemonSet auf jedem Node, und sein Ausfall heißt zwar nicht, dass bestehende Verbindungen abreißen — die eBPF-Programme arbeiten im Kernel weiter —, aber neue Pods bekommen keine Netzwerk-Identität mehr. Die mitgelieferten Prometheus-Metriken zu Policy-Drops und Endpoint-Zustand gehören deshalb ins Standard-Dashboard der Plattform.

Wer das Thema strukturiert lernen will — von eBPF-Grundlagen über Policy-Patterns bis Hubble — findet den Einstieg im Cilium-Lernpfad.