Welche komplexen Aufgaben mussten Sie im Bereich der Netzwerkinteraktion zwischen Containern lösen?

Optimierung der Netzwerkleistung zwischen Diensten in einem Mesh basierend auf Istio. Es war notwendig, Engpässe im Zusammenhang mit dem Overhead des Service Proxy (Envoy), der Konfiguration von mTLS und der Policy-Engine zu identifizieren und zu beheben. Dazu gehörte die Analyse von Istio-Metriken (Anfrage-Dauer, Fehleranzahl, Latenzen), die Nachverfolgung verteilter Anfragen und die Feinabstimmung der Envoy-Konfiguration.

Lösung von Routing-Problemen in dynamisch skalierenden Kubernetes-Clustern. Beim Skalieren der Dienste traten Verzögerungen bei der Verbreitung von EndpointSlices und eine inkorrekte Lastverteilung auf. Dies wurde durch die Einstellung aggressiverer Cache-Timeouts in kube-proxy und die Verwendung fortschrittlicherer Load-Balancing-Algorithmen im Ingress-Controller (z.B. least_request) behoben.

Implementierung einer sicheren Interaktion zwischen Containern in verschiedenen Subnetzen mit strengen Netzwerkrichtlinien (Network Policies). Es war notwendig, die Richtlinien so zu konfigurieren, dass nur der notwendige Datenverkehr zwischen bestimmten Pod-Paaren oder Namespaces erlaubt wird, während alles andere blockiert wird. Dies erforderte ein tiefgehendes Verständnis der Network Policy-Selektoren und der Mechanismen ihrer Anwendung durch externe CNI-Plugins (z.B. Calico).

Fehlerbehebung bei DNS-Auflösungsproblemen innerhalb der Container, insbesondere in Umgebungen mit mehreren DNS-Servern oder komplexen Weiterleitungsregeln. Es wurde der Datenverkehr auf Pod-Ebene mit tcpdump analysiert und die Konfiguration von /etc/resolv.conf in den Containern sowie die CoreDNS-Konfiguration im Kubernetes-Cluster überprüft.

# Beispiel für DNS-Traffic-Analyse innerhalb eines Pods
kubectl exec <pod-name> -- tcpdump -i any udp port 53 -v

# Beispiel einer NetworkPolicy zur Erlaubnis des Traffics zwischen zwei Namespaces
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-frontend-to-backend
  namespace: frontend-namespace
spec:
  podSelector:
    matchLabels:
      app: frontend
  policyTypes:
    - Egress
  egress:
    - to:
      - podSelector:
          matchLabels:
            app: backend
        namespaceSelector:
          matchLabels:
            name: backend-namespace

Lösung von Problemen im Zusammenhang mit der Verwendung von nicht standardisierten Protokollen, die "out of the box" in Service Mesh oder CNI nicht unterstützt werden und spezielle Proxy-Konfigurationen oder Lösungen erforderten. Zum Beispiel die Organisation der Interaktion über ein anderes Protokoll als HTTP/1.1 oder gRPC innerhalb von Istio, was die Erstellung eigener Envoy-Filter erforderlich machen konnte.