NAT-Gateway für ausgehenden Traffic konfigurieren

In diesem Dokument wird beschrieben, wie Sie ein NAT-Gateway für Anthos-Cluster auf 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.

NAT-Gateway für ausgehenden Traffic für Anthos-Cluster auf Bare Metal-Servern

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 Anthos-Cluster 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 Details der Network Gateway Group (Annotation und Spezifikation) in die Clusterkonfigurationsdatei ein, wenn Sie einen neuen Cluster der Version 1.12.9 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.

Eine Einschränkung von NetworkGatewayGroup in Anthos-Cluster on Bare-Metal besteht darin, dass nur das Standardobjekt für Floating-IP-Zuweisungen abgeglichen wird. Darüber hinaus meldet nur das Standard-Gateway den Zuweisungsstatus für alle Floating-IP-Adressen.

Das Standardgateway wird durch den NetworkGatewayGroup mit dem Namen default im Namespace kube-system definiert. Wenn Sie mehrere Gateway-Objekte erstellen, müssen Sie daher darauf achten, dass die IP-Adressen in den nicht standardmäßigen Gateways auch im Standard-Gateway-Manifest angegeben sind. Andernfalls werden sie nicht als Floating-IP-Adressen zugewiesen und können daher nicht vom EgressNATPolicies-Objekt verwendet werden.

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

Prüfen Sie das Standard-Gateway-Objekt (name: default) mit kubectl, um den Zuweisungsstatus der Floating-IP-Adressen abzurufen:

kubectl -n kube-system get NetworkGatewayGroup.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:
  ...
  floatingIPs:
    192.168.1.100: worker1
    192.168.1.101: worker2
    192.168.1.102: worker1

Nachdem Sie den Status des Standard-Gateways geprüft haben, erstellen Sie zusätzliche Gateway-Objekte im Namespace kube-system, um jede Floating-IP-Adresse zu "verfolgen".

Beachten Sie, dass diese neuen Gateway-Objekte nicht den Zuweisungsstatus melden, der sich im default-Gateway befindet.

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

Erstellen Sie mehrere Richtlinien, die auf die "sekundären" Gateway-Objekte verweisen, z. B. gateway1, der im vorherigen Schritt erstellt wurde:

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. Für Anthos-Cluster auf Bare Metal Version 1.12.0 und höher ist das ausgehende NAT-Gateway nur in der Vorschau auf Ubuntu 18.04 verfügbar. Während der Vorschau ist dieses Feature kostenlos.