9 Kubernetes kube-proxy: Pod-zu-Pod-Kommunikation und Service-Netzwerk

Dieses Kapitel behandelt die zentrale Rolle von kube-proxy in der Kubernetes-Netzwerkarchitektur. Es erklärt, wie Pod-zu-Pod-Kommunikation funktioniert, wie Services in Netzwerkrouten übersetzt werden und welche verschiedenen Implementierungsmodi für unterschiedliche Skalierungsanforderungen existieren.

9.1 Big Picture - Service-Netzwerk-Architektur

kube_proxy_big_picture.svg Übersicht der kube-proxy Architektur mit allen Betriebsmodi und Kommunikationsflüssen zwischen Pods, Services und externen Clients.

9.2 Überblick der kube-proxy Funktionen

Funktion Beschreibung Implementierung
Service Discovery Übersetzung von Service-Namen in Pod-IPs Watch API Server für Services/Endpoints
Load Balancing Verteilung eingehender Requests auf verfügbare Pods iptables/IPVS Rules, Round-Robin/Weighted
Network Translation DNAT von ClusterIPs zu Pod-IPs Kernel-basierte NAT-Regeln
Session Affinity Sticky Sessions für stateful Applications Connection Tracking, Source IP Hashing
External Access NodePort und LoadBalancer Implementation Node-weite Port-Bindings
Health-based Routing Routing nur zu “Ready” Pods Endpoints Controller Integration

9.3 Pod-zu-Pod-Kommunikation Grundlagen

9.3.1 Kubernetes Netzwerkmodell

Das Kubernetes-Netzwerkmodell basiert auf einem Flat Network Design, bei dem jeder Pod eine eindeutige IP-Adresse erhält und direkt mit anderen Pods kommunizieren kann - ohne NAT oder komplexe Routing-Mechanismen. Dieses Design vereinfacht die Netzwerkarchitektur erheblich und ermöglicht es Anwendungen, so zu funktionieren, als würden sie auf einem traditionellen physischen Netzwerk laufen.

Kernprinzipien des Flat Network Models:

kube_proxy_flat_network.svg Darstellung des Flat Network Models mit Pod-zu-Pod-Kommunikation über Node-Grenzen hinweg.

9.3.2 CNI-Plugin Integration

Die tatsächliche Implementierung des Flat Network Models erfolgt durch Container Network Interface (CNI) Plugins, die für die Netzwerk-Konfiguration der Pods verantwortlich sind:

CNI-Plugin Netzwerk-Technologie Charakteristikum
Flannel VXLAN Overlay Network Einfach, gut für kleinere Cluster
Calico BGP + iptables/eBPF Native L3-Routing, Network Policies
Weave Mesh-Netzwerk Verschlüsselung, automatische Discovery
Cilium eBPF Hochperformant, L7-Funktionalität
AWS VPC CNI Native VPC Integration Cloud-native, Security Groups

9.3.3 Service Abstraktion - Das Problem der dynamischen Pod-IPs

Obwohl Pods direkt über ihre IP-Adressen kommunizieren können, entstehen in der Praxis erhebliche Herausforderungen:

Probleme ohne Service-Abstraktion:

Service-Lösung:

Services lösen diese Probleme durch eine stabile Abstraktion, die eine konstante IP-Adresse (ClusterIP) und DNS-Namen für eine Gruppe von Pods bereitstellt:

apiVersion: v1
kind: Service
metadata:
  name: web-service
spec:
  selector:
    app: web
  ports:
    - port: 80        # Service-Port (Eingangsport)
      targetPort: 8080 # Container-Port (Zielport)
  type: ClusterIP
  clusterIP: 10.96.0.100  # Stabile virtuelle IP

Service-Abstraktion Vorteile:

9.4 kube-proxy Architektur und Kommunikationsmodell

9.4.1 Rolle von kube-proxy im Cluster

kube-proxy ist die zentrale Komponente, die Services von einer abstrakten Konfiguration in konkrete Netzwerkrouten übersetzt. Es läuft als DaemonSet auf jedem Worker Node und stellt sicher, dass Service-Traffic korrekt an die dahinterliegenden Pods weitergeleitet wird.

