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.
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: /.*
.

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

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

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.

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.

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.

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

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: Wenn
ncp/ssl-mode
auf
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/whitelist-source-range
festgelegt ist.

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.