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-T Data Center 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.
  • Le champ matchExpressions n'est pas pris en charge.
  • 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.

Dans NCP 3.0.0 et 3.0.1, si une stratégie réseau n'a que des sorties spécifiées mais pas d'entrée, une règle de pare-feu est créée pour autoriser tout 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, une règle de pare-feu est créée pour autoriser tout le trafic de sortie.

À partir de NCP 3.0.2, 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.