すべてのプロダクト
Search
ドキュメントセンター

API Gateway:高度な APIG Ingress の使用方法

最終更新日:Mar 04, 2026

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

カナリーリリース

APIG Ingress は、リクエストヘッダー、クエリパラメーター、Cookie、および重みに基づくカナリーリリースを含む高度なルーティングをサポートします。カナリーリリースはアノテーションで設定します。カナリーリリースを有効化するには、アノテーション nginx.ingress.kubernetes.io/canary: "true" を設定します。異なるアノテーションにより、異なるカナリーリリース機能が有効化されます。

説明

複数のカナリーメソッドを設定した場合、優先順位は「ヘッダーまたはクエリパラメーターによる方式」→「Cookie による方式」→「重みによる方式」の順となります。

ヘッダーによるカナリーリリース

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

  • nginx.ingress.kubernetes.io/canary-by-header-valuenginx.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 の両方を設定する場合

    リクエストの query parameter key および query parameter value が設定値と一致する場合のみ、トラフィックはカナリーサービスにルーティングされます。それ以外の場合、トラフィックは安定版サービスにルーティングされます。

    説明

    ヘッダーによるカナリーリリースとクエリパラメーターによるカナリーリリースを併用できます。両方の条件が満たされた場合にのみ、トラフィックはカナリーサービスにルーティングされます。

例:

  • リクエスト 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 にリクエストを転送することを意味します。この設定は以下の 2 通りの方法で行えます:

APIG Ingress で定義された Pod ラベルを使用する

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

  • "" または base として設定した場合、opensergo.io/canary: "" のラベルを持つ Pod、または opensergo.io/canary で始まるキープレフィックスを持つラベルを持たない Pod にリクエストが転送されます。これには空のラベルやラベルがない Pod も含まれます。

  • その他の値で設定した場合、gray などと設定すると、opensergo.io/canary-gray: gray のラベルを持つ Pod にリクエストが転送されます。

例として、Kubernetes Service の名前が `go-httpbin` であり、2 つの Deployment に関連付けられているとします。1 つ目の Deployment は、opensergo.io/canary で始まるキープレフィックスを持つラベルを持たない Pod を管理します。2 つ目の Deployment は、opensergo.io/canary-gray: gray のカナリーラベルを持つ Pod を管理します。以下のように設定します:

# 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

リクエストヘッダーに x-user-id: test が含まれる場合に go-httpbin-gray に、それ以外の場合に go-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:
              # Service を 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:
              # Service を go-httpbin として設定し、アノテーションでバージョンを指定
              serviceName: go-httpbin
              servicePort: 8080

カスタムラベルを使用する

サービスサブセットの Pod をカスタムラベルで定義するには、higress.ingress.kubernetes.io/service-subset および higress.ingress.kubernetes.io/subset-labels の両方のアノテーションを設定します。

説明

このサブセットは、opensergo.io/canary で始まるラベルとは関連付けられません。

例として、Kubernetes Service の名前が go-httpbin であり、2 つの Deployment に関連付けられているとします。1 つ目の Deployment は、opensergo.io/canary で始まるキープレフィックスを持つラベルを持たない Pod を管理します。2 つ目の Deployment は、version: gray のカナリーラベルを持つ Pod を管理します。以下のように設定します:

# 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

リクエストヘッダーに x-user-id: test が含まれる場合に go-httpbin-gray に、それ以外の場合に go-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:
              # Service を 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:
              # Service を go-httpbin として設定し、アノテーションでバージョンを指定
              serviceName: go-httpbin
              servicePort: 8080

クロスドメイン

クロスオリジンリソース共有(CORS)により、Web アプリケーションサーバはクロスドメインアクセスを制御し、ドメイン間での安全なデータ転送を確保できます。詳細については、「クロスオリジンリソース共有(CORS)」をご参照ください。

アノテーション

説明

nginx.ingress.kubernetes.io/enable-cors

CORS を有効化または無効化します。

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

リソースへのアクセスを許可するオリジンを指定します。複数のオリジンをカンマで区切って指定できます。ワイルドカード文字 (*) を使用できます。デフォルト値は * であり、すべてのオリジンを許可します。

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

ブラウザがリクエストとともに資格情報を送信できるかどうかを指定します。デフォルト値は true です。

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

プリフライトリクエストの結果をキャッシュできる最大時間(秒)を指定します。デフォルト値は 1728000 です。

例として、クロスドメインリクエストを example.com ドメインに制限し、GET および POST メソッドのみを許可し、X-Foo-Bar リクエストヘッダーを許可し、資格情報の送信を禁止するには、以下の構成を使用します:

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 では正規表現によるマッチも追加でサポートしています。Ingress スペックで定義されたパスに対して正規表現マッチを有効化するには、アノテーション nginx.ingress.kubernetes.io/use-regex: true を追加します。

例として、ドメイン名が 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/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. /v1/ で始まるプレフィックスを持つリクエスト(例: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. /v1/ で始まるプレフィックスを持つリクエスト(例: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 をバックエンドサービスに転送する前に、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 にリダイレクトするには、以下のように設定します:

バージョン 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

バージョン 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 を指定します。スキーム(HTTP または HTTPS)を含める必要があります。

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

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

例として、http://example.com/test を http://example.com/app に恒久的にリダイレクトするには、以下のように設定します:

バージョン 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

バージョン 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 を指定します。スキーム(HTTP または HTTPS)を含める必要があります。

例として、http://example.com/test を http://example.com/app に一時的にリダイレクトするには、以下のように設定します:

バージョン 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

バージョン 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

ヘッダー制御

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

リクエストヘッダー制御

アノテーション

説明

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 に対するリクエストに、2 つのヘッダー(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 ステータスコードに対する再試行を指定します(例:http_502、http_403)。

  • non_idempotent:非等冪リクエストの失敗時に再試行を有効化します。デフォルトでは、APIG Ingress は失敗した非等冪の POST や PATCH リクエストを再試行しません。non_idempotent を設定すると、再試行が有効になります。

  • off:再試行を無効化します。

例として、example/test リクエストの最大再試行回数を 2 回、再試行タイムアウトを 5 秒、HTTP ステータスコード 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 アドレスまたは Classless Inter-Domain Routing (CIDR) ブロックをサポートします。複数のエントリをカンマで区切ります。

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

ルートの IP ブラックリストを指定します。IP アドレスまたは CIDR ブロックをサポートします。複数のエントリをカンマで区切ります。

例:

  • クライアント IP アドレス 1.1.X.X のみからの example.com/test へのアクセスを許可するには、以下の構成を使用します:

    バージョン 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

    バージョン 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.2.2 からの example.com/test へのアクセスを拒否するには、以下の構成を使用します:

    バージョン 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

    バージョン 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 アドレスまたは CIDR ブロックをサポートします。IP アドレスをカンマで区切ります。

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

ドメイン名の IP ブラックリストを指定します。ドメインレベルの設定は、ルートレベルの設定よりも優先度が低くなります。IP アドレスまたは CIDR ブロックをサポートします。IP アドレスをカンマで区切ります。

例:

  • example.com ドメイン名のすべてのルートへのアクセスを、クライアント IP アドレス 1.1.X.X および 2.2.2.2 のみから許可するには、以下の構成を使用します:

    バージョン 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

    バージョン 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 アドレス 1.1.X.X および 2.2.2.2 からの example.com ドメインのすべてのルートへのアクセスを許可し、クライアント IP アドレス 3.3.X.X からのみ example.com/order ルートへのアクセスを許可するには、以下の構成を使用します:

    バージョン 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

    バージョン 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 は、ルーティングレベルでのインスタンス単位のレート制限をサポートします。指定された期間内に、各ゲートウェイレプリカ上で指定されたルートに一致するリクエスト数を、設定されたしきい値を超えないように制限します。

説明

このレート制限はインスタンス単位で適用されます。設定されたしきい値は、各ゲートウェイインスタンスで個別に適用されます。ゲートウェイクラスター全体でルートのトラフィックを制限するには、グローバルレート制限を使用してください。

アノテーション

説明

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

各ゲートウェイインスタンスにおけるこのルートの 1 分あたりの最大リクエスト数を指定します。最大バーストリクエスト数は、この値に limit-burst-multiplier を乗算した値となります。

レート制限がトリガーされた場合、レスポンス本文には local_rate_limited が含まれます。レスポンスステータスコードはゲートウェイのバージョンによって異なります:

  • ゲートウェイバージョンが 1.2.23 より前の場合:ステータスコード 503。

  • ゲートウェイバージョンが 1.2.23 以降の場合:ステータスコード 429。

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

各ゲートウェイインスタンスにおけるこのルートの 1 秒あたりの最大リクエスト数を指定します。最大バーストリクエスト数は、この値に limit-burst-multiplier を乗算した値となります。

レート制限がトリガーされた場合、レスポンス本文には local_rate_limited が含まれ、レスポンスステータスコードは以下のとおりです:

  • ゲートウェイバージョンが 1.2.23 より前の場合:ステータスコード 503。

  • ゲートウェイバージョンが 1.2.23 以降の場合:ステータスコード 429。

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

最大バーストリクエスト数のバースト乗数を指定します。デフォルト値は 5 です。

例:

  • example.com/test へのリクエストを 1 分あたり 100 件に制限し、バースト容量を 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 へのリクエストを 1 秒あたり 10 件に制限し、バースト容量を 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 秒あたりの最大リクエスト数をクラスター全体で制限できます。

説明

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

higress.ingress.kubernetes.io/rate-limit アノテーションを使用して、ゲートウェイクラスター全体でルートの 1 秒あたりの最大リクエスト数を設定できます。レート制限がトリガーされた場合、デフォルトの動作は、ステータスコード 429 およびレスポンス本文「sentinel rate limited」を含むレスポンスを返すことです。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:以下の構成は、ゲートウェイクラスター全体で example.com/test へのリクエストを 1 秒あたり 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:以下の構成は、ゲートウェイクラスター全体で example.com/test へのリクエストを 1 秒あたり 100 件に制限します。レート制限がトリガーされた場合、ゲートウェイはステータスコード 503 と「server is overloaded」というレスポンス本文を返します。

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:以下の構成は、ゲートウェイクラスター全体で example.com/test へのリクエストを 1 秒あたり 100 件に制限します。レート制限がトリガーされた場合、リクエストは 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: 同時実行制御がトリガーされたときに返される HTTP ステータスコード。デフォルトは 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 への同時リクエストの最大数を 1000 に制限します。同時実行制御がトリガーされたときに、状態コード 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。

ゲートウェイクラスター全体で example.com/test への同時リクエストの最大数を 1000 に制限します。同時実行制御がトリガーされたときに、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:トラフィックを指定されたミラーサービスにコピーします。サービスのフォーマットは 名前空間/サービス名:ポート です。

    • 名前空間:Kubernetes サービスが存在する名前空間です。省略可能で、デフォルト値は Ingress が存在する名前空間です。

    • サービス名:Kubernetes サービスの名前です。必須項目です。

    • ポート:Kubernetes サービスへトラフィックを転送する際のポート番号です。省略可能で、デフォルト値は最初に定義されたポートです。

  • higress.ingress.kubernetes.io/mirror-percentage:コピー対象とするトラフィックの割合(%)です。設定可能な範囲は 0 ~ 100 です。デフォルト値は 100 です。

説明

コピーされたトラフィックがターゲットサービスに転送される際、元のリクエストの Host ヘッダーには自動的に -shadow サフィックスが追加されます。

たとえば、example.com/test からのトラフィックを、名前空間が test、サービス名が app、ポートが 8080 のターゲットサービスにコピー・転送する場合を示します。

説明

この例では、コピーされたトラフィックがターゲットサービスに転送される際に、Host は自動的に example.com-shadow に書き換えられます。

バージョン 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

バージョン 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 に書き換えられます。

バージョン 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

バージョン 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" を追加します。アプリケーションコンテナーが gRPC サービスを提供する場合は、リクエストをバックエンドアプリケーションコンテナーに転送するために、アノテーション nginx.ingress.kubernetes.io/backend-protocol: "GRPC" を追加します。

説明

NGINX Ingress とは異なり、APIG Ingress では、バックエンドサービスの Kubernetes Service リソースにおけるポート名(Port Name)が grpc または http2 として定義されている場合、自動的に gRPC または HTTP/2 を使用します。この場合、アノテーション nginx.ingress.kubernetes.io/backend-protocol: "GRPC" の設定は不要です。

例:

  • リクエスト example/test を HTTPS プロトコルでバックエンドサービスに転送します。以下の構成を使用します:

    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
  • リクエスト example/test を gRPC プロトコルでバックエンドサービスに転送します。以下のいずれかの方法をご利用ください:

    • 方法 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:Service のポート名(Port Name)を使用する場合。以下のように構成します:

      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

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

負荷分散は、ゲートウェイがバックエンドサービスにリクエストを転送する際に、ノードを選択する方法を決定します。

標準の負荷分散アルゴリズム

nginx.ingress.kubernetes.io/load-balance: バックエンドサービスの標準の負荷分散アルゴリズムです。デフォルト値は round_robin です。有効な値は次のとおりです:

  • round_robin: ラウンドロビン負荷分散。

  • least_conn: 最小接続負荷分散。

  • random: ランダム負荷分散。

重要

クラウドネイティブゲートウェイは EWMA アルゴリズムをサポートしていません。EWMA を設定した場合、ゲートウェイはラウンドロビンにフォールバックします。

たとえば、バックエンドサービス demo-service の負荷分散アルゴリズムを least_conn に設定します。次のように設定します:

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:サービスのラップアップ期間(単位:秒)。デフォルトでは無効です。

説明

サービスのウォームアップは、選択されたロードバランシングアルゴリズムに依存します。現在、ラウンドロビンおよび least_conn のみがサポートされています。

たとえば、バックエンドサービス 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

クッキーアフィニティ (セッション維持)

ゲートウェイによって、同じクッキーを持つリクエストは常に同じノードにルーティングされます。最初のリクエストにクッキーが含まれている場合、APIG Ingress は最初の応答でクッキーを生成します。このクッキーにより、後続のリクエストは常に同じノードにルーティングされることが保証されます。

アノテーション

説明

nginx.ingress.kubernetes.io/affinity

アフィニティのタイプ。サポートされているのはクッキーアフィニティのみです。デフォルト値は `cookie` です。

nginx.ingress.kubernetes.io/affinity-mode

アフィニティのモード。クラウドネイティブゲートウェイでは `Balanced` モードのみがサポートされます。デフォルト値は `Balanced` です。

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

指定したクッキーの値をハッシュキーとして設定します。デフォルトは `INGRESSCOOKIE` です。

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

指定したクッキーが存在しない場合に生成されるクッキーのパス値です。デフォルト値は `/` です。

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

指定したクッキーが存在しない場合に生成されるクッキーの最大有効期間 (秒) です。デフォルト値はセッションレベルです。

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

指定したクッキーが存在しない場合に生成されるクッキーの有効期限 (秒) です。デフォルト値はセッションレベルです。

例:

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

    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
  • クッキー名を test、クッキーパスを /、クッキーの有効期限を 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

ゲートウェイとバックエンドサービス間の接続プール構成

ゲートウェイ上の特定サービスについて、接続プールを構成します。この設定は、ゲートウェイとバックエンドサービス間の接続数を制御します。これにより、バックエンドサービスの過負荷を防止し、バックエンドサービスの安定性および高可用性を向上させます。

  • higress.ingress.kubernetes.io/connection-policy-tcp-max-connection:ゲートウェイとバックエンドサービス間で確立可能な最大接続数です。

  • higress.ingress.kubernetes.io/connection-policy-tcp-max-connection-per-endpoint:ゲートウェイとバックエンドサービスのシングルノード(1 つのエンドポイント)間で確立可能な最大接続数です。

  • higress.ingress.kubernetes.io/connection-policy-http-max-request-per-connection:ゲートウェイとバックエンドサービス間の単一接続上で許容される最大リクエスト数です。

たとえば、demo-service バックエンドサービスの構成では、ゲートウェイとバックエンドサービス間で確立可能な最大接続数は 10、またゲートウェイとバックエンドサービスの各シングルノード間で確立可能な最大接続数は 2 となります。

バージョン 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

バージョン 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

クライアントとゲートウェイ間の TLS バージョンと暗号スイートの構成

デフォルトでは、APIG Ingress は最小の Transport Layer Security (TLS) バージョンを TLSv1.0 に、最大の TLS バージョンを TLSv1.3 に設定します。デフォルトの暗号スイートは次のとおりです:

  • 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 バージョン 1.0 から 1.2 を使用する TLS ハンドシェイクにのみ適用されます。

たとえば、ドメイン名 example.com の場合、最小および最大の TLS バージョンを TLSv1.2 に設定します。構成は次のとおりです:

バージョン 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

バージョン 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

ゲートウェイとバックエンドサービスの相互 TLS (mTLS)

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

アノテーション

説明

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

バックエンド サービス による 身分認証 のために ゲートウェイ が使用する クライアント 証明書 。形式: secretNamespace/secretName。

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

TLS ハンドシェイク 中に使用される サーバ名表示 (SNI)。

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

TLS ハンドシェイク 中の SNI を 有効 または 無効 にします。

例えば、ゲートウェイ と バックエンド サービス 間で 相互 TLS (mTLS) を 有効 にするには、デフォルト の 名前空間 にある gateway-cert という名前の シークレット を使用します。次のように設定します。

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

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    nginx.ingress.kubernetes.io/proxy-ssl-secret: "default/ateway-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