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 wird zwar jede Funktion im Detail erläutert, aber es kann schwierig sein, zu wissen, wo man bei einem realen Problem anfangen soll.

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

Wenn Sie bereits mit häufigen Netzwerkproblemen vertraut sind und sich lieber direkt mit den technischen Details befassen möchten, finden Sie in den folgenden Ressourcen grundlegende Informationen zum GKE-Netzwerk:

Anwendungsfall: Netzwerkbasis für GKE entwerfen

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

Herausforderung: IP-Adressen aufgebraucht

Szenario:Die Komplexität und Nutzung Ihrer Anwendung werden voraussichtlich zunehmen. Sie müssen also 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. Außerdem müssen Sie die Zuweisung von IP-Adressen planen, um eine Ausschöpfung 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. Dazu gehört die Auswahl geeigneter IP-Adressbereiche für die einzelnen Bereiche unter Berücksichtigung der Pod-Dichte und die Vermeidung von Überschneidungen mit anderen Netzwerken.

Challenge: Defense-in-Depth-Sicherheit erzwingen

Szenario: Sie müssen Ihre Clusterperimeter schützen und Zero-Trust-Regeln für Pod-zu-Pod-Verbindungen erzwingen.

Lösung: Verwenden Sie Firewallrichtlinien für Clusterperimeter. Weitere Informationen finden Sie unter Kommunikation zwischen Pods und Services 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 Backends. Verwenden Sie für öffentliche HTTP(S)-Anwendungen Ingress oder die Gateway API. Weitere Informationen finden Sie unter Load-Balancing in GKE.

Herausforderung: Beobachtbarkeitstools zum Monitoring und zur Problembehebung bei Arbeitslasten verwenden

Szenario:Sie müssen Probleme mit dem Netzwerkverkehr beheben und GKE-Traffic-Flüsse nachvollziehen und überwachen, um Probleme effektiv zu diagnostizieren.

Lösung: Implementieren Sie Beobachtbarkeitstools, um den Netzwerkverkehr zu überwachen und Fehler zu beheben.

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: Einen stabilen Endpunkt für die Pod-zu-Pod-Kommunikation bereitstellen

Szenario:Ihre Anwendung benötigt Pods, um mit anderen Pods zu kommunizieren, aber die dynamischen IP-Adressen, die von Pods verwendet werden, machen diese Kommunikation unzuverlässig.

Lösung: Erstellen Sie einen Kubernetes-Dienst. Ein ClusterIP-Dienst stellt eine stabile virtuelle IP-Adresse und einen DNS-Namen bereit, wobei ein Load Balancing über Pods hinweg erfolgt. Weitere Informationen finden Sie unter Kubernetes-Dienste.

Challenge: Dienst für externen Zugriff verfügbar machen

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-Features bieten. Weitere Informationen finden Sie unter LoadBalancer-Dienste.

Herausforderung: Eine dauerhafte, 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.

Aufgabe: Erweitertes Traffic-Routing verwalten

Szenario: Wenn Ihre Anwendung wächst, benötigen Sie eine komplexere Kontrolle über die Weiterleitung des Traffics. Möglicherweise ist z. B. Folgendes nötig:

  • Mehrere Websites (z. B. api.beispiel.de und shop.beispiel.de) auf einem einzelnen Load-Balancer hosten, um Kosten zu sparen.
  • Anfragen anhand des URL-Pfads an verschiedene Dienste weiterleiten (z. B. / an die Frontend-Arbeitslast und /api/v1 an die Backend-Arbeitslast senden).
  • Sichern Sie Ihre Anwendung mit HTTPS, indem Sie TLS-Zertifikate verwalten.
  • Mit Canary-Releases können Sie neue Funktionen sicher in Phasen bereitstellen. Dabei wird ein kleiner Teil des Traffics an eine neue Version gesendet, bevor ein vollständiger Roll-out erfolgt.

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

Anwendungsfall: Service Discovery für eine wachsende Anwendung skalieren

