NCP erstellt einen Load Balancer auf Schicht 7 für Dateneingänge mit TLS-Spezifikation und einen Load Balancer auf Schicht 7 für Dateneingänge ohne TLS-Spezifikation. Ab NCP 2.5.1 können Sie auch CRDs (CustomResourceDefinitions) für die Skalierung des eingehenden Datenverkehrs erstellen.
Beachten Sie Folgendes:
- Alle Dateneingänge 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.
- Dateneingänge ohne TLS-Spezifikation werden auf dem virtuellen HTTP-Server (Port 80) gehostet.
- Dateneingänge 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 Änderung des Dateneingangs durch Hinzufügen oder Entfernen eines 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 Dateneingangsdefinitionen für einen einzelnen Cluster doppelte Regeln vorliegen, wird nur die erste Regel angewendet. Die anderen Dateneingänge mit den doppelten Regeln werden mit einem Fehler kommentiert. Wenn Sie zum Beispiel zwei Dateneingänge mit identischen host und path erstellen, ein Dateneingang 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 Dateneingang mit einem Fehler kommentiert. Weitere Informationen finden Sie im Abschnitt "Fehler" unten.
- Pro Cluster wird nur ein einzelner Dateneingang mit einem Standard-Backend unterstützt. Datenverkehr, der mit keiner Ingress-Regel übereinstimmt, wird an das Standard-Backend weitergeleitet.
- Wenn mehrere Dateneingänge mit einem Standard-Backend vorhanden sind, wird nur der erste konfiguriert. Die anderen erhalten eine Fehleranmerkung. Weitere Informationen finden Sie im Abschnitt "Fehler" unten.
- Die Regeln werden in der folgenden Reihenfolge angewendet:
- Regeln, bei denen host und path angegeben ist und die keine übereinstimmenden regulären Ausdrücke haben.
- Regeln, bei denen host und path angegeben ist und die übereinstimmende reguläre Ausdrücke haben (mit dem längsten Dateneingang path zuerst).
- Regeln, bei denen host oder path angegeben ist und die keine übereinstimmenden regulären Ausdrücke haben.
- Regeln, bei denen host oder path angegeben ist und die übereinstimmende reguläre Ausdrücke haben (mit dem längsten Dateneingang path zuerst).
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, 2.5.1 |
| ncp/use-regex | Aktiviert Pfad Musterübereinstimmung | true, false | false | 2.5.1 |
| ingress.kubernetes.io/rewrite-target | Der Pfad der eingehenden Anforderung wird neu geschrieben |
|
Kein Standardwert | Siehe Spalte „Unterstützte Werte“ |
| ncp/http-redirect | Leitet HTTP-Anforderungen an HTTPS weiter | true, false | false | 2.5.1 |
| kubernetes.io/ingress-class | Gibt an, welche Dateneingangssteuerung für diesen Dateneingang verantwortlich ist | nsx, nginx usw. | nsx | 2.5, 2.5.1 |
| nsx/loadbalancer | Platziert einen eingehenden Datenverkehr auf einem dedizierten Load Balancer | Name einer LoadBalancer-CRD | Kein Standardwert | 2.5.1 |
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 Dateneingangsspezifikation: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
Ab NCP 2.5.1 können Sie den Abgleich mit regulärem Ausdruck für den Dateneingangsparameter 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 Dateneingangsspezifikation:apiVersion: extensions/v1beta1 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 Dateneingänge vor dem Upgrade von NCP auf 2.5.1
Dies ist nur erforderlich, wenn Sie über Dateneingänge verfügen, die alle einen Abgleich der Unterpfade mithilfe der Zeichen '.‘ und '*' erfordern.
- Aktualisieren Sie die Dateneingänge, um die Anmerkung ncp/use-regex: true einzubeziehen.
- 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: /.*.
- Für NCP 2.5.0 und früher
- 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: 80Die 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:apiVersion: extensions/v1beta1 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 Dateneingangsspezifikation 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 eingehende Datenverkehr von NCP verarbeitet. Wenn ein anderer Wert angegeben ist, wird der eingehende Datenverkehr 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.
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 Dateneingang mit einem Standard-Back-End vorhanden ist. Der Dateneingang ist dann inaktiv. Dieser Fehler tritt auf, wenn (1) dieser Dateneingang für HTTP und ein weiterer Dateneingang für HTTP mit einem Standard-Backend existiert; (2) dieser Dateneingang für HTTPS und ein weiterer Dateneingang für HTTPS mit einem Standard-Backend existiert; oder (3) dieser Dateneingang für HTTP und HTTPS und ein weiterer Dateneingang für HTTP und HTTPS mit einem Standard-Backend existiert. Um den Fehler zu beheben, löschen Sie den Dateneingang und erstellen Sie ihn mit einer korrekten Spezifikation neu.
- ncp/warning.loadbalancer: SECRET_NOT_FOUND
Dieser Fehler weist darauf hin, dass der in der Ingress-Spezifikation angegebene geheime Schlüssel nicht vorhanden ist. Der Dateneingang 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 Dateneingang ist dann inaktiv. Um den Fehler zu beheben, löschen Sie den Dateneingang und erstellen Sie ihn mit einer korrekten Spezifikation neu.
- Eine Dateneingangsregel steht im Konflikt mit einer anderen Dateneingangsregel im selben Kubernetes-Cluster. Ab NCP 2.5.1 werden Konflikte nur noch für Dateneingänge 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 Dateneingang hat keinen TLS-Abschnitt.
- Die Anmerkung ncp/http-redirect wird auf true gesetzt, und der Dateneingang 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.
