Proxy in Kubernetes

Proxys in Kubernetes für Pods und Services werden hauptsächlich über Umgebungsvariablen für den ausgehenden Datenverkehr, Sidecar-Container für eine granulare Steuerung und Service-Mesh-Integration sowie Ingress-Ressourcen oder Service-Typen für das Management des eingehenden Datenverkehrs konfiguriert. Dieser Artikel beschreibt die Mechanismen zur Implementierung von Proxy-Konfigurationen in einer Kubernetes-Umgebung.

Egress-Proxy-Konfiguration für Pods

Pods benötigen oft einen Egress-Proxy, um auf externe Netzwerke zuzugreifen, Sicherheitsrichtlinien durchzusetzen oder den Datenverkehr außerhalb des Clusters zu verwalten.

Umgebungsvariablen

Die einfachste Methode zur Konfiguration eines Egress-Proxys für Anwendungen innerhalb eines Pods ist die Verwendung von Standard-HTTP/HTTPS-Proxy-Umgebungsvariablen. Viele Anwendungen und Client-Bibliotheken respektieren diese Variablen automatisch.

• HTTP_PROXY: Gibt einen Proxy-Server für HTTP-Anfragen an.
• HTTPS_PROXY: Gibt einen Proxy-Server für HTTPS-Anfragen an.
• NO_PROXY: Eine durch Kommas getrennte Liste von Hostnamen, Domänen oder IP-Adressen, die den Proxy umgehen sollen. Dies ist entscheidend für die interne Cluster-Kommunikation (z.B. kubernetes.default.svc, 10.0.0.0/8, *.svc.cluster.local).

Diese Variablen werden in der Container-Spezifikation des Pods definiert.

apiVersion: v1
kind: Pod
metadata:
  name: my-app-with-proxy
spec:
  containers:
  - name: my-app
    image: my-application-image:latest
    env:
    - name: HTTP_PROXY
      value: "http://proxy.internal.domain:3128"
    - name: HTTPS_PROXY
      value: "http://proxy.internal.domain:3128"
    - name: NO_PROXY
      value: "localhost,127.0.0.1,.svc,.cluster.local,10.0.0.0/8" # Beispiel: Anpassen für Ihr Cluster-CIDR

Init-Container für dynamische Proxy-Konfiguration

Für komplexere Szenarien kann ein Init-Container Proxy-Konfigurationen vorbereiten oder Zertifikate injizieren, bevor der Hauptanwendungscontainer startet. Dies ist nützlich für:

• Abrufen von Proxy-Details von einem Konfigurationsdienst.
• Generieren von NO_PROXY-Listen basierend auf internen IP-Bereichen des Clusters.
• Injizieren von benutzerdefinierten CA-Zertifikaten, die vom Proxy benötigt werden.

apiVersion: v1
kind: Pod
metadata:
  name: my-app-init-proxy
spec:
  initContainers:
  - name: init-proxy-config
    image: alpine/git # Beispiel: Ein einfaches Image zum Abrufen der Konfiguration
    command: ["sh", "-c", "echo 'HTTP_PROXY=http://dynamic-proxy:3128' > /mnt/proxy/config"]
    volumeMounts:
    - name: proxy-config-volume
      mountPath: /mnt/proxy
  containers:
  - name: my-app
    image: my-application-image:latest
    command: ["sh", "-c", ". /mnt/proxy/config && exec my-app-binary"] # Konfiguration laden
    volumeMounts:
    - name: proxy-config-volume
      mountPath: /mnt/proxy
  volumes:
  - name: proxy-config-volume
    emptyDir: {}

Sidecar-Proxys für Egress

Ein Sidecar-Proxy läuft im selben Pod wie der Anwendungscontainer. Er fängt den gesamten ausgehenden Datenverkehr vom Anwendungscontainer ab und leitet ihn durch den Proxy. Dieses Muster bietet:

• Netzwerktransparenz: Der Anwendungscontainer muss nicht Proxy-aware sein; der Sidecar übernimmt die Proxy-Logik.
• Zentralisierte Richtlinie: Egress-Richtlinien (z.B. Zulassungs-/Verweigerungslisten, Ratenbegrenzung, Authentifizierung) können auf Sidecar-Ebene durchgesetzt werden, unabhängig von der Anwendung.
• Beobachtbarkeit: Der Sidecar kann Metriken, Logs und Traces für den gesamten ausgehenden Datenverkehr emittieren.

