NAT-Gateway für ausgehenden Traffic konfigurieren

Mit Google Distributed Cloud können Sie die Quellnetzwerkadressübersetzung (SNAT, Source Network Address Translation) konfigurieren, sodass bestimmter ausgehender Traffic von Ihrem Nutzercluster eine vorhersagbare Quell-IP-Adresse erhält.

In diesem Dokument wird gezeigt, wie ein NAT-Gateway für ausgehenden Traffic für einen Nutzercluster konfiguriert wird.

Achtung: Sie können Cluster der Version 1.8.x oder 1.9.x, für die Anthos Network Gateway aktiviert ist, nicht auf eine neuere Version aktualisieren. Sie können beispielsweise kein Cluster der Version 1.9.0 mit aktiviertem Anthos Network Gateway auf Version 1.9.x aktualisieren oder ein Upgrade auf Version 1.10 durchführen. Sie können nur Cluster aktualisieren, für die Anthos Network Gateway aktiviert ist, wenn sie in Version 1.10 oder höher erstellt wurden. Sie können einen Cluster der Version 1.8.x oder Version 1.9.x löschen und dann der Anleitung in diesem Dokument neu erstellen.

Einführung

Manchmal werden Pods in einem Nutzercluster ausgeführt, die Pakete an Komponenten senden müssen, die in Ihrer Organisation, aber außerhalb des Clusters ausgeführt werden. Sie können diese externen Komponenten so gestalten, dass sie eingehenden Netzwerktraffic entsprechend einer Reihe bekannter Quell-IP-Adressen filtern.

Im Folgenden sind einige Szenarien aufgeführt:

• Sie haben eine Firewall vor einer Datenbank, die den Zugriff nur nach IP-Adresse zulässt. Das Team, das die Datenbankfirewall verwaltet, unterscheidet sich vom Team, das den Nutzercluster verwaltet.

• Arbeitslasten in Ihrem Nutzercluster müssen über das Internet auf eine Drittanbieter-API zugreifen. Aus Sicherheitsgründen authentifiziert und autorisiert der API-Anbieter den Traffic mithilfe der IP-Adresse als Identität.

Mit einem NAT-Gateway für ausgehenden Traffic können Sie die Quell-IP-Adressen für den Netzwerktraffic, der einen Cluster verlässt, detailliert steuern.

Preise

Für die Verwendung dieses Features während der Vorschau fallen keine Gebühren an.

Funktionsweise eines NAT-Gateways für ausgehenden Traffic

Wenn ein Pod ein Paket aus dem Cluster sendet, wird das Paket normalerweise per SNAT mit der IP-Adresse des Knotens übersetzt, auf dem der Pod ausgeführt wird.

Wenn ein NAT-Gateway für ausgehenden Traffic vorhanden ist, können Sie festlegen, dass bestimmte ausgehende Pakete zuerst an einen dedizierten Gateway-Knoten gesendet werden. Die Netzwerkschnittstelle auf dem Gateway-Knoten wird mit zwei IP-Adressen konfiguriert: der primären IP-Adresse und der Quell-IP-Adresse für ausgehenden Traffic.

Wenn ein Paket ausgewählt wurde, das für das NAT-Gateway für ausgehenden Traffic verwendet wird, verlässt das Paket den Cluster vom Gateway-Knoten und wird per SNAT mit der Quell-IP-Adresse für ausgehenden Traffic übersetzt, die auf der Netzwerkschnittstelle konfiguriert ist.

Das folgende Diagramm veranschaulicht den Paketablauf:

Das obige Diagramm zeigt den Ablauf eines Pakets, das vom Pod gesendet wird.

1. Auf einem Knoten mit der IP-Adresse 192.168.1.1 generiert ein Pod mit der IP-Adresse 10.10.10.1 ein ausgehendes Paket.

2. Das Paket entspricht einer Regel für ausgehenden Traffic, sodass das Paket an den Gateway-Knoten weitergeleitet wird.

3. Der Gateway-Knoten ändert die Quell-IP-Adresse in 192.168.1.100 und sendet das Paket aus dem Cluster.

