Einführung in Cilium

Ausgehend von einem Kubernetes-Cluster ohne belastbare Sicht auf den Datenpfad ordnen die Teilnehmenden CNI, Cilium Agent, Operator, Hubble und den eBPF-basierten Datenpfad ein. An einer vorbereiteten Anwendung verfolgen sie Zuständigkeiten vom Pod-Start bis zur Kommunikation und markieren, welche Komponente Konfiguration verteilt, Verkehr verarbeitet oder Beobachtungsdaten liefert.

Eine Cilium-Installation ist nur so gut wie ihre Voraussetzungen und gewählten Modi. Die Teilnehmenden prüfen Kernel-Funktionen, CNI-Zustand, Routing- und IPAM-Rahmenbedingungen, leiten daraus passende Installationswerte ab und installieren Cilium mit CLI oder Helm in der Laborumgebung. Ein erfolgreiches cilium status --wait liefert den ersten reproduzierbaren Abnahmepunkt.

Nach der Installation ist eine grüne Statusanzeige noch kein Netzwerkmodell. Die Teilnehmenden verfolgen einen Pod-zu-Pod- und einen Service-Aufruf über Endpoints, Sicherheitsidentitäten, Routing und Load Balancing. Sie halten Quellidentität, Ziel, Pfad und erwartete Antwort fest und gleichen ihre Hypothese mit den Zuständen von Cilium und Kubernetes ab.

Wenn Abhängigkeiten nur als IP-Adressen erscheinen, bleiben Fehler und Verantwortungen schwer zuzuordnen. Die Gruppe aktiviert Hubble Relay, nutzt die Hubble CLI als primäres Werkzeug und die Open-Source-UI optional als Service Map. Sie erzeugt definierten Testverkehr und filtert aktuelle Flows nach Namespace, Pod, Richtung und Verdict. Am Ende belegt ein dokumentierter CLI-Filter den erwarteten Servicepfad sowie einen bewusst fehlgeschlagenen Aufruf.

Ein installierter CNI braucht eine reproduzierbare Abnahme statt einzelner Ping-Tests. Die Teilnehmenden führen den Cilium Connectivity Test aus, unterscheiden Testfehler von Infrastrukturproblemen und prüfen ausgewählte Pfade zusätzlich mit Hubble. Der Block endet mit einer Baseline aus Status, erfolgreichen Prüfungen und einer begründeten Abweichung, die später als Vergleich dient.

Offene Pod-Kommunikation wird nicht sofort mit einer langen Regelliste sicher. Aus definiertem Testverkehr und aktuellen Hubble-Flows erstellen die Teilnehmenden manuell eine minimale Kommunikationsmatrix für die Testanwendung, vergleichen Kubernetes NetworkPolicy mit CiliumNetworkPolicy und führen Default Deny kontrolliert ein. Vorher-Nachher-Tests belegen, welche Verbindung gewollt blockiert wird und welche Geschäftsverbindung erhalten bleibt.

Wechselnde Pod-IP-Adressen dürfen eine Zugriffskontrolle nicht unbrauchbar machen. Die Teilnehmenden formulieren L3/L4-Regeln mit Labels, Namespaces, Ports und Cilium-Identitäten im Cluster, provozieren einen falsch gewählten Selector und korrigieren ihn anhand realisierter Endpoint-Policy. Das Ergebnis ist eine getestete Regel, deren erlaubte und verweigerte Pfade eindeutig dokumentiert sind.

Ausgehende Zugriffe auf externe Dienste lassen sich selten dauerhaft mit einzelnen IP-Adressen beschreiben. Die Gruppe baut mit CiliumNetworkPolicy eine DNS- und FQDN-basierte Egress-Regel, erlaubt die notwendige Namensauflösung und prüft Antworten sowie TTL-abhängige Zustände in der Testanwendung. Hubble und Cilium-Policydaten zeigen anschließend, dass nur das vorgesehene Ziel erreichbar bleibt.

Ein freigegebener TCP-Port sagt noch nicht, welche HTTP-Aktion zulässig sein soll. Die Teilnehmenden ergänzen eine CiliumNetworkPolicy mit HTTP-L7-Regeln für Methode und Pfad, ordnen die Rolle des Envoy-Proxys ein und testen im Lab erlaubte sowie verweigerte Requests. Sichtbare HTTP-Verdicts bestätigen die Wirkung und machen die zusätzliche Betriebsabhängigkeit transparent.

Eine fachlich plausible Policy kann durch Selektoren, Richtung oder DNS-Zustand trotzdem unerwartet blockieren. In einem vorbereiteten Fehlerfall arbeiten die Teilnehmenden von einem Hubble-Drop über Endpoint und realisierte Policy bis zur verursachenden Regel. Sie beheben ausschließlich die falsche Annahme und beweisen mit positiven und negativen Tests, dass die Grenze erhalten bleibt.

Service-Erreichbarkeit darf nicht als Blackbox enden. In einem Cluster mit aktivem kube-proxy Replacement stellen die Teilnehmenden ClusterIP- und NodePort-Services bereit, prüfen deren Pfade, vergleichen EndpointSlices mit Cilium-Servicezustand und untersuchen die zugehörige BPF-LB-Map. Der Test ist erfolgreich, wenn alle erwarteten Backends programmiert und über die vorgesehenen Pfade erreichbar sind.

Verschlüsselung ist erst belastbar, wenn Umfang und Ausschlüsse überprüft werden. Die Teilnehmenden aktivieren transparente WireGuard-Verschlüsselung in der Laborumgebung, prüfen Node-Voraussetzungen und erzeugen Verkehr über mehrere Nodes. cilium-dbg status, WireGuard-Peers und Verkehr auf cilium_wg0 belegen verschlüsselte Cross-Node-Pfade; Hubble korreliert die Workload-Flows, die separat bewertet werden müssen.

Bei einer Störung entscheidet die Reihenfolge der Signale darüber, wie schnell falsche Hypothesen ausscheiden. Die Gruppe erstellt einen Diagnosepfad aus cilium status, Endpoint-Zustand, Logs, Health und Connectivity Tests und sammelt mit cilium sysdump ein übergabefähiges Paket. Vor dem Teilen identifiziert sie sensible Inhalte und dokumentiert den kleinsten belastbaren Befund.

Bleibt ein Datenpfad- oder Policy-Problem unterhalb der Hubble-Sichtbarkeit, führt die Diagnose gezielt zu eBPF. Die Teilnehmenden korrelieren Endpoint und Node, prüfen relevante Programme und Cilium-Maps für IP-Cache, Policy oder Load Balancing und nutzen bei Bedarf bpftool. Sie programmieren kein eBPF, sondern belegen eine konkrete Abweichung zwischen gewünschtem und realisiertem Zustand.

Zum Abschluss verbindet ein vorbereiteter Vorfall Installation, Servicepfad, Policy und Observability. Die Teilnehmenden priorisieren Hypothesen, stellen die fehlerhafte Konfiguration wieder her und liefern einen Evidenzsatz aus Status, Flow, Policy und gegebenenfalls eBPF-Zustand. Danach übertragen sie das Vorgehen in eine Rollout-Checkliste mit Verantwortlichkeiten, Prüfpunkten und klaren Eskalationsgrenzen.