Google verwendet KI-Technologie, um Inhalte in Ihre bevorzugte Sprache zu übersetzen. KI-Übersetzungen können Fehler enthalten.

NAT-Gateway für ausgehenden Traffic konfigurieren

In diesem Dokument wird beschrieben, wie Sie ein NAT-Gateway für ausgehenden Traffic für Google Distributed Cloud einrichten. Dieses Gateway bietet nichtflüchtige, deterministische SNAT-IP-Adressen für den ausgehenden Traffic von Ihren Clustern. Wenn Sie Arbeitslasten mit ausgehendem Nutzertraffic (außerhalb Ihrer Cluster) ausführen, möchten Ihre Kunden diesen Traffic mit einigen deterministischen IP-Adressen identifizieren. Dadurch können Ihre Kunden IP-basierte Sicherheitsmaßnahmen ergreifen, wie das Setzen von Richtlinien auf die Zulassungsliste.

Diese Seite richtet sich an Netzwerkspezialisten, die das Netzwerk für ihre Organisation entwerfen und erstellen sowie Netzwerkgeräte installieren, konfigurieren und unterstützen. Weitere Informationen zu gängigen Rollen und Beispielaufgaben, auf die wir in Google Cloud Inhalten verweisen, finden Sie unter Häufig verwendete GKE-Nutzerrollen und -Aufgaben.

Das NAT-Gateway für ausgehenden Traffic wird mit zwei benutzerdefinierten Ressourcen aktiviert. Für einen bestimmten Namespace gibt die benutzerdefinierte Ressource NetworkGatewayGroup Floating-IP-Adressen an, die auf der Netzwerkschnittstelle eines Knotens konfiguriert werden können, der als Gateway fungieren soll. Mit der benutzerdefinierten Ressource EgressNatPolicy können Sie Routing-Richtlinien für ausgehenden Traffic festlegen, um den Traffic auf dem Gateway für ausgehenden Traffic zu steuern.

Wenn Sie kein NAT-Gateway für ausgehenden Traffic einrichten oder ausgehender Traffic nicht den Trafficauswahlregeln entspricht, wird ausgehender Traffic von einem bestimmten Pod zu einem Ziel außerhalb Ihres Clusters an die IP-Adresse des Knotens maskiert, auf dem der Pod ausgeführt wird. In diesem Szenario gibt es keine Garantie, dass der gesamte ausgehende Traffic von einem bestimmten Pod dieselbe Quell-IP-Adresse hat oder zu derselben Knoten-IP-Adresse maskiert wird.

NAT-Gateway für ausgehenden Traffic ist ein erweitertes Netzwerkangebot, das auf Dataplane V2 basiert.

Funktionsweise des NAT-Gateways für ausgehenden Traffic

Die Logik zur Auswahl von ausgehendem Traffic basiert auf einem Namespace-Selector, einem Pod-Selector und einer Reihe von Ziel-IP-Adressbereichen in CIDR-Blocknotation. Um die Funktionsweise des NAT-Gateways für ausgehenden Traffic zu veranschaulichen, betrachten wir den Fluss eines Pakets von einem Pod zu einem externen Consumer und die entsprechende Antwort. Angenommen, das Knotensubnetz hat IP-Adressen im CIDR-Block 192.168.1.0/24.

Das folgende Diagramm zeigt die Netzwerkarchitektur für ausgehenden Traffic über einen Gateway-Knoten.

Diagramm zum NAT-Gateway für ausgehenden Traffic für Google Distributed Cloud

Der Paketdurchlauf durch das NAT-Gateway für ausgehenden Traffic könnte so aussehen:

Ausgehender Traffic wird von einem Pod mit der IP-Adresse 10.10.10.1 in einem Knoten mit der IP-Adresse 192.168.1.1 generiert.

