Version 1.15 Diese Version wird nicht mehr unterstützt. Informationen zum Upgrade auf Version 1.16 finden Sie in der aktuellen Dokumentation unter Cluster upgraden. Weitere Informationen zu unterstützten und nicht unterstützten Versionen finden Sie in der aktuellen Dokumentation auf der Seite Versionsverlauf.

NAT-Gateway für ausgehenden Traffic konfigurieren

In diesem Dokument wird beschrieben, wie Sie ein NAT-Gateway für ausgehenden Traffic für GDCV für Bare Metal 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.

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 des Knotens konfiguriert werden können, der als Gateway ausgewählt werden 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 wenn ausgehender Traffic die Regeln zur Trafficauswahl nicht erfüllt, wird der ausgehende 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 für die Auswahl des ausgehenden Traffics basiert auf einem Namespace-Selektor, einem Pod-Selektor und einer Reihe von Ziel-IP-Adressbereichen in der CIDR-Blocknotation. Zur Veranschaulichung der Funktionsweise des NAT-Gateways für ausgehenden Traffic betrachten wir den Durchlauf eines Pakets von einem Pod zu einem externen Nutzer 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 des NAT-Gateways für ausgehenden Traffic für GKE on Bare Metal

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 der Netzwerk-Gateway-Gruppe ist eine gebündelte Komponente von GKE on Bare Metal. 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 Netzwerk-Gateway-Gruppendetails (Annotation und Spezifikation) in die Clusterkonfigurationsdatei ein, wenn Sie einen neuen Cluster mit Version 1.15.11 erstellen.

Benutzerdefinierte `NetworkGatewayGroup`-Ressource erstellen

Zum Aktivieren der Netzwerk-Gateway-Gruppe setzen Sie das Feld spec.clusterNetwork.advancedNetworking in der Clusterkonfigurationsdatei auf true, wenn Sie einen Cluster erstellen, 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 Antwortvorlage 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 für die Verwendung derselben IP-Adresse konfigurieren möchten, verwenden Sie gatewayRef.name und gatewayRef.namespace für beide.

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. In der Regel 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

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.
Upgrades werden nicht für Cluster unterstützt, die für die Verwendung der Vorschau des NAT-Gateways für ausgehenden Traffic konfiguriert wurden. Ab Version 1.15.0 von GKE on Bare Metal ist das NAT-Gateway für ausgehenden Traffic nur unter Ubuntu 18.04 in der Vorabversion verfügbar. Während der Vorschau ist dieses Feature kostenlos.