IP-Adressierung in GKE

Um skalierbare und sichere GKE-Cluster (Google Kubernetes Engine) zu erstellen, müssen Sie die IP-Adressierung effektiv verwalten. In diesem Dokument erhalten Sie einen umfassenden Überblick darüber, wie GKE IP-Adressen für die Clusterkommunikation verwendet, welche Netzwerkmodelle unterstützt werden und welche Best Practices für eine effektive IP-Adressverwaltung gelten.

Dieses Dokument richtet sich an Cloud-Architekten und Netzwerkspezialisten, die das Netzwerk für ihre Organisation entwerfen und erstellen. Weitere Informationen zu gängigen Rollen und Beispielaufgaben in Google Cloudfinden Sie unter Häufig verwendete GKE Enterprise-Nutzerrollen und -Aufgaben.

Bevor Sie fortfahren, sollten Sie sich mit den folgenden Konzepten vertraut machen:

So werden GKE-Komponenten über IP-Adressen verbunden

GKE basiert auf dem Kubernetes-Netzwerkmodell, das für die Kommunikation eine eindeutige IP-Adresse für jede Komponente erfordert. In den folgenden Abschnitten wird beschrieben, wie GKE IP-Adressen für die wichtigsten Clusterkomponenten zuweist und verwendet:

  • Knoten: GKE weist jedem Knoten, der eine Compute Engine-VM-Instanz ist, eine interne IP-Adresse aus dem primären IP-Adressbereich des Subnetzes zu, das seinem Knotenpool zugeordnet ist. Diese IP-Adresse ermöglicht die Kommunikation zwischen dem Knoten und der Kubernetes-Steuerungsebene. Knoten können auch eine externe IP-Adresse für den ausgehenden Internetzugriff haben.

  • Pods: Gemäß dem Kubernetes-Modell „IP-Adresse pro Pod“ weist GKE jedem Pod eine eindeutige IP-Adresse aus einem dem Knoten zugewiesenen Pod-CIDR-Bereich zu. In GKE werden Pod-IP-Adressen nativ über das VPC-Netzwerk weitergeleitet. Diese integrierte Routbarkeit ermöglicht die direkte Kommunikation zwischen Pods, auch über verschiedene Knoten hinweg, ohne dass eine Network Address Translation (NAT) erforderlich ist. Alle Container in einem einzelnen Pod haben dieselbe IP-Adresse und können über localhost kommunizieren.

  • Services: GKE weist jedem Kubernetes-Service eine stabile virtuelle IP-Adresse (die ClusterIP) aus einem dedizierten sekundären IP-Adressbereich zu. Dieser ClusterIP bietet einen einzelnen, zuverlässigen Endpunkt für eine Gruppe von Pods. Wenn Sie Traffic an die ClusterIP senden, führt GKE automatisch ein Load-Balancing für einen fehlerfreien Pod innerhalb dieses Dienstes durch.

  • Steuerungsebene: In privaten Clustern befindet sich die Steuerungsebene in einem von Google verwalteten Mandantenprojekt und verwendet einen eigenen internen IP-Adressbereich. Dieses Mandantenprojekt wird mit Ihrem VPC-Netzwerk verbunden und ermöglicht eine sichere Kommunikation zwischen der Steuerungsebene und den Knoten im VPC-Netzwerk Ihres Clusters. Für diese Verbindung wird in der Regel Private Service Connect verwendet.

  • Load Balancer: Wenn Sie Anwendungen im Internet oder in Ihrem VPC-Netzwerk bereitstellen möchten, können Sie GKE so konfigurieren, dassGoogle Cloud -Load Balancer verwendet werden. Externe Load-Balancer verwenden öffentliche IP-Adressen. Interne Load-Balancer verwenden interne IP-Adressen aus dem primären Subnetzbereich Ihres VPC-Netzwerk.

In der folgenden Tabelle wird zusammengefasst, wie GKE IP-Adressen Clusterkomponenten zuweist:

Komponente Zuweisung von IP-Adressen
Knoten GKE weist jedem Knoten eine interne IP-Adresse zu. GKE weist diese IP-Adresse aus dem primären IP-Adressbereich des Subnetzes zu, das mit dem Knotenpool des Knotens verknüpft ist. Dieses Subnetz kann entweder das Standardsubnetz des Clusters oder ein zusätzliches Subnetz sein.
Pod GKE weist jedem Pod eine eindeutige IP-Adresse aus dem Pod-CIDR-Bereich zu, der seinem Knoten zugewiesen ist.
Dienst (ClusterIP) GKE weist jedem Dienst eine stabile virtuelle IP-Adresse (ClusterIP) aus einem dedizierten sekundären IP-Adressbereich im VPC-Netzwerk des Clusters zu.
Steuerungsebene In privaten Clustern hat die GKE-Steuerungsebene einen eigenen internen IP-Adressbereich in einem von Google verwalteten Mandantenprojekt. Dieses Mandantenprojekt wird mit Ihrem VPC-Netzwerk verbunden, in der Regel über Private Service Connect.
Load-Balancer Externe Load-Balancer verwenden öffentliche IP-Adressen. Interne Load-Balancer verwenden interne IP-Adressen aus dem primären IP-Adressbereich des Subnetzes des Clusters.

Kubernetes-IP-Adressierung und GKE-Implementierung

Um GKE effektiv nutzen zu können, müssen Sie die Unterschiede zwischen dem abstrakten Kubernetes-Netzwerkmodell und der Implementierung dieses Modells in GKE auf Google Cloudverstehen.

  • Kubernetes-IP-Adressierungsmodell: Im Open-Source-Kubernetes-Projekt ist festgelegt, dass jeder Pod eine eindeutige IP-Adresse erhält. Alle Pod-IP-Adressen können direkt ohne Network Address Translation (NAT) kommunizieren. So wird ein flacher Netzwerkbereich geschaffen, in dem Pods sich über ihre zugewiesenen IP-Adressen erreichen können.

  • GKE-Implementierung der IP-Adressierung: GKE implementiert das Kubernetes-IP-Adressierungsmodell auf Google Cloud durch die Integration in VPC-natives Networking. Wenn Sie einen Pod erstellen, weist GKE ihm eine IP-Adresse aus einem VPC-Alias-IP-Adressbereich zu. Dadurch ist die IP-Adresse jedes Pods nativ in Ihrem gesamten VPC-Netzwerk routingfähig. Dies ermöglicht die direkte Kommunikation nicht nur zwischen Pods, sondern auch mit anderen Google Cloud -Ressourcen wie Compute Engine-Instanzen und Cloud SQL-Datenbanken. Ebenso verwaltet GKE die Kubernetes-Service-IP-Adressen (z. B. ClusterIP) im VPC-Netzwerk. Wenn Sie LoadBalancer-Dienste für die externe Bereitstellung erstellen, stellt GKEGoogle Cloud -Load-Balancer bereit. Diese Load-Balancer verwenden öffentliche oder interne IP-Adressen aus Ihrem VPC-Netzwerk. GKE nutzt die robuste IP-Adressierungs- und Netzwerkinfrastruktur von Google Cloud, um Kubernetes-IP-basierte Netzwerkkonzepte auf skalierbare und sichere Weise zu implementieren.

GKE-Netzwerkmodell: VPC-native Cluster

GKE implementiert das Kubernetes-Netzwerkmodell mit VPC-nativem Networking, einer Kernfunktion von Google Cloud .

In diesem Modell werden Alias-IP-Adressbereiche verwendet. In einem VPC-nativen Cluster konfiguriert Kubernetes Pod-IP-Adressen als Alias-IP-Adressbereiche auf der virtuellen Netzwerkschnittstelle des Knotens.

Diese Implementierung bietet mehrere wichtige Vorteile:

  • VPC-native Routingfähigkeit:Pod-IP-Adressen sind in Ihrem VPC-Netzwerk direkt routingfähig. Dies vereinfacht das Netzwerkdesign und ermöglicht eine direkte Kommunikation mit geringer Latenz zwischen Ihren Pods und anderen Google Cloud Ressourcen wie Compute Engine-Instanzen und Cloud SQL-Instanzen.
  • Routenkontingent sparen:Wenn Sie Alias-IP-Adressen für Pods verwenden, erstellt GKE keine benutzerdefinierten statischen Routen für jeden Knoten. Dadurch wird Ihr VPC-Routenkontingent geschont, was eine erhebliche Verbesserung gegenüber den alten routenbasierten Clustern darstellt und für groß angelegte Bereitstellungen wichtig ist.
  • Sicherheit verbessern:Mit der VPC-nativen Weiterleitung können Sie VPC-native Firewallregeln direkt auf Ihren Pod-Traffic anwenden und so die Sicherheit auf Netzwerkebene verbessern.