4. Der Rücktraffic kehrt zum Gateway-Knoten mit dem Ziel 192.168.1.100 zurück.

5. Der Gateway-Knoten verwendet Conntrack, um die Ziel-IP-Adresse in 10.10.10.1 zu ändern.

6. Das Paket wird als clusterinterner Traffic behandelt, an den ursprünglichen Knoten weitergeleitet und an den ursprünglichen Pod zurückgesendet.

Identitäten

In diesem Thema werden zwei Identitäten behandelt:

• Clusteradministrator. Diese Person erstellt einen Nutzercluster und gibt Floating-IP-Adressen an, die von Anthos Network Gateway verwendet werden sollen.

• Entwickler. Diese Person führt Arbeitslasten im Nutzercluster aus und erstellt Richtlinien für ausgehenden Traffic.

NAT-Gateway für ausgehenden Traffic aktivieren

Dieser Abschnitt richtet sich an Clusteradministratoren.

Verwenden Sie zum Konfigurieren eines NAT-Gateways für ausgehenden Traffic die Felder enableDataplaneV2 und advancedNetworking in der Konfigurationsdatei des Nutzerclusters und erstellen Sie ein oder mehrere NetworkGatewayGroup-Objekte.

Legen Sie in der Clusterkonfigurationsdatei die folgenden Felder auf true fest:

enableDataplaneV2: true
...
advancedNetworking: true

Erstellen Sie den Nutzercluster.

Floating-IP-Adressen angeben

Dieser Abschnitt richtet sich an Clusteradministratoren.

Wählen Sie eine Reihe von IP-Adressen aus, die Sie als Quelladressen für ausgehenden Traffic verwenden möchten. Diese werden als Floating-IP-Adressen bezeichnet, da Network Gateway Group sie nach Bedarf den Netzwerkschnittstellen von Knoten zuweist, die als Gateways für ausgehenden Traffic ausgewählt werden.

Die Floating-IP-Adressen müssen sich im selben Subnetz wie die Knoten-IP-Adressen befinden.

Der Satz von Floating-IP-Adressen darf sich nicht mit dem Satz von IP-Adressen überschneiden, den Sie für Ihre Knoten angegeben haben.

Angenommen, ein Subnetz hat den Adressbereich 192.168.1.0/24. Nehmen wir außerdem an, dass Sie 192.168.1.1 bis 192.168.1.99 für Knoten verwenden möchten. Dann können Sie 192.168.1.100 bis 192.168.1.104 als Floating-IP-Adressen verwenden.

NetworkGatewayGroup-Objekt erstellen

Dieser Abschnitt richtet sich an Clusteradministratoren.

Hier ein Beispiel für ein Manifest für ein NetworkGatewayGroup-Objekt:

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
  - 192.168.1.103
  - 192.168.1.104

Ersetzen Sie das Array floatingIPs durch Ihre Floating-IP-Adressen und speichern Sie das Manifest in einer Datei mit dem Namen my-ngg.yaml.

Erstellen Sie das NetworkGatewayGroup-Objekt:

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG apply -f my-ngg.yaml

Beispiel für eine NAT-Richtlinie für ausgehenden Traffic

Dieser Abschnitt richtet sich an Entwickler.

Das folgende Beispiel zeigt eine benutzerdefinierte EgressNatPolicy-Ressource:

kind: EgressNATPolicy
apiVersion: networking.gke.io/v1
metadata:
  name: alice-paul
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

Im vorhergehenden Manifest sehen wir:

• Ein Pod ist ein Kandidat für NAT für ausgehenden Traffic, wenn er folgende Voraussetzungen erfüllt:

  • Der Pod hat das Label role: frontend und der Pod befindet sich in einem Namespace mit dem Label user: alice.

  • Der Pod hat das Label role: frontend und der Pod befindet sich in einem Namespace mit dem Label user: paul.

• Traffic von einem Kandidaten-Pod an eine Adresse im Bereich 8.8.8.0/24 wird an das NAT-Gateway für ausgehenden Traffic gesendet.

