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-T Data Center-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.
  • Das Feld matchExpressions wird nicht unterstützt.
  • 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 in NCP 3.0.0 und 3.0.1 für eine Netzwerkrichtlinie nur ein Egress angegeben ist, sie aber keinen Ingress aufweist, wird eine Firewallregel erstellt, um den gesamten Ingress-Datenverkehr zuzulassen. In ähnlicher Weise wird eine Firewallregel erstellt, um den gesamten Egress-Datenverkehr zuzulassen, wenn für eine Netzwerkrichtlinie nur Ingress angegeben ist, aber kein Egress.

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