IP-Adressierung in GKE

Um skalierbare und sichere GKE-Cluster (Google Kubernetes Engine) zu erstellen, müssen Sie die IP-Adressierung effektiv verwalten. Dieses Dokument bietet 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-Unternehmensnutzerrollen und -Aufgaben.

Machen Sie sich vor dem Fortfahren mit den folgenden Konzepten vertraut:

Verbindung von GKE-Komponenten über IP-Adressen

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

  • Knoten: GKE weist jedem Knoten, bei dem es sich um eine Compute Engine-VM-Instanz handelt, eine interne IP-Adresse aus dem primären IP-Adressbereich des Subnetzes zu, das mit seinem Knotenpool verknüpft 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-per-Pod“ weist GKE jedem Pod eine eindeutige IP-Adresse aus einem Pod-CIDR-Bereich zu, der dem Knoten zugewiesen ist. In GKE leitet das VPC-Netzwerk Pod-IP-Adressen nativ weiter. Diese integrierte Routingfähigkeit ermöglicht die direkte Kommunikation zwischen Pods – auch über verschiedene Knoten hinweg –, ohne dass Network Address Translation (NAT) erforderlich ist. Alle Container innerhalb eines einzelnen Pods haben dieselbe IP-Adresse und können über localhost kommunizieren.

  • Dienste (ClusterIP): GKE weist jedem ClusterIP-, NodePort- und LoadBalancer-Dienst eine stabile, interne virtuelle IP-Adresse (die ClusterIP) zu. Für IPv4-Dienste weist GKE diese Adresse aus einem dedizierten sekundären IP-Adressbereich (oder aus dem 34.118.224.0/20-Bereich) zu. Für IPv6-Services (in Dual-Stack- und Single-Stack-IPv6-Clustern) verwendet GKE keinen sekundären IP-Adressbereich. Stattdessen weist GKE Adressen aus dem privaten 2600:2D00:0:4::0:0/64-IPv6-Adressbereich von Google zu. Dieser ClusterIP stellt einen einzelnen, zuverlässigen internen Endpunkt für eine Gruppe von Pods bereit. Wenn Sie Traffic an den ClusterIP senden, führt GKE automatisch ein Load Balancing zu einem 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 stellt eine Verbindung zu Ihrem VPC-Netzwerk her und ermöglicht so 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 ist zusammengefasst, wie GKE Clusterkomponenten IP-Adressen zuweist:

Komponente Zuweisung von IP-Adressen
Knoten Die GKE weist jedem Knoten eine interne IP-Adresse zu. Die 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 dem Knoten zugewiesen ist.
Dienst (ClusterIP) GKE weist jedem Service eine stabile virtuelle IP-Adresse (ClusterIP) zu. Bei IPv4-Services weist GKE diese Adresse aus einem dedizierten sekundären IP-Adressbereich innerhalb des VPC-Netzwerk des Clusters (oder aus 34.118.224.0/20) zu. Bei IPv6-Services verwendet GKE keinen sekundären IP-Adressbereich. Stattdessen weist GKE Adressen aus dem Bereich 2600:2D00:0:4::0:0/64 zu.
Steuerungsebene In privaten Clustern hat die GKE-Steuerungsebene einen eigenen internen IP-Adressbereich innerhalb eines von Google verwalteten Mandantenprojekts. Dieses Mandantenprojekt stellt eine Verbindung zu Ihrem VPC-Netzwerk her, 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

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

  • Kubernetes-IP-Adressierungsmodell: Das Open-Source-Kubernetes-Projekt gibt an, dass jeder Pod eine eindeutige IP-Adresse erhält. Alle Pod-IP-Adressen können direkt ohne Network Address Translation (NAT) kommunizieren. Dieser Ansatz trägt dazu bei, einen flachen Netzwerkbereich zu gewährleisten, in dem Pods sich gegenseitig über ihre zugewiesenen IP-Adressen erreichen können.

  • GKE-IP-Adressierungsimplementierung: GKE implementiert das Kubernetes-IP-Adressierungsmodell in Google Cloud durch die Integration in VPC-natives Netzwerk. In IPv4- und Dual-Stack-Clustern weist GKE beim Erstellen eines Pods dessen IP-Adresse aus einem VPC-Alias-IP-Adressbereich zu. In Einzelstack-IPv6-Clustern verwendet GKE keine Alias-IP-Adressbereiche. Stattdessen weist die GKE Pod-IP-Adressen direkt aus einem Unterbereich auf dem Knoten zu. Dadurch ist die IP-Adresse jedes Pods nativ im gesamten VPC-Netzwerk routingfähig. Dies ermöglicht eine direkte Kommunikation nicht nur zwischen Pods, sondern auch mit anderenGoogle Cloud -Ressourcen wie Compute Engine-Instanzen und Cloud SQL-Datenbanken. Ebenso verwaltet die GKE Kubernetes-Service-IP-Adressen (z. B. ClusterIPs) 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. Die GKE verwendet die robuste IP-Adressierungs- und Netzwerkinfrastruktur von Google Cloud, um IP-basierte Netzwerkkonzepte von Kubernetes skalierbar und sicher zu implementieren.

