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.

Diese Funktion erfordert eine Antrea-NSX-Interworking-Version, die für VMware Container Networking™ with Antrea™ 1.6.0 oder höher verfügbar ist. Weitere Informationen finden Sie in den Versionshinweisen zu  1.6.0.

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