In diesem Artikel geben wir eine Einführung in Cilium , eine Netzwerklösung für Kubernetes, die eBPF für leistungsstarke Netzwerkaufgaben, Sicherheit und Beobachtbarkeit verwendet. Wir behandeln die Installation von Cilium, die Konfiguration von Netzwerkrichtlinien und die Verwendung von Hubble zur Beobachtbarkeit.

Einführung in Cilium und seine Verwendung in Kubernetes

Cilium ist eine Netzwerklösung für Kubernetes, die fortschrittliche Netzwerk- und Sicherheitsfunktionen bietet. Sie verwendet eBPF, um leistungsstarke Netzwerkaufgaben, Sicherheit und Beobachtbarkeit in Kubernetes durchzuführen.

In diesem Artikel werden wir untersuchen, wie man Cilium für das Kubernetes-Netzwerk verwendet. Wir werden die Grundlagen der Einrichtung von Cilium in einem Cluster, die Konfiguration von Netzwerkrichtlinien und die Verwendung von Hubble zur Beobachtbarkeit behandeln. Wir werden auch bewährte Verfahren für die Verwendung von Cilium in Produktionsumgebungen und die Behebung häufiger Probleme besprechen. Fangen wir an, indem wir Cilium in unseren Kubernetes-Cluster installieren!

Hinweis: Wir empfehlen dir die Verwendung von kind, um dies auf deinem lokalen Rechner auszuprobieren. K3d (das unter der Haube k3s verwendet) enthält in seinen Knoten-Images kein Bash, was dazu führt, dass die Cilium-Installation fehlschlägt.

Cilium installieren

Zunächst müssen wir das Cilium CLI gemäß der Dokumentation installieren.

Sobald die CLI-Installation abgeschlossen ist, können wir Cilium in unseren Cluster installieren, indem wir Folgendes ausführen:

$ cilium install

Dies installiert Cilium in den Cluster, auf den unser aktueller kubectl-Kontext zeigt. Um eine funktionierende Installation zu überprüfen, verwenden wir:

$ cilium status --wait

Die Ausgabe sollte ungefähr so aussehen:

    /¯¯\
 /¯¯\__/¯¯\    Cilium:         OK
 \__/¯¯\__/    Operator:       OK
 /¯¯\__/¯¯\    Hubble:         disabled
 \__/¯¯\__/    ClusterMesh:    disabled
    \__/

DaemonSet         cilium             Desired: 1, Ready: 1/1, Available: 1/1
Deployment        cilium-operator    Desired: 1, Ready: 1/1, Available: 1/1
Containers:       cilium             Running: 1
                  cilium-operator    Running: 1
Cluster Pods:     0/3 managed by Cilium
Image versions    cilium             quay.io/cilium/cilium:v1.12.5@sha256:06ce2b0a0a472e73334a7504ee5c5d8b2e2d7b72ef728ad94e564740dd505be5: 1
                  cilium-operator    quay.io/cilium/operator-generic:v1.12.5@sha256:b296eb7f0f7656a5cc19724f40a8a7121b7fd725278b7d61dc91fe0b7ffd7c0e: 1

Wenn alles gut aussieht, können wir die ordnungsgemäße Netzwerkverbindung überprüfen, indem wir Folgendes ausführen:

$ cilium connectivity test

Dies erstellt einen dedizierten Namespace und führt einige Tests auf vordefinierten Workloads aus, um die Netzwerkverbindung des Clusters zu testen.

Die erfolgreiche Ausgabe sieht wie folgt aus:

All 31 tests (151 actions) successful, 0 tests skipped, 1 scenarios skipped.

Wenn alle Tests erfolgreich durchgeführt wurden, herzlichen Glückwunsch! Wir haben Cilium erfolgreich in unseren Kubernetes-Cluster installiert!

Konfigurieren von Netzwerkrichtlinien mit Cilium

Netzwerkrichtlinien in Kubernetes werden zur Kontrolle und Filterung des Datenverkehrs verwendet. Standardmäßig kann jeder Pod, der in einem Cluster läuft, mit jedem anderen Pod kommunizieren, was je nach Einrichtung unsicher sein kann. Mithilfe von Netzwerkrichtlinien können wir Regeln implementieren, die nur den Verkehr zulassen, den wir explizit zulassen wollen. Cilium ermöglicht es uns, Regeln auf der HTTP-Ebene festzulegen, wodurch die Netzwerkregeln von unserem Anwendungscode entkoppelt werden.

Nun, da Cilium in unserem Cluster läuft, wollen wir es testen, indem wir einige Netzwerkrichtlinien anwenden, um festzulegen, welcher Datenverkehr innerhalb des Clusters sowie nach innen und außen erlaubt ist.

Die häufig verwendete Richtlinie "default-deny-ingress" kann mit Cilium wie folgt implementiert werden:

apiVersion: "cilium.io/v2"
kind: CiliumNetworkPolicy
metadata:
  name: "deny-all-ingress"
