NCP 2.5.0 以前の場合
NCP 2.5.0 以前では、正規表現文字「.」および「*」を使用すると、すべてのサブパスの一致が自動的に有効になります。たとえば、パス
/coffee/.*
は、
/coffee/
、
/coffee/a
、および
/coffee/b
のように後に 0 または 1 文字以上の文字が続く
/coffee/
に一致しますが、
/coffee
、
/coffeecup
、または
/coffeecup/a
には一致しません。
Ingress の仕様の例：
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
NCP 2.5.1 以降の場合
アノテーション
ncp/use-regex
を使用して、Ingress
path
（
host
ではない）パラメータの正規表現一致を有効または無効にできます。
false
に設定されている場合は、
equals
一致を使用してパスの完全一致が実行されます。
true
に設定した場合、文字列開始文字 (^) と文字列終了文字 ($) をパスに追加することによって、正規表現の一致が実行されます。これにより、要求 URI 全体がパターンに一致するようになります。
OR
演算子 (|) を使用する場合は、常に括弧で範囲を指定して、^ と $ がすべてのオペランドに適用されるようにします。例：
path: /(tea|coffee|milk)
Ingress の仕様の例：
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
NCP を 2.5.1 以降にアップグレードする前に Ingress を更新する
これは、Ingress が文字「.」および「*」を使用するすべてのサブパス一致を必要とする場合にのみ必要です。
アノテーション
ncp/use-regex: true
を含めるように Ingress を更新します。
すべてのサブパス一致では、
/coffee/*
や
/*
などのパスがある場合はそれらのパスを
/coffee/.*
および
/.*
に変更します。
/coffee/.*
は
/coffee/
、
/coffee/a
、
/coffee/b
、
/coffee/a/b
などと一致します。
/.*
は
/coffee
、
/tea
、
/coffee/a
などと一致します。パスを省略すると、
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

アノテーションが
false
に設定されている場合は、HTTPS 仮想サーバのルールが作成されます。
アノテーションが
true
に設定されているか、存在しない場合は、HTTP と HTTPS 仮想サーバの両方のルールが作成されます。Ingress の仕様に TLS セクションがある場合のみ、HTTPS ルールが作成されます。

アノテーションが
false
に設定されている場合、HTTP 仮想サーバへの受信 HTTP トラフィック（ポート 80）は HTTPS 仮想サーバにリダイレクトされません。
アノテーションが
true
に設定されている場合、HTTP 仮想サーバへの受信 HTTP トラフィック（ポート 80）は HTTPS 仮想サーバ（ポート 443）にリダイレクトされます。

値が
nsx
の場合、この Ingress は NCP によって処理されます。他の値が指定されている場合、Ingress は NCP によって無視されます。詳細については、サードパーティの入力方向コントローラを参照してください。

設定すると、送信元 IP アドレスがこの注釈に含まれている場合にのみ、受信要求が受け入れられます。それ以外の場合は、トラフィックがドロップされます。

CIDR、IP アドレス、IP 範囲の組み合わせを指定できます。たとえば、1.1.1.1/24, 2.2.2.2, 3.3.3.3-4.4.4.4 と指定できます。

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

この注釈は、Ingress のすべてのルールに適用されます。ロード バランサは、これらのルールに対して選択された SSL モードで動作します。
注:
ncp/ssl-mode
が
reencrypt
または
passthrough
に設定されている場合は、
kubernetes.io/ingress.allow-http
を
False
に設定する必要があります。
ingress.kubernetes.io/rewrite-target
、
ncp/use-regex
、または
ncp/whitelist-source-range
注釈が設定されていない場合、この注釈に
passthrough
を設定することはできません。

入力方向のすべてのルールで JWT クライアント認証を有効にするには、
ncp/jwt-alg
と
ncp/jwt-secret
の両方に有効な値を設定する必要があります。有効にすると、有効な JSON Web Token がある場合にのみ、着信 HTTP トラフィックがバックエンドに渡されます。それ以外の場合は、401 ステータスでトラフィックが拒否されます。
この機能は次の注釈と互換性がありません。
kubernetes.io/ingress.allow-http: true
ncp/http-redirect: true
ncp/ssl-mode: passthrough
ncp/jwt-alg
：
サポートされている対称アルゴリズム：HS256
サポートされている非対称アルゴリズム：RS256
ncp/jwt-secret
：
入力方向と同じ名前空間で、この注釈に指定された名前の Kubernetes シークレットに対称キーまたはパブリック証明書を構成する必要があります。
対称アルゴリズムの場合、シークレットを
jwt.key
フィールドに保存する必要があります。
非対称アルゴリズムの場合は、パブリック証明書を
tls.crt
フィールドに保存する必要があります。
対称シークレットまたはパブリック証明書が上記の場所に保存されていない場合、またはシークレットに保存されているデータが無効な場合、JWT クライアント認証は無効になります。
ncp/jwt-token
：
この注釈では 1 つのアイテムのみを構成できます。
_arg_<param_name>
：JWT が URI パラメータとして渡された場合。JWT を含むパラメータ名を指定します。
_cookie_<cookie_name>
：JWT が Cookie として渡された場合。JWT を含む Cookie 名を指定します。