VPC-nativ ist der Standard- und empfohlene Netzwerkmodus für alle GKE-Cluster.

Warum ein effektives IP-Adressmanagement entscheidend ist

Damit Ihr Cluster skaliert werden kann und die Anwendung fehlerfrei funktioniert, müssen Sie Ihren IP-Adressbereich effektiv planen:

  • Skalierbarkeit sicherstellen: Planen Sie die IP-Adressbereiche für Knoten, Pods und Dienste effektiv, um eine Ausschöpfung der IP-Adressen zu verhindern und eine Skalierung Ihres Clusters ohne störende Netzwerkarchitekturänderungen zu ermöglichen.
  • Zuverlässigkeit garantieren: Vermeiden Sie sich überschneidende IP-Adressbereiche zwischen Ihrem GKE-Cluster und anderen Netzwerken, z. B. lokalen Umgebungen, die über Cloud VPN verbunden sind. Überlappende Bereiche können zu Routingkonflikten, unvorhersehbarem Verhalten und Dienstunterbrechungen führen.
  • Sicherheit erhöhen: IP-Adressen effektiv verwalten, um die Netzwerksicherheit zu erhöhen. Definieren Sie Kubernetes-Netzwerkrichtlinien, um den Traffic-Fluss zwischen Pods zu steuern, und konfigurieren Sie Firewallregeln für die Arbeitslastisolierung auf Netzwerkebene.

IP-Adressierungsmodell für den Cluster auswählen

GKE unterstützt verschiedene Netzwerkstack-Konfigurationen, um Ihre Netzwerkanforderungen zu erfüllen, darunter Nur-IPv4-, Dual-Stack- (IPv4 und IPv6) und demnächst auch Nur-IPv6-Optionen.

Nur IPv4 (Single-Stack)

Dies ist die Standard- und häufigste Konfiguration, bei der alle Clusterkomponenten IPv4-Adressen verwenden. Auch in einem reinen IPv4-Modell bietet GKE Flexibilität:

  • Private IP-Adressen gemäß RFC 1918: Verwenden Sie für Ihren Cluster private IP-Adressbereiche gemäß RFC 1918, z. B. 10.0.0.0/8.
  • Privat verwendete öffentliche IP-Adressen (PUPIs): Wenn Ihrer Organisation nicht genügend private IP-Adressbereiche zur Verfügung stehen, können Sie öffentliche IP-Adressbereiche für die interne Verwendung in Ihrem VPC-Netzwerk verwenden. Wenn Sie PUPIs verwenden, müssen Sie den IP-Masquerade-Agent konfigurieren. Dieser Agent führt eine Quellnetzwerkadressübersetzung (Source Network Address Translation, SNAT) für ausgehenden Traffic von Pods aus. Ohne SNAT wird der Rückgabe-Traffic zu einem Pod, der eine PUPI verwendet, über das öffentliche Internet weitergeleitet und schlägt fehl. Der IP Masquerade Agent verhindert dies, indem er die Quell-IP-Adresse ausgehender Pakete von der PUPI des Pods in die interne IP-Adresse des Knotens ändert. So wird sichergestellt, dass der Rückgabe-Traffic korrekt an den Knoten zurückgeleitet und dann an den ursprünglichen Pod weitergeleitet wird.

Dual-Stack (IPv4 und IPv6)

Ein Dual-Stack-Cluster verwendet sowohl IPv4- als auch IPv6-Protokolle. GKE weist Knoten, Pods und Diensten in einem Dual-Stack-Cluster sowohl eine IPv4- als auch eine IPv6-Adresse zu. Dieses Modell ist ideal für:

  • Erleichtert den schrittweisen Übergang zu IPv6.
  • Sorgen Sie für Kompatibilität mit sowohl IPv6-fähigen Arbeitslasten als auch vorhandenen reinen IPv4-Clients und ‑Diensten.

Sie können die Verwendung eines Dual-Stack-Netzwerks beim Erstellen eines Clusters aktivieren oder einen vorhandenen Single-Stack-Cluster auf Dual-Stack umstellen.

Nächste Schritte