• Der Abschnitt gatewayRef bestimmt die IP-Adresse der ausgehenden Quelle. Die benutzerdefinierte EgressNATPolicy-Ressource verwendet die Werte gatewayRef.name und gatewayRef.namespace, um ein NetworkGatewayGroup-Objekt zu finden. Die Richtlinie verwendet eine der Floating-IP-Adressen der NetworkGatewayGroup als Quell-IP-Adresse für ausgehenden Traffic. Wenn die übereinstimmende NetworkGatewayGroup mehrere Floating-IP-Adressen enthält, verwendet die Richtlinie die erste IP-Adresse in der floatingIPs-Liste und ignoriert alle anderen IP-Adressen. Wenn im Abschnitt gatewayRef ungültige Felder vorhanden sind, kann das Egress-NAT-Richtlinienobjekt nicht angewendet werden.

EgressNATPolicy-Objekt erstellen

Erstellen Sie Ihr eigenes EgressNATPolicy-Manifest. Setzen Sie metadata.name auf "my-policy". Speichern Sie Ihr Manifest in einer Datei mit dem Namen my-policy.yaml.

Erstellen Sie das EgressNatPolicy-Objekt:

kubectl apply --kubeconfig USER_CLUSTER_KUBECONFIG -f my-policy.yaml

Informationen zur NAT-Richtlinie für ausgehenden Traffic ansehen

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get egressnatpolicy my-policy --output yaml

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get networkgatewaygroup --namespace kube-system --output yaml

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG describe egressnatpolicy my-policy

Reihenfolge von Vorgängen

Die NAT-Richtlinie für ausgehenden Traffic ist mit APIs für Netzwerkrichtlinien kompatibel. Die Netzwerkrichtlinie wird vor der NAT-Richtlinie für ausgehenden Traffic ausgewertet. Wenn eine Netzwerkrichtlinie vorgibt, ein Paket zu verwerfen, wird das Paket unabhängig von der NAT-Richtlinie für ausgehenden Traffic verworfen.

Mehrere Richtlinien für ausgehenden Traffic

Wie bereits beschrieben verwendet jede EgressNATPolicy die erste IP-Adresse in der floatingIPs-Liste aus der NetworkGatewayGroup, die mit gatewayRef.name und gatewayRef.namespace übereinstimmt. Wenn Sie mehrere Richtlinien erstellen und unterschiedliche IP-Adressen verwenden möchten, müssen Sie mehrere NetworkGatewayGroup-Objekte erstellen und auf sie verweisen. Wenn Sie mehrere Richtlinien erstellen, muss das Objekt gatewayRef für jede Richtlinie eindeutig sein.

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.

Hinweis: Mit Anthos Network Gateway können Sie keine neuen Gateway-Objekte erstellen, die IP-Adressen in spec.floatingIPs enthalten, die bereits in vorhandenen Gateway-Objekten verwendet werden. Diese Regel wird in Google Distributed Cloud Version 1.15.0 und höher durch einen Webhook erzwungen.

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

1. 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
   

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

   kind: EgressNATPolicy
   apiVersion: networking.gke.io/v1
   metadata:
     name: egresspolicy1
   spec:
     ...
     gatewayRef:
       name: gateway1
       namespace: kube-system
   ---
   kind: EgressNATPolicy
   apiVersion: networking.gke.io/v1
   metadata:
     name: egresspolicy2
   spec:
     ...
     gatewayRef:
       name: gateway2
       namespace: kube-system
   ---
   kind: EgressNATPolicy
   apiVersion: networking.gke.io/v1
   metadata:
     name: egresspolicy3
   spec:
     ...
     gatewayRef:
       name: gateway3
       namespace: kube-system
   

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

NetworkGatewayGroup-Ressourcen unterstützen Knotenselektoren. Um eine Teilmenge von Knoten anzugeben, die für das Hosting einer Floating-IP-Adresse berücksichtigt werden, können Sie den Knotenselektor 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"

Der Knotenselektor wird mit Knoten mit dem angegebenen Label abgeglichen. 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 eine Knotenauswahl die Hochverfügbarkeit (High Availability, HA) der Platzierung von Floating-IP-Adressen beeinträchtigen.