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.
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.
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:
|
Ressourcenbedingung mit Cluster-Geltungsbereich |
Bedingungen in den dynamischen Mitgliedschaftskriterien basieren auf einem der folgenden Kubernetes-Mitgliedstypen:
|
Ressourcenbedingung mit Namespace-Geltungsbereich |
Bedingungen in den dynamischen Mitgliedschaftskriterien basieren auf einem der folgenden Kubernetes-Mitgliedstypen:
|
Ü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.
- Beide Kriterien verwenden denselben Kubernetes-Mitgliedstyp.
- beide Kriterien eine einzelne Bedingung verwenden.
- 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 |
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 |