IP-Adressen bei der Migration zu GKE planen

In diesem Dokument wird beschrieben, wie Sie die Verwendung von IP-Adressen in Google Kubernetes Engine (GKE) verwalten und bei Bedarf alternative Netzwerkmodelle in GKE verwenden. In diesem Dokument werden die folgenden Konzepte behandelt:

  • Nutzung von Pod-IP-Adressen in GKE reduzieren, damit GKE die IP-Adressanforderungen der meisten Organisationen erfüllt
  • Alternative Netzwerkmodelle in GKE implementieren, wenn die Clusterarchitektur nicht die Anforderungen Ihrer Organisation erfüllt.

Dieses Dokument für Cloud-Architekten, Betriebstechniker und Netzwerktechniker, die Kubernetes-Cluster aus anderen Umgebungen zu GKE migrieren möchten. Folgen Sie der Anleitung in diesem Dokument, wenn es in Ihrer Organisation schwierig ist, genügend interne IP-Adressen für die erwartete Nutzung von GKE zuzuweisen.

In diesem Dokument wird davon ausgegangen, dass Sie mit Kubernetes und dem zugehörigen Netzwerkmodell vertraut sind. Außerdem sollten Sie mit Netzwerkkonzepten wie IP-Adressierung, Network Address Translation (NAT), Firewalls und Proxys vertraut sein.

In diesem Dokument werden keine Verwaltungsstrategien für den Adressbereich behandelt, der für Service-IP-Adressen verwendet wird. Die Anzahl der für Services erforderlichen Adressen ist viel niedriger als für Pods und die Optionen zur Reduzierung dieser Anzahl sind begrenzt. In GKE ist der Service-IP-Adressbereich für die gesamte Lebensdauer des Clusters festgelegt. Daher muss der Bereich der Service-IP-Adressen auf die größte erwartete Anzahl von Services ausgelegt sein. Da Service-IP-Adressen außerhalb des Clusters nicht erreichbar sind, können Sie diese Adressen in anderen Netzwerken wiederverwenden.

Dieses Dokument bezieht sich auch auf verschiedene Kubernetes-Netzwerkmodelle: vollständig integriert, Inselmodus und isoliert. Diese Modelle unterscheiden sich darin, wie Pod-IP-Adressen im gesamten Netzwerk erreicht werden können. Diese Unterschiede wirken sich auf die verwendbaren IP-Adressverwaltungsstrategien aus. Ausführlichere Informationen zu diesen Modellen und zum GKE-Netzwerkmodell finden Sie unter Vergleich der von GKE und anderen Kubernetes-Implementierungen verwendeten Netzwerkmodelle.

Nutzung interner IP-Adressen in GKE reduzieren

GKE verwendet ein vollständig integriertes Netzwerkmodell, bei dem Cluster in einem VPC-Netzwerk bereitgestellt werden, das auch andere Anwendungen enthalten kann. Das GKE-Modell bietet viele Vorteile. Bei diesem Modelltyp können Pod-IP-Adressen jedoch nicht wiederverwendet werden. Aufgrund dieser fehlenden Wiederverwendbarkeit müssen Sie Pod-IP-Adressen verwenden, die im gesamten VPC-Netzwerk eindeutig sind. Daher müssen Sie sorgfältig überlegen, wie viele eindeutige IP-Adressen Sie benötigen.

Die Anzahl der eindeutigen Adressen, die Sie benötigen, hat Einfluss darauf, ob Sie die Verwendung der IP-Adresse so reduzieren müssen:

  • Wenn der Adressbereich für die erforderlichen IP-Adressen ausreicht, müssen Sie nicht unbedingt Maßnahmen ergreifen, um die Nutzung von IP-Adressen zu reduzieren. Es ist jedoch hilfreich zu wissen, wie Sie die Nutzung von IP-Adressen reduzieren, um die Mindestanzahl der zu verwendenden IP-Adressen zu ermitteln.
  • Wenn der Adressbereich nicht ausreicht, müssen Sie die Nutzung von IP-Adressen reduzieren, um GKE-Cluster zu erstellen, die den Einschränkungen Ihres Adressbereichs entsprechen.

