Konfigurieren von Netzwerkressourcen

Beim Konfigurieren einiger Netzwerkressourcen müssen Sie sich bestimmter Einschränkungen bewusst sein.

Grenzwerte für Tags und Bezeichnungen

Tags weisen die folgenden Grenzwerte auf:

Der Tag-Bereich hat einen Grenzwert von 128 Zeichen.
Der Tag-Wert hat einen Grenzwert von 256 Zeichen.
Jedes Objekt kann maximal 30 Tags aufweisen.

Diese Grenzwerte können zu Problemen führen, wenn Kubernetes- oder OpenShift-Anmerkungen in NSX-Bereiche und -Tags kopiert und die Grenzwerte überschritten werden. Wenn ein Tag beispielsweise für einen Switch-Port bestimmt ist und das Tag in einer Firewallregel verwendet wird, wird die Regel möglicherweise nicht erwartungsgemäß angewendet, da der Anmerkungsschlüssel oder -wert beim Kopieren in einen Bereich oder ein Tag möglicherweise abgeschnitten wurde.

Bezeichnungen weisen die folgenden Grenzwerte auf:

Ein Pod darf höchstens 25 Bezeichnungen aufweisen.
Ein Namespace darf höchstens 27 Bezeichnungen aufweisen.
Ein Ingress-Controller-Pod darf nicht mehr als 24 Bezeichnungen aufweisen.

Netzwerkrichtlinien

Eine NetworkPolicy-Ressource weist die folgenden Einschränkungen auf:

Ein podSelector oder namespaceSelector darf nicht mehr als 4 matchLabels aufweisen.
Wenn Sie im Abschnitt ingress from oder egress to über ein einzelnes Element verfügen, das sowohl namespaceSelector als auch podSelector angibt, darf der namespaceSelector nicht mehr als 5 Namespaces auswählen. Andernfalls tritt ein Fehler auf. Ein Beispiel für eine solche Spezifikation (es gibt keine Bindestriche vor podSelector):
```
- namespaceSelector:
    matchLabels:
      project: myproject
  podSelector:
    matchLabels:
      role: db
```

Bei jeder Ingress- oder Egress-Regel darf die Gesamtzahl der namespaceSelectoren plus podSelectoren nicht mehr als 5 sein. Beispielsweise ist Folgendes nicht zulässig, weil die Regel aus 6 Selektoren besteht:

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

Die Netzwerkrichtlinie „Gesamten Egress zulassen“ mit namedPorts im Abschnitt to.ports wird nicht unterstützt.
Wenn Sie im Richtlinienmodus matchExpressions in podSelector oder namespaceSelector angeben, ist höchstens ein In-Operator zulässig. Wenn Sie sowohl namespaceSelector als auch podSelector angeben, darf für einen von ihnen höchstens ein In-Operator vorhanden sein. Für beide darf kein In-Operator vorhanden sein. Die folgende Spezifikation ist beispielsweise nicht zulässig:
```
    - namespaceSelector:
        matchExpressions:
        - {key: key1, operator: In, values: [value1]}
      podSelector:
        matchExpressions:
        - {key: key1, operator: In, values: [value1]}
```
Wenn Sie im Manager-Modus matchExpressions in podSelector, namespaceSelector oder sowohl namespaceSelector als auch podSelector angeben, gibt es keine Beschränkung für die Anzahl der In-Operatoren.
Die Netzwerkrichtlinie mit SCTP im Feld protocol wird nicht unterstützt.

Um die Einschränkungen zu umgehen, können Sie eine Netzwerkrichtlinie mit spezifischeren matchLabels erstellen oder eine Netzwerkrichtlinie durch mehrere Netzwerkrichtlinien ersetzen, die nicht mehr als 5 Selektoren benötigen.

Wenn eine Netzwerkrichtlinie von NCP nicht unterstützt wird, wird sie von NCP mit einer Fehleranmerkung versehen. Sie können die Netzwerkrichtlinie aktualisieren, um den Fehler zu beheben, und NCP wird sie erneut verarbeiten.

Wenn für eine Netzwerkrichtlinie nur Egress angegeben ist, aber kein Ingress, wird keine Firewallregel für den Ingress-Datenverkehr erstellt. In ähnlicher Weise wird eine Firewallregel für den Egress-Datenverkehr zugelassen, wenn für eine Netzwerkrichtlinie nur Ingress angegeben ist, aber kein Egress.

Wenn NSX App-ID-Firewallregeln auf von NCP erstellten Ressourcen angewendet werden, werden nur die Gruppenmitgliedschaftskriterien „Segment“ und „Segmentport“ unterstützt. Beachten Sie, dass die Funktion der App-ID-Firewallregel nur unterstützt wird, wenn NCP für die Verwendung NSX Richtlinien-API konfiguriert ist.