Generische Gruppen mit Kubernetes-Mitgliedstypen in dynamischen Mitgliedschaftskriterien

Sie können Gruppen mit Kubernetes-Mitgliedstypen (Ressourcen) 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.

In dieser Dokumentation wird mit dem Ausdruck „Kubernetes-Mitgliedstypen“ auf „Kubernetes-Ressourcen“ verwiesen, die Sie zum Konfigurieren dynamischer Mitgliedschaftskriterien verwenden können.

Derzeit unterstützen generische Gruppen mit Kubernetes-Mitgliedstypen ausschließlich dynamische Mitgliedschaftskriterien. Kubernetes-Mitgliedstypen können in einer generischen Gruppendefinition nicht statisch hinzugefügt werden.

Hinweis: Für die Bewertung der effektiven Mitglieder einer generischen Gruppe, die dynamische Mitgliedschaftskriterien enthält, die mithilfe von Kubernetes-Mitgliedstypen definiert wurden, wird die NSX-Ressourcenbestandsliste berücksichtigt, die von Kubernetes-Clustern mit Antrea-CNI gemeldet wird. Die Ressourcenbestandsliste, die von Kubernetes-Clustern mit NCP-CNI gemeldet wird, wird bei der Bewertung der effektiven Gruppenmitglieder ignoriert.

Kubernetes-Mitgliedstypen in Mitgliedschaftskriterien

In einer generischen Gruppe sind Kubernetes-Mitgliedstypen nur dann auf der Seite Mitgliedschaftskriterien verfügbar, wenn in Ihrer NSX-Umgebung mindestens ein Antrea-Kubernetes-Cluster registriert ist.

Hinweis: 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.

Die folgende Tabelle enthält die Kubernetes-Mitgliedstypen, die in der Ansicht Standard von NSX 4.1 verfügbar sind, um dynamische Mitgliedschaftskriterien zu einer generischen Gruppe hinzuzufügen. Jeder Kubernetes-Mitgliedstyp gehört entweder zum Cluster-Geltungsbereich oder zum Namespace-Geltungsbereich.

Mitgliedstyp	Geltungsbereich
Kubernetes-Cluster	Cluster
Kubernetes-Namespace	Namespace
Kubernetes-Knoten	Cluster
Kubernetes-Dienst	Namespace
Kubernetes-Ingress	Namespace
Kubernetes-Gateway	Namespace
Antrea-Egress	Cluster
Antrea-IP-Pool	Cluster

Benennungskonventionen für Bedingungen mit Kubernetes-Mitgliedstypen

Die folgende Tabelle erläutert die Benennungskonventionen, die in dieser Dokumentation verwendet werden, um die verschiedenen Bedingungen darzustellen, die Sie in dynamischen Mitgliedschaftskriterien hinzufügen können, die auf Kubernetes-Mitgliedstypen basieren.

Benennungskonvention für Bedingung	Bedeutung
Kubernetes-Cluster-Bedingung	Bedingungen in den dynamischen Mitgliedschaftskriterien basieren auf dem Kubernetes-Cluster-Mitgliedstyp.
Kubernetes-Namespace-Bedingung	Bedingungen in den dynamischen Mitgliedschaftskriterien basieren auf dem Kubernetes-Namespace-Mitgliedstyp.
Ressourcenbedingung	Bedingungen in den dynamischen Mitgliedschaftskriterium basieren auf einem der folgenden Kubernetes-Mitgliedstypen: Kubernetes-Dienst Kubernetes-Ingress Kubernetes-Gateway Antrea-Egress Antrea-IP-Pool Kubernetes-Knoten
Ressourcenbedingung mit Cluster-Geltungsbereich	Bedingungen in den dynamischen Mitgliedschaftskriterien basieren auf einem der folgenden Kubernetes-Mitgliedstypen: Antrea-Egress Antrea-IP-Pool Kubernetes-Knoten
Ressourcenbedingung mit Namespace-Geltungsbereich	Bedingungen in den dynamischen Mitgliedschaftskriterien basieren auf einem der folgenden Kubernetes-Mitgliedstypen: Kubernetes-Dienst Kubernetes-Ingress Kubernetes-Gateway

