Configuration des ressources en réseau

Lors de la configuration de certaines ressources réseau, vous devez connaître certaines restrictions.

Limites sur les balises et les étiquettes

Les balises ont les limites suivantes :

L'étendue de la balise est limitée à 128 caractères.
La valeur de la balise est limitée à 256 caractères.
Chaque objet peut contenir un maximum de 30 balises.

Ces limites peuvent entraîner des problèmes lorsque des annotations Kubernetes ou OpenShift sont copiées vers des étendues et des balises NSX et que les limites sont dépassées. Par exemple, si une balise est destinée à un port de commutateur et que la balise est utilisée dans une règle de pare-feu, la règle risque de ne pas être appliquée comme prévu, car la clé ou la valeur d'annotation a été tronquée lors de sa copie sur une étendue ou une balise.

Les étiquettes ont les limites suivantes :

Chaque espace ne peut contenir plus de 25 étiquettes.
Chaque espace de noms ne peut contenir plus de 27 étiquettes.
Un espace de contrôleur d'entrée ne peut contenir plus de 24 étiquettes.

Stratégies réseau

Une ressource NetworkPolicy a les limitations suivantes :

Un podSelector ou un namespaceSelector ne peut pas avoir plus de 4 matchLabels.
Dans une section ingress from ou egress to, si vous disposez d'un seul élément qui spécifie namespaceSelector et podSelector, le namespaceSelector ne doit pas sélectionner plus de 5 espaces de noms. Sinon, une erreur se produira. Exemple de spécification de ce type (notez qu'il n'y a pas de trait d'union avant podSelector) :
```
- namespaceSelector:
    matchLabels:
      project: myproject
  podSelector:
    matchLabels:
      role: db
```

Pour toute règle d'entrée ou de sortie, le nombre total de namespaceSelectors plus podSelectors ne peut pas être supérieur à 5. Par exemple, les éléments suivants ne sont pas autorisés, car la règle dispose d'un total de 6 sélecteurs :

ingress:
    - namespaceSelector:
        matchLabels:
          project: myproject1
    - namespaceSelector:
        matchLabels:
          project: myproject2
    - namespaceSelector:
        matchLabels:
          project: myproject3
    - podSelector:
        matchLabels:
          role: db
    - podSelector:
        matchLabels:
          role: app
    - podSelector:
        matchLabels:
          role: infra

La stratégie réseau Autoriser toute sortie avec namedPorts dans la section to.ports n'est pas prise en charge.
Dans le mode Stratégie, lors de la spécification de matchExpressions dans podSelector ou namespaceSelector, un opérateur In au maximum est autorisé. Si vous spécifiez namespaceSelector et podSelector, vous ne pouvez avoir qu'un seul opérateur In pour l'un d'eux. Vous ne pouvez pas avoir un opérateur In pour chacun d'eux. Par exemple, la spécification suivante n'est pas autorisée :
```
    - namespaceSelector:
        matchExpressions:
        - {key: key1, operator: In, values: [value1]}
      podSelector:
        matchExpressions:
        - {key: key1, operator: In, values: [value1]}
```
En mode Gestionnaire, lorsque vous spécifiez matchExpressions dans podSelector, namespaceSelector ou à la fois dans namespaceSelector et dans podSelector, il n'y a aucune restriction sur le nombre d'opérateurs In.
La stratégie réseau avec SCTP dans le champ protocol n'est pas prise en charge.

Pour contourner les limitations, vous pouvez créer une stratégie réseau avec des matchLabels plus spécifiques ou remplacer une stratégie réseau avec plusieurs stratégies réseau qui ne nécessitent pas plus de 5 sélecteurs.

Si une stratégie réseau n'est pas prise en charge par NCP, il l'annotera avec une erreur. Vous pouvez mettre à jour la stratégie réseau pour corriger l'erreur et NCP la traitera à nouveau.

Si une stratégie réseau n'a que des sorties spécifiées mais pas d'entrée, aucune règle de pare-feu n'est créée pour le trafic d'entrée. De même, si une stratégie réseau n'a que des entrées spécifiées mais pas de sortie, aucune règle de pare-feu n'est créée pour le trafic de sortie.

Lorsque les règles de pare-feu d'ID d'application NSX sont appliquées aux ressources créées par NCP, seuls les critères d'appartenance au groupe « Segment » et « Port de segment » sont pris en charge. Notez que la fonctionnalité de règle de pare-feu d'ID d'application n'est prise en charge que si NCP est configuré pour l'API de stratégie NSX.