GKE-Netzwerkdokumentation und ‑Anwendungsfälle

Netzwerke in Google Kubernetes Engine (GKE) umfassen eine Vielzahl von Konzepten, darunter Pods, Dienste, DNS, Load-Balancing, Sicherheit und IP-Adressverwaltung. In der Dokumentation werden zwar alle Funktionen ausführlich erläutert, aber es kann schwierig sein, zu wissen, wo man bei einem realen Problem anfangen soll.

Dieses Dokument hilft Ihnen, sich in der GKE-Netzwerkdokumentation zurechtzufinden, indem es häufige Herausforderungen mit den Funktionen und Abschnitten verknüpft, die diese lösen. In jedem Anwendungsfall wird ein Szenario vorgestellt, die Herausforderung identifiziert und auf die relevante Dokumentation verwiesen. Dieses Dokument richtet sich an Cloud-Architekten, Entwickler und Betriebsteams, die häufige Netzwerkprobleme in GKE verstehen und lösen müssen.

Wenn Sie bereits mit häufigen Netzwerkproblemen vertraut sind und direkt in die technischen Details eintauchen möchten, finden Sie in den folgenden Ressourcen grundlegende Informationen zu GKE-Netzwerken:

Anwendungsfall: Netzwerkbasis für GKE entwerfen

In diesem Anwendungsfall sind Sie ein Cloud-Architekt, der eine skalierbare, sichere und zuverlässige Netzwerkbasis für eine neue GKE-Plattform entwerfen muss.

Herausforderung: IP-Adressenmangel verhindern

Szenario:Die Komplexität und Nutzung Ihrer Anwendung werden voraussichtlich zunehmen. Daher müssen Sie ein Netzwerk entwerfen, das skaliert werden kann, um den erhöhten Traffic zu bewältigen und das Wachstum von Pods, Diensten und Knoten zu unterstützen. Sie müssen auch die Zuweisung von IP-Adressen planen, um einen Mangel zu vermeiden.

Lösung:Planen Sie Ihr IP-Adressierungsschema so, dass die Anzahl der Knoten, Pods und Dienste berücksichtigt wird, die Sie benötigen. Dieser Plan umfasst die Auswahl geeigneter IP Adressbereiche für die einzelnen Elemente, die Berücksichtigung der Pod-Dichte und die Vermeidung von Überschneidungen mit anderen Netzwerken. Weitere Informationen finden Sie unter IP-Adressmigration in GKE verwalten.

Herausforderung: Defense-in-Depth-Sicherheit erzwingen

Szenario:Sie müssen Ihre Clusterperimeter sichern und Zero-Trust-Regeln für die Kommunikation zwischen Pods erzwingen.

Lösung: Verwenden Sie Firewallrichtlinien für Cluster perimeter. Weitere Informationen finden Sie unter Kommunikation zwischen Pods und Diensten mithilfe von Netzwerkrichtlinien steuern.

Herausforderung: Traffic an verschiedene Arten von Anwendungen weiterleiten

Szenario:Sie müssen dafür sorgen, dass andere Dienste und Nutzer verschiedene Arten von Anwendungen erreichen können, z. B. private Back-Ends und öffentliche HTTP(S)-Anwendungen.

Lösung:Verwenden Sie interne Load-Balancer für private Back-Ends. Verwenden Sie für öffentliche HTTP(S)-Anwendungen die Ingress API oder die Gateway API. Weitere Informationen finden Sie unter Load-Balancing in GKE.

Herausforderung: Beobachtbarkeitstools verwenden, um Probleme mit Arbeitslasten zu beobachten und zu beheben

Szenario:Sie müssen Probleme mit dem Netzwerkverkehr beheben und GKE-Trafficflüsse verstehen und beobachten, um Probleme effektiv zu diagnostizieren.

Lösung: Implementieren Sie Beobachtbarkeitstools, um den Netzwerktraffic zu beobachten und Fehler zu beheben. Weitere Informationen finden Sie unter Traffic mit GKE Dataplane V2 beobachten.