Kernaufgaben von kube-proxy:

  1. Watch-basierte Synchronisation: Überwacht Änderungen an Services und Endpoints über API Server Watch-Streams
  2. Regel-Generierung: Erstellt Netzwerkregeln basierend auf aktueller Service-Konfiguration
  3. Kernel-Integration: Synchronisiert Regeln mit Linux-Kernel (iptables/IPVS)
  4. Traffic-Routing: Stellt sicher, dass Service-Requests an verfügbare Pod-Endpoints weitergeleitet werden

kube_proxy_architecture.svg Detaillierte Darstellung der kube-proxy Architektur und Kommunikationsflüsse.

9.4.2 Watch-Mechanismus und Event-basierte Synchronisation

kube-proxy folgt dem Controller-Pattern und reagiert event-basiert auf Cluster-Änderungen:

Watch-Objekte:

Synchronisation-Zyklus:

  1. Event Detection: kube-proxy erhält Watch-Event vom API Server
  2. State Analysis: Vergleich zwischen gewünschtem (Service-Spec) und aktuellem Zustand (Kernel-Regeln)
  3. Rule Generation: Erstellung der benötigten Netzwerkregeln
  4. Kernel Sync: Atomare Anwendung der Regeln im Linux-Kernel
  5. Status Reporting: Rückmeldung über erfolgreiche Synchronisation

9.4.3 Service-Zustandsmodell

Services durchlaufen verschiedene Zustände, die kube-proxy entsprechend behandelt:

Service-Zustand Beschreibung kube-proxy Aktion
Active mit Endpoints Service hat verfügbare, ready Pods Erstellt Routing-Regeln zu Pod-IPs
Active ohne Endpoints Service definiert, aber keine ready Pods Erstellt Service-IP, aber keine Backend-Regeln
Terminating Service wird gelöscht Entfernt alle zugehörigen Routing-Regeln
External Service Service zeigt auf externe IP Spezielle Routing-Regeln für externe Ziele

9.5 Betriebsmodi von kube-proxy

9.5.1 Historische Entwicklung und Modus-Evolution

Die verschiedenen kube-proxy Betriebsmodi spiegeln die Evolution der Kubernetes-Netzwerkperformance und -skalierung wider:

Modus Einführung Status Skalierung Performance
Userspace Kubernetes 1.0 Deprecated Niedrig (<100 Services) Niedrig
iptables Kubernetes 1.1 Standard Mittel (100-5k Services) Mittel
IPVS Kubernetes 1.9 Empfohlen Hoch (5k+ Services) Hoch

9.5.2 Userspace-Modus (Legacy)

Der Userspace-Modus war die ursprüngliche Implementierung von kube-proxy und funktioniert als TCP/UDP-Proxy im User-Space:

Funktionsweise:

Client → iptables (redirect) → kube-proxy (userspace) → TCP-Proxy → Pod

Charakteristika:

Limitierungen:

9.5.3 iptables-Modus (Standard)

Der iptables-Modus eliminiert den User-Space-Proxy und implementiert Service-Routing direkt im Linux-Kernel über Network Address Translation (NAT):

Funktionsweise:

Client → iptables (DNAT) → Pod (direkt)

Regel-Hierarchie:

KUBE-SERVICES (Eingangsregeln für alle Services)
    ↓
KUBE-SVC-[SERVICE-HASH] (Service-spezifische Load-Balancing-Kette)
    ↓
KUBE-SEP-[ENDPOINT-HASH] (Endpoint-spezifische DNAT-Regeln)

Load-Balancing-Mechanismus:

Vorteile:

Limitierungen:

Darstellung des Packet-Flows durch iptables-Regelketten für Service-Routing.

9.5.4 IPVS-Modus (High Performance)

Der IPVS-Modus nutzt das IP Virtual Server Subsystem des Linux-Kernels für hochperformantes Layer-4-Load-Balancing:

Funktionsweise:

Client → IPVS (Virtual Server) → Real Server (Pod) (direkt)

IPVS-Konzepte:

Load-Balancing-Algorithmen:

Algorithmus Abkürzung Beschreibung Use Case
Round Robin rr Gleichmäßige Rotation Standard für homogene Pods
Weighted Round Robin wrr Gewichtete Rotation Pods mit unterschiedlicher Kapazität
Least Connection lc Verbindung zu Pod mit wenigsten aktiven Connections Long-running Connections
Weighted Least Connection wlc Gewichtet + Least Connection Heterogene Pods + Connection-sensitive
Source Hash sh Hash der Client-IP Session Affinity
Destination Hash dh Hash der Ziel-IP Seltener verwendet

