Zu den zu konfigurierenden NSX-T Data Center-Ressourcen gehören eine Overlay-Transportzone, ein logischer Tier-0-Router, ein logischer Switch zum Verbinden der virtuellen Maschinen des Knotens, IP-Blöcke für Kubernetes-Knoten und ein IP-Pool für SNAT.

Wichtig: Wenn die Ausführung mit NSX-T Data Center 2.4 oder höher erfolgt, müssen Sie mithilfe der Registerkarte Netzwerk und Sicherheit – Erweitert NSX-T-Ressourcen konfigurieren.

In der NCP-Konfigurationsdatei ncp.ini sind die NSX-T Data Center-Ressourcen unter Verwendung ihrer UUIDs oder Namen angegeben.

Overlay-Transportzone

Melden Sie sich bei NSX Manager an und navigieren Sie zu System > Fabric > Transportzonen. Suchen Sie nach der für Containernetzwerke verwendeten Overlay-Transportzone oder erstellen Sie eine neue.

Geben Sie eine Overlay-Transportzone für einen Cluster an, indem Sie die Option overlay_tz im Abschnitt [nsx_v3] der Datei ncp.ini festlegen. Dieser Schritt ist optional. Wenn Sie overlay_tz nicht festlegen, ruft NCP die ID der Overlay-Transportzone automatisch vom Tier-0-Router ab.

Logisches Tier-0-Routing

Melden Sie sich bei NSX Manager an und navigieren Sie zu Netzwerk und Sicherheit – Erweitert > Netzwerk > Router. Suchen Sie nach dem für Containernetzwerke verwendeten Router oder erstellen Sie einen neuen.

Geben Sie einen logischen Tier-0-Router für einen Cluster an, indem Sie die Option tier0_router im Abschnitt [nsx_v3] der Datei ncp.ini festlegen.

Hinweis: Der Router muss im Aktiv/Standby-Modus erstellt werden.

Logischer Switch

Die vom Knoten für den Netzwerkdatenverkehr verwendeten vNICs müssen mit einem logischen Overlay-Switch verbunden sein. Die Verwaltungsschnittstelle des Knotens muss nicht zwingend mit NSX-T Data Center verbunden sein, obwohl dies die Einrichtung erleichtert. Sie können einen logischen Switch erstellen, indem Sie sich bei NSX Manager anmelden und zu Netzwerk und Sicherheit – Erweitert > Netzwerk > Switching > Switches navigieren. Erstellen Sie auf dem Switch logische Ports und hängen Sie die vNICs des Knotens daran an. Die logischen Ports müssen die folgenden Tags aufweisen:
  • Tag: <cluster_name>, Geltungsbereich: ncp/cluster
  • Tag: <node_name>, Geltungsbereich: ncp/node_name
Der Wert für <cluster_name> muss mit dem Wert der Option cluster im Abschnitt [coe] von ncp.ini übereinstimmen.

IP-Blöcke für Kubernetes-Pods

Melden Sie sich bei NSX Manager an und navigieren Sie zu Netzwerk und Sicherheit – Erweitert > Netzwerk > IPAM, um einen oder mehrere IP-Blöcke zu erstellen. Geben Sie den IP-Block im CIDR-Format an.

Geben Sie IP-Blöcke für Kubernetes-Pods an, indem Sie die Option container_ip_blocks im Abschnitt [nsx_v3] der Datei ncp.ini festlegen.

Sie können IP-Blöcke auch spezifisch für Nicht-SNAT-Namespaces (für Kubernetes) oder Cluster (für PCF) erstellen.

Geben Sie Nicht-SNAT-IP-Blöcke ein, indem Sie die Option no_snat_ip_blocks im Abschnitt [nsx_v3] der Datei ncp.ini festlegen.

Wenn Sie Nicht-SNAT-IP-Blöcke erstellen, während NCP ausgeführt wird, müssen Sie NCP neu starten. Andernfalls verwendet NCP weiterhin die freigegebenen IP-Blöcke, bis sie erschöpft sind.

Hinweis: Wenn Sie einen IP-Block erstellen, darf das Präfix nicht größer als der Wert des Parameters subnet_prefix in der NCP-Konfigurationsdatei ncp.ini sein. Weitere Informationen finden Sie unter Configmap für ncp.ini in ncp-rc.yml.

IP-Pool für SNAT

Ein IP-Pool in NSX Manager wird für die Zuteilung von IP-Adressen, die für die Übersetzung von Pod-IPs mithilfe von SNAT-Regeln verwendet werden, und für die Bereitstellung von Ingress-Controllern unter Verwendung von SNAT/DNAT-Regeln verwendet, genau wie OpenStack-Floating-IPs. Diese IP-Adressen werden auch als „externe IP-Adressen“ bezeichnet.

Mehrere Kubernetes-Cluster verwenden denselben externen IP-Pool. Jede NCP-Instanz verwendet einen Teil dieses Pools für den Kubernetes-Cluster, den sie verwaltet. Standardmäßig wird dasselbe Subnetzpräfix für Pod-Subnetze verwendet. Wen Sie eine andere Subnetzgröße verwenden möchten, aktualisieren Sie die external_subnet_prefix-Option im [nsx_v3]-Abschnitt in ncp.ini.

Sie können IP-Pools für SNAT angeben, indem Sie die Option external_ip_pools im Abschnitt [nsx_v3] der Datei ncp.ini festlegen.

Sie können zu einem anderen IP-Pool wechseln, indem Sie die Konfigurationsdatei ändern und NCP neu starten.

Einschränken eines SNAT-IP-Pools auf bestimmte Kubernetes-Namespaces oder PCF-Organisationen

Sie können durch Hinzufügen der folgenden Tags zum IP-Pool festlegen, welchem Kubernetes-Namespace oder welcher PCF Org IPs aus dem SNAT-IP-Pool zugeteilt werden können.
  • Für einen Kubernetes-Namespace: scope: ncp/owner, tag: ns:<namespace_UUID>
  • Für eine PCF Org: scope: ncp/owner, tag: org:<org_UUID>
Sie können die Namespace- oder Org-UUID mit einem der folgenden Befehle abrufen:
kubectl get ns -o yaml
cf org <org_name> --guid
Beachten Sie Folgendes:
  • Jedes Tag sollte eine UUID enthalten. Sie können mehrere Tags für denselben Pool erstellen.
  • Wenn Sie die Tags ändern, nachdem einigen Namespaces oder Orgs IPs basierend auf den alten Tags zugewiesen wurden, werden diese IPs nicht wiederhergestellt, bis sich die SNAT-Konfigurationen der Kubernetes-Dienste oder PCF-Anwendungen ändern oder NCP neu gestartet wird.
  • Die Owner-Tags für Namespace und PCF Org sind optional. Ohne diese Tags können jedem Namespace bzw. jeder PCF Org IPs aus dem SNAT-IP-Pool zugeteilt werden.

Konfigurieren eines SNAT-IP-Pools für einen Dienst

Sie können einen SNAT-IP-Pool für einen Dienst konfigurieren, indem Sie dem Dienst eine Anmerkung hinzufügen. Beispiel:
    apiVersion: v1
    kind: Service
    metadata:
      name: svc-example
      annotations:
        ncp/snat_pool: <external IP pool ID or name>
      selector:
        app: example
    ...

Der von ncp/snat_pool angegebene-IP-Pool muss über das Tag scope: ncp/owner, tag: cluster:<cluster_name> verfügen.

NCP konfiguriert die SNAT-Regel für diesen Dienst. Bei der Quell-IP der Regel handelt es sich um die Gruppe der Backend-Pods. Bei der Ziel-IP handelt es sich um die SNAT-IP, die aus dem angegebenen externen IP-Pool zugeteilt wurde. Falls bei der Konfiguration der SNAT-Regel durch NCP ein Fehler auftritt, wird der Dienst mit der Anmerkung ncp/error.snat: <error> versehen. Dies sind die möglichen Fehler:
  • IP_POOL_NOT_FOUND: Der SNAT-IP-Pool wurde in NSX Manager nicht gefunden.
  • IP_POOL_EXHAUSTED: Der SNAT-IP-Pool ist ausgeschöpft.
  • IP_POOL_NOT_UNIQUE: Der durch ncp/snat_pool angegebene Pool verweist auf mehrere Pools in NSX Manager.
  • SNAT_POOL_ACCESS_DENY: Das Owner-Tag des Pools stimmt nicht mit dem Namespace des Diensts überein, der die Zuteilungsanforderung sendet.
  • SNAT_RULE_OVERLAPPED: Eine neue SNAT-Regel wird erstellt, aber der Pod des SNAT-Diensts gehört auch zu einem anderen SNAT-Dienst, d. h., für denselben Pod sind mehrere SNAT-Regeln vorhanden.
  • POOL_ACCESS_DENIED – Der von ncp/snat_pool angegebene IP-Pool weist das Tag scope: ncp/owner, tag: cluster:<cluster_name> nicht auf, oder das Owner-Tag des Pools stimmt nicht mit dem Namespace des Diensts überein, der die Zuteilungsanforderung sendet.
Beachten Sie Folgendes:
  • Der von ncp/snat_pool angegebene Pool sollte bereits in NSX-T Data Center vorhanden sein, bevor der Dienst konfiguriert wird.
  • In NSX-T Data Center ist die Priorität der SNAT-Regel für den Dienst höher als die für das Projekt.
  • Wenn ein Pod mit mehreren SNAT-Regeln konfiguriert wird, funktioniert nur eine der Regeln.
  • Sie können zu einem anderen IP-Pool wechseln, indem Sie die Anmerkung ändern und NCP neu starten.

Konfigurieren eines SNAT-IP-Pools für einen Namespace

Sie können einen SNAT-IP-Pool für einen Namespace konfigurieren, indem Sie dem Namespace eine Anmerkung hinzufügen. Beispiel:
    apiVersion: v1
    kind: Namespace
    metadata:
      name: ns-sample
      annotations:
        ncp/snat_pool: <external IP pool ID or name>
    ...
NCP konfiguriert die SNAT-Regel für diesen Namespace. Bei der Quell-IP der Regel handelt es sich um die Gruppe der Backend-Pods. Bei der Ziel-IP handelt es sich um die SNAT-IP, die aus dem angegebenen externen IP-Pool zugeteilt wurde. Falls bei der Konfiguration der SNAT-Regel durch NCP ein Fehler auftritt, wird der Namespace mit der Anmerkung ncp/error.snat: <error> versehen. Dies sind die möglichen Fehler:
  • IP_POOL_NOT_FOUND: Der SNAT-IP-Pool wurde in NSX Manager nicht gefunden.
  • IP_POOL_EXHAUSTED: Der SNAT-IP-Pool ist ausgeschöpft.
  • IP_POOL_NOT_UNIQUE: Der durch ncp/snat_pool angegebene Pool verweist auf mehrere Pools in NSX Manager.
  • POOL_ACCESS_DENIED – Der von ncp/snat_pool angegebene IP-Pool weist das Tag scope: ncp/owner, tag: cluster:<cluster_name> nicht auf, oder das Owner-Tag des Pools stimmt nicht mit dem Namespace überein, der die Zuteilungsanforderung sendet.
Beachten Sie Folgendes:
  • Sie können nur einen SNAT-IP-Pool in der Anmerkung angeben.
  • Der SNAT-IP-Pool muss nicht in ncp.ini konfiguriert sein.
  • Der von ncp/snat_pool angegebene-IP-Pool muss über das Tag scope: ncp/owner, tag: cluster:<cluster_name> verfügen.
  • Der mit ncp/snat_pool angegebene IP-Pool kann auch ein Namespace-Tag, scope: ncp/owner, tag: ns:<namespace_UUID>, aufweisen.
  • Wenn die Anmerkung ncp/snat_pool fehlt, verwendet der Namespace den SNAT-IP-Pool für den Cluster.
  • Sie können zu einem anderen IP-Pool wechseln, indem Sie die Anmerkung ändern und NCP neu starten.

Konfigurieren eines SNAT-Pools für eine PAS-App

Standardmäßig konfiguriert NCP die SNAT-IP für eine PAS-Organisation (Pivotal Application Service). Sie können eine SNAT-IP für eine App konfigurieren, indem Sie eine App mit einer manifest.xml erstellen, die die SNAT-IP-Pool-Informationen enthält. Beispiel:
    applications:
      - name: frontend
        memory: 32M
        disk_quota: 32M
        buildpack: go_buildpack
        env:
          GOPACKAGENAME: example-apps/cats-and-dogs/frontend
          NCP_SNAT_POOL: <external IP pool ID or name>
    ...
NCP konfiguriert die SNAT-Regel für diese Anwendung. Die Quell-IP der Regel ist der Satz von IP-Adressen der Instanzen, und ihre Ziel-IP ist die SNAT-IP, die aus einem externen IP-Pool zugewiesen wurde. Beachten Sie Folgendes:
  • Der von NCP_SNAT_POOL angegebene Pool sollte bereits in NSX-T Data Center vorhanden sein, bevor die Anwendung mithilfe von Push übertragen wird.
  • Die SNAT-Regel für eine Anwendung hat eine höhere Priorität als diejenige für eine Organisation.
  • Eine Anwendung kann nur mit einer SNAT-IP konfiguriert werden.
  • Sie können zu einem anderen IP-Pool wechseln, indem Sie die Konfiguration ändern und NCP neu starten.

Konfigurieren von SNAT für PCF Version 3

Mit PCF Version 3 können Sie SNAT auf zwei Arten konfigurieren:

  • Konfigurieren Sie NCP_SNAT_POOL in manifest.yml, wenn Sie die App erstellen.
    Die App trägt beispielsweise den Namen bread und die manifest.yml enthält die folgenden Informationen:
    applications:
    - name: bread
      stack: cflinuxfs2
      random-route: true
      env:
        NCP_SNAT_POOL: AppSnatExternalIppool
      processes:
      - type: web
        disk_quota: 1024M
        instances: 2
        memory: 512M
        health-check-type: port
      - type: worker
        disk_quota: 1024M
        health-check-type: process
        instances: 2
        memory: 256M
        timeout: 15
    Führen Sie die folgenden Befehle aus:
    cf v3-push bread
    cf v3-apply-manifest -f manifest.yml
    cf v3-apps
    cf v3-restart bread
  • Konfigurieren Sie NCP_SNAT_POOL mithilfe des Befehls cf v3-set-env.
    Führen Sie die folgenden Befehle aus (unter der Annahme, dass die App den Namen app3 trägt):
    cf v3-set-env app3 NCP_SNAT_POOL AppSnatExternalIppool
    (optional) cf v3-stage app3 -package-guid <package-guid> (You can get package-guid with "cf v3-packages app3".)
    cf v3-restart app3

(Optional, nur für Kubernetes) Firewall-Markierungsabschnitte

Damit der Administrator Firewallregeln erstellen kann und diese die von NCP erstellten, auf Netzwerkrichtlinien basierenden Firewallabschnitte nicht beeinträchtigen, melden Sie sich bei NSX Manager an, navigieren Sie zu Sicherheit > Verteilte Firewall > Allgemein und erstellen Sie zwei Firewallabschnitte.

Geben Sie Firewall-Markierungsabschnitte an, indem Sie die Optionen bottom_firewall_section_marker und top_firewall_section_marker im Abschnitt [nsx_v3] der Datei ncp.ini festlegen.

Der untere Firewallabschnitt muss sich unterhalb des oberen Firewallabschnitts befinden. Wenn diese Firewallabschnitte erstellt sind, werden alle von NCP zur Isolierung erstellten Firewallabschnitte oberhalb des unteren Firewallabschnitts und alle von NCP für Richtlinien erstellten Firewallabschnitte unterhalb des oberen Firewallabschnitts erstellt. Wenn diese Markierungsabschnitte nicht erstellt werden, werden alle Isolierungsregeln unten und alle Richtlinienabschnitte oben erstellt. Mehrere markierte Firewallabschnitte mit demselben Wert pro Cluster werden nicht unterstützt und führen zu einem Fehler.