Anwendungsfall: Neuen Mikrodienst freigeben

In diesem Anwendungsfall sind Sie ein Entwickler, der einen neuen Mikrodienst in GKE bereitstellt. Sie müssen den Mikrodienst für andere Dienste im Cluster und später für externe Clients zugänglich machen.

Herausforderung: Stabilen Endpunkt für die Kommunikation zwischen Pods bereitstellen

Szenario:Ihre Anwendung erfordert, dass Pods mit anderen Pods kommunizieren. Die dynamischen IP-Adressen, die von Pods verwendet werden, machen diese Kommunikation jedoch unzuverlässig.

Lösung:Erstellen Sie einen Kubernetes-Dienst. Ein ClusterIP-Dienst bietet eine stabile virtuelle IP-Adresse und einen DNS-Namen, die auf Pods verteilt sind. Weitere Informationen finden Sie unter Kubernetes Dienste.

Herausforderung: Dienst für externen Zugriff freigeben

Szenario:Der Mikrodienst muss für eine Demo über das Internet erreichbar sein.

Lösung:Erstellen Sie einen LoadBalancer-Dienst. GKE stellt einen regionalen externen Passthrough-Network-Load-Balancer mit einer öffentlichen IP-Adresse bereit. Für HTTP(S)-Traffic sollten Sie Ingress oder Gateway verwenden, die Layer-7-Funktionen bieten. Weitere Informationen finden Sie unter LoadBalancer Dienste.

Herausforderung: Permanente, nutzerfreundliche URL zuweisen

Szenario:Der Dienst benötigt einen stabilen Domainnamen für Clients.

Lösung:Reservieren Sie eine statische IP-Adresse und konfigurieren Sie DNS für eine benutzerdefinierte Domain. Weitere Informationen finden Sie unter Domainnamen mit statischen IP Adressen konfigurieren.

Herausforderung: Erweiterte Traffic-Weiterleitung verwalten

Szenario:Mit dem Wachstum Ihrer Anwendung benötigen Sie eine ausgefeiltere Steuerung der Traffic-Weiterleitung. Möglicherweise ist z. B. Folgendes nötig:

  • Mehrere Websites (z. B. api.example.com und shop.example.com) auf einem einzelnen Load-Balancer hosten, um Kosten zu sparen.
  • Anfragen basierend auf dem URL-Pfad an verschiedene Dienste weiterleiten (z. B. Senden von / an die Front-End-Arbeitslast und /api/v1 an die Back-End-Arbeitslast).
  • Anwendung mit HTTPS sichern, indem Sie TLS-Zertifikate verwalten.
  • Neue Funktionen sicher in Phasen bereitstellen, indem Sie Canary-Releases verwenden. Dabei senden Sie einen kleinen Teil des Traffics an eine neue Version, bevor Sie sie vollständig bereitstellen.

Lösung:Verwenden Sie die Gateway API. Die Implementierung der Gateway API in GKE bietet eine leistungsstarke und standardisierte Möglichkeit, diese Art von North-South-Traffic zu verwalten. Sie unterstützt erweiterte Funktionen wie pfadbasiertes Routing, Header-Abgleich und Traffic-Aufteilung. Weitere Informationen finden Sie unter Gateway API.

Anwendungsfall: Service Discovery für eine wachsende Anwendung skalieren

Mit zunehmendem Traffic und steigender Komplexität Ihrer auf Mikrodiensten basierenden Anwendung nehmen die DNS-Abfragen zwischen Diensten erheblich zu. Entwickler müssen zwar wissen, wie sie in dieser Umgebung robuste Anwendungen erstellen, aber Plattform- und Betriebsteams sind oft für die Implementierung skalierbarer Netzwerklösungen verantwortlich.

Herausforderung: Dienst-zu-Dienst-Kommunikation aktivieren

Szenario:Pods benötigen eine zuverlässige Möglichkeit, andere Dienste zu finden.