Vorteile:

Voraussetzungen:

Performance-Charakteristika:

Metrik iptables IPVS Verbesserung
Service Lookup O(n) O(1) ~100x bei 10k Services
Rule Sync Time 10+ Sekunden <1 Sekunde ~10x schneller
Memory Usage Hoch bei vielen Regeln Konstant ~50% weniger
CPU Overhead Steigend mit Regeln Konstant ~30% weniger

9.6 Service-Typen und Netzwerk-Implementation

9.6.1 ClusterIP Services - Interne Cluster-Kommunikation

ClusterIP ist der Standard-Service-Typ für interne Cluster-Kommunikation. Er stellt eine virtuelle IP-Adresse bereit, die nur innerhalb des Clusters erreichbar ist:

apiVersion: v1
kind: Service
metadata:
  name: backend-api
spec:
  type: ClusterIP                # Standard-Type (kann weggelassen werden)
  selector:
    app: backend
  ports:
    - port: 3000                 # Service-Port (eingehend)
      targetPort: 8080           # Container-Port (ausgehend)
  clusterIP: 10.96.1.100         # Automatisch zugewiesen oder manuell gesetzt

ClusterIP-Eigenschaften:

Typische Verwendung:

9.6.2 NodePort Services - Externe Zugänglichkeit

NodePort-Services erweitern ClusterIP-Services um externe Erreichbarkeit durch Öffnung eines Ports auf allen Cluster-Nodes:

apiVersion: v1
kind: Service
metadata:
  name: web-frontend
spec:
  type: NodePort
  selector:
    app: web
  ports:
    - port: 80                   # ClusterIP-Port (intern)
      targetPort: 8080           # Container-Port
      nodePort: 30080            # Node-Port (extern, 30000-32767)

NodePort-Traffic-Flow:

External Client → NodeIP:30080 → ClusterIP:80 → PodIP:8080

NodePort-Charakteristika:

Praktische Überlegungen:

9.6.3 LoadBalancer Services - Cloud-Integration

LoadBalancer-Services nutzen Cloud-Provider-spezifische Load-Balancer für professionelle externe Zugänglichkeit:

apiVersion: v1
kind: Service
metadata:
  name: public-api
  annotations:
    service.beta.kubernetes.io/aws-load-balancer-type: nlb
    service.beta.kubernetes.io/aws-load-balancer-scheme: internet-facing
spec:
  type: LoadBalancer
  selector:
    app: api
  ports:
    - port: 443
      targetPort: 8443
status:
  loadBalancer:
    ingress:
    - hostname: api-lb-123456.us-west-2.elb.amazonaws.com

LoadBalancer-Integration:

Cloud Provider Load Balancer Typ Annotations
AWS ELB, ALB, NLB aws-load-balancer-type, aws-load-balancer-scheme
GCP Cloud Load Balancing cloud.google.com/load-balancer-type
Azure Azure Load Balancer service.beta.kubernetes.io/azure-load-balancer-internal
MetalLB On-Premise L2/L3 metallb.universe.tf/address-pool

LoadBalancer-Traffic-Flow:

Internet → Cloud LB → NodePort → ClusterIP → Pod

9.6.4 ExternalName Services - DNS-Delegation

ExternalName-Services bieten DNS-Aliasing für externe Services ohne kube-proxy-Involvement:

apiVersion: v1
kind: Service
metadata:
  name: external-database
spec:
  type: ExternalName
  externalName: prod-db.company.com

Anwendungsfälle:

Vergleichende Darstellung aller Service-Typen und ihrer Netzwerk-Implementation.

9.7 Load Balancing und Traffic-Verteilung

9.7.1 Endpoint-Management und Health-Integration

kube-proxy routing basiert auf dem Endpoints-Controller, der kontinuierlich die Verfügbarkeit und Bereitschaft von Pods überwacht:

