- Authors
- Name
- Phillip Pham
- @ddppham
Kubernetes Cilium CNI: eBPF-basierte Netzwerk-Security fuer Production
TL;DR
- Cilium ersetzt iptables durch eBPF-Programme im Linux-Kernel -- das eliminiert den iptables-Overhead bei grossen Clusters.
- CiliumNetworkPolicy bietet L3/L4 plus L7-Filtering (HTTP-Methoden, Pfade, Header, DNS-Domains).
- Hubble liefert Netzwerk-Observability mit Flow-Logs und Service-Maps ohne Sidecar-Proxies.
- Cilium Service Mesh laeuft sidecar-free ueber eBPF -- kein Envoy pro Pod noetig.
- WireGuard-Encryption verschluesselt Pod-zu-Pod-Traffic transparent mit einer Helm-Option.
Warum eBPF statt iptables
Traditionelle CNI-Plugins nutzen iptables fuer Service-Routing und NetworkPolicies. Bei 1.000 Services entstehen ca. 20.000 iptables-Regeln pro Node. Jedes Paket durchlaeuft diese sequentiell. Bei 5.000 Services werden Updates messbar langsam.
eBPF laedt Programme direkt in den Kernel-Netzwerkpfad. Statt linearer Regelabarbeitung nutzt Cilium Hash Maps mit konstantem Lookup.
| Metrik | iptables (kube-proxy) | eBPF (Cilium) |
|---|---|---|
| Service-Routing Latenz | O(n) linear | O(1) konstant |
| Rule-Update bei 5.000 Services | 5-15 Sekunden | Millisekunden |
| Memory pro Node | 50-200 MB | 10-30 MB |
| CPU bei hohem Throughput | Hoch | 30-50% weniger |
| L7-Visibility | Nicht moeglich | Nativ |
Installation via Helm
# Kernel-Version pruefen (Minimum 5.4, empfohlen 5.10+)
uname -r
# Helm-Installation mit kube-proxy Replacement
helm repo add cilium https://helm.cilium.io/
helm install cilium cilium/cilium \
--version 1.16.5 \
--namespace kube-system \
--set kubeProxyReplacement=true \
--set k8sServiceHost="API_SERVER_IP" \
--set k8sServicePort="6443" \
--set hubble.enabled=true \
--set hubble.relay.enabled=true \
--set hubble.ui.enabled=true \
--set encryption.enabled=true \
--set encryption.type=wireguard \
--set bpf.masquerade=true
# Verifizieren
cilium status --wait
cilium connectivity test
Fuer Helm-Grundlagen: Helm Charts Einfuehrung.
EKS-spezifische Installation
helm install cilium cilium/cilium \
--version 1.16.5 \
--namespace kube-system \
--set eni.enabled=true \
--set ipam.mode=eni \
--set egressMasqueradeInterfaces=eth0 \
--set kubeProxyReplacement=true \
--set hubble.enabled=true \
--set hubble.relay.enabled=true \
--set encryption.enabled=true \
--set encryption.type=wireguard
CiliumNetworkPolicy: L3 bis L7
Standard NetworkPolicies arbeiten auf L3/L4. CiliumNetworkPolicy erweitert das um HTTP-Methoden, URL-Pfade und DNS-Domains.
L3/L4 mit DNS-Filterung
apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
name: isolate-production
namespace: production
spec:
endpointSelector:
matchLabels:
app: webapp
ingress:
- fromEndpoints:
- matchLabels:
app: api-gateway
toPorts:
- ports:
- port: "8080"
protocol: TCP
egress:
- toEndpoints:
- matchLabels:
app: database
toPorts:
- ports:
- port: "5432"
protocol: TCP
- toEndpoints:
- matchLabels:
"k8s:io.kubernetes.pod.namespace": kube-system
"k8s:k8s-app": kube-dns
toPorts:
- ports:
- port: "53"
protocol: UDP
rules:
dns:
- matchPattern: "*.production.svc.cluster.local"
L7 HTTP Policy: Methoden und Pfade filtern
apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
name: api-l7-policy
namespace: api
spec:
endpointSelector:
matchLabels:
app: rest-api
ingress:
- fromEndpoints:
- matchLabels:
app: frontend
toPorts:
- ports:
- port: "8080"
protocol: TCP
rules:
http:
- method: GET
path: "/api/v1/products"
- method: POST
path: "/api/v1/orders"
headers:
- 'Content-Type: application/json'
- fromEndpoints:
- matchLabels:
app: admin-panel
toPorts:
- ports:
- port: "8080"
protocol: TCP
rules:
http:
- method: GET
- method: POST
- method: PUT
- method: DELETE
Das Frontend darf nur GET auf Products und POST auf Orders. Das Admin-Panel hat vollen Zugriff. Alles andere wird auf L7-Ebene geblockt.
DNS-aware Policy fuer externe APIs
apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
name: allow-external-apis
namespace: backend
spec:
endpointSelector:
matchLabels:
app: payment-service
egress:
- toFQDNs:
- matchName: "api.stripe.com"
- matchName: "api.paypal.com"
toPorts:
- ports:
- port: "443"
protocol: TCP
- toEndpoints:
- matchLabels:
"k8s:io.kubernetes.pod.namespace": kube-system
"k8s:k8s-app": kube-dns
toPorts:
- ports:
- port: "53"
protocol: UDP
rules:
dns:
- matchPattern: "*"
Cilium loest DNS-Namen auf und aktualisiert die eBPF-Maps automatisch -- auf IP-Ebene waere das bei wechselnden Cloud-IPs kaum umsetzbar. Weitere NetworkPolicy-Strategien: Kubernetes Network Policies Advanced.
Cluster-weite Default-Deny Policy
apiVersion: cilium.io/v2
kind: CiliumClusterwideNetworkPolicy
metadata:
name: deny-external-by-default
spec:
endpointSelector:
matchExpressions:
- key: "k8s:io.kubernetes.pod.namespace"
operator: NotIn
values: ["kube-system", "monitoring", "ingress"]
egress:
- toEntities:
- cluster
- toEndpoints:
- matchLabels:
"k8s:io.kubernetes.pod.namespace": kube-system
"k8s:k8s-app": kube-dns
toPorts:
- ports:
- port: "53"
protocol: UDP
rules:
dns:
- matchPattern: "*"
Hubble: Netzwerk-Observability
Hubble erfasst alle Netzwerk-Flows ueber eBPF -- ohne Sidecar-Proxies, ohne Sampling.
# Hubble CLI installieren
HUBBLE_VERSION=$(curl -s https://raw.githubusercontent.com/cilium/hubble/master/stable.txt)
curl -L --remote-name-all \
"https://github.com/cilium/hubble/releases/download/${HUBBLE_VERSION}/hubble-linux-amd64.tar.gz"
tar xzvf hubble-linux-amd64.tar.gz -C /usr/local/bin
# Port-Forward und Flows beobachten
cilium hubble port-forward &
hubble observe --namespace production
hubble observe --verdict DROPPED
hubble observe --from-label "app=frontend" --to-label "app=api"
# Hubble UI (Service Map)
cilium hubble ui
Die Hubble UI zeigt eine interaktive Service Map. Gedroppte Flows sind rot markiert -- hilfreich um nach dem Aktivieren von Policies legitimen Traffic zu pruefen.
Prometheus-Metriken
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
name: hubble
namespace: kube-system
spec:
selector:
matchLabels:
app.kubernetes.io/name: hubble
endpoints:
- port: peer-metrics
interval: 30s
Wichtige Metriken:
hubble_flows_processed_total # Verarbeitete Flows
hubble_drop_total # Drops nach Grund
hubble_dns_queries_total # DNS-Queries nach Domain
hubble_http_requests_total # HTTP-Requests nach Methode/Status
Fuer die vollstaendige Monitoring-Strategie: Kubernetes Monitoring und Observability.
WireGuard Transparent Encryption
# Bei bestehender Installation aktivieren
helm upgrade cilium cilium/cilium \
--namespace kube-system --reuse-values \
--set encryption.enabled=true \
--set encryption.type=wireguard
cilium encrypt status
Performance-Impact:
Ohne Encryption: ~9.4 Gbit/s (Pod-zu-Pod, 10G NIC)
Mit WireGuard: ~8.8 Gbit/s (ca. 6% Overhead)
Mit IPsec: ~7.2 Gbit/s (ca. 23% Overhead)
WireGuard nutzt Curve25519 und ChaCha20-Poly1305 direkt im Kernel.
Cilium Service Mesh: Sidecar-Free
Cilium nutzt eBPF fuer L4-Features (mTLS, Load Balancing) direkt im Kernel. Fuer L7-Features wird ein gemeinsamer Envoy pro Node genutzt statt pro Pod.
helm upgrade cilium cilium/cilium \
--namespace kube-system --reuse-values \
--set gatewayAPI.enabled=true
| Aspekt | Istio (Sidecar) | Cilium Service Mesh |
|---|---|---|
| Memory Overhead | 50-100 MB pro Pod | 0 (eBPF) bzw. geteilt |
| Latenz-Overhead | 2-5 ms pro Hop | Unter 1 ms |
| mTLS | Envoy Sidecar | WireGuard (Kernel) |
| Restart bei Upgrade | Alle Pods | Rolling Cilium Agent Update |
Fuer einen Service-Mesh-Vergleich: Istio vs. Linkerd.
Cilium vs. Calico
| Feature | Cilium | Calico |
|---|---|---|
| Dataplane | eBPF | iptables oder eBPF |
| L7 NetworkPolicies | Nativ | Nur ueber Istio-Integration |
| Observability | Hubble (eingebaut) | Erfordert Dritttools |
| Service Mesh | Sidecar-free (eingebaut) | Nicht nativ |
| BGP-Support | Ja | Ja (ausgereifter) |
| Kernel-Anforderung | 5.4+ | 4.x |
| CNCF Status | Graduated (2024) | Graduated (2023) |
Empfehlung: Cilium bei L7-Policies, integrierter Observability oder sidecar-freiem Service Mesh. Calico bei bestehenden Setups oder aelteren Kernel-Versionen.
Migration von Calico zu Cilium
# Schritt 1: Backup
kubectl get networkpolicies -A -o yaml > networkpolicies-backup.yaml
kubectl get globalnetworkpolicies.crd.projectcalico.org -o yaml > calico-gnp-backup.yaml
# Schritt 2: Node-fuer-Node Migration
kubectl drain node-1 --ignore-daemonsets --delete-emptydir-data
helm uninstall calico -n calico-system
helm install cilium cilium/cilium \
--version 1.16.5 --namespace kube-system \
--set kubeProxyReplacement=true \
--set hubble.enabled=true \
--set encryption.enabled=true \
--set encryption.type=wireguard
kubectl uncordon node-1
cilium connectivity test
Standard Kubernetes NetworkPolicies funktionieren mit beiden CNIs unveraendert. Calico GlobalNetworkPolicies muessen in CiliumClusterwideNetworkPolicies konvertiert werden. Weitere Netzwerk-Segmentierungsstrategien: Kubernetes Network Segmentation.
Troubleshooting
# Cilium Status
cilium status
# Agent-Logs
kubectl logs -n kube-system -l k8s-app=cilium --tail=50
# Endpoint-Status
kubectl get ciliumendpoints -n production
# Gedroppte Pakete analysieren
hubble observe --verdict DROPPED --namespace production
# Connectivity-Probleme debuggen
cilium connectivity test --single-node
Fazit
Cilium hat sich als das CNI fuer moderne Kubernetes-Cluster etabliert. Die eBPF-Architektur loest Performance-Probleme bei grossen Clusters, und die integrierten Features -- L7-Policies, Hubble, WireGuard, Service Mesh -- reduzieren die Einzelkomponenten im Cluster erheblich.
Verwandte Artikel
- Kubernetes Network Policies Advanced
- Kubernetes Network Segmentation Defense
- Istio vs. Linkerd Vergleich
- Kubernetes Monitoring und Observability
- Helm Charts fuer Kubernetes
Braucht ihr Unterstuetzung bei der Cilium-Einfuehrung oder der Migration von einem anderen CNI? Kontaktiert uns fuer eine individuelle Beratung.
Kubernetes-Beratung gesucht?
Wir helfen deutschen Unternehmen bei der Kubernetes-Implementierung, Migration und Optimierung. DSGVO-konform und praxiserprobt.
📖 Verwandte Artikel
Weitere interessante Beiträge zu ähnlichen Themen
CNI-Vergleich: Calico vs Cilium für Kubernetes
Calico und Cilium im direkten Vergleich: Architektur, Performance, Network Policies und Observability. Welches CNI-Plugin passt zu deinem Cluster?
Cilium vs Calico: eBPF vs iptables CNI Vergleich
Cilium und Calico im technischen Vergleich: eBPF vs iptables Performance, NetworkPolicies, Observability und Komplexität. Mit Entscheidungshilfe für euer Cluster.
Kubernetes Insider Threat Detection: Strategien für umfassende Clustersicherheit
Entdecke effektive Strategien für die umfassende Kubernetes Insider Threat Detection. Lerne, wie du Innentäter durch lückenloses Monitoring, Behavioral Analytics und fortschrittliche Runtime Security in deinen Kubernetes-Clustern frühzeitig erkennst und die Sicherheit sowie Compliance nachhaltig stärkst.
Network Policies: Kubernetes-Traffic richtig absichern
Kubernetes erlaubt standardmäßig allen Pod-Traffic. Mit Network Policies sichern Sie Ingress und Egress gezielt ab. Praxis-Guide mit YAML-Beispielen.
Netzwerk-Mikrosegmentierung in Kubernetes umsetzen
Mikrosegmentierung in Kubernetes mit Default-Deny, Zonen-Architektur und Cilium ClusterWide NetworkPolicy praktisch umsetzen.