Nichtflüchtige IP-Adressen für Pods

In diesem Dokument wird beschrieben, wie Sie die zuverlässige Kommunikation konfigurieren, indem Sie bestimmten Pods in Ihren GKE-Clustern (Google Kubernetes Engine) eine oder mehrere persistente IP-Adressen zuweisen. Für Anwendungen, die eine hohe Verfügbarkeit erfordern, können Sie diese persistenten IP-Adressen auch für schnelles Failover konfigurieren oder Load Balancing auf Grundlage von Systemdiagnosen verwenden.

In bestimmten Fällen, in denen Sie eine benutzerdefinierte NAT-Lösung (Network Address Translation) ausführen, benötigen Sie möglicherweise eine statische persistente IP-Adresse für ausgehende und eingehende Verbindungen, entweder wenn die NAT-Lösung die Verbindung initiiert oder wenn sie sie empfängt. Möglicherweise möchten Sie auch die IP-Adressen steuern, die der Anwendung zugewiesen sind, um zu verwalten, wie sie mit anderen Systemen interagiert oder wie sie bestimmte Arten von Anfragen gemäß Ihren Geschäftsanforderungen verarbeitet.

Standardmäßig verwendet der Pod seine Schnittstellen-IP-Adressen für ausgehenden Traffic. Die IP-Adressen der Schnittstelle ändern sich, wenn der Pod neu gestartet oder verschoben wird. Wenn Sie mehr Kontrolle über die Routingkommunikation haben möchten, können Sie nichtflüchtige IP-Adressen manuell für Ihre Pods in GKE konfigurieren.

Diese IP-Adressen können entweder externe IP-Adressen für die Kommunikation über das Internet oder interne IP-Adressen für die Kommunikation in Ihrem Google Cloud-Netzwerk sein. Sie können entweder von Google bereitgestellte IP-Adressen verwenden oder Ihre eigenen IP-Adressen (BYOIP) mitbringen.

Durch das Konfigurieren nichtflüchtiger IP-Adressen für Pods in GKE können Sie die Anwendungs- und Geschäftslogik so zuordnen, dass bestimmte Pods Traffic an eine der nichtflüchtigen IP-Adressen senden und von diesen empfangen können.

Das folgende Diagramm zeigt, wie ein Pod mit mehreren Netzwerkschnittstellen eine persistente IP-Adresse aus einem sekundären Netzwerk verwenden kann, während er weiterhin über das Standardnetzwerk kommuniziert:

Architektur mit mehreren Netzwerken
Multinetzwerkarchitektur

Terminologie und Konzepte

Auf dieser Seite werden die folgenden Konzepte verwendet:

Load-Balancing auf Grundlage von Systemdiagnosen

Verwenden Sie Load-Balancing auf Grundlage von Systemdiagnosen, wenn Sie Traffic von einer persistenten IP-Adresse auf mehrere aktive Pods verteilen möchten, die einem bestimmten Label-Selektor entsprechen. Für diese Funktion werden regionale Systemdiagnosen verwendet, die Sie erstellen, um Pods kontinuierlich zu überwachen und dafür zu sorgen, dass Traffic nur an fehlerfreie Endpunkte weitergeleitet wird. Sie können auch Standby-Pods (Back-up-Pods) für die statische IP-Adresse konfigurieren. GKE leitet Traffic nur dann automatisch an diese Standby-Pods weiter, wenn alle primären aktiven Pods die Systemdiagnose nicht bestehen. Diese Konfiguration verhindert, dass einzelne Pods bei einem Fehler überlastet werden, und sorgt für eine kontinuierliche Dienstverfügbarkeit.

Gateway-Klassen

Gateway-Klassen, mit denen Ihre persistenten IP-Adressenzuweisungen verwaltet werden, sind in den folgenden Klassen verfügbar:

  • gke-persistent-regional-external-managed für externe IP-Adressen
  • gke-persistent-regional-internal-managed für interne (nurGoogle Cloud) IP-Adressen
  • gke-persistent-fast-regional-external-managed für externe IP-Adressen mit schnellem Failover
  • gke-persistent-fast-regional-internal-managed für interne (nurGoogle Cloud) IP-Adressen mit schnellem Failover