Endpoints-Lifecycle:

  1. Pod Creation: Neuer Pod wird erstellt, aber noch nicht ready
  2. Readiness Probe: Kubelet führt Health Checks durch
  3. Endpoint Addition: Bei erfolgreicher Readiness wird Pod zu Endpoints hinzugefügt
  4. Traffic Routing: kube-proxy beginnt mit Traffic-Weiterleitung
  5. Health Monitoring: Kontinuierliche Überwachung der Pod-Readiness
  6. Endpoint Removal: Bei Failure oder Shutdown wird Pod aus Endpoints entfernt

Readiness vs. Liveness Integration:

containers:
- name: app
  readinessProbe:              # Bestimmt Endpoint-Aufnahme
    httpGet:
      path: /ready
      port: 8080
    initialDelaySeconds: 5
  livenessProbe:               # Bestimmt Pod-Restart
    httpGet:
      path: /health
      port: 8080
    initialDelaySeconds: 30

Endpoint-Status und Traffic-Routing:

Pod-Status Readiness Endpoints kube-proxy Routing
Running + Ready True Included Receives Traffic
Running + Not Ready False Excluded No Traffic
Terminating + Ready True Excluded No Traffic (Grace Period)
Failed False Excluded No Traffic

9.7.2 Session Affinity und Persistence

Session Affinity ermöglicht sticky sessions, bei denen aufeinanderfolgende Requests vom gleichen Client an denselben Pod geleitet werden:

ClientIP-basierte Affinity:

spec:
  sessionAffinity: ClientIP
  sessionAffinityConfig:
    clientIP:
      timeoutSeconds: 86400    # 24 Stunden Session-Persistenz

Implementation in verschiedenen Modi:

iptables-Modus:

IPVS-Modus:

Anwendungsfälle für Session Affinity:

Überlegungen und Limitierungen:

9.7.3 EndpointSlices - Skalierbare Endpoint-Verwaltung

EndpointSlices lösen Skalierungsprobleme von traditionellen Endpoints-Objekten bei Services mit vielen Pods:

Traditionelle Endpoints-Limitierungen:

EndpointSlices-Vorteile:

apiVersion: discovery.k8s.io/v1
kind: EndpointSlice
metadata:
  name: web-service-slice-1
  labels:
    kubernetes.io/service-name: web-service
addressType: IPv4
endpoints:
- addresses:
  - "10.244.1.10"
  conditions:
    ready: true
  topology:
    kubernetes.io/hostname: worker-node-1
    topology.kubernetes.io/zone: us-west-2a
ports:
- port: 8080
  protocol: TCP

EndpointSlices-Charakteristika:

9.8 Externe Zugriffe und Traffic Policies

9.8.1 ExternalTrafficPolicy Optionen

ExternalTrafficPolicy bestimmt, wie externer Traffic (NodePort/LoadBalancer) durch den Cluster geleitet wird:

Cluster Policy (Default):

spec:
  externalTrafficPolicy: Cluster

Eigenschaften:

Local Policy:

spec:
  externalTrafficPolicy: Local

Eigenschaften:

Traffic-Flow-Vergleich:

Policy Traffic Flow Source IP Load Distribution
Cluster External → NodeA → NodeB → Pod Node IP Gleichmäßig
Local External → NodeA → Pod (same node) Client IP Pod-Placement abhängig

9.8.2 Ingress vs. Service-basierte externe Zugriffe

Service-basierte Zugriffe (NodePort/LoadBalancer):

Ingress-basierte Zugriffe:

# Service-basiert
apiVersion: v1
kind: Service
metadata:
  name: web
spec:
  type: LoadBalancer
  ports:
  - port: 80
  selector:
    app: web

---
# Ingress-basiert
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: web-ingress
spec:
  rules:
  - host: api.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: web
            port:
              number: 80

Vergleichende Darstellung verschiedener Patterns für externen Cluster-Zugriff.

9.9 Debugging und Troubleshooting

9.9.1 Systematisches Service-Debugging

Bei Service-Connectivity-Problemen ist ein systematischer Layer-by-Layer-Ansatz empfehlenswert:

Layer 1: DNS-Resolution

# DNS-Auflösung testen
kubectl exec -it debug-pod -- nslookup web-service.default.svc.cluster.local

# CoreDNS-Status prüfen
kubectl get pods -n kube-system -l k8s-app=kube-dns
kubectl logs -n kube-system -l k8s-app=kube-dns