Beachten Sie die folgenden Optionen, um die Nutzung von IP-Adressen in GKE zu reduzieren:

  • Einstellung für Pods pro Knoten ändern. Standardmäßig reservieren GKE-Standard-Cluster einen /24-Subnetzbereich für jeden Knoten und lassen bis zu 110 Pods pro Knoten zu. Wenn Sie maximal 64 Pods pro Knoten verwenden möchten, können Sie die maximale Anzahl von Pods pro Knoten anpassen und so die Nutzung von Pod-IP-Adressen um mindestens die Hälfte reduzieren. Autopilot-Cluster ermöglichen 32 Pods pro Knoten. Diese Einstellung kann nicht geändert werden.
  • Mehrere Pod-IP-Adressbereiche verwenden. Mit dem zusammenhängenden Multi-Pod-CIDR (Classless Inter-Domain Routing) können Sie sekundäre Cluster-IP-Adressbereiche zu vorhandenen Clustern hinzufügen. Sie können auswählen, welchen Pod-IP-Adressbereich jeder Knotenpool verwendet. Wenn Sie den von jedem Pool verwendeten IP-Adressbereich auswählen, können Sie beim Zuweisen des anfänglichen Pod-IP-Adressbereichs konservativ vorgehen und gleichzeitig den Cluster erweiterbar halten.

  • IP-Adressen außerhalb von RFC 1918 verwenden. Ihr Unternehmensnetzwerk hat möglicherweise nicht genügend nicht zugewiesene RFC 1918-IP-Adressen, die für Ihre Pod-IP-Adressen verwendet werden können. Wenn Sie nicht genügend nicht zugewiesene RFC 1918-IP-Adressen haben, können Sie Adressen außerhalb RFC 1918 wie Adressen im RFC 6598-Adressbereich (100.64.0.0/10) verwenden.

    Wenn Sie den RFC 6598-Bereich bereits in anderswo im Unternehmensnetzwerk verwenden, können Sie den Adressbereich Klasse E/RFC 5735 (240.0.0.0/4) für Pod-IP-Adressen nutzen. Der Traffic von diesen IP-Adressen wird jedoch auf Windows-Hosts und auf mancher lokalen Hardware blockiert. Wenn Sie vermeiden möchten, dass RFC 5735-Adressen blockiert werden, können Sie den Traffic zu diesen externen Zielen maskieren, wie im Abschnitt Pod-IP-Adressen nur in lokalen Netzwerken ausblenden beschrieben. Sie verlieren jedoch einige Telemetriedaten, die an lokale Anwendungen weitergeleitet werden, wenn Sie den Traffic zu externen Zielen maskieren.

Wenn Ihre Organisation einen großen öffentlichen IP-Adressbereich hat, können Sie auch privat verwendete öffentliche Adressen (PUPI-Adressen) verwenden. Wenn Sie PUPI-Adressen verwenden, müssen Sie die PUPI-Adressen in die Liste nonMasqueradeCIDRs aufnehmen, um eine Verbindung außerhalb des Clusters ohne NAT herzustellen.

Netzwerkmodell in GKE auswählen

Im Dokument zum GKE-Netzwerkmodell wird erläutert, wie Standardcluster in GKE funktionieren, einschließlich der beteiligten Pod-IP-Adressen. In diesem Dokument wird im Abschnitt Nutzung interner IP-Adressen in GKE reduzieren beschrieben, wie Sie die Anzahl der in diesen Clustern erforderlichen internen IP-Adressen reduzieren können. Kenntnisse über die Funktionsweise des GKE-Netzwerkmodells und das Reduzieren interner IP-Adressen sind für jedes in GKE verwendete Netzwerkmodell wichtig.

Wenn Sie diese Konzepte kennen und anwenden, erhalten Sie jedoch möglicherweise keine Netzwerkimplementierung, die Ihren Anforderungen entspricht. Mit dem folgenden Entscheidungsbaum können Sie entscheiden, wie Sie das für Sie am besten geeignete GKE-Netzwerkmodell implementieren:

Entscheidungsbaum für Strategien zur Migration von IP-Adressen in GKE.

Der Entscheidungsbaum beginnt immer mit der Erstellung von GKE-Standardclustern, die auf einem vollständig integrierten Netzwerkmodell basieren. Der nächste Schritt im Entscheidungsbaum besteht darin, die Nutzung von IP-Adressen zu reduzieren. Dazu werden alle in diesem Dokument beschriebenen Optionen angewendet.

Wenn Sie die IP-Adressnutzung so weit wie möglich reduziert haben und noch keinen ausreichenden Adressbereich für Ihre GKE-Cluster haben, benötigen Sie ein alternatives Netzwerkmodell. Anhand des Entscheidungsbaums können Sie entscheiden, welches der folgenden alternativen Netzwerkmodelle zu verwenden ist:

  • Pod-IP-Adressen nur in lokalen Netzwerken ausblenden. Verwenden Sie dieses Modell, wenn die folgenden Kriterien gelten:
    • Sie können den RFC 6598-Bereich nicht verwenden, um die Nutzung interner IP-Adressen zu reduzieren.
    • Sie können den Adressbereich der Klasse E/RFC 5735 verwenden und diesen Bereich in lokalen Netzwerken ausblenden.
  • Pod-IP-Adressen mithilfe von Private Service Connect ausblenden. Verwenden Sie dieses Modell, wenn die folgenden Kriterien gelten:
    • Sie können nicht den Adressbereich der Klasse E/RFC 5735 verwenden.
    • Ihre Cluster benötigen keine private Kommunikation mit Diensten im größeren Netzwerk.
    • Sie müssen Ihre Cluster nicht aus Regionen erreichen, die sich außerhalb der Region des Clusters befinden.
  • Pod-IP-Adressen über die interne Verwendung öffentlicher IP-Adressen und VPC-Netzwerk-Peering ausblenden. Obwohl dieses Modell selten erforderlich ist, verwenden Sie dieses Modell, wenn die folgenden Kriterien gelten:
    • Sie können nicht den Adressbereich der Klasse E/RFC 5735 verwenden.
    • Ihre Cluster benötigen private Kommunikation mit Diensten im größeren Netzwerk.
    • Ihrer Organisation wurde ein öffentlicher IP-Adressbereich zugewiesen, der nicht verwendet wird und der groß genug für Ihren größten Cluster ist.
  • Pod-IP-Adressen mithilfe von Cloud VPN ausblenden. Verwenden Sie dieses Modell, wenn Ihre Cluster keines der anderen im Entscheidungsbaum beschriebenen Kriterien erfüllen.

Dieser Entscheidungsbaum sollte nur zur Orientierung verwendet werden. Je nach Anwendungsfall möchten Sie möglicherweise ein anderes Modell verwenden, basierend auf den Vor- und Nachteilen jedes Modells. Häufig sind mehrere Modelle praktikabel und Sie können auswählen, welcher Ansatz am besten zu Ihrer Organisation passt.

Es gibt seltene Fälle, in denen die alternativen Modelle im Entscheidungsbaum nicht Ihren Anforderungen entsprechen. In diesen seltenen Fällen können Sie möglicherweise das unter Clusteradressen über Multi-NIC-Instanzen ausblenden beschriebene Modell verwenden.

Alternative Netzwerkmodelle emulieren

Damit Sie die Vorteile des vollständig integrierten Netzwerkmodells nutzen können, sollten sich Ihre GKE-Cluster im selben logischen Netzwerk wie Ihre anderen Cloud-Ressourcen befinden. Möglicherweise können Sie dieser Empfehlung jedoch nicht folgen. Möglicherweise haben Sie keinen ausreichenden IP-Adressbereich oder müssen Pod-IP-Adressen aus dem größeren Netzwerk Ihrer Organisation ausblenden.

In diesem Abschnitt werden Optionen zur Verwendung des vollständig integrierten Netzwerkmodells beschrieben. Dabei werden verschiedene Architekturmuster beschrieben, die verschiedene alternative Netzwerkmodelle in GKE imitieren. Diese alternativen Architekturmuster erstellen einen Betriebsmodus für GKE, der dem Netzwerkmodell im Inselmodus oder dem Netzwerkmodell im isolierten Modus ähnelt.

Jedes alternative Architekturmuster enthält die folgenden Informationen:

  • Eine Beschreibung des Architekturmusters

  • Ein Diagramm, das zeigt, wie dieses Muster implementiert wird

    Jedes Implementierungsdiagramm zeigt die Verwendung eines internen Load-Balancers. Wenn ein bestimmter Load Balancer im Diagramm nicht angezeigt wird, empfehlen wir die Verwendung des internen Passthrough-Network-Load-Balancers. Wenn Sie mehrere Backend-Dienste verwenden möchten, können Sie stattdessen einen internen Application Load Balancer verwenden.

  • Eine Beschreibung der Vor- und Nachteile dieses Musters

Pod-IP-Adressen nur in lokalen Netzwerken ausblenden

Das Architekturmuster, bei dem Sie IP-Adressen in lokalen Netzwerken ausblenden, verwendet eine Kombination der folgenden Routingziele:

  • Die GKE-Cluster in Google Cloud Pod-IP-Adressen zuweisen lassen, die über die Google Cloud-Bereitstellung weitergeleitet werden.
  • Verhindern, dass diese IP-Adressen ohne NAT über Cloud VPN oder Cloud Interconnect an lokale Ressourcen oder an andere Cloud-Umgebungen weitergeleitet werden

Dieses Architekturmuster wird häufig mit dem IP-Adressbereich der Klasse E/RFC 5735 verwendet, da dieser Bereich viele IP-Adressen enthält. Dadurch, dass so viele IP-Adressen verfügbar sind, kann leichter jedem Pod eine eindeutige IP-Adresse zugewiesen werden. IP-Adressen der Klasse E/RFC 5735 können jedoch nicht einfach an lokale Ressourcen weitergeleitet werden, da viele Netzwerkhardwareanbieter diesen Traffic blockieren.

Anstelle des IP-Adressbereichs der Klasse E/RFC 5735 können Sie auch RFC 1918-IP-Adressen oder eine interne Gruppe von IP-Adressen außerhalb des RFC 1918-Bereichs verwenden. Wenn Sie eine dieser anderen Gruppen von IP-Adressen verwenden, prüfen Sie, ob sich die IP-Adressen zwischen den für die Pods verwendeten Adressen und den Adressen in lokalen Netzwerken überschneiden. Wenn es eine Überschneidung gibt, achten Sie darauf, dass keine Kommunikation zwischen Clustern, die diese Adressen verwenden, und den lokalen Anwendungen, die diese Adressen verwenden, erfolgt.

Mit den folgenden Schritten können Sie dieses Architekturmuster einrichten:

  1. Erstellen Sie einen sekundären IP-Adressbereich für das Pod-Subnetz. Wie bereits in diesem Abschnitt beschrieben, können Sie diesen Adressbereich aus dem Bereich der Klasse E/RFC 5735, dem RFC 1918-Bereich oder einer internen Gruppe von IP-Adressen außerhalb des RFC 1918-Bereichs erstellen. In der Regel wird der Bereich der Klasse E/RFC 5735 verwendet.
  2. Verwenden Sie benutzerdefinierte beworbene Routen und entfernen Sie den Pod-IP-Adressbereich aus den Advertisements auf Ihren Cloud Routern. Durch das Entfernen dieser Adressen sorgen Sie dafür, dass Pod-IP-Bereiche nicht über das Border Gateway Protocol (BGP) an Ihre lokalen Router gemeldet werden.
  3. Erstellen Sie Ihren GKE-Cluster mit dem sekundären IP-Adressbereich als CIDR (Classless Inter-Domain Routing) für den Pod. Sie können die unter Nutzung interner IP-Adressen in GKE reduzieren beschriebenen Strategien verwenden, um die IP-Adressnutzung zu reduzieren.

  4. Fügen Sie der Liste nonMasqueradeCIDRs im Masquerade-Agent die folgenden IP-Adressen hinzu:

    • Den IP-Adressbereich, den Sie für Pods verwendet haben.
    • Der für Knoten verwendete IP-Adressbereich.
    • Andere IP-Adressen, die nur in Google Cloud verwendet werden, z. B. die primären IP-Adressbereiche, die in Google Cloud verwendet werden.

    Geben Sie nicht die internen IP-Adressbereiche an, die in lokalen Umgebungen oder in anderen Cloud-Umgebungen verwendet werden. Wenn Sie Windows-Arbeitslasten in Google Cloud haben, lassen Sie sie in separaten Subnetzen und fügen Sie diese Bereiche auch nicht hinzu.

Wenn Sie die vorherigen Schritte zum Einrichten dieses Musters verwenden, konfigurieren Sie Ihre Cluster so, dass sie:

  • Als vollständig integriertes Netzwerkmodell in Google Cloud fungieren
  • Bei der Interaktion mit lokalen Netzwerken wie ein Netzwerkmodell im Inselmodus fungieren

Damit dieses alternative Muster das Netzwerkmodell im Inselmodus vollständig emuliert, müssen Sie die Liste nonMasqueradeCIDRs im Masquerade-Agent in eine Liste ändern, die nur die Knoten- und Pod-IP-Adressbereiche des Clusters enthält. Wenn Sie eine solche Liste erstellen, wird der Traffic außerhalb des Clusters immer für die Knoten-IP-Adresse maskiert, auch innerhalb von Google Cloud. Nach dieser Änderung können Sie jedoch keine Telemetriedaten auf Pod-Ebene im VPC-Netzwerk erheben.

Das folgende Diagramm zeigt eine Implementierung dieses Architekturmusters:

Netzwerkdiagramm, das das Implementieren des Ausblendens von IP-Adressen nur in lokalen Netzwerken zeigt.

Das obige Diagramm zeigt, wie Pod-IP-Adressen in externen Netzwerken ausgeblendet werden. Wie in diesem Diagramm dargestellt, können Pods in Google Cloud direkt miteinander kommunizieren, auch zwischen Clustern. Diese Pod-Kommunikation ähnelt dem GKE-Modell. Das Diagramm zeigt auch die Pods, die Adressen im Bereich der Klasse E/RFC 5735 verwenden.

Für Traffic, der außerhalb der Cluster gesendet wird, zeigt das Diagramm, wie SNAT (Source NAT) auf den Traffic angewendet wird, wenn er den Knoten verlässt. SNAT wird unabhängig davon verwendet, ob dieser Traffic über Cloud VPN an lokale Anwendungen oder über Cloud NAT an externe Anwendungen weitergeleitet wird.

Bei diesem Architekturmuster werden Pod-IP-Adressen für die Kommunikation innerhalb von Google Cloud verwendet. Der Traffic wird nur maskiert, wenn er an lokale Anwendungen oder andere Cloud-Umgebungen gerichtet ist. Sie können zwar keine direkte Verbindung von lokalen Anwendungen zu Pods herstellen, jedoch eine Verbindung zu Diensten, die über das interne Load-Balancing bereitgestellt werden.

Das Ausblenden von Pod-IP-Adressen in lokalen Netzwerken hat folgende Vorteile:

  • Sie können das vollständig integrierte Netzwerkmodell in Google Cloud weiterhin nutzen, wenn Sie z. B. Firewalls verwenden und Telemetriedaten basierend auf Pod-IP-Adressen erheben. Darüber hinaus können Sie zu Debugging-Zwecken in Google Cloud eine direkte Verbindung zu Pods herstellen.
  • Sie können weiterhin Multi-Cluster-Service-Meshes mit Pod-IP-Adressen in Google Cloud verwenden.

Das Ausblenden von Pod-IP-Adressen in externen Netzwerken hat jedoch folgende Nachteile:

  • Sie können Pod- oder Service-IP-Adressbereiche nicht für verschiedene Cluster in Google Cloud wiederverwenden.
  • Möglicherweise müssen Sie zwei verschiedene Gruppen von Firewallregeln verwalten: eine für Traffic zwischen lokalen Netzwerken und eine für den Traffic vollständig innerhalb von Google Cloud.
  • Sie können keine direkte Pod-zu-Pod-Kommunikation in Multi-Cluster-Service-Meshes haben, die sich sowohl über Google Cloud als auch über Ihre lokale Umgebung oder die Umgebung anderer Cloud-Dienstanbieter erstrecken. Wenn Sie beispielsweise Istio verwenden, muss die gesamte Kommunikation zwischen Istio-Gateways erfolgen.

Pod-IP-Adressen mithilfe von Private Service Connect ausblenden

Bei diesem Architekturmuster wird Private Service Connect verwendet, um Pod-IP-Adressen auszublenden. Verwenden Sie dieses Architekturmuster, wenn Sie folgende Anforderungen haben:

  • Sie müssen nur eine begrenzte Anzahl von Services aus Ihren GKE-Clustern verfügbar machen.
  • Ihre GKE-Cluster können unabhängig voneinander funktionieren und erfordern keine ausgehende Kommunikation mit vielen Anwendungen in Ihrem Unternehmensnetzwerk.

Private Service Connect bietet die Möglichkeit, Ihre Dienste zu veröffentlichen, die von anderen Netzwerken genutzt werden sollen. Sie können Ihre GKE-Services mithilfe eines internen Passthrough-Network-Load-Balancers und mit Dienstanhängen verfügbar machen und diese Dienste über einen Endpunkt aus anderen VPC-Netzwerken nutzen.

Mit den folgenden Schritten können Sie dieses Architekturmuster einrichten:

  1. Erstellen Sie in einem separaten VPC-Netzwerk einen GKE-Cluster. Das VPC-Netzwerk sollte nur diesen Cluster enthalten.
  2. Für jeden GKE-Service in Ihrem Cluster, der von anderen Clustern oder Anwendungen in einem anderen VPC-Netzwerk zugänglich sein muss, erstellen Sie einen internen Passthrough-Network-Load-Balancer mit Private Service Connect.

  3. (Optional) Wenn Ihr GKE-Cluster eine ausgehende Kommunikation zu einigen Anwendungen in Ihrem Unternehmensnetzwerk benötigt, können Sie diese Anwendungen bereitstellen, indem Sie Dienste über Private Service Connect veröffentlichen.

    Das folgende Diagramm zeigt eine Implementierung dieses Architekturmusters:

Netzwerkdiagramm, das das Implementieren des Ausblendens von IP-Adressen über Private Service Connect zeigt.

Das obige Diagramm zeigt, wie die Kommunikation innerhalb und zwischen Clustern im Private Service Connect-Modell einem isolierten Netzwerkmodell ähnelt. Die zulässige Kommunikation erfolgt jedoch über Private Service Connect-Endpunkte statt über öffentliche IP-Adressen. Wie in diesem Diagramm dargestellt, erhält jeder Cluster ein eigenes separates VPC-Netzwerk. Darüber hinaus kann jedes VPC-Netzwerk dieselbe IP-Adresse verwenden und jeder Cluster kann denselben IP-Adressbereich verwenden. Nur Pods innerhalb eines Clusters können direkt miteinander kommunizieren.

Für die Kommunikation von außerhalb des Clusters zeigt das Diagramm, wie eine externe Anwendung den Cluster über einen Private Service Connect-Endpunkt erreichen kann. Dieser Endpunkt stellt eine Verbindung zum Dienstanhang her, der vom Dienstersteller im Cluster-VPC-Netzwerk bereitgestellt wird. Die Kommunikation zwischen Clustern erfolgt auch über einen Private Service Connect-Endpunkt und den Dienstanhang eines Diensterstellers.

Die Verwendung von Private Service Connect zum Ausblenden von Pod-IP-Adressen bietet folgende Vorteile:

  • Sie müssen keine IP-Adressen planen, da der IP-Adressbereich des GKE-Clusters im Rest des Netzwerks ausgeblendet ist. Bei diesem Ansatz wird dem vorhandenen VPC-Netzwerk nur eine einzige IP-Adresse pro Dienst zur Verfügung gestellt.
  • Es ist einfacher, den Cluster zu sichern, da dieses Modell klar definiert, welche Dienste verfügbar gemacht werden, und nur diese verfügbar gemachten Dienste können vom Rest des VPC-Netzwerks erreicht werden.

Die Verwendung von Private Service Connect zum Ausblenden von Pod-IP-Adressen hat jedoch die folgenden Nachteile:

  • Pods innerhalb des Clusters können keine private Kommunikation außerhalb des Clusters einrichten. Pods können nur mit öffentlichen Diensten (wenn die Pods mit dem Internet verbunden sind) oder mit Google APIs (über privaten Google-Zugriff) kommunizieren. Wenn Dienste außerhalb des Clusters über Private Service Connect verfügbar sind, können Pods diese Dienste ebenfalls erreichen. Allerdings erstellen nicht alle internen Dienstanbieter Dienstanhänge. Daher kann Private Service Connect nur verwendet werden, wenn die Anzahl dieser Dienste auf die Anbieter beschränkt ist, die Anhänge bereitstellen.
  • Endpunkte können nur in der Region erreicht werden, in der sich der Dienst befindet. Außerdem können diese Endpunkte nur vom verbundenen VPC-Netzwerk aus erreicht werden, nicht von Peering-VPC-Netzwerken oder Netzwerken, die über Cloud VPN oder Cloud Interconnect verbunden sind.

Pod-IP-Adressen mithilfe von Cloud VPN ausblenden

Bei diesem Architekturmuster wird Cloud VPN verwendet, um eine Trennung zwischen den GKE-Clustern und dem Haupt-VPC-Netzwerk zu erstellen. Wenn Sie diese Trennung erstellen, funktioniert das resultierende Netzwerk ähnlich wie das Netzwerkmodell im Inselmodus. Wie das Modell im Inselmodus bietet dieses Muster den Vorteil, dass Pod- und Service-IP-Adressbereiche zwischen Clustern wiederverwendet werden. Die Wiederverwendung ist möglich, da für die Kommunikation mit Anwendungen außerhalb des Clusters SNAT verwendet wird. Die Knoten verwenden SNAT, um Pod-IP-Adressen ihrer eigenen Knoten-IP-Adresse zuzuordnen, bevor der Traffic den Knoten verlässt.

Mit den folgenden Schritten können Sie dieses Modell einrichten:

  1. Erstellen Sie in einem separaten VPC-Netzwerk einen GKE-Cluster. Das VPC-Netzwerk sollte nur diesen Cluster enthalten.

    Verwenden Sie für den Cluster den nicht verwendeten Teil Ihrer öffentlichen IP-Adresszuweisung, um zwei IP-Adressbereiche zu definieren: einen für Pods und einen für Services. Passen Sie die Größe dieser IP-Adressbereiche entsprechend den Anforderungen des größten GKE-Clusters an, den Sie verwenden möchten. Reservieren Sie jeden dieser Bereiche zur exklusiven Verwendung in GKE. Außerdem wiederverwenden Sie diese Bereiche für alle GKE-Cluster in Ihrer Organisation.

    Manchmal ist das Reservieren eines so großen IP-Adressbereichs nicht möglich. Ihre Organisation verwendet möglicherweise bereits den IP-Adressbereich des Pods oder der Services oder beide für andere Anwendungen. Wenn der IP-Adressbereich verwendet wird und nicht reserviert werden kann, achten Sie darauf, dass die Anwendungen, die diese IP-Adressen verwenden, nicht mit dem GKE-Cluster kommunizieren müssen.

  2. Konfigurieren Sie für den soeben erstellten Cluster die Liste nonMasqueradeCIDRs im Masquerade-Agent in einer Liste mit dem Knoten und den Pod-IP-Adressbereichen des Clusters. Diese Liste führt dazu, dass GKE immer Traffic maskiert, der den Cluster zur Knoten-IP-Adresse verlässt, auch innerhalb von Google Cloud.

  3. Verwenden Sie Cloud VPN, um das VPC-Netzwerk, das den GKE-Cluster enthält, mit dem vorhandenen Haupt-VPC-Netzwerk zu verbinden.

  4. Verwenden Sie benutzerdefinierte beworbene Routen, um zu verhindern, dass das VPC-Netzwerk des Clusters die IP-Adressbereiche für Pods und Services anbietet, die an Ihr Haupt-VPC-Netzwerk gerichtet sind.

  5. Wiederholen Sie die Schritte 1 bis 4 für die anderen GKE-Cluster, die Sie benötigen. Verwenden Sie für alle Cluster dieselben IP-Adressbereiche für Pods und Services. Verwenden Sie jedoch für jeden Knoten unterschiedliche IP-Adressen.

  6. Wenn Sie eine Verbindung zu lokalen Netzwerken über Cloud VPN oder Cloud Interconnect herstellen, verwenden Sie benutzerdefinierte beworbene Routen, um die Knoten-IP-Bereiche manuell anzubieten.

  7. Wenn Sie über VPC-Netzwerk-Peering andere Netzwerke mit Ihrem Haupt-VPC-Netzwerk verbunden haben, exportieren Sie benutzerdefinierte Routen für diese Peerings, um zu gewährleisten, dass die GKE-Clusterknoten die Peering-Netzwerke erreichen.

Das folgende Diagramm zeigt eine Implementierung der Verwendung von Cloud VPN zum Ausblenden von Pod-IP-Adressen:

Netzwerkdiagramm, das das Implementieren des Ausblendens von IP-Adressen mithilfe von Cloud VPN zeigt.

Das obige Diagramm zeigt, wie Pod-IP-Adressen mithilfe von Cloud VPN ausgeblendet werden. Dieser Ansatz ähnelt dem Netzwerkmodell im Inselmodus. Wie im Diagramm dargestellt, erhält jeder GKE-Cluster ein eigenes separates VPC-Netzwerk. Jedes Netzwerk hat einen eigenen Knoten-IP-Adressbereich, der aber denselben Pod-IP-Adressbereich verwendet. Cloud VPN-Tunnel verbinden diese VPC-Netzwerke miteinander und mit dem Unternehmensnetzwerk. Der Pod-IP-Adressbereich wird nicht von den VPC-Netzwerken angeboten, die Cluster enthalten.

Beachten Sie im Diagramm, dass nur Pods innerhalb eines Clusters direkt miteinander kommunizieren können. Der Knoten verwendet SNAT, um den Pod-IP-Adressbereich zu maskieren, wenn er außerhalb des Clusters mit einem anderen Cluster, dem Unternehmensnetzwerk oder einem verbundenen lokalen Netzwerk kommuniziert. Pods können nicht direkt von anderen Clustern oder dem Unternehmensnetzwerk erreicht werden. Nur Cluster-Services, die mit einem internen Load-Balancer verfügbar gemacht werden, können über die Cloud VPN-Verbindungen erreicht werden.

Das Verwenden von Cloud VPN zum Ausblenden von Pod-IP-Adressen hat die folgenden Vorteile:

  • Wie im Netzwerkmodell im Inselmodus beschrieben, können Sie Pod- und Service-IP-Adressbereiche zwischen Clustern wiederverwenden.
  • Firewalls benötigen möglicherweise weniger Konfiguration, da Pod-IP-Adressen nicht direkt vom Haupt-VPC-Netzwerk und von verbundenen Netzwerken erreichbar sind. Daher müssen Sie keine expliziten Firewallregeln konfigurieren, um die Kommunikation mit den Pods zu blockieren.

Die Verwendung von Cloud VPN zum Ausblenden von Pod-IP-Adressen hat jedoch die folgenden Nachteile:

  • Es bestehen dieselben Nachteile wie beim Netzwerkmodell im Inselmodus. Beispielsweise können Sie keine Firewallregeln auf Pod-Ebene festlegen. Außerdem können Sie im Haupt-VPC-Netzwerk oder im verbundenen Netzwerk keine Telemetriedaten auf Pod-Ebene erheben.
  • Im Vergleich zum Standard-GKE-Netzwerkmodell führt dieses Muster zu zusätzlichen Kosten, die aus den Kosten, die mit Cloud VPN-Tunneln verbunden sind, und aus Gebühren für die Datenübertragung resultieren.
  • Cloud VPN hat ein Bandbreitenlimit pro VPN-Tunnel. Wenn Sie dieses Bandbreitenlimit erreichen, können Sie mehrere Cloud VPN-Tunnel konfigurieren und Traffic mithilfe von Equal Cost Multipath (ECMP) verteilen. Die Ausführung dieser Aktionen erschwert jedoch die Einrichtung und Verwaltung Ihrer GKE-Implementierung.
  • Wenn Sie die Route Advertisements synchron halten müssen, wird die Clustererstellung komplexer. Wenn Sie neue GKE-Cluster erstellen, müssen Sie Cloud VPN-Tunnel einrichten und benutzerdefinierte beworbene Routen für diese Tunnel und für lokale Anwendungen erstellen.

Pod-IP-Adressen mithilfe intern verwendeter öffentlicher IP-Adressen und mit VPC-Netzwerk-Peering ausblenden

Wenn Ihre Organisation nicht verwendete öffentliche IP-Adressen hat, können Sie dieses Architekturmuster verwenden, das einem Netzwerkmodell im Inselmodus ähnelt, aber mit privater Verwendung dieses öffentlichen IP-Adressbereichs. Diese Architektur ähnelt dem Modell, das Cloud VPN verwendet, verwendet jedoch stattdessen VPC-Netzwerk-Peering, um die Trennung zwischen dem GKE-Cluster und dem Hauptnetzwerk zu erstellen.

Mit den folgenden Schritten können Sie dieses Architekturmuster einrichten:

  1. Erstellen Sie in einem separaten VPC-Netzwerk einen GKE-Cluster. Das VPC-Netzwerk sollte nur diesen Cluster enthalten.

    Verwenden Sie für den Cluster den nicht verwendeten Teil Ihrer öffentlichen IP-Adresszuweisung, um zwei IP-Adressbereiche zu definieren: einen für Pods und einen für Services. Passen Sie die Größe dieser IP-Adressbereiche entsprechend den Anforderungen des größten GKE-Clusters an, den Sie verwenden möchten. Reservieren Sie jeden dieser Bereiche zur exklusiven Verwendung in GKE. Außerdem wiederverwenden Sie diese Bereiche für alle GKE-Cluster in Ihrer Organisation.

    Statt Ihre öffentliche IP-Adresszuweisung zu verwenden, ist es theoretisch möglich, die größeren, nicht verwendeten öffentlichen IP-Adressblöcke von Drittanbietern zu verwenden. Wir empfehlen jedoch dringend, eine solche Konfiguration nicht vorzunehmen, da diese IP-Adressen jederzeit verkauft oder öffentlich verwendet werden können. Der Verkauf oder die Verwendung von Adressen hat bei der Verwendung öffentlicher Dienste im Internet zu Sicherheits- und Verbindungsproblemen geführt.

  2. Konfigurieren Sie für den soeben erstellten Cluster die Liste nonMasqueradeCIDRs im Masquerade-Agent in einer Liste mit dem Knoten und den Pod-IP-Adressbereichen des Clusters. Diese Liste führt dazu, dass GKE immer Traffic maskiert, der den Cluster zur Knoten-IP-Adresse verlässt, auch innerhalb von Google Cloud.

  3. Verwenden Sie VPC-Netzwerk-Peering, um das VPC-Netzwerk, das den GKE-Cluster enthält, mit dem vorhandenen Haupt-VPC-Netzwerk zu verbinden. Da in diesem Modell keine PUPI-Adressen ausgetauscht werden sollen, geben Sie beim Konfigurieren des Peerings das Flag --no-export-subnet-routes-with-public-ip an.

  4. Wiederholen Sie die Schritte 1 bis 3 für die anderen GKE-Cluster, die Sie benötigen. Verwenden Sie für alle Cluster denselben IP-Adressbereich für Pod und Services. Verwenden Sie jedoch für jeden Knoten eine eigene IP-Adresse.

  5. Wenn Sie eine Verbindung zu lokalen Netzwerken über Cloud VPN oder Cloud Interconnect herstellen, verwenden Sie benutzerdefiniertes Route Advertisement, um die IP-Adressbereiche des Knotens manuell anzubieten.

Das folgende Diagramm zeigt eine Implementierung dieses Architekturmusters:

Netzwerkdiagramm, das das Implementieren des Ausblendens von IP-Adressen über PUPI und VPC-Netzwerk-Peering zeigt.

Das obige Diagramm zeigt, wie IP-Adressen mithilfe von VPC-Netzwerk-Peering ausgeblendet werden. Wie im Diagramm dargestellt, erhält jeder GKE-Cluster ein eigenes separates VPC-Netzwerk. Jeder Knoten hat einen eigenen IP-Adressbereich für den Knoten, verwendet jedoch denselben Pod-IP-Adressbereich, der über den PUPI-Adressbereich Ihrer Organisation definiert wurde. Die VPC-Netzwerke sind über VPC-Netzwerk-Peering miteinander und mit Nicht-Kubernetes-Anwendungen in Google Cloud verbunden. Der PUPI-Adressbereich wird zwischen den Peerings nicht angeboten. Die VPC-Netzwerke stellen über Cloud VPN-Tunnel eine Verbindung zum Unternehmensnetzwerk her.

Nur Pods innerhalb eines Clusters können direkt miteinander kommunizieren. Der Knoten verwendet SNAT, um den Pod-IP-Bereich zu maskieren, wenn er außerhalb des Clusters mit einem anderen Cluster, dem Unternehmensnetzwerk oder einem verbundenen lokalen Netzwerk kommuniziert. Pods können nicht direkt von anderen Clustern oder dem Unternehmensnetzwerk erreicht werden. Nur Services, die mit einem internen Load-Balancer verfügbar gemacht werden, können über VPC-Netzwerk-Peering-Verbindungen erreicht werden.

Dieses Architekturmuster ähnelt dem zuvor beschriebenen Cloud VPN-Ansatz, hat jedoch folgende Vorteile gegenüber diesem Muster:

  • Im Unterschied zum Cloud VPN-Architekturmuster fallen beim VPC-Netzwerk-Peering keine zusätzlichen Kosten für Cloud VPN-Tunnel oder Bandbreite zwischen Umgebungen an.
  • Für das VPC-Netzwerk-Peering gelten keine Bandbreitenbeschränkungen. Es ist vollständig in die softwarebasierten Netzwerke von Google eingebunden. Daher bietet VPC-Netzwerk-Peering möglicherweise eine geringere Latenz als Cloud VPN, da für das Peering nicht die von Cloud VPN benötigten Gateways und Verarbeitungsprozesse erforderlich sind.

Das VPC-Netzwerk-Peering-Modell hat jedoch auch die folgenden Nachteile gegenüber dem Cloud VPN-Modell:

  • Ihre Organisation benötigt einen öffentlichen IP-Adressbereich, der nicht verwendet wird und der groß genug für den Pod-IP-Adressbereich ist, der vom größten GKE-Cluster benötigt wird, den Sie erwarten.
  • Das VPC-Netzwerk-Peering ist nicht transitiv. Daher können GKE-Cluster, die über VPC-Netzwerk-Peering mit dem Haupt-VPC-Netzwerk verbunden sind, nicht direkt miteinander oder mit Anwendungen in VPC-Netzwerken kommunizieren, die über Peering mit der Haupt-VPC verbunden sind. Sie müssen diese Netzwerke direkt über VPC-Netzwerk-Peering verbinden, um eine solche Kommunikation zu ermöglichen, oder eine Proxy-VM im Haupt-VPC-Netzwerk verwenden.

Clusteradressen über Multi-NIC-Instanzen ausblenden

Dieses Architekturmuster beinhaltet die folgenden Komponenten und Technologien, um ein Modell zu erstellen, das einem Netzwerkmodell im Inselmodus ähnelt:

  • Es verwendet Compute Engine-Instanzen mit mehreren Netzwerkschnittstellenkarten (NICs), um eine Trennschicht zwischen GKE-Clustern und dem Haupt-VPC-Netzwerk zu erstellen.
  • Dabei wird NAT für IP-Adressen verwendet, die zwischen diesen Umgebungen gesendet werden.

Sie können dieses Muster verwenden, wenn Sie bestimmten Traffic prüfen, transformieren oder filtern möchten, der die GKE-Cluster erreicht oder verlässt. Wenn Sie diese Art von Prüf-, Transformations- oder Filtervorgängen ausführen müssen, verwenden Sie dafür die bereitgestellten Compute Engine-Instanzen.

Das Verwenden von Instanzen mit mehreren NICs zum Ausblenden von Clusteradressen hat folgende Vorteile:

  • Der IP-Adressbereich des GKE-Clusters ist im Rest des Netzwerks ausgeblendet. Nur eine einzige IP-Adresse pro Dienst wird dem nutzenden VPC-Netzwerk zur Verfügung gestellt.
  • Dienste können global, aus verbundenen lokalen Netzwerken und aus Peering-Netzwerken erreicht werden.

Die Verwendung von Instanzen mit mehreren NICs zum Ausblenden von Clusteradressen hat jedoch folgende Nachteile:

  • Die Implementierung dieses Modells ist komplexer als andere Ansätze, da sie nicht nur die Implementierung des Modells, sondern auch die Einrichtung des Monitorings und des Loggings für die Instanzen mit mehreren NICs erfordert.
  • Für die Instanzen mit mehreren NICs gelten Bandbreitenbeschränkungen und die Preise für VM-Instanzen.
  • Sie müssen die Instanzen mit mehreren NICs verwalten und aktualisieren.

Nächste Schritte