Lösung:GKE bietet einen clusterinternen DNS-Dienst (z. B. kube-dns oder Cloud DNS), der stabile DNS-Namen für Dienste auflöst und so eine zuverlässige Kommunikation zwischen Pods ermöglicht. Weitere Informationen finden Sie unter Diensterkennung und DNS.

Herausforderung: DNS-Leistung im großen Maßstab verbessern

Szenario:Ein hohes Abfragevolumen verursacht Verzögerungen bei der Suche.

Lösung:Aktivieren Sie NodeLocal DNSCache. Jeder Knoten speichert DNS-Abfragen lokal im Cache, wodurch die Latenz reduziert wird. Weitere Informationen finden Sie unter NodeLocal DNSCache einrichten Übersicht.

Herausforderung: Diensterkennung in der gesamten VPC bereitstellen

Szenario:Compute Engine-VMs müssen auf Dienste im Cluster zugreifen.

Lösung:Integrieren Sie Cloud DNS, damit DNS-Einträge für Dienste in der gesamten VPC aufgelöst werden. Weitere Informationen finden Sie unter Cloud DNS für GKE verwenden.

Anwendungsfall: Mehrstufige Anwendung sichern

In diesem Anwendungsfall sind Sie Mitglied eines Plattformtechnikteams, das eine dreistufige Anwendung (Front-End, Abrechnung, Datenbank) bereitstellt. Sie müssen die Zero-Trust-Kommunikation erzwingen.

Herausforderung: Strenge Traffic-Regeln erzwingen

Szenario:Nur bestimmte Dienste sollen miteinander kommunizieren.

Lösung:Aktivieren Sie die Durchsetzung von Netzwerkrichtlinien und wenden Sie default deny-Richtlinien an. Definieren Sie dann explizite Zulassungsregeln (z. B. lässt das Front-End Traffic zur Abrechnung zu, die Abrechnung lässt Traffic zur Datenbank zu). Weitere Informationen finden Sie unter Netzwerkrichtlinien für Anwendungen konfigurieren.

Herausforderung: Netzwerkrichtlinien prüfen und verifizieren

Szenario:Sicherheit erfordert einen Nachweis der Durchsetzung und Transparenz.

Lösung:Aktivieren Sie das Logging von Netzwerkrichtlinien, um zugelassene und abgelehnte Verbindungen aufzuzeichnen. Weitere Informationen finden Sie unter Logging von Netzwerkrichtlinien verwenden.

Herausforderung: Dienst privat für Nutzer freigeben

Szenario:Ein Backend-Dienst wie eine Datenbank oder API muss für Nutzer in anderen VPC-Netzwerken zugänglich sein, ohne ihn dem öffentlichen Internet auszusetzen oder sich mit der Komplexität des VPC-Peerings auseinandersetzen zu müssen.

Lösung:Verwenden Sie Private Service Connect, um den Dienst zu veröffentlichen. Nutzer können dann in ihrer eigenen VPC einen PSC-Endpunkt erstellen, um privat und sicher auf Ihren Dienst zuzugreifen. Weitere Informationen finden Sie unter Dienste mit Private Service Connectfreigeben.

Anwendungsfall: Hochverfügbarkeit in mehreren Clustern erreichen

In diesem Anwendungsfall sind Sie ein SRE, der Arbeitslasten für ein E-Commerce-Unternehmen in mehreren GKE-Clustern in verschiedenen Regionen ausführt, um die Zuverlässigkeit zu verbessern.

Herausforderung: Clusterübergreifende Kommunikation aktivieren

Szenario:Dienste in einem Cluster müssen Dienste in einem anderen Cluster erkennen und aufrufen können.

Lösung:Verwenden Sie GKE-Multi-Cluster-Dienste (MCS), um einen globalen DNS-Namen zu erstellen und Traffic automatisch an fehlerfreie Back-Ends weiterzuleiten. Weitere Informationen finden Sie unter Multi-Cluster Dienste.

Herausforderung: Zuverlässigen Failover sicherstellen