Die Zieladresse des Traffics ist ein Endpunkt außerhalb des Clusters.
Wenn der Traffic mit einer Regel für ausgehenden Traffic übereinstimmt, leitet das eBPF-Programm den ausgehenden Traffic an den Gateway-Knoten weiter, anstatt die Knoten-IP-Adresse direkt zu maskieren.
Der Gateway-Knoten empfängt den ausgehenden Traffic.
Der Gateway-Knoten maskiert die Quell-IP-Adresse 10.10.10.1 des ausgehenden Traffics, mit der in der benutzerdefinierten Ressource EgressNATPolicy angegebenen Quell-IP-Adresse 192.168.1.100.
Der Rücktraffic wird mit dem Ziel 192.168.1.100 an den Gateway-Knoten zurückgegeben.
Der Gateway-Knoten gleicht die Verbindungsverfolgung des Rücktraffics mit dem des ursprünglichen ausgehenden Traffics ab und schreibt die Ziel-IP-Adresse in 10.10.10.1 um.
10.10.10.1 wird als In-Cluster-Traffic behandelt, an den ursprünglichen Knoten weitergeleitet und zurück an den ursprünglichen Pod gesendet.

Floating-IP-Adressen für Knoten-Traffic konfigurieren

Die benutzerdefinierte Ressource „Network Gateway Group“ ist eine gebündelte Komponente von Google Distributed Cloud. Die Ressource verwaltet eine Liste mit einer oder mehreren Floating-IP-Adressen, die für ausgehenden Traffic von Knoten in Ihrem Cluster verwendet werden. Teilnehmende Knoten werden durch den angegebenen Namespace bestimmt. Die Netzwerk-Gateway-Gruppe stellt eine Floating-IP-Adresse jederzeit auf Best-Effort-Basis zur Verfügung. Wenn ein Knoten mit einer Floating-IP-Adresse ausfällt, wird die zugewiesene IP-Adresse vom erweiterten Netzwerkbetreiber auf den nächsten verfügbaren Knoten verschoben. Der gesamte ausgehende Traffic von Arbeitslasten, die diese IP-Adresse verwenden, wird ebenfalls verschoben.

Fügen Sie die Details zur Netzwerk-Gateway-Gruppe (Annotation und Spezifikation) in die Clusterkonfigurationsdatei ein, wenn Sie einen neuen 1.36.100-gke.144-Cluster erstellen.

Benutzerdefinierte `NetworkGatewayGroup`-Ressource erstellen

Sie aktivieren die Netzwerk-Gateway-Gruppe, indem Sie das Feld spec.clusterNetwork.advancedNetworking in der Clusterkonfigurationsdatei beim Erstellen eines Clusters auf true setzen, wie im folgenden Beispiel gezeigt:

apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: cluster1
  namespace: cluster-cluster1
spec:
  clusterNetwork:
    ...
    advancedNetworking: true
    ...

Legen Sie beim Erstellen der benutzerdefinierten Ressource NetworkGatewayGroup als Namespace den Cluster-Namespace fest und geben Sie eine Liste der Floating-IP-Adressen an, wie im folgenden Beispiel gezeigt:

kind: NetworkGatewayGroup
apiVersion: networking.gke.io/v1
metadata:
  namespace: cluster-cluster1
  name: default
spec:
  floatingIPs:
  - 192.168.1.100
  - 192.168.1.101
  - 192.168.1.102

Der Operator für erweiterte Netzwerkoptionen weist den Floating-IP-Adressen die Knoten gemäß den folgenden Kriterien zu:

Knotensubnetz: Die Floating-IP-Adresse muss mit dem Subnetz des Knotens übereinstimmen.
Knotenrolle (Steuerungsebene, Worker): Worker-Knoten haben beim Zuweisen von Floating-IP-Adressen Vorrang vor Knoten der Steuerungsebene.
Vorhandensein einer Floating-IP-Adresse: Der Operator priorisiert Zuweisungen an Knoten, die noch keine Floating-IP-Adresse haben.

Die Zuordnung von Adressen zu Knoten finden Sie im Abschnitt status, wenn Sie das Objekt NetworkGatewayGroup abrufen. Das Objekt NetworkGatewayGroup befindet sich im Namespace kube-system. Wenn ein Gatewayknoten ausgefallen ist, weist der erweiterte Netzwerkoperator die Floating-IP-Adresse dem nächsten verfügbaren Knoten zu.

