IP-Adressierung in GKE

Zum Erstellen skalierbarer und sicherer Google Kubernetes Engine-Cluster (GKE) müssen Sie die IP-Adressierung effektiv verwalten. In diesem Dokument finden 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 Google Cloudfinden Sie unter Häufig verwendete GKE Enterprise-Nutzerrollen und Aufgaben.

Bevor Sie fortfahren, sollten Sie mit den folgenden Konzepten vertraut sein:

Wie IP-Adressen GKE-Komponenten verbinden

GKE basiert auf dem Kubernetes-Netzwerkmodell, bei dem jede Komponente eine eigene IP-Adresse für die Kommunikation haben muss. In den folgenden Abschnitten wird beschrieben, wie GKE IP-Adressen für die Kernkomponenten des Clusters 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 mit dem 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 pro Pod“ weist GKE jedem Pod eine eindeutige IP-Adresse aus einem Pod-CIDR-Bereich zu, der dem Knoten zugewiesen ist. In GKE werden Pod-IP-Adressen nativ im VPC-Netzwerk weitergeleitet. Diese integrierte Routingfähigkeit ermöglicht die direkte Kommunikation zwischen Pods – auch über verschiedene Knoten hinweg – ohne Network Address Translation (NAT). Alle Container innerhalb eines einzelnen Pods verwenden 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. Diese ClusterIP bietet einen einzelnen, zuverlässigen Endpunkt für eine Gruppe von Pods. Wenn Sie Traffic an die ClusterIP senden, führt GKE automatisch einen Load-Ausgleich auf einen fehlerfreien Pod innerhalb dieses Service durch.

  • Steuerungsebene: In privaten Clustern befindet sich die Steuerungsebene in einem von Google verwalteten Mandantenprojekt und verwendet einen eigenen internen IP-Adressbereich. Dieses Mandantenprojekt ist 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, dass Google 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 IP-Adressen den 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-Adress bereich 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.
Service (ClusterIP) GKE weist jedem Service 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 ist 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

Wenn Sie GKE effektiv nutzen möchten, müssen Sie die Unterschiede zwischen dem abstrakten Kubernetes-Netzwerkmodell und der Implementierung dieses Modells in GKE verstehen Google Cloud.

  • 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 schaffen, in dem Pods sich über ihre zugewiesenen IP-Adressen erreichen können.

  • GKE-Implementierung der IP-Adressierung: GKE implementiert das Kubernetes-IP-Adressierungsmodell in GKE Google Cloud durch die Integration mit VPC-nativen Netzwerken. 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 im 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 Kubernetes-Service-IP-Adressen (z. B. ClusterIPs) im VPC-Netzwerk. Wenn Sie LoadBalancer Services für die externe Bereitstellung erstellen, stellt GKE Google Cloud Load-Balancer bereit. Diese Load-Balancer verwenden öffentliche oder interne IP-Adressen aus Ihrem VPC-Netzwerk. GKE nutzt Google Cloud's robuste IP-Adressierungs- und Netzwerkinfrastruktur, um Kubernetes-IP-basierte Netzwerkkonzepte auf skalierbare und sichere Weise zu implementieren.

GKE-Netzwerkmodell: VPC-native Cluster

GKE implementiert das Kubernetes-Netzwerkmodell mit VPC-nativen Netzwerken, einer Kern Google Cloud funktion von Google Cloud.

Dieses Modell verwendet Alias-IP-Adressbereiche. 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 direkt in Ihrem VPC-Netzwerk routingfähig. Dies vereinfacht das Netzwerk design und ermöglicht die direkte Kommunikation mit niedriger 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 älteren routenbasierten Clustern darstellt und für groß angelegte Bereitstellungen wichtig ist.
  • Sicherheit verbessern: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 Standard- und empfohlene Netzwerkmodus für alle GKE-Cluster.

Warum eine effektive IP-Adressverwaltung entscheidend ist

Damit Ihr Cluster skaliert werden kann und die Anwendungsstabilität erhalten bleibt, müssen Sie Ihren IP-Adressbereich effektiv planen:

  • Skalierbarkeit gewährleisten: Planen Sie die IP-Adressbereiche für Knoten, Pods und Services effektiv, um eine Erschöpfung der IP-Adressen zu vermeiden und Ihren Cluster zu skalieren ohne dass eine störende Neugestaltung der Netzwerkarchitektur erforderlich ist.
  • Zuverlässigkeit garantieren: Vermeiden Sie überlappende 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: Verwalten Sie IP-Adressen effektiv, 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 Workload-Isolation auf Netzwerkebene.

IP-Adressierungsmodell für Ihren Cluster auswählen

GKE unterstützt mehrere Netzwerkstack-Konfigurationen, um Ihre Netzwerkanforderungen zu erfüllen, darunter Optionen für nur IPv4, Dual-Stack (IPv4 und IPv6) und bald auch nur IPv6.

Nur IPv4 (Single-Stack)

Dies ist die Standard- und häufigste Konfiguration, bei der alle Clusterkomponenten IPv4-Adressen verwenden. Auch innerhalb eines Modells, das nur IPv4 verwendet, bietet GKE Flexibilität:

  • Private IP-Adressen gemäß RFC 1918: Verwenden Sie private IP-Adressbereiche gemäß RFC 1918 (z. B. 10.0.0.0/8) für Ihren Cluster.
  • Privat verwendete öffentliche IP-Adressen (PUPIs): Wenn Ihre Organisation nicht über genügend private IP-Adressbereiche 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 Agenten konfigurieren. Dieser Agent führt eine Quellnetzwerkadressübersetzung (SNAT) für ausgehenden Traffic von Pods durch. Ohne SNAT wird der Rücktraffic zu einem Pod, der eine PUPI verwendet, über das öffentliche Internet weitergeleitet und schlägt fehl. Der IP-Maskierungsagent verhindert dies, indem er die Quell-IP-Adresse ausgehender Pakete von der PUPI des Pods in die interne IP-Adresse des Knotens ändert. Dieser Ansatz trägt dazu bei, dass der Rücktraffic 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 Services in einem Dual-Stack-Cluster sowohl eine IPv4- als auch eine IPv6-Adresse zu. Dieses Modell ist ideal für folgende Szenarien:

  • Erleichterung eines schrittweisen Übergangs zu IPv6.
  • Sicherstellung der Kompatibilität mit IPv6-fähigen Workloads sowie mit vorhandenen Clients und Services, die nur IPv4 verwenden.

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