GKE-Netzwerkmodell: VPC-native Cluster

Die GKE implementiert das Kubernetes-Netzwerkmodell mithilfe von VPC-nativen Netzwerken, einer zentralen Funktion von Google Cloud .

In IPv4- und Dual-Stack-Clustern verwendet dieses Modell Alias-IP-Adressbereiche: In einem VPC-nativen Cluster konfiguriert Kubernetes Pod-IP-Adressen als Alias-IP-Adressbereiche auf der virtuellen Netzwerkschnittstelle des Knotens. Einzelstack-IPv6-Cluster weisen Knoten- und Pod-IP-Adressbereiche direkt aus dem Subnetz-CIDR-Block zu, ohne Alias-IP-Adressbereiche zu verwenden.

Diese Implementierung bietet mehrere wichtige Vorteile:

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

VPC-nativ ist der standardmäßige und empfohlene Netzwerkmodus für alle GKE-Cluster.

Warum eine effektive Verwaltung von IP-Adressen wichtig ist

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

  • Skalierbarkeit sicherstellen: Planen Sie die IP-Adressbereiche für Knoten, Pods und Dienste effektiv, um eine Erschöpfung der IP-Adressen zu vermeiden und die Skalierung Ihres Clusters ohne störende Netzwerkarchitekturänderungen zu ermöglichen.
  • Zuverlässigkeit gewährleisten: Vermeiden Sie sich überschneidende IP-Adressbereiche zwischen Ihrem GKE-Cluster und anderen Netzwerken, z. B. lokalen Umgebungen, die über Cloud VPN verbunden sind. Sich überschneidende Bereiche können zu Routingkonflikten, unvorhersehbarem Verhalten und Dienstunterbrechungen führen.
  • Mehr Sicherheit: Verwalten Sie IP-Adressen effektiv, um die Netzwerksicherheit zu erhöhen. Definieren Sie Kubernetes-Netzwerkrichtlinien, um den Trafficfluss 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 mehrere Netzwerkstack-Konfigurationen, um Ihre Netzwerkanforderungen zu erfüllen, darunter Nur-IPv4-, Dual-Stack- (IPv4- und IPv6-Adressen) und Single-Stack-IPv6-Optionen.

Nur IPv4 (einzelner Stack)

Dies ist die Standardkonfiguration und die am häufigsten verwendete Konfiguration, bei der alle Clusterkomponenten IPv4-Adressen verwenden. Auch innerhalb eines reinen IPv4-Modells 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 Ihre Organisation nicht über genügend private IP-Adressen verfügt, 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-Masquerading-Agent konfigurieren. Dieser Agent führt eine Quellnetzwerkadressübersetzung (SNAT) für ausgehenden Traffic von Pods durch. Ohne SNAT wird der Rückgabetraffic 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ückverkehr korrekt an den Knoten 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 Services in einem Dual-Stack-Cluster sowohl eine IPv4- als auch eine IPv6-Adresse zu. Dieses Modell ist ideal für:

  • Ermöglicht einen schrittweisen Übergang zu IPv6-Adressen.
  • Kompatibilität mit IPv6-fähigen Arbeitslasten und vorhandenen IPv4-Clients und -Diensten

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

Single-Stack-IPv6 (Vorabversion)

Ein Einzelstack-IPv6-Cluster weist nur IPv6-Adressen für die gesamte Cluster-Datenebene (Pods, Knoten und Dienste) zu. Dieses Modell umgeht Engpässe bei der Erschöpfung privater IPv4-Adressen (RFC 1918) und sorgt gleichzeitig für eine sichere interne oder externe Verbindung für eingehenden und ausgehenden Traffic. Im Gegensatz zu IPv4- und Dual-Stack-Clustern, die Alias-IP-Adressbereiche verwenden, weisen Einzelstack-IPv6-Cluster einen /96-Teilbereich von IPv6-Adressen pro Knoten direkt aus Ihrem Subnetzwerk (/64) zu und weisen Pods auf jedem Knoten einen /112-Adressbereich zu. Dienste (ClusterIP) erhalten Adressen aus einem privaten IPv6-Adressbereich von Google (2600:2D00:0:4::0:0/64). Single-Stack-IPv6-Cluster unterstützen auch BYOIP-IPv6-Adressbereiche, die mit dem BYOIPv6-EAP-Prozess konfiguriert wurden.

Weitere Informationen zur Zuweisung und zum Verhalten von Single-Stack-IPv6-Adressen finden Sie unter Single-Stack-IPv6-Cluster erstellen und verwalten.

Nächste Schritte