Gateway-Konfiguration prüfen

Nachdem Sie die Änderungen an der Gateway-Konfiguration angewendet haben, können Sie mit kubectl den Status des Gateways prüfen und die für das Gateway angegebenen Floating-IP-Adressen abrufen.

Mit dem folgenden Befehl können Sie den Status von NetworkGatewayGroup prüfen und feststellen, wie die Floating-IP-Adressen zugewiesen werden:

kubectl -n kube-system get networkgatewaygroups.networking.gke.io default -o yaml

Die Antwort für einen Cluster mit den beiden Knoten worker1 und worker2 könnte so aussehen:

kind: NetworkGatewayGroup
apiVersion: networking.gke.io/v1
metadata:
  namespace: kube-system
  name: default
spec:
  floatingIPs:
  - 192.168.1.100
  - 192.168.1.101
  - 192.168.1.102
status:
  nodes:
    worker1: Up
    worker2: Up // Or Down
  floatingIPs:
    192.168.1.100: worker1
    192.168.1.101: worker2
    192.168.1.102: worker1

Regeln zur Traffic-Auswahl festlegen

Die benutzerdefinierte Ressource EgressNATPolicy gibt Trafficauswahlregeln an und weist ausgehendem Traffic, der den Cluster verlässt, eine deterministische IP-Adresse zu. Beim Festlegen der benutzerdefinierten Ressource sind egress (mit mindestens einer Regel), destinationCIDRs und egressSourceIP erforderlich.

Verwenden Sie kubectl apply, um die benutzerdefinierte EgressNATPolicy-Ressource zu erstellen. Die folgenden Abschnitte enthalten Details und Beispiele zum Definieren der Spezifikation.

Routingregeln für ausgehenden Traffic festlegen

Mit der benutzerdefinierten Ressource EgressNatPolicy können Sie die folgenden Regeln für ausgehenden Traffic angeben:

Geben Sie im Abschnitt egress eine oder mehrere Regeln zur Auswahl des ausgehenden Traffics an.
- Jede Regel besteht aus einem podSelector und einem namespaceSelector.
- Die Auswahl basiert auf einem Namespace-Label (namespaceSelector.matchLabels.user) und einem Pod-Label (podSelector.matchLabels.role).
- Wenn ein Pod mit einer der Regeln übereinstimmt (Übereinstimmung verwendet eine OR-Beziehung), wird er für ausgehenden Traffic ausgewählt.
Geben Sie im Abschnitt destinationCIDRs zulässige Zieladressen an.
- destinationCIDRs enthält eine Liste von CIDR-Blöcken.
- Wenn der ausgehende Traffic von einem Pod eine Ziel-IP-Adresse hat, die in den Bereich eines der angegebenen CIDR-Blöcke fällt, wird er für ausgehenden Traffic ausgewählt.

Im folgenden Beispiel ist ausgehender Traffic von einem Pod zulässig, wenn die folgenden Kriterien erfüllt sind:

Der Pod ist mit role: frontend gekennzeichnet.
Der Pod befindet sich in einem Namespace mit dem Label user: alice oder user: paul.
Der Pod kommuniziert mit IP-Adressen im CIDR-Block 8.8.8.0/24.

kind: EgressNATPolicy
apiVersion: networking.gke.io/v1
metadata:
  name: egress
spec:
  sources:
  - namespaceSelector:
      matchLabels:
        user: alice
    podSelector:
      matchLabels:
        role: frontend
  - namespaceSelector:
      matchLabels:
        user: paul
    podSelector:
      matchLabels:
        role: frontend
  action: SNAT
  destinations:
    - cidr: 8.8.8.0/24
  gatewayRef:
    name: default
    namespace: kube-system

Weitere Informationen zur Verwendung von Labels finden Sie in der Kubernetes-Dokumentation unter Labels und Selektoren.

