---
title: "Verwendung von Cilium für Kubernetes-Netzwerke und Beobachtbarkeit"
description: "Erfahre, wie du Cilium eBPF für leistungsstarke Netzwerk-, Sicherheits- und Überwachungsaufgaben in Kubernetes nutzt. Jetzt lesen und Kubernetes optimieren!"
canonical_url: "https://www.blueshoe.de/blog/cilium-kubernetes-networking-observability/"
---
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](https://github.com/kubernetes-sigs/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](https://docs.cilium.io/en/stable/gettingstarted/k8s-install-default/#install-the-cilium-cli) installieren.
Sobald die CLI-Installation abgeschlossen ist, können wir Cilium in unseren Cluster installieren, indem wir Folgendes ausführen:
```docker
$ cilium install
```
Dies installiert Cilium in den Cluster, auf den unser aktueller kubectl-Kontext zeigt. Um eine funktionierende Installation zu überprüfen, verwenden wir:
```docker
$ cilium status --wait
```
Die Ausgabe sollte ungefähr so aussehen:
```docker
/¯¯\
/¯¯\__/¯¯\ 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:
```docker
$ 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:
```docker
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!
UNSER PODCAST: TOOLS FOR THE CRAFT
E3: Deep dive into Getdeck
Michael und Robert stellen Getdeck vor und demonstrieren es. Außerdem vergleichen sie lokale und entfernte Kubernetes- und Pre-Production-Cluster.
Weitere Ausgaben unseres Podcasts findest du hier:
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:
```docker
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:
```docker
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](https://de.wikipedia.org/wiki/OSI-Modell) nach oben, können wir auch HTTP-Methoden und Pfade wie folgt einschränken:
```docker
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:
```docker
$ 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](https://docs.cilium.io/en/stable/gettingstarted/hubble_setup/#install-the-hubble-client) 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](/loesungen/api-entwicklung/) abzufragen. Dies geschieht wie folgt:
```docker
$ 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](https://docs.cilium.io/en/stable/gettingstarted/hubble_setup/#install-the-hubble-client) 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](https://docs.cilium.io/en/stable/network/clustermesh/) 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](https://docs.cilium.io/en/stable/network/servicemesh/) 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.
## Sitemap
See the full [sitemap](/sitemap.md) for all pages.