NCP erstellt einen Load Balancer auf Schicht 7 für Ingresses mit TLS-Spezifikation und einen Load Balancer auf Schicht 7 für Ingresses ohne TLS-Spezifikation. Sie können auch CRDs (CustomResourceDefinitions) für die Ingress-Skalierung erstellen.

Beachten Sie Folgendes:
  • Alle Ingresses erhalten eine einzelne IP-Adresse.
  • Der Ingress-Ressource wird eine IP-Adresse aus dem externen IP-Pool zugeteilt, der durch die Option external_ip_pools im Abschnitt [nsx_v3] in ncp.ini angegeben ist. Der Load Balancer wird unter dieser IP-Adresse und auf den HTTP- und HTTPS-Ports (80 und 443) bereitgestellt.
  • Der Ingress-Ressource wird eine IP-Adresse aus dem externen IP-Pool zugeteilt, der durch die Option external_ip_pools_lb im Abschnitt [nsx_v3] in ncp.ini angegeben ist. Wenn die Option external_ip_pools_lb nicht vorhanden ist, wird der von external_ip_pools angegebene Pool verwendet. Der Load Balancer wird unter dieser IP-Adresse und auf den HTTP- und HTTPS-Ports (80 und 443) bereitgestellt.
  • Sie können zu einem anderen IP-Pool wechseln, indem Sie die Konfiguration ändern und NCP neu starten.
  • Sie können ein Standardzertifikat für TLS angeben. Informationen zum Erstellen eines Zertifikats sowie zum Mounten eines Zertifikats in den NCP-Pod finden Sie unten.
  • Ingresses ohne TLS-Spezifikation werden auf dem virtuellen HTTP-Server (Port 80) gehostet.
  • Ingresses mit TLS-Spezifikation werden auf dem virtuellen HTTPS-Server (Port 443) gehostet. Der Load Balancer fungiert als SSL-Server und beendet die SSL-Clientverbindung.
  • Eine Ingress-Änderung durch Hinzufügen oder Entfernen des TLS-Abschnitts wird nicht unterstützt. Nach dem Entfernen des tls-Schlüssels aus der Ingress-Spezifikation werden die Ingress-Regeln vom virtuellen HTTPS-Server (Port 443) auf den virtuellen HTTP-Server (Port 80) übertragen. Ebenso werden die Ingress-Regeln vom virtuellen HTTP-Server (Port 80) auf den virtuellen HTTPS-Server (Port 443) übertragen, wenn der tls-Schlüssel zur Ingress-Spezifikation hinzugefügt wird.
  • Wenn in Ingress-Definitionen für einen einzelnen Cluster doppelte Regeln vorliegen, wird nur die erste Regel angewendet. Die anderen Ingresses mit den doppelten Regeln werden mit einem Fehler kommentiert. Wenn Sie zum Beispiel zwei Ingresses mit identischen host und path erstellen, ein Ingresses TLS und der andere nicht-TLS ist, dabei kubernetes.io/ingress.allow-http gleich false ist, werden die beiden Regeln auf verschiedenen virtuellen Servern erstellt und stehen nicht in Konflikt miteinander. Wenn kubernetes.io/ingress.allow-http jedoch true ist, wird der später angewendete Ingress mit einem Fehler kommentiert. Weitere Informationen finden Sie im Abschnitt "Fehler" unten.
  • Pro Cluster wird nur ein einzelner Ingress mit einem Standard-Backend unterstützt. Datenverkehr, der mit keiner Ingress-Regel übereinstimmt, wird an das Standard-Backend weitergeleitet.
  • Wenn mehrere Ingresses mit einem Standard-Backend vorhanden sind, wird nur der erste konfiguriert. Die anderen erhalten eine Fehleranmerkung. Weitere Informationen finden Sie im Abschnitt "Fehler" unten.
  • (NCP 3.0.0 und 3.0.1) Die Regeln werden in der folgenden Reihenfolge angewendet:
    1. Regeln, bei denen host und path angegeben ist und die keine übereinstimmenden regulären Ausdrücke haben.
    2. Regeln, bei denen host und path angegeben ist und die übereinstimmende reguläre Ausdrücke haben (mit dem längsten Ingress path zuerst).
    3. Regeln, bei denen host oder path angegeben ist und die keine übereinstimmenden regulären Ausdrücke haben.
    4. Regeln, bei denen host oder path angegeben ist und die übereinstimmende reguläre Ausdrücke haben (mit dem längsten Ingress path zuerst).
  • (NCP 3.0.2 und höher) Die Regeln werden in der folgenden Reihenfolge angewendet:
    1. Regeln sowohl mit host als auch path angegeben.
      1. Regeln mit dem Exact pathType.
      2. Regeln mit dem Prefix pathType.
      3. Regeln mit dem Regex pathType.
    2. Regeln mit host oder path angegeben.
      1. Regeln mit dem Exact pathType.
      2. Regeln mit dem Prefix pathType.
      3. Regeln mit dem Regex pathType.

    Hinweis: Wenn mehrere Pfade einer Anforderung entsprechen, wird dem längsten übereinstimmenden Pfad Vorrang eingeräumt.

    Informationen zu pathType:
    • ImplementationSpecific wird genauso behandelt wie Exact.
    • Zwei passende Pfade mit unterschiedlichen pathTypen können nebeneinander vorhanden sein.
    • Für den Prefix-Typ stimmt /foo mit /foo/ überein, /foo/bar, aber nicht /foo bzw. /foobar. Um mit /foo übereinzustimmen, fügen Sie den Exact-Pfad /foo zur Ingress-Regel hinzu.
  • (Dies ist anwendbar, wenn Sie den Richtlinienmodus verwenden.) Wenn ein TLS-Ingress mit einem standardmäßigen Backend erstellt wird, sollten Sie aus folgenden Gründen das standardmäßige Backend so einrichten, dass es sowohl auf HTTP als auch auf HTTPS-Anforderungen reagiert:
    • Der Load Balancer beendet TLS und sendet HTTP-Anforderungen an den standardmäßigen Backend-Server, wenn TLS-Ingress (im Cluster für das Anwendungsbeispiel „Kubernetes/PKS“ oder im selben Namespace für das Anwendungsbeispiel „Project Pacific“) mit dem Host vorhanden ist, der dem Host in der Anforderung entspricht.
    • Der Load Balancer verschlüsselt die HTTPS-Anforderung neu und sendet sie an den standardmäßigen Backend-Server, wenn kein TLS-Ingress (im Cluster für das Anwendungsbeispiel „Kubernetes/PKS“ oder im selben Namespace für das Anwendungsbeispiel „Project Pacific“) mit dem Host vorhanden ist, der dem Host in der Anforderung entspricht.
  • Die IngressClass-Ressource wird nicht unterstützt.
  • (NCP 3.0.0 und 3.0.1) Das pathType-Attribut wird nicht unterstützt.
  • (NCP 3.0.2 und höher) Das pathType-Attribut wird unterstützt.
  • (NCP 3.0.2 und höher) Die Clientauthentifizierung JWT (JSON Web Token) wird unterstützt. Für diese Funktion ist NSX-T Data Center 3.0.0 oder höher erforderlich.

Funktions Anmerkungen

In der folgenden Tabelle sind die von NCP unterstützten Anmerkungen aufgeführt:
Anmerkung Beschreibung Unterstützte Werte Standardwert NCP-Version
kubernetes.io/ingress.allow-http Aktiviert HTTP-Anforderungen zusätzlich zu HTTPS true, false true 2.5 und höher
ncp/use-regex Aktiviert Pfad Musterübereinstimmung true, false false 2.5.1 und höher
ingress.kubernetes.io/rewrite-target Der Pfad der eingehenden Anforderung wird neu geschrieben
  • (NCP 2.5 und höher) Pfad, der mit „/“ beginnt
  • (NCP 2.5.1 und höher und NSX-T 2.5.1) Pfad mit einem nummerierten Platzhalter für eine Gruppe, die in einem regulären Ausdruck erfasst wird, z. B. /$1
Kein Standardwert Siehe Spalte „Unterstützte Werte“
ncp/http-redirect Leitet HTTP-Anforderungen an HTTPS weiter true, false false 2.5.1 und höher
kubernetes.io/ingress.class Gibt an, welche Ingress-Steuerung für diesen Ingress verantwortlich ist nsx, nginx usw. nsx 2.5 und höher
nsx/loadbalancer Platziert einen Ingress auf einem dedizierten Load Balancer Name einer LoadBalancer-CRD Kein Standardwert 2.5.1 und höher
ncp/whitelist-source-range Begrenzt den Ingress-Zugriff nach IP der Anforderungsquelle Kommagetrennte Liste der CIDRs, IP-Adressen oder IP-Bereiche. Kein Standardwert 3.0.0 und höher
ncp/ssl-mode Legt den SSL-Modus für alle Regeln in einem Ingress fest. offload, reencrypt, passthrough offload 3.0.1 und höher
ncp/jwt-alg Legt fest, welcher Algorithmus zum Validieren der JWT-Signatur verwendet werden soll. Aktiviert die JWT-Clientauthentifizierung, wenn mit ncp/jwt-secret festgelegt. HS256, RS256 Kein Standardwert 3.0.2 und höher
ncp/jwt-secret Gibt den Namen des Kubernetes-Geheimnisses an, der den für die Signaturvalidierung verwendeten JWT- oder öffentlichen Schlüssel enthält. Aktiviert die JWT-Clientauthentifizierung, wenn mit ncp/jwt-alg festgelegt. Name eines Kubernetes-Geheimnisses Kein Standardwert 3.0.2 und höher
ncp/jwt-token Zusätzlicher Speicherort für die Suche nach JWT in der HTTP-Anfrage. _arg_<param_name>, _cookie_<cookie_name> Kein Standardwert 3.0.2 und höher
ncp/jwt-realm Gibt den Realm-Header an, der mit 401 zurückgegeben wird, wenn die Authentifizierung fehlgeschlagen ist. Zeichenfolge, die den Bereich angibt Hostname der Ingress-Regel 3.0.2 und höher
ncp/jwt-preserve Option, um JWT beizubehalten und nach erfolgreicher Authentifizierung an Backend zu übergeben. true, false true 3.0.2 und höher
Details zu den Anmerkungen:
  • Übereinstimmender Pfad-Regex (regulärer Ausdruck)
    • Für NCP 2.5.0 und früher

      In NCP 2.5.0 und früher werden alle Abgleiche von Unterpfaden automatisch mit den Zeichen für einen regulären Ausdruck '.' und '*' aktiviert. Beispielsweise entspricht der Pfad /coffee/.* dem Pfad /coffee/ gefolgt von NULL, einem oder mehreren Zeichen, z. B. /coffee/, /coffee/a und /coffee/b, aber nicht /coffee, /coffeecup oder /coffeecup/a.

      Beispiel für eine Ingress-Spezifikation:
      kind: Ingress
      metadata:
        name: cafe-ingress
      spec:
        rules:
        - http:
            paths:
            - path: /coffee/.*    #Matches /coffee/, /coffee/a but NOT /coffee, /coffeecup, etc.
              backend:
                serviceName: coffee-svc
                servicePort: 80
    • Für NCP 2.5.1 und höher
      Sie können den Abgleich mit regulärem Ausdruck für den Ingress-Parameter path (aber nicht host) mithilfe der Anmerkung ncp/use-regex aktivieren oder deaktivieren. Wenn der Wert auf false festgelegt ist, wird der genaue Pfad Abgleich durchgeführt, indem die equals übereinstimmen. Wenn der Wert auf true festgelegt ist, wird die Übereinstimmung mit regulärem Ausdruck durch Hinzufügen des Zeichenfolgen Zeichens (^) und des Zeichenfolgen Zeichens ($) zum Pfad so durchgeführt, dass der gesamte Anforderungs-URI mit dem Muster übereinstimmt. Beachten Sie, dass bei Verwendung des OR-Operators (|) der Geltungsbereich immer mit Klammern angegeben wird, damit ^ und $ auf alle Operanden angewendet werden. Beispiel: path: /(tea|coffee|milk). Beispiel für eine Ingress-Spezifikation:
      kind: Ingress
      metadata:
        name: cafe-ingress
        annotations:
          kubernetes.io/ingress.class: "nsx"
          ncp/use-regex: "true"
      spec:
        rules:
        - host: cafe.example.com
          http:
            paths:
            - path: /tea/.*
              backend:
                serviceName: tea-svc
                servicePort: 80
    • Aktualisieren der Ingresses vor dem Upgrade von NCP auf 2.5.1 oder höher
      Dies ist nur erforderlich, wenn Sie über Ingresses verfügen, die alle einen Abgleich der Unterpfade mithilfe der Zeichen '.' und '*' erfordern.
      1. Aktualisieren Sie die Ingresses, um die Anmerkung ncp/use-regex: true einzubeziehen.
      2. Wenn Sie für alle unter Pfad Übereinstimmungen Pfade wie /coffee/* oder /* haben, ändern Sie sie in /coffee/.* und /.*.

        /coffee/.* werden mit /coffee/, /coffee/a, /coffee/b, /coffee/a/b usw. übereinstimmen. /.* werden mit /coffee, /tea, /coffee/a usw. übereinstimmen. Das Weglassen des Pfads führt zu demselben Verhalten wie path: /.*.

  • Beispiel für die Anmerkung ingress.kubernetes.io/rewrite-target:
    kind: Ingress
    metadata:
      name: cafe-ingress
      annotations:
        ingress.kubernetes.io/rewrite-target: /
    spec:
      rules:
      - host: cafe.example.com
        http:
          paths:
          - path: /tea
            backend:
              serviceName: tea-svc
              servicePort: 80
          - path: /coffee
            backend:
              serviceName: coffee-svc
              servicePort: 80

    Die Pfade /tea und /coffee werden in / umgeschrieben, bevor die URL an den Backend-Dienst gesendet wird.

    Ab NCP 2.5.1 und NSX-T 2.5.1 werden die erfassten Gruppen in den nummerierten Platzhaltern im Format $1, $2 usw. gespeichert, wenn path mit einem regulären Ausdruck angegeben wird. Diese Platzhalter können als Parameter in der Anmerkung ingress.kubernetes.io/rewrite-target verwendet werden. Benannte Erfassungsgruppen und benannte Platzhalter werden nicht unterstützt. Beispiel:
    kind: Ingress
    metadata:
      name: cafe-ingress
      annotations:
        kubernetes.io/ingress.class: "nsx"
        ncp/use-regex: "true"
        #/tea/cup will be rewritten to /cup before sending request to endpoint
        ingress.kubernetes.io/rewrite-target: /$1
    spec:
      rules:
      - host: cafe.example.com
        http:
          paths:
          - path: /tea/(.*)
            backend:
              serviceName: tea-svc
              servicePort: 80
  • Informationen zur Anmerkung kubernetes.io/ingress.allow-http:
    • Wenn die Anmerkung auf false festgelegt ist, werden Regeln für den virtuellen HTTPS-Server erstellt.
    • Wenn die Anmerkung auf true festgelegt ist oder fehlt, werden Regeln sowohl für virtuelle HTTP- als auch HTTPS-Server erstellt. HTTPS-Regeln werden nur erstellt, wenn der TLS-Abschnitt in der Ingress-Spezifikation vorhanden ist.
  • Informationen zur Anmerkung ncp/http-redirect:
    • Wenn die Anmerkung auf false festgelegt ist, wird der eingehende HTTP-Datenverkehr (Port 80) zum virtuellen HTTP-Server nicht zum virtuellen HTTPS-Server umgeleitet.
    • Wenn die Anmerkung auf true festgelegt ist, wird der eingehende HTTP-Datenverkehr (Port 80) zum virtuellen HTTP-Server zum virtuellen HTTPS-Server (Port 443) umgeleitet.

    Diese Anmerkung ist nur gültig, wenn der TLS-Abschnitt vorhanden ist. Diese Anmerkung hat Vorrang vor kubernetes.io/ingress.allow-http. Wenn der Wert auf true festgelegt ist, wird der übereinstimmende HTTP-Datenverkehr an HTTPS weitergeleitet, unabhängig davon, wie kubernetes.io/ingress.allow-http festgelegt ist.

  • Informationen zur Anmerkung kubernetes.io/ingress.class:
    • Wenn der Wert nsx ist, wird dieser Ingress von NCP verarbeitet. Wenn ein anderer Wert angegeben ist, wird der Ingress von NCP ignoriert. Weitere Informationen finden Sie unter Ingress-Controller von Drittanbietern.
  • Weitere Informationen zur Anmerkung nsx/loadbalancer finden Sie unter LoadBalancer-CRDs zum Verarbeiten der Ingress-Skalierung.
  • Informationen zur Anmerkung ncp/whitelist-source-range:
    • Wenn diese Einstellung festgelegt ist, wird eine eingehende Anforderung nur akzeptiert, wenn die Quell-IP in dieser Anmerkung enthalten ist. Andernfalls wird der Datenverkehr verworfen.
    • Sie können eine Kombination aus CIDR, IP-Adressen und IP-Bereichen angeben. Beispiel: 1.1.1.1/24, 2.2.2.2, 3.3.3.3-4.4.4.4.
    • Beispiel-YAML:
      kind: Ingress
      metadata:
        name: cafe-ingress
        annotations:
          kubernetes.io/ingress.class: "nsx"
          ncp/whitelist-source-range: "192.168.128.0/17, 192.168.64.0-192.168.64.255, 192.168.16.32"
      spec:
        tls:
        - hosts:
          - cafe.example.com
        rules:
        - host: cafe.example.com
          http:
            paths:
            - path: /tea
              backend:
                serviceName: tea-svc
                servicePort: 80
  • Informationen zur Anmerkung ncp/ssl-mode:
    • Diese Anmerkung gilt für alle Regeln in einem Ingress, und der Lastausgleichsdienst wird im ausgewählten SSL-Modus für diese Regeln ausgeführt.

      Hinweis: Diese Anmerkung kann nicht auf passthrough festgelegt werden, wenn die Anmerkung ingress.kubernetes.io/rewrite-target, ncp/use-regex oder ncp/whitelist-source-range festgelegt ist.

  • Informationen zu JWT-Clientauthentifizierung:
    • Um die JWT-Clientauthentifizierungsmethode für alle Regeln unter einem Ingress zu aktivieren, müssen sowohl ncp/jwt-alg als auch ncp/jwt-secret auf einen gültigen Wert festgelegt werden. Wenn diese Option aktiviert ist, wird der eingehende HTTP-Datenverkehr nur dann an das Backend übergeben, wenn er ein gültiges JSON-Webtoken enthält. Andernfalls wird der Datenverkehr mit dem Status 401 abgelehnt.
    • Diese Funktionen sind mit den folgenden Anmerkungen nicht kompatibel:
      • kubernetes.io/ingress.allow-http: true
      • ncp/http-redirect: true
      • ncp/ssl-mode: passthrough
    • ncp/jwt-alg:
      • Unterstützte symmetrische Algorithmen: HS256
      • Unterstützte asymmetrische Algorithmen: RS256
    • ncp/jwt-secret:
      • Ein symmetrischer Schlüssel oder öffentliches Zertifikat muss in einem Kubernetes-Geheimnis mit dem Namen konfiguriert werden, der in dieser Anmerkung unter demselben Namespace wie der Ingress angegeben ist.
      • Bei symmetrischen Algorithmen muss das Geheimnis im Feld jwt.key gespeichert werden.
      • Bei asymmetrischen Algorithmen muss das öffentliche Zertifikat im Feld tls.crt gespeichert werden.
      • Die JWT-Clientauthentifizierung wird deaktiviert, wenn das symmetrische Geheimnis oder öffentliche Zertifikat nicht in den oben erwähnten Speicherorten gespeichert ist oder wenn die im Geheimnis gespeicherten Daten ungültig sind.
    • ncp/jwt-token:
      • In dieser Anmerkung kann nur ein Element konfiguriert werden.
      • _arg_<param_name>: Für JWT als URI-Parameter übergeben. Geben Sie den Parameternamen an, der JWT enthält.
      • _cookie_<cookie_name>: Für JWT als Cookie übergeben. Geben Sie den Cookienamen an, der JWT enthält.

Fehler

Fehler werden in der Ingress-Ressource als Anmerkung dokumentiert. Der Fehlerschlüssel lautet ncp/error.loadbalancer, der Schlüssel für Warnungen ncp/warning.loadbalancer. Dies sind die möglichen Fehler und Warnungen:
  • ncp/error.loadbalancer: DEFAULT_BACKEND_IN_USE

    Dieser Fehler weist darauf hin, dass bereits ein Ingress mit einem Standard-Back-End vorhanden ist. Der Ingress ist dann inaktiv. Dieser Fehler tritt auf, wenn (1) dieser Ingress für HTTP und ein weiterer Ingress für HTTP mit einem Standard-Backend existiert; (2) dieser Ingress für HTTPS und ein weiterer Ingress für HTTPS mit einem Standard-Backend existiert; oder (3) dieser Ingress für HTTP und HTTPS und ein weiterer Ingress für HTTP und HTTPS mit einem Standard-Backend existiert. Um den Fehler zu beheben, löschen Sie den Ingress und erstellen Sie ihn mit einer korrekten Spezifikation neu.

  • ncp/warning.loadbalancer: SECRET_NOT_FOUND

    Dieser Fehler weist darauf hin, dass das in der Ingress-Spezifikation angegebene Geheimnis nicht vorhanden ist oder wenn ncp/jwt-alg und ncp/jwt-secret neu zugeordnet werden, aber das Geheimnis nicht im selben Namespace wie der Ingress gefunden werden kann. Der Ingress ist dann nur teilweise aktiv. Um den Fehler zu beheben, erstellen Sie den fehlenden geheimen Schlüssel. Beachten Sie, dass eine Warnung in der Anmerkung während des Lebenszyklus der Ingress-Ressource nicht gelöscht wird.

  • ncp/warning.loadbalancer: INVALID_INGRESS
    Dieser Fehler weist darauf hin, dass eine der folgenden Bedingungen wahr ist. Der Ingress ist dann inaktiv. Um den Fehler zu beheben, löschen Sie den Ingress und erstellen Sie ihn mit einer korrekten Spezifikation neu.
    • Eine Ingress-Regel steht im Konflikt mit einer anderen Ingress-Regel im selben Kubernetes-Cluster. Konflikte werden nur noch für Ingresses mit der gleichen Abgleichstrategie, d. h. dem gleichen Wert für die Anmerkung ncp/use-regex, ermittelt.
    • Die Anmerkung kubernetes.io/ingress.allow-http wird auf false gesetzt, und der Ingress hat keinen TLS-Abschnitt.
    • Die Anmerkung ncp/http-redirect wird auf true gesetzt, und der Ingress hat keinen TLS-Abschnitt.
    • Bei einer Ingress-Regel sind host und path nicht angegeben. Eine Ingress-Regel dieser Art weist dieselbe Funktionalität wie das Ingress-Standard-Backend auf. Verwenden Sie stattdessen das Ingress-Standard-Backend.
    • Der Ingress weist JWL-Anmerkungen auf, die nicht korrekt verarbeitet werden können. Beispiel:
      • Entweder ncp/jwt-alg oder ncp/jwt-secret fehlt.
      • ncp/jwt-alg ist mit einem nicht unterstützten Algorithmus konfiguriert.
      • ncp/jwt-alg und ncp/jwt-secret sind mit anderen HTTP-aktivierenden Anmerkungen oder mit SSL-Passthrough konfiguriert.