Gängige Sidecar-Proxys sind Envoy (von Istio verwendet) oder Linkerd's Proxy.

apiVersion: v1
kind: Pod
metadata:
  name: my-app-with-sidecar-egress
spec:
  containers:
  - name: my-app
    image: my-application-image:latest
    # Anwendungsdatenverkehr wird über iptables-Regeln zum Sidecar umgeleitet
  - name: egress-proxy-sidecar
    image: envoyproxy/envoy:v1.28.0 # Beispiel Envoy-Image
    ports:
    - containerPort: 15001 # Port, an den die Anwendung Datenverkehr sendet
    volumeMounts:
    - name: envoy-config
      mountPath: /etc/envoy
    # Konfiguration für Envoy zur Weiterleitung des Datenverkehrs an einen externen Proxy oder direkt
    # (typischerweise von einer Service-Mesh-Steuerungsebene verwaltet)
  volumes:
  - name: envoy-config
    configMap:
      name: egress-envoy-config

Ingress-Proxy-Konfiguration für Services

Für eingehenden Datenverkehr zu Services bietet Kubernetes mehrere Mechanismen, die von Natur aus Proxying beinhalten.

Kubernetes Services (kube-proxy)

Die kube-proxy-Komponente, die auf jedem Knoten läuft, verwaltet die virtuelle IP (VIP) für Kubernetes Services. Wenn ein Client innerhalb oder außerhalb des Clusters versucht, sich mit der ClusterIP eines Services zu verbinden, fängt kube-proxy den Datenverkehr ab und leitet ihn an einen der Pods weiter, die diesen Service unterstützen. Dies fungiert als Layer-4 (TCP/UDP) Proxy und Load Balancer.

• Modus: kube-proxy arbeitet im iptables- (Standard) oder ipvs-Modus.
  • iptables: Verwendet iptables-Regeln zur Durchführung von NAT und Lastverteilung.
  • ipvs: Verwendet IP Virtual Server (IPVS) für anspruchsvollere Lastverteilungsalgorithmen und bessere Leistung bei einer großen Anzahl von Services.

Dieses Proxying ist automatisch und erfordert keine explizite Konfiguration innerhalb von Pods oder Services, außer der Definition des Services selbst.

apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  selector:
    app: my-app
  ports:
    - protocol: TCP
      port: 80
      targetPort: 8080
  type: ClusterIP # Internes Proxying durch kube-proxy

Ingress-Ressourcen und Ingress-Controller

Für den externen HTTP/HTTPS-Zugriff auf Services wird eine Ingress-Ressource in Verbindung mit einem Ingress-Controller verwendet. Der Ingress-Controller selbst ist ein spezialisierter Proxy, der innerhalb des Clusters läuft.

• Ingress-Controller: Ein Pod (oder eine Reihe von Pods), der einen Proxy wie NGINX, HAProxy, Traefik oder einen AWS ALB/GCE L7 Load Balancer Controller ausführt. Er überwacht Ingress-Ressourcen und konfiguriert seine Proxy-Regeln dynamisch.
• Ingress-Ressource: Definiert Regeln für das Routing von externem HTTP/HTTPS-Datenverkehr zu Services. Dies umfasst hostbasiertes Routing, pfadbasiertes Routing und TLS-Terminierung.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-ingress
spec:
  rules:
  - host: api.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: my-service
            port:
              number: 80
  tls: # Optional: TLS-Terminierung am Ingress-Controller
  - hosts:
    - api.example.com
    secretName: my-tls-secret

LoadBalancer Services

Wenn ein Service vom Typ LoadBalancer erstellt wird, stellt er einen externen Load Balancer (typischerweise vom Cloud-Anbieter) bereit. Dieser externe Load Balancer fungiert als Proxy und leitet den Datenverkehr an die NodePorts des Services weiter, die kube-proxy dann an die unterstützenden Pods routet.

apiVersion: v1
kind: Service
metadata:
  name: my-external-service
spec:
  selector:
    app: my-app
  ports:
    - protocol: TCP
      port: 80
      targetPort: 8080
  type: LoadBalancer # Externes Proxying durch Cloud-Anbieter-LB

