Sie können NCP für die Unterstützung von Ingress-Controllern von Drittanbietern konfigurieren.

Bearbeiten der Datei NCP.ini

Sie müssen die Konfigurationsdatei /var/vcap/data/jobs/ncp/xxxxxxxx/config/ncp.ini bearbeiten (wobei xxxxxxxx die BOSH-Bereitstellungs-ID ist). Diese Datei wird dann in rootfs kopiert und von NCP jedes Mal verwendet, wenn NCP neu gestartet wird. Diese Datei muss auf jedem Master-Knoten bearbeitet werden.

Wichtig: Änderungen an ncp. ini sind bei TKGI-Cluster-Aktualisierungen nicht persistent. Wenn Sie Änderungen über die TKGI-Kachel vornehmen und dann die TKGI-Bereitstellung aktualisieren, gehen die Änderungen an ncp. ini verloren.
Die relevanten Optionen befinden sich im Abschnitt nsx_v3.
  • use_native_loadbalancer: Wenn dies auf False festgelegt ist, verarbeitet NCP unabhängig von den zugehörigen Anmerkungen keine Ingresses oder Dienste vom Typ LoadBalancer-Aktualisierungen. Diese Einstellung gilt für den gesamten TKGI-Cluster. Die Standardeinstellung lautet True.
  • default_ingress_class_nsx: Wenn dies auf True festgelegt ist, wird NCP zum standardmäßigen Ingress-Controller und verarbeitet sowohl Dateneingänge mit der Anmerkung kubernetes.io/ingress.class: "nsx" als auch Dateneingänge ohne Anmerkung. Wenn der Wert auf False festgelegt ist, verarbeitet NCP nur Ingresses mit der Anmerkung kubernetes.io/ingress.class: "nsx". Die Standardeinstellung lautet True.
    Ab NCP 3.2.1 wird default_ingress_class_nsx nicht mehr unterstützt. NCP wird beim Auflösen der Ingress-Klasse Folgendes berücksichtigen:
    • Anmerkungen
    • ingressClass Objekte
    • Wenn keine Anmerkung angegeben ist und use_native_loadbalancer „True“ lautet, verarbeitet NSX-LB den Ingress. Andernfalls wird NSX-LB dies nicht verarbeiten.
Wenn Sie möchten, dass NCP dem NGINX-Controller-Pod eine dynamische IP-Adresse zuweist und den Status von Ingresses mit der dynamischen IP-Adresse aktualisiert, führen Sie die folgenden Schritte aus:
  • Legen Sie im Abschnitt k8s in ncp.ini den Wert ingress_mode=nat fest.
  • Fügen Sie dem NGINX-Ingress-Controller-Pod die Anmerkung ncp/ingress-controller: "True" hinzu.

NCP aktualisiert den Status von Dateneingängen, die die Anmerkung kubernetes.io/ingress.class: "nginx" aufweisen, mit der dynamischen IP-Adresse des NGINX-Ingress-Controller-Pods. Wenn default_ingress_class_nsx=False festgelegt ist, aktualisiert NCP auch den Status von Dateneingängen ohne die Anmerkung kubernetes.io/ingress.class mit der dynamischen IP-Adresse des NGINX-Ingress-Controller-Pods.

Hinweis: Selbst wenn der NGINX-Ingress-Controller-Pod nicht über die Anmerkung ncp/ingress-controller: "True" verfügt, aktualisiert NCP den Status der oben erwähnten Dateneingänge auf loadBalancer: {}. Die Dateneingänge könnten dann in einer Schleife festgehalten werden, in der der NGINX-Controller den Ingress-Status auf loadBalancer: {ingress: [{ip: <IP>}]} aktualisiert und NCP den Ingress-Status auf loadBalancer: {} aktualisiert. Um diese Situation zu vermeiden, führen Sie die folgenden Schritte aus:

Für Ingress-Controller von Drittanbietern, die im NAT-Modus ausgeführt werden, können Sie die Parameter http_ingress_port und https_ingress_port im Abschnitt k8s bearbeiten, um benutzerdefinierte Ports für die für den Ingress-Controller exponierten NAT-Regeln festzulegen.

Szenario 1: NCP verarbeitet Dateneingänge, ist aber nicht der standardmäßige Ingress-Controller.

Befolgen Sie dieses Verfahren, damit NCP die Ingresses von nsx-Klassen verarbeiten kann.
  1. Bearbeiten Sie den Abschnitt nsx_v3 in ncp.ini auf jedem Master-Knoten.
    1. Legen Sie default_ingress_class_nsx auf False fest.
    2. Lassen Sie use_native_loadbalancer auf True festgelegt. Dies ist der Standardwert.
  2. Starten Sie NCP auf jedem Master-Knoten neu. Dies kann zu einem Master-Failover führen.
  3. Fügen Sie allen Ingresses, die NCP verarbeiten soll, die Anmerkung kubernetes.io/ingress.class: "nsx" hinzu.

Szenario 2: NCP ist der standardmäßige Ingress-Controller.

Befolgen Sie dieses Verfahren:
  1. Es ist nicht erforderlich, ncp.ini zu bearbeiten, sondern es muss sichergestellt werden, dass alle Ingresses mit Anmerkungen versehen sind.
  2. Die von NCP zu verarbeitenden Dateneingänge sollten mit der Anmerkung kubernetes.io/ingress.class: "nsx" versehen werden.

    Obwohl NCP Dateneingänge ohne die Anmerkung kubernetes.io/ingress.class verarbeitet, besteht die bewährte Vorgehensweise bei mehreren Ingress-Controllern darin, immer über die Anmerkung kubernetes.io/ingress.class zu verfügen und sich nicht auf das Verhalten des standardmäßigen Ingress-Controllers zu verlassen.

  3. Dateneingänge, die von Drittanbieter-Ingress-Controllern verarbeitet werden, müssen als Anmerkung mit dem Wert versehen werden, der von diesen Ingress-Controllern benötigt wird.
Wichtig: Sofern es nicht das Ziel ist, NGINX als standardmäßigen Ingress-Controller festzulegen, verwenden Sie nginx nicht als NGINX-Ingress-Controller, da NGINX dadurch zum standardmäßigen Ingress-Controller wird.

Szenario 3: NCP verarbeitet unabhängig von der Anmerkung keinen Ingress.

Befolgen Sie dieses Verfahren:
  1. Bearbeiten Sie den Abschnitt nsx_v3 in ncp.ini auf jedem Master-Knoten.
    1. Legen Sie use_native_loadbalancer auf False fest. Der Wert default_ingress_class_nsx ist nun irrelevant.
  2. Starten Sie NCP auf jedem Master-Knoten neu. Dies kann zu einem Master-Failover führen.

Beachten Sie, dass NCP auch die Dienste vom Typ „LoadBalancer“ nicht verarbeitet.