spec:
  endpointSelector:
    matchLabels:
  ingress:
  - {}

Da der matchLabels-Schlüssel leer ist, wird dies auf jeden Endpunkt angewendet und sperrt effektiv den gesamten eingehenden Datenverkehr innerhalb des Clusters.

Da wir möchten, dass unsere Dienste miteinander kommunizieren, fügen wir eine Richtlinie hinzu, die explizit den eingehenden Datenverkehr zwischen zwei Diensten erlaubt.

Eine einfache "ingress-allow" Richtlinie könnte wie folgt aussehen:

apiVersion: "cilium.io/v2"
kind: CiliumNetworkPolicy
metadata:
  name: "ingress-allow"
spec:
  endpointSelector:
    matchLabels:
      role: backend-api
  ingress:
  - fromEndpoints:
    - matchLabels:
        role: client

Diese Netzwerkrichtlinie erlaubt allen eingehenden Datenverkehr von Endpunkten mit dem Label role: client, die sich mit Endpunkten mit dem Label role: backend-api.

Bewegen wir uns auf den OSI-Modellschichten nach oben, können wir auch HTTP-Methoden und Pfade wie folgt einschränken:

apiVersion: "cilium.io/v2"
kind: CiliumNetworkPolicy
metadata:
  name: "rule1"
spec:
  description: "Allow HTTP GET /api from app=client to app=api"
  endpointSelector:
    matchLabels:
      app: api
  ingress:
  - fromEndpoints:
    - matchLabels:
        app: client
    toPorts:
    - ports:
      - port: "80"
        protocol: TCP
      rules:
        http:
        - method: "GET"
          path: "/api"

Dies erlaubt eingehenden HTTP-Verkehr von Endpunkten mit dem Label app: client zu Endpunkten mit dem Label app: api, solange die HTTP-Methode GET ist und der Pfad "/public" ist. Anfragen an andere Ports als 80 werden abgelehnt, während andere HTTP-Verben und andere Pfade abgelehnt werden.

Cilium für Observability verwenden

Cilium Hubble ist ein leistungsstarkes Observability-Tool, das tiefe Einblicke in den Netzwerkverkehr und die Sicherheit eines Kubernetes-Clusters bietet. In diesem Abschnitt werden wir erkunden, wie man Hubble für Observability einrichtet und verwendet.

Einrichten von Hubble

Um Hubble zu verwenden, müssen wir es, wie folgt, in unserem Kubernetes-Cluster bereitstellen:

$ cilium hubble enable --ui

Wenn wir "cilium status" erneut ausführen, sehen wir, dass Hubble aktiviert und ausgeführt wird.

Um die gesammelten Daten zu nutzen, installieren wir das Hubble CLI wie in der Dokumentation beschrieben. Sobald die Installation abgeschlossen ist, können wir den Hubble-API-Zugriff überprüfen, indem wir zuerst ein Port-Forwarding für Hubble erstellen und dann die Hubble CLI verwenden, um den Hubble-Status zu überprüfen und die API abzufragen. Dies geschieht wie folgt:

$ cilium hubble port-forward&
$ hubble status
$ hubble observe
Apr  4 07:14:29.119: 10.244.0.166:37906 (host) -> cilium-test/echo-same-node-9f8754876-ns7tx:8181 (ID:2357) to-endpoint FORWARDED (TCP Flags: ACK)
Apr  4 07:14:29.120: 10.244.0.166:41980 (host) <- cilium-test/echo-same-node-9f8754876-ns7tx:8080 (ID:2357) to-stack FORWARDED (TCP Flags: ACK, PSH)
Apr  4 07:14:29.121: 10.244.0.166:41980 (host) -> cilium-test/echo-same-node-9f8754876-ns7tx:8080 (ID:2357) to-endpoint FORWARDED (TCP Flags: ACK, FIN)
Apr  4 07:14:29.121: 10.244.0.166:41980 (host) <- cilium-test/echo-same-node-9f8754876-ns7tx:8080 (ID:2357) to-stack FORWARDED (TCP Flags: ACK, FIN)
Apr  4 07:14:29.121: 10.244.0.166:41980 (host) -> cilium-test/echo-same-node-9f8754876-ns7tx:8080 (ID:2357) to-endpoint FORWARDED (TCP Flags: ACK)
Apr  4 07:14:30.119: 10.244.0.166:41986 (host) -> cilium-test/echo-same-node-9f8754876-ns7tx:8080 (ID:2357) to-endpoint FORWARDED (TCP Flags: SYN)
Apr  4 07:14:30.119: 10.244.0.166:41986 (host) <- cilium-test/echo-same-node-9f8754876-ns7tx:8080 (ID:2357) to-stack FORWARDED (TCP Flags: SYN, ACK)
Apr  4 07:14:30.119: 10.244.0.166:41986 (host) -> cilium-test/echo-same-node-9f8754876-ns7tx:8080 (ID:2357) to-endpoint FORWARDED (TCP Flags: ACK)
Apr  4 07:14:30.119: 10.244.0.166:37912 (host) -> cilium-test/echo-same-node-9f8754876-ns7tx:8181 (ID:2357) to-endpoint FORWARDED (TCP Flags: SYN)
Apr  4 07:14:30.119: 10.244.0.166:37912 (host) <- cilium-test/echo-same-node-9f8754876-ns7tx:8181 (ID:2357) to-stack FORWARDED (TCP Flags: SYN, ACK)
Apr  4 07:14:30.119: 10.244.0.166:37912 (host) -> cilium-test/echo-same-node-9f8754876-ns7tx:8181 (ID:2357) to-endpoint FORWARDED (TCP Flags: ACK)
Apr  4 07:14:30.119: 10.244.0.166:37912 (host) -> cilium-test/echo-same-node-9f8754876-ns7tx:8181 (ID:2357) to-endpoint FORWARDED (TCP Flags: ACK, PSH)
Apr  4 07:14:30.119: 10.244.0.166:41986 (host) -> cilium-test/echo-same-node-9f8754876-ns7tx:8080 (ID:2357) to-endpoint FORWARDED (TCP Flags: ACK, PSH)
Apr  4 07:14:30.120: 10.244.0.166:37912 (host) <- cilium-test/echo-same-node-9f8754876-ns7tx:8181 (ID:2357) to-stack FORWARDED (TCP Flags: ACK, PSH)
Apr  4 07:14:30.120: 10.244.0.166:37912 (host) <- cilium-test/echo-same-node-9f8754876-ns7tx:8181 (ID:2357) to-stack FORWARDED (TCP Flags: ACK, FIN)
Apr  4 07:14:30.120: 10.244.0.166:37912 (host) -> cilium-test/echo-same-node-9f8754876-ns7tx:8181 (ID:2357) to-endpoint FORWARDED (TCP Flags: ACK, FIN)
Apr  4 07:14:30.120: 10.244.0.166:37912 (host) -> cilium-test/echo-same-node-9f8754876-ns7tx:8181 (ID:2357) to-endpoint FORWARDED (TCP Flags: ACK)
Apr  4 07:14:30.121: 10.244.0.166:41986 (host) <- cilium-test/echo-same-node-9f8754876-ns7tx:8080 (ID:2357) to-stack FORWARDED (TCP Flags: ACK, PSH)
Apr  4 07:14:30.121: 10.244.0.166:41986 (host) -> cilium-test/echo-same-node-9f8754876-ns7tx:8080 (ID:2357) to-endpoint FORWARDED (TCP Flags: ACK, FIN)
Apr  4 07:14:30.121: 10.244.0.166:41986 (host) <- cilium-test/echo-same-node-9f8754876-ns7tx:8080 (ID:2357) to-stack FORWARDED (TCP Flags: ACK, FIN)

Wenn du grafische Benutzeroberflächen bevorzugst, kannst du auch Hubble UI in deinem Cluster bereitstellen. Hubble UI bietet dir Zugriff auf eine grafische Servicemap, die zur visuellen Überprüfung des Datenverkehrs im Cluster verwendet werden kann. Für unser Beispiel-Setup sieht Hubble UI folgendermaßen aus:

Fazit

Zusammenfassend bietet Cilium eine robuste Netzwerklösung für Kubernetes, die es Benutzern ermöglicht, präzise Netzwerkrichtlinien durchzusetzen und Netzwerkaktivitäten in Echtzeit zu verfolgen. Durch sein cloud-natives Design und seine auf eBPF basierende Architektur ist Cilium die erste Wahl für Benutzer, die erweiterte Netzwerkfunktionen in ihren Kubernetes-Setups suchen.

Weitere Schritte

Cilium bietet noch viele weitere Funktionen, die wir in diesem Beitrag nicht behandeln können. Hier ist eine kurze Zusammenfassung dessen, wozu Cilium noch fähig ist.

Cluster Mesh

Mit Cluster Mesh können wir Netzwerkpfade über mehrere Kubernetes-Cluster hinweg erweitern, sodass Endpunkte in verbundenen Clustern miteinander kommunizieren können, während gleichzeitig Netzwerkrichtlinien durchgesetzt werden.

Service Mesh

Cilium Service Mesh zielt darauf ab, traditionelle Service-Mesh-Lösungen wie Linkerd zu ersetzen. Es gibt jedoch einen entscheidenden Unterschied: Während Linkerd auf Sidecar-Proxies zur Verwaltung des Datenverkehrs zwischen Pods angewiesen ist, verwendet Cilium Service Mesh auf der Knotenebene eBPF, um den Datenverkehr zu verwalten. Dies verbessert die Leistung, reduziert die Last und entkoppelt den Service Mesh weiter von den tatsächlichen Workloads.