Übersicht über Mitgliedschaftskriterien bei Kubernetes-Mitgliedstypen

Ein Kriterium kann eine oder mehrere Bedingungen enthalten. Die Bedingungen können denselben Kubernetes-Mitgliedstyp oder eine Kombination aus verschiedenen Kubernetes-Mitgliedstypen verwenden. Es gelten allerdings einige Einschränkungen für das Hinzufügen mehrerer Bedingungen mit gemischten Mitgliedstypen zu einem Mitgliedschaftskriterium. Weitere Informationen finden Sie weiter unten in dieser Dokumentation im Abschnitt Einschränkungen für die Verwendung von Kubernetes-Mitgliedstypen in einem Kriterium.

Standardmäßig verwendet NSX den logischen Operator UND nach jeder Bedingung in einem Mitgliedschaftskriterium. Andere logische Operatoren werden zur Verknüpfung der Bedingungen in einem Mitgliedschaftskriterium nicht unterstützt.

Um Kriterien zu verknüpfen, sind die Operatoren ODER und UND verfügbar. Standardmäßig wählt NSX den Operator ODER aus, um zwei Kriterien zu verknüpfen. Der Operator UND wird nur zwischen zwei Kriterien unterstützt, wenn:

• Beide Kriterien verwenden denselben Kubernetes-Mitgliedstyp.
• beide Kriterien eine einzelne Bedingung verwenden.

Die folgenden Einschränkungen gelten für das Hinzufügen mehrerer Bedingungen:

• In einem einzelnen Mitgliedschaftskriterium werden maximal fünf Bedingungen mit demselben Kubernetes-Mitgliedstyp unterstützt. In einem Kriterium können Sie beispielsweise maximal fünf Kubernetes-Dienstbedingungen hinzufügen.
• In einem einzelnen Mitgliedschaftskriterium werden maximal 15 Bedingungen mit gemischten Kubernetes-Mitgliedstypen unterstützt. Beispielsweise können Sie in einem Kriterium maximal 15 Bedingungen mit einer Kombination aus Kubernetes-Namespace-Bedingungen und Kubernetes-Ingress-Bedingungen hinzufügen.
• In einer generischen Gruppe werden maximal 35 Bedingungen mit gemischten Mitgliedstypen unterstützt.

Eine Gruppe kann maximal fünf Mitgliedschaftskriterien aufweisen. Die Gesamtanzahl der Kriterien, die Sie in einer generischen Gruppe hinzufügen können, wird jedoch durch die Anzahl der Bedingungen in jedem Kriterium bestimmt. Nachfolgend finden Sie Beispiele.

Beispiel 1

Eine generische Gruppe mit drei Mitgliedschaftskriterien und insgesamt 35 Bedingungen:

• Kriterium 1 hat 15 Bedingungen mit gemischten Mitgliedstypen.
• Kriterium 2 hat 15 Bedingungen mit gemischten Mitgliedstypen.
• Kriterium 3 hat 5 Bedingungen mit demselben Mitgliedstyp.

Beispiel 2

Eine generische Gruppe mit vier Mitgliedschaftskriterien und insgesamt 35 Bedingungen:

• Kriterium 1 hat 15 Bedingungen mit gemischten Mitgliedstypen.
• Kriterium 2 hat 14 Bedingungen mit gemischten Mitgliedstypen.
• Kriterium 3 hat vier Bedingungen mit demselben Mitgliedstyp.
• Kriterium 4 hat zwei Bedingungen mit demselben Mitgliedstyp.

Beispiel 3

Eine generische Gruppe mit fünf Mitgliedschaftskriterien und insgesamt 22 Bedingungen:

• Kriterium 1 hat 10 Bedingungen mit gemischten Mitgliedstypen.
• Kriterium 2 hat drei Bedingungen mit demselben Mitgliedstyp.
• Kriterium 3 hat vier Bedingungen mit demselben Mitgliedstyp.
• Kriterium 4 hat drei Bedingungen mit demselben Mitgliedstyp.
• Kriterium 5 hat zwei Bedingungen mit gemischten Mitgliedstypen.

Da diese Gruppe den Grenzwert von fünf Kriterien erreicht hat, können Sie kein weiteres Mitgliedschaftskriterium hinzufügen. Sie können jedoch bei Bedarf weitere Bedingungen zu einem der fünf Kriterien hinzufügen, solange Sie die oben genannten Obergrenzen nicht überschreiten:

• Maximal fünf Bedingungen mit demselben Mitgliedstyp in einem einzelnen Kriterium.
• Maximal 15 Bedingungen mit gemischten Mitgliedstypen in einem einzelnen Kriterium.
• Insgesamt 35 Bedingungen in der generischen Gruppe.

Einschränkungen für die Verwendung von Kubernetes-Mitgliedstypen in einem Kriterium

Die folgende Tabelle enthält eine allgemeine Übersicht der Einschränkungen oder Validierungen, die für die Verwendung von Kubernetes-Mitgliedstypen in einem einzelnen Mitgliedschaftskriterium gelten. Beispiele für Validierungen finden Sie weiter unten in dieser Dokumentation im Abschnitt Validierungen für die dynamische Gruppierung mit Kubernetes-Mitgliedstypen.

Mitgliedstyp	Einschränkungen für die Verwendung des Mitgliedstyps in einem Kriterium	Unterstützte Attribute	Tag-Operator	Geltungsbereichsoperator
Kubernetes-Cluster	Kann nicht alleine in einem Kriterium verwendet werden. In einem Kriterium ist nur eine Cluster-Bedingung zulässig. Muss mit mindestens einer Kubernetes-Ressourcenbedingung kombiniert werden. Kann optional mit Kubernetes-Namespace-Bedingungen und Kubernetes-Ressourcenbedingungen kombiniert werden.	Name	Nicht unterstützt	Nicht unterstützt
Kubernetes-Namespace	Kann nicht alleine in einem Kriterium verwendet werden. Kann nicht mit Ressourcenbedingungen mit Cluster-Geltungsbereich kombiniert werden. Muss mit Ressourcenbedingungen mit Namespace-Geltungsbereich kombiniert werden. Kann optional mit einer Kubernetes-Cluster-Bedingung kombiniert werden.	Name Tag	Gleich – Ein Tag kann ausgewählt werden	Gleich
Antrea-Egress	Kann alleine in einem Kriterium verwendet werden. Kann optional mit einer Kubernetes-Cluster-Bedingung kombiniert werden.	Name Tag	Gleich – Ein Tag kann ausgewählt werden	Gleich
Antrea-IP-Pool	Kann alleine in einem Kriterium verwendet werden. Kann optional mit einer Kubernetes-Cluster-Bedingung kombiniert werden.	Name Tag	Gleich – Ein Tag kann ausgewählt werden	Gleich
Kubernetes-Ingress	Kann alleine in einem Kriterium verwendet werden. Kann optional entweder nur mit Kubernetes-Namespace-Bedingungen oder nur mit einer Kubernetes-Cluster-Bedingung oder mit beiden kombiniert werden.	Name Tag	Gleich – Ein Tag kann ausgewählt werden	Gleich
Kubernetes-Gateway	Kann alleine in einem Kriterium verwendet werden. Kann optional entweder nur mit Kubernetes-Namespace-Bedingungen oder nur mit einer Kubernetes-Cluster-Bedingung oder mit beiden kombiniert werden.	Name Tag	Gleich – Ein Tag kann ausgewählt werden	Gleich
Kubernetes-Dienst	Kann alleine in einem Kriterium verwendet werden. Kann optional entweder nur mit Kubernetes-Namespace-Bedingungen oder nur mit einer Kubernetes-Cluster-Bedingung oder mit beiden kombiniert werden.	Name Tag	Gleich – Ein Tag kann ausgewählt werden	Gleich
Kubernetes-Knoten	Kann alleine in einem Kriterium verwendet werden. Es ist nur eine einzelne Knotenbedingung zulässig. Kann optional mit einer Kubernetes-Cluster-Bedingung kombiniert werden. Kann nicht mit Kubernetes-Namespace-Bedingungen oder Kubernetes-Ressourcenbedingungen kombiniert werden.	IP-Adresse Pod-CIDR	Nicht unterstützt Weitere Informationen finden Sie im Hinweis unter der Tabelle.	Nicht unterstützt