Szenario:Wenn ein regionaler Dienst nicht mehr verfügbar ist, muss der Traffic automatisch umgeleitet werden.

Lösung:MCS bietet eine zustandsabhängige Service Discovery, mit der Clients einen einzelnen DNS-Namen in ein fehlerfreies Backend im nächstgelegenen verfügbaren Cluster auflösen können. Dieser Ansatz ermöglicht einen zuverlässigen Failover. Weitere Informationen finden Sie unter Multi-Cluster-Dienste.

Anwendungsfall: Sichere und effiziente mehrmandantenfähige GKE-Umgebung erstellen

Als Mitglied eines Plattformtechnikteams stellen Sie mehreren Anwendungsteams GKE-Cluster zur Verfügung. Sie müssen die Netzwerksteuerung zentralisieren, IP-Adressen sparen und strenge Sicherheitsmaßnahmen erzwingen.

Herausforderung: Netzwerksteuerung zentralisieren

Szenario:Mehrere Anwendungsteams benötigen eigene Cluster, aber die Netzwerke müssen zentral verwaltet werden.

Lösung:Verwenden Sie eine freigegebene VPC. Netzwerkressourcen befinden sich in einem Hostprojekt, aber Anwendungscluster werden in Dienstprojekten ausgeführt. Weitere Informationen finden Sie unter Cluster mit gemeinsam genutzter VPC konfigurieren.

Herausforderung: Begrenzte IP-Adressen effizient verwalten

Szenario:Der IP-Adressbereich ist begrenzt und muss effizient genutzt werden.

Lösung:Passen Sie die maximale Anzahl von Pods pro Knoten an und verwenden Sie bei Bedarf Bereiche außerhalb von RFC 1918 für Pod-IP-Adressen. Weitere Informationen finden Sie unter IP-Adressmigration in GKE verwalten.

Herausforderung: Moderne, sichere Datenebene verwenden und Cluster mit der neuen Datenebene bereitstellen

Szenarien :

  • Das Unternehmen benötigt eine hohe Leistung und eine integrierte Richtliniendurchsetzung, um anspruchsvolle Arbeitslasten und eine Zero-Trust-Sicherheitsstrategie zu unterstützen. Beispielsweise führen Sie möglicherweise umfangreiche Mikrodienste aus, die empfindlich auf Netzwerklatenz reagieren, oder Sie müssen strenge Sicherheitsgrenzen zwischen Anwendungen in einem mehrmandantenfähigen Cluster erzwingen, um die Einhaltung regulatorischer Anforderungen zu erfüllen.
  • Cluster müssen so konfiguriert sein, dass sie eine moderne Netzwerkdatenebene für hohe Leistung und Sicherheit verwenden. Außerdem müssen sie in der zentral verwalteten Netzwerkstruktur der Organisation bereitgestellt werden.

Lösung:Verwenden Sie GKE Dataplane V2, das auf eBPF basiert und eine hohe Leistung sowie eine integrierte Durchsetzung von Netzwerkrichtlinien bietet. Weitere Informationen finden Sie unter GKE Dataplane V2.

Anwendungsfall: Traffic beobachten und Fehler beheben

Als SRE untersuchen Sie, warum ein Checkout-Dienst keine Verbindung zu einem Zahlungsdienst herstellen kann.

Herausforderung: Verbindungsprobleme beheben

Szenario:Pakete werden verworfen, aber die Ursache ist unklar.

Lösung:Aktivieren Sie die Beobachtbarkeit von GKE Dataplane V2. Messwerte wie hubble_drop_total bestätigen, dass Pakete abgelehnt werden. Weitere Informationen finden Sie unter Fehlerbehebung mit Hubble.

Herausforderung: Ursache für verworfene Pakete ermitteln

Szenario:Nachdem Sie bestätigt haben, dass Netzwerkpakete verworfen werden (z. B. mit hubble_drop_total), ermitteln Sie, welche Netzwerkrichtlinie den Traffic zwischen Diensten blockiert.