Layer 2: Service-Konfiguration

# Service-Definition validieren
kubectl get service web-service -o yaml
kubectl describe service web-service

# Endpoints/EndpointSlices prüfen
kubectl get endpoints web-service
kubectl get endpointslices -l kubernetes.io/service-name=web-service

Layer 3: Pod-Readiness

# Pod-Status und Readiness prüfen
kubectl get pods -l app=web -o wide
kubectl describe pod <pod-name>

# Readiness Probe Logs
kubectl logs <pod-name> --previous

Layer 4: kube-proxy Konfiguration

# kube-proxy Status
kubectl get pods -n kube-system -l k8s-app=kube-proxy
kubectl logs -n kube-system -l k8s-app=kube-proxy

# kube-proxy Konfiguration
kubectl get configmap kube-proxy -n kube-system -o yaml

9.9.2 Netzwerk-Level Debugging

iptables-Modus Debugging:

# Service-spezifische Regelketten anzeigen
iptables -t nat -L KUBE-SERVICES -n --line-numbers
iptables -t nat -L KUBE-SVC-<SERVICE-HASH> -n

# Packet-Zähler für Traffic-Analysis
iptables -t nat -L -n -v | grep <service-ip>

# Connection-Tracking für aktive Sessions
conntrack -L -p tcp --dport 80 | grep <service-ip>

IPVS-Modus Debugging:

# Virtual Services auflisten
ipvsadm -Ln

# Service-spezifische Real Servers
ipvsadm -Ln -t <service-ip>:<port>

# Connection-Statistiken
ipvsadm -Ln --stats --connection

# Rate-Limiting und Performance-Metriken
ipvsadm -Ln --rate

Network Connectivity Testing:

# ClusterIP-Erreichbarkeit testen
kubectl run debug --image=nicolaka/netshoot -it --rm
# Im Pod:
curl -v http://<service-ip>:<port>
nc -zv <service-ip> <port>

# Pod-zu-Pod direkte Connectivity
curl -v http://<pod-ip>:<container-port>

# DNS-basierte Service-Resolution
curl -v http://<service-name>.<namespace>.svc.cluster.local

9.9.3 Häufige Probleme und Lösungsansätze

Problem: Service nicht erreichbar

Mögliche Ursachen und Debugging:

  1. DNS-Resolution fehlgeschlagen
  2. Keine verfügbaren Endpoints
  3. kube-proxy nicht funktional
  4. Network Policy Blockierung

Problem: Ungleichmäßige Load-Distribution

Ursachen-Analyse:

Problem: Source-IP nicht verfügbar

Typische Szenarien:

Lösungsansätze:

9.10 Performance-Optimierung und Skalierung

9.10.1 Betriebsmodus-Auswahl basierend auf Cluster-Größe

Kleine Cluster (< 100 Services, < 1000 Pods):

Mittlere Cluster (100-1000 Services, 1000-10000 Pods):

Große Cluster (> 1000 Services, > 10000 Pods):

Performance-Metriken für Modus-Entscheidung:

Metrik iptables Limit IPVS Empfehlung
Rules-Sync-Duration > 10 Sekunden < 1 Sekunde
Services × Endpoints > 50.000 Unbegrenzt
CPU-Usage (kube-proxy) > 50% < 10%
Memory-Usage > 2GB < 500MB

9.10.2 Monitoring und Observability

Wichtige kube-proxy Metriken:

Metrik Beschreibung Alert-Threshold
kubeproxy_sync_proxy_rules_duration_seconds Zeit für Regel-Synchronisation > 10s
kubeproxy_sync_proxy_rules_last_timestamp_seconds Letzte erfolgreiche Synchronisation > 300s alt
kubeproxy_sync_proxy_rules_iptables_restore_failures_total Fehlgeschlagene iptables-Updates > 0
kubeproxy_network_programming_duration_seconds End-to-End Network Programming Latenz > 30s

Prometheus AlertManager Regeln:

groups:
- name: kube-proxy
  rules:
  - alert: KubeProxyDown
    expr: up{job="kube-proxy"} == 0
    for: 5m
    annotations:
      summary: "kube-proxy is down"
      
  - alert: KubeProxyRulesSyncLatency
    expr: kubeproxy_sync_proxy_rules_duration_seconds > 10
    for: 2m
    annotations:
      summary: "kube-proxy rules sync is taking too long"

