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.
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.1in einem Knoten mit der IP-Adresse192.168.1.1generiert.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.1des ausgehenden Traffics, mit der in der benutzerdefinierten RessourceEgressNATPolicyangegebenen Quell-IP-Adresse192.168.1.100.Der Rücktraffic wird mit dem Ziel
192.168.1.100an 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.1um.10.10.10.1wird 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
AnthosNetworkGatewayprüfen und feststellen, wie die Floating-IP-Adressen zugewiesen werden:kubectl -n kube-system get anthosnetworkgateway.networking.gke.io default -oyamlDie Antwort für einen Cluster mit den beiden Knoten
worker1undworker2kö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: worker1Verwenden Sie den folgenden Befehl, um den Status
AnthosNetworkGatewayund die Adresszuweisung für einen bestimmten Knoten abzurufen.kubectl -n kube-system get anthosnetworkgatewaynode.networking.gke.io NODE_NAME -oyamlErsetzen 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
egresseine oder mehrere Regeln zur Auswahl des ausgehenden Traffics an.- Jede Regel besteht aus einem
podSelectorund einemnamespaceSelector. - 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.
- Jede Regel besteht aus einem
Geben Sie im Abschnitt
destinationCIDRszulässige Zieladressen an.destinationCIDRsenthä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: frontendgekennzeichnet. - Der Pod befindet sich in einem Namespace mit dem Label
user: aliceoderuser: 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.