Die folgenden Gateway-Klassen gelten für das Systemdiagnose-basierte Load Balancing:

  • gke-passthrough-lb-internal-managed für interne (nurGoogle Cloud) persistente IP-Adressen, die von mehreren Pods gemeinsam genutzt werden.

  • gke-passthrough-lb-external-managed für externe statische IP-Adressen, die von mehreren Pods gemeinsam genutzt werden.

    Gateway-Klassen funktionieren in bestimmten Regionen. Gateway-Klassen bieten eine grundlegende IP-Adressverwaltung und konzentrieren sich auf das Netzwerk-Routing der Schicht 3 (L3).

In der folgenden Tabelle werden die Funktionen der einzelnen Gateway-Klassen verglichen:

Funktion Gateway-Klassen „gke-persistent-*“ Gateway-Klassen „gke-passthrough-lb-*“
Hauptziel Eine statische IP-Adresse für eine einzelne Arbeitslast. Load-Balancing für mehrere Arbeitslasten
Pod-Zuordnung 1:1 (Routen zum zuletzt erstellten passenden Pod). 1:N (verteilt den Traffic auf alle fehlerfreien übereinstimmenden Pods).
Systemdiagnosen Für Routing-Entscheidungen nicht unterstützt. Erforderlich (verwendet regionale Systemdiagnosen).
Backup-Pods Nicht unterstützt. Wird unterstützt (Standby-Pods für Failover werden verwendet).
Failover-Geschwindigkeit „Standard“ oder „Fast“ (verwendet *-fast-*-Klassen). Mit Systemdiagnoseparametern konfigurierbar

Gateway-Objekte

Gateway-Objekte dienen als zentraler Punkt für die Verwaltung und Konfiguration von persistenten IP-Adressen. Gateway-Objekte in GKE verwalten einen Pool von persistenten IP-Adressen. Darin werden diese Adressen aufgeführt und Regeln dafür definiert, wie sie GKEIPRoute zugewiesen werden können.

Listener

Ein Listener ist Teil Ihrer GKE Gateway-Konfiguration und steuert, welche Pods in Gateway-Namespaces die nichtflüchtigen IP-Adressen verwenden können, die vom Gateway gehalten werden. Mit dem Listener können Sie den Zugriff anpassen, um Flexibilität und Sicherheit zu gewährleisten. Jeder Listener benötigt einen eindeutigen Namen und ermöglicht es Ihnen, den Zugriff nach Namespace zu filtern (alle, labelbasiert oder nur der Namespace des Gateways).

GKEIPRoute-Objekt

Das GKEIPRoute-Objekt ist eine benutzerdefinierte Ressource, die Sie konfigurieren, um einem bestimmten Pod in Ihrem GKE-Cluster eine persistente IP-Adresse zuzuweisen. Sie können den Statusbereich des GKEIPRoute-Objekts verwenden, um die Einrichtung Ihrer persistenten IP-Adresse zu überwachen. Dort finden Sie wichtige Informationen in den folgenden Feldern:

  • Pod

    Im Feld Pod sehen Sie den genauen Namen des Pods, der mit den persistenten IP-Adressen verknüpft ist. Ein einzelner Pod kann mehrere statische IP-Adressen verwenden.

  • Bedingungen

    Das Feld Bedingungen gibt an, ob die Einrichtung Ihrer externen IP-Adresse korrekt funktioniert. Es kann auch bei der Diagnose von Problemen helfen, wenn Ihre Konfiguration ungültig ist. Es gibt vier Bedingungen:

    • Accepted:Gibt an, ob die GKEIPRoute-Ressourcenspezifikation gültig ist. Wenn Ihre Konfiguration Fehler enthält, hat die Bedingung Accepted den Wert False mit einem Grund.
    • GCPReady:Gibt an, dass Google Cloud alle erforderlichen Ressourcen vorbereitet hat. Fehler während der Bereitstellung der Google Cloud -Ressource werden im Status der GCPReady-Bedingung angezeigt.
    • DPV2Ready:Gibt den Status der Datenpfadprogrammierung an, z. B. wenn der Datenpfad bereit und programmiert ist, um Netzwerkverbindungen auf den konfigurierten nichtflüchtigen IP-Adressen zuzulassen.
    • Ready: Gibt an, dass die Einrichtung der persistenten IP-Adress gültig und funktionsfähig ist. Die Pods sind über die persistenten IP-Adressen erreichbar, sofern Sie Ihre Anwendung für die Verwendung dieser Adressen konfiguriert haben. Dieser Wert wird auf True gesetzt, wenn die drei anderen vorherigen Bedingungen ebenfalls True sind.

  • nodeSelector

    Wenn Sie das schnelle Failover verwenden, müssen Sie mit dem Feld nodeSelector angeben, welche Knoten für das schnelle Failover vorkonfiguriert sind. So können Sie im Falle eines Failovers den neuen Pod schnell auf einem bestimmten Knoten mit der persistenten IP-Adresse online schalten. Sie müssen dafür sorgen, dass Sie Ihre Pods mit persistenten IP-Adressen auf diesen Knoten planen. Normalerweise verwenden Sie dazu die nodeSelector des Pods, um Labels auf den Knoten abzugleichen. Verwenden Sie das Feld nodeSelector, wenn Sie das schnelle Failover konfigurieren, und achten Sie darauf, dass mit den angegebenen Labels nicht mehr als 64 Knoten ausgewählt werden.

