Kubernetes v1.26: Revolutionäre Verbesserungen im Traffic-Management

Kubernetes v1.26 bringt bedeutende Fortschritte im Netzwerk-Traffic-Management mit sich. Zwei Funktionen, die Unterstützung der internen Traffic-Policy für Services und die Endpunkt-Slice-Abbruchbedingungen, wurden in den allgemeinen Zugriff (GA) überführt. Eine dritte Funktion, das Proxy für abgebrochene Endpunkte, hat den Beta-Status erreicht. Diese Verbesserungen zielen darauf ab, Herausforderungen im Traffic-Management zu adressieren und neue Möglichkeiten für die Zukunft zu eröffnen.

Verlust von Traffic durch Load Balancer während Rolling Updates

Vor Kubernetes v1.26 konnten Cluster während Rolling Updates Traffic-Verluste durch Service-Load-Balancer erleiden, wenn das Feld externalTrafficPolicy auf Local gesetzt war. Um das zu verstehen, hilft ein kurzer Überblick darüber, wie Kubernetes Load Balancer verwaltet!

In Kubernetes können Sie einen Service mit type: LoadBalancer erstellen, um eine Anwendung extern über einen Load Balancer bereitzustellen. Die Implementierung des Load Balancers variiert zwischen Clustern und Plattformen, aber der Service bietet eine generische Abstraktion, die konsistent über alle Kubernetes-Installationen hinweg ist.

apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  selector:
    app.kubernetes.io/name: my-app
  ports:
    - protocol: TCP
      port: 80
      targetPort: 9376
  type: LoadBalancer

Unter der Haube weist Kubernetes dem Service einen NodePort zu, der dann von kube-proxy verwendet wird, um einen Netzwerkdatenpfad vom NodePort zum Pod bereitzustellen. Ein Controller fügt dann alle verfügbaren Nodes im Cluster dem Backend-Pool des Load Balancers hinzu, wobei der zugewiesene NodePort für den Service als Backend-Zielport verwendet wird.

Oft ist es vorteilhaft, externalTrafficPolicy: Local für Services festzulegen, um zusätzliche Hops zwischen Nodes zu vermeiden, die keine gesunden Pods für diesen Service ausführen. Wenn externalTrafficPolicy: Local verwendet wird, wird ein zusätzlicher NodePort für Gesundheitsprüfungen zugewiesen, sodass Nodes, die keine gesunden Pods enthalten, vom Backend-Pool eines Load Balancers ausgeschlossen werden.

Ein häufiges Szenario, in dem Traffic verloren gehen kann, ist, wenn ein Node alle Pods für einen Service verliert, aber der externe Load Balancer den Gesundheitsprüfungs-NodePort noch nicht überprüft hat. Die Wahrscheinlichkeit für diese Situation hängt stark vom konfigurierten Gesundheitsprüfungsintervall des Load Balancers ab. Je größer das Intervall, desto wahrscheinlicher ist dies, da der Load Balancer weiterhin Traffic zu einem Node sendet, selbst nachdem kube-proxy die Weiterleitungsregeln für diesen Service entfernt hat. Dies geschieht auch, wenn Pods während Rolling Updates beginnen, sich zu beenden. Da Kubernetes beendete Pods nicht als “bereit” betrachtet, kann Traffic verloren gehen, wenn während eines Rolling Updates nur beendete Pods auf einem Node vorhanden sind.

Ab Kubernetes v1.26 aktiviert kube-proxy standardmäßig die Funktion ProxyTerminatingEndpoints, die ein automatisches Failover und Routing zu abgebrochenen Endpunkten in Szenarien ermöglicht, in denen der Traffic andernfalls verloren ginge. Konkret wird bei einem Rolling Update, wenn ein Node nur abgebrochene Pods enthält, der Traffic zu den abgebrochenen Pods basierend auf ihrer Bereitschaft weitergeleitet. Darüber hinaus wird kube-proxy die Gesundheitsprüfung des NodePorts aktiv fehlschlagen, wenn nur abgebrochene Pods verfügbar sind. Auf diese Weise informiert kube-proxy den externen Load Balancer, dass keine neuen Verbindungen zu diesem Node gesendet werden sollten, während Anfragen für bereits bestehende Verbindungen weiterhin sanft bearbeitet werden können.

Die neuen Funktionen in Kubernetes v1.26 bieten Entwicklern und DevOps-Teams erhebliche Vorteile und reduzieren Ausfallzeiten während Rolling Updates. ayedo ist stolz darauf, Partner im Kubernetes-Ökosystem zu sein und Ihnen zu helfen, das Beste aus diesen neuen Möglichkeiten herauszuholen.

Quelle: Kubernetes Blog