In diesem Dokument wird das Netzwerkmodell beschrieben, das von Google Kubernetes Engine (GKE) verwendet wird, und es wird erläutert, wie es sich von Netzwerkmodellen in anderen Kubernetes-Umgebungen unterscheiden kann. In diesem Dokument werden die folgenden Konzepte behandelt:
- Die gängigsten Netzwerkmodelle, die in verschiedenen Kubernetes-Implementierungen verwendet werden
- Die Mechanismen zur IP-Adressierung der gängigsten Netzwerkmodelle
- Die Vor- und Nachteile jedes Netzwerkmodells
- Eine detaillierte Beschreibung des von GKE verwendeten Standard-Netzwerkmodells
Das Dokument richtet sich an Cloud-Architekten, Betriebstechniker und Netzwerktechniker, die möglicherweise mit anderen Kubernetes-Implementierungen vertraut sind und GKE verwenden möchten. In diesem Dokument wird davon ausgegangen, dass Sie mit Kubernetes und dem grundlegenden Netzwerkmodell vertraut sind. Außerdem sollten Sie mit Netzwerkkonzepten wie IP-Adressierung, Network Address Translation (NAT), Firewalls und Proxys vertraut sein.
In diesem Dokument wird nicht behandelt, wie Sie das Standard-GKE-Netzwerkmodell ändern, um verschiedene Einschränkungen für IP-Adressen zu berücksichtigen. Wenn bei der Migration zu GKE nicht genug IP-Adressen verfügbar sind, finden Sie weitere Informationen unter Strategien für die IP-Adressverwaltung bei der Migration zu GKE.
Typische Implementierungen von Netzwerkmodellen
Sie können das Kubernetes-Netzwerkmodell auf verschiedene Arten implementieren. Jede Implementierung muss jedoch immer die folgenden Anforderungen erfüllen:
- Jeder Pod benötigt eine eindeutige IP-Adresse.
- Pods können auf allen Knoten ohne NAT mit anderen Pods kommunizieren.
- Agents auf einem Knoten, wie
kubelet, können mit allen Pods auf diesem Knoten kommunizieren. - Pods im Hostnetzwerk eines Knotens können ohne Verwendung von NAT mit allen Pods auf allen Knoten kommunizieren.
Es wurden mehr als 20 verschiedene Implementierungen für das Kubernetes-Netzwerkmodell entwickelt, die diese Anforderungen erfüllen.
Diese Implementierung kann in drei Arten von Netzwerkmodellen gruppiert werden. Diese drei Modelle unterscheiden sich in folgender Hinsicht:
- Wie Pods mit Nicht-Kubernetes-Diensten im Unternehmensnetzwerk kommunizieren können
- Wie Pods mit anderen Kubernetes-Clustern in derselben Organisation kommunizieren können
- Ob NAT für die Kommunikation außerhalb des Clusters erforderlich ist
- Ob Pod-IP-Adressen in anderen Clustern oder an anderer Stelle im Unternehmensnetzwerk wiederverwendet werden können
Jeder Cloud-Anbieter hat mindestens einen dieser Modelltypen implementiert.
In der folgenden Tabelle ist aufgeführt, welche drei Modelltypen am häufigsten verwendet werden und in welcher Kubernetes-Implementierung sie verwendet werden:
| Netzwerkmodellname | Wird in diesen Implementierungen verwendet |
|---|---|
| Vollständig integriert oder flach |
|
| Inselmodus oder mit Bridge |
|
| Isoliert oder mit Air Gap |
|
Wenn in diesem Dokument die Netzmodelle beschrieben werden, geht es um die Auswirkungen auf verbundene lokale Netzwerke. Sie können jedoch die für verbundene lokale Netzwerke beschriebenen Konzepte auf Netzwerke anwenden, die über ein virtuelles privates Netzwerk (VPN) oder über eine private Interconnect-Verbindung, einschließlich Verbindungen zu anderen Cloud-Anbietern, verbunden sind. Bei GKE umfassen diese Verbindungen die Kopnnektivitäten über Cloud VPN oder Cloud Interconnect.
Vollständig integriertes Netzwerkmodell
Das vollständig integrierte Netzwerkmodell (flaches Modell) bietet eine einfache Kommunikation mit Anwendungen außerhalb von Kubernetes und in anderen Kubernetes-Clustern. Große Cloud-Dienstanbieter implementieren dieses Modell häufig, da sie ihre Kubernetes-Implementierung eng in ihr softwarebasiertes Netzwerk (SDN) einbinden können.
Wenn Sie das vollständig integrierte Modell verwenden, werden die IP-Adressen, die Sie für Pods verwenden, in dem Netzwerk weitergeleitet, in dem sich der Kubernetes-Cluster befindet. Das zugrunde liegende Netzwerk weiß außerdem, auf welchem Knoten sich die Pod-IP-Adressen befinden. In vielen Implementierungen stammen die Pod-IP-Adressen auf demselben Knoten aus einem bestimmten, vorab zugewiesenen Pod-IP-Adressbereich. Dieser vorab zugewiesene Adressbereich ist jedoch nicht erforderlich.
Das folgende Diagramm zeigt Pod-Kommunikationsoptionen im vollständig integrierten Netzwerkmodell:
Das obige Diagramm eines vollständig integrierten Netzwerkmodells zeigt die folgenden Kommunikationsmuster:
- Pods innerhalb eines Kubernetes-Clusters können direkt miteinander kommunizieren.
- Pods können mit anderen Pods in anderen Clustern kommunizieren, solange sich diese Cluster im selben Netzwerk befinden.
- Pods benötigen kein NAT, um mit anderen Anwendungen außerhalb des Clusters zu kommunizieren, unabhängig davon, ob sich diese Anwendungen im selben Netzwerk oder verbundenen Netzwerken befinden.
Das Diagramm zeigt auch, dass Pod-IP-Adressbereiche zwischen verschiedenen Clustern unterschiedlich sind.
Das vollständig integrierte Netzwerkmodell ist in folgenden Implementierungen verfügbar:
- GKE implementiert dieses Modell standardmäßig. Weitere Informationen zu dieser Implementierung finden Sie unter GKE-Netzwerkmodell weiter unten in diesem Dokument.
- Standardmäßig implementiert Amazon EKS dieses Modell. In dieser Implementierung verwendet Amazon EKS das Plug-in für das Amazon VPC Container Networking Interface (CNI) für Kubernetes, um Pod-IP-Adressen direkt aus dem VPC-Adressbereich zuzuweisen. Das CNI-Plug-in weist IP-Adressen entweder aus dem Standardsubnetz zu, in dem sich die Knoten befinden, oder aus einem benutzerdefinierten Subnetz. Pod-IP-Adressen stammen nicht aus einem dedizierten Pod-IP-Adressbereich pro Knoten.
- In Azure implementiert AKS dieses Modell bei der Verwendung von Azure CNI (erweitertes Netzwerk). Diese Implementierung ist nicht die Standardkonfiguration. In dieser Implementierung erhält jeder Pod eine IP-Adresse aus dem Subnetz. Sie können auch die maximale Anzahl von Pods pro Knoten konfigurieren. Daher entspricht die Anzahl der im Voraus reservierten IP-Adressen für Pods auf diesem Knoten der maximalen Anzahl von Pods pro Knoten.
Die Verwendung eines vollständig integrierten Netzwerkmodells bietet folgende Vorteile:
- Bessere Telemetriedaten: Pod-IP-Adressen sind im gesamten Netzwerk sichtbar. Durch diese Sichtbarkeit sind Telemetriedaten nützlicher als in anderen Modellen, da Pods auch über Telemetriedaten identifiziert werden können, die außerhalb des Clusters erhoben werden.
- Einfachere Firewallkonfiguration: Beim Festlegen von Firewallregeln ist es im vollständig integrierten Netzwerkmodell einfacher als bei den anderen Modellen, Knoten- und Pod-Traffic zu unterscheiden.
- Bessere Kompatibilität: Pods können über Protokolle kommunizieren, die NAT nicht unterstützen.
- Besseres Debugging: Wenn es von der Firewall zugelassen wird, können Ressourcen außerhalb des Clusters Pods während des Debugging-Prozesses direkt erreichen.
- Kompatibilität mit Service Meshes: Service Meshes wie Istio oder Anthos Service Mesh können problemlos über Cluster hinweg kommunizieren, da Pods direkt miteinander kommunizieren können. Einige Service-Mesh-Implementierungen unterstützen nur Pod-zu-Pod-Verbindungen für Multi-Cluster-Service-Meshes.
Die Verwendung eines vollständig integrierten Netzwerkmodells hat folgende Nachteile:
- IP-Adressnutzung: Sie können innerhalb des Netzwerks keine Pod-IP-Adressen verwenden und jede IP-Adresse muss eindeutig sein. Diese Anforderungen können zu einer großen Anzahl von IP-Adressen führen, die für Pods reserviert werden müssen.
- SDN-Anforderungen: Ein vollständig integriertes Netzwerkmodell erfordert eine tiefe Integration in das liegenden Netzwerk, da die Kubernetes-Implementierung das SDN direkt programmieren muss. Die Programmierung des SDN ist für den Nutzer transparent und erzeugt keine für den Nutzer spürbaren Nachteile. Solche tief integrierten Netzwerkmodelle können jedoch nicht so einfach in selbstverwalteten, lokalen Umgebungen implementiert werden.
Netzwerkmodell im Inselmodus
Das Netzwerkmodell im Inselmodus (oder Bridge) wird häufig für lokale Kubernetes-Implementierungen verwendet, bei denen keine tiefe Integration in das zugrunde liegende Netzwerk möglich ist. Wenn Sie ein Netzwerkmodell im Inselmodus verwenden, können Pods in einem Kubernetes-Cluster über eine Art von Gateway oder Proxy mit Ressourcen außerhalb des Clusters kommunizieren.
Das folgende Diagramm zeigt Pod-Kommunikationsoptionen in einem Netzwerkmodell im Inselmodus:
Das vorherige Diagramm eines Netzwerkmodells im Inselmodus zeigt, wie Pods in einem Kubernetes-Cluster direkt miteinander kommunizieren können. Das Diagramm zeigt auch, dass Pods in einem Cluster ein Gateway oder einen Proxy verwenden müssen, wenn sie mit Anwendungen außerhalb des Clusters oder mit Pods in anderen Clustern kommunizieren. Die Kommunikation zwischen einem Cluster und einer externen Anwendung erfordert zwar ein einzelnes Gateway, während für die Cluster-zu-Cluster-Kommunikation zwei Gateways erforderlich sind. Der Traffic zwischen zwei Clustern wird über ein Gateway geleitet, wenn der erste Cluster verlassen wird, und über ein weiteres Gateway, wenn er in den anderen Cluster gelangt.
Es gibt verschiedene Möglichkeiten, die Gateways oder Proxys in einem isolierten Netzwerkmodell zu implementieren. Die folgenden Implementierungen sind die beiden häufigsten Gateways oder Proxys:
Knoten als Gateways verwenden: Diese Implementierung wird häufig verwendet, wenn Knoten im Cluster Teil des vorhandenen Netzwerks sind und ihre IP-Adressen innerhalb dieses Netzwerks nativ routingfähig sind. In diesem Fall sind die Knoten selbst die Gateways, die eine Verbindung von innerhalb des Clusters zum größeren Netzwerk ermöglichen. Ausgehender Traffic von einem Pod aus dem Cluster heraus kann entweder zu anderen Clustern oder zu Nicht-Kubernetes-Anwendungen weitergeleitet werden, z. B. zum Aufrufen einer lokalen API im Unternehmensnetzwerk. Für diesen ausgehenden Traffic verwendet der Knoten, der den Pod enthält, die SNAT (Source NAT), um die IP-Adresse des Pods der Knoten-IP-Adresse zuzuordnen. Damit Anwendungen außerhalb des Clusters mit Services im Cluster kommunizieren können, können Sie für die meisten Implementierungen den Diensttyp NodePort verwenden. In einigen Implementierungen können Sie den Diensttyp LoadBalancer verwenden, um Services verfügbar zu machen. Wenn Sie den LoadBalancer-Diensttyp verwenden, weisen Sie diesen Services eine virtuelle IP-Adresse zu, für die ein Load-Balancing zwischen Knoten erfolgt und die an einen Pod weitergeleitet wird, der Teil des Service ist.
Das folgende Diagramm zeigt das Implementierungsmuster bei Verwendung von Knoten als Gateways:
Das obige Diagramm zeigt, dass die Verwendung von Knoten als Gateways keine Auswirkungen auf die Pod-zu-Pod-Kommunikation innerhalb eines Clusters hat. Pods in einem Cluster kommunizieren weiterhin direkt miteinander. Das Diagramm zeigt jedoch auch die folgenden Kommunikationsmuster außerhalb des Clusters:
- Wie Pods mit anderen Clustern oder Nicht-Kubernetes-Anwendungen kommunizieren, indem sie beim Verlassen des Knotens SNAT verwenden
- Wie Traffic von externen Services in anderen Clustern oder Nicht-Kubernetes-Anwendungen über einen NodePort-Dienst in den Cluster gelangt, bevor er an den richtigen Pod im Cluster weitergeleitet wird
Proxy-VMs mit mehreren Netzwerkschnittstellen verwenden: Bei diesem Implementierungsmuster wird über Proxys auf das Netzwerk zugegriffen, das den Kubernetes-Cluster enthält. Die Proxys müssen Zugriff auf den Pod- und Knoten-IP-Adressbereich haben. Bei diesem Muster hat jede Proxy-VM zwei Netzwerkschnittstellen: eine Schnittstelle im größeren Unternehmensnetzwerk und eine Schnittstelle im Netzwerk, das den Kubernetes-Cluster enthält.
Das folgende Diagramm zeigt das Implementierungsmuster bei Verwendung von Proxy-VMs:
Das obige Diagramm zeigt, dass die Verwendung von Proxys im Inselmodus keine Auswirkungen auf die Kommunikation innerhalb eines Clusters hat. Pods in einem Cluster können weiterhin direkt miteinander kommunizieren. Das Diagramm zeigt jedoch auch, wie die Kommunikation von Pods mit anderen Clustern oder Nicht-Kubernetes-Anwendungen über einen Proxy geleitet wird, der sowohl auf das Netzwerk des Clusters als auch auf das Zielnetzwerk zugreifen kann. Darüber hinaus wird die Kommunikation von außerhalb des Clusters über dieselbe Art von Proxy geleitet.
Das Netzwerkmodell im Inselmodus ist in den folgenden Implementierungen verfügbar:
- Azure Kubernetes Service (AKS) verwendet standardmäßig ein Netzwerk im Inselmodus, wenn Sie das Kubenet-Netzwerk (einfach) nutzen. Wenn AKS ein Netzwerk im Inselmodus verwendet, umfasst das virtuelle Netzwerk, das den Cluster enthält, nur Knoten-IP-Adressen. Pod-IP-Adressen sind nicht Teil des virtuellen Netzwerks. Stattdessen erhalten Pods IP-Adressen aus einem anderen logischen Bereich. Das von AKS verwendete Inselmodus-Modell leitet auch Pod-zu-Pod-Traffic zwischen Knoten über benutzerdefinierte Routen, wobei für die Knotenschnittstelle IP-Weiterleitung aktiviert ist. Für die Pod-Kommunikation mit Ressourcen außerhalb des Clusters verwendet der Knoten SNAT, um die Pod-IP-Adresse der Knoten-IP-Adresse zuzuordnen, bevor der ausgehende Traffic den Knoten verlässt.
- In Oracle Container Engine für Kubernetes (OKE) verwendet die Pod-zu-Pod-Kommunikation ein VXLAN-Overlay-Netzwerk. Außerdem verwendet der Traffic von Pods zu Anwendungen außerhalb des Clusters SNAT, um die Pod-IP-Adresse der Knoten-IP-Adresse zuzuordnen.
Die Verwendung eines Netzwerkmodells im Inselmodus bietet folgende Vorteile:
- IP-Adressnutzung: Pod-IP-Adressen im Cluster können in anderen Clustern wiederverwendet werden. IP-Adressen, die bereits von externen Diensten im Unternehmensnetzwerk verwendet werden, können jedoch nicht für Pods verwendet werden, wenn die Kommunikation zwischen den Pods und diesen Diensten erfolgen muss. Daher besteht die Best Practice für Netzwerke im Inselmodus darin, einen Pod-IP-Adressbereich zu reservieren, der innerhalb des Netzwerks eindeutig ist, und diesen IP-Adressbereich für alle Cluster zu verwenden.
- Einfachere Sicherheitseinstellungen: Da Pods nicht direkt für den Rest des Unternehmensnetzwerks verfügbar sind, müssen Sie die Pods nicht vor eingehendem Traffic vom Rest des Unternehmensnetzwerks schützen.
Die Verwendung eines Netzwerkmodells im Inselmodus hat die folgenden Nachteile:
- Ungenaue Telemetrie: Außerhalb des Clusters erhobene Telemetriedaten enthalten nur die Knoten-IP-Adresse, nicht die Pod-IP-Adresse. Das Fehlen von Pod-IP-Adressen erschwert die Identifizierung der Quelle und des Ziels des Traffics.
- Schwierigeres Debugging: Beim Debugging können Sie keine direkte Verbindung zu Pods von außerhalb des Clusters herstellen.
- Schwieriger zu konfigurierende Firewalls: Sie können Knoten-IP-Adressen nur verwenden, wenn Sie Ihre Firewall konfigurieren. Daher können die resultierenden Firewalleinstellungen entweder allen Pods auf einem Knoten, dem Knoten selbst oder weder den Pods noch dem Knoten erlauben, externe Dienste zu erreichen.
Kompatibilität mit Service Meshes: Im Inselmodus ist eine direkte Pod-zu-Pod-Kommunikation zwischen Clustern in Service Meshes, wie Istio oder Anthos Service Mesh, nicht möglich.
Bei einigen Service-Mesh-Implementierungen gibt es weitere Einschränkungen. Die Anthos Service Mesh-Multi-Cluster-Unterstützung für GKE-Cluster in Google Cloud unterstützt nur Cluster im selben Netzwerk. Bei Istio-Implementierungen, die ein Modell mit mehreren Netzwerken unterstützen, muss die Kommunikation über Istio-Gateways erfolgen. Dadurch werden Multi-Cluster-Service-Mesh-Bereitstellungen komplexer.
Isoliertes Netzwerkmodell
Das isolierte Netzwerkmodell (Modell mit Air Gap) wird häufig für Cluster verwendet, die nur über öffentliche APIs auf das größere Unternehmensnetzwerk zugreifen müssen. Wenn Sie ein isoliertes Netzwerkmodell verwenden, ist jeder Kubernetes-Cluster isoliert und kann keine internen IP-Adressen für die Kommunikation mit dem Rest des Netzwerks verwenden. Der Cluster befindet sich in einem eigenen privaten Netzwerk. Wenn ein Pod im Cluster mit Diensten außerhalb des Clusters kommunizieren muss, muss diese Kommunikation sowohl für eingehenden als auch für ausgehenden Traffic öffentliche IP-Adressen verwenden.
Das folgende Diagramm zeigt Pod-Kommunikationsoptionen in einem isolierten Netzwerkmodell:
Das obige Diagramm eines isolierten Netzwerkmodells zeigt, dass Pods innerhalb eines Kubernetes-Clusters direkt miteinander kommunizieren können. Das Diagramm zeigt auch, dass Pods keine internen IP-Adressen für die Kommunikation mit Pods in anderen Clustern verwenden können. Darüber hinaus können Pods nur mit Anwendungen außerhalb des Clusters kommunizieren, wenn die folgenden Kriterien erfüllt sind:
- Es gibt ein Internetgateway, das den Cluster mit der Außenwelt verbindet.
- Die externe Anwendung verwendet für die Kommunikation eine externe IP-Adresse.
Schließlich zeigt das Diagramm, wie derselbe IP-Adressbereich für Pods und Knoten von verschiedenen Umgebungen wiederverwendet werden kann.
Das isolierte Netzwerkmodell wird von Kubernetes-Implementierungen nicht oft verwendet. Sie können jedoch bei jeder Implementierung ein isoliertes Netzwerkmodell erreichen. Sie müssen lediglich einen Kubernetes-Cluster in einem separaten Netzwerk oder einer VPC bereitstellen, ohne eine Verbindung zu anderen Diensten oder zum Unternehmensnetzwerk zu ermöglichen. Die resultierende Implementierung hat die gleichen Vor- und Nachteile wie das isolierte Netzwerkmodell.
Die Verwendung eines isolierten Netzwerkmodus bietet folgende Vorteile:
- IP-Adressnutzung: Sie können alle internen IP-Adressen im Cluster wiederverwenden: Knoten-IP-Adressen, Services-IP-Adressen und Pod-IP-Adressen. Die Wiederverwendung interner IP-Adressen ist möglich, da jeder Cluster ein eigenes privates Netzwerk hat und die Kommunikation mit Ressourcen außerhalb des Clusters nur über öffentliche IP-Adressen erfolgt.
- Kontrolle: Die Clusteradministratoren haben die volle Kontrolle über die IP-Adressierung im Cluster und müssen keine Aufgaben zur IP-Adressverwaltung ausführen. Beispielsweise können Administratoren Pods und Services im Cluster den gesamten
10.0.0.0/8-Adressbereich zuweisen, selbst wenn diese Adressen bereits in der Organisation verwendet werden. - Sicherheit: Die Kommunikation außerhalb des Clusters wird streng kontrolliert und verwendet, wenn sie erlaubt wird, klar definierte externe Schnittstellen und NAT.
Die Verwendung eines isolierten Netzwerkmodells hat die folgenden Nachteile:
- Keine private Kommunikation: Die Kommunikation mit internen IP-Adressen ist für andere Cluster oder andere Dienste im Netzwerk nicht zulässig.
GKE-Netzwerkmodell
GKE verwendet ein vollständig integriertes Netzwerkmodell, bei dem Cluster in einem VPC-Netzwerk (Virtual Private Cloud) bereitgestellt werden, das auch andere Anwendungen enthalten kann.
Wir empfehlen die Verwendung eines VPC-nativen Clusters für Ihre GKE-Umgebung. Sie können Ihren nativen VPC-Cluster entweder in Standard oder Autopilot erstellen. Wenn Sie den Autopilot-Modus wählen, ist der VPC-native Modus immer aktiviert und kann nicht deaktiviert werden. In den folgenden Abschnitten wird das GKE-Netzwerkmodell im Standardmodus beschrieben. Außerdem werden Hinweise dazu gegeben, wie sich Autopilot davon unterscheidet.
IP-Adressverwaltung in VPC-nativen Clustern
Wenn Sie einen VPC-nativen Cluster verwenden, sind Pod-IP-Adressen für jeden Knoten sekundäre IP-Adressen. Jedem Knoten wird ein bestimmtes Subnetz eines Pod-IP-Adressbereichs zugewiesen, das Sie beim Erstellen des Clusters aus Ihrem internen IP-Adressbereich auswählen. Standardmäßig weist ein VPC-nativer Cluster jedem Knoten ein /24-Subnetz zur Verwendung als Pod-IP-Adressen zu. Ein /24-Subnetz entspricht 256 IP-Adressen. Im Autopilot verwendet der Cluster ein /26-Subnetz, das 64 Adressen entspricht. Sie können diese Subnetzeinstellung nicht ändern.
Das GKE-Netzwerkmodell lässt nicht zu, dass IP-Adressen im gesamten Netzwerk wiederverwendet werden. Wenn Sie zu GKE migrieren, müssen Sie die Zuweisung von IP-Adressen planen, um die Nutzung interner IP-Adressen in GKE zu reduzieren.
Da Pod-IP-Adressen innerhalb des VPC-Netzwerks routingfähig sind, können Pods standardmäßig Traffic von den folgenden Ressourcen empfangen:
- Von anderen Diensten im VPC-Netzwerk
- Aus VPC-Netzwerken, die über VPC-Netzwerk-Peering verbunden sind
- Aus verbundenen lokalen Netzwerken über Cloud VPN oder Cloud Interconnect
Externe Traffickommunikation mit dem IP-Masquerade-Agent verwalten
Wenn Sie von Pods mit Diensten außerhalb des Clusters kommunizieren, steuert der IP-Masquerade-Agent, wie der Traffic bei diesen Diensten angezeigt wird. Der IP-Masquerade-Agent verarbeitet private und externe IP-Adressen anders:
- Standardmäßig maskiert der IP-Masquerade-Agent keinen Traffic an interne IP-Adressen, einschließlich RFC 1918-IP-Adressen, und an IP-Adressen außerhalb des RFC 1918-Bereichs, die häufig intern verwendet werden. Weitere Informationen finden Sie in der Liste der Standardziele ohne Maskierung. Da die internen IP-Adressen nicht maskiert werden, verwendet der Knoten für diese Adressen kein NAT.
- Bei externen IP-Adressen maskiert der IP-Masquerade-Agent diese Adressen für die Knoten-IP-Adresse. Daher werden diese maskierten Adressen von Cloud NAT in eine externe IP-Adresse übersetzt oder sie werden in die externe IP-Adresse der VM-Instanz übersetzt.
Sie können in Ihrem VPC-Netzwerk oder in verbundenen Netzwerken auch privat verwendete öffentliche IP-Adressen (PUPI) verwenden. Auch bei der Verwendung von PUPI-Adressen können Sie vom vollständig integrierten Netzwerkmodell profitieren und die Pod-IP-Adresse direkt als Quelle sehen. Um beide diese Ziele zu erreichen, müssen Sie die PUPI-Adressen in die Liste nonMasqueradeCIDRs aufnehmen.
Pod-Trafficfluss in einem GKE-Netzwerk
Das folgende Diagramm zeigt, wie Pods im GKE-Netzwerkmodell kommunizieren können:
Das obige Diagramm zeigt, wie Pods in GKE-Umgebungen interne IP-Adressen für die direkte Kommunikation mit den folgenden Ressourcen verwenden können:
- Andere Pods im selben Cluster
- Pods in anderen GKE-Clustern im selben VPC-Netzwerk
- Andere Google Cloud-Anwendungen im selben VPC-Netzwerk
- Lokale Anwendungen, die über Cloud VPN verbunden sind
Das Diagramm zeigt auch, was geschieht, wenn ein Pod eine externe IP-Adresse für die Kommunikation mit einer Anwendung verwenden muss. Wenn der Traffic den Knoten verlässt, verwendet der Knoten, in dem sich der Pod befindet, SNAT, um die IP-Adresse des Pods der IP-Adresse des Knotens zuzuordnen. Nachdem der Traffic den Knoten verlassen hat, übersetzt Cloud NAT die IP-Adresse des Knotens in eine externe IP-Adresse.
Für die in diesem Dokument bisher beschriebenen Vorteile, insbesondere für den Vorteil der Sichtbarkeit von Pod-IP-Adressen in allen Telemetriedaten, hat Google ein vollständig integriertes Netzwerkmodell gewählt. In GKE werden Pod-IP-Adressen in VPC-Flusslogs (einschließlich Pod-Namen in Metadaten), in der Paketspiegelung, im Firewallregel-Logging und in Ihren eigenen Anwendungslogs für Ziele ohne Maskierung sichtbar gemacht.
Nächste Schritte
- Weitere Informationen zu Strategien für die IP-Adressverwaltung bei der Migration zu GKE
- Best Practices für GKE-Netzwerke
- AWS- und Azure-Dienste mit Google Cloud vergleichen
- Container zu Google Cloud migrieren: Von Kubernetes zu GKE migrieren