NCP erstellt einen Layer-7-Lastausgleichsdienst für Ingresses mit TLS-Spezifikation und einen Layer-7-Lastausgleichsdienst 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.
- Die Regeln werden in der folgenden Reihenfolge angewendet:
- Regeln sowohl mit host als auch path angegeben.
- Regeln mit dem Exact pathType.
- Regeln mit dem Prefix pathType.
- Regeln mit dem Regex pathType.
- Regeln mit host oder path angegeben.
- Regeln mit dem Exact pathType.
- Regeln mit dem Prefix pathType.
- Regeln mit dem Regex pathType.
Hinweis: Wenn mehrere Pfade einer Anforderung entsprechen, wird dem längsten übereinstimmenden Pfad Vorrang eingeräumt.
Informationen zu pathType:- Ab Kubernetes 1.19 ist pathType obligatorisch.
- Wenn use-regex festgelegt ist, wird dies nur dann wirksam, wenn pathType ImplementationSpecific ist.
- Wenn use-regex nicht festgelegt ist, wird ImplementationSpecific genau so behandelt wie Exact. pathType hat vor anderen NCP-Anmerkungen Vorrang.
- 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.
- Regeln sowohl mit host als auch path angegeben.
- Platzhalter für Hostname
Bei der Angabe des Hostnamens können Sie den genauen Namen angeben, z. B. abc.example.com oder einen Platzhalter verwenden, z. B. *.example.com. Beachten Sie, dass der Platzhalter einer oder mehreren DNS-Bezeichnungen entspricht. Die folgende Tabelle zeigt die Treffer, wenn Sie *.example.com angeben.
Host-Header Treffer abc.example.com Abgleichen abc.def.example.com Abgleichen example.com Kein Treffer - (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/TKGI“ 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/TKGI“ 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 unterstützt.
- Das pathType-Attribut wird unterstützt.
- Die Clientauthentifizierung mit JWT (JSON Web Token) wird unterstützt. Diese Funktion erfordert NSX 3.0.0 oder höhere Versionen.
Ab Kubernetes 1.18 ist die
kubernetes.io/ingress.class-Anmerkung veraltet und wird durch die IngressClass-Ressource ersetzt. Um
NSX als Ingress-Controller in der IngressClass-Ressource anzugeben, legen Sie den Controller-Parameter auf
k8s.io/nsx fest. Beispiel:
apiVersion: networking.k8s.io/v1
kind: IngressClass
metadata:
name: nsx-lb
annotations:
ingressclass.kubernetes.io/is-default-class: true
spec:
controller: k8s.io/nsx
Um einen Ingress-Controller eines Drittanbieters anzugeben, legen Sie den Controller-Parameter auf
k8s.io/<controller name>. Beispiel:
apiVersion: networking.k8s.io/v1
kind: IngressClass
metadata:
name: nginx-lb
annotations:
ingressclass.kubernetes.io/is-default-class: false
spec:
controller: k8s.io/ingress-nginx
Um die IngressClass als Standardeinstellung für den Cluster festzulegen, legen Sie die Anmerkung ingressclass.kubernetes.io/is-default-class auf true fest. Weitere Informationen finden Sie im obigen Beispiel.
Sie dürfen nicht sowohl die kubernetes.io/ingress.class-Anmerkung als auch die IngressClass-Ressource verwenden.
Wenn Sie ein
Endpoints Objekt manuell konfigurieren, stellen Sie sicher, dass Sie den Parameter
targetRef festlegen. Der Wert sollte die UID des Backend-Pods sein. Beispiel:
apiVersion: networking.k8s.io/v1
kind: Endpoints
metadata:
name: tea-svc
subsets:
- addresses:
- ip: 172.26.0.2
targetRef:
uid: 4378e0ae-5837-49c6-a0b2-178dced8eb1e
...
Funktions Anmerkungen
In der folgenden Tabelle sind die von NCP unterstützten Anmerkungen aufgeführt:
| Anmerkung | Beschreibung | Unterstützte Werte | Standardwert |
|---|---|---|---|
| kubernetes.io/ingress.allow-http | Aktiviert HTTP-Anforderungen zusätzlich zu HTTPS | true, false | true |
| ncp/use-regex | Aktiviert Pfad Musterübereinstimmung | true, false | false |
| ingress.kubernetes.io/rewrite-target | Der Pfad der eingehenden Anforderung wird neu geschrieben |
|
Kein Standardwert |
| ncp/http-redirect | Leitet HTTP-Anforderungen an HTTPS weiter | true, false | false |
| kubernetes.io/ingress.class | Gibt an, welche Ingress-Steuerung für diesen Ingress verantwortlich ist | nsx, nginx usw. | nsx |
| nsx/loadbalancer | Platziert einen Ingress auf einem dedizierten Load Balancer | Name einer LoadBalancer-CRD | Kein Standardwert |
| ncp/allowed-source-range | Begrenzt den Ingress-Zugriff nach IP der Anforderungsquelle | Kommagetrennte Liste der CIDRs, IP-Adressen oder IP-Bereiche. | Kein Standardwert |
| ncp/ssl-mode | Legt den SSL-Modus für alle Regeln in einem Ingress fest. | offload, reencrypt, passthrough | offload |
| 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 |
| 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 |
| ncp/jwt-token | Zusätzlicher Speicherort für die Suche nach JWT in der HTTP-Anfrage. | _arg_<param_name>, _cookie_<cookie_name> | Kein Standardwert |
| 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 |
| ncp/jwt-preserve | Option, um JWT beizubehalten und nach erfolgreicher Authentifizierung an Backend zu übergeben. | true, false | true |
| ncp/connection_multiplexing_enabled | Aktiviert TCP-Multiplexing. | true, false | false |
| ncp/connection_multiplexing_number | Wenn TCP-Multipelxing aktiviert ist, gibt dies die Anzahl der verfügbaren TCP-Verbindungen im Leerlauf an. | 0–2147483647 | 6 |
Details zu den Anmerkungen:
- Übereinstimmender Pfad-Regex (regulärer Ausdruck)
- 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:apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: cafe-ingress annotations: kubernetes.io/ingress.class: "nsx" #/tea/cup will be served by tea-svc:80 ncp/use-regex: "True" spec: rules: - host: cafe.example.com http: paths: # for this tea and coffee NCP will configure regex rule - path: /tea/(.*) pathType: ImplementationSpecific backend: service: name: tea-svc port: number: 80 - path: /coffee/(.*) pathType: ImplementationSpecific backend: service: name: coffee-svc port: number: 80 # for juice and alcohol NCP will configure Exact and Prefix rules - path: /juice pathType: Exact backend: service: name: juice-svc port: number: 80 - path: /alcohol pathType: Prefix backend: service: name: bar number: 80 - Aktualisieren von Ingresses vor dem Upgrade von NCP
Dies ist nur erforderlich, wenn Sie über Ingresses verfügen, die alle einen Abgleich der Unterpfade mithilfe der Zeichen '.' und '*' erfordern.
- Aktualisieren Sie die Ingresses, 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: /.*.
- 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:
- Im folgenden Beispiel des Anmerkungs-ingress.kubernetes.io/rewrite-target werden die Pfade /tea und /coffee in / umgeschrieben, bevor die URL an den Backend-Dienst gesendet wird.
apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: cafe-ingress annotations: ingress.kubernetes.io/rewrite-target: / spec: rules: - host: cafe.example.com http: paths: - path: /tea pathType: ImplementationSpecific backend: service: name: tea-svc port: number: 80 - path: /coffee pathType: ImplementationSpecific backend: service: name: coffee-svc port: number: 80Die erfassten Gruppen werden 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: networking.k8s.io/v1 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/(.*) pathType: ImplementationSpecific backend: service: name: tea-svc port: number: 80 - path: /coffee/(.*) pathType: ImplementationSpecific backend: service: name: coffee-svc port: number: 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/allowed-source-range:
- Wird nur im Richtlinienmodus unterstützt.
- 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.
- YAML-Beispiel:
apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: cafe-ingress annotations: kubernetes.io/ingress.class: "nsx" #Source IP addresses allowed to access ingress URL ncp/allowed-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 pathType: ImplementationSpecific backend: service: name: tea-svc port: number: 80 - path: /coffee pathType: ImplementationSpecific backend: service: name: coffee-svc port: number: 80
- Informationen zur Anmerkung ncp/ssl-mode:
- Wird nur im Richtlinienmodus unterstützt.
- 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.
Wenn für ncp/ssl-mode reencrypt oder passthrough festgelegt ist, muss kubernetes.io/ingress.allow-http auf False gesetzt werden. Diese Anmerkung kann nicht auf passthrough gesetzt werden, wenn die Anmerkung ingress.kubernetes.io/rewrite-target, ncp/use-regex oder ncp/allowed-source-range festgelegt ist.
Wenn für ncp/ssl-mode passthrough festgelegt ist, wird das Attribut path in der rules-Spezifikation nicht unterstützt.
- 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.
- Informationen zu den Anmerkungen ncp/connection_multiplxing_enabled und ncp/connection_multiplxing_number:
- TCP-Multiplexing darf nicht mit HTTP NTLM koexistieren. Wenn in NSX ein Load Balancer-Pool mit aktiviertem TCP-Multipelxing an einen NTLM-fähigen Layer-7-Server gebunden ist, hat die NTLM-Konfiguration Vorrang vor TCP-Multiplexing.
- YAML-Beispiel:
apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: cafe-ingress annotations: ncp/connection_multiplexing_enabled: "true" ncp/connection_multiplexing_number: 100 spec: tls: - hosts: - cafe.example.com rules: - host: cafe.example.com http: paths: - path: /tea backend: service: name: tea-svc port: number: 80 - path: /coffee backend: service: name: coffee-svc port: number: 80
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.
