すべてのプロダクト
Search

このプロダクト

    API Gateway:APIG Ingress の高度な機能

    ドキュメントセンター

    API Gateway:APIG Ingress の高度な機能

    最終更新日:Dec 04, 2025

    Kubernetes クラスタでは、APIG Ingress は サービスへの外部アクセスを管理するための レイヤー 7 ロードバランシングを提供する API オブジェクトです。このトピックでは、クラスタのイングレストラフィックを管理するために使用できる APIG Ingress の高度な機能について説明します。

    カナリアリリース

    APIG Ingress は、ヘッダー、クエリパラメータ、Cookie、および重みに基づくカナリアリリースのサポートを含む、ルーティング機能を提供します。この機能は、Ingress リソースにアノテーションを追加することで構成できます。カナリアリリースを有効にするには、nginx.ingress.kubernetes.io/canary: "true" アノテーションを追加します。その後、他の特定のアノテーションを使用して、さまざまなタイプのカナリアリリースを実装できます。

    説明

    複数のメソッドが構成されている場合、カナリアリリース選択の優先順位は次のとおりです。ヘッダーに基づく | クエリパラメータに基づく > Cookie に基づく > 重みに基づく（高から低）。

    ヘッダーベースのカナリアリリース

    • nginx.ingress.kubernetes.io/canary-by-header のみを構成した場合、トラフィックはリクエストヘッダーに基づいてルーティングされます。構成された header 値が always の場合、トラフィックはカナリアサービスエンドポイントにルーティングされます。それ以外の場合、トラフィックはカナリアサービスにルーティングされません。

    • nginx.ingress.kubernetes.io/canary-by-header-value と nginx.ingress.kubernetes.io/canary-by-header の両方を構成した場合、リクエストのヘッダーとヘッダー値が構成された値と一致する場合にのみ、トラフィックはカナリアサービスにルーティングされます。それ以外の場合、トラフィックはカナリアサービスにルーティングされません。

    説明

    NGINX Ingress と ALB Ingress は、カナリアリリース中に最大 2 つのサービスバージョンをサポートします。 APIG Ingress は、カナリアリリース中に無制限の数のサービスバージョンをサポートします。

    例：

    • リクエストヘッダーが apig: always の場合、リクエストはカナリアサービス demo-service-canary にルーティングされます。それ以外の場合、リクエストは本番サービス demo-service にルーティングされます。以下のサンプルコードは設定を示しています：

      Kubernetes 1.19 以降を実行するクラスタ

      apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    nginx.ingress.kubernetes.io/canary: "true"
    nginx.ingress.kubernetes.io/canary-by-header: "apig"
  name: demo-canary
spec:
  ingressClassName: apig
  rules:
    - http:
        paths:
          - backend:
              service:
                name: demo-service-canary
                port: 
                  number: 80
            path: /hello
            pathType: Exact
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: demo
spec:
  ingressClassName: apig
  rules:
    - http:
        paths:
          - backend:
              service:
                name: demo-service
                port: 
                  number: 80
            path: /hello
            pathType: Exact

      Kubernetes 1.19 より前のバージョンを実行するクラスタ

      apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  annotations:
    nginx.ingress.kubernetes.io/canary: "true"
    nginx.ingress.kubernetes.io/canary-by-header: "apig"
  name: demo-canary
spec:
  ingressClassName: apig
  rules:
    - http:
        paths:
          - path: /hello
            backend:
              serviceName: demo-service-canary
              servicePort: 80
---
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: demo
spec:
  ingressClassName: apig
  rules:
    - http:
        paths:
          - path: /hello
            backend:
              serviceName: demo-service
              servicePort: 80

    • リクエストヘッダーが apig: v1 の場合、リクエストはカナリアサービス demo-service-canary-v1 にルーティングされます。リクエストヘッダーが apig: v2 の場合、リクエストはカナリアサービス demo-service-canary-v2 にルーティングされます。それ以外の場合、リクエストは本番サービス demo-service にルーティングされます。以下のサンプルコードは設定を示しています：

      Kubernetes 1.19 以降を実行するクラスタ

      apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    nginx.ingress.kubernetes.io/canary: "true"
    nginx.ingress.kubernetes.io/canary-by-header: "apig"
    nginx.ingress.kubernetes.io/canary-by-header-value: "v1"
  name: demo-canary-v1
spec:
  ingressClassName: apig
  rules:
    - http:
        paths:
          - backend:
              service:
                name: demo-service-canary-v1
                port: 
                  number: 80
            path: /hello
            pathType: Exact
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    nginx.ingress.kubernetes.io/canary: "true"
    nginx.ingress.kubernetes.io/canary-by-header: "apig"
    nginx.ingress.kubernetes.io/canary-by-header-value: "v2"
  name: demo-canary-v2
spec:
  ingressClassName: apig
  rules:
    - http:
        paths:
          - backend:
              service:
                name: demo-service-canary-v2
                port: 
                  number: 80
            path: /hello
            pathType: Exact
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: demo
spec:
  ingressClassName: apig
  rules:
    - http:
        paths:
          - backend:
              service:
                name: demo-service
                port: 
                  number: 80
            path: /hello
            pathType: Exact

      Kubernetes 1.19 より前のバージョンを実行するクラスタ

      apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  annotations:
    nginx.ingress.kubernetes.io/canary: "true"
    nginx.ingress.kubernetes.io/canary-by-header: "apig"
    nginx.ingress.kubernetes.io/canary-by-header-value: "v1"
  name: demo-canary-v1
spec:
  ingressClassName: apig
  rules:
    - http:
        paths:
          - path: /hello
            backend:
              serviceName: demo-service-canary-v1
              servicePort: 80
---
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  annotations:
    nginx.ingress.kubernetes.io/canary: "true"
    nginx.ingress.kubernetes.io/canary-by-header: "apig"
    nginx.ingress.kubernetes.io/canary-by-header-value: "v2"
  name: demo-canary-v2
spec:
  ingressClassName: apig
  rules:
    - http:
        paths:
          - path: /hello
            backend:
              serviceName: demo-service-canary-v2
              servicePort: 80
---
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: demo
spec:
  ingressClassName: apig
  rules:
    - http:
        paths:
          - path: /hello
            backend:
              serviceName: demo-service
              servicePort: 80

    クエリパラメータベースのカナリアリリース

    • higress.ingress.kubernetes.io/canary-by-query のみを構成する

      リクエストは URL のクエリパラメータに基づいて送信されます。リクエストの URL で、クエリパラメータキーがアノテーションで指定されたキーと同じで、クエリパラメータ値が always の場合、リクエストはカナリアバージョンに送信されます。それ以外の場合、リクエストはカナリアバージョンに送信されません。

    • higress.ingress.kubernetes.io/canary-by-query-value と higress.ingress.kubernetes.io/canary-by-query の両方を構成する

      リクエストの クエリパラメータキー と クエリパラメータ値 が構成された値と一致する場合、トラフィックはカナリアサービスにルーティングされます。それ以外の場合、トラフィックはカナリアサービスにルーティングされません。

      説明

      ヘッダーベースのカナリアリリースは、クエリパラメータベースのカナリアリリースと一緒に使用できます。両方のカナリアリリース方式の一致条件が満たされた場合にのみ、リクエストはカナリアバージョンに送信されます。

    例：

    • リクエスト URL のクエリパラメータが canary: gray の場合、リクエストはカナリアサービス demo-service-canary にルーティングされます。それ以外の場合、リクエストは本番サービス demo-service にルーティングされます。次のサンプルコードは構成を示しています。

      Kubernetes 1.19 以降を実行するクラスタ

      apiVersion:networking.k8s.io/v1 
kind: Ingress
metadata:
  annotations:
    nginx.ingress.kubernetes.io/canary: "true"
    higress.ingress.kubernetes.io/canary-by-query: "canary"
    higress.ingress.kubernetes.io/canary-by-query-value: "gray"
  name: demo-canary
spec:
  ingressClassName: apig
  rules:
    - http:
        paths:
          - backend:
              service:
                name: demo-service-canary
                port: 
                  number: 80
            path: /hello
            pathType: Exact
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: demo
spec:
  ingressClassName: apig
  rules:
    - http:
        paths:
          - backend:
              service:
                name: demo-service
                port: 
                  number: 80
            path: /hello
            pathType: Exact

      Kubernetes 1.19 より前のバージョンを実行するクラスタ

      apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  annotations:
    nginx.ingress.kubernetes.io/canary: "true"
    higress.ingress.kubernetes.io/canary-by-query: "canary"
    higress.ingress.kubernetes.io/canary-by-query-value: "gray"
  name: demo-canary
spec:
  ingressClassName: apig
  rules:
    - http:
        paths:
          - path: /hello
            backend:
              serviceName: demo-service-canary
              servicePort: 80
---
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: demo
spec:
  ingressClassName: apig
  rules:
    - http:
        paths:
          - path: /hello
            backend:
              serviceName: demo-service
              servicePort: 80

    • リクエスト URL のクエリパラメータが canary: gray で、リクエストヘッダーに x-user-id: test が含まれている場合、リクエストはカナリアサービス demo-service-canary にルーティングされます。それ以外の場合、リクエストは本番サービス demo-service にルーティングされます。次のサンプルコードは構成を示しています。

      Kubernetes 1.19 以降を実行するクラスタ

      apiVersion:networking.k8s.io/v1 
kind: Ingress
metadata:
  annotations:
    nginx.ingress.kubernetes.io/canary: "true"
    higress.ingress.kubernetes.io/canary-by-query: "canary"
    higress.ingress.kubernetes.io/canary-by-query-value: "gray"
    nginx.ingress.kubernetes.io/canary-by-header: "x-user-id"
    nginx.ingress.kubernetes.io/canary-by-header-value: "test"
  name: demo-canary
spec:
  ingressClassName: apig
  rules:
    - http:
        paths:
          - backend:
              service:
                name: demo-service-canary
                port: 
                  number: 80
            path: /hello
            pathType: Exact
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: demo
spec:
  ingressClassName: apig
  rules:
    - http:
        paths:
          - backend:
              service:
                name: demo-service
                port: 
                  number: 80
            path: /hello
            pathType: Exact

      Kubernetes 1.19 より前のバージョンを実行するクラスタ

      apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  annotations:
    nginx.ingress.kubernetes.io/canary: "true"
    higress.ingress.kubernetes.io/canary-by-query: "canary"
    higress.ingress.kubernetes.io/canary-by-query-value: "gray"
    nginx.ingress.kubernetes.io/canary-by-header: "x-user-id"
    nginx.ingress.kubernetes.io/canary-by-header-value: "test"
  name: demo-canary
spec:
  ingressClassName: apig
  rules:
    - http:
        paths:
          - path: /hello
            backend:
              serviceName: demo-service-canary
              servicePort: 80
---
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: demo
spec:
  ingressClassName: apig
  rules:
    - http:
        paths:
          - path: /hello
            backend:
              serviceName: demo-service
              servicePort: 80

    Cookie ベースのカナリアリリース

    nginx.ingress.kubernetes.io/canary-by-cookie: このアノテーションは、Cookie に基づいてトラフィックを分割します。構成された cookie 値が always の場合、トラフィックはカナリアサービスにルーティングされます。それ以外の場合、トラフィックはカナリアサービスにルーティングされません。

    説明

    Cookie ベースのカナリアリリースはカスタム値をサポートしていません。構成された cookie 値は always でなければなりません。

    たとえば、リクエスト Cookie が demo=always の場合、リクエストはカナリアサービス demo-service-canary にルーティングされます。それ以外の場合、リクエストは本番サービス demo-service にルーティングされます。次のサンプルコードは構成を示しています。

    Kubernetes 1.19 以降を実行するクラスタ

    apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    nginx.ingress.kubernetes.io/canary: "true"
    nginx.ingress.kubernetes.io/canary-by-cookie: "demo"
  name: demo-canary
spec:
  ingressClassName: apig
  rules:
    - http:
        paths:
          - backend:
              service:
                name: demo-service-canary
                port: 
                  number: 80
            path: /hello
            pathType: Exact
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: demo
spec:
  ingressClassName: apig
  rules:
    - http:
        paths:
          - backend:
              service:
                name: demo-service
                port: 
                  number: 80
            path: /hello
            pathType: Exact

    Kubernetes 1.19 より前のバージョンを実行するクラスタ

    apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  annotations:
    nginx.ingress.kubernetes.io/canary: "true"
    nginx.ingress.kubernetes.io/canary-by-cookie: "demo"
  name: demo-canary
spec:
  ingressClassName: apig
  rules:
    - http:
        paths:
          - path: /hello
            backend:
              serviceName: demo-service-canary
              servicePort: 80
---
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: demo
spec:
  ingressClassName: apig
  rules:
    - http:
        paths:
          - path: /hello
            backend:
              serviceName: demo-service
              servicePort: 80

    重みベースのカナリアリリース

    アノテーション

    説明

    nginx.ingress.kubernetes.io/canary-weight

    カナリアバージョンに送信されるリクエストの割合を指定します。値は 0 から 100 までの整数です。

    nginx.ingress.kubernetes.io/canary-weight-total

    合計重みを指定します。デフォルト値：100。

    たとえば、カナリアバージョン demo-service-canary-v1 の重みを 30% に設定し、カナリアバージョン demo-service-canary-v2 の重みを 20% に設定し、ベースバージョン demo-service の重みを 50% に設定できます。サンプル構成：

    Kubernetes 1.19 以降を実行するクラスタ

    apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    nginx.ingress.kubernetes.io/canary: "true"
    nginx.ingress.kubernetes.io/canary-weight: "30"
  name: demo-canary-v1
spec:
  ingressClassName: apig
  rules:
    - http:
        paths:
          - backend:
              service:
                name: demo-service-canary-v1
                port: 
                  number: 80
            path: /hello
            pathType: Exact
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    nginx.ingress.kubernetes.io/canary: "true"
    nginx.ingress.kubernetes.io/canary-weight: "20"
  name: demo-canary-v2
spec:
  ingressClassName: apig
  rules:
    - http:
        paths:
          - backend:
              service:
                name: demo-service-canary-v2
                port: 
                  number: 80
            path: /hello
            pathType: Exact
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: demo
spec:
  ingressClassName: apig
  rules:
    - http:
        paths:
          - backend:
              service:
                name: demo-service
                port: 
                  number: 80
            path: /hello
            pathType: Exact

    Kubernetes 1.19 より前のバージョンを実行するクラスタ

    apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  annotations:
    nginx.ingress.kubernetes.io/canary: "true"
    nginx.ingress.kubernetes.io/canary-weight: "30"
  name: demo-canary-v1
spec:
  ingressClassName: apig
  rules:
    - http:
        paths:
          - path: /hello
            backend:
              serviceName: demo-service-canary-v1
              servicePort: 80
---
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  annotations:
    nginx.ingress.kubernetes.io/canary: "true"
    nginx.ingress.kubernetes.io/canary-weight: "20"
  name: demo-canary-v2
spec:
  ingressClassName: apig
  rules:
    - http:
        paths:
          - path: /hello
            backend:
              serviceName: demo-service-canary-v2
              servicePort: 80
---
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: demo
spec:
  ingressClassName: apig
  rules:
    - http:
        paths:
          - path: /hello
            backend:
              serviceName: demo-service
              servicePort: 80

    サービスサブセット

    サービスサブセットは、Service が複数の Deployment に関連付けられているシナリオに適しています。 Ingress を使用して、リクエストを Service の Pod のサブセットに転送できます。ほとんどの場合、リクエストは特定のラベルを持つ Service Pod に転送されます。次のいずれかの方法を使用して、サービスサブセットを構成できます。

    APIG Ingress の Pod ラベル規則を使用する

    アノテーション higress.ingress.kubernetes.io/service-subset を使用してサービスバージョンを設定できます。デフォルトでは、APIG Ingress は構成されたサービスバージョンを `opensergo.io/canary` というプレフィックスが付いた Pod ラベルにマップします。アノテーションは次のように機能します。

    • 値が "" または base の場合、リクエストは opensergo.io/canary: "" というラベルが付いているか、opensergo.io/canary プレフィックスのラベルキーがない Pod に転送されます。これらの Pod は空のラベルまたはラベルがないと見なされます。

    • 値が別の文字列に設定されている場合、リクエストは `opensergo.io/canary-{value}: {value}` というラベルが付いた Pod に転送されます。たとえば、値が gray の場合、リクエストは opensergo.io/canary-gray: gray というラベルが付いた Pod に転送されます。

    たとえば、go-httpbin という名前の Kubernetes Service は 2 つの Deployment に関連付けられています。一方の Deployment によって管理される Pod には、opensergo.io/canary というプレフィックスが付いたラベルキーがありません。もう一方の Deployment によって管理される Pod には、カナリアラベル opensergo.io/canary-gray: gray が付いています。サンプル構成：

    # go-httpbin k8s service
apiVersion: v1
kind: Service
metadata:
  name: go-httpbin
  namespace: default
spec:
  ports:
    - port: 8080
      protocol: TCP
  selector:
    app: go-httpbin
---
# go-httpbin base deployment
apiVersion: apps/v1
kind: Deployment
metadata:
  name: go-httpbin-base
  namespace: default
spec:
  replicas: 1
  selector:
    matchLabels:
      app: go-httpbin
  template:
    metadata:
      labels:
        app: go-httpbin
    spec:
      containers:
        - image: registry.cn-hangzhou.aliyuncs.com/apig/go-httpbin
          args:
            - "--version=base"
          imagePullPolicy: Always
          name: go-httpbin
---
# go-httpbin gray deployment
apiVersion: apps/v1
kind: Deployment
metadata:
  name: go-httpbin-gray
  namespace: default
spec:
  replicas: 1
  selector:
    matchLabels:
      app: go-httpbin
  template:
    metadata:
      labels:
        app: go-httpbin
        opensergo.io/canary-gray: gray
    spec:
      containers:
        - image: registry.cn-hangzhou.aliyuncs.com/apig/go-httpbin
          args:
            - "--version=gray"
          imagePullPolicy: Always
          name: go-httpbin

    example.com/test リクエストのヘッダーに x-user-id: test が含まれている場合、リクエストは go-httpbin-gray に転送されます。それ以外の場合、リクエストは httpbin-base に転送されます。サンプル構成：

    Kubernetes 1.19 以降を実行するクラスタ

    apiVersion:networking.k8s.io/v1 
kind: Ingress
metadata:
  annotations:
    nginx.ingress.kubernetes.io/canary: "true"
    nginx.ingress.kubernetes.io/canary-by-header: "x-user-id"
    nginx.ingress.kubernetes.io/canary-by-header-value: "test"
    # カナリアラベル opensergo.io/canary-gray: gray を持つ Pod にリクエストを転送します。
    higress.ingress.kubernetes.io/service-subset: gray
  name: demo-canary
  namespace: default
spec:
  ingressClassName: apig
  rules:
    - http:
        paths:
          - backend:
              service:
                name: go-httpbin
                port: 
                  number: 8080
            path: /test
            pathType: Exact
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    # ラベルが opensergo.io/canary で始まらない Pod にリクエストを転送します。
    higress.ingress.kubernetes.io/service-subset: ""
  name: demo
  namespace: default
spec:
  ingressClassName: apig
  rules:
    - http:
        paths:
          - backend:
              service:
                name: go-httpbin
                port: 
                  number: 8080
            path: /test
            pathType: Exact

    Kubernetes 1.19 より前のバージョンを実行するクラスタ

    apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  annotations:
    nginx.ingress.kubernetes.io/canary: "true"
    nginx.ingress.kubernetes.io/canary-by-header: "x-user-id"
    nginx.ingress.kubernetes.io/canary-by-header-value: "test"
    # カナリアラベル opensergo.io/canary-gray: gray を持つ Pod にリクエストを転送します。
    higress.ingress.kubernetes.io/service-subset: gray
  name: demo-canary
  namespace: default
spec:
  ingressClassName: apig
  rules:
    - http:
        paths:
          - path: /test
            backend:
              # go-httpbin サービスを設定し、アノテーションでバージョンを指定します。
              serviceName: go-httpbin
              servicePort: 8080
---
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  annotations:
    # ラベルが opensergo.io/canary で始まらない Pod にリクエストを転送します。
    higress.ingress.kubernetes.io/service-subset: ""
  name: demo
  namespace: default
spec:
  ingressClassName: apig
  rules:
    - http:
        paths:
          - path: /test
            backend:
              # go-httpbin サービスを設定し、アノテーションでバージョンを指定します。
              serviceName: go-httpbin
              servicePort: 8080

    カスタムラベルの使用

    higress.ingress.kubernetes.io/service-subset アノテーションと higress.ingress.kubernetes.io/subset-labels アノテーションの両方を設定することで、サブセットのポッドコレクションを定義するためのカスタムラベルを構成できます。

    説明

    この場合、サブセットはプレフィックスが opensergo.io/canary であるラベルにはマッピングされなくなります。

    たとえば、go-httpbin という名前の Kubernetes サービスが 2 つのデプロイメントに関連付けられているとします。1 つのデプロイメントによって管理されるポッドには、プレフィックスが opensergo.io/canary であるラベルキーがありません。もう 1 つのデプロイメントによって管理されるポッドには、カナリアラベル version: gray があります。設定例:

    # go-httpbin k8s service
apiVersion: v1
kind: Service
metadata:
  name: go-httpbin
  namespace: default
spec:
  ports:
    - port: 8080
      protocol: TCP
  selector:
    app: go-httpbin
---
# go-httpbin base deployment
apiVersion: apps/v1
kind: Deployment
metadata:
  name: go-httpbin-base
  namespace: default
spec:
  replicas: 1
  selector:
    matchLabels:
      app: go-httpbin
  template:
    metadata:
      labels:
        app: go-httpbin
    spec:
      containers:
        - image: registry.cn-hangzhou.aliyuncs.com/apig/go-httpbin
          args:
            - "--version=base"
          imagePullPolicy: Always
          name: go-httpbin
---
# go-httpbin base gray
apiVersion: apps/v1
kind: Deployment
metadata:
  name: go-httpbin-gray
  namespace: default
spec:
  replicas: 1
  selector:
    matchLabels:
      app: go-httpbin
  template:
    metadata:
      labels:
        app: go-httpbin
        version: gray
    spec:
      containers:
        - image: registry.cn-hangzhou.aliyuncs.com/apig/go-httpbin
          args:
            - "--version=gray"
          imagePullPolicy: Always
          name: go-httpbin

    example.com/test リクエストのヘッダーに x-user-id: test が含まれている場合、リクエストは go-httpbin-gray に転送されます。それ以外の場合は、リクエストは httpbin-base に転送されます。

    Kubernetes 1.19 以降を実行しているクラスタ

    apiVersion:networking.k8s.io/v1 
kind: Ingress
metadata:
  annotations:
    nginx.ingress.kubernetes.io/canary: "true"
    nginx.ingress.kubernetes.io/canary-by-header: "x-user-id"
    nginx.ingress.kubernetes.io/canary-by-header-value: "test"
    # カナリアラベル version: gray を持つ Pod にリクエストを転送します。
    higress.ingress.kubernetes.io/service-subset: gray
    higress.ingress.kubernetes.io/subset-labels: version gray
  name: demo-canary
  namespace: default
spec:
  ingressClassName: apig
  rules:
    - http:
        paths:
          - backend:
              service:
                name: go-httpbin
                port: 
                  number: 8080
            path: /test
            pathType: Exact
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    # ラベルが opensergo.io/canary で始まらない Pod にリクエストを転送します。
    higress.ingress.kubernetes.io/service-subset: ""
  name: demo
  namespace: default
spec:
  ingressClassName: apig
  rules:
    - http:
        paths:
          - backend:
              service:
                name: go-httpbin
                port: 
                  number: 8080
            path: /test
            pathType: Exact

    Kubernetes 1.19 より前のバージョンを実行しているクラスタ

    apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  annotations:
    nginx.ingress.kubernetes.io/canary: "true"
    nginx.ingress.kubernetes.io/canary-by-header: "x-user-id"
    nginx.ingress.kubernetes.io/canary-by-header-value: "test"
    # カナリアラベル version: gray を持つ Pod にリクエストを転送します。
    higress.ingress.kubernetes.io/service-subset: gray
    higress.ingress.kubernetes.io/subset-labels: version gray
  name: demo-canary
  namespace: default
spec:
  ingressClassName: apig
  rules:
    - http:
        paths:
          - path: /test
            backend:
              # go-httpbin サービスを設定し、アノテーションでバージョンを指定します。
              serviceName: go-httpbin
              servicePort: 8080
---
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  annotations:
    # ラベルが opensergo.io/canary で始まらない Pod にリクエストを転送します。
    higress.ingress.kubernetes.io/service-subset: ""
  name: demo
  namespace: default
spec:
  ingressClassName: apig
  rules:
    - http:
        paths:
          - path: /test
            backend:
              # go-httpbin サービスを設定し、アノテーションでバージョンを指定します。
              serviceName: go-httpbin
              servicePort: 8080

    CORS

    クロスオリジン リソース共有（CORS）を使用すると、Web アプリケーション サーバはクロスオリジン リソースにアクセスし、クロスオリジン データ転送を保護できます。CORS の詳細については、「Cross-Origin Resource Sharing (CORS)」をご参照ください。

    注釈

    説明

    nginx.ingress.kubernetes.io/enable-cors

    CORS を有効にするかどうかを指定します。

    nginx.ingress.kubernetes.io/cors-allow-origin

    許可されるサードパーティ サイトを指定します。サードパーティ サイトはカンマ（,）で区切ります。アスタリスク（*）をワイルドカード文字として使用できます。デフォルト値：*。この値は、すべてのサードパーティ サイトが CORS に許可されていることを示します。

    nginx.ingress.kubernetes.io/cors-allow-methods

    GET、POST、PUT などの許可されるリクエスト メソッドを指定します。リクエスト メソッドはカンマ（,）で区切ります。アスタリスク（*）をワイルドカード文字として使用できます。デフォルト値：GET,PUT,POST,DELETE,PATCH,OPTIONS。

    nginx.ingress.kubernetes.io/cors-allow-headers

    許可されるリクエスト ヘッダーを指定します。リクエスト ヘッダーはカンマ（,）で区切ります。アスタリスク（*）をワイルドカード文字として使用できます。デフォルト値：DNT,X-CustomHeader,Keep-Alive,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Authorization。

    nginx.ingress.kubernetes.io/cors-expose-headers

    ブラウザに公開できるレスポンス ヘッダーを指定します。レスポンス ヘッダーはカンマ（,）で区切ります。

    nginx.ingress.kubernetes.io/cors-allow-credentials

    CORS リクエストで資格情報を伝送することを許可するかどうかを指定します。デフォルトでは、CORS 操作中に資格情報を渡すことができます。

    nginx.ingress.kubernetes.io/cors-max-age

    事前チェック結果をキャッシュできる最大期間を指定します。単位：秒。デフォルト値：1728000。

    たとえば、example.com を許可されたサードパーティ Web サイトとして構成し、GET と POST を許可されたリクエスト メソッドとして構成し、X-Foo-Bar を許可されたリクエスト ヘッダーとして構成し、CORS 操作中の資格情報の受け渡しを許可しないものとします。設定例：

    Kubernetes 1.19 以降を実行するクラスタ

    apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    nginx.ingress.kubernetes.io/enable-cors: "true"
    nginx.ingress.kubernetes.io/cors-allow-origin: "example.com"
    nginx.ingress.kubernetes.io/cors-allow-methods: "GET,POST"
    nginx.ingress.kubernetes.io/cors-allow-headers: "X-Foo-Bar"
    nginx.ingress.kubernetes.io/cors-allow-credentials: "false"
  name: demo
spec:
  ingressClassName: apig
  rules:
    - http:
        paths:
          - backend:
              service:
                name: demo-service
                port: 
                  number: 80
            path: /hello
            pathType: Exact

    Kubernetes 1.19 より前のバージョンを実行するクラスタ

    apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  annotations:
    nginx.ingress.kubernetes.io/enable-cors: "true"
    nginx.ingress.kubernetes.io/cors-allow-origin: "example.com"
    nginx.ingress.kubernetes.io/cors-allow-methods: "GET,POST"
    nginx.ingress.kubernetes.io/cors-allow-headers: "X-Foo-Bar"
    nginx.ingress.kubernetes.io/cors-allow-credentials: "false"
  name: demo
spec:
  ingressClassName: apig
  rules:
    - http:
        paths:
          - path: /hello
            backend:
              serviceName: demo-service
              servicePort: 80

    正規表現マッチ

    標準 Kubernetes Ingress は完全一致とプレフィックス一致のみをサポートしますが、APIG Ingress は正規表現マッチもサポートします。アノテーション nginx.ingress.kubernetes.io/use-regex: true を使用して、Ingress 仕様で定義されたパスの正規表現マッチを有効にできます。

    想定されるドメイン名が example.com の場合、リクエストパスが /app または /test で始まるリクエストはサービス demo に転送されます。設定例:

    Kubernetes 1.19 以降を実行するクラスタ

    apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    nginx.ingress.kubernetes.io/use-regex: 'true'
  name: regex-match
  namespace: default
spec:
  ingressClassName: apig
  rules:
    - http:
        paths:
          - backend:
              service:
                name: demo
                port: 
                  number: 8080
            path: /(app|test)/(.*)
            pathType: Prefix

    Kubernetes 1.19 より前のバージョンを実行するクラスタ

    apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  annotations:
    nginx.ingress.kubernetes.io/use-regex: 'true'
  name: regex-match
  namespace: default
spec:
  ingressClassName: apig
  rules:
    - http:
        paths:
          - path: /(app|test)/(.*)
            backend:
              serviceName: demo
              servicePort: 8080

    パスとホストの書き換え

    リクエストが宛先バックエンド サービスに転送される前に、書き換え操作を実行してリクエスト内の元のパスとホストを変更できます。

    アノテーション

    説明

    nginx.ingress.kubernetes.io/rewrite-target

    書き換え操作の宛先パスを指定します。キャプチャ グループがサポートされています。

    nginx.ingress.kubernetes.io/upstream-vhost

    ホストの書き換え

    パスの書き換え

    1. example.com/test リクエストがバックエンド サービスに転送される前に、example.com/test を example.com/dev として書き換えます。設定例:

      Kubernetes 1.19 以降を実行するクラスタ

      apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: "/dev"
  name: demo
spec:
  ingressClassName: apig
  rules:
    - host: example.com
      http:
        paths:
          - backend:
              service:
                name: demo-service
                port: 
                  number: 80
            path: /test
            pathType: Exact

      Kubernetes 1.19 より前のバージョンを実行するクラスタ

      apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: "/dev"
  name: demo
spec:
  ingressClassName: apig
  rules:
    - http:
        paths:
          - path: /test
            pathType: Exact
            backend:
              serviceName: demo-service
              servicePort: 80

    2. example.com/v1/xxx リクエストがバックエンド サービスに転送される前に、プレフィックス /v1 を削除し、リクエストを example.com/xxx として書き換えます。設定例:

      Kubernetes 1.19 以降を実行するクラスタ

      apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: "/$1"
  name: demo
spec:
  ingressClassName: apig
  rules:
    - host: example.com
      http:
        paths:
          - backend:
              service:
                name: demo-service
                port: 
                  number: 80
            path: /v1/(.*)
            pathType: Prefix

      Kubernetes 1.19 より前のバージョンを実行するクラスタ

      apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: "/$1"
  name: demo
spec:
  ingressClassName: apig
  rules:
    - http:
        paths:
          - path: /v1/(.*) 
          	pathType: Prefix
            backend:
              serviceName: demo-service
              servicePort: 80

    3. example.com/v1/xxx リクエストがバックエンド サービスに転送される前に、プレフィックス /v1 を /v2 に変更し、リクエストを example.com/v2/xxx として書き換えます。設定例:

      Kubernetes 1.19 以降を実行するクラスタ

      apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: "/v2/$1"
  name: demo
spec:
  ingressClassName: apig
  rules:
    - host: example.com
      http:
        paths:
          - backend:
              service:
                name: demo-service
                port: 
                  number: 80
            path: /v1/(.*)
            pathType: Prefix

      Kubernetes 1.19 より前のバージョンを実行するクラスタ

      apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: "/v2/$1"
  name: demo
spec:
  ingressClassName: apig
  rules:
    - http:
        paths:
          - path: /v1/(.*)
            pathType: Prefix
            backend:
              serviceName: demo-service
              servicePort: 80

    ホストの書き換え

    たとえば、example.com/test リクエストがバックエンド サービスに転送される前に、example.com/test を test.com/test として書き換えます。設定例:

    Kubernetes 1.19 以降を実行するクラスタ

    apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    nginx.ingress.kubernetes.io/upstream-vhost: "test.com"
  name: demo
spec:
  ingressClassName: apig
  rules:
    - host: example.com
      http:
        paths:
          - backend:
              service:
                name: demo-service
                port: 
                  number: 80
            path: /test
            pathType: Exact

    Kubernetes 1.19 より前のバージョンを実行するクラスタ

    apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  annotations:
    nginx.ingress.kubernetes.io/upstream-vhost: "test.com"
  name: demo
spec:
  ingressClassName: apig
  rules:
    - host: example.com 
      http:
        paths:
          - path: /test
            backend:
              serviceName: demo-service
              servicePort: 80

    リダイレクト

    リダイレクトは、元のクライアント リクエストを宛先リクエストに変更するために使用されます。

    HTTP から HTTPS へのリダイレクト

    アノテーション

    説明

    nginx.ingress.kubernetes.io/ssl-redirect

    HTTP から HTTPS へのリダイレクト

    nginx.ingress.kubernetes.io/force-ssl-redirect

    HTTP リクエストを HTTPS リクエストにリダイレクトするかどうかを指定します。

    説明

    APIG Ingress は両方のアノテーションを同じように扱い、HTTP リクエストを HTTPS に強制的にリダイレクトします。

    たとえば、リクエスト http://example.com/test を https://example.com/test にリダイレクトします。設定例:

    Kubernetes 1.19 以降を実行するクラスタ

    apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    nginx.ingress.kubernetes.io/ssl-redirect: "true"
  name: demo
spec:
  ingressClassName: apig
  rules:
    - host: example.com
      http:
        paths:
          - backend:
              service:
                name: demo-service
                port: 
                  number: 80
            path: /test
            pathType: Exact

    Kubernetes 1.19 より前のバージョンを実行するクラスタ

    apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  annotations:
    nginx.ingress.kubernetes.io/ssl-redirect: "true"
  name: demo
spec:
  ingressClassName: apig
  rules:
    - host: example.com 
      http:
        paths:
          - path: /test
            backend:
              serviceName: demo-service
              servicePort: 80

    恒久的なリダイレクト

    アノテーション

    説明

    nginx.ingress.kubernetes.io/permanent-redirect

    恒久的なリダイレクトの宛先 URL を指定します。宛先 URL には、HTTP または HTTPS のスキームを含める必要があります。

    nginx.ingress.kubernetes.io/permanent-redirect-code

    恒久的なリダイレクトの HTTP ステータスコードを指定します。デフォルト値: 301。

    たとえば、http://example.com/test から http://example.com/app に恒久的なリダイレクトを実行します。設定例:

    Kubernetes 1.19 以降を実行するクラスタ

    apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    nginx.ingress.kubernetes.io/permanent-redirect: "http://example.com/app"
  name: demo
spec:
  ingressClassName: apig
  rules:
    - host: example.com
      http:
        paths:
          - backend:
              service:
                name: demo-service
                port: 
                  number: 80
            path: /test
            pathType: Exact

    Kubernetes 1.19 より前のバージョンを実行するクラスタ

    apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  annotations:
    nginx.ingress.kubernetes.io/permanent-redirect: "http://example.com/app"
  name: demo
spec:
  ingressClassName: apig
  rules:
    - host: example.com 
      http:
        paths:
          - path: /test
            backend:
              serviceName: demo-service
              servicePort: 80

    一時的なリダイレクト

    nginx.ingress.kubernetes.io/temporal-redirect: 一時的なリダイレクトの宛先 URL を指定します。宛先 URL には、HTTP または HTTPS のスキームを含める必要があります。

    たとえば、http://example.com/test から http://example.com/app に一時的なリダイレクトを実行します。設定例:

    Kubernetes 1.19 以降を実行するクラスタ

    apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    nginx.ingress.kubernetes.io/temporal-redirect: "http://example.com/app"
  name: demo
spec:
  ingressClassName: apig
  rules:
    - host: example.com
      http:
        paths:
          - backend:
              service:
                name: demo-service
                port: 
                  number: 80
            path: /test
            pathType: Exact

    Kubernetes 1.19 より前のバージョンを実行するクラスタ

    apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  annotations:
    nginx.ingress.kubernetes.io/temporal-redirect: "http://example.com/app"
  name: demo
spec:
  ingressClassName: apig
  rules:
    - host: example.com 
      http:
        paths:
          - path: /test
            backend:
              serviceName: demo-service
              servicePort: 80

    ヘッダー制御

    ヘッダー制御を使用すると、Hingress Ingress がリクエストをバックエンド サービスに転送する前に、リクエスト ヘッダーを追加、削除、または変更できます。 また、Hingress Ingress が受信したレスポンスをクライアントに転送する前に、レスポンス ヘッダーを追加、削除、または変更することもできます。

    リクエスト ヘッダー制御

    アノテーション

    説明

    higress.ingress.kubernetes.io/request-header-control-add

    リクエストがバックエンド サービスに転送されるときに、リクエストに追加されるヘッダーを指定します。 ヘッダーが存在する場合、その値は元の値の後に連結されます。 構文：

    • 単一ヘッダー：キーと値のペアが使用されます。

    • 複数ヘッダー：YAML 特殊文字 | を使用し、各キーと値のペアを別の行に配置します。

    higress.ingress.kubernetes.io/request-header-control-update

    リクエストがバックエンド サービスに転送されるときに、リクエスト内で変更されるヘッダーを指定します。 ヘッダーが存在する場合、その値は元の値を上書きします。 構文：

    • 単一ヘッダー：キーと値のペアが使用されます。

    • 複数ヘッダー：YAML 特殊文字 | を使用し、各キーと値のペアを別の行に配置します。

    higress.ingress.kubernetes.io/request-header-control-remove

    リクエストがバックエンド サービスに転送されるときに、リクエストから削除されるヘッダーを指定します。 構文：

    • 単一ヘッダー：キーが使用されます。

    • 複数ヘッダー：複数のヘッダーをカンマ (,) で区切ります。

    例：

    • リクエスト example.com/test にヘッダー foo: bar と test: true を追加します。 設定例：

      Kubernetes 1.19 以降を実行するクラスタ

      apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    higress.ingress.kubernetes.io/request-header-control-add: |
      foo bar
      test true
  name: demo
spec:
  ingressClassName: apig
  rules:
    - host: example.com
      http:
        paths:
          - backend:
              service:
                name: demo-service
                port: 
                  number: 80
            path: /test
            pathType: Exact

      Kubernetes 1.19 より前のバージョンを実行するクラスタ

      apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  annotations:
    higress.ingress.kubernetes.io/request-header-control-add: |
      foo bar
      test true
  name: demo
spec:
  ingressClassName: apig
  rules:
    - host: example.com 
      http:
        paths:
          - path: /test
            backend:
              serviceName: demo-service
              servicePort: 80

    • ヘッダー制御と段階的リリースを組み合わせて、カナリアトラフィックにタグを付けることができます。リクエストヘッダーが `apig: v1` の場合、リクエストはカナリアサービス `demo-service-canary-v1` にルーティングされ、ヘッダー `stage: gray` が追加されます。それ以外の場合、リクエストは本番サービス `demo-service` にルーティングされ、ヘッダー `stage: production` が追加されます。以下のサンプルコードは設定を示しています：

      Kubernetes 1.19 以降を実行するクラスタ

      apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    nginx.ingress.kubernetes.io/canary: "true"
    nginx.ingress.kubernetes.io/canary-by-header: "apig"
    nginx.ingress.kubernetes.io/canary-by-header-value: "v1"
    higress.ingress.kubernetes.io/request-header-control-add: "stage gray"
  name: demo-canary-v1
spec:
  ingressClassName: apig
  rules:
    - http:
        paths:
          - backend:
              service:
                name: demo-service-canary-v1
                port: 
                  number: 80
            path: /hello
            pathType: Exact
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    higress.ingress.kubernetes.io/request-header-control-add: "stage production"
  name: demo
spec:
  ingressClassName: apig
  rules:
    - http:
        paths:
          - backend:
              service:
                name: demo-service
                port: 
                  number: 80
            path: /hello
            pathType: Exact

      Kubernetes 1.19 より前のバージョンを実行するクラスタ

      apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  annotations:
    nginx.ingress.kubernetes.io/canary: "true"
    nginx.ingress.kubernetes.io/canary-by-header: "apig"
    nginx.ingress.kubernetes.io/canary-by-header-value: "v1"
    higress.ingress.kubernetes.io/request-header-control-add: "stage gray"
  name: demo-canary-v1
spec:
  ingressClassName: apig
  rules:
    - http:
        paths:
          - path: /hello
            backend:
              serviceName: demo-service-canary-v1
              servicePort: 80
---
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  annotations:
    higress.ingress.kubernetes.io/request-header-control-add: |
      foo bar
      test true
  name: demo
spec:
  ingressClassName: apig
  rules:
    - host: example.com 
      http:
        paths:
          - path: /hello
            backend:
              serviceName: demo-service
              servicePort: 80

    レスポンス ヘッダー制御

    アノテーション

    説明

    higress.ingress.kubernetes.io/response-header-control-add

    バックエンド サービスから受信したレスポンスに、クライアントに転送される前に追加されるヘッダーを指定します。 ヘッダーが存在する場合、その値は元の値の後に連結されます。 構文：

    • 単一ヘッダー：キーと値のペアが使用されます。

    • 複数ヘッダー：YAML 特殊文字 | を使用し、各キーと値のペアを別の行に配置します。

    higress.ingress.kubernetes.io/response-header-control-update

    バックエンド サービスから受信したレスポンスに、クライアントに転送される前に変更されるヘッダーを指定します。 ヘッダーが存在する場合、その値は元の値を上書きします。 構文：

    • 単一ヘッダー：キーと値のペアが使用されます。

    • 複数ヘッダー：YAML 特殊文字 | を使用し、各キーと値のペアを別の行に配置します。

    higress.ingress.kubernetes.io/response-header-control-remove

    バックエンド サービスから受信したレスポンスから、クライアントに転送される前に削除されるヘッダーを指定します。 構文：

    • 単一ヘッダー：キーが使用されます。

    • 複数ヘッダー：複数のヘッダーをカンマ (,) で区切ります。

    たとえば、リクエスト example.com/test へのレスポンスからヘッダー req-cost-time を削除します。 設定例：

    Kubernetes 1.19 以降を実行するクラスタ

    apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    higress.ingress.kubernetes.io/response-header-control-remove: "req-cost-time"
  name: demo
spec:
  ingressClassName: apig
  rules:
    - host: example.com
      http:
        paths:
          - backend:
              service:
                name: demo-service
                port: 
                  number: 80
            path: /test
            pathType: Exact

    Kubernetes 1.19 より前のバージョンを実行するクラスタ

    apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  annotations:
    higress.ingress.kubernetes.io/response-header-control-remove: "req-cost-time"
  name: demo
spec:
  ingressClassName: apig
  rules:
    - host: example.com 
      http:
        paths:
          - path: /test
            backend:
              serviceName: demo-service
              servicePort: 80

    リトライ

    APIG Ingress は、ルートレベルのリトライ設定を提供し、失敗したリクエストを自動的にリトライします。必要に応じてリトライ条件を設定できます。たとえば、接続に失敗した場合、バックエンド サービスが利用できない場合、または特定の HTTP ステータスコードが返された場合にリクエストをリトライできます。

    アノテーション

    説明

    nginx.ingress.kubernetes.io/proxy-next-upstream-tries

    リクエストリトライの最大回数を指定します。デフォルト値：3。

    nginx.ingress.kubernetes.io/proxy-next-upstream-timeout

    リクエストリトライのタイムアウト期間を指定します。単位：秒。デフォルトでは、タイムアウト期間は構成されていません。

    nginx.ingress.kubernetes.io/proxy-next-upstream

    リクエストをリトライする条件。複数の条件はカンマ (,) で区切ります。デフォルト値は error,timeout です。有効な値は次のとおりです。

    • error：接続の確立に失敗し、ステータスコード 5xx が返されます。

    • timeout：接続の確立がタイムアウトし、ステータスコード 5xx が返されます。

    • invalid_header：リクエストエラーが発生し、ステータスコード 5xx が返されます。

    • http_xxx：返されたステータスコードに基づいてリトライがトリガーされます。例：http_502 および http_403。

    • non_idempotent：失敗した非冪等リクエストに対してリトライがトリガーされます。デフォルトでは、APIG Ingress は、POST リクエストや PATCH リクエストなどの失敗した非冪等リクエストをリトライしません。「non_idempotent」を構成すると、これらのリクエストのリトライを有効にできます。

    • off：リトライは無効になります。

    たとえば、example/test リクエストが利用可能です。リクエストの場合、リクエストリトライの最大回数を 2 に設定し、リトライタイムアウト期間を 5 秒に設定し、ステータスコード 502 が返された場合にのみリトライをトリガーし、非冪等リクエストのリトライを有効にします。設定例：

    Kubernetes 1.19 以降を実行するクラスタ

    apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    nginx.ingress.kubernetes.io/proxy-next-upstream-tries: "2"
    nginx.ingress.kubernetes.io/proxy-next-upstream-timeout: "5"
    nginx.ingress.kubernetes.io/proxy-next-upstream: "http_502,non_idempotent"
  name: demo
spec:
  ingressClassName: apig
  rules:
    - host: example.com
      http:
        paths:
          - backend:
              service:
                name: demo-service
                port: 
                  number: 80
            path: /test
            pathType: Exact

    Kubernetes 1.19 より前のバージョンを実行するクラスタ

    apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  annotations:
    nginx.ingress.kubernetes.io/proxy-next-upstream-tries: "2"
    nginx.ingress.kubernetes.io/proxy-next-upstream-timeout: "5"
    nginx.ingress.kubernetes.io/proxy-next-upstream: "http_502,non_idempotent"
  name: demo
spec:
  ingressClassName: apig
  rules:
    - host: example.com 
      http:
        paths:
          - path: /test
            backend:
              serviceName: demo-service
              servicePort: 80

    IP アドレスのホワイトリストとブラックリストに基づくアクセス制御

    APIG Ingress は、ドメインレベルとルートレベルで IP ブラックリストとホワイトリストのアクセス制御を提供します。ルートレベルのルールは、ドメインレベルのルールよりも優先順位が高くなります。

    ルートレベルの IP アドレスのホワイトリストとブラックリスト

    アノテーション

    説明

    nginx.ingress.kubernetes.io/whitelist-source-range

    特定のルートの IP アドレスのホワイトリストを指定します。IP アドレスと CIDR ブロックがサポートされています。IP アドレスまたは CIDR ブロックはカンマ (,) で区切ります。

    higress.ingress.kubernetes.io/blacklist-source-range

    特定のルートの IP アドレスのブラックリストを指定します。IP アドレスと CIDR ブロックがサポートされています。IP アドレスまたは CIDR ブロックはカンマ (,) で区切ります。

    例:

    • クライアント IP アドレス 1.1.xx.xx から example.com/test へのアクセスを許可します。設定例:

      Kubernetes 1.19 以降を実行するクラスタ

      apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    nginx.ingress.kubernetes.io/whitelist-source-range: 1.1.X.X
  name: demo
spec:
  ingressClassName: apig
  rules:
    - host: example.com
      http:
        paths:
          - backend:
              service:
                name: demo-service
                port: 
                  number: 80
            path: /test
            pathType: Exact

      Kubernetes 1.19 より前のバージョンを実行するクラスタ

      apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  annotations:
    nginx.ingress.kubernetes.io/whitelist-source-range: 1.1.X.X
  name: demo
spec:
  ingressClassName: apig
  rules:
    - host: example.com 
      http:
        paths:
          - path: /test
            backend:
              serviceName: demo-service
              servicePort: 80

    • クライアント IP アドレス 2.2.xx.xx から example.com/test へのアクセスを拒否します。設定例:

      Kubernetes 1.19 以降を実行するクラスタ

      apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    higress.ingress.kubernetes.io/blacklist-source-range: 2.2.2.2
  name: demo
spec:
  ingressClassName: apig
  rules:
    - host: example.com
      http:
        paths:
          - backend:
              service:
                name: demo-service
                port: 
                  number: 80
            path: /test
            pathType: Exact

      Kubernetes 1.19 より前のバージョンを実行するクラスタ

      apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  annotations:
    higress.ingress.kubernetes.io/blacklist-source-range: 2.2.2.2
  name: demo
spec:
  ingressClassName: apig
  rules:
    - host: example.com
      http:
        paths:
          - path: /test
            backend:
              serviceName: demo-service
              servicePort: 80

    ドメイン名レベルの IP アドレスのホワイトリストとブラックリスト

    アノテーション

    説明

    higress.ingress.kubernetes.io/domain-whitelist-source-range

    特定のドメイン名の IP アドレスのホワイトリストを指定します。ルートレベルの IP アドレスのホワイトリストは、ドメイン名レベルの IP アドレスのホワイトリストよりも優先されます。IP アドレスと CIDR ブロックがサポートされています。IP アドレスまたは CIDR ブロックはカンマ (,) で区切ります。

    higress.ingress.kubernetes.io/domain-blacklist-source-range

    特定のドメイン名の IP アドレスのブラックリストを指定します。ルートレベルの IP アドレスのブラックリストは、ドメイン名レベルの IP アドレスのブラックリストよりも優先されます。IP アドレスと CIDR ブロックがサポートされています。IP アドレスまたは CIDR ブロックはカンマ (,) で区切ります。

    例:

    • クライアント IP アドレス 1.1.xx.xx と 2.2.xx.xx からドメイン名 example.com のすべてのルートへのアクセスを許可します。設定例:

      Kubernetes 1.19 以降を実行するクラスタ

      apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    higress.ingress.kubernetes.io/domain-whitelist-source-range: 1.1.X.X,2.2.2.2
  name: demo
spec:
  ingressClassName: apig
  rules:
    - host: example.com
      http:
        paths:
          - backend:
              service:
                name: demo-service
                port: 
                  number: 80
            path: /test
            pathType: Exact
         - backend:
              service:
                name: app-service
                port: 
                  number: 80
            path: /app
            pathType: Exact

      Kubernetes 1.19 より前のバージョンを実行するクラスタ

      apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  annotations:
    higress.ingress.kubernetes.io/domain-whitelist-source-range: 1.1.X.X,2.2.2.2
  name: demo
spec:
  ingressClassName: apig
  rules:
    - host: example.com
      http:
        paths:
          - path: /test
            backend:
              serviceName: demo-service
              servicePort: 80
          - path: /app
            backend:
              serviceName: app-service
              servicePort: 80

    • ドメイン名レベルの IP アドレスのホワイトリストとブラックリストをルートレベルの IP アドレスのホワイトリストとブラックリストと共に使用します。クライアント IP アドレス 1.1.xx.xx と 2.2.xx.xx から example.com ドメイン名のすべてのルートへのアクセスを許可し、クライアント IP アドレス 3.3.xx.xx からのみ example.com/order ルートへのアクセスを許可します。設定例:

      Kubernetes 1.19 以降を実行するクラスタ

      apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    higress.ingress.kubernetes.io/domain-whitelist-source-range: 1.1.X.X,2.2.2.2
  name: demo-domain
spec:
  ingressClassName: apig
  rules:
    - host: example.com
      http:
        paths:
          - backend:
              service:
                name: demo-service
                port: 
                  number: 80
            path: /test
            pathType: Exact
         - backend:
              service:
                name: app-service
                port: 
                  number: 80
            path: /app
            pathType: Exact
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    nginx.ingress.kubernetes.io/whitelist-source-range: 3.3.X.X
  name: demo-route
spec:
  ingressClassName: apig
  rules:
    - host: example.com
      http:
        paths:
          - backend:
              service:
                name: demo-service
                port: 
                  number: 80
            path: /order
            pathType: Exact

      Kubernetes 1.19 より前のバージョンを実行するクラスタ

      apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  annotations:
    higress.ingress.kubernetes.io/domain-whitelist-source-range: 1.1.X.X,2.2.2.2
  name: demo-domain
spec:
  ingressClassName: apig
  rules:
    - host: example.com
      http:
        paths:
          - path: /test
            backend:
              serviceName: demo-service
              servicePort: 80
          - path: /app
            backend:
              serviceName: app-service
              servicePort: 80
---
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  annotations:
    nginx.ingress.kubernetes.io/whitelist-source-range: 3.3.X.X
  name: demo-route
spec:
  ingressClassName: apig
  rules:
    - host: example.com
      http:
        paths:
          - path: /order
            backend:
              serviceName: demo-service
              servicePort: 80

    単一ゲートウェイのスロットリング

    APIG Ingress は、単一のゲートウェイインスタンスのルートレベルのスロットリングポリシーをサポートしています。これらのポリシーは、設定された期間内における各ゲートウェイレプリカの特定のルートへのリクエスト数を定義済みのしきい値に制限します。

    説明

    システムは、構成されたしきい値に基づいて単一の Cloud-native API Gateway インスタンスのスロットリングを実行します。 Cloud-native API Gateway クラスタのルートのトラフィックをスロットルする場合は、代わりにグローバルスロットリング制御ポリシーを使用できます。

    アノテーション

    説明

    higress.ingress.kubernetes.io/route-limit-rpm

    Cloud-native API Gateway インスタンスでルーティングされる1分あたりの最大リクエスト数 (RPM) を指定します。最大 RPM のバースト制限は、指定された値に higress.ingress.kubernetes.io/route-limit-burst-multiplier を掛けた値と同じです。

    スロットリングがトリガーされると、レスポンス本文は local_rate_limited になります。応答状態コードは次のとおりです。

    • Cloud-native API Gateway のバージョンが 1.2.23 より前の場合、状態コード 503 が返されます。

    • Cloud-native API Gateway のバージョンが 1.2.23 以後の場合、状態コード 429 が返されます。

    higress.ingress.kubernetes.io/route-limit-rps

    Cloud-native API Gateway インスタンスでルーティングされる1秒あたりの最大リクエスト数 (RPS) を指定します。最大 RPS のバースト制限は、指定された値に higress.ingress.kubernetes.io/route-limit-burst-multiplier を掛けた値と同じです。

    スロットリングがトリガーされると、レスポンス本文は local_rate_limited になります。応答状態コードは次のとおりです。

    • Cloud-native API Gateway のバージョンが 1.2.23 より前の場合、状態コード 503 が返されます。

    • Cloud-native API Gateway のバージョンが 1.2.23 以後の場合、状態コード 429 が返されます。

    higress.ingress.kubernetes.io/route-limit-burst-multiplier

    バースト制限の乗数を指定します。デフォルト値：5。

    例：

    • example.com/test リクエストの場合、最大 RPM を 100 に設定し、最大 RPM のバースト制限を 200 に設定します。設定例：

      Kubernetes 1.19 以降を実行するクラスタ

      apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    higress.ingress.kubernetes.io/route-limit-rpm: "100"
    higress.ingress.kubernetes.io/route-limit-burst-multiplier: "2"
  name: demo
spec:
  ingressClassName: apig
  rules:
    - host: example.com
      http:
        paths:
          - backend:
              service:
                name: demo-service
                port: 
                  number: 80
            path: /test
            pathType: Exact

      Kubernetes 1.19 より前のバージョンを実行するクラスタ

      apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  annotations:
    higress.ingress.kubernetes.io/route-limit-rpm: "100"
    higress.ingress.kubernetes.io/route-limit-burst-multiplier: "2"
  name: demo
spec:
  ingressClassName: apig
  rules:
    - host: example.com
      http:
        paths:
          - path: /test
            backend:
              serviceName: demo-service
              servicePort: 80

    • example.com/test リクエストの場合、最大 RPS を 10 に設定し、最大 RPS のバースト制限を 50 に設定します。設定例：

      Kubernetes 1.19 以降を実行するクラスタ

      apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    higress.ingress.kubernetes.io/route-limit-rps: "10"
    # デフォルト値は 5 です。
    # higress.ingress.kubernetes.io/route-limit-burst-multiplier: "5"
  name: demo
spec:
  ingressClassName: apig
  rules:
    - host: example.com
      http:
        paths:
          - backend:
              service:
                name: demo-service
                port: 
                  number: 80
            path: /test
            pathType: Exact

      Kubernetes 1.19 より前のバージョンを実行するクラスタ

      apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  annotations:
    higress.ingress.kubernetes.io/route-limit-rps: "10"
    # デフォルト値は 5 です。
    # higress.ingress.kubernetes.io/route-limit-burst-multiplier: "5"
  name: demo
spec:
  ingressClassName: apig
  rules:
    - host: example.com
      http:
        paths:
          - path: /test
            backend:
              serviceName: demo-service
              servicePort: 80

    グローバル速度制限制御

    APIG Ingress は Sentinel と統合して、ゲートウェイ クラスタのグローバルなルートレベルの速度制限を提供します。これにより、クラスタ全体で特定のルートに対する 1 秒あたりの最大リクエスト数 (RPS) が制限されます。

    説明

    この機能には、APIG Ingress ゲートウェイ バージョン 1.2.25 以降が必要です。

    higress.ingress.kubernetes.io/rate-limit アノテーションを使用して、ゲートウェイ クラスタ全体のルートの最大 RPS を設定します。速度制限がトリガーされると、デフォルトの動作では、応答本文 `sentinel rate limited` と共に 429 状態コードが返されます。 APIG Ingress は、この動作をカスタマイズする 2 つの方法を提供します。カスタム応答またはリダイレクトです。これらのメソッドは 1 つだけ使用できます。

    カスタム応答

    • higress.ingress.kubernetes.io/rate-limit-fallback-custom-response-code: 速度制限がトリガーされたときの応答状態コード。デフォルトは 429 です。

    • higress.ingress.kubernetes.io/rate-limit-fallback-custom-response-body-type: 速度制限がトリガーされたときの応答本文のフォーマット。デフォルトは text です。

      • text に設定すると、応答の Content-Type は text/plain; charset=UTF-8 になります。

      • json に設定すると、応答の Content-Type は application/json; charset=UTF-8 になります。

    • higress.ingress.kubernetes.io/rate-limit-fallback-custom-response-body: 速度制限がトリガーされたときの応答本文。デフォルトは sentinel rate limited です。

    例 1：Cloud-native API Gateway クラスタの example.com/test リクエストの最大 RPS を 100 に設定し、デフォルトの速度制限動作を保持します。設定例：

    Kubernetes 1.19 以降を実行するクラスタ

    apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    higress.ingress.kubernetes.io/rate-limit: "100"
  name: demo
spec:
  ingressClassName: apig
  rules:
    - host: example.com
      http:
        paths:
          - backend:
              service:
                name: demo-service
                port: 
                  number: 80
            path: /test
            pathType: Exact

    Kubernetes 1.19 より前のバージョンを実行するクラスタ

    apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  annotations:
    higress.ingress.kubernetes.io/rate-limit: "100"
  name: demo
spec:
  ingressClassName: apig
  rules:
    - host: example.com
      http:
        paths:
          - path: /test
            backend:
              serviceName: demo-service
              servicePort: 80

    例 2：Cloud-native API Gateway クラスタの example.com/test リクエストの最大 RPS を 100 に設定し、速度制限がトリガーされたときの応答コードを 503 に、応答本文を server is overload に設定します。

    Kubernetes 1.19 以降を実行するクラスタ

    apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    higress.ingress.kubernetes.io/rate-limit: "100"
    higress.ingress.kubernetes.io/rate-limit-fallback-custom-response-code: "503"
    higress.ingress.kubernetes.io/rate-limit-fallback-custom-response-body: "server is overload"
  name: demo
spec:
  ingressClassName: apig
  rules:
    - host: example.com
      http:
        paths:
          - backend:
              service:
                name: demo-service
                port: 
                  number: 80
            path: /test
            pathType: Exact

    Kubernetes 1.19 より前のバージョンを実行するクラスタ

    apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  annotations:
    higress.ingress.kubernetes.io/rate-limit: "100"
    higress.ingress.kubernetes.io/rate-limit-fallback-custom-response-code: "503"
    higress.ingress.kubernetes.io/rate-limit-fallback-custom-response-body: "server is overload"
  name: demo
spec:
  ingressClassName: apig
  rules:
    - host: example.com
      http:
        paths:
          - path: /test
            backend:
              serviceName: demo-service
              servicePort: 80

    リダイレクト

    • higress.ingress.kubernetes.io/rate-limit-fallback-redirect-url: 速度制限がトリガーされたときにリダイレクトされる URL。

    例 1：Cloud-native API Gateway クラスタの example.com/test リクエストの最大 RPS を 100 に設定し、速度制限がトリガーされたときの URL を example.com/fallback に設定します。

    Kubernetes 1.19 以降を実行するクラスタ

    apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    higress.ingress.kubernetes.io/rate-limit: "100"
    higress.ingress.kubernetes.io/rate-limit-fallback-redirect-url: "example.com/fallback"
  name: demo
spec:
  ingressClassName: apig
  rules:
    - host: example.com
      http:
        paths:
          - backend:
              service:
                name: demo-service
                port: 
                  number: 80
            path: /test
            pathType: Exact

    Kubernetes 1.19 より前のバージョンを実行するクラスタ

    apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  annotations:
    higress.ingress.kubernetes.io/rate-limit: "100"
    higress.ingress.kubernetes.io/rate-limit-fallback-redirect-url: "example.com/fallback"
  name: demo
spec:
  ingressClassName: apig
  rules:
    - host: example.com
      http:
        paths:
          - path: /test
            backend:
              serviceName: demo-service
              servicePort: 80

    グローバル同時実行制御

    APIG Ingress は Sentinel と統合して、ゲートウェイ クラスタのグローバルなルートレベルの同時実行制御を提供します。これにより、クラスタ全体で特定のルートに対して処理される同時リクエストの最大数が制限されます。

    説明

    この機能には、APIG Ingress ゲートウェイ バージョン 1.2.25 以降が必要です。

    higress.ingress.kubernetes.io/concurrency-limit アノテーションを使用して、ゲートウェイ クラスタ全体のルートに対する同時リクエストの最大数を設定します。同時実行制御がトリガーされると、デフォルトの応答の状態コードは 429 で、本文は sentinel rate limited です。APIG Ingress は、この動作をカスタマイズする 2 つの方法を提供します。カスタム応答またはリダイレクトです。これらのメソッドは 1 つだけ使用できます。

    カスタム応答

    • higress.ingress.kubernetes.io/concurrency-limit-fallback-custom-response-code: 同時実行制御がトリガーされたときの応答状態コード。デフォルトは 429 です。

    • higress.ingress.kubernetes.io/concurrency-limit-fallback-custom-response-body-type: 同時実行制御がトリガーされたときの応答本文のフォーマット。デフォルトは text です。

      • text に設定すると、応答の Content-Type は text/plain; charset=UTF-8 になります。

      • json に設定すると、応答の Content-Type は application/json; charset=UTF-8 になります。

    • higress.ingress.kubernetes.io/concurrency-limit-fallback-custom-response-body: 同時実行制御がトリガーされたときの応答本文。デフォルトは sentinel rate limited です。

    例 1: ゲートウェイ クラスタで処理される example.com/test リクエストの最大数を 1000 に設定し、デフォルトの同時実行制御動作を保持します。設定例:

    Kubernetes 1.19 以降を実行するクラスタ

    apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    higress.ingress.kubernetes.io/concurrency-limit: "1000"
  name: demo
spec:
  ingressClassName: apig
  rules:
    - host: example.com
      http:
        paths:
          - backend:
              service:
                name: demo-service
                port: 
                  number: 80
            path: /test
            pathType: Exact

    Kubernetes 1.19 より前のバージョンを実行するクラスタ

    apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  annotations:
    higress.ingress.kubernetes.io/concurrency-limit: "1000"
  name: demo
spec:
  ingressClassName: apig
  rules:
    - host: example.com
      http:
        paths:
          - path: /test
            backend:
              serviceName: demo-service
              servicePort: 80

    例 2: ゲートウェイ クラスタ上の `example.com/test` の同時リクエストの最大数を 1,000 に制限します。同時実行制御がトリガーされたら、状態コード 503 と応答本文 server is overloaded を返します。

    Kubernetes 1.19 以降を実行するクラスタ

    apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    higress.ingress.kubernetes.io/concurrency-limit: "1000"
    higress.ingress.kubernetes.io/concurrency-limit-fallback-custom-response-code: "503"
    higress.ingress.kubernetes.io/concurrency-limit-fallback-custom-response-body: "server is overload"
  name: demo
spec:
  ingressClassName: apig
  rules:
    - host: example.com
      http:
        paths:
          - backend:
              service:
                name: demo-service
                port: 
                  number: 80
            path: /test
            pathType: Exact

    Kubernetes 1.19 より前のバージョンを実行するクラスタ

    apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  annotations:
    higress.ingress.kubernetes.io/concurrency-limit: "1000"
    higress.ingress.kubernetes.io/concurrency-limit-fallback-custom-response-code: "503"
    higress.ingress.kubernetes.io/concurrency-limit-fallback-custom-response-body: "server is overload"
  name: demo
spec:
  ingressClassName: apig
  rules:
    - host: example.com
      http:
        paths:
          - path: /test
            backend:
              serviceName: demo-service
              servicePort: 80

    リダイレクト

    • higress.ingress.kubernetes.io/concurrency-limit-fallback-redirect-url: 同時実行制御がトリガーされたときにリダイレクトされる URL。

    Cloud-native API Gateway クラスタによって処理される example.com/test リクエストの最大数を 1,000 に設定し、同時実行制御がトリガーされたときの URL を example.com/fallback に設定します。

    Kubernetes 1.19 以降を実行するクラスタ

    apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    higress.ingress.kubernetes.io/concurrency-limit: "1000"
    higress.ingress.kubernetes.io/concurrency-limit-fallback-redirect-url: "example.com/fallback"
  name: demo
spec:
  ingressClassName: apig
  rules:
    - host: example.com
      http:
        paths:
          - backend:
              service:
                name: demo-service
                port: 
                  number: 80
            path: /test
            pathType: Exact

    Kubernetes 1.19 より前のバージョンを実行するクラスタ

    apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  annotations:
    higress.ingress.kubernetes.io/concurrency-limit: "1000"
    higress.ingress.kubernetes.io/concurrency-limit-fallback-redirect-url: "example.com/fallback"
  name: demo
spec:
  ingressClassName: apig
  rules:
    - host: example.com
      http:
        paths:
          - path: /test
            backend:
              serviceName: demo-service
              servicePort: 80

    トラフィックミラーリング

    トラフィックミラーリングを設定して、トラフィックを指定のサービスにコピーできます。 トラフィックミラーリングは、操作の監査やトラフィックテストなどのシナリオに適しています。

    • higress.ingress.kubernetes.io/mirror-target-service: コピーされたトラフィックの転送先サービス。 サービスのフォーマットは、namespace/name:port です。

      • namespace: Kubernetes サービスが存在する名前空間。 このパラメーターはオプションです。 デフォルトの名前空間は、Ingress ゲートウェイが存在する名前空間です。

      • name: Kubernetes サービスの名前。 このパラメーターは必須です。

      • port: ミラーリングされたトラフィックの転送先 Kubernetes サービスポート。 このパラメーターはオプションです。 デフォルトでは、最初のポートが使用されます。

    • higress.ingress.kubernetes.io/mirror-percentage: ミラーリングされたトラフィックの割合。 有効な値: 0 ～ 100。 デフォルト値: 100。

    説明

    コピーされたトラフィックが宛先サービスに転送されると、-shadow サフィックスが元の要求の Host ヘッダーに自動的に追加されます。

    たとえば、example.com/test からの要求はコピーされ、宛先サービス test/app:8080 に転送されます。

    説明

    この例では、コピーされたトラフィックが宛先サービスに転送されると、Host ヘッダーの値は自動的に example.com-shadow に変更されます。

    Kubernetes 1.19 以後のバージョンを実行するクラスタ

    apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    higress.ingress.kubernetes.io/mirror-target-service: test/app:8080
  name: demo
spec:
  ingressClassName: apig
  rules:
    - host: example.com
      http:
        paths:
          - backend:
              service:
                name: demo-service
                port: 
                  number: 80
            path: /test
            pathType: Exact

    Kubernetes 1.19 より前のバージョンを実行するクラスタ

    apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  annotations:
    higress.ingress.kubernetes.io/mirror-target-service: test/app:8080
  name: demo
spec:
  ingressClassName: apig
  rules:
    - host: example.com
      http:
        paths:
          - path: /test
            backend:
              serviceName: demo-service
              servicePort: 80

    たとえば、example.com/test からの要求はコピーされ、宛先サービス test/app:8080 に転送され、ミラーリングされたトラフィックの割合は 10% です。

    説明

    この例では、コピーされたトラフィックが宛先サービスに転送されると、Host ヘッダーの値は自動的に example.com-shadow に変更されます。

    Kubernetes 1.19 以後のバージョンを実行するクラスタ

    apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    higress.ingress.kubernetes.io/mirror-target-service: test/app:8080
    higress.ingress.kubernetes.io/mirror-percentage: "10"
  name: demo
spec:
  ingressClassName: apig
  rules:
    - host: example.com
      http:
        paths:
          - backend:
              service:
                name: demo-service
                port: 
                  number: 80
            path: /test
            pathType: Exact

    Kubernetes 1.19 より前のバージョンを実行するクラスタ

    apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  annotations:
    higress.ingress.kubernetes.io/mirror-target-service: test/app:8080
    higress.ingress.kubernetes.io/mirror-percentage: "10"
  name: demo
spec:
  ingressClassName: apig
  rules:
    - host: example.com
      http:
        paths:
          - path: /test
            backend:
              serviceName: demo-service
              servicePort: 80

    バックエンド サービス プロトコル: HTTPS と gRPC

    デフォルトでは、APIG Ingress は HTTP を使用してリクエストをバックエンド アプリケーション コンテナーに転送します。アプリケーション コンテナーが HTTPS を使用している場合は、アノテーション nginx.ingress.kubernetes.io/backend-protocol: "HTTPS" を使用して、HTTPS 経由でリクエストを転送できます。アプリケーション コンテナーが gRPC サービスの場合は、アノテーション nginx.ingress.kubernetes.io/backend-protocol: "GRPC" を使用して、gRPC 経由でリクエストを転送できます。

    説明

    NGINX Ingress とは異なり、バックエンド サービスの Kubernetes サービス リソースのポート名が `gRPC` または `HTTP2` として定義されている場合は、nginx.ingress.kubernetes.io/backend-protocol: "GRPC" アノテーションを構成する必要はありません。APIG Ingress は自動的に gRPC または HTTP/2 を使用します。

    例:

    • HTTPS を使用して example/test リクエストをバックエンド サービスに転送します。設定例:

      Kubernetes 1.19 以降を実行するクラスタ

      apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    nginx.ingress.kubernetes.io/backend-protocol: "HTTPS"
  name: demo
spec:
  ingressClassName: apig
  rules:
    - host: example.com
      http:
        paths:
          - backend:
              service:
                name: demo-service
                port: 
                  number: 80
            path: /
            pathType: Exact

      Kubernetes 1.19 より前のバージョンを実行するクラスタ

      apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  annotations:
    nginx.ingress.kubernetes.io/backend-protocol: "HTTPS"
  name: demo
spec:
  ingressClassName: apig
  rules:
    - host: example.com
      http:
        paths:
          - path: /test
            backend:
              serviceName: demo-service
              servicePort: 80

    • gRPC を使用して example/test リクエストをバックエンド サービスに転送します。次の方法を使用できます。

      • 方法 1: アノテーションを使用する。設定例:

        Kubernetes 1.19 以降を実行するクラスタ

        apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    nginx.ingress.kubernetes.io/backend-protocol: "GRPC"
  name: demo
spec:
  ingressClassName: apig
  rules:
    - host: example.com
      http:
        paths:
          - backend:
              service:
                name: demo-service
                port: 
                  number: 80
            path: /test
            pathType: Exact

        Kubernetes 1.19 より前のバージョンを実行するクラスタ

        apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  annotations:
    nginx.ingress.kubernetes.io/backend-protocol: "GRPC"
  name: demo
spec:
  ingressClassName: apig
  rules:
    - host: example.com
      http:
        paths:
          - path: /test
            backend:
              serviceName: demo-service
              servicePort: 80

      • 方法 2：サービスポート名を次のように使用してサービスを設定します：

        Kubernetes 1.19 以降を実行するクラスタ

        apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: demo
spec:
  ingressClassName: apig
  rules:
    - host: example.com
      http:
        paths:
          - backend:
              service:
                name: demo-service
                port: 
                  number: 80
            path: /order
            pathType: Exact
---
apiVersion: v1
kind: Service
metadata:
  name: demo-service
spec:
  ports:
    - name: grpc
      port: 80
      protocol: TCP
  selector:
    app: demo-service

        Kubernetes 1.19 より前のバージョンを実行するクラスタ

        apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: demo
spec:
  ingressClassName: apig
  rules:
    - host: example.com
      http:
        paths:
          - path: /test
            backend:
              serviceName: demo-service
              servicePort: 80
---
apiVersion: v1
kind: Service
metadata:
  name: demo-service
spec:
  ports:
    - name: grpc
      port: 80
      protocol: TCP
  selector:
    app: demo-service

    バックエンドサービスの負荷分散アルゴリズム

    負荷分散アルゴリズムは、クラウドネイティブ API Gateway インスタンスがバックエンドサービスにリクエストを転送するときにノードがどのように選択されるかを決定します。

    一般的な負荷分散アルゴリズム

    nginx.ingress.kubernetes.io/load-balance: バックエンドサービスで使用される一般的な負荷分散アルゴリズムを指定します。デフォルト値: round_robin。有効な値:

    • round_robin: ラウンドロビンに基づく負荷分散。

    • least_conn: 最小接続数に基づく負荷分散。

    • random: ランダム化された負荷分散。

    重要

    クラウドネイティブ API Gateway は、指数加重移動平均（EWMA）アルゴリズムをサポートしていません。 EWMA アルゴリズムを構成すると、アルゴリズムはラウンドロビン負荷分散アルゴリズムにロールバックされます。

    たとえば、demo-service バックエンドサービスに最小接続負荷分散アルゴリズムを構成します。構成例:

    Kubernetes 1.19 以降を実行するクラスタ

    apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    nginx.ingress.kubernetes.io/load-balance: "least_conn"
  name: demo
spec:
  ingressClassName: apig
  rules:
    - host: example.com
      http:
        paths:
          - backend:
              service:
                name: demo-service
                port: 
                  number: 80
            path: /order
            pathType: Exact

    Kubernetes 1.19 より前のバージョンを実行するクラスタ

    apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  annotations:
    nginx.ingress.kubernetes.io/load-balance: "least_conn"
  name: demo
spec:
  ingressClassName: apig
  rules:
    - host: example.com
      http:
        paths:
          - path: /test
            backend:
              serviceName: demo-service
              servicePort: 80

    一貫したハッシュに基づく負荷分散アルゴリズム

    一貫したハッシュベースの負荷分散アルゴリズムは、リクエストアフィニティを提供し、同じ特性を持つリクエストが常に同じノードにルーティングされるようにします。 APIG Ingress は、ハッシュキーとして NGINX 変数、リクエストヘッダー、およびリクエストパス パラメーターを使用することをサポートしています。

    nginx.ingress.kubernetes.io/upstream-hash-by: 一貫したハッシュに基づく負荷分散アルゴリズムを指定します。クラウドネイティブ ゲートウェイは、次のタイプの一貫したハッシュをサポートしています。

    • クラウドネイティブ ゲートウェイは、特定の Nginx 変数の構成をサポートしています。

      • $request_uri: リクエストパス。ハッシュキーとして使用されます。パス パラメーターが含まれます。

      • $host: リクエストホスト。ハッシュキーとして使用されます。

      • $remote_addr: クライアント IP アドレス。ハッシュキーとして使用されます。

    • リクエストヘッダーに基づく一貫したハッシュ。 $http_headerName を構成するだけで済みます。

    • リクエストパス パラメーターに基づく一貫したハッシュ。 $arg_varName を構成するだけで済みます。

    例:

    • リクエストのクライアント IP アドレスをハッシュキーとして使用します。クライアント IP アドレスからのリクエストは常に同じノードに配信されます。構成例:

      Kubernetes 1.19 以降を実行するクラスタ

      apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    nginx.ingress.kubernetes.io/upstream-hash-by: "$remote_addr"
  name: demo
spec:
  ingressClassName: apig
  rules:
    - host: example.com
      http:
        paths:
          - backend:
              service:
                name: demo-service
                port: 
                  number: 80
            path: /test
            pathType: Exact

      Kubernetes 1.19 より前のバージョンを実行するクラスタ

      apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  annotations:
    nginx.ingress.kubernetes.io/upstream-hash-by: "$remote_addr"
  name: demo
spec:
  ingressClassName: apig
  rules:
    - host: example.com
      http:
        paths:
          - path: /test
            backend:
              serviceName: demo-service
              servicePort: 80

    • リクエストヘッダー X-Stage をハッシュキーとして使用し、リクエストヘッダー X-Stage の値が同じリクエストを同じノードに配信します。構成例:

      Kubernetes 1.19 以降を実行するクラスタ

      apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    nginx.ingress.kubernetes.io/upstream-hash-by: "$http_x-stage"
  name: demo
spec:
  ingressClassName: apig
  rules:
    - host: example.com
      http:
        paths:
          - backend:
              service:
                name: demo-service
                port: 
                  number: 80
            path: /test
            pathType: Exact

      Kubernetes 1.19 より前のバージョンを実行するクラスタ

      apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  annotations:
    nginx.ingress.kubernetes.io/upstream-hash-by: "$http_x-stage"
  name: demo
spec:
  ingressClassName: apig
  rules:
    - host: example.com
      http:
        paths:
          - path: /test
            backend:
              serviceName: demo-service
              servicePort: 80

    • リクエストパス パラメーター X-Stage をハッシュキーとして使用し、リクエストパス パラメーター X-Stage の値が同じリクエストを同じノードに配信します。構成例:

      Kubernetes 1.19 以降を実行するクラスタ

      apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    nginx.ingress.kubernetes.io/upstream-hash-by: "$arg_x-stage"
  name: demo
spec:
  ingressClassName: apig
  rules:
    - host: example.com
      http:
        paths:
          - backend:
              service:
                name: demo-service
                port: 
                  number: 80
            path: /test
            pathType: Exact

      Kubernetes 1.19 より前のバージョンを実行するクラスタ

      apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  annotations:
    nginx.ingress.kubernetes.io/upstream-hash-by: "$arg_x-stage"
  name: demo
spec:
  ingressClassName: apig
  rules:
    - host: example.com
      http:
        paths:
          - path: /test
            backend:
              serviceName: demo-service
              servicePort: 80

    サービス プリフェッチ（無損失オンライン）

    サービス プリフェッチ機能を使用すると、新しいノードがリリースされたときに、指定されたサービス プリフェッチ ウィンドウでトラフィックを徐々に増加させることができます。これにより、ノードが完全にプリフェッチされます。

    higress.ingress.kubernetes.io/warmup: サービスがプリフェッチされる期間を指定します。単位：秒。 デフォルトでは、サービス プリフェッチ機能は有効になっていません。

    説明

    サービス プリフェッチは、選択した負荷分散アルゴリズムによって異なります。 ラウンドロビンと最小接続数に基づく負荷分散アルゴリズムのみがサポートされています。

    たとえば、バックエンド サービス demo-service のサービス プリフェッチ機能を有効にし、プリフェッチ タイム ウィンドウを 30 秒に設定します。設定例：

    Kubernetes 1.19 以降を実行するクラスタ

    apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    higress.ingress.kubernetes.io/warmup: "30"
  name: demo
spec:
  ingressClassName: apig
  rules:
    - host: example.com
      http:
        paths:
          - backend:
              service:
                name: demo-service
                port: 
                  number: 80
            path: /test
            pathType: Exact

    Kubernetes 1.19 より前のバージョンを実行するクラスタ

    apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  annotations:
    higress.ingress.kubernetes.io/warmup: "30"
  name: demo
spec:
  ingressClassName: apig
  rules:
    - host: example.com
      http:
        paths:
          - path: /test
            backend:
              serviceName: demo-service
              servicePort: 80

    Cookie アフィニティ（セッション維持）

    ゲートウェイは、常に同じ Cookie を持つリクエストを同じノードにルーティングします。クライアントの最初のリクエストにアフィニティ Cookie がない場合、APIG Ingress は応答で Cookie を生成します。これにより、そのクライアントからの後続のリクエストは常に同じノードにルーティングされます。

    アノテーション

    説明

    nginx.ingress.kubernetes.io/affinity

    アフィニティのタイプを指定します。デフォルトおよび唯一の有効な値は cookie です。

    nginx.ingress.kubernetes.io/affinity-mode

    アフィニティモードを指定します。デフォルトおよび唯一の有効な値は balanced です。

    nginx.ingress.kubernetes.io/session-cookie-name

    ハッシュキーとして使用される Cookie の名前を指定します。デフォルト値：INGRESSCOOKIE。

    nginx.ingress.kubernetes.io/session-cookie-path

    指定された Cookie が存在しない場合に生成される Cookie のパスを指定します。デフォルト値：/。

    nginx.ingress.kubernetes.io/session-cookie-max-age

    指定された Cookie が存在しない場合に生成される Cookie の有効期限を指定します。単位：秒。デフォルトでは、このアノテーションはセッションレベルで指定されます。

    nginx.ingress.kubernetes.io/session-cookie-expires

    指定された Cookie が存在しない場合に生成される Cookie の有効期限を指定します。単位：秒。デフォルトでは、このアノテーションはセッションレベルで指定されます。

    例：

    • デフォルトの APIG Ingress 構成で Cookie アフィニティを有効にするには、次のサンプルコードを使用します。デフォルトの Cookie 名は `INGRESSCOOKIE`、パスは `/`、Cookie のライフサイクルはセッションレベルです。

      Kubernetes 1.19 以降を実行するクラスタ

      apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    nginx.ingress.kubernetes.io/affinity: "cookie"
  name: demo
spec:
  ingressClassName: apig
  rules:
    - host: example.com
      http:
        paths:
          - backend:
              service:
                name: demo-service
                port: 
                  number: 80
            path: /test
            pathType: Exact

      Kubernetes 1.19 より前のバージョンを実行するクラスタ

      apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  annotations:
    nginx.ingress.kubernetes.io/affinity: "cookie"
  name: demo
spec:
  ingressClassName: apig
  rules:
    - host: example.com
      http:
        paths:
          - path: /test
            backend:
              serviceName: demo-service
              servicePort: 80

    • Cookie アフィニティを有効にし、Cookie 名を test、パスを /、Cookie の有効期限を 10 秒に設定します。設定例：

      Kubernetes 1.19 以降を実行するクラスタ

      apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    nginx.ingress.kubernetes.io/affinity: "cookie"
    nginx.ingress.kubernetes.io/session-cookie-name: "test"
    nginx.ingress.kubernetes.io/session-cookie-max-age: "10"
  name: demo
spec:
  ingressClassName: apig
  rules:
    - host: example.com
      http:
        paths:
          - backend:
              service:
                name: demo-service
                port: 
                  number: 80
            path: /test
            pathType: Exact

      Kubernetes 1.19 より前のバージョンを実行するクラスタ

      apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  annotations:
    nginx.ingress.kubernetes.io/affinity: "cookie"
    nginx.ingress.kubernetes.io/session-cookie-name: "test"
    nginx.ingress.kubernetes.io/session-cookie-max-age: "10"
  name: demo
spec:
  ingressClassName: apig
  rules:
    - host: example.com
      http:
        paths:
          - path: /test
            backend:
              serviceName: demo-service
              servicePort: 80

    クラウドネイティブ API Gateway インスタンスとバックエンドサービス間の接続プールの設定

    クラウドネイティブ API Gateway インスタンスで指定されたバックエンドサービスの接続プールを設定すると、クラウドネイティブ API Gateway インスタンスとバックエンドサービス間の接続数を制御できます。 これにより、バックエンドサービスの過負荷を防ぎ、バックエンドサービスの安定性と高可用性を確保できます。

    • higress.ingress.kubernetes.io/connection-policy-tcp-max-connection: クラウドネイティブ API Gateway インスタンスとバックエンドサービス間で確立できる最大接続数。

    • higress.ingress.kubernetes.io/connection-policy-tcp-max-connection-per-endpoint: クラウドネイティブ API Gateway インスタンスとバックエンドサービスのシングルノード間で確立できる最大接続数。

    • higress.ingress.kubernetes.io/connection-policy-http-max-request-per-connection: クラウドネイティブ API Gateway インスタンスとバックエンドサービス間の単一接続での最大リクエスト数。

    たとえば、バックエンドサービス demo-service の場合、クラウドネイティブ API Gateway インスタンスとバックエンドサービス間で確立できる最大接続数を 10 に設定し、クラウドネイティブ API Gateway インスタンスとバックエンドサービスのシングルノード間で確立できる最大接続数を 2 に設定できます。

    Kubernetes 1.19 以降を実行するクラスタ

    apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    higress.ingress.kubernetes.io/connection-policy-tcp-max-connection: "10"
    higress.ingress.kubernetes.io/connection-policy-tcp-max-connection-per-endpoint: "2"
  name: demo
spec:
  ingressClassName: apig
  rules:
    - host: example.com
      http:
        paths:
          - backend:
              service:
                name: demo-service
                port: 
                  number: 80
            path: /test
            pathType: Exact

    Kubernetes 1.19 より前のバージョンを実行するクラスタ

    apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  annotations:
    higress.ingress.kubernetes.io/connection-policy-tcp-max-connection: "10"
    higress.ingress.kubernetes.io/connection-policy-tcp-max-connection-per-endpoint: "2"
  name: demo
spec:
  ingressClassName: apig
  rules:
    - host: example.com
      http:
        paths:
          - path: /test
            backend:
              serviceName: demo-service
              servicePort: 80

    クライアントと Cloud-native API Gateway インスタンス間の通信の TLS バージョンと暗号スイート

    デフォルトでは、APIG Ingress は 1.0 から 1.3 までの TLS バージョンをサポートしています。デフォルトの暗号スイートは次のとおりです。

    • ECDHE-ECDSA-AES128-GCM-SHA256

    • ECDHE-RSA-AES128-GCM-SHA256

    • ECDHE-ECDSA-AES128-SHA

    • ECDHE-RSA-AES128-SHA

    • AES128-GCM-SHA256

    • AES128-SHA

    • ECDHE-ECDSA-AES256-GCM-SHA384

    • ECDHE-RSA-AES256-GCM-SHA384

    • ECDHE-ECDSA-AES256-SHA

    • ECDHE-RSA-AES256-SHA

    • AES256-GCM-SHA384

    • AES256-SHA

    次の表は、特定のドメイン名に対して最も早い、または最新の TLS バージョンと暗号スイートを指定するために使用できるアノテーションを示しています。

    アノテーション

    説明

    higress.ingress.kubernetes.io/tls-min-protocol-version

    TLS の最小バージョンを指定します。デフォルト値：TLSv1.0。有効値：

    • TLSv1.0

    • TLSv1.1

    • TLSv1.2

    • TLSv1.3

    higress.ingress.kubernetes.io/tls-max-protocol-version

    TLS の最新バージョンを指定します。デフォルト値：TLSv1.3。

    nginx.ingress.kubernetes.io/ssl-cipher

    TLS 暗号スイートを指定します。複数の TLS 暗号スイートを指定できます。カンマ (,) で区切ります。このアノテーションは、v1.0 から v1.2 までの TLS バージョンが TLS ハンドシェイクに使用される場合にのみ有効になります。

    たとえば、ドメイン名 example.com が使用可能です。このドメイン名の場合、最も早い TLS バージョンを TLSv1.2 に設定し、最新バージョンを TLSv1.2 に設定します。設定例：

    Kubernetes 1.19 以降を実行するクラスタ

    apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    higress.ingress.kubernetes.io/tls-min-protocol-version: "TLSv1.2"
    higress.ingress.kubernetes.io/tls-max-protocol-version: "TLSv1.2"
  name: demo
spec:
  ingressClassName: apig
  rules:
    - host: example.com
      http:
        paths:
          - backend:
              service:
                name: demo-service
                port: 
                  number: 80
            path: /test
            pathType: Exact

    Kubernetes 1.19 より前のバージョンを実行するクラスタ

    apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  annotations:
    higress.ingress.kubernetes.io/tls-min-protocol-version: "TLSv1.2"
    higress.ingress.kubernetes.io/tls-max-protocol-version: "TLSv1.2"
  name: demo
spec:
  ingressClassName: apig
  rules:
    - host: example.com
      http:
        paths:
          - path: /test
            backend:
              serviceName: demo-service
              servicePort: 80

    Cloud-native API Gateway インスタンスとバックエンド サービス間の mTLS 認証

    デフォルトでは、APIG Ingress は HTTP を使用してリクエストをバックエンド アプリケーション コンテナーに転送します。アノテーション nginx.ingress.kubernetes.io/backend-protocol: "HTTPS" を使用して、HTTPS 経由でバックエンド サービスにアクセスするように APIG Ingress を構成できます。これは一方向 TLS であり、APIG Ingress のみがバックエンド サービスによって提供された証明書を検証します。バックエンド サービス証明書は、通常、信頼できる認証局（CA）によって発行される必要があります。より安全なゼロトラスト モデルを実現するために、相互 TLS（mTLS）を使用できます。 mTLS を使用すると、ゲートウェイとバックエンド サービスは相互認証を実行します。ゲートウェイはバックエンド サービスの証明書を検証し、バックエンド サービスはゲートウェイの証明書を検証します。

    アノテーション

    説明

    nginx.ingress.kubernetes.io/proxy-ssl-secret

    Cloud-native API Gateway インスタンスによって使用されるクライアント証明書を指定します。クライアント証明書は、バックエンド サービスが Cloud-native API Gateway インスタンスを認証するために使用されます。フォーマットは secretNamespace/secretName です。

    nginx.ingress.kubernetes.io/proxy-ssl-name

    TLS ハンドシェイク中に使用されるサーバ名表示（SNI）を指定します。

    nginx.ingress.kubernetes.io/proxy-ssl-server-name

    TLS ハンドシェイク中に使用される SNI を有効にするか無効にするかを指定します。

    たとえば、Cloud-native API Gateway インスタンスとバックエンド サービス間で mTLS を実行し、secretName を gateway-cert に設定し、secretNamespace を default に設定します。設定例：

    Kubernetes 1.19 以降を実行するクラスタ

    apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    nginx.ingress.kubernetes.io/proxy-ssl-secret: "default/gateway-cert"
  name: demo
spec:
  ingressClassName: apig
  rules:
    - host: example.com
      http:
        paths:
          - backend:
              service:
                name: demo-service
                port: 
                  number: 80
            path: /test
            pathType: Exact

    Kubernetes 1.19 より前のバージョンを実行するクラスタ

    apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  annotations:
    nginx.ingress.kubernetes.io/proxy-ssl-secret: "default/gateway-cert"
  name: demo
spec:
  ingressClassName: apig
  rules:
    - host: example.com
      http:
        paths:
          - path: /test
            backend:
              serviceName: demo-service
              servicePort: 80