Netzwerk zwischen Kubernetes-Knoten und Ingress NetScaler mithilfe des Node Controllers einrichten

Last published : Oct 02, 2026
In Kubernetes-Umgebungen müssen Sie, wenn Sie die Dienste für den externen Zugriff über das Ingress-Gerät bereitstellen, das Netzwerk zwischen den Kubernetes-Knoten und dem Ingress-Gerät entsprechend konfigurieren.
Die Netzwerkkonfiguration ist eine Herausforderung, da die Pods private IP-Adressen basierend auf dem CNI-Framework verwenden. Ohne eine ordnungsgemäße Netzwerkkonfiguration kann das Ingress-Gerät diese privaten IP-Adressen nicht erreichen. Außerdem ist die manuelle Konfiguration des Netzwerks, um eine solche Erreichbarkeit sicherzustellen, in Kubernetes-Umgebungen umständlich.
Wenn sich der Kubernetes-Cluster und der Ingress NetScaler® in verschiedenen Subnetzen befinden, können Sie keine Route zwischen ihnen mithilfe von statischer Routenführung herstellen. Dieses Szenario erfordert einen Overlay-Mechanismus, um eine Route zwischen dem Kubernetes-Cluster und dem Ingress NetScaler herzustellen.
NetScaler bietet einen Node Controller, den Sie verwenden können, um ein auf Virtual Extensible LAN (VXLAN) basierendes Overlay-Netzwerk zwischen den Kubernetes-Knoten und dem Ingress NetScaler zu erstellen, wie im folgenden Diagramm dargestellt:
CIC mit CNC
Hinweis:
Der NetScaler Node Controller funktioniert nicht in einer Konfiguration, in der ein NetScaler-Cluster als Ingress-Gerät konfiguriert ist. Der Node Controller erfordert die Einrichtung eines VXLAN-Tunnels zwischen NetScaler und Kubernetes-Knoten, um Routen zu konfigurieren, und die Erstellung eines VXLAN auf einem NetScaler-Cluster wird nicht unterstützt.
Related information
Netzwerk

Selbstheilende Router-Pods und native Integritätsprüfungen

Ab NetScaler Node Controller Version 3.1.0 können Sie einen kube-cnc-router Pod pro berechtigtem Knoten bereitstellen, um das VXLAN-Overlay zwischen diesem Knoten und NetScaler aufzubauen. Diese Verbesserung macht diese Flotte selbstheilend und fügt Kubernetes-native Integritätsprüfungen hinzu, sodass ein einzelner Knoten, der sich von einem vorübergehenden Problem erholt, keine manuelle Aktion erfordert.
Mit dieser Funktion erhalten Sie:
  • Selbstheilung pro Knoten – wenn ein Router-Pod auf einem Knoten gelöscht wird oder fehlschlägt, erstellt der Controller nur den Pod dieses Knotens neu. Kein Controller-Neustart, keine Auswirkungen auf andere Knoten.
  • Native Liveness-/Readiness-Probes sowohl auf dem Node Controller als auch auf den Router-Pods.
  • Stabile VTEP-IP – ein Knoten behält dieselbe Overlay-IP über Pod-Neuerstellungen und Controller-Neustarts hinweg, sodass sich der ADC PBR Next-Hop nicht ändert.
Zuvor überwachte der Controller nur Knotenereignisse und nutzte das Vorhandensein eines Host-<nodeId> Schlüssels in der Router-ConfigMap als Beweis für die Existenz des Pods. Wenn ein Router-Pod entfernt wurde (z. B. nach einem kurzen Netzwerkausfall eines Knotens), blieb der Schlüssel erhalten, sodass der Controller Update not required as pod entry found in cmap protokollierte und den Pod nie neu erstellte. Die einzige Abhilfe war der Neustart des Node Controllers, der jeden Router-Pod im Cluster neu erstellt – was für gesunde Knoten störend ist.

Funktionsweise dieser Funktion

  • Selbstheilung: Ein Pod-Lebenszyklus-Watcher erstellt den Pod für einen Knoten bei Löschung, Fehler oder im Status 'stuck-Pending' neu (nachdem erneut überprüft wurde, ob der Knoten existiert, bereit ist und die Taints des Knotens toleriert).
  • Zustandsprüfungen: Node Controller — Bereitschaft = Informer-Caches synchronisiert, Lebendigkeit = interner Heartbeat aktuell. Router-Pod — Bereitschaft = Overlay-Einrichtung abgeschlossen, Lebendigkeit = VXLAN-Schnittstelle existiert und hält ihre Adresse (oder der Pod ist absichtlich geparkt).
  • Stabile VTEP-IP: Die VTEP-CIDR jedes Knotens wird in einer dedizierten <router-configmap-name>-vtep ConfigMap aufgezeichnet und bei jeder Neuerstellung/jedem Neustart wiederverwendet; sie wird nur freigegeben, wenn der Knoten gelöscht wird.

Voraussetzungen

  • Die Kubernetes Version 1.6 oder höher, wenn Sie eine Kubernetes-Umgebung verwenden.
  • Die OpenShift Version 4.8 oder höher, wenn Sie die OpenShift-Plattform verwenden.
  • Die Helm Version 2.x oder höher. Sie können den Anweisungen unter Helm Installation folgen, um diese zu installieren.
  • Sie bestimmen die Ingress NetScaler IP-Adresse, die der Controller benötigt, um mit NetScaler zu kommunizieren. Die IP-Adresse kann je nach Art der NetScaler-Bereitstellung eine der folgenden sein:
    • (Standalone-Appliances) NSIP – Die Management-IP-Adresse eines Standalone-NetScalers. Weitere Informationen finden Sie unter IP Addressing in NetScaler.
    • (Appliances im Hochverfügbarkeitsmodus) SNIP – Die Subnetz-IP-Adresse. Weitere Informationen finden Sie unter IP Addressing in NetScaler.
  • Sie bestimmen die Ingress NetScaler SNIP. Diese IP-Adresse wird verwendet, um ein Overlay-Netzwerk zwischen den Kubernetes-Clustern herzustellen, das der Controller benötigt, um mit NetScaler zu kommunizieren.
  • Der Benutzername und das Kennwort der NetScaler VPX- oder MPX-Appliance, die als Ingress-Gerät verwendet wird. Der NetScaler muss über ein Systembenutzerkonto (nicht Standard) mit bestimmten Berechtigungen verfügen, damit der Node Controller die NetScaler VPX- oder MPX-Appliance konfigurieren kann. Anweisungen zum Erstellen des Systembenutzerkontos auf NetScaler finden Sie unter Create System User Account for NSNC in NetScaler.
    Sie müssen den Benutzernamen und das Kennwort mithilfe von Kubernetes-Secrets übergeben. Erstellen Sie ein Kubernetes-Secret für den Benutzernamen und das Kennwort mit dem folgenden Befehl:
    kubectl create secret generic nsloginns --from-literal=username='nsnc' --from-literal=password='mypassword'

Systembenutzerkonto für NetScaler Node Controller in NetScaler erstellen

Der Node-Controller konfiguriert den NetScaler mithilfe eines Systembenutzerkontos von NetScaler. Das Systembenutzerkonto muss bestimmte Berechtigungen haben, damit der NSNC Folgendes auf NetScaler konfigurieren kann:
  • Routen hinzufügen, löschen oder anzeigen
  • ARP hinzufügen, löschen oder anzeigen
  • VXLAN hinzufügen, löschen oder anzeigen
  • IP hinzufügen, löschen oder anzeigen
Hinweis:
Das Systembenutzerkonto muss Berechtigungen haben, die auf der von Ihnen definierten Befehlsrichtlinie basieren.
Um das Systembenutzerkonto zu erstellen, führen Sie folgende Schritte aus:
  1. Melden Sie sich bei der NetScaler-Appliance an. Führen Sie Folgendes aus:
    1. Verwenden Sie einen SSH-Client, wie z. B. PuTTy, um eine SSH-Verbindung zur NetScaler-Appliance zu öffnen.
    2. Melden Sie sich mit den Administratoranmeldeinformationen bei der Appliance an.
  2. Erstellen Sie das Systembenutzerkonto mithilfe des folgenden Befehls:
    add system user <username> <password>
    Zum Beispiel:
    add system user nsnc mypassword
  3. Erstellen Sie eine Richtlinie, um dem Systembenutzerkonto die erforderlichen Berechtigungen bereitzustellen. Verwenden Sie den folgenden Befehl:
    add cmdpolicy nsnc-policy ALLOW  (^\S+\s+arp)|(^\S+\s+arp\s+.*)|(^\S+\s+route)|(^\S+\s+route\s+.*)|(^\S+\s+vxlan)|(^\S+\s+vxlan\s+.*)|(^\S+\s+ns\s+ip)|(^\S+\s+ns\s+ip\s+.*)|(^\S+\s+bridgetable)|(^\S+\s+bridgetable\s+.*)
  4. Binden Sie die Richtlinie mithilfe des folgenden Befehls an das Systembenutzerkonto:
    bind system user nsnc nsnc-policy 0

NetScaler Node Controller bereitstellen

Um die Netzwerkkonnektivität mithilfe des Node Controllers herzustellen:
  1. Stellen Sie den NetScaler Ingress Controller bereit. Führen Sie die folgenden Schritte aus:
    1. Fügen Sie das Helm-Chart-Repository des Node Controllers mithilfe des Befehls hinzu:
      helm repo add netscaler https://netscaler.github.io/netscaler-helm-charts/
    2. Um das Chart mit dem Releasenamen, nsnc, zu installieren, verwenden Sie den folgenden Befehl:
      helm install nsnc netscaler/netscaler-node-controller --set license.accept=yes,nsIP=<NSIP>,vtepIP=<NetScaler SNIP>,vxlan.id=<VXLAN ID>,vxlan.port=<VXLAN PORT>,network=<IP-address-range-for-VTEP-overlay>,adcCredentialSecret=<Secret-for-NetScaler-credentials>
      Oder Sie können die values.yaml-Datei wie hiernach gezeigt erstellen und den folgenden Befehl verwenden:
      helm install nsnc netscaler/netscaler-node-controller -f values.yaml
      Values.yaml
      adcCredentialSecret: "nsloginns" # Kubernetes Secret created for login into Netscaler as mentioned in pre-requisite section.
      clusterName: "" # For e.g. "cluster1", provide the name of the cluster, provide same cluster name in NetScaler Ingress Controller deployment as well.
      cniType: "" # provide the CNI supported (canal, flannel, Calico, cilium, weave)
      license:
        accept: 'yes'
      network: "<network>" #for e.g. 172.16.3.0/24 # Give a network IP not conflicting with pod IP range and cluster IP range
      nsIP: <IP-ADDRESS>  # Management IP of the NetScaler (can be NSIP or SNIP with management access enabled for HA and CLIP for cluster)
      vtepIP: <IP-ADDRESS>  # SNIP IP of the NetScaler
      healthProbes:
        enabled: true
      vxlan:
        id: <ID> # VXLAN ID that you want to use
        port: <PORT> # VXLAN PORT that you want to use
      Hinweis:
      Der Parameter healthProbes.enabled steuert, ob Kubernetes Liveness- und Readiness-Probes zum Node Controller hinzugefügt werden. Diese Probes ermöglichen es Kubernetes, einen fehlerhaften Controller automatisch zu erkennen und neu zu starten. Der Parameter ist standardmäßig aktiviert (true) und erfordert die Node Controller Image-Version 3.1.0 oder höher. Wenn Sie eine frühere Image-Version verwenden, setzen Sie diesen Parameter auf false.
      Weitere Informationen zu den verschiedenen Argumenten finden Sie unter Obligatorische und optionale Parameter.
  2. Überprüfen Sie die Bereitstellung.
Nachdem Sie den Node Controller bereitgestellt haben, können Sie überprüfen, ob der Node Controller eine Route auf dem NetScaler konfiguriert hat.
Zur Überprüfung melden Sie sich am NetScaler an und verwenden Sie die folgenden Befehle, um die vom Node Controller auf dem NetScaler konfigurierten VXLAN VNID, VXLAN PORT, SNIP, Route und Bridgetable zu überprüfen:
Überprüfung
Überprüfung
Die Hervorhebungen im Screenshot zeigen die VXLAN VNID, den VXLAN PORT, SNIP, die Route und die Bridgetable, die vom Node-Controller auf NetScaler konfiguriert wurden.

Cluster-Bereitstellungen überprüfen

Abgesehen von der netscaler-node-controller-Bereitstellung werden auch einige andere Ressourcen erstellt.
  • Im Namespace, in dem NSNC bereitgestellt ist:
    • Für jeden Worker-Knoten ein kube-cnc-router-Pod.
    • Eine ConfigMap kube-cnc-router.
Verifizierung
Auf jedem der Worker-Knoten werden eine Schnittstelle cncvxlan<hash-of-namespace> und eine iptables-Regel erstellt.
Verifizierung Verifizierung
# Delete one node's router pod; a replacement appears within ~30s, other nodes are
# untouched, and the new pod keeps the same VTEP IP.
kubectl delete pod kube-cnc-router-<nodeId> -n <namespace>
kubectl get pods -n <namespace> -w

# The per-node IP allocation survives recreates/restarts
kubectl get configmap <router-configmap-name>-vtep -n <namespace> -o yaml

# Probes on the pod spec
kubectl describe pod <pod> -n <namespace> | grep -A2 -E 'Liveness|Readiness'

NetScaler Kubernetes Node-Controller löschen

helm delete nsnc

NetScaler Node-Controller ohne Internetzugang ausführen

Der Node-Controller erstellt intern Hilfs-Pods (kube-cnc-router-Pods) auf jedem Kubernetes-Cluster-Knoten. Das standardmäßig verwendete Image ist quay.io/citrix/cnc-router:1.1.0, das Internetzugang erfordert. Wenn die Kubernetes-Knoten keinen Internetzugang haben, schlägt die Erstellung von kube-cnc-router-Pods fehl.
NetScaler bietet jedoch eine Möglichkeit, auf das Image aus Ihrem internen Repository zuzugreifen, sodass Sie den Node-Controller ohne Internetzugang ausführen können. Mithilfe der Umgebungsvariablen CNC_ROUTER_IMAGE können Sie auf das interne Repository-Image von quay.io/citrix/cnc-router:1.1.0 verweisen.

NetScaler Node-Controller zur Verwendung eines Images aus dem internen Repository konfigurieren

Wenn Sie den Node-Controller bereitstellen, geben Sie die Umgebungsvariable CNC_ROUTER_IMAGE an und legen Sie den Wert der Variablen als Ihren internen Repository-Pfad für das Image quay.io/citrix/cnc-router:1.1.0 fest.
Wenn Sie diese Umgebungsvariable angeben, verwendet der Node Controller das interne Repository-Image, das von der Umgebungsvariablen CNC_ROUTER_IMAGE bereitgestellt wird, um die kube-cnc-router Helfer-Pods zu erstellen. Wenn die Umgebungsvariable nicht angegeben ist, verwendet er das Standard-Image quay.io/citrix/cnc-router:1.1.0, das Internetzugang erfordert. Legen Sie nsncRouterImage fest, während Sie den Node Controller bereitstellen.
nsncRouterImage: "quay.io/citrix/cnc-router"

Mehrere NetScaler Node Controller im selben Cluster ausführen

Wenn Sie mehrere Node Controller im selben Cluster bereitstellen möchten, verwenden Sie einen anderen Namen für CNC_ROUTER_NAME, indem Sie das folgende Argument beim Bereitstellen des Node Controllers festlegen.
nsncRouterName: "abc-nsnc-router"
Zur Fehlerbehebung bei der Bereitstellung des Node Controllers, siehe Fehlerbehebung beim Node Controller