Service-Level Monitoring:

# Service Response Time Monitoring
kubectl run monitoring --image=nicolaka/netshoot --rm -it
# Continuous health checks
while true; do
  curl -w "@curl-format.txt" -o /dev/null -s http://service-name/health
  sleep 5
done

9.10.3 Tuning und Optimierung

kube-proxy Konfiguration-Tuning:

# kube-proxy ConfigMap Optimierung
apiVersion: v1
kind: ConfigMap
metadata:
  name: kube-proxy
  namespace: kube-system
data:
  config.conf: |
    apiVersion: kubeproxy.config.k8s.io/v1alpha1
    kind: KubeProxyConfiguration
    mode: "ipvs"                           # IPVS für bessere Performance
    ipvs:
      scheduler: "rr"                      # Round-Robin Load-Balancing
      syncPeriod: "30s"                    # Reduzierte Sync-Frequenz
      minSyncPeriod: "5s"                  # Minimum zwischen Syncs
    iptables:
      syncPeriod: "30s"
      minSyncPeriod: "10s"
      masqueradeAll: false                 # Nur bei NodePort/LoadBalancer
    metricsBindAddress: "0.0.0.0:10249"    # Metrics-Endpoint
    enableProfiling: true                  # Performance-Profiling

Kernel-Parameter für High-Performance:

# Erhöhung der Connection-Tracking-Limits
echo 'net.netfilter.nf_conntrack_max = 1048576' >> /etc/sysctl.conf
echo 'net.netfilter.nf_conntrack_buckets = 262144' >> /etc/sysctl.conf

# TCP-Optimierung für hohe Connection-Raten
echo 'net.core.somaxconn = 32768' >> /etc/sysctl.conf
echo 'net.ipv4.tcp_max_syn_backlog = 16384' >> /etc/sysctl.conf

# Anwendung der Einstellungen
sysctl -p

9.11 Weiterführende Konzepte und Integration

9.11.1 CNI-Plugin Integration und kube-proxy Interaktion

kube-proxy arbeitet komplementär zu CNI-Plugins - beide haben unterschiedliche Verantwortlichkeiten im Kubernetes-Netzwerk-Stack:

Verantwortlichkeitsaufteilung:

Komponente Verantwortlichkeit Scope
CNI-Plugin Pod-zu-Pod-Kommunikation, IP-Zuweisung, Route-Management L3-Netzwerk (IP-Layer)
kube-proxy Service-zu-Pod-Mapping, Load-Balancing, External Access L4-Abstraktion (Service-Layer)

Beispiel-Integration mit Calico:

# Calico NetworkPolicy beeinflusst Pod-zu-Pod-Traffic
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-all-ingress
spec:
  podSelector: {}
  policyTypes:
  - Ingress

# kube-proxy Service-Regeln haben Vorrang bei Service-Traffic
apiVersion: v1
kind: Service
metadata:
  name: protected-service
spec:
  selector:
    app: protected
  ports:
  - port: 80

Calico + kube-proxy Regel-Hierarchie:

  1. CNI-Plugin-Regeln: Grundlegende Pod-zu-Pod-Connectivity
  2. Network Policy-Regeln: Pod-zu-Pod Access Control
  3. kube-proxy Service-Regeln: Service-zu-Pod Load-Balancing
  4. Application-Level-Rules: Container-interne Firewall

9.11.2 eBPF-basierte Alternativen - Cilium als kube-proxy Replacement

Cilium kube-proxy Replacement bietet eine eBPF-basierte Alternative, die kube-proxy komplett ersetzen kann:

Traditioneller Stack:

Application → Service → kube-proxy (iptables/IPVS) → CNI → Pod

Cilium-basierter Stack:

Application → Service → Cilium eBPF → Pod (direkt)

Cilium Vorteile gegenüber kube-proxy:

Feature kube-proxy Cilium eBPF
Performance Kernel-Space (iptables/IPVS) Kernel-Space (eBPF)
Latenz ~0.1-1ms ~0.01-0.1ms
Skalierung Linear (IPVS) Konstant
L7 Load-Balancing Nicht verfügbar HTTP/gRPC-aware
Observability Begrenzt Umfassend (Hubble)
Security Network Policies extern Integrierte L3-L7-Policies

