NAT-Gateway für ausgehenden Traffic konfigurieren

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.

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.

Anthos Network Gateway aktivieren

Dieser Abschnitt richtet sich an Clusteradministratoren.

Erstellen Sie einen neuen Nutzercluster mit aktiviertem Anthos Network Gateway.

Legen Sie in der Konfigurationsdatei für Nutzercluster enableDataplaneV2 und enableAnthosNetworkGateway auf true fest.

enableDataplaneV2: true
...
enableAnthosNetworkGateway: 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 Anthos Network Gateway 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.

AnthosNetworkGateway-Objekt erstellen

Dieser Abschnitt richtet sich an Clusteradministratoren.

Hier ist ein Beispiel für ein Manifest für ein AnthosNetworkGateway-Objekt:

kind: AnthosNetworkGateway
apiVersion: networking.gke.io/v1alpha1
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-ang.yaml.

Erstellen Sie das AnthosNetworkGateway-Objekt:

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG apply -f my-ang.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
metadata:
  name: alice-paul
spec:
  egress:
  - namespaceSelector:
      matchLabels:
        user: alice
    podSelector:
      matchLabels:
        role: frontend
  - namespaceSelector:
      matchLabels:
        user: paul
    podSelector:
      matchLabels:
        role: frontend
  destinationCIDRs:
  - 8.8.8.0/24
  egressSourceIP: 192.168.1.100

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.

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

Bekannte Probleme

Doppelte egressSourceIP-Adressen

Wenn Sie ein EgressNATGateway-Objekt erstellen, könnten Sie eine egressSourceIP-Adresse angeben, die bereits für ein anderes EgressNATPolicy-Objekt verwendet wird. Dies führt zu Konflikten beim Routing von ausgehendem Traffic. Erkundigen Sie sich bei Ihrem Entwicklungsteam, welche Floating-IP-Adressen verfügbar sind, bevor Sie die egressSourceIP-Adresse angeben.

Änderungen an benutzerdefinierten Ressourcen

Änderungen an benutzerdefinierten EgresNATPolicy-Ressourcen werden nicht in benutzerdefinierte Cilium-Ressourcen übernommen.