Sie können Antrea-Gruppen erstellen und als Quellen oder Ziele in Richtlinien für verteilte Firewalls verwenden, um den Datenverkehr zwischen Pods innerhalb eines Antrea-Kubernetes-Clusters zu schützen.
Die Funktion für Antrea-Gruppen wird nur unterstützt, wenn in Ihrer NSX-Umgebung einer oder mehrere Antrea-Kubernetes-Cluster registriert sind. Wenn registrierte Antrea-Kubernetes-Cluster erkannt werden, zeigt NSX Manager auf der Seite Gruppe hinzufügen der Benutzeroberfläche einen separaten Gruppentyp mit dem Namen Antrea an. Sie müssen diesen Gruppentyp auswählen, um Antrea-Gruppen hinzuzufügen.
Wenn Sie den Datenverkehr zwischen Antrea-Kubernetes-Clustern und VMs im NSX-Overlay-Netzwerk schützen möchten, müssen Sie Gruppen vom Typ Generisch mit Kubernetes-Mitgliedstypen in dynamischen Mitgliedschaftskriterien erstellen und diese Gruppen in Firewallregeln verwenden. Weitere Informationen finden Sie unter Generische Gruppen mit Kubernetes-Mitgliedstypen in dynamischen Mitgliedschaftskriterien.
Eine Antrea-Gruppe kann statische IP-Adressen, Mitgliedschaftskriterien oder beides enthalten. IP-Adressen können Pod- oder Dienst-IP-Adressen sein.
Wenn eine Antrea-Gruppe Mitgliedschaftskriterien enthält, können die effektiven Mitglieder, die anhand dieser Mitgliedschaftskriterien berechnet werden, nur Pods sein.
- Effektive Mitglieder werden für Antrea-Gruppen nur berechnet, wenn die Antrea-Gruppen in Regeln für verteilte Firewalls verwendet werden.
Wenn Sie Antrea-Gruppen mit Mitgliedschaftskriterien hinzufügen, diese Gruppen jedoch in keiner der Regeln für verteilte Firewalls verwenden, werden die effektiven Mitglieder dieser Antrea-Gruppen in NSX nicht berechnet oder ausgewertet. Mit anderen Worten: Die Seite Effektive Mitglieder dieser Antrea-Gruppen ist leer.
- Wenn Sie statische IP-Adressen in Antrea-Gruppen hinzufügen, werden effektive Mitglieder derzeit nicht auf der Benutzeroberfläche angezeigt, unabhängig davon, ob die Gruppen in Regeln für verteilte Firewalls verwendet werden.
- Namespace
- Dienst
- Pod
Übersicht über Mitgliedschaftskriterien
- Mitgliedstyp
- Entweder der Name des Mitgliedstyps oder ein Tag, das mit dem Mitgliedstyp verbunden ist
- Tag-Operator und -Wert (nur bei Verwendung des Tags)
- Bereichsoperator und -wert (nur bei Verwendung des Tags)
Standardmäßig verwendet NSX den logischen Operator UND nach jeder Bedingung in einem Mitgliedschaftskriterium. Andere logische Operatoren werden zur Verknüpfung von Bedingungen in einem Mitgliedschaftskriterium nicht unterstützt.
- Beispiele:
-
Mitgliedschaftskriterien Beschreibung Kriterium 1:
Pod-Tag gleich App-Geltungsbereich gleich Servern
Das Mitgliedschaftskriterium besteht nur aus einer einzelnen Bedingung, die auf dem Pod basiert. Mehrere Bedingungen werden nicht verwendet. Zu den effektiven Mitgliedern dieser Antrea-Gruppe gehören alle Pods mit dem App-Tag.
Kriterium 2:
Pod-Tag gleich App-Geltungsbereich gleich Servern
Pod-Tag gleich DB-Geltungsbereich gleich Servern
Pod-Tag gleich Webbereich gleich Servern
Das Mitgliedschaftskriterium besteht aus drei Bedingungen. Alle Bedingungen im Kriterium basieren auf dem Pod. Zu den effektiven Mitgliedern dieser Antrea-Gruppe gehören alle Pods mit den Tags „App“, „DB“ und „Web“.
Kriterium 3:
Namespace-Name gleich Produktion
Dienstname gleich Cache
Das Mitgliedschaftskriterium besteht aus zwei Bedingungen mit einer Kombination aus Namespace und Dienst. Zu den effektiven Mitgliedern dieser Antrea-Gruppe gehören alle Pods, die dem Cache-Dienst im Produktions-Namespace zugeordnet sind.
Verknüpfen von Mitgliedschaftskriterien mit ODER- und UND-Operatoren
- Beide Kriterien verwenden denselben Mitgliedstyp.
- beide Kriterien eine einzelne Bedingung verwenden.
- Beispiele:
-
- Kriterium 1, Kriterium 2 und Kriterium 3 basieren alle auf dem Pod und enthalten nicht mehrere Bedingungen. In diesem Fall können Kriterium 1 und Kriterium 2 mit dem Operator ODER oder UND verknüpft werden. Ebenso können Kriterium 2 und Kriterium 3 auch mit dem Operator ODER oder UND verknüpft werden.
- Kriterium 1 basiert auf dem Pod, während Kriterium 2 zwei Bedingungen verwendet: eine, die auf dem Dienst basiert und die andere, die auf dem Namespace basiert. In diesem Fall wird nur der Operator ODER zur Verknüpfung der Kriterien 1 und 2 unterstützt. Der UND-Operator ist nicht zulässig.
- Kriterium 1 und Kriterium 2 basieren auf dem Pod, während Kriterium 3 zwei Bedingungen verwendet: eine, die auf dem Dienst basiert und die andere, die auf dem Namespace basiert. In diesem Fall können Kriterium 1 und Kriterium 2 mit dem Operator UND oder ODER verknüpft werden. Kriterium 2 und Kriterium 3 können jedoch nur mit dem Operator ODER verknüpft werden. Der UND-Operator ist nicht zulässig.
Unterstützte und nicht unterstützte Funktionen
Mitgliedstyp | Objektattribut | Tag-Operator | Geltungsbereichsoperator | Beispielkriterien |
---|---|---|---|---|
Namespace |
Name |
Gleich |
Nicht anwendbar |
Namespace-Name gleich Produktion |
Namespace |
Tag |
Gleich Ungleich |
Gleich |
Namespace-Tag gleich DB-Geltungsbereich gleich Servern |
Dienst |
Name |
Nicht unterstützt |
Nicht unterstützt |
Dienstname gleich Cache |
Pod |
Tag |
Gleich Ungleich |
Gleich |
Pod-Tag gleich App-Geltungsbereich gleich Servern |
- Die folgenden Tag-Operatoren werden derzeit für Namespace- und Pod-Mitgliedstypen nicht unterstützt:
- Enthält
- Beginnt mit
- Endet mit
- In einem Mitgliedschaftskriterium muss eine Bedingung, die auf dem Dienst basiert, mit einer Bedingung basierend auf dem Attribut „Name“ des Namespaces kombiniert werden. Mit anderen Worten: Ein Kriterium, das nur den Mitgliedstyp „Dienst“ enthält, ist nicht zulässig.
- In einem Mitgliedschaftskriterium kann eine Bedingung, die auf dem Dienst basiert, nicht mit einer Bedingung kombiniert werden, die auf dem Pod basiert. Sie können jedoch auf Dienst und Pod basierende Bedingungen zu zwei separaten Mitgliedschaftskriterien hinzufügen und mit dem Operator ODER verknüpfen.
- Für das statische Hinzufügen von Mitgliedern zu einer Antrea-Gruppe werden nur IP-Adressen unterstützt. Namespace, Pod und Dienst können nicht statisch als Mitglieder zu einer Antrea-Gruppe hinzugefügt werden.
- Wenn Sie eine NSX-Gruppe hinzufügen, zeigt eine Informationsmeldung an, wenn Sie versuchen, den Gruppentyp von Antrea in Allgemein oder von Antrea in Nur IP-AdressenAntrea zu ändern. Beim Bestätigen der Änderung gehen alle Mitgliedschaftskriterien in der Gruppe verloren. Nur die IP-Adressen werden in der Gruppe beibehalten.
Nachdem eine Antrea-Gruppe in NSX realisiert (gespeichert) wurde, können Sie den Gruppentyp nicht mehr ändern. Die Gruppentypen Allgemein und Nur IP-Adressen werden abgeblendet.
Problemumgehung für Kubernetes-Version ≤ 1.20
Das Antrea-Gruppenkriterium „Namespace-Name ist gleich Wert“ funktioniert mit Kubernetes-Version ≥ 1.21.
Kubernetes 1.21 oder höher fügt allen Namespaces automatisch eine spezielle Bezeichnung hinzu, und das Kriterium „Namespace-Name ist gleich Wert“ verwendet intern diese spezielle Bezeichnung. Für Kubernetes-Version ≤ 1.20 ist jedoch eine Problemumgehung erforderlich. Sie müssen den Antrea-Controller-Webhook auf dem Namespace registrieren, der Ereignisse erstellt. Wenn der Antrea-Controller-Webhook aufgerufen wird, fügt Antrea-Controller dem neuen Namespace eine spezielle Bezeichnung hinzu, sodass das Kriterium „Namespace-Name ist gleich Wert“ diese Bezeichnung verwenden kann. Weitere Informationen zum Registrieren des Antrea-Controller-Webhooks finden Sie in Schritt 3 in Übermitteln der YAML-Dateien an den Kubernetes-API-Server.
kube-system
und
default
erhalten die spezielle Bezeichnung nicht. Das Kriterium „Namespace-Name ist gleich
Wert“ funktioniert nicht mit diesen Namespaces.