Quell-IP-Adresse für ausgehenden Traffic abrufen

Die benutzerdefinierte Ressource EgressNATPolicy (Richtlinie) verwendet die Werte gatewayRef.name und gatewayRef.namespace, um ein NetworkGatewayGroup-Objekt (Gateway) zu finden. Die Richtlinie verwendet eine der Floating-IP-Adressen als Quell-IP-Adresse für ausgehenden Traffic. Wenn das übereinstimmende Gateway mehrere Floating-IP-Adressen enthält, verwendet die Richtlinie die erste IP-Adresse in der floatingIPs-Liste und ignoriert alle anderen IP-Adressen. Für das Beispielgateway lautet die erste Adresse in der Liste floatingIPs 192.168.1.100. Ungültige Felder oder Werte im Abschnitt gatewayRef führen dazu, dass das Richtlinienobjekt nicht angewendet wird.

Mehrere Richtlinien für ausgehenden Traffic und mehrere Gateway-Objekte

Wie im vorherigen Abschnitt beschrieben, verwendet jedes egressNATPolicy-Objekt (Richtlinie) die erste IP-Adresse in der floatingIPs-Liste aus dem Gateway-Objekt, das mit gatewayRef.name und gatewayRef.namespace übereinstimmt. Sie können mehrere Richtlinien erstellen. Wenn Sie andere IP-Adressen verwenden möchten, müssen Sie mehrere NetworkGatewayGroup-Objekte erstellen und jeweils auf sie verweisen.

Jede NetworkGatewayGroup-Ressource muss eindeutige Floating-IP-Adressen enthalten. Wenn Sie mehrere EgressNATPolicy-Objekte so konfigurieren möchten, dass sie dieselbe IP-Adresse verwenden, nutzen Sie für beide dieselbe gatewayRef.name und gatewayRef.namespace.

So richten Sie mehrere Richtlinien für ausgehenden Traffic und mehrere Gateway-Objekte ein:

Erstellen Sie Gateway-Objekte im Namespace kube-system, um die einzelnen Floating-IP-Adressen zu verwalten. Normalerweise sollte jede Richtlinie für ausgehenden Traffic ein entsprechendes Gateway-Objekt haben, damit die richtige IP-Adresse zugewiesen wird.

Überprüfen Sie dann jedes Gateway-Objekt mit kubectl, um den Zuweisungsstatus der Floating-IP-Adressen zu erhalten:

kind: NetworkGatewayGroup
apiVersion: networking.gke.io/v1
metadata:
  namespace: kube-system
  name: gateway1
spec:
  floatingIPs:
  - 192.168.1.100
status:
  ...
  floatingIPs:
    192.168.1.100: worker1
---
kind: NetworkGatewayGroup
apiVersion: networking.gke.io/v1
metadata:
  namespace: kube-system
  name: gateway2
spec:
  floatingIPs:
  - 192.168.1.101
status:
  ...
  floatingIPs:
    192.168.1.101: worker2
---
kind: NetworkGatewayGroup
apiVersion: networking.gke.io/v1
metadata:
  namespace: kube-system
  name: gateway3
spec:
  floatingIPs:
  - 192.168.1.102
status:
  ...
  floatingIPs:
    192.168.1.102: worker1

Erstellen Sie mehrere Richtlinien, die auf die Gateway-Objekte verweisen, z. B. gateway1, die im vorherigen Schritt erstellt wurden:

kind: EgressNATPolicy
apiVersion: networking.gke.io/v1
metadata:
  name: egress1
spec:
  ...
  gatewayRef:
    name: gateway1
    namespace: kube-system
---
kind: EgressNATPolicy
apiVersion: networking.gke.io/v1
metadata:
  name: egress2
spec:
  ...
  gatewayRef:
    name: gateway2
    namespace: kube-system
---
kind: EgressNATPolicy
apiVersion: networking.gke.io/v1
metadata:
  name: egress3
spec:
  ...
  gatewayRef:
    name: gateway3
    namespace: kube-system