Sidecar-Proxys für Ingress (Service Mesh)

In einem Service Mesh (z.B. Istio, Linkerd) werden Sidecar-Proxys in Pods injiziert, um sowohl den eingehenden als auch den ausgehenden Datenverkehr für den Anwendungscontainer zu verwalten. Für den eingehenden Datenverkehr fängt der Sidecar den eingehenden Datenverkehr zur Anwendung ab und wendet Mesh-Richtlinien (z.B. Authentifizierung, Autorisierung, Traffic Shifting, Wiederholungsversuche, Circuit Breaking) an, bevor er ihn an den Anwendungscontainer weiterleitet.

Dies bietet:

• Richtliniendurchsetzung: Feingranulare Kontrolle darüber, wie Services kommunizieren.
• Beobachtbarkeit: Automatische Metriken, Protokollierung und verteiltes Tracing für die gesamte Service-zu-Service-Kommunikation.
• Traffic Management: Erweiterte Routing-Funktionen (z.B. Canary Deployments, A/B-Tests).
• Sicherheit: Gegenseitiges TLS (mTLS) zwischen Services.

Die Sidecar-Injektion und -Konfiguration werden typischerweise von der Steuerungsebene des Service Mesh automatisiert.

apiVersion: v1
kind: Pod
metadata:
  name: my-app-with-mesh-sidecar
  labels:
    app: my-app
    # Beispiel für Istio: löst automatische Sidecar-Injektion aus
    istio-injection: enabled
spec:
  containers:
  - name: my-app
    image: my-application-image:latest
    ports:
    - containerPort: 8080
  # Die Istio-Steuerungsebene fügt automatisch einen 'istio-proxy'-Sidecar-Container hinzu
  # und konfiguriert iptables-Regeln zur Umleitung des Datenverkehrs.

Vergleich der Proxy-Ansätze

Praktische Überlegungen

Zertifikatsverwaltung

Proxys terminieren oder initiieren oft TLS-Verbindungen.

• Ingress-Controller: Verwalten TLS-Zertifikate typischerweise über Kubernetes Secrets, was die TLS-Terminierung am Rand des Clusters ermöglicht.
• Sidecar-Proxys: In einem Service Mesh handhaben Sidecars mTLS automatisch, oft unter Verwendung kurzlebiger Zertifikate, die von der Zertifizierungsstelle des Mesh ausgestellt werden. Für den ausgehenden Datenverkehr müssen sie möglicherweise benutzerdefinierten CAs vertrauen, um verschlüsselten Datenverkehr zu inspizieren oder sich mit internen Services zu verbinden.

Leistung und Overhead

Jeder Proxy führt einen zusätzlichen Hop im Netzwerkpfad ein, was zu Latenz führen kann.

• kube-proxy: Hoch optimiert. Der ipvs-Modus bietet eine bessere Leistung für eine große Anzahl von Services.
• Sidecars: Führen CPU-, Speicher- und Netzwerk-Overhead pro Pod ein. Dieser Overhead ist eine Designüberlegung für Service-Mesh-Bereitstellungen.
• Ingress-Controller: Können bei hohem Datenverkehrsaufkommen einen Engpass darstellen, wenn sie nicht entsprechend skaliert werden.

Beobachtbarkeit

Proxys bieten einen zentralen Punkt zum Sammeln von Telemetriedaten.

• Logs: Proxys können Verbindungsdetails, Anfrage-/Antwort-Header und Fehler protokollieren.
• Metriken: Standardmetriken wie Anfrageraten, Latenzen, Fehlerraten können erfasst werden.
• Tracing: Sidecar-Proxys in einem Service Mesh ermöglichen verteiltes Tracing ohne Änderungen am Anwendungscode.

Sicherheit

Proxys sind kritische Durchsetzungspunkte für Sicherheitsrichtlinien.

• Zugriffskontrolle: Proxys können Authentifizierungs- und Autorisierungsrichtlinien für eingehenden und ausgehenden Datenverkehr durchsetzen.
• Netzwerksegmentierung: Proxys können den Anwendungsdatenverkehr isolieren und direkte Verbindungen zwischen Services verhindern, die nicht kommunizieren sollten.
• DDoS-Schutz: Externe Proxys (wie Ingress-Controller oder Cloud-LBs) können DDoS-Minderungsfunktionen bieten.