Die folgenden Felder gelten nur für das Systemdiagnose-basierte Load-Balancing:

  • loadBalancing: Gibt den Namen der regionalen Systemdiagnose an, mit der der Status der Pods überwacht wird.
  • backupPodSelector: Definiert die Gruppe von Pods, die Traffic empfangen, wenn alle primären Pods fehlerhaft sind.

Reaktionsmodi

Reaktionsmodi bestimmen, wie sich das System verhält, wenn sich der mit einer persistenten IP-Adresse verknüpfte Pod ändert, z. B. wenn er auf einen anderen Knoten verschoben wird oder ein neu erstellter übereinstimmender Pod verfügbar wird. Mit Reaktionsmodi können Sie Ihre persistenten IP-Adressen auch dann verwenden, wenn sich Ihre Pods ändern.

Reaktionsmodi sind:

  • ReadyCondition

    Im Modus ReadyCondition priorisiert das System nichtflüchtiger IP-Adressen den Pod-Zustand. Das System nichtflüchtiger IP-Adressen weist IP-Adressen nur Pods zu, die den angegebenen Labels entsprechen und Kubernetes-Systemdiagnosen bestanden haben. Dabei wird der Status Ready als True signalisiert. Dieser Modus ist ideal für Anwendungen, bei denen es entscheidend ist, dass der Pod, der die persistente IP-Adresse empfängt, vollständig auf die Verarbeitung von ein- und ausgehendem Traffic vorbereitet ist.

  • Vorhanden

    Im Modus Exists wird die Anwesenheit eines Pods priorisiert. Die nichtflüchtige IP-Adresse wird an einen Pod angehängt, wenn dieser Pod den Labels in Ihrer Konfiguration entspricht und auf einem bestimmten Knoten in Ihrem Cluster geplant wurde. Das bedeutet, dass der Pod vorhanden ist und einen bestimmten Ort hat, an dem er ausgeführt werden kann. Dieser Modus eignet sich gut für Szenarien, in denen eine schnelle Zuweisung der nichtflüchtigen IP-Adresse Vorrang vor strikter Bereitschaft hat, oder in Umgebungen wie denen für Entwicklung und Tests, in denen eine sofortige Konnektivität wichtiger sein kann als die vollständige Anwendungsbereitschaft.

StatefulSets

StatefulSets sind eine Art von Kubernetes-Arbeitslast, die für Anwendungen entwickelt wurde, die stabile Kennungen und nichtflüchtigen Speicher benötigen. Pods in einem StatefulSet haben vorhersagbare Namen (z. B. „my-app-0“, „my-app-1“).

Deployments