(Optional) Knoten angeben, auf denen Floating-IP-Adressen platziert werden sollen

NetworkGatewayGroup-Ressourcen unterstützen Knotenauswahlen. Um eine Teilmenge von Knoten anzugeben, die für das Hosting einer Floating-IP-Adresse berücksichtigt werden, können Sie die Knotenauswahl zum NetworkGatewayGroup-Objekt hinzufügen, wie im folgenden Beispiel gezeigt:

kind: NetworkGatewayGroup
apiVersion: networking.gke.io/v1
metadata:
  namespace: cluster-cluster1
  name: default
spec:
  floatingIPs:
  - 192.168.1.100
  - 192.168.1.101
  - 192.168.1.102
  nodeSelector:
    node-type: "egressNat"

Die Knotenauswahl entspricht Knoten mit dem angegebenen Label. Nur diese Knoten werden für das Hosting einer Floating-IP-Adresse berücksichtigt. Wenn Sie mehrere Selektoren angeben, wird deren Logik additiv angewendet. Ein Knoten muss also mit jedem Label übereinstimmen, um für das Hosten einer Floating-IP-Adresse infrage zu kommen. Wenn es nicht viele Knoten mit übereinstimmenden Labels gibt, kann ein Knotenselektor die Hochverfügbarkeit (HA) der Platzierung von Floating-IP-Adressen verringern.

Schnelles Failover für ein NAT-Gateway für ausgehenden Traffic mit Hochverfügbarkeit

Bei Clustern ab Version 1.34 können Sie das NAT-Gateway für ausgehenden Traffic mit schnellem Failover konfigurieren. Wenn Sie mehrere Floating-IP-Adressen haben und ein schnelles Failover konfigurieren, wird ein Ausgang mit hoher Verfügbarkeit bereitgestellt. Diese Funktion bietet eine bessere Lastverteilung für ausgehenden Traffic und ein schnelleres Failover, um Ausfallzeiten zu minimieren. Anstatt sich jeweils auf einen einzelnen Gateway-Knoten zu verlassen (Aktiv/Standby), verteilt der Cluster ausgehenden Traffic auf mehrere Gateway-Knoten und alle konfigurierten Floating-IP-Adressen in einer NetworkGatewayGroup-Ressource.

Dieses Active-Active-Modell bietet die folgenden Hauptvorteile:

Lastverteilung: Ausgehender Traffic von verschiedenen Quellendpunkten wie Pods wird auf alle verfügbaren Gateway-Knoten verteilt. Dadurch wird die Last auf einzelnen Knoten reduziert und die insgesamt verfügbare Egress-Bandbreite erhöht.
Schnelles Failover: Wenn ein Egress-Gateway-Knoten ausfällt, wird der Traffic automatisch zu den verbleibenden fehlerfreien Knoten weitergeleitet. Ziel ist es, dass der Traffic schnell auf das Failover-System umgeleitet wird. Während bestehende Verbindungen auf dem ausgefallenen Knoten unterbrochen werden, werden neue Verbindungen sofort über andere Gateways hergestellt, wodurch die Ausfallzeit minimiert wird.

Wichtige Unterschiede

Wenn Sie das NAT-Gateway für ausgehenden Traffic für schnelles Failover konfigurieren, ändert sich die Funktionsweise des NAT-Gateways für ausgehenden Traffic:

Funktion	Aktiv/Stand-by (Standardeinstellung)	Aktiv/Aktiv (schneller Failover)
Verwendung von Floating-IP-Adressen	Die `EgressNATPolicy` verwendet nur die erste Floating-IP-Adresse in der `NetworkGatewayGroup`.	Alle in der `NetworkGatewayGroup` aufgeführten Floating-IP-Adressen verteilen den ausgehenden Traffic aktiv.
Failover	Wenn der Gateway-Knoten ausfällt, wird dieselbe Floating-IP-Adresse auf einen anderen Knoten verschoben, was zu einer Unterbrechung des Traffics führen kann.	Wenn ein Gatewayknoten ausfällt, wird der Traffic zu einer anderen, fehlerfreien IP-Adresse auf einem anderen Knoten weitergeleitet. Neue Verbindungen werden sofort über die fehlerfreien Gateways weitergeleitet, während vorhandene zustandsbehaftete Verbindungen auf dem fehlerhaften Knoten beendet werden.
Traffic	Der gesamte Traffic für eine bestimmte Richtlinie wird über einen einzelnen Gateway-Knoten geleitet.	Der Traffic wird auf mehrere Gateway-Knoten verteilt. Grundlage dafür ist eine konsistente Hashfunktion des Quellendpunkts, z. B. eines Pods.

