Version 1.8. This version is no longer supported. For information about how to upgrade to version 1.9, see Upgrading Anthos on bare metal in the 1.9 documentation. For more information about supported and unsupported versions, see the Version history page in the latest documentation.

Diese Seite wurde von der Cloud Translation API übersetzt.

NAT-Gateway für ausgehenden Traffic für die externe Kommunikation konfigurieren

In diesem Dokument wird beschrieben, wie Sie ein NAT-Gateway für Anthos-Cluster auf Bare Metal einrichten. Dieses Gateway bietet persistentes, deterministisches Routing für den ausgehenden Traffic Ihrer Cluster. 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 wie Richtlinien auf die Zulassungsliste setzen. Die Funktion kann in der Vorschau kostenlos genutzt werden.

Das NAT-Gateway für ausgehenden Traffic wird mit zwei benutzerdefinierten Ressourcen aktiviert. Für einen bestimmten Namespace gibt die benutzerdefinierte Ressource AnthosNetworkGateway 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.

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

Der Anthos Network Gateway-Controller ist eine gebündelte Komponente von Anthos-Clustern auf Bare Metal. Der Controller 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. Das Anthos Network Gateway stellt eine Floating-IP-Adresse jederzeit und auf Best-Effort-Basis zur Verfügung. Wenn ein Knoten mit einer Floating-IP-Adresse ausfällt, wird die zugewiesene IP-Adresse vom Anthos Netzwerk Gateway 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 zum Anthos Network Gateway (Annotation und Spezifikation) in die Clusterkonfigurationsdatei ein, wenn Sie einen neuen 1.8.0-Cluster erstellen.

Benutzerdefinierte `AnthosNetworkGateway`-Ressource erstellen

Sie aktivieren das Anthos Network Gateway mithilfe der Annotation baremetal.cluster.gke.io/enable-anthos-network-gateway in der Clusterkonfigurationsdatei, wenn Sie einen Cluster erstellen. Legen Sie die Annotation wie im folgenden Beispiel auf true fest:

apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  annotations:
    baremetal.cluster.gke.io/enable-anthos-network-gateway: "true"
  name: cluster1
  namespace: cluster-cluster1

Legen Sie beim Erstellen der benutzerdefinierten Ressource AnthosNetworkGateway als Namespace den Cluster-Namespace fest und geben Sie eine Liste der Floating-IP-Adressen an, wie im folgenden Beispiel gezeigt:

kind: AnthosNetworkGateway
apiVersion: networking.gke.io/v1alpha1
metadata:
  namespace: cluster-cluster1
  name: default
spec:
  floatingIPs:
  - 192.168.1.100
  - 192.168.1.101
  - 192.168.1.102

Die Anzahl der angegebenen Floating-IP-Adressen wirkt sich auf die Zuverlässigkeit des Clusters aus. Beispielsweise funktioniert ein NAT-Gateway für ausgehenden Traffic nur mit einer angegebenen Floating-IP-Adresse, ein Knotenfehler kann jedoch zu Trafficunterbrechungen führen. Wenn Sie weitere Floating-IP-Adressen hinzufügen, weist AnthosNetworkGateway diese nach Bedarf zu und verschiebt sie. Es wird empfohlen, mindestens zwei Floating-IP-Adressen pro L2-Domain anzugeben, die im Cluster verwendet wird.

Der Controller weist Knoten auf der Grundlage der folgenden Kriterien die Floating-IP-Adressen zu:

Knotensubnetz: Die Floating-IP-Adresse muss mit dem Knotensubnetz übereinstimmen.
Knotenrolle (Master, Worker): Worker-Knoten haben beim Zuweisen von Floating-IP-Adressen Vorrang vor Masterknoten.
Vorhandensein einer Floating-IP-Adresse: Der Controller 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 AnthosNetworkGateway abrufen. Beachten Sie, dass sich das Objekt AnthosNetworkGateway im kube-system-Namespace befindet. Wenn ein Gateway-Knoten ausfällt, weist der Controller von AnthosNetworkGateway die Floating-IP-Adressen 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 AnthosNetworkGateway prüfen und feststellen, wie die Floating-IP-Adressen zugewiesen werden:

kubectl -n kube-system get anthosnetworkgateway.networking.gke.io default -oyaml

Die Antwort für einen Cluster mit den beiden Knoten worker1 und worker2 könnte so aussehen:

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
status:
  nodes:
    worker1: Up
    worker2: Up // Or Down
  floatingIPs:
    192.168.1.100: worker1
    192.168.1.101: worker2
    192.168.1.102: worker1

Verwenden Sie den folgenden Befehl, um den Status AnthosNetworkGateway und die Adresszuweisung für einen bestimmten Knoten abzurufen.
```
kubectl -n kube-system get anthosnetworkgatewaynode.networking.gke.io NODE_NAME -oyaml
```
Ersetzen Sie NODE_NAME durch den Namen des spezifischen Knotens/Computers, den Sie untersuchen möchten.

Auswahlregeln für Traffic 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 angeben

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 Bereich 8.8.8.0/24.

kind: EgressNATPolicy
apiVersion: networking.gke.io/v1alpha1
metadata:
  name: egress
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

Weitere Informationen zur Verwendung von Labels finden Sie in der Kubernetes-Dokumentation unter Labels und Selektoren.

Quell-IP-Adresse für ausgehenden Traffic angeben

Geben Sie im Feld egressSourceIP die Quell-IP-Adresse an, die Sie verwenden möchten. Die Quell-IP-Adresse muss mit einer der Floating-IP-Adressen übereinstimmen, die in der benutzerdefinierten Ressource AnthosNetworkGateway angegeben sind.

Wenn Sie EgressNATPolicy-Beispiel aus dem vorherigen Abschnitt verwenden und die Kriterien für Pod-Auswahl und Ziel-IP-Adresse erfüllt sind, wird ausgehender Traffic vom Pod mit SNAT in 192.168.1.100 übersetzt.

Damit die Route akzeptiert wird, muss sich die egressSourceIP-Adresse im selben Subnetz wie die Gateway-Knoten-IP befinden. Wenn die Adresse egressSourceIP dem Gateway-Knoten nicht bekannt (nicht zugewiesen) ist, kann die Weiterleitungsanfrage nicht ausgeführt werden. In diesem Fall erhalten Sie bei den Kubernetes-Ereignissen den Fehler UnknownEgressIP.

Verwenden Sie den folgenden kubectl-Befehl, um die Ereignisse für das EgressNATPolicy-Objekt zu drucken:

kubectl describe EgressNATPolicy egress

Wenn mehrere EgressNATPolicy-CRs vorhanden sind, muss jede eine andere egressSourceIP-Adresse haben. Stimmen Sie sich mit dem Entwicklungsteam ab, um Konflikte zu vermeiden.

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 L2-Domain mit Knoten-IP-Adressen für diese Vorschau 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.