Deployments sind eine Art von Kubernetes-Arbeitslast zum Verwalten zustandsloser Anwendungen, bei denen Pods im Allgemeinen austauschbar sind. Pod-Namen in Deployments sind nicht vollständig vorhersagbar.

Anwendungsfälle

Nichtflüchtige IP-Adressen für GKE-Pods decken mehrere Anwendungsfälle für Netzwerk- und Sicherheitsdienstanbieter ab, die netzwerkbezogene Anwendungen in GKE ausführen.

Nichtflüchtige IP-Adressen für GKE-Pods sind für die folgenden Anwendungsfälle vorgesehen:

  • NAT-Steuerung:Durch die Zuweisung persistenter IP-Adressen an Pods, auf denen Netzwerkfunktionen ausgeführt werden, erhalten Sie eine detaillierte Steuerung der Quell-IP-Adressen, die für ausgehenden Traffic verwendet werden. So können Sie Ihre eigene NAT-Logik einbinden.
  • Dedizierte IP-Adresspools:Mit dedizierten IP-Adressen können Sie bestimmten 5G Core-Pods bestimmte Adressen zuweisen und so die Kompatibilität mit spezieller Anbietersoftware sicherstellen.
  • Zuverlässige Trafficflüsse:Da der Rücktraffic über dieselbe Netzwerkfunktion zurückgeleitet werden muss, sorgen persistente IP-Adressen dafür, dass externe Systeme den richtigen Pod ohne Kommunikationsunterbrechungen erkennen und darauf reagieren.
  • Hohe Verfügbarkeit für zeitkritische Anwendungen:Für Anwendungen mit strengen Anforderungen an die Betriebszeit, z. B. in der Telekommunikationsbranche, können Sie persistente IP-Adressen mit schnellem Failover verwenden, um den Traffic im Fehlerfall schnell zu einem fehlerfreien Pod umzuleiten. So lässt sich die Ausfallzeit auf wenige Sekunden reduzieren.
  • Lastverteilung:Wenn Sie Load-Balancing auf Grundlage von Systemdiagnosen verwenden, verteilt GKE den Traffic auf mehrere aktive Pods, um eine Überlastung einer einzelnen Instanz zu vermeiden. Wenn keine fehlerfreien Pods verfügbar sind, können Sie Backup-Pods in anderen Namespaces oder Knoten konfigurieren.

Vorteile

Nichtflüchtige IP-Adressen für GKE-Pods bieten Ihnen die folgenden Vorteile:

  • Externe Identität:Wenn Sie einem Pod eine externe persistente IP-Adresse zuweisen, können externe Systeme diesen Pod konsistent erreichen, auch wenn er neu gestartet oder innerhalb des Clusters verschoben wird. Dies ist hilfreich für Dienste, die einen extern auffindbaren Endpunkt benötigen.
  • Zuverlässige Kommunikation:Anwendungen, die von anderen Ressourcen mit bestimmten IP-Adressen abhängig sind, können mit persistenten IP-Adressen zuverlässige Verbindungen herstellen. Statische IP-Adressen sind wichtig für Legacy-Systeme oder Anwendungen mit fest codierten IP-Adressabhängigkeiten.
  • Legacy-Migrationen: Legacy-Migrationen können bei der Migration von Anwendungen helfen, die während des Übergangs bestimmte IP-Adressen benötigen.
  • BYOIP: Mit BYOIP können Sie die Kontrolle über bestimmte IP-Adressbereiche behalten, die Sie bereits besitzen, indem Sie sie in Ihren GKE-Clustern verwenden.
  • Verbesserte Anwendungsverfügbarkeit: Mit der schnellen Failover-Funktion können Sie die Verfügbarkeit Ihrer kritischen Anwendungen erheblich verbessern, indem Sie die Ausfallzeit im Falle eines Pod-Fehlers auf nur wenige Sekunden reduzieren.
  • Hohe Verfügbarkeit mit automatischem Failover: Erreichen Sie die Dienstverfügbarkeit, indem Sie den Traffic automatisch an fehlerfreie Standby-Pods weiterleiten, wenn primäre Pods Systemdiagnosen nicht bestehen.

Nächste Schritte