Hinweis: Wenn Sie eine generische Gruppe mit Kubernetes-Knoten-Mitgliedstyp mithilfe der API erstellen, ist nur der Operator „Stimmt überein“ zulässig. Dieser Operator darf ausschließlich den Wert „*“ annehmen. Das Platzhalterzeichen „*“ stimmt mit allen Knoten im Kubernetes-Cluster überein (wenn die Kubernetes-Knoten-Bedingung mit einer Kubernetes-Cluster-Bedingung kombiniert ist) oder es stimmt mit Knoten in allen Clustern überein (wenn nur die Kubernetes-Knotenbedingung verwendet wird).

Validierungen für die dynamische Gruppierung mit Kubernetes-Mitgliedstypen

Validierung 1

Ein Mitgliedschaftskriterium kann maximal eine Kubernetes-Cluster-Bedingung aufweisen. Um einen einzelnen Kubernetes-Cluster nach Name abzugleichen, verwenden Sie den Operator „Gleich“ und geben Sie den Clusternamen ein.

Hinweis: Der Kubernetes-Clustername muss eindeutig sein.

Wenn Sie in einer einzelnen Kubernetes-Cluster-Bedingung mehrere Cluster abgleichen möchten, können Sie einen der folgenden Operatoren verwenden:

• Eingehend
• Beginnt mit
• Endet mit

Beispiel:

Entspricht einem einzelnen Kubernetes-Cluster	Entspricht mehreren Kubernetes-Clustern
Kriterium: Kubernetes Cluster Name Equals ClusterA	Kriterium: Kubernetes Cluster Name In ClusterA,ClusterB,ClusterC Maximal fünf kommagetrennte Werte sind zulässig. Zwischen den Werten dürfen keine Leerzeichen eingefügt werden.

Validierung 2

Ein Mitgliedschaftskriterium mit einer Kubernetes-Cluster-Bedingung kann mit einer der Kubernetes-Ressourcenbedingungen kombiniert werden. Wenn Sie auch Kubernetes-Namespace-Bedingungen in demselben Kriterium hinzufügen, müssen Ressourcenbedingungen auf den Namespace-Geltungsbereich beschränkt werden.

Beispiele:

• Ein Mitgliedschaftskriterium mit einer Kubernetes-Cluster-Bedingung und drei Kubernetes-Ingress-Bedingungen ist gültig.
• Ein Mitgliedschaftskriterium mit einer Kubernetes-Cluster-Bedingung und zwei Antrea-Egress-Bedingungen ist gültig.
• Ein Mitgliedschaftskriterium mit einer Kubernetes-Cluster-Bedingung und drei Antrea-IP-Pool-Bedingungen ist gültig.
• Ein Mitgliedschaftskriterium mit einer Kubernetes-Clusterbedingung, einer Kubernetes-Namespace-Bedingung und drei Kubernetes-Gateway-Bedingungen ist gültig.

Validierung 3

Ein Mitgliedschaftskriterium muss mindestens eine Kubernetes-Ressourcenbedingung enthalten. Ein Mitgliedschaftskriterium ist ungültig, wenn es Folgendes enthält:

• Nur Kubernetes-Cluster-Bedingung
• Nur Kubernetes-Namespace-Bedingung
• Nur Kubernetes-Cluster-Bedingung und Kubernetes-Namespace-Bedingung

Beispiele:

• Ein Mitgliedschaftskriterium mit einer Kubernetes-Cluster-Bedingung, einer Kubernetes-Namespace-Bedingung und einer Kubernetes-Ingress-Bedingung ist gültig.
• Ein Mitgliedschaftskriterium mit einer Kubernetes-Cluster-Bedingung, zwei Kubernetes-Namespace-Bedingungen und drei Kubernetes-Ingress-Bedingungen ist gültig.

Validierung 4

Ein Mitgliedschaftskriterium darf nur eine Kubernetes-Knoten-Bedingung enthalten. Optional kann eine Kubernetes-Knoten-Bedingung mit nur einer Kubernetes-Cluster-Bedingung kombiniert werden.

Eine Kubernetes-Knoten-Bedingung kann nicht mit Kubernetes-Namespace-Bedingungen oder Kubernetes-Ressourcenbedingungen kombiniert werden.

Ein Mitgliedschaftskriterium mit nur einer Kubernetes-Knotenbedingung kann eigenständig vorhanden sein. Eine Gruppe mit nur einer Kubernetes-Knotenbedingung stimmt jedoch mit Knoten aller Antrea-Kubernetes-Cluster überein, die bei NSX registriert sind.

Tag-Operator und Geltungsbereich-Operator werden für die Kubernetes-Knoten-Bedingung derzeit nicht unterstützt.

Die Kubernetes-Knotenbedingung unterstützt die beiden folgenden Eigenschaften.

Eigenschaft	Beschreibung
IP-Adresse	Entspricht der internen IP-Adresse aller Knoten der angegebenen Antrea-Kubernetes-Cluster.
Pod-CIDR	Entspricht dem Pod-CIDR aller Knoten der angegebenen Antrea-Kubernetes-Cluster.

Validierung 5

Wenn ein Mitgliedschaftskriterium eine Kubernetes-Cluster-Bedingung und Kubernetes-Namespace-Bedingungen enthält, muss es mindestens eine Kubernetes-Ressourcenbedingung mit Namespace-Geltungsbereich enthalten. Sie können keine der folgenden Kubernetes-Ressourcenbedingungen mit Cluster-Geltungsbereich in demselben Kriterium kombinieren:

• Antrea-Egress
• Antrea-IP-Pool
• Kubernetes-Knoten

Beispiele:

• Ein Mitgliedschaftskriterium mit einer Kubernetes-Clusterbedingung, zwei Kubernetes-Namespace-Bedingungen und Kubernetes-Gateway-Bedingungen ist gültig.
• Ein Mitgliedschaftskriterium mit einer Kubernetes-Cluster-Bedingung, vier Kubernetes-Namespace-Bedingungen und drei Kubernetes-Dienstbedingungen ist gültig.
• Ein Mitgliedschaftskriterium mit einer Kubernetes-Cluster-Bedingung, einer Kubernetes-Namespace-Bedingung und einer Antrea-Egress-Bedingung ist ungültig, da Antrea-Egress eine Ressource im Cluster-Geltungsbereich ist.

Validierung 6

Ein Mitgliedschaftskriterium muss mindestens eine Kubernetes-Ressourcenbedingung enthalten. Eine Ressourcenbedingung kann in einem Kriterium eigenständig vorhanden sein. Wenn Sie jedoch mehrere Ressourcenbedingungen in einem Kriterium hinzufügen, müssen alle Ressourcenbedingungen denselben Mitgliedstyp aufweisen.