Wenn der Traffic und die Komplexität Ihrer auf Mikrodiensten basierenden Anwendung zunehmen, steigt die Anzahl der DNS-Abfragen zwischen Diensten erheblich. Entwickler müssen zwar wissen, wie sie in dieser Umgebung stabile Anwendungen erstellen, aber Plattform- und Betriebsteams sind oft für die Implementierung skalierbarer Netzwerklösungen verantwortlich.

Challenge: Dienst-zu-Dienst-Kommunikation aktivieren

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

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

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

Szenario:Ein hohes Abfragevolumen führt zu Verzögerungen bei der Suche.

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

Herausforderung: Service Discovery über die VPC hinweg bereitstellen

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

Lösung:Cloud DNS einbinden, 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 Teil eines Plattformentwicklungsteams, das eine dreistufige Anwendung (Frontend, Abrechnung, Datenbank) bereitstellt. Sie müssen die Zero-Trust-Kommunikation erzwingen.

Challenge: Strikte Verkehrsregeln durchsetzen

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. Frontend lässt Traffic zu Billing zu, Billing lässt Traffic zu Database zu). Weitere Informationen finden Sie unter Netzwerkrichtlinien für Anwendungen konfigurieren.

Aufgabe: Netzwerkrichtlinien prüfen und verifizieren

Szenario: Die 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.

Aufgabe: Dienst privat für Nutzer verfügbar machen

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

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

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

Als Teil eines Plattform-Engineering-Teams stellen Sie mehreren Anwendungsteams GKE-Cluster zur Verfügung. Sie müssen die Netzwerksteuerung zentralisieren, IP-Adressen einsparen und strenge Sicherheitsmaßnahmen durchsetzen.

Herausforderung: Netzwerksteuerung zentralisieren

Szenario:Mehrere App-Teams benötigen eigene Cluster, die Netzwerkfunktionen müssen jedoch zentral verwaltet werden.

Lösung: Verwenden Sie 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.

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

Szenarien:

  • Das Unternehmen benötigt hohe Leistung und 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 Multi-Mandanten-Cluster erzwingen, um die Einhaltung regulatorischer Anforderungen zu erfüllen.
  • Cluster müssen so konfiguriert sein, dass sie eine moderne Netzwerk-Dataplane für hohe Leistung und Sicherheit verwenden, und sie müssen innerhalb der zentral verwalteten Netzwerkstruktur der Organisation bereitgestellt werden.

Lösung:Verwenden Sie GKE Dataplane V2, die auf eBPF basiert und für hohe Leistung und integrierte Durchsetzung von Netzwerkrichtlinien sorgt. Weitere Informationen finden Sie unter GKE Dataplane V2.

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

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

Das folgende Diagramm zeigt die End-to-End-Architektur einer sicheren, mehrstufigen Einzelhandelsanwendung, die in GKE bereitgestellt wird. Die Architektur durchläuft mehrere Phasen:

  • Phase 1: Grundlegende Einrichtung mit einer gemeinsam genutzten VPC und GKE Dataplane V2 erstellen.
  • Phase 2:Anwendung mit der Gateway-APIverfügbar machen.
Diagramm der End-to-End-Architektur für eine sichere, mehrstufige Einzelhandelsanwendung in GKE, in dem Netzwerkkomponenten in sechs Phasen der Bereitstellung und Skalierung dargestellt werden.
Abbildung 1. Eine End-to-End-Architektur für eine sichere, mehrschichtige Einzelhandelsanwendung in GKE, in der die wichtigsten Netzwerkkomponenten hervorgehoben werden, die in jeder Phase der Bereitstellung und Skalierung verwendet werden. Die Details der einzelnen Phasen werden in den folgenden Abschnitten beschrieben.

Phase 1: Plattformgrundlage schaffen

Herausforderung:Das Netzwerk für mehrere Anwendungsteams zentralisieren und genügend IP-Adressen zuweisen, um die Skalierung zu ermöglichen.

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 Latenz von DNS-Lookups bei zunehmendem Traffic reduzieren.

Lösung:

Nächste Schritte