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.
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.
Das Paket entspricht einer Regel für ausgehenden Traffic, sodass das Paket an den Gateway-Knoten weitergeleitet wird.
Der Gateway-Knoten ändert die Quell-IP-Adresse in 192.168.1.100 und sendet das Paket aus dem Cluster.
Der Rücktraffic kehrt zum Gateway-Knoten mit dem Ziel 192.168.1.100 zurück.
Der Gateway-Knoten verwendet Conntrack, um die Ziel-IP-Adresse in 10.10.10.1 zu ändern.
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 Labeluser: alice
.Der Pod hat das Label
role: frontend
und der Pod befindet sich in einem Namespace mit dem Labeluser: 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.