Cilium kube-proxy Replacement Konfiguration:

# Cilium ConfigMap
apiVersion: v1
kind: ConfigMap
metadata:
  name: cilium-config
  namespace: kube-system
data:
  # kube-proxy Replacement aktivieren
  kube-proxy-replacement: "strict"
  k8s-service-host: "10.0.0.1"
  k8s-service-port: "6443"
  
  # eBPF-Features
  enable-l7-proxy: "true"
  enable-ipv4: "true"
  enable-ipv6: "false"
  
  # Performance-Optimierung
  preallocate-bpf-maps: "true"
  bpf-lb-algorithm: "maglev"          # Konsistentes Hashing

Migration zu Cilium:

# 1. Cilium mit kube-proxy Replacement installieren
helm install cilium cilium/cilium \
  --set kubeProxyReplacement=strict \
  --set k8sServiceHost=<APISERVER_IP> \
  --set k8sServicePort=6443

# 2. kube-proxy DaemonSet entfernen
kubectl delete daemonset kube-proxy -n kube-system

# 3. Validation
cilium status
cilium service list

9.11.3 Service Mesh Integration

Service Mesh (Istio, Linkerd) arbeitet oberhalb von kube-proxy und erweitert Service-Funktionalität:

Architektur-Layer:

Application Layer     │ Service Mesh (Istio/Linkerd)
                     │ ├─ mTLS, Traffic Management
                     │ ├─ Circuit Breaking, Retries
                     │ └─ Observability, Security
────────────────────────────────────────────────────
Service Layer        │ kube-proxy
                     │ ├─ Service Discovery
                     │ ├─ Load Balancing
                     │ └─ External Access
────────────────────────────────────────────────────
Network Layer        │ CNI Plugin (Calico/Flannel)
                     │ ├─ Pod-zu-Pod Networking
                     │ ├─ IP Address Management
                     │ └─ Network Policies

Service Mesh + kube-proxy Interaktion:

9.12 Best Practices und Empfehlungen

9.12.1 Produktions-Best-Practices

Betriebsmodus-Auswahl:

Service-Design-Patterns:

Monitoring und Alerting:

Security-Überlegungen:

9.12.2 Troubleshooting-Checkliste

Bei Service-Connectivity-Problemen:

  1. DNS-Resolution validieren

    nslookup service-name.namespace.svc.cluster.local

  2. Service-Konfiguration prüfen

    kubectl describe service <service-name>
kubectl get endpoints <service-name>

  3. Pod-Readiness verifizieren

    kubectl get pods -l <selector> -o wide

  4. kube-proxy Status kontrollieren

    kubectl get pods -n kube-system -l k8s-app=kube-proxy

  5. Netzwerk-Rules inspizieren

    # iptables-Modus
iptables -t nat -L KUBE-SERVICES

# IPVS-Modus  
ipvsadm -Ln

Performance-Probleme debuggen:

  1. Sync-Latenz messen

    curl http://node-ip:10249/metrics | grep sync_duration

  2. Resource-Usage prüfen

    kubectl top pods -n kube-system -l k8s-app=kube-proxy

  3. Network-Overhead analysieren

    iftop -i eth0  # Network Bandwidth per Interface
ss -tuln       # Active Network Connections

9.12.3 Migration und Upgrade-Strategien

Upgrade von iptables zu IPVS:

# 1. IPVS-Module auf allen Nodes aktivieren
for node in $(kubectl get nodes -o name); do
  kubectl debug $node -it --image=ubuntu -- bash -c "chroot /host modprobe ip_vs ip_vs_rr"
done

# 2. kube-proxy ConfigMap aktualisieren
kubectl patch configmap kube-proxy -n kube-system --patch '
data:
  config.conf: |
    mode: "ipvs"
    ipvs:
      scheduler: "rr"
'

# 3. kube-proxy DaemonSet Rolling Update
kubectl rollout restart daemonset kube-proxy -n kube-system
kubectl rollout status daemonset kube-proxy -n kube-system

# 4. Validation
kubectl get pods -n kube-system -l k8s-app=kube-proxy
ipvsadm -Ln  # Auf Worker Nodes ausführen

Monitoring während Migration: