Sie können generische Gruppen mit Kubernetes-Mitgliedstypen in dynamischen Mitgliedschaftskriterien erstellen, um den eingehenden oder ausgehenden Datenverkehr von Antrea-Kubernetes-Clustern abzugleichen.

Sie können diese generischen Gruppen dann in Regeln für verteilte Firewalls oder in Gateway-Firewallregeln verwenden, um den Datenverkehr zwischen VMs in der NSX-Umgebung und Pods in Antrea-Kubernetes-Clustern zu schützen.

Wichtig: In einer NSX-Umgebung mit mehreren Mandanten werden Kubernetes-Cluster-Ressourcen nicht für die Projektbestandsliste verfügbar machen. Daher können Sie innerhalb eines Projekts keine generischen Gruppen mit Kubernetes-Mitgliedstypen in dynamischen Mitgliedschaftskriterien erstellen. Sie müssen die Gruppen in der Ansicht Standard (Standardspeicher) von NSX erstellen und diese dann in den Regeln für verteilte Firewalls oder in Gateway-Firewallregeln unter dem Standardspeicher verwenden.

Voraussetzungen

  • Antrea-Kubernetes-Cluster sind in NSX registriert.
  • Wenden Sie eine geeignete Sicherheitslizenz in Ihrer NSX-Bereitstellung an, die das System berechtigt, Sicherheitsrichtlinien für verteilte Firewalls zu konfigurieren.

Schützen des Datenverkehrs von Antrea-Kubernetes-Clustern zu VMs in NSX

Um den Datenverkehr von Antrea-Kubernetes-Clustern mit NSX abzugleichen, können Sie in den Firewallregeln generische Gruppen hinzufügen, die auf den folgenden Kubernetes-Mitgliedstypen (Ressourcen) basieren:
  • Kubernetes-Knoten
  • Antrea-Egress
  • Antrea-IP-Pool

Das folgende Diagramm zeigt die typischen Datenverkehrsflüsse vom Antrea-Kubernetes-Cluster zu den VMs im logischen NSX-Netzwerk.


Das Bild wird im umgebenden Text erläutert.

Wie in diesem Datenverkehrsflussdiagramm dargestellt, sind für den Abgleich des Datenverkehrs, der den Antrea-Kubernetes-Cluster verlässt, folgende Szenarien möglich:

Szenario 1: SNAT über Egress (Gateway-Knoten)

Sie können eine Egress-Ressource in Ihrem Antrea-Kubernetes-Cluster bereitstellen. Wählen Sie in der Manifestdatei der Egress-Ressource die Gruppierungskriterien von Pods aus, für die die Egress-Ressource gilt. Sie können die Egress-IP entweder manuell in der Manifestdatei angeben oder die Antrea-CNI kann eine Egress-IP aus einer benutzerdefinierten ExternalIPPool-Ressource zuteilen.

Wichtig: Die Egress-IP-Adressen müssen im physischen Netzwerk geroutet werden können und von allen Knoten im Kubernetes-Cluster erreichbar sein.

Die Antrea-CNI sendet den ausgehenden Datenverkehr der ausgewählten Pods an die Gateway-Knoten. Die Gateway-Knoten führen eine Quelladressübersetzung (Source Address Translation, SNAT) durch, um die Quell-IP (Pod-IP) in die Egress-IP zu übersetzen.

Im vorherigen Datenverkehrsflussdiagramm wird beispielsweise der ausgehende Datenverkehr von pod1 und pod2, die auf node1 ausgeführt werden, an die Gateway-Knoten gesendet. Der Gateway-Knoten übersetzt die Pod-IP-Adressen in egress1-IP-Adressen.

Weitere Informationen zur Egress-Ressource finden Sie im Egress-Handbuch im Antrea-Dokumentationsportal.

Welche Clusterknoten als Gateway-Knoten verwendet werden können, hängt von der Knotennetzwerktopologie ab, die von Ihrem physischen Netzwerkadministrator oder dem IaaS-Netzwerkadministrator gesteuert wird. Die Gateway-Knoten weisen die beiden folgenden Merkmale auf:
  • Das physische Netzwerk erlaubt den Knoten den Zugriff auf das externe Netzwerk über eine routingfähige IP als Quell-IP.
  • Optional wird auf dem physischen Gateway eine physische Firewall so konfiguriert, dass ausgehender Datenverkehr von den Gateway-Knoten gefiltert wird.
Beachten Sie die folgenden Beispiele:
  • Beispiel 1: Angenommen, Ihr Antrea-Kubernetes-Cluster verfügt über drei Knoten: node1, node2 und node3. Angenommen, node1 und node2 im Cluster sind spezielle Knoten, da ihnen zwei Netzwerkschnittstellen zugewiesen sind. Eine Schnittstelle für die K8s-Clusterkommunikation und eine weitere Schnittstelle für die Verbindung mit dem externen Netzwerk. node3 wird nur eine Netzwerkschnittstelle für die Cluster-Kommunikation zugewiesen. In diesem Szenario können nur Knoten1 und Knoten2 als Gateway-Knoten verwendet werden.
  • Beispiel 2: Angenommen, allen drei Knoten im K8s-Cluster ist nur eine Netzwerkschnittstelle zugewiesen und der Netzwerkadministrator hat die physische Firewall so konfiguriert, dass nur node1- und node2-MAC-Adressen auf das Internet zugreifen können. In diesem Szenario können Knoten1 und Knoten2 als Gateway-Knoten verwendet werden.
  • Beispiel 3: Angenommen, alle drei Knoten können auf das Internet zugreifen. Der Netzwerkadministrator hat eine physische Firewall auf dem physischen Gateway konfiguriert, und die Firewall möchte Datenverkehr von einer bestimmten Egress-IP filtern. In diesem Szenario können alle drei Knoten als Gateway-Knoten verwendet werden.

Der folgende Absatz erläutert eine implementierungsspezifische Einschränkung:

Alle physischen Hosts oder eine VM, der sich außerhalb des Antrea-Kubernetes-Clusters befindet, können nicht als Gateway-Knoten für das Tunneln des ausgehenden Datenverkehrs des Pods verwendet werden. Der Grund ist, dass Antrea-Agent die Egress-IP-Adressen beibehält und dieser Agent auf allen Knoten des K8s-Clusters als Pod ausgeführt wird. Daher müssen der physische Host oder eine VM, die Sie als Gateway-Knoten verwenden möchten, Teil des K8s-Clusters sein.

Szenario 2: SNAT über Knoten

In diesem Szenario werden Pods nicht explizit in der Manifestdatei einer Egress-Ressource ausgewählt.

Der ausgehende Datenverkehr des Pods wird für die Knoten-IP maskiert. Anschließend wird der Datenverkehr an das IaaS-Netzwerk gesendet. Beispiel: Im vorherigen Datenverkehrsflussdiagramm übersetzt eine SNAT-Regel die Quell-IP (pod3-IP, pod4-IP) in die node2-IP-Adresse. Anschließend wird der ausgehende Datenverkehr des Pods an das IaaS-Netzwerk gesendet.

Szenario 3: Routingfähige Pods, die direkt mit dem IaaS-Netzwerk überbrückt werden

Pods sind routingfähig, wenn ihnen im Underlay-Netzwerk routingfähige IP-Adressen zugewiesen werden. In der Regel werden Pods private IP-Adressen aus der Eigenschaft „PodCIDR“ zugewiesen, die auf dem Knoten konfiguriert ist. Wenn Pods auf ein Netzwerk zugreifen möchten, das sich außerhalb des K8s-Clusters befindet, ist für den Datenverkehr ein SNAT-Vorgang erforderlich, der die Quell-IP (Pod-IP) in eine routingfähige IP übersetzt.

Wenn Ihr Antrea-Kubernetes-Cluster auf dem NSX-Overlay-Netzwerk mit dem Tanzu Kubernetes Grid-Dienst (TKGS) bereitgestellt wird, gibt es einen Mechanismus, mit dem die Tanzu Kubernetes-Clusterknoten (TKC-Knoten) routingfähige Subnetze von NSX anfordern und dann ein routingfähiges Subnetz als PodCIDR-Eigenschaft des Knotens verwenden können. Anschließend können die Pods routingfähige IP-Adressen abrufen. Weitere Informationen zum Konfigurieren des TKC mit einem Netzwerk mit routingfähigen Pods finden Sie in der Dokumentation zu VMware vSphere with Tanzu.

Wenn Ihr Antrea-Kubernetes-Cluster nicht im NSX-Overlay-Netzwerk bereitgestellt ist, kann der Kubernetes-Administrator sicherstellen, dass im Underlay-Netzwerk ein routingfähiges Subnetz oder ein routingfähiger IP-Bereich reserviert sind. Der Administrator kann das Subnetz oder einen IP-Bereich in der Manifestdatei der benutzerdefinierten IPPool-Ressource konfigurieren. Anschließend kann die Antrea-CNI den Pods routingfähige IP-Adressen zuteilen.

Im vorherigen Datenverkehrsflussdiagramm erhält beispielsweise pod5, der auf node5 ausgeführt wird, eine routingfähige IP-Adresse aus einer benutzerdefinierten IPPool-Ressource.

Weitere Informationen zur benutzerdefinierten IPPool-Ressource finden Sie im Antrea IPAM-Handbuch im Antrea-Dokumentationsportal.

Schützen des Datenverkehrs von VMs in NSX zu Antrea-Kubernetes-Clustern

Um den Datenverkehr von NSX zu Antrea-Kubernetes-Clustern abzugleichen, können Sie in den Firewallregeln generische Gruppen hinzufügen, die auf den folgenden Kubernetes-Mitgliedstypen (Ressourcen) basieren:
  • Kubernetes-Dienst
  • Kubernetes-Ingress
  • Kubernetes-Gateway
  • Antrea-IP-Pool

Das folgende Diagramm zeigt die typischen Datenverkehrsflüsse von VMs im logischen NSX-Netzwerk zum Antrea-Kubernetes-Cluster.


Das Bild wird im umgebenden Text beschrieben.

Wie in diesem Datenverkehrsflussdiagramm dargestellt, sind für den Abgleich des Datenverkehrs, der im Antrea-Kubernetes-Cluster eingeht, folgende Szenarien möglich:

Szenario 1: Pods für externen Datenverkehr werden über virtuelle IP und Ports verfügbar gemacht
Sie können Pods für externen Datenverkehr verfügbar machen, indem Sie eine Load Balancer-Lösung eines Drittanbieters mit folgenden nativen Kubernetes-Ressourcen implementieren:
  • Ingress: Er funktioniert als Load Balancer der Schicht 7. Eine Ingress-Ressource stellt eine virtuelle IP-Adresse (VIP) bereit und macht einige Ports (TCP/UDP) verfügbar.
  • Gateway: Er funktioniert als Load Balancer der Schichten 4 und 7. Eine Gateway-Ressource stellt eine VIP bereit und macht einige Ports (TCP/UDP) verfügbar.
  • Dienst vom Typ „LoadBalancer“: Er funktioniert wie ein Load Balancer der Schicht 4. Der Dienst stellt eine VIP bereit und macht einige Ports (TCP/UDP) verfügbar.
Hinweis: Obwohl Ingress- und Gateway-Ressourcen als Load Balancer auf Schicht 7 funktionieren können, werden sie für Regeln für verteilte Firewalls und für Gateway-Firewallregeln in NSX als Load Balancer der Schichten 3 oder 4 angezeigt, indem IP-Adressen und Ports verwendet werden, die dem eingehenden Datenverkehr entsprechen.
Szenario 2: Pods für externen Datenverkehr werden über Knoten-IP und Ports verfügbar gemacht
  • Kubernetes-Dienst vom Typ „NodePort“: Er löst auf allen Knoten im K8s-Cluster aus, dass auf dem Knoten ein Port für jeden Dienstport geöffnet wird. Der Dienst ist über die Knoten-IP und den Port erreichbar. Der Knoten führt für den Datenverkehr SNAT und DNAT aus.
  • Kubernetes-Dienst vom Typ „ClusterIP“ mit aktivierter NodePortLocal-Funktion: Sie müssen die NodePortLocal-Funktion auf dem Antrea-Agent aktivieren und in der Manifestdatei des Kubernetes-Diensts eine Anmerkung hinzufügen. Die Antrea-CNI erkennt die Anmerkung und öffnet einen Port für jeden Pod auf dem Knoten, auf dem der Pod ausgeführt wird. NodePortlLocal vermeidet, dass auf allen Knoten des K8s-Clusters ein Port geöffnet wird, und spart dadurch verfügbare Portbereiche ein. Außerdem wird ein SNAT-Vorgang vermieden und die ursprüngliche Client-IP wird beibehalten.

    Weitere Informationen zur Funktion „NodePortLocal“ finden Sie im NodePortLocal-Handbuch im Antrea-Dokumentationsportal.

Szenario 3: Pods für externen Datenverkehr werden über routingfähige Pod-IP-Adressen verfügbar gemacht

Antrea unterstützt die Zuweisung routingfähiger IP-Adressen zu Pods durch Bereitstellung der benutzerdefinierten IPPool-Ressource in Ihrem Antrea-Kubernetes-Cluster. Den Pods werden IP-Adressen aus diesem Pool zugewiesen und sie werden direkt zum IaaS-Netzwerk überbrückt.

Unterstützte IaaS-Netzwerke

Antrea-Kubernetes-Cluster können auf folgenden IaaS-Plattformen bereitgestellt werden:
  • vSphere-basiertes lokales Datencenter: Wie Tanzu Kubernetes-Cluster, die mit dem Tanzu Kubernetes Grid-Dienst erstellt werden. Die Cluster werden von Tanzu Kubernetes Grid (TKG) 2.0 und vSphere verwaltet.
  • VMware Cloud: Als Tanzu Kubernetes-Cluster, die von TKG 2.0 und VMC-SDDC verwaltet werden.
  • Public Clouds: als verwaltete Kubernetes-Cluster auf den Public Cloud-Plattformen.
  • Physische Server: Als Kubernetes-Cluster auf Bare Metal-Servern.
  • OpenShift:
    • Die in OpenShift-Clustern bereitgestellte Antrea-CNI und OpenShift werden im IPI-Modus (Installer Provisioned Infrastructure) oder im UPI-Modus (User Provisioned Infrastructure) bereitgestellt.
    • Folgende Infrastrukturanbieter sind möglich: vSphere, Amazon Web Services (AWS), Azure, OpenStack, Google Cloud Platform (GCP), Bare Metal.
Wichtig: Das IaaS-Netzwerk ist für den Datenverkehr zwischen Antrea-Kubernetes-Clustern und VMs zuständig. Für den Datenverkehr zwischen verschiedenen Sites, z. B. lokalen Datencentern, VMware Cloud und Public Cloud, kann ein IaaS-spezifisches VPN genutzt werden. In allen Fällen können vom IaaS-Netzwerk SNAT-Vorgänge angewendet werden. Der NSX-Administrator muss sicherstellen, dass die Quell- oder Ziel-IP-Adressen routingfähig sind. Damit können sie in Firewallregeln zum Schutz des Datenverkehrs zwischen VMs und Kubernetes-Clustern verwendet werden.

Empfohlene Vorgehensweisen zum Anwenden von Firewallrichtlinien

Sowohl die verteilte Firewall als auch die Gateway-Firewall ermöglichen in den Quellen und Zielen der Firewallregeln die Angabe generischer Gruppen mit Kubernetes-Mitgliedstypen. Sie können daher flexibel entscheiden, ob Sie die Gruppen in der verteilten Firewall oder in der Gateway-Firewall referenzieren möchten.

VMware bietet die folgende Empfehlung:
  • Verwenden Sie die NSX-Gateway-Firewall, um Datenverkehr von Antrea-Kubernetes-Clustern zu VMs in einem NSX-Netzwerk zuzulassen oder zu blockieren.

    Mit diesem Ansatz können Sie den Datenverkehr zum frühestmöglichen Zeitpunkt zu filtern, wenn er in das NSX-Overlay-Netzwerk eingeht.

  • Verwenden Sie die verteilte NSX-Firewall, um in einem NSX-Netzwerk Datenverkehr von VMs zu Antrea-Kubernetes-Clustern zuzulassen oder zu blockieren.

    Mit diesem Ansatz können Sie den Datenverkehr zum frühestmöglichen Zeitpunkt zu filtern, wenn er die VMs in einem NSX-Overlay-Netzwerk verlässt.

Übersicht der Kubernetes-Mitgliedstypen für die Nutzung in Firewallrichtlinien

Die folgende Tabelle enthält die Kubernetes-Mitgliedstypen, die Sie in generischen NSX-Gruppen für den Abgleich des Datenverkehrs in Firewallregeln verwenden können.

Mitgliedstyp Geltungsbereich Verwendung in Firewallrichtlinie

Kubernetes-Cluster

Cluster

Wird als UND-Bedingung in dynamischen Gruppenkriterien eingesetzt, um Ressourcen von bestimmten Clustern abzugleichen.

Kubernetes-Namespace

Namespace

 Wird als UND-Bedingung in den dynamischen Gruppenkriterien eingesetzt, um Ressourcen aus bestimmten Namespaces abzugleichen.

Antrea-Egress

Cluster

Abgleichen des ausgehenden Datenverkehrs von Antrea-Kubernetes-Clustern, bei denen Quell-IP = Egress-IP
Antrea-IP-Pool

Cluster

Abgleichen des ausgehenden Datenverkehrs von Antrea-Kubernetes-Clustern, bei denen sich die Quell-IP in IP-Bereichen befindet.

Abgleichen des eingehenden Datenverkehrs von Antrea-Kubernetes-Clustern, bei denen sich die Ziel-IP in IP-Bereichen befindet.

Kubernetes-Knoten

Cluster

Abgleichen des ausgehenden Datenverkehrs von Antrea-Kubernetes-Clustern, bei denen die Quell-IP zu den IP-Adressen des Clusterknotens gehört.

Kubernetes-Ingress

Namespace

Abgleichen des eingehenden Datenverkehrs von Antrea-Kubernetes-Clustern, bei denen die Ziel-IP zu den Ingress-IP-Adressen gehört.

Kubernetes-Gateway

Namespace

Abgleichen des eingehenden Datenverkehrs von Antrea-Kubernetes-Clustern, bei denen die Ziel-IP zu den Gateway-IP-Adressen gehört.

Kubernetes-Dienst (type=LoadBalancer)

Namespace

Abgleichen des eingehenden Datenverkehrs von Antrea-Kubernetes-Clustern, bei denen die Ziel-IP zu den LoadBalancer-IP-Adressen gehört.

Kubernetes-Dienst (type=NodePort)

Namespace

Abgleichen des eingehenden Datenverkehrs von Antrea-Kubernetes-Clustern, bei denen Ziel-IP + Port zu Knoten-IP-Adressen + NodePort-Bereich gehört.

Kubernetes-Dienst (type=ClusterIP)

Namespace

Keine

Kubernetes-Dienst (type=ClusterIP) und NodePortLocal-Funktion aktiviert

Namespace

Abgleichen des eingehenden Datenverkehrs von Antrea-Kubernetes-Clustern, bei denen Ziel-IP + Port zu Knoten-IP-Adressen + NodePortLocal-Bereich gehört.