Konvertieren von Kubernetes-Netzwerkrichtlinien in NSX-Richtlinien für verteilte Firewalls

Der Antrea-NSX-Adapter synchronisiert die Kubernetes-Netzwerkrichtlinien der registrierten Antrea-Kubernetes-Cluster mit der NSX-Bestandsliste. Diese K8s-Netzwerkrichtlinien können jedoch nicht in der NSX-Umgebung aktualisiert oder verwaltet werden.

Wenn Sie die K8s-Netzwerkrichtlinien in NSX bearbeiten möchten, können Sie sie in Ihre NSX-Umgebung importieren. Diese Importfunktion ist ab NSX 4.2 verfügbar und wird nur über die NSX-API unterstützt.

Übersicht über das Importieren von K8s-Netzwerkrichtlinien

Der Importvorgang konvertiert die K8s-Netzwerkrichtlinien in NSX DFW-Richtlinien (Verteilte Firewall) mit entsprechendem Datenverkehrsverhalten. Nachdem die K8s-Netzwerkrichtlinien in NSX DFW-Richtlinien konvertiert wurden, wird NSX zur Wahrheitsquelle für die Verwaltung der konvertierten DFW-Richtlinien. Sie können die DFW-Richtlinien dann bearbeiten, entweder über die NSX Manager-Benutzeroberfläche oder über die NSX-API.

Bei dieser Konvertierung handelt es sich um einen unidirektionalen Vorgang. Sie können die NSX DFW-Richtlinien nicht zurück in K8s-Netzwerkrichtlinien konvertieren.

Wichtig: Wenn Ihre NSX-Bestandsliste Kubernetes-Netzwerkrichtlinien enthält, die vom NSX Container Plugin (NCP) verwaltet werden, wird die Importfunktion nicht unterstützt. Die K8s-Netzwerkrichtlinien, die Sie in NSX importieren möchten, müssen von der Antrea-CNI verwaltet werden.

Jede importierte K8s-Netzwerkrichtlinie wird in eine oder zwei NSX DFW-Richtlinien konvertiert. Eine DFW-Richtlinie enthält alle Zulassungsregeln (wenn Ingress- oder Egress-Regeln in der K8s-Netzwerkrichtlinie vorhanden sind) und die andere DFW-Richtlinie enthält die Standardregel zum Verwerfen des Datenverkehrs. Die DFW-Richtlinie mit der standardmäßigen Verwerfungsregel wird immer generiert.

Das System legt den Umfang (Geltungsbereich) der NSX DFW-Richtlinie auf dem Antrea Kubernetes-Cluster fest. Darüber hinaus ist der Geltungsbereich der DFW-Richtlinie weiter auf jene Antrea-Gruppe beschränkt, welche die effektiven Pod-Mitglieder des Kubernetes-Namespace enthält.

Die konvertierten DFW-Richtlinien werden in der Anwendungsebene von NSX platziert. Die Import-API hängt die konvertierten DFW-Richtlinien an andere vorhandene Antrea-Richtlinien in der Anwendungsebene an. Die importierten Richtlinien werden nach vorhandenen Antrea-Richtlinien in NSX erzwungen, aber bevor die Antrea-Cluster-Netzwerkrichtlinien (ACNP) und Antrea-Netzwerkrichtlinien (ANP) erzwungen werden, die nativ im Kubernetes-Cluster definiert werden. Das ursprüngliche Datenverkehrsverhalten innerhalb des K8s-Namespace wird nach der Konvertierung in NSX DFW-Richtlinien beibehalten.

Die Antrea-CNI realisiert die konvertierten DFW-Richtlinien als Antrea-Cluster-Netzwerkrichtlinien im Kubernetes-Cluster. Diese Netzwerkrichtlinien des Antrea-Clusters werden jetzt von NSX verwaltet und können nur in der NSX-Umgebung bearbeitet werden. Wenn Sie versuchen, die ACNP-Konfiguration mithilfe der kubectl-Befehlszeile zu bearbeiten, überschreibt der Antrea-NSX-Adapter die ACNP-Änderungen an der ursprünglichen Richtliniendefinition, wie sie in NSX vorhanden ist, oder setzt sie zurück.

Nachdem die K8s-Netzwerkrichtlinien erfolgreich in NSX importiert wurden, löscht das System automatisch die ursprünglichen Kubernetes-Netzwerkrichtlinien aus der K8s-Bestandsliste. Das System kennzeichnet auch die konvertierten DFW-Richtlinien mit dem Namen des K8s-Clusters, der ursprünglichen K8s-Netzwerkrichtlinie und dem K8s-Namespace. Diese Tags können Ihnen dabei helfen, die konvertierten DFW-Richtlinien in der Benutzeroberfläche von NSX Manager zu durchsuchen. Alternativ können Sie den Befehl kubectl get acnp -o wide in der kubectl-Befehlszeile ausführen, um die Tags (also Bezeichnungen in K8s) im entsprechenden realisierten ACNP anzuzeigen.

Voraussetzungen für den Import von K8s-Netzwerkrichtlinien

Der Antrea-Kubernetes-Cluster muss bei NSX 4.2 oder höher registriert sein.
Die Importfunktion erfordert eine Antrea-NSX Interworking-Version, die für VMware Container Networking™ with Antrea™ 1.9.0 oder höher verfügbar ist.
Wenden Sie eine geeignete Sicherheitslizenz in Ihrer NSX-Bereitstellung an, die das System berechtigt, Sicherheitsrichtlinien für verteilte Firewalls zu konfigurieren.
Ihnen wird entweder die Rolle „Enterprise-Administrator“ oder die Rolle „Sicherheitsadministrator“ im Standardspeicher Ihrer NSX-Umgebung zugewiesen.
Stellen Sie sicher, dass der Antrea-NSX-Adapter die Kubernetes-Netzwerkrichtlinien erfolgreich an die NSX-Bestandsliste gemeldet hat.
Führen Sie beispielsweise die folgenden Schritte aus, um dies auf der Benutzeroberfläche von NSX Manager zu überprüfen:
1. Navigieren Sie zu Bestandsliste > Container > Namespaces.
2. Filtern Sie bei Bedarf die Liste der Namespaces nach dem CNI-Typ Antrea.
3. Erweitern Sie einen Namespace und klicken Sie dann auf die Anzahl der Netzwerkrichtlinien, um zu überprüfen, ob die Kubernetes-Netzwerkrichtlinien mit der NSX-Bestandsliste synchronisiert wurden.
  Um zu überprüfen, ob NSX alle Kubernetes-Netzwerkrichtlinien im Namespace liest, können Sie die Anzahl in der Benutzeroberfläche mit der Anzahl der Richtlinien vergleichen, die mit dem folgenden kubectl-Befehl abgerufen werden. Die Anzahl muss identisch sein.
```
kubectl get networkpolicies -n <namespace>
```

Zuordnen von K8s-Netzwerkrichtlinienfeldern zu Feldern der NSX-Richtlinie für verteilte Firewalls

Wie bereits erläutert, konvertiert das System diese Netzwerkrichtlinie in eine oder zwei DFW-Richtlinien, wenn eine Kubernetes-Netzwerkrichtlinie in NSX importiert wird. Eine DFW-Richtlinie enthält alle Zulassungsregeln und die andere DFW-Richtlinie enthält die standardmäßige Regel zum Verwerfen des Datenverkehrs. Das System erstellt Antrea-Gruppen gemäß der Spezifikation der K8s-Netzwerkrichtlinie. Die Antrea-Gruppen werden in den Feldern Quellen, Ziele und Angewendet auf der konvertierten DFW-Richtlinien verwendet.

In der folgenden Tabelle wird die Zuordnung der Felder in der Kubernetes-Netzwerkrichtlinie zu den Feldern in der NSX-Richtlinie für verteilte Firewalls erläutert.

Feld in K8s-Netzwerkrichtlinie	NSX-Ressource	Beschreibung
Die K8s-Netzwerkrichtlinie an sich	Entweder eine oder zwei DFW-Richtlinien	Alle Regeln in `spec.ingress` oder `spec.egress` der K8s-Netzwerkrichtlinie werden der DFW-Zulassungsrichtlinie hinzugefügt. Das heißt, die Regelaktion für alle Regeln in dieser DFW-Richtlinie ist auf Zulassen festgelegt. Eine DFW-Richtlinie mit einer Standard-Verwerfungsregel wird erstellt, die eine Regel für das Verwerfen von eingehendem Datenverkehr oder ausgehendem Datenverkehr oder ein- und ausgehendem Datenverkehr gemäß den Werten in der `spec.policyTypes`-Liste der K8s-Netzwerkrichtlinie enthält. Wenn beispielsweise die Liste `spec.policyTypes` der K8s-Netzwerkrichtlinienspezifikation nur `egress` enthält, verfügt die DFW-Verwerfungsrichtlinie über eine standardmäßige Verwerfungsregel für ausgehenden Datenverkehr (Datenverkehrsrichtung: Ausgehend). Wenn die Kubernetes-Netzwerkrichtlinie keine Ingress- und Egress-Regeln enthält, wird eine DFW-Richtlinie mit nur der standardmäßigen Drop-Regel erstellt.
`spec.podSelector` und `metadata.namespace`	Gruppe vom Typ Antrea	Sowohl `spec.podSelector` als auch `metadata.namespace` werden zum Konvertieren in eine Antrea-Gruppe verwendet. Auf die erstellte Antrea-Gruppe wird im Bereich Angewendet auf der DFW-Zulassungsrichtlinie und der DFW-Verwerfungsrichtlinie verwiesen. Wenn `spec.podSelector` nicht angegeben ist, enthält die Antrea-Gruppe nur den Namespace.
`spec.ingress[]` und `spec.egress[]`	Firewallregeln in der DFW-Zulassungsrichtlinie	Jede Regel im Abschnitt `spec.ingress` und `spec.egress` der K8s-Netzwerkrichtlinie wird in eine NSX DFW-Regel konvertiert. Diese DFW-Regeln werden der DFW-Zulassungsrichtlinie hinzugefügt.
`spec.ingress[*].from` `podSelector` `namespaceSelector` `ipBlock`	Gruppen vom Typ Antrea	Die Pod- und Namespace-Selektoren im Abschnitt `ingress` `from` werden in Antrea-Gruppen mit dynamischen Mitgliedschaftskriterien konvertiert. Die IP-CIDR-Bereiche in der Auswahl `ipBlock` werden in Mitglieder statischer IP-Adressen in der Antrea-Gruppe konvertiert. Auf diese Antrea-Gruppen wird im Feld Quellen der DFW-Regeln verwiesen.
`spec.egress[*].to` `podSelector` `namespaceSelector` `ipBlock`	Gruppen vom Typ Antrea	Die Pod- und Namespace-Selektoren im Abschnitt `egress` `to` werden in Antrea-Gruppen mit dynamischen Mitgliedschaftskriterien konvertiert. Die IP-CIDR-Bereiche in der Auswahl `ipBlock` werden in Mitglieder statischer IP-Adressen in der Antrea-Gruppe konvertiert. Auf diese Antrea-Gruppen wird im Feld Ziele der DFW-Regeln verwiesen.
`spec.ingress[].ports` `protocol` `port` und `spec.egress[].ports` `protocol` `port`	Diensteinträge in der DFW-Regel	Das Layer-4-Protokoll und der Zielport (einschließlich des Bereichs der Zielports) in der Spezifikation der Ingress- und Egress-Regel der K8s-Netzwerkrichtlinie werden in Diensteinträge der DFW-Regeln konvertiert. Die Zielports oder der Portbereich in der K8s-Regelspezifikation werden immer zielseitigen Ports im Diensteintrag zugeordnet.

Beispiele für Feldzuordnungen

Dieser Abschnitt enthält einige Beispiele, die Ihnen dabei helfen, die Zuordnung der Felder in der Kubernetes-Netzwerkrichtlinie zu den Feldern in der DFW-Richtlinie zu verstehen, wenn eine K8s-Netzwerkrichtlinie in NSX importiert wird.

Beispiel 1

Spezifikation der K8s-Netzwerkrichtlinie:

apiVersion: v1
kind: Namespace
metadata:
  name: my-ns1
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: knp1
  namespace: my-ns1
spec:
  podSelector: {}
  policyTypes:
    - Egress
  egress:
    - to:
        - ipBlock:
            cidr: 8.8.8.8/32
      ports:
        - protocol: UDP
          port: 53

Diese K8s-Netzwerkrichtlinie wählt alle Pods im Namespace „my-ns1“ aus und lässt ausgehenden Datenverkehr (ausgehende Verbindungen) von jedem Pod in diesem Namespace zum 8.8.8.8/32 CIDR auf UDP-Port 53 zu. Der gesamte andere ausgehende Datenverkehr von den Pods in diesem Namespace wird verworfen.

Wenn diese K8s-Netzwerkrichtlinie in NSX importiert wird, werden zwei DFW-Richtlinien erstellt. Eine DFW-Richtlinie enthält eine einzelne Zulassungsregel und die andere DFW-Richtlinie eine einzelne Verwerfungsregel.

Der Abschnitt spec.podSelector wird in eine Antrea-Gruppe mit einem dynamischen Mitgliedschaftskriterium konvertiert. Das Kriterium in der Gruppe wählt alle Pods im Namespace „my-ns1“ aus. Auf diese Antrea-Gruppe wird im Feld Angewendet auf sowohl der DFW-Richtlinie für die Zulassungsrichtlinie als auch der DfW-Verwerfungsrichtlinie verwiesen.

Die Auswahl ipBlock im Abschnitt spec.egress.to wird in eine Antrea-Gruppe mit einem Mitglied der statischen IP-Adresse 8.8.8.8/32 konvertiert. Auf diese Antrea-Gruppe wird im Feld Ziele der DFW-Zulassungsregel verwiesen. Diese Gruppe wird hier als „Group-1“ bezeichnet.

Der Abschnitt spec.egress.ports wird in einen Diensteintrag mit UDP-Protokoll und Zielport 53 konvertiert.

Die Konfiguration der DFW-Zulassungsregel in NSX lautet wie folgt.

Quellen	Ziele	Dienste	Kontextprofile	Regel angewendet auf	Regelaktion	Richtung der Regel
Nicht verfügbar	Group-1	UDP Quelle: Beliebig, Ziel: 53	Nicht verfügbar	Beliebig	Zulassen	Ausgehend

Quellen

Ziele

Dienste

Kontextprofile

Regel angewendet auf

Regelaktion

Richtung der Regel

Nicht verfügbar

Group-1

UDP

Quelle: Beliebig, Ziel: 53

Nicht verfügbar

Beliebig

Zulassen

Ausgehend

Die Konfiguration der DFW-Verwerfungsregel in NSX lautet wie folgt.

Quellen	Ziele	Dienste	Kontextprofile	Regel angewendet auf	Regelaktion	Richtung der Regel
Beliebig	Beliebig	Beliebig	Nicht verfügbar	Beliebig	Verwerfen	Ausgehend

Beispiel 2

Spezifikation der K8s-Netzwerkrichtlinie:

apiVersion: v1
kind: Namespace
metadata:
  name: my-ns2
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: knp2
  namespace: my-ns2
spec:
  podSelector: {}
  policyTypes:
    - Ingress
    - Egress

Diese Kubernetes-Netzwerkrichtlinie wählt alle Pods im Namespace „my-ns2“ aus und verwirft den gesamten eingehenden und ausgehenden Datenverkehr von diesen Pods. Diese Richtlinie verwirft im Grunde genommen allen eingehenden und ausgehenden Datenverkehr für den Namespace.

Wenn diese K8s-Netzwerkrichtlinie in NSX importiert wird, wird nur eine DFW-Verwerfungsrichtlinie erstellt. Die konvertierte DFW-Richtlinie enthält eine einzelne Firewallregel mit Verwerfen-Aktion.

Der Abschnitt spec.podSelector wird in eine Antrea-Gruppe mit einem dynamischen Mitgliedschaftskriterium konvertiert. Das Kriterium in der Gruppe wählt alle Pods im Namespace „my-ns2“ aus. Auf diese Antrea-Gruppe wird im Feld Angewendet auf der DFW-Drop-Richtlinie verwiesen.

Die Konfiguration der DFW-Verwerfungsregel in NSX lautet wie folgt.

Quellen	Ziele	Dienste	Kontextprofile	Regel angewendet auf	Regelaktion	Richtung der Regel
Beliebig	Beliebig	Beliebig	Nicht verfügbar	Beliebig	Verwerfen	In_Out

Benennungskonvention von konvertierten DFW-Richtlinien und Antrea-Gruppen

Das System verwendet die folgende Benennungskonvention für die konvertierten DFW-Richtlinien zum Zulassen und Ablegen:

DFW-Zulassungsrichtlinie: <cluster_name>-<namespace>-<K8s_networkpolicy_name>-<K8s_networkpolicy_uuid>-allow
DfW-Verwerfungsrichtlinie: <cluster_name>-<namespace>-<K8s_networkpolicy_name>-<K8s_networkpolicy_uuid>-drop

Die Werte von cluster_name, namespace und K8s_networkpolicy_name werden auf jeweils 12 Byte gekürzt.

Das System verwendet die folgende Benennungskonvention für die Antrea-Gruppen:

Gruppen, auf die im Feld „Angewendet auf“ der DFW-Zulassungs- und -Verwerfungsrichtlinien verwiesen wird: <cluster_name>-<namespace>-<K8s_networkpolicy_uuid>
Gruppen, auf die im Feld „Quellen“ der DFW-Regeln verwiesen wird: <cluster_name>-<namespace>-<K8s_networkpolicy_uuid>-rule[rule index]-from-<peer index>
Gruppen, auf die im Feld „Ziele“ der DFW-Regeln verwiesen wird: <cluster_name>-<namespace>-<K8s_networkpolicy_uuid>-rule[rule index]-to-<peer index>

Die Werte von cluster_name und namespace werden auf jeweils 12 Byte gekürzt.

Um zu verstehen, wie das System dem Regelindex und dem Peer-Index im Antrea-Gruppennamen Werte zuordnet, betrachten Sie das folgende Beispiel einer K8s-Netzwerkrichtlinie mit drei Ingress-Regeln.

Beispiel

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: knp3
  namespace: my-ns3
spec:
  podSelector: {}
  policyTypes:
    - Ingress
  ingress:
    - from:
        - namespaceSelector:
            matchExpressions:
            - key: namespace
              operator: In
              values: ["test-ns1"]
        - podSelector:
            matchExpressions:
            - key: app
              operator: In
              values: ["nginx"]
      ports:
        - protocol: TCP
          port: 80
    - from:
        - namespaceSelector:
            matchExpressions:
            - key: namespace
              operator: In
              values: [""]
      ports:
        - protocol: TCP
          port: 443
    - from:
        - namespaceSelector:
            matchExpressions:
            - key: namespace
              operator: In
              values: ["test-ns4"]
      ports:
        - protocol: TCP
          port: 8080
          endPort: 8090

Betrachten wir den folgenden Ausschnitt der ersten ingress.from-Regel:

ingress:
    - from:
        - namespaceSelector:
            matchExpressions:
            - key: namespace
              operator: In
              values: ["test-ns1"]
        - podSelector:
            matchExpressions:
            - key: app
              operator: In
              values: ["nginx"]
      ports:
        - protocol: TCP
          port: 80

Der Abschnitt from dieser Ingress-Regel enthält zwei Elemente. Ein Element wählt Pods mithilfe der Namespace-Auswahl aus und das andere Element wählt Pods mithilfe der Pod-Auswahl aus. Wir bezeichnen diese beiden Elemente als Peers.

Das System erstellt eine Antrea-Gruppe für jeden Peer in der Regel. Die konvertierte DFW-Regel hat den Regelindex 0, und diese Regel enthält zwei Antrea-Gruppen im Feld Quellen der Regel. Ein Antrea-Gruppenname hat den Peer-Index 0 und der andere Gruppenname hat wie folgt den Peer-Index 1:

<cluster_name>-my-ns3-knp3-rule[0]-from-0

<cluster_name>-my-ns3-knp3-rule[0]-from-1

Betrachten Sie nun den folgenden Ausschnitt der zweiten und dritten ingress.from-Regeln:

ingress:
    - from:
        - namespaceSelector:
            matchExpressions:
            - key: namespace
              operator: In
              values: [""]
      ports:
        - protocol: TCP
          port: 443
    - from:
        - namespaceSelector:
            matchExpressions:
            - key: namespace
              operator: In
              values: ["test-ns4"]
      ports:
        - protocol: TCP
          port: 8080
          endPort: 8090

Der Abschnitt from in jeder dieser beiden Ingress-Regeln enthält nur ein einzelnes Element, das Pods mithilfe der Namespace-Auswahl auswählt. Die konvertierten DFW-Regeln haben den Regelindex 1 bzw. 2 und jede Regel enthält eine einzelne Antrea-Gruppe im Feld Quellen der Regel. In diesem Fall wird der Peer-Index nicht an die Namen der Antrea-Gruppen angehängt. Die Gruppennamen lauten wie folgt:

<cluster_name>-my-ns3-knp3-rule[1]-from

<cluster_name>-my-ns3-knp3-rule[2]-from

Allgemeiner Import-Workflow mithilfe der API

Stellen Sie sicher, dass die Voraussetzungen für den Import der Kubernetes-Netzwerkrichtlinien erfüllt sind, wie weiter oben in dieser Dokumentation erläutert.
Führen Sie den folgenden kubectl-Befehl aus, um die Liste der Kubernetes-Netzwerkrichtlinien in einem bestimmten Namespace anzuzeigen:
```
kubectl get networkpolicies -n <namespace>
```
Beispiel:
```
kubectl get networkpolicies -n test-ns5

NAME     POD-SELECTOR   AGE
k-np10   app=demo       82m
k-np11   app=myapp      82m
k-np12   app=demo       82m
k-np9    app=myapp      82m
```
In diesem Beispiel enthält der Namespace test-ns5 vier Kubernetes-Netzwerkrichtlinien. Bei diesem Verfahren importieren wir die Richtlinien „k-np9“ und „k-np11“ in NSX.
Führen Sie den folgenden kubectl-Befehl aus, um die ID jeder Kubernetes-Netzwerkrichtlinie abzurufen, die Sie importieren möchten.
```
kubectl get networkpolicies <policy-name> -n <namespace> -o yaml
```
Um beispielsweise die IDs der Netzwerkrichtlinien „k-np9“ und „k-np11“ abzurufen, führen Sie die folgenden Befehle aus:
```
kubectl get networkpolicies k-np9 -n test-ns5 -o yaml
kubectl get networkpolicies k-np11 -n test-ns5 -o yaml
```
Beachten Sie in der Ausgabe beider kubectl-Befehle die ID, die im Feld metadata.uid angezeigt wird. In unserem K8s-Cluster lauten die Richtlinien-IDs wie folgt:
- Für „k-np9“: e5a59ae6-cc0e-42a5-80bd-f6fa13b5b70d
- Für „k-np11“: 84b850fb-69ad-4e95-a563-a95ce6b70557
Diese Richtlinien-IDs dienen nur als Beispiele. Sie können in Ihrem K8s-Cluster anders lauten. Sie benötigen diese Richtlinien-IDs zum Ausführen der Import-API, die im nächsten Schritt erläutert wird.

Führen Sie die folgende NSX-API aus, um die Kubernetes-Netzwerkrichtlinien zu importieren:

Beispiel:

POST https://<nsx-mgr>/policy/api/v1/infra/import-k8s-np-to-dfw?on_error=ABORT  -k
{
    "network_policy_ids" : ["e5a59ae6-cc0e-42a5-80bd-f6fa13b5b70d", "84b850fb-69ad-4e95-a563-a95ce6b70557"],
    "sequence_number_upper" : 1000,
    "sequence_number_lower" : 2000
}

Der Parameter network_policy_ids ist obligatorisch, während die Parameter sequence_number_upper und sequence_number_lower optional sind.

In diesem Beispiel werden die IDs der K8s-Netzwerkrichtlinien („k-np9“ und „k-np11“) für den Import in NSX angegeben.

Detaillierte Informationen zu diesen Anforderungsparametern, der API-Beispielanforderung und der API-Beispielantwort finden Sie im Handbuch zu NSX-API.

Der Abfrageparameter on_error bestimmt die durch die API durchzuführende Aktion, wenn ein Fehler auftritt. In der folgenden Tabelle werden die gültigen Werte dieses Abfrageparameters erläutert.

Wert	Beschreibung
ABBRECHEN	Dieser Wert ist die Standardoption. Wenn beim Importieren der K8s-Netzwerkrichtlinien ein Fehler auftritt, verhindert das System, dass alle konvertierten DFW-Richtlinien und Antrea-Gruppen übernommen werden. Der Importvorgang wird vorzeitig beendet und keine der K8s-Netzwerkrichtlinien wird konvertiert. Die API-Antwort gibt die Fehlermeldung für jede K8s-Netzwerkrichtlinie zurück, die zu einem Fehler geführt hat. Beispiel: Angenommen, Sie haben UUIDs von zwei K8s-Netzwerkrichtlinien im API-Anforderungstext angegeben, z. B. „knp1“ und „knp2“. Die Richtlinie „knp1“ enthält das nicht unterstützte SCTP-Protokoll in einer Egress-Regelspezifikation. Wenn Sie die Import-API ausführen, löst die Konvertierung der Netzwerkrichtlinie „knp1“ einen Fehler aus und der Importvorgang wird vorzeitig beendet. Das System konvertiert die nächste K8s-Netzwerkrichtlinie („knp2“) nicht, selbst wenn diese Netzwerkrichtlinie gültig ist.
WEITER	Wenn beim Importieren der aktuellen K8s-Netzwerkrichtlinie ein Fehler auftritt, überspringt das System diese Richtlinie und fährt mit dem Import der nächsten K8s-Netzwerkrichtlinie fort. Die API-Antwort gibt die Fehlermeldung für jede K8s-Netzwerkrichtlinie zurück, die während des Importvorgangs übersprungen wurde. Vorsicht: Eine Änderung des Datenverkehrsverhaltens ist zu erwarten, wenn die importierten K8s-Netzwerkrichtlinien und die übersprungenen K8s-Netzwerkrichtlinien auf denselben Pod angewendet werden. Beispiel: Dies ist eine Fortsetzung des gleichen Beispiels, wie in der vorherigen Zeile erwähnt. Wenn der Import der Netzwerkrichtlinie „knp1“ einen Fehler auslöst, fährt das System mit dem Importieren der Netzwerkrichtlinie „knp2“ fort und konvertiert diese Netzwerkrichtlinie erfolgreich. Die API-Antwort gibt dieselbe Fehlermeldung für die Netzwerkrichtlinie „knp1“ zurück, die während der Konvertierung einen Fehler auslöste.

Wert

Beschreibung

ABBRECHEN

Dieser Wert ist die Standardoption.

Wenn beim Importieren der K8s-Netzwerkrichtlinien ein Fehler auftritt, verhindert das System, dass alle konvertierten DFW-Richtlinien und Antrea-Gruppen übernommen werden. Der Importvorgang wird vorzeitig beendet und keine der K8s-Netzwerkrichtlinien wird konvertiert. Die API-Antwort gibt die Fehlermeldung für jede K8s-Netzwerkrichtlinie zurück, die zu einem Fehler geführt hat.

Beispiel:

Angenommen, Sie haben UUIDs von zwei K8s-Netzwerkrichtlinien im API-Anforderungstext angegeben, z. B. „knp1“ und „knp2“. Die Richtlinie „knp1“ enthält das nicht unterstützte SCTP-Protokoll in einer Egress-Regelspezifikation. Wenn Sie die Import-API ausführen, löst die Konvertierung der Netzwerkrichtlinie „knp1“ einen Fehler aus und der Importvorgang wird vorzeitig beendet. Das System konvertiert die nächste K8s-Netzwerkrichtlinie („knp2“) nicht, selbst wenn diese Netzwerkrichtlinie gültig ist.

WEITER

Wenn beim Importieren der aktuellen K8s-Netzwerkrichtlinie ein Fehler auftritt, überspringt das System diese Richtlinie und fährt mit dem Import der nächsten K8s-Netzwerkrichtlinie fort. Die API-Antwort gibt die Fehlermeldung für jede K8s-Netzwerkrichtlinie zurück, die während des Importvorgangs übersprungen wurde.

Vorsicht: Eine Änderung des Datenverkehrsverhaltens ist zu erwarten, wenn die importierten K8s-Netzwerkrichtlinien und die übersprungenen K8s-Netzwerkrichtlinien auf denselben Pod angewendet werden.

Beispiel:

Dies ist eine Fortsetzung des gleichen Beispiels, wie in der vorherigen Zeile erwähnt. Wenn der Import der Netzwerkrichtlinie „knp1“ einen Fehler auslöst, fährt das System mit dem Importieren der Netzwerkrichtlinie „knp2“ fort und konvertiert diese Netzwerkrichtlinie erfolgreich. Die API-Antwort gibt dieselbe Fehlermeldung für die Netzwerkrichtlinie „knp1“ zurück, die während der Konvertierung einen Fehler auslöste.

Die K8s-Netzwerkrichtlinien, die Sie in einer einzelnen API-Anforderung importieren, können zu verschiedenen registrierten Antrea-Kubernetes-Clustern gehören. Sie können auch zu mehreren Namespaces innerhalb eines einzelnen Antrea-Kubernetes-Clusters gehören.

Wenn ein Namespace mehrere K8s-Netzwerkrichtlinien enthält, wird empfohlen, diese in einer einzelnen API-Anforderung zu importieren. Der Grund dafür ist, dass K8s-Netzwerkrichtlinien innerhalb eines Namespace miteinander verbunden sein können. Diese Vorgehensweise hilft dabei, sicherzustellen, dass sich das Datenverkehrsverhalten nicht ändert, nachdem die Netzwerkrichtlinien in NSX importiert wurden.

Wechseln Sie nach erfolgreichem Import zur Benutzeroberfläche von NSX Manager und zeigen Sie die Konfiguration der Antrea-Gruppen und DFW-Richtlinien an.
Optional: Zeigen Sie die realisierten Antrea-Cluster-Netzwerkrichtlinien an und überprüfen Sie die ACNP-Spezifikationen und ClusterGroup-Spezifikationen, indem Sie die folgenden kubectl-Befehle ausführen:
```
kubectl get acnp
```
```
kubectl get acnp <acnp-id> -o yaml
```
```
kubectl get cg <cg-id> -o yaml
```
Optional: Stellen Sie sicher, dass die K8s-Netzwerkrichtlinien, die erfolgreich in NSX importiert wurden, im K8s-Cluster nicht angezeigt werden, indem Sie den folgenden kubectl-Befehl ausführen:
```
kubectl get networkpolicies -n <namespace>
```
Für dieses Beispiel lautet der Befehl folgendermaßen:
```
kubectl get networkpolicies -n test-ns5

NAME     POD-SELECTOR   AGE
k-np10   app=demo       84m
k-np12   app=demo       84m
```
Beachten Sie, dass die importierten Kubernetes-Netzwerkrichtlinien („k-np9“ und „k-np11“) im K8s-Cluster nicht mehr angezeigt werden.

Nicht unterstützte Kubernetes-Netzwerkrichtlinienfunktionen

Einige Funktionen in Kubernetes-Netzwerkrichtlinien werden derzeit nicht für die Konvertierung in NSX DFW-Richtlinien und Antrea-Gruppen unterstützt. Die API-Antwort zeigt eine entsprechende Fehlermeldung an, wenn die Konvertierung aufgrund einer der folgenden nicht unterstützten Funktionen fehlschlägt.

K8s-Netzwerkrichtlinien, die Portnamen der Ebene 4 für Pods verwenden, werden nicht konvertiert. DFW-Richtlinien unterstützen nur Portnummern.
K8s-Netzwerkrichtlinien, die das SCTP-Protokoll enthalten, werden nicht konvertiert. NSX DFW-Richtlinien unterstützen keinen SCTP-Datenverkehr.
K8s-Netzwerkrichtlinien können über eine große Anzahl von matchLabels oder matchExpressions im Abschnitt podSelector oder NetworkPolicyPeer verfügen. Das dynamische Mitgliedschaftskriterium in einer Antrea-Gruppe kann jedoch maximal 15 Bedingungen mit gemischten Mitgliedstypen und 5 Bedingungen mit demselben Mitgliedstyp unterstützen. Wenn diese Obergrenze in einem Gruppenmitgliedschaftskriterium überschritten wird, schlägt die Konvertierung fehl.
Kubernetes-Netzwerkrichtlinien, die matchExpressions mit dem Operator DoesNotExist enthalten, werden nicht in Antrea-Gruppen konvertiert. Der Operator DoesNotExist in Kubernetes wird dem Wert NotEquals für den Geltungsbereichsoperator in NSX zugeordnet. Der Geltungsbereichsoperator in einer Antrea-Gruppendefinition unterstützt diesen Wert jedoch derzeit nicht.
Kubernetes-Netzwerkrichtlinien, die matchExpressions mit dem Operator In enthalten, dürfen nur einen einzigen Wert enthalten, damit die Konvertierung erfolgreich durchgeführt werden kann. Mehrere Werte im Operator In werden derzeit nicht für die Konvertierung in Antrea-Gruppen unterstützt.

Verhalten bei verschiedenen Versionen des Antrea-NSX-Adapter

Sie können den Antrea-NSX-Adapter und NSX separat und in beliebiger Reihenfolge aktualisieren. Die neuen Änderungen des Antrea-NSX-Adapter sind mit NSX-Versionen vor 4.2 kompatibel.

Folgendes Szenario wird angenommen:

Ihre NSX-Umgebung weist Version 4.2 auf, es sind mehrere Antrea-Kubernetes-Cluster registriert. Einige Kubernetes-Cluster weisen die neue Version des Antrea-NSX-Adapter (z. B. v0.15) auf, während einige Cluster eine alte Version des Antrea-NSX-Adapter (z. B. v0.11) aufweisen. In diesem Fall löscht die alte Version des Antrea-NSX-Adapter die ursprünglichen Kubernetes-Netzwerkrichtlinien nach der Konvertierung nicht automatisch aus dem Kubernetes-Cluster. Ein Kubernetes-Administrator oder ein Namespace-Administrator muss die ursprünglichen Kubernetes-Netzwerkrichtlinien manuell löschen. Beachten Sie, dass die Konvertierung in DFW-Richtlinien weiterhin durchgeführt wird. Die konvertierten DFW-Zulassungsrichtlinien und die standardmäßigen Verwerfungsrichtlinien werden als Antrea-Cluster-Netzwerkrichtlinien im Kubernetes-Cluster realisiert und von der Antrea-CNI vor den ursprünglichen Kubernetes-Netzwerkrichtlinien ausgewertet. Wenn die ursprünglichen Kubernetes-Richtlinien nicht aus dem Kubernetes-Cluster gelöscht werden, kann das in den konvertierten DFW-Richtlinien definierte Datenverkehrsverhalten mit den ursprünglichen Kubernetes-Netzwerkrichtlinien in Konflikt stehen.