Lösung:Verwenden Sie die Hubble-Befehlszeile oder die Hubble-UI, um Abläufe zu verfolgen. Die Hubble-UI bietet eine visuelle Darstellung des Traffics und hebt die falsch konfigurierte Richtlinie hervor, die die Verbindung ablehnt. Mit dieser Visualisierung kann das Team die Ursache des Problems schnell ermitteln und die Richtlinie korrigieren. Weitere Informationen finden Sie unter Traffic mit GKE Dataplane V2 beobachten.

End-to-End-Anwendungsfall: Sichere Einzelhandelsanwendung bereitstellen und skalieren

In diesem End-to-End-Szenario erstellt ein Plattformtechnikteam eine standardisierte GKE-Plattform für mehrere Anwendungsteams. Das Team stellt eine dreistufige Einzelhandelsanwendung (Front-End, Abrechnung, Datenbank) bereit und optimiert sie. Dieser Prozess umfasst das Sichern, Skalieren, Verbessern der Leistung für ML-Arbeitslasten und das Einbinden erweiterter Sicherheits-Appliances.

Das folgende Diagramm zeigt die End-to-End-Architektur einer sicheren, mehrstufigen Einzelhandelsanwendung, die in GKE bereitgestellt wird. Die Architektur entwickelt sich in mehreren Phasen:

  • Phase 1:Erstellen Sie eine grundlegende Einrichtung mit einer gemeinsam genutzten VPC und GKE Dataplane V2.
  • Phase 2:Geben Sie die Anwendung mit der Gateway API und Multi-Cluster-Diensten für hohe Verfügbarkeitfrei.
  • Phase 3:Beschleunigen Sie ML-Aufgaben mit gVNIC und Tier 1-Netzwerken.
  • Phase 4:Stellen Sie erweiterte Sicherheits-Appliances mit Unterstützung für mehrere Netzwerke bereit.
Diagramm der End-to-End-Architektur für eine sichere, mehrstufige Einzelhandelsanwendung in GKE, das Netzwerkkomponenten in sechs Phasen der Bereitstellung und Skalierung veranschaulicht.
Abbildung 1. End-to-End-Architektur für eine sichere, mehrstufige Einzelhandelsanwendung in GKE, in der die wichtigsten Netzwerkkomponenten hervorgehoben sind, die in jeder Phase der Bereitstellung und Skalierung verwendet werden. Die Details der einzelnen Phasen werden beschrieben in den folgenden Abschnitten.

Phase 1: Plattformbasis erstellen

Herausforderung:Zentralisieren Sie die Netzwerke für mehrere Anwendungsteams und weisen Sie genügend IP-Adressen zu, um die Skalierung zu bewältigen.

Lösung :

Phase 2: Anwendung bereitstellen und sichern

Herausforderung:Zuverlässige Dienst-zu-Dienst-Kommunikation sicherstellen und Zero-Trust-Sicherheit erzwingen.

Lösung :

Phase 3: Anwendung freigeben und für Wachstum skalieren

Herausforderung:Externen Zugriff bereitstellen und die DNS-Lookup-Latenz bei steigendem Traffic reduzieren.

Lösung :

Phase 4: Hochverfügbarkeit erreichen und Probleme beheben

Herausforderung:Regionalen Failover sicherstellen und verworfenen Traffic debuggen.

Lösung :

Phase 5: ML-Arbeitslasten beschleunigen

Herausforderung:Netzwerkengpässe für das GPU-basierte Modelltraining beseitigen.

Lösung :

  • Aktivieren Sie gVNIC für eine höhere Bandbreite.
  • Konfigurieren Sie Tier 1-Netzwerke auf kritischen Knoten für maximalen Durchsatz.

Phase 6: Erweiterte Sicherheits-Appliances bereitstellen

Herausforderung:Firewall und IDS von Drittanbietern mit separatem Verwaltungs- und Datenebenentraffic mit extrem niedriger Latenz bereitstellen.

Lösung :

Nächste Schritte