Schnellen Failover konfigurieren

Die Konfiguration der Funktion umfasst zwei Hauptschritte:

Geben Sie mehrere Floating-IP-Adressen an.

Konfigurieren Sie die NetworkGatewayGroup mit einem Pool von mindestens zwei dynamischen IP-Adressen, um die Vorteile von Hochverfügbarkeit und Lastverteilung zu nutzen. Wenn Sie mehr Floating-IP-Adressen verwenden, verbessern Sie die Zuverlässigkeit und den Durchsatz des ausgehenden Traffics.

Hier sehen Sie eine Beispielkonfiguration:
```
apiVersion: networking.gke.io/v1
kind: NetworkGatewayGroup
metadata:
  name: egress-gateways
  namespace: cluster-admin
spec:
  nodeSelector:
    # Selects nodes that are designated as egress gateways
    node-role.kubernetes.io/egress: ""
  floatingIPs:
  - "192.168.1.100"
  - "192.168.1.101"
  - "192.168.1.102"
```

Fügen Sie der benutzerdefinierten Ressource EgressNATPolicy die Annotation networking.gke.io/egressnat-ha: "enable" hinzu, um das schnelle Failover zu aktivieren:

kind: EgressNATPolicy
apiVersion: networking.gke.io/v1
metadata:
  name: egress
  annotations:
    networking.gke.io/egressnat-ha: "enable"
spec:
  ...

Auswahlregeln für ausgehenden Traffic und Netzwerkrichtlinien

Das NAT-Gateway für ausgehenden Traffic ist mit Netzwerkrichtlinien-APIs kompatibel. Netzwerkrichtlinien werden zuerst bewertet und haben Vorrang vor den Regeln zur Trafficauswahl des NAT-Gateways. Wenn beispielsweise der ausgehende Traffic eine Netzwerkrichtlinie auslöst, die dazu führt, dass das Paket verworfen wird, prüfen die Gateway-Regeln für ausgehenden Traffic das Paket nicht. Nur wenn die Netzwerkrichtlinie das Paket an ausgehenden Traffic zulässt, werden die Regeln zur Auswahl des ausgehenden Traffics ausgewertet, um zu entscheiden, wie der Traffic verarbeitet wird, entweder mithilfe des NAT-Gateways für ausgehenden Traffic oder direkt durch Maskierung mit der IP-Adresse des Knoten, auf dem der Pod ausgeführt wird.

Beschränkungen

Derzeit gelten folgende Einschränkungen für das NAT-Gateway für ausgehenden Traffic:

Das NAT-Gateway für ausgehenden Traffic ist nur für den IPv4-Modus aktiviert.
Ausgehende IP-Adressen müssen sich in derselben Ebene-2-Domain mit Knoten-IP-Adressen befinden.
Wenn Sie das standardmäßige BGP-Load-Balancing zusammen mit Egress NAT konfigurieren und die GKE On-Prem API zum Verwalten Ihrer Cluster verwenden (mit Terraform, der Google Cloud Console oder der gcloudCLI), werden BGP-Peer-Selektoren nicht unterstützt. Diese fehlende Unterstützung kann dazu führen, dass BGP-Sitzungen zufällig falsche lokale IPs für das Peering verwenden, was zu einem BGP-Peering-Fehler führt. Eine Problemumgehung finden Sie unter Gebündelte Load-Balancer mit BGP konfigurieren: Einschränkung des BGP-Selektors.