Hinweis: Die Kubernetes-Cluster-Bedingung und die Kubernetes-Namespace-Bedingungen werden zum Definieren des Geltungsbereichs eines Kriteriums verwendet. Es handelt sich nicht um Kubernetes-Ressourcenbedingungen. Daher sind sie nicht durch diese Validierungsregel eingeschränkt.

Beispiele:

• Ein Mitgliedschaftskriterium mit fünf Kubernetes-Dienstbedingungen ist gültig.
• Ein Mitgliedschaftskriterium mit einer Kubernetes-Cluster-Bedingung, drei Kubernetes-Namespace-Bedingungen und vier Kubernetes-Dienstbedingungen ist gültig.
• Ein Mitgliedschaftskriterium mit einer Kubernetes-Cluster-Bedingung, drei Kubernetes-Namespace-Bedingungen, vier Kubernetes-Dienstbedingungen und drei Kubernetes-Ingress-Bedingungen ist ungültig. Der Grund dafür ist, dass Sie Ressourcenbedingungen aus zwei verschiedenen Mitgliedstypen (Kubernetes-Dienst und Kubernetes-Ingress) in demselben Kriterium kombiniert haben.

  Sie können jedoch separate Kriterien mit einer Ressourcenbedingung erstellen, die auf einem einzelnen Mitgliedstyp basiert, und dann beide Kriterien mit einem ODER-Operator verbinden, wie unten dargestellt:

  Kriterium 1:

  Eine Kubernetes-Cluster-Bedingung + drei Kubernetes-Namespace-Bedingungen + vier Kubernetes-Dienstbedingungen

  ODER

  Kriterium 2:

  Eine Kubernetes-Cluster-Bedingung + drei Kubernetes-Namespace-Bedingungen + drei Kubernetes-Ingress-Bedingungen

Validierung 7

In einem einzelnen Mitgliedschaftskriterium dürfen Bedingungen, die auf NSX-Mitgliedstypen basieren, nicht mit Bedingungen kombiniert werden, die auf Kubernetes-Mitgliedstypen basieren. Sie können jedoch eine Gruppe mit einem Kriterium besitzen, das ausschließlich auf NSX-Mitgliedstypen basiert, und ein weiteres Kriterium, das ausschließlich auf Kubernetes-Mitgliedstypen basiert, und beide Kriterien mit einem ODER-Operator verknüpfen.

Beispiel:

Gültig	Ungültig
Kriterium 1: VM-Bedingungen ODER Kriterium 2: Kubernetes-Cluster-Bedingung + Kubernetes-Gateway-Bedingungen	Kriterium: NSX-Segmentbedingung + Segmentportbedingung AND Kubernetes-Cluster-Bedingung + Kubernetes-Gateway-Bedingungen

Effektive Mitglieder für Bedingungen mit Kubernetes-Mitgliedstypen

Aus der Perspektive von NSX sind die effektiven Mitglieder für Gruppen mit Kubernetes-Mitgliedstypen entweder diskrete IP-Adressen, IP-Bereiche oder eine Liste von IP-Adressen und Ports.

Die folgende Tabelle zeigt einige Beispiele.

Beispiel für Gruppendefinition	Anwendungsfall	Beschreibung	Effektive Mitglieder
Kubernetes-Cluster-Bedingung AND Kubernetes-Knotenbedingung (basierend auf der IP-Adresse)	Datenverkehr vom Antrea-Kubernetes-Cluster zu NSX	Entspricht allen Knoten-IP-Adressen in den angegebenen Clustern	IP-Adressen
Kubernetes-Cluster-Bedingung AND Kubernetes-Knotenbedingung (basierend auf dem Pod-CIDR)	Datenverkehr vom Antrea-Kubernetes-Cluster zu NSX	Entspricht den Pod-CIDRs aller Knoten in den angegebenen Clustern	Pod-CIDRs
Kubernetes-Cluster-Bedingung AND Antrea-Egress-Bedingung (basierend auf dem Namen)	Datenverkehr vom Antrea-Kubernetes-Cluster zu NSX	Entspricht Egress nach Name in den angegebenen Clustern	Egress-IP-Adressen
Kubernetes-Cluster-Bedingung AND Antrea-Egress-Bedingung (basierend auf Tag) AND Weitere Antrea-Egress-Bedingungen (basierend auf Tag)	Datenverkehr vom Antrea-Kubernetes-Cluster zu NSX	Entspricht Egress nach Tags in den angegebenen Clustern.	Egress-IP-Adressen
Kubernetes-Cluster-Bedingung AND Antrea-IP-Pool-Bedingung (basierend auf dem Namen)	Datenverkehr vom Antrea-Kubernetes-Cluster zu NSX Datenverkehr von NSX zum Antrea-Kubernetes-Cluster	Entspricht dem IP-Pool nach Name in den angegebenen Clustern	IP-Bereiche
Kubernetes-Cluster-Bedingung AND Antrea-IP-Pool-Bedingung (basierend auf Tag) AND Weitere Antrea-IP-Pool-Bedingungen (basierend auf Tags)	Datenverkehr vom Antrea-Kubernetes-Cluster zu NSX Datenverkehr von NSX zum Antrea-Kubernetes-Cluster	Entspricht IP-Pools nach Tags in angegebenen Clustern	IP-Bereiche
Kubernetes-Cluster-Bedingung AND Kubernetes-Namespace-Bedingung AND Kubernetes-Ingress-Bedingung (basierend auf dem Namen)	Datenverkehr von NSX zum Antrea-Kubernetes-Cluster	Entspricht Ingress nach Name in angegebenen Clustern und im Namespace	Ingress-IP-Adressen
Kubernetes-Cluster-Bedingung AND Kubernetes-Namespace-Bedingung AND Kubernetes-Gateway-Bedingung (basierend auf dem Namen)	Datenverkehr von NSX zum Antrea-Kubernetes-Cluster	Entspricht Gateway nach Name in angegebenen Clustern und im Namespace	Gateway-IP-Adressen
Kubernetes-Cluster-Bedingung AND Kubernetes-Namespace-Bedingung AND Kubernetes-Ingress-Bedingung (basierend auf Tag) AND Weitere Kubernetes-Ingress-Bedingungen (basierend auf Tags)	Datenverkehr von NSX zum Antrea-Kubernetes-Cluster	Entspricht Ingress nach Tags in angegebenen Clustern und im Namespace	Ingress-IP-Adressen
Kubernetes-Cluster-Bedingung AND Kubernetes-Namespace-Bedingung AND Kubernetes-Gateway-Bedingung (basierend auf Tag) AND Weitere Kubernetes-Gateway-Bedingungen (basierend auf Tags)	Datenverkehr von NSX zum Antrea-Kubernetes-Cluster	Entspricht Gateway nach Tags in angegebenen Clustern und im Namespace	Gateway-IP-Adressen
Kubernetes-Cluster-Bedingung AND Kubernetes-Namespace-Bedingung AND Kubernetes-Dienstbedingung (basierend auf Tag und type=LoadBalancer) AND Kubernetes-Dienstbedingungen (basierend auf Tags und type=LoadBalancer)	Datenverkehr von NSX zum Antrea-Kubernetes-Cluster	Entspricht dem Dienst (LoadBalancer) nach Tags in angegebenen Clustern und im Namespace	LoadBalancer-Ingress-IP-Adressen
Kubernetes-Cluster-Bedingung AND Kubernetes-Namespace-Bedingung AND Kubernetes-Dienstbedingung (basierend auf Name, type=ClusterIP und aktivierter NodePortLocal-Funktion)	Datenverkehr von NSX zum Antrea-Kubernetes-Cluster	Entspricht Dienst (ClusterIP mit aktiviertem NodePortLocal) nach Name in angegebenen Clustern und im Namespace.	Knoten-IP-Adressen, NodePortLocal-Bereich