NAT-Gateway für ausgehenden Traffic konfigurieren

10

Version 1.10 

• Version 1.28 (neueste)
• Version 1.16
• Version 1.15
• Frühere Versionen (nicht unterstützt)

Vorschau

Dieses Produkt oder diese Funktion unterliegt den „Nutzungsbedingungen für Pre-GA-Angebote“ im Abschnitt „Allgemeine Nutzungsbedingungen“ der dienstspezifischen Nutzungsbedingungen. Pre-GA-Produkte und -Funktionen sind unverändert verfügbar und werden möglicherweise nur eingeschränkt unterstützt. Weitere Informationen finden Sie in den Beschreibungen der Startphase.

Mit Anthos-Cluster auf VMware (GKE On-Prem) können Sie 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.

Eine Einschränkung in Anthos-Cluster auf VMware für diese Version besteht darin, dass nur die NetworkGatewayGroup mit dem Namen default im Namespace kube-system für Floating-IP-Zuweisungen abgeglichen wird. Darüber hinaus meldet nur die standardmäßige NetworkGatewayGroup den Zuweisungsstatus für alle Floating-IP-Adressen.

Wenn Sie mehrere NetworkGatewayGroup-Objekte erstellen, müssen Sie daher darauf achten, dass die IP-Adressen in den nicht standardmäßigen Objekten auch im Standard-NetworkGatewayGroup-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 NetworkGatewayGroup-Objekte ein:

1. Prüfen Sie das standardmäßige NetworkGatewayGroup-Objekt (name: default) mit kubectl, um den Zuweisungsstatus der Floating-IP-Adressen abzurufen:

   kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get networkgatewaygroup --name default --output 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
   

2. Nachdem Sie den Status der standardmäßigen NetworkGatewayGroup geprüft haben, erstellen Sie zusätzliche NetworkGatewayGroup-Objekte im Namespace kube-system, um jede Floating-IP-Adresse zu "verfolgen".

   Beachten Sie, dass diese neuen Objekte nicht den Zuweisungsstatus melden, der sich in der NetworkGatewayGroup default 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
   

3. Erstellen Sie mehrere Richtlinien, die auf die "sekundären" NetworkGatewayGroup-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