Conversion de stratégies réseau Kubernetes en stratégies de pare-feu distribué NSX

L’Adaptateur NSX Antrea synchronise les stratégies réseau Kubernetes des clusters Kubernetes Antrea enregistrés avec l'inventaire NSX. Cependant, ces stratégies réseau K8s ne peuvent pas être mises à jour ou gérées dans l'environnement NSX.

Si vous souhaitez modifier les stratégies réseau K8s dans NSX, vous pouvez les importer dans votre environnement NSX. Cette fonctionnalité d'importation est disponible à partir de NSX 4.2 et n'est prise en charge qu'avec NSX API.

Présentation de l'importation de stratégies réseau K8s

L'opération d'importation convertit les stratégies réseau K8s en stratégies de pare-feu distribué (DFW) NSX avec un comportement de trafic équivalent. Une fois les stratégies réseau K8s converties en stratégies DFW NSX, NSX devient la source de vérité pour la gestion des stratégies DFW converties. Vous pouvez ensuite modifier les stratégies DFW à l'aide de l'interface utilisateur NSX Manager ou de l'API NSX.

Cette conversion est une opération unidirectionnelle. Vous ne pouvez pas convertir les stratégies DFW NSX en stratégies réseau K8s.

Important : Si votre inventaire NSX contient des stratégies réseau Kubernetes gérées par le NSX Container Plugin (NCP), la fonctionnalité d'importation n'est pas prise en charge. Les stratégies réseau K8s que vous souhaitez importer dans NSX doivent être gérées par le CNI Antrea.

Chaque stratégie réseau K8s importée est convertie en une ou deux stratégies DFW NSX. Une stratégie DFW contiendra toutes les règles d'autorisation (si des règles d'entrée ou de sortie existent dans la stratégie réseau K8s), et l'autre stratégie DFW contiendra la règle de trafic d'abandon par défaut. La stratégie DFW avec la règle d'abandon par défaut est toujours générée.

Le système définit l'étendue de la stratégie DFW NSX sur le cluster Kubernetes Antrea. En outre, l'étendue de la stratégie DFW est également limitée au groupe Antrea qui contient les membres d'espace effectifs de l'espace de noms Kubernetes.

Les stratégies DFW converties sont placées dans le niveau Application de NSX. L'API d'importation ajoute les stratégies DFW converties après d'autres stratégies Antrea existantes dans le niveau Application. Les stratégies importées sont appliquées après les stratégies Antrea existantes dans NSX, mais avant l'application des stratégies réseau de cluster Antrea (ACNP) et les stratégies réseau Antrea (ANP), qui sont définies en mode natif dans le cluster Kubernetes. Le comportement du trafic d'origine dans l'espace de noms K8s est conservé après la conversion en stratégies DFW NSX.

Antrea CNI réalise les stratégies DFW converties en tant que stratégies réseau de cluster Antrea dans le cluster Kubernetes. Ces stratégies réseau de cluster Antrea sont désormais gérées par NSX et peuvent être modifiées uniquement dans l'environnement NSX. Si vous tentez de modifier la configuration ACNP à l'aide de la ligne de commande kubectl, l’Adaptateur NSX Antrea remplacera ou rétablira les modifications d'ACNP apportées à la définition de stratégie d'origine telle qu'elle existe dans NSX.

Une fois les stratégies réseau K8s correctement importées dans NSX, le système supprime automatiquement les stratégies réseau Kubernetes d'origine de l'inventaire K8s. Le système balise également les stratégies DFW converties avec le nom du cluster K8s, la stratégie réseau K8s d'origine et l'espace de noms K8s. Ces balises peuvent vous aider à rechercher les stratégies DFW converties dans l'interface utilisateur NSX Manager. Vous pouvez également exécuter la commande kubectl get acnp -o wide sur la ligne de commande kubectl pour afficher les balises (c'est-à-dire les étiquettes dans K8s) dans l'ACNP réalisé correspondant.

Conditions préalables à l'importation des stratégies réseau K8s

Le cluster Antrea Kubernetes doit être enregistré dans NSX 4.2 ou version ultérieure.
La fonctionnalité d'importation nécessite la version d'interfonctionnement Antrea-NSX disponible avec VMware Container Networking™ with Antrea™ 1.9.0 ou version ultérieure.
Appliquez une licence de sécurité appropriée dans votre déploiement NSX qui autorise le système à configurer des stratégies de sécurité de pare-feu distribué.
Le rôle Administrateur d'entreprise ou Administrateur de sécurité vous est attribué dans l'espace par défaut de votre environnement NSX.
Vérifiez que l’Adaptateur NSX Antrea a correctement signalé les stratégies réseau Kubernetes à l'inventaire NSX.
Par exemple, pour vérifier dans l'interface utilisateur NSX Manager, procédez comme suit :
1. Accéder à Inventaire > Conteneurs > Espaces de noms.
2. Si nécessaire, filtrez la liste des espaces de noms avec le type CNI comme Antrea.
3. Développez un espace de noms, puis cliquez sur le nombre de stratégies réseau pour vérifier si les stratégies réseau Kubernetes sont synchronisées avec l'inventaire NSX.
  Pour vérifier si NSX lit toutes les stratégies réseau Kubernetes dans l'espace de noms, vous pouvez comparer le nombre dans l'interface utilisateur avec le nombre de stratégies récupérées par la commande kubectl suivante. Le nombre doit être le même.
```
kubectl get networkpolicies -n <namespace>
```

Mappage des champs de stratégie réseau K8s aux champs de stratégie de pare-feu distribué NSX

Comme expliqué précédemment, lorsqu'une stratégie réseau Kubernetes est importée dans NSX, le système convertit cette stratégie réseau en une ou deux stratégies DFW. Une stratégie DFW contient toutes les règles d'autorisation et l'autre stratégie DFW contient la règle de trafic d'abandon par défaut. Le système crée des groupes Antrea en fonction de la spécification de la stratégie réseau K8s. Les groupes Antrea sont utilisés dans les champs Sources, Destinations et Appliqué à des stratégies DFW converties.

Le tableau suivant explique le mappage des champs de la stratégie réseau Kubernetes aux champs de la stratégie de pare-feu distribué NSX.

Champ dans la stratégie réseau K8s	Ressources NSX	Description
Stratégie réseau K8s elle-même	Une ou deux stratégies DFW	Toutes les règles du `spec.ingress` ou du `spec.egress` de la stratégie réseau K8s sont ajoutées à la stratégie « autoriser » DFW. Autrement dit, l'action de règle pour toutes les règles de cette stratégie DFW est définie sur Autoriser. Une stratégie DFW avec une règle d'abandon par défaut est créée avec une règle pour annuler le trafic d'entrée, le trafic sortant ou le trafic d'entrée et de sortie en fonction des valeurs de la liste de `spec.policyTypes` de la stratégie réseau K8s. Par exemple, si la liste `spec.policyTypes` de la spécification de stratégie réseau K8s contient uniquement `egress`, la stratégie DFW « abandonner » dispose d'une règle d'abandon par défaut pour le trafic de sortie (sens du trafic : sortie). Si la stratégie réseau Kubernetes ne contient aucune règle d'entrée et de sortie, une stratégie DFW avec uniquement la règle d'abandon par défaut est créée.
`spec.podSelector` et `metadata.namespace`	Groupe de type Antrea	`spec.podSelector` et `metadata.namespace` sont utilisés pour convertir en groupe Antrea. Le groupe Antrea créé est référencé dans Appliqué à des stratégies « autoriser » et « abandonner » DFW. Si `spec.podSelector` n'est pas spécifié, le groupe Antrea contient uniquement l'espace de noms.
`spec.ingress[]` et `spec.egress[]`	Règles de pare-feu dans la stratégie « autoriser » DFW	Chaque règle de la section `spec.ingress` et `spec.egress` de la stratégie réseau K8s est convertie en une règle DFW NSX. Ces règles DFW sont ajoutées à la stratégie « autoriser » DFW.
`spec.ingress[*].from` `podSelector` `namespaceSelector` `ipBlock`	Groupes de type Antrea	L'espace et les sélecteurs d'espace de noms de la section `ingress` `from` sont convertis en groupes Antrea avec des critères d'appartenance dynamique. Les plages CIDR IP dans le sélecteur de `ipBlock` sont converties en membres d'adresses IP statiques dans le groupe Antrea. Ces groupes Antrea sont référencés dans le champ Sources des règles DFW.
`spec.egress[*].to` `podSelector` `namespaceSelector` `ipBlock`	Groupes de type Antrea	L'espace et les sélecteurs d'espace de noms de la section `egress` `to` sont convertis en groupes Antrea avec des critères d'appartenance dynamique. Les plages CIDR IP dans le sélecteur de `ipBlock` sont converties en membres d'adresses IP statiques dans le groupe Antrea. Ces groupes Antrea sont référencés dans le champ Destinations des règles DFW.
`spec.ingress[].ports` `protocol` `port` et `spec.egress[].ports` `protocol` `port`	Entrées de service dans la règle DFW	Le protocole de couche 4 et le port cible (y compris la plage de ports cibles) dans la spécification de règle d'entrée et de sortie de la stratégie réseau K8s sont convertis en entrées Service dans les règles DFW. Les ports cibles ou la plage de ports dans la spécification de règle K8s sont toujours mappés aux ports de destination dans l'entrée Service.

Exemples de mappages de champs

Cette section inclut quelques exemples pour vous aider à comprendre le mappage des champs de la stratégie réseau Kubernetes aux champs de la stratégie DFW lorsqu'une stratégie réseau K8s est importée dans NSX.

Exemple 1

Spécification de stratégie réseau K8s :

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

Cette stratégie réseau K8s sélectionne tous les espaces dans l'espace de noms my-ns1 et autorise le trafic de sortie (connexions sortantes) à partir de n'importe quel espace de cet espace de noms vers le CIDR 8.8.8.8/32 sur le port UDP 53. Tout le trafic de sortie des espaces de cet espace de noms est abandonné.

Lorsque cette stratégie réseau K8s est importée dans NSX, deux stratégies DFW sont créées. Une stratégie DFW contient une règle d'autorisation unique et l'autre stratégie DFW contient une règle d'abandon unique.

La section spec.podSelector est convertie en un groupe Antrea avec un critère d'appartenance dynamique. Le critère dans le groupe sélectionne tous les espaces dans l'espace de noms my-ns1. Ce groupe Antrea est référencé dans le champ Appliqué à de la stratégie d'autorisation de DFW et de la stratégie d'abandon DFW.

Le sélecteur de ipBlock dans la section spec.egress.to est converti en groupe Antrea avec un membre d'adresse IP statique 8.8.8.8/32. Ce groupe Antrea est référencé dans le champ Destinations de la règle d'autorisation DFW. Appelons ce groupe Group-1.

La section spec.egress.ports est convertie en entrée Service avec le protocole UDP et le port de destination 53.

La configuration de la règle d'autorisation de DFW dans NSX est la suivante.

Sources	Destinations	Services	Profils de contexte	Règle Appliqué à	Action de règle	Sens de règle
S/O	Groupe-1	UDP Source : Any, Destination : 53	S/O	Quelconque	Autoriser	Sortant

Sources

Destinations

Services

Profils de contexte

Règle Appliqué à

Action de règle

Sens de règle

S/O

Groupe-1

UDP

Source : Any, Destination : 53

S/O

Quelconque

Autoriser

Sortant

La configuration de la règle d'abandon DFW dans NSX est la suivante.

Sources	Destinations	Services	Profils de contexte	Règle Appliqué à	Action de règle	Sens de règle
Quelconque	Quelconque	Quelconque	S/O	Quelconque	Annuler	Sortant

Exemple 2

Spécification de stratégie réseau K8s :

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

Cette stratégie réseau Kubernetes sélectionne tous les espaces dans l'espace de noms my-ns2 et abandonne tout le trafic d'entrée et le trafic de sortie de ces espaces. Cette stratégie crée essentiellement un abandon par défaut de tout le trafic d'entrée et de sortie pour l'espace de noms.

Lorsque cette stratégie réseau K8s est importée dans NSX, une seule stratégie d'abandon DFW est créée. La stratégie DFW convertie contient une règle de pare-feu unique avec action d'abandon.

La section spec.podSelector est convertie en un groupe Antrea avec un critère d'appartenance dynamique. Le critère dans le groupe sélectionne tous les espaces dans l'espace de noms my-ns2. Ce groupe Antrea est référencé dans le champ Appliqué à de la stratégie d'abandon de DFW.

La configuration de la règle d'abandon DFW dans NSX est la suivante.

Sources	Destinations	Services	Profils de contexte	Règle Appliqué à	Action de règle	Sens de règle
Quelconque	Quelconque	Quelconque	S/O	Quelconque	Annuler	In_Out

Convention de dénomination des stratégies DFW et des groupes de Antrea convertis

Le système utilise la convention d'attribution de nom suivante pour les stratégies d'autorisation et d'abandon de DFW converties :

Stratégie d'autorisation de DFW: <cluster_name>-<namespace>-<K8s_networkpolicy_name>-<K8s_networkpolicy_uuid>-allow
Stratégie d'abandon de DFW: <cluster_name>-<namespace>-<K8s_networkpolicy_name>-<K8s_networkpolicy_uuid>-drop

Les valeurs de cluster_name, namespace et K8s_networkpolicy_name sont tronquées chacune à 12 octets.

Le système utilise la convention de dénomination suivante pour les groupes Antrea :

Groupes référencés dans le champ Appliqué à des stratégies d'autorisation et d'abandon de DFW: <cluster_name>-<namespace>-<K8s_networkpolicy_uuid>
Groupes référencés dans le champ Sources des règles DFW: <cluster_name>-<namespace>-<K8s_networkpolicy_uuid>-rule[rule index]-from-<peer index>
Groupes référencés dans le champ Destinations des règles DFW: <cluster_name>-<namespace>-<K8s_networkpolicy_uuid>-rule[rule index]-to-<peer index>

Les valeurs de cluster_name et namespace sont tronquées à 12 octets chacune.

Pour comprendre comment le système attribue des valeurs à l'index de règle et à l'index homologue dans le nom du groupe Antrea, prenez l'exemple suivant d'une stratégie réseau K8s, qui contient trois règles d'entrée.

Exemple

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

Examinons l'extrait de la première règle ingress.from, comme suit :

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

La section from de cette règle d'entrée contient deux éléments. Un élément sélectionne les espaces à l'aide du sélecteur d'espace de noms et l'autre élément sélectionne les espaces à l'aide du sélecteur d'espace. Nous appelons ces deux éléments des pairs.

Le système crée un groupe Antrea pour chaque homologue dans la règle. La règle DFW convertie a l'index de règle 0 et cette règle contient deux groupes Antrea dans le champ Sources de la règle. Un nom de groupe Antrea a l'index d'homologue 0 et l'autre nom de groupe a l'index d'homologue 1, comme suit :

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

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

Tenez compte de l'extrait de la deuxième et de la troisième ingress.from règles, comme suit :

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

La section from de chacune de ces deux règles d'entrée contient un seul élément qui sélectionne les espaces à l'aide du sélecteur d'espace de noms. Les règles DFW converties ont respectivement l'index de règle 1 et 2, et chaque règle contient un groupe de Antrea unique dans le champ Sources de la règle. Dans ce cas, l'index homologue n'est pas ajouté aux noms des groupes Antrea. Les noms de groupes disponibles sont les suivants :

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

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

Workflow d'importation de haut niveau à l'aide de l'API

Assurez-vous que vous avez respecté les conditions préalables à l'importation des stratégies réseau Kubernetes, comme expliqué précédemment dans cette documentation.
Exécutez la commande kubectl suivante pour afficher la liste des stratégies réseau Kubernetes dans un espace de noms donné :
```
kubectl get networkpolicies -n <namespace>
```
Par exemple :
```
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
```
Dans cet exemple, l'espace de noms test-ns5 contient quatre stratégies réseau Kuberentes. Dans cette procédure, nous allons importer les stratégies « k-np9 » et « k-np11 » dans NSX.
Exécutez la commande kubectl suivante pour récupérer l'ID de chaque stratégie réseau Kubernetes que vous souhaitez importer.
```
kubectl get networkpolicies <policy-name> -n <namespace> -o yaml
```
Par exemple, pour récupérer les ID des stratégies réseau « k-np9 » et « k-np11 », exécutez les commandes suivantes :
```
kubectl get networkpolicies k-np9 -n test-ns5 -o yaml
kubectl get networkpolicies k-np11 -n test-ns5 -o yaml
```
Dans la sortie de ces deux commandes kubectl, notez l'ID que vous voyez dans le champ metadata.uid. Dans notre cluster K8s, les ID de stratégie sont les suivants :
- Pour k-np9 : e5a59ae6-cc0e-42a5-80bd-f6fa13b5b70d
- Pour k-np11 : 84b850fb-69ad-4e95-a563-a95ce6b70557
Ces ID de stratégie ne sont qu'à des fins d'exemple. Ils peuvent être différents dans votre cluster K8s. Vous aurez besoin de ces ID de stratégie pour exécuter l'API d'importation, ce qui est expliqué à l'étape suivante.

Exécutez l'API NSX suivante pour importer les stratégies réseau Kubernetes :

Par exemple :

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
}

Le paramètre network_policy_ids est obligatoire, tandis que les paramètres sequence_number_upper et sequence_number_lower sont facultatifs.

Dans cet exemple, les ID des stratégies réseau K8s (k-np9 et k-np11) sont spécifiés pour l'importation dans NSX.

Pour obtenir des informations détaillées sur ces paramètres de demande, l'exemple de demande d'API et l'exemple de réponse d'API, reportez-vous au Guide de NSX API.

Le paramètre de requête on_error détermine l'action que l'API doit effectuer lorsqu'une erreur se produit. Le tableau suivant explique les valeurs valides de ce paramètre de requête.

Valeur	Description
ABANDONNER	Il s'agit de la valeur par défaut. Si une erreur se produit lors de l'importation des stratégies réseau K8s, le système empêche toutes les stratégies DFW converties et les groupes Antrea d'être validés. L'opération d'importation se termine prématurément et aucune des stratégies réseau K8s n'est convertie. La réponse de l'API renvoie le message d'erreur pour chaque stratégie réseau K8s qui a généré une erreur. Exemple : Supposons que vous ayez spécifié des UUID de deux stratégies réseau K8s, par exemple knp1 et knp2 dans le corps de la demande d'API. La stratégie knp1 contient le protocole SCTP non pris en charge dans une spécification de règle de sortie. Lorsque vous exécutez l'API d'importation, la conversion de la stratégie réseau knp1 génère une erreur et l'opération d'importation se termine prématurément. Le système ne convertit pas la stratégie réseau K8s suivante (knp2), même si cette stratégie réseau est valide.
CONTINUER	Si une erreur se produit lors de l'importation de la stratégie réseau K8s actuelle, le système ignore cette stratégie et continue d'importer la stratégie réseau K8s suivante. La réponse de l'API renvoie le message d'erreur pour chaque stratégie réseau K8s qui a été ignorée lors de l'opération d'importation. Attention : Une modification du comportement du trafic peut être attendue si les stratégies réseau K8s importées et les stratégies réseau K8s ignorées sont appliquées au même espace. Exemple : Continuez avec le même exemple, comme mentionné dans la ligne précédente. Lorsque l'importation de la stratégie réseau knp1 génère une erreur, le système continue d'importer la stratégie réseau knp2 et convertit cette stratégie réseau. La réponse de l'API renvoie le même message d'erreur pour la stratégie réseau knp1, qui a échoué lors de la conversion.

Valeur

Description

ABANDONNER

Il s'agit de la valeur par défaut.

Si une erreur se produit lors de l'importation des stratégies réseau K8s, le système empêche toutes les stratégies DFW converties et les groupes Antrea d'être validés. L'opération d'importation se termine prématurément et aucune des stratégies réseau K8s n'est convertie. La réponse de l'API renvoie le message d'erreur pour chaque stratégie réseau K8s qui a généré une erreur.

Exemple :

Supposons que vous ayez spécifié des UUID de deux stratégies réseau K8s, par exemple knp1 et knp2 dans le corps de la demande d'API. La stratégie knp1 contient le protocole SCTP non pris en charge dans une spécification de règle de sortie. Lorsque vous exécutez l'API d'importation, la conversion de la stratégie réseau knp1 génère une erreur et l'opération d'importation se termine prématurément. Le système ne convertit pas la stratégie réseau K8s suivante (knp2), même si cette stratégie réseau est valide.

CONTINUER

Si une erreur se produit lors de l'importation de la stratégie réseau K8s actuelle, le système ignore cette stratégie et continue d'importer la stratégie réseau K8s suivante. La réponse de l'API renvoie le message d'erreur pour chaque stratégie réseau K8s qui a été ignorée lors de l'opération d'importation.

Attention : Une modification du comportement du trafic peut être attendue si les stratégies réseau K8s importées et les stratégies réseau K8s ignorées sont appliquées au même espace.

Exemple :

Continuez avec le même exemple, comme mentionné dans la ligne précédente. Lorsque l'importation de la stratégie réseau knp1 génère une erreur, le système continue d'importer la stratégie réseau knp2 et convertit cette stratégie réseau. La réponse de l'API renvoie le même message d'erreur pour la stratégie réseau knp1, qui a échoué lors de la conversion.

Les stratégies réseau K8s que vous importez dans une demande d'API unique peuvent appartenir à différents clusters Kubernetes enregistrés Antrea. Elles peuvent également appartenir à plusieurs espaces de noms au sein d'un cluster Kubernetes Antrea unique.

Si un espace de noms inclut plusieurs stratégies réseau K8s, nous vous recommandons de les importer dans une demande d'API unique. Cela est dû au fait que les stratégies réseau K8s à l'intérieur d'un espace de noms peuvent être liées les unes aux autres. Cette pratique permet de s'assurer que le comportement du trafic ne change pas après l'importation des stratégies réseau dans NSX.

Une fois l'importation réussie, accédez à l'interface utilisateur NSX Manager et affichez la configuration des groupes Antrea et des stratégies DFW.
Facultatif : affichez les stratégies réseau de cluster réalisées Antrea, vérifiez les spécifications ACNP et ClusterGroup en exécutant les commandes kubectl suivantes :
```
kubectl get acnp
```
```
kubectl get acnp <acnp-id> -o yaml
```
```
kubectl get cg <cg-id> -o yaml
```
Facultatif : vérifiez que les stratégies réseau K8s qui sont correctement importées dans NSX ne sont pas visibles dans le cluster K8s en exécutant la commande kubectl suivante :
```
kubectl get networkpolicies -n <namespace>
```
Pour notre exemple, la commande est la suivante :
```
kubectl get networkpolicies -n test-ns5

NAME     POD-SELECTOR   AGE
k-np10   app=demo       84m
k-np12   app=demo       84m
```
Notez que les stratégies réseau Kubernetes importées (k-np9 et k-np11) ne sont plus visibles dans le cluster K8s.

Fonctionnalités de stratégie réseau Kubernetes non prises en charge

Certaines fonctionnalités des stratégies réseau Kubernetes ne sont actuellement pas prises en charge pour la conversion en stratégies DFW NSX et groupes Antrea. La réponse de l'API affiche un message d'erreur approprié lorsque la conversion échoue en raison de l'une des fonctionnalités non prises en charge suivantes.

Les stratégies réseau K8s qui utilisent des noms de port de couche 4 pour les espaces ne sont pas converties. Les stratégies DFW prennent uniquement en charge les numéros de port.
Les stratégies réseau K8s qui contiennent le protocole SCTP ne sont pas converties. Les stratégies NSX DFW ne prennent pas en charge le trafic SCTP.
Les stratégies réseau K8s peuvent comporter un grand nombre de matchLabels ou de matchExpressions dans la section podSelector ou NetworkPolicyPeer. Cependant, le critère d'appartenance dynamique dans un groupe Antrea peut prendre en charge un maximum de 15 conditions avec des types de membres mixtes et 5 conditions avec le même type de membre. Lorsque cette limite maximale est dépassée dans un critère d'appartenance à un groupe, la conversion échoue.
Les stratégies réseau Kubernetes qui contiennent des matchExpressions avec l'opérateur DoesNotExist ne sont pas converties en groupes Antrea. L'opérateur DoesNotExist dans Kubernetes est mappé à la valeur NotEquals de l'opérateur d'étendue dans NSX. Toutefois, l'opérateur d'étendue dans une définition de groupe Antrea ne prend actuellement pas en charge cette valeur.
Les stratégies réseau Kubernetes qui contiennent matchExpressions avec l'opérateur In ne doivent contenir qu'une seule valeur pour que la conversion réussisse. Plusieurs valeurs dans l'opérateur In ne sont actuellement pas prises en charge pour la conversion en groupes Antrea.

Comportement avec différentes versions Adaptateur NSX Antrea

Vous pouvez mettre à niveau Adaptateur NSX Antrea et NSX séparément, et dans n'importe quel ordre. Les nouvelles modifications apportées au Adaptateur NSX Antrea sont compatibles avec NSX versions antérieures à 4.2.

Examinez le scénario suivant :

Votre environnement NSX est à la version 4.2 et il dispose de plusieurs clusters Kubernetes Antrea enregistrés sur celui-ci. Certains clusters Kubernetes disposent de la nouvelle version de Adaptateur NSX Antrea (par exemple v0.15), tandis que d'autres disposent d'une ancienne version de Adaptateur NSX Antrea (par exemple v0.11). Dans ce cas, l'ancienne version de Adaptateur NSX Antrea ne supprimera pas automatiquement les stratégies réseau Kubernetes d'origine du cluster Kubernetes après la conversion. L'administrateur Kubernetes ou l'administrateur d'espace de noms doit supprimer manuellement les stratégies réseau Kubernetes d'origine. Notez que la conversion en stratégies DFW est toujours effectuée. Les stratégies d'autorisation DFW converties et les stratégies d'abandon par défaut sont réalisées en tant que stratégies réseau de cluster Antrea dans le cluster Kubernetes, et elles sont évaluées par Antrea CNI avant les stratégies réseau Kubernetes d'origine. Si les stratégies Kubernetes d'origine ne sont pas supprimées du cluster Kubernetes, le comportement du trafic défini dans les stratégies DFW converties peut entrer en conflit avec les stratégies réseau Kubernetes d'origine.