In diesem Dokument wird beschrieben, wie Sie die Verbindung von Pods in GKE zu externen Endpunkten konfigurieren, einschließlich Ressourcen in lokalen Netzwerken und öffentlichen Internetdiensten. Wenn Sie die Quell-IP-Adresse des GKE-Pod-Traffics steuern möchten, können Sie sowohl die ip-masq-agent (Übersetzung auf Knotenebene) als auch Cloud NAT (ausgehender Traffic auf VPC-Ebene) verwenden.
Übersicht
Wenn ein Pod in einem VPC-nativen GKE-Cluster ein Paket an ein Ziel außerhalb des Clusters sendet, ändert sich die Quell-IP-Adresse des Pakets je nach Konfiguration des IP-Masquerading-Agents auf Knotenebene (ip-masq-agent) und von Cloud NAT.
- Übersetzung auf Knotenebene (
ip-masq-agent) : Übersetzt die Quell-IP-Adresse des Pakets von der Pod-IP-Adresse (sekundärer Subnetzbereich) in die interne Knoten-IP-Adresse (primärer Subnetzbereich) basierend auf einer konfiguriertennonMasqueradeCIDRs-Liste. - Gateway auf VPC-Ebene (Cloud NAT) : Übersetzt interne VPC-IP-Adressen (Knoten-IP-Adressen oder Pod-IP-Adressen) in statische öffentliche IP-Adressen, um ausgehenden Internetzugriff zu ermöglichen.
Je nachdem, ob ein Ziel vom Knoten maskiert wird, verlässt das Paket den Knoten entweder mit der IP-Adresse des Knotens oder der IP-Adresse des Pods. Diese Quell-IP-Adresse bestimmt, wie Sie Ihre Cloud Router oder lokalen Router konfigurieren.
Zusammenwirken von IP-Masquerading und Cloud NAT
Bei internetorientiertem Traffic durchlaufen Pakete von einem Pod sowohl den Knoten-Netzwerkstack als auch das Cloud NAT-Gateway.
Szenario A: Maskierung in Knoten-IP-Adresse (empfohlen für ausgehenden Internet-Traffic)
Wenn die Ziel-IP-Adresse mit keinem Bereich in der nonMasqueradeCIDRs Liste übereinstimmt:
- Der
ip-masq-agentführt SNAT (Source NAT) auf dem GKE-Knoten aus. Die Quell-IP-Adresse wird von der Pod-IP-Adresse in die Knoten-IP-Adresse umgeschrieben. - Das Paket gelangt mit der Knoten-IP-Adresse als Quelle in das VPC-Netzwerk.
- Das Cloud NAT-Gateway fängt das Paket ab.
- Cloud NAT übersetzt die Knoten-IP-Adresse in eine öffentliche IP-Adresse und leitet sie an das Internet weiter.
Szenario B: Beibehalten der Pod-IP-Adresse (keine Maskierung)
Wenn die Ziel-IP-Adresse mit einem Bereich in der nonMasqueradeCIDRs-Liste übereinstimmt (oder wenn die Standard-SNAT deaktiviert ist):
- Der
ip-masq-agentlässt das Paket unverändert. Die Quell-IP-Adresse bleibt die Pod-IP-Adresse. - Das Paket gelangt mit der Pod-IP-Adresse als Quelle in das VPC-Netzwerk.
- Das Cloud NAT-Gateway fängt das Paket ab.
- Cloud NAT übersetzt die Pod-IP-Adresse nur dann in eine öffentliche IP-Adresse, wenn Cloud NAT explizit so konfiguriert ist, dass der sekundäre IP-Adressbereich des Subnetzes übersetzt wird, der für GKE-Pods verwendet wird.
IP-Masquerading-Prüfung
Mit dieser Prüfung können Sie prüfen, ob eine Ziel-IP-Adresse basierend auf Ihrer ip-masq-agent-Konfiguration maskiert wird.
Beispiel für Trafficfluss
Die folgende Beispielkonfiguration veranschaulicht den Übersetzungspfad:
- Pod-IP-Adressbereich:
10.4.0.0/14(Pod-IP-Adresse:10.4.0.5) - Knoten-IP-Adressbereich:
10.128.0.0/20(Knoten-IP-Adresse:10.128.0.10) - Ziel-IP-Adresse:
8.8.8.8(öffentlicher DNS-Server, nicht in dernonMasqueradeCIDRs-Liste)
Wenn der Pod ein Paket sendet, geschieht Folgendes:
- Paket startet im Pod:Das Paket stammt von der Netzwerkschnittstelle des Pods (IP-Adresse:
10.4.0.5) mit der Ziel-IP-Adresse8.8.8.8. - Maskierung auf Knotenebene:Da sich die Ziel-IP-Adresse
8.8.8.8nicht in dernonMasqueradeCIDRs-Liste befindet, fängt derip-masq-agentauf dem Hostknoten das Paket ab, wenn es den Knoten verlässt, und führt SNAT aus. Die Quell-IP-Adresse wird von der Pod-IP-Adresse10.4.0.5in die IP-Adresse des Hostknotens10.128.0.10umgeschrieben. - VPC-Ausgang:Das Paket erreicht das VPC-Netzwerk mit der IP-Adresse des Hostknotens
10.128.0.10als Quell-IP-Adresse. - Cloud NAT-Gateway:Da das Ziel das öffentliche Internet ist, verarbeitet Cloud NAT das Paket, übersetzt die Quell-IP-Adresse von
10.128.0.10in eine öffentliche NAT-IP-Adresse (z. B.203.0.113.1) und leitet sie an das Internet weiter. - Antwortverarbeitung:Die Antwort wird an die öffentliche Cloud NAT-IP-Adresse zurückgesendet, die von Cloud NAT wieder in die IP-Adresse des Hostknotens
10.128.0.10übersetzt wird. Der Knoten übersetzt dann die IP-Adresse des Hostknotens wieder in die Pod-IP-Adresse10.4.0.5und liefert sie an den Pod-Container.
Trafficfluss mit Cloud Service Mesh (CSM)
Wenn Ihre Arbeitslasten Cloud Service Mesh verwenden, verhält sich das Traffic-Routing so:
- Sidecar-Proxy oder Sidecarless-CNI-Umleitung:Ausgehende Pakete aus dem Anwendungscontainer werden vom Mesh abgefangen (mit einem Sidecar-Proxy wie Envoy oder über ebpf-basierte oder CNI-Umleitung), bevor sie den Netzwerk-Namespace des Knotens erreichen.
- Richtlinienanwendung:Das Mesh bestimmt anhand seiner Autorisierungs- und Ausgangsrichtlinien, ob die Verbindung zulässig ist.
- Ausgangsrouting:
- Wenn der Traffic über ein Cloud Service Mesh-Ausgangs-Gateway weitergeleitet wird, entspricht die Quell-IP-Adresse des Pakets, das den Knoten verlässt, der IP-Adresse des Knotens oder Pods des Ausgangs-Gateways und nicht dem ursprünglichen Pod.
- Wenn der Traffic direkt an den externen Endpunkt weitergeleitet wird, verlässt das Paket den Proxy und wird über den Standard-Netzwerkstack des Hostknotens weitergeleitet. In diesem Fall gelten die
ip-masq-agent-Richtlinien und Cloud NAT-Konfigurationen, die zuvor in diesem Dokument beschrieben wurden, weiterhin für den ausgehenden Traffic.
- Weitere Informationen zum Konfigurieren von Routing, Gateways und zum Verwalten von externem Traffic in Cloud Service Mesh finden Sie in der Cloud Service Mesh-Dokumentation.
Verbindungsprobleme beheben und isolieren
Wenn ein Pod keine Verbindung zu einem externen Endpunkt herstellen kann und Sie ein Service Mesh verwenden, müssen Sie isolieren, ob das Problem in der Service Mesh-Konfiguration oder im zugrunde liegenden GKE-Routing liegt. So isolieren Sie das Problem:
- Service Mesh umgehen: Stellen Sie einen temporären Client-Pod in einem Namespace bereit, in dem die Sidecar-Injektion deaktiviert ist, oder verwenden Sie die
sidecar.istio.io/inject: "false"Annotation in der Pod-Spezifikation, um die Injektion für die Testarbeitslast zu verhindern. - Verbindung testen:Versuchen Sie, vom Nicht-Mesh-Pod aus eine Verbindung zum externen Ziel herzustellen (z. B. mit
curl,pingodernc). - Ergebnisse analysieren:
- Wenn die Verbindung erfolgreich ist:Das zugrunde liegende GKE-Netzwerkrouting, die
ip-masq-agent-Regeln und das Cloud NAT-Gateway sind korrekt konfiguriert. Die Verbindungsblockierung wird durch Cloud Service Mesh-Richtlinien, fehlende Ausgangsregeln oder mTLS-Regeln verursacht. Weitere Informationen zur Fehlerbehebung finden Sie unter Fehlerbehebung bei Bereitstellungen, die Envoy verwenden in der Cloud Service Mesh-Dokumentation. - Wenn die Verbindung fehlschlägt:Das Problem liegt an der zugrunde liegenden Netzwerkinfrastruktur (z. B. IP-Masquerading, Cloud Router, Cloud NAT, VPC-Firewallregeln oder lokalen Firewalls). Führen Sie die Schritte auf dieser Seite aus, um Ihre Routingkonfiguration zu prüfen.
- Wenn die Verbindung erfolgreich ist:Das zugrunde liegende GKE-Netzwerkrouting, die
Quell-IP-Adressbereich mit der Prüfung ermitteln
Bevor Sie Router oder Firewalls konfigurieren, verwenden Sie die IP-Masquerading-Prüfung in diesem Dokument und führen Sie folgende Schritte aus:
- Fügen Sie den YAML-Inhalt Ihrer
ip-masq-agent-ConfigMap in das Konfigurationsfeld ein. - Geben Sie die Ziel-IP-Adresse Ihres Zielendpunkts ein (z. B. Ihre lokale Datenbank oder ein externer Internetdienst).
- Klicken Sie auf Masquerading prüfen.
- Schauen Sie sich die Ausgabe an:
- Maskiert: Das Paket verwendet den Knoten-IP-Adressbereich als Quelle.
- Nicht maskiert: Das Paket verwendet den Pod-IP-Adressbereich als Quelle.
Verbindung zu Endpunkten konfigurieren
Konfigurieren Sie basierend auf den Ergebnissen der IP-Masquerading-Prüfung Ihre Netzwerkpfade und Gateways entsprechend dem Zieltyp.
Lokale Endpunkte (VPN oder Interconnect)
Cloud NAT wird nicht für die lokale Verbindung verwendet. Sie müssen jedoch Ihre Router und Firewalls basierend auf dem Quell-IP-Adressbereich konfigurieren, den Sie mit der IP-Masquerading-Prüfung ermittelt haben.
Wenn der Traffic maskiert ist (Quelle ist die Knoten-IP-Adresse):
- Cloud Router:Achten Sie darauf, dass die Cloud Router-Advertisements den primären IP-Adressbereich des GKE-Cluster-Subnetzes enthalten.
- Lokaler Router oder Firewall:Konfigurieren Sie Ihre lokalen Router und Firewalls so, dass eingehender Traffic aus dem GKE-Knoten-IP-Adressbereich zugelassen und verarbeitet wird.
Wenn der Traffic nicht maskiert ist (Quelle ist die Pod-IP-Adresse):
- Cloud Router:Konfigurieren Sie benutzerdefinierte Routen-Advertisements auf Ihrem Cloud Router, um den sekundären IP-Adressbereich des GKE-Pods für Ihr lokales Netzwerk zu bewerben.
- Lokaler Router oder Firewall:Konfigurieren Sie lokale Routingtabellen und Firewalls so, dass Traffic aus dem GKE-Pod-IP-Adressbereich zugelassen wird, und sorgen Sie dafür, dass Rückrouten wieder für die VPC beworben werden.
Internetendpunkte (Cloud NAT)
Wenn Sie Traffic an öffentliche Internetendpunkte weiterleiten, müssen Sie ein Cloud NAT-Gateway in der VPC konfigurieren.
- Wechseln Sie in der Cloud de Confiance Console zur Seite Cloud NAT.
- Wählen Sie Ihr Cloud NAT-Gateway aus oder erstellen Sie es.
- Wählen Sie unter Cloud NAT-Quelle aus, wie das Gateway GKE-Subnetzbereiche verarbeitet:
- Wenn der Traffic maskiert ist (Quelle ist die Knoten-IP-Adresse) : Wählen Sie die primären IP-Adressbereiche des Subnetzes aus. Bei kommerziellen GKE-Bereitstellungen ist dies in der Regel die Standardeinstellung.
- Wenn der Traffic nicht maskiert ist (Quelle ist die Pod-IP-Adresse) : Wählen Sie Primäre und sekundäre IP-Adressbereiche aus oder geben Sie den sekundären Bereich des GKE-Pods explizit an. Wenn Sie nur primäre Bereiche auswählen, wird der GKE-Pod-Internettraffic blockiert.