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

Container Compute Service:ALB Ingress の高度な設定

最終更新日:Nov 09, 2025

Application Load Balancer (ALB) Ingress は、Kubernetes クラスター内のサービスへの外部アクセスを管理するためのレイヤー 7 の負荷分散を提供する API オブジェクトです。 このトピックでは、Alibaba Cloud Container Compute Service (ACS) クラスターで ALB Ingress を使用して、ドメイン名と URL パスに基づいてバックエンドサーバーグループにリクエストを転送し、HTTP リクエストを HTTPS にリダイレクトし、カナリアリリースを実装する方法について説明します。

前提条件

  • ACS クラスターが作成されていること。 詳細については、「ACS クラスターの作成」をご参照ください。

  • AlbConfig オブジェクトが作成されていること。 詳細については、「ALB Ingress の概要」をご参照ください。

ドメイン名に基づくリクエストの転送

次の手順を実行して、ドメイン名を持つ Ingress とドメイン名のない Ingress を作成し、それらの Ingress を使用してリクエストを転送します。

通常のドメインに基づくリクエストの転送

  1. 次のテンプレートを使用して、Deployment、Service、および Ingress を作成します。 Ingress のドメイン名へのリクエストは Service に転送されます。

    apiVersion: v1
    kind: Service
    metadata:
      name: demo-service
      namespace: default
    spec:
      ports:
        - name: port1
          port: 80
          protocol: TCP
          targetPort: 8080
      selector:
        app: demo
      sessionAffinity: None
      type: ClusterIP
    ---
    apiVersion: apps/v1
    kind: Deployment
    metadata:
      name: demo
      namespace: default
    spec:
      replicas: 1
      selector:
        matchLabels:
          app: demo
      template:
        metadata:
          labels:
            app: demo
        spec:
          containers:
            - image: registry.cn-hangzhou.aliyuncs.com/alb-sample/cafe:v1
              imagePullPolicy: IfNotPresent
              name: demo
              ports:
                - containerPort: 8080
                  protocol: TCP
    ---
    apiVersion: networking.k8s.io/v1
    kind: Ingress
    metadata:
      name: demo
      namespace: default
    spec:
      ingressClassName: alb
      rules:
        - host: demo.domain.ingress.top
          http:
            paths:
              - backend:
                  service:
                    name: demo-service
                    port: 
                      number: 80
                path: /hello
                pathType: ImplementationSpecific
  2. 次のコマンドを実行して、指定されたドメイン名を使用してアプリケーションにアクセスします。

    [ADDRESS] を ALB インスタンスのドメイン名に置き換えます。これは kubectl get ing コマンドを実行して取得できます。

    curl -H "host: demo.domain.ingress.top" <ADDRESS>/hello

    期待される出力:

    {"hello":"coffee"}

ドメイン名なしの Ingress の作成

  1. 次のテンプレートは、Ingress の構成を示しています。

    apiVersion: networking.k8s.io/v1
    kind: Ingress
    metadata:
      name: demo
      namespace: default
    spec:
      ingressClassName: alb
      rules:
        - host: ""
          http:
            paths:
              - backend:
                  service:
                    name: demo-service
                    port: 
                      number: 80
                path: /hello
  2. 次のコマンドを実行して、ドメイン名を使用してアプリケーションにアクセスします。

    [ADDRESS] を ALB インスタンスのドメイン名に置き換えます。 このドメイン名は、kubectl get ing コマンドを実行して取得できます。

    curl <ADDRESS>/hello

    期待される出力:

    {"hello":"coffee"}

URL パスに基づくリクエストの転送

ALB Ingress は、URL パスに基づいてリクエストを転送できます。 pathType フィールドを設定して、URL 一致ポリシーを指定できます。 pathType は、ExactImplementationSpecific (デフォルト)、および Prefix の 3 つの一致タイプをサポートしています。

説明

URL 一致ポリシーは互いに競合する可能性があります。 競合する URL 一致ポリシーが存在する場合、リクエストはポリシーの優先度の降順でこれらのポリシーと照合されます。 詳細については、「転送ルールの優先度の設定」をご参照ください。

一致モード

ルール

URL パス

URL パスがルールに一致するかどうか

プレフィックス

/

(すべてのパス)

はい

プレフィックス

/foo

  • /foo

  • /foo/

はい

プレフィックス

/foo/

  • /foo

  • /foo/

はい

プレフィックス

/aaa/bb

/aaa/bbb

いいえ

プレフィックス

/aaa/bbb

/aaa/bbb

はい

プレフィックス

/aaa/bbb/

/aaa/bbb

はい。 URL パスは、ルールの末尾のスラッシュ (/) を無視します。

プレフィックス

/aaa/bbb

/aaa/bbb/

はい。 ルールは、URL パスの末尾のスラッシュ (/) に一致します。

プレフィックス

/aaa/bbb

/aaa/bbb/ccc

はい。 ルールは、URL パスのサブパスに一致します。

プレフィックス

同時に 2 つのルールを設定します:

  • /

  • /aaa

/aaa/ccc

はい。 リクエストパスは、ルールパスの / プレフィックスに一致します。

プレフィックス

同時に 2 つのルールを設定します:

  • /aaa

  • /

/aaa/ccc

はい。 リクエストパスは、ルールパスの /aaa プレフィックスに一致します。

プレフィックス

同時に 2 つのルールを設定します:

  • /aaa

  • /

/ccc

はい。 リクエストパスは、ルールパスの / プレフィックスに一致します。

プレフィックス

/aaa

/ccc

いいえ

Exact または ImplementationSpecific

/foo

/foo

はい

Exact または ImplementationSpecific

/foo

/bar

いいえ

Exact または ImplementationSpecific

/foo

/foo/

いいえ

Exact または ImplementationSpecific

/foo/

/foo

いいえ

3 つの一致方法の例を次に示します。

Exact

  1. 次のテンプレートは、Ingress の構成を示しています。

    apiVersion: networking.k8s.io/v1
    kind: Ingress
    metadata:
      name: demo-path
      namespace: default
    spec:
      ingressClassName: alb
      rules:
        - http:
            paths:
            - path: /hello
              backend:
                service:
                  name: demo-service
                  port: 
                    number: 80
              pathType: Exact
  2. 次のコマンドを実行して、アプリケーションにアクセスします。

    [ADDRESS] を ALB インスタンスのドメイン名に置き換えます。 ドメイン名は kubectl get ing コマンドを実行して取得できます。

    curl <ADDRESS>/hello

    期待される出力:

    {"hello":"coffee"}

ImplementationSpecific: デフォルトの一致ポリシー

ALB Ingress では、このポリシーは Exact ポリシーと同じ方法で処理されます。

  1. 次のテンプレートは、Ingress の構成を示しています。

    apiVersion: networking.k8s.io/v1
    kind: Ingress
    metadata:
      name: demo-path
      namespace: default
    spec:
      ingressClassName: alb
      rules:
        - http:
            paths:
            - path: /hello
              backend:
                service:
                  name: demo-service
                  port:
                    number: 80
              pathType: ImplementationSpecific
  2. 次のコマンドを実行して、アプリケーションにアクセスします。

    [ADDRESS] を ALB インスタンスのドメイン名に置き換えます。これは kubectl get ing コマンドを実行して取得できます。

    curl <ADDRESS>/hello

    期待される出力:

    {"hello":"coffee"}

Prefix

このポリシーは、/ で区切られた URL パス要素に対して、大文字と小文字を区別するプレフィックスマッチを実行します。

  1. 次のテンプレートは、Ingress の構成を示しています。

    apiVersion: networking.k8s.io/v1
    kind: Ingress
    metadata:
      name: demo-path-prefix
      namespace: default
    spec:
      ingressClassName: alb
      rules:
        - http:
            paths:
            - path: /
              backend:
                service:
                  name: demo-service
                  port:
                    number: 80
              pathType: Prefix
  2. 次のコマンドを実行して、アプリケーションにアクセスします。

    [ADDRESS] を ALB インスタンスのドメイン名に置き換えます。これは kubectl get ing コマンドを実行して取得できます。

    curl <ADDRESS>/hello

    期待される出力:

    {"hello":"coffee"}

ヘルスチェックの設定

次のアノテーションを使用して、ALB Ingress のヘルスチェックを設定できます。 次の YAML テンプレートは、ヘルスチェックが有効になっている Ingress を作成する方法の例を示しています。

次の YAML テンプレートは、ヘルスチェックが有効になっている Ingress を作成する方法の例を示しています。

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: cafe-ingress
  annotations:
    alb.ingress.kubernetes.io/healthcheck-enabled: "true"
    alb.ingress.kubernetes.io/healthcheck-path: "/"
    alb.ingress.kubernetes.io/healthcheck-protocol: "HTTP"
    alb.ingress.kubernetes.io/healthcheck-method: "HEAD"
    alb.ingress.kubernetes.io/healthcheck-httpcode: "http_2xx"
    alb.ingress.kubernetes.io/healthcheck-timeout-seconds: "5"
    alb.ingress.kubernetes.io/healthcheck-interval-seconds: "2"
    alb.ingress.kubernetes.io/healthy-threshold-count: "3"
    alb.ingress.kubernetes.io/unhealthy-threshold-count: "3"
spec:
  ingressClassName: alb
  rules:
  - http:
      paths:
      # コンテキストパスを設定します。
      - path: /tea
        backend:
          service:
            name: tea-svc
            port:
              number: 80
      # コンテキストパスを設定します。
      - path: /coffee
        backend:
          service:
            name: coffee-svc
            port:
              number: 80

次の表に、YAML テンプレートのパラメーターを示します。

パラメーター

説明

alb.ingress.kubernetes.io/healthcheck-enabled

(オプション) ヘルスチェックを有効にするかどうかを指定します。 デフォルトでは、この機能は無効 (false) になっています。

alb.ingress.kubernetes.io/healthcheck-path

オプション。 ヘルスチェックが実行される URL パス。 デフォルト値: /

  • ヘルスチェックを実行する Web ページの URL を入力します。 静的な Web ページの URL を入力することをお勧めします。 URL は 1~80 文字の長さで、文字、数字、ハイフン (-)、スラッシュ (/)、ピリオド (.)、パーセント記号 (%)、疑問符 (?)、番号記号 (#)、およびアンパサンド (&) を含めることができます。 URL には、次の拡張文字を含めることもできます: _ ; ~ ! ( ) * [ ] @ $ ^ : ' , +。 URL はスラッシュ (/) で始まる必要があります。

  • デフォルトでは、ALB インスタンスは、バックエンドの Elastic Compute Service (ECS) インスタンスで設定されたデフォルトのアプリケーションホームページに HTTP HEAD リクエストを送信して、ヘルスチェックを実行します。 ALB インスタンスは、ECS インスタンスのプライベート IP アドレスにリクエストを送信します。 ヘルスチェックにデフォルトのアプリケーションホームページを使用したくない場合は、URL パスを指定する必要があります。

alb.ingress.kubernetes.io/healthcheck-protocol

オプション。 ヘルスチェックに使用されるプロトコル。

  • HTTP: ALB インスタンスは、バックエンドサーバーに HEAD または GET リクエストを送信して、ブラウザからのアクセスをシミュレートし、バックエンドサーバーが正常であるかどうかを確認します。 これがデフォルトのプロトコルです。

  • TCP: ALB インスタンスは、バックエンドサーバーに TCP SYN パケットを送信して、バックエンドサーバーのポートがリクエストを受信できるかどうかを確認します。

alb.ingress.kubernetes.io/healthcheck-method

オプション。 ヘルスチェックに使用されるリクエストメソッド。

  • HEAD: デフォルトでは、ALB インスタンスはバックエンドサーバーに HEAD リクエストを送信して、HTTP ヘルスチェックを実行します。 バックエンドサーバーが HEAD リクエストをサポートしていることを確認してください。 バックエンドサーバーが HEAD メソッドをサポートしていないか、HEAD メソッドが無効になっている場合、ヘルスチェックが失敗することがあります。 この場合、GET メソッドを使用できます。

  • GET: 応答のサイズが 8 KB を超える場合、応答は断片化されます。 これはヘルスチェックの結果には影響しません。

alb.ingress.kubernetes.io/healthcheck-httpcode

バックエンドサーバーがヘルスチェックに合格したときに返されるステータスコード。

有効な値: http_2xx (デフォルト)、http_3xxhttp_4xx、および http_5xx

alb.ingress.kubernetes.io/healthcheck-timeout-seconds

ヘルスチェックのタイムアウト期間。 バックエンドサーバーが指定されたタイムアウト期間内に応答しない場合、サーバーはヘルスチェックに失敗します。 有効な値: 1~300。 デフォルト値: 5。 単位: 秒。

alb.ingress.kubernetes.io/healthcheck-interval-seconds

2 つの連続するヘルスチェックの間隔。 単位: 秒。 有効な値: 1~50。 デフォルト値: 2。 単位: 秒。

alb.ingress.kubernetes.io/healthy-threshold-count

異常なバックエンドサーバーが正常と見なされるまでに連続してヘルスチェックに合格する必要がある回数。 有効な値: 2~10。 デフォルト値: 3。

alb.ingress.kubernetes.io/unhealthy-threshold-count

正常なバックエンドサーバーが異常と見なされるまでに連続してヘルスチェックに失敗する必要がある回数。 有効な値: 2~10。 デフォルト値: 3。

HTTP リクエストから HTTPS リクエストへのリダイレクトの設定

ALB Ingress で alb.ingress.kubernetes.io/ssl-redirect: "true" アノテーションを設定して、HTTP リクエストを HTTPS ポート 443 にリダイレクトできます。

重要

ALB Ingress を使用してリスナーを作成することはできません。 ALB Ingress が期待どおりに機能するようにするには、AlbConfig でリスナーのポートとプロトコルを指定し、リスナーを ALB Ingress のサービスに関連付ける必要があります。 ALB リスナーの作成方法の詳細については、「AlbConfig を使用して ALB リスナーを設定する」をご参照ください。

例:

apiVersion: v1
kind: Service
metadata:
  name: demo-service-ssl
  namespace: default
spec:
  ports:
    - name: port1
      port: 80
      protocol: TCP
      targetPort: 8080
  selector:
    app: demo-ssl
  sessionAffinity: None
  type: ClusterIP
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: demo-ssl
  namespace: default
spec:
  replicas: 1
  selector:
    matchLabels:
      app: demo-ssl
  template:
    metadata:
      labels:
        app: demo-ssl
    spec:
      containers:
        - image: registry.cn-hangzhou.aliyuncs.com/alb-sample/cafe:v1
          imagePullPolicy: IfNotPresent
          name: demo-ssl
          ports:
            - containerPort: 8080
              protocol: TCP
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    alb.ingress.kubernetes.io/ssl-redirect: "true"
  name: demo-ssl
  namespace: default
spec:
  ingressClassName: alb
  tls:
  - hosts:
    - ssl.alb.ingress.top
  rules:
    - host: ssl.alb.ingress.top
      http:
        paths:
          - backend:
              service:
                name: demo-service-ssl
                port: 
                  number: 80
            path: /
            pathType: Prefix

バックエンドプロトコルとして HTTPS または gRPC を設定する

ALB は、バックエンドプロトコルとして HTTPS と gRPC をサポートしています。 ALB Ingress のバックエンドプロトコルを設定するには、alb.ingress.kubernetes.io/backend-protocol: "grpc" または alb.ingress.kubernetes.io/backend-protocol: "https" アノテーションを設定するだけです。 Ingress を使用して gRPC サービスを転送するには、対応するドメイン名に SSL 証明書があり、TLS プロトコルを使用している必要があります。 次の例は、gRPC プロトコルのサンプル構成を示しています。

説明

バックエンドプロトコルは変更できません。 プロトコルを変更するには、Ingress を削除して再構築してください。

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    alb.ingress.kubernetes.io/backend-protocol: "grpc"
  name: lxd-grpc-ingress
spec:
  ingressClassName: alb
  tls:
  - hosts:
    - demo.alb.ingress.top
  rules:
  - host: demo.alb.ingress.top
    http:
      paths:  
      - path: /
        pathType: Prefix
        backend:
          service:
            name: grpc-demo-svc
            port:
              number: 9080

正規表現の設定

カスタム転送条件を設定するには、path フィールドに正規表現を記述します。 次の例は、サンプル構成を示しています。

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
   alb.ingress.kubernetes.io/use-regex: "true" # path フィールドで正規表現をサポートします。
   alb.ingress.kubernetes.io/conditions.service-a: | # アノテーションで指定された Service はクラスター内に存在する Service である必要があり、Service 名は rule フィールドの backend の Service 名と同じである必要があります。
     [{
       "type": "Path",
       "pathConfig": {
           "values": [
              "~*^/pathvalue1", # 正規表現は正規表現フラグ ~ * に従う必要があります。
              "/pathvalue2" # 完全一致の場合、パスの前に ~ * を追加する必要はありません。
           ]
       }
      }]
  name: ingress-example
spec:
  ingressClassName: alb
  rules:
   - http:
      paths:
      - path: /test
        pathType: Prefix
        backend:
          service:
            name: service-a
            port:
              number: 88

書き換えルールの設定

ALB は書き換え機能をサポートしています。 ALB Ingress でこの機能を設定するには、alb.ingress.kubernetes.io/rewrite-target: /path/${2} アノテーションを追加します。 次のルールが適用されます。

  • rewrite-target アノテーションでは、${number} 形式の変数を、pathType が Prefix に設定されている path で設定する必要があります。

  • デフォルトでは、*? などの正規表現記号を path フィールドで使用することはできません。 正規表現記号を使用するには、rewrite-target アノテーションを設定する必要があります。

  • path/ で始まる必要があります。

説明

書き換えルールで正規表現を指定する場合は、次の点に注意してください。

  • Ingress の path フィールドには、複数の括弧 () を含む 1 つ以上の正規表現を記述できます。 ただし、rewrite-target アノテーションの書き換えパスでは、最大 3 つの変数 ${1}${2}、および ${3} を使用できます。

  • 正規表現に一致する変数が連結されて、元のパスを上書きするパスが形成されます。

  • 正規表現の置換による書き換えのロジックは次のとおりです: クライアントリクエストは、複数の括弧 () を含む正規表現に一致し、rewrite-target アノテーションには ${1}${2}、および ${3} 変数の 1 つ以上が含まれます。

たとえば、Ingress の path/sys/(.*)/(.*)/aaa に設定され、rewrite-target アノテーションが /${1}/${2} に設定されている場合、クライアントがパス /sys/ccc/bbb/aaa にリクエストを送信すると、path/sys/(.*)/(.*)/aaa に一致します。 rewrite-target アノテーションは、${1}ccc に、${2}bbb に置き換えます。 バックエンドサーバーが受信する最終的なリクエストパスは /ccc/bbb です。

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    alb.ingress.kubernetes.io/use-regex: "true" # path フィールドで正規表現をサポートします。
    alb.ingress.kubernetes.io/rewrite-target: /path/${2} # 正規表現に一致する変数が連結されて、元のパスを上書きするパスが形成されます。
  name: rewrite-ingress
spec:
  ingressClassName: alb
  rules:
  - host: demo.alb.ingress.top
    http:
      paths:
      - path: /something(/|$)(.*)
        pathType: Prefix
        backend:
          service:
            name: rewrite-svc
            port:
              number: 9080

カスタムリスニングポートの設定

ALB Ingress では、カスタムリスニングポートを設定できます。 これにより、ポート 80 と 443 を同時に介してサービスを公開できます。

重要

ALB Ingress を使用してリスナーを作成することはできません。 ALB Ingress が期待どおりに機能するようにするには、AlbConfig でリスナーのポートとプロトコルを指定し、リスナーを ALB Ingress のサービスに関連付ける必要があります。 ALB リスナーの作成方法の詳細については、「AlbConfig を使用して ALB リスナーを設定する」をご参照ください。

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: cafe-ingress
  annotations:
   alb.ingress.kubernetes.io/listen-ports: '[{"HTTP": 80},{"HTTPS": 443}]'
spec:
  ingressClassName: alb
  tls:
  - hosts:
    - demo.alb.ingress.top
  rules:
  - host: demo.alb.ingress.top
    http:
      paths:
      - path: /tea
        pathType: ImplementationSpecific
        backend:
          service:
            name: tea-svc
            port:
              number: 80

転送ルールの優先度の設定

デフォルトでは、転送ルールは次のルールに基づいて優先順位が付けられます。

  • Ingress は、namespace/name の辞書順でソートされます。 値が小さいほど、優先度が高くなります。

  • 同じ Ingress 内では、ルールは rule フィールドでの順序に基づいてソートされます。 以前に設定されたルールほど、優先度が高くなります。

Ingress の namespace/name を変更したくない場合は、次の Ingress アノテーションを設定して、転送ルールの優先度を定義できます。

説明

ルールの優先度は、同じリスナー内で一意である必要があります。 alb.ingress.kubernetes.io/order アノテーションを使用して、Ingress の優先度を指定できます。 値は 1~1,000 の整数である必要があります。 値が小さいほど、優先度が高くなります。 デフォルトの優先度は 10 です。 より高い優先度を割り当てるには、より小さい値を指定します。

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: cafe-ingress
  annotations:
   alb.ingress.kubernetes.io/order: "2"
spec:
  ingressClassName: alb
  rules:
  - host: demo.alb.ingress.top
    http:
      paths:
      - path: /tea
        pathType: ImplementationSpecific
        backend:
          service:
            name: tea-svc
            port:
              number: 80

アノテーションを使用した段階的リリースの実行

ALB は複雑なルーティング機能を提供し、ヘッダー、Cookie、および重みに基づくカナリアリリースをサポートします。 アノテーションを設定することで、カナリアリリースを実装できます。 カナリアリリースを有効にするには、alb.ingress.kubernetes.io/canary: "true" アノテーションを設定する必要があります。 さまざまなアノテーションを使用して、さまざまなカナリアリリース機能を実装できます。

説明
  • 異なるルールを使用するカナリアリリースは、ヘッダーベース > Cookie ベース > 重みベースの順に有効になります。

  • カナリアリリースを実行して新しいアプリケーションバージョンをテストするときは、元の Ingress ルールを変更しないでください。 そうしないと、アプリケーションへのアクセスが中断される可能性があります。 新しいアプリケーションバージョンがテストに合格したら、以前のアプリケーションバージョンで使用されていたバックエンド Service を、新しいアプリケーションバージョンで使用されているバックエンド Service に置き換えます。 次に、カナリアリリースを実装するための Ingress ルールを削除します。

  • alb.ingress.kubernetes.io/canary-by-header および alb.ingress.kubernetes.io/canary-by-header-value: このルールはリクエストヘッダーの値を指定し、alb.ingress.kubernetes.io/canary-by-header と一緒に使用する必要があります。

    • リクエストの headerheader-value が設定値と一致する場合、リクエストは段階的リリースサービスエンドポイントに割り当てられます。

    • 他の header 値の場合、header は無視され、リクエストトラフィックは段階的リリースの優先度に基づいて、他のルールによって設定された段階的リリースサービスに割り当てられます。

    リクエストヘッダーが location: hz の場合、リクエストはカナリアリリースサービスにルーティングされます。 他のヘッダーを持つリクエストは、カナリアリリースの重みに基づいてルーティングされます。 次の例は、サンプル構成を示しています。

    apiVersion: networking.k8s.io/v1
    kind: Ingress
    metadata:
      annotations:
        alb.ingress.kubernetes.io/order: "1"
        alb.ingress.kubernetes.io/canary: "true"
        alb.ingress.kubernetes.io/canary-by-header: "location"
        alb.ingress.kubernetes.io/canary-by-header-value: "hz"
      name: demo-canary
      namespace: default
    spec:
      ingressClassName: alb
      rules:
        - http:
            paths:
              - backend:
                  service:
                    name: demo-service-hello
                    port: 
                      number: 80
                path: /hello
                pathType: ImplementationSpecific
  • alb.ingress.kubernetes.io/canary-by-cookie: Cookie に基づいてトラフィックを分割します。

    • cookie の値が always に設定されている場合、リクエストトラフィックは段階的リリースサービスエンドポイントに割り当てられます。

    • cookie の値が never に設定されている場合、リクエストトラフィックは段階的リリースサービスエンドポイントに割り当てられません。

    説明

    Cookie ベースのカナリアリリースは、alwaysnever の値のみをサポートします。 カスタム値はサポートされていません。

    リクエスト Cookie が demo=always の場合、リクエストはカナリアリリースサービスにルーティングされます。 次の例は、サンプル構成を示しています。

    apiVersion: networking.k8s.io/v1
    kind: Ingress
    metadata:
      annotations:
        alb.ingress.kubernetes.io/order: "2"
        alb.ingress.kubernetes.io/canary: "true"
        alb.ingress.kubernetes.io/canary-by-cookie: "demo"
      name: demo-canary-cookie
      namespace: default
    spec:
      ingressClassName: alb
      rules:
        - http:
            paths:
              - backend:
                  service:
                    name: demo-service-hello
                    port: 
                      number: 80
                path: /hello
                pathType: ImplementationSpecific
  • alb.ingress.kubernetes.io/canary-weight: カナリアサービスにルーティングされるリクエストの割合を指定します。 値は 0~100 の整数である必要があります。

    次の例では、新しいアプリケーションバージョンにルーティングされるリクエストの割合が 50% に設定されています。

    apiVersion: networking.k8s.io/v1
    kind: Ingress
    metadata:
      annotations:
        alb.ingress.kubernetes.io/order: "3"
        alb.ingress.kubernetes.io/canary: "true"
        alb.ingress.kubernetes.io/canary-weight: "50"
      name: demo-canary-weight
      namespace: default
    spec:
      ingressClassName: alb
      rules:
        - http:
            paths:
              - backend:
                  service:
                    name: demo-service-hello
                    port: 
                      number: 80
                path: /hello
                pathType: ImplementationSpecific

アノテーションを使用したセッション維持の設定

ALB Ingress では、次のアノテーションを使用してセッション維持を設定できます。

  • alb.ingress.kubernetes.io/sticky-session: セッション維持を有効にするかどうかを指定します。 有効な値: true または false。 デフォルト値: false

  • alb.ingress.kubernetes.io/sticky-session-type: Cookie の処理方法。 有効な値: Insert または Server。 デフォルト値: Insert

    • Insert: Cookie を挿入します。 クライアントが最初のリクエストを送信すると、Server Load Balancer は応答に Cookie (SERVERID) を挿入します。 クライアントがこの Cookie を使用して次のリクエストを送信すると、Server Load Balancer はリクエストを以前に記録されたバックエンドサーバーに転送します。

    • Server: Cookie を書き換えます。 Server Load Balancer がユーザー定義の Cookie を見つけると、元の Cookie を書き換えます。 クライアントが新しい Cookie を使用して次のリクエストを送信すると、Server Load Balancer はリクエストを以前に記録されたバックエンドサーバーに転送します。

    説明

    このパラメーターは、サーバーグループに対して StickySessionEnabledtrue に設定されている場合にのみ有効になります。

  • alb.ingress.kubernetes.io/cookie-timeout: Cookie のタイムアウト期間 (秒)。 1~86,400 の整数を指定できます。 デフォルト値は 1000 です。

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: cafe-ingress-v3
  annotations:
    alb.ingress.kubernetes.io/sticky-session: "true"
    alb.ingress.kubernetes.io/sticky-session-type: "Insert"
    alb.ingress.kubernetes.io/cookie-timeout: "1800"
spec:
  ingressClassName: alb
  rules:
  - http:
      paths:
      # コンテキストパスを設定します。
      - path: /tea2
        backend:
          service:
            name: tea-svc
            port: 
             number: 80
      # コンテキストパスを設定します。
       - path: /coffee2
         backend:
           service:
              name: coffee-svc
              port: 
               number: 80

バックエンドサーバーグループの負荷分散アルゴリズムの指定

ALB Ingress では、Ingress アノテーション alb.ingress.kubernetes.io/backend-scheduler を設定することで、サーバーグループの負荷分散アルゴリズムを指定できます。 次の例は、サンプル構成を示しています。 デフォルトでは、クラスターのバージョンは 1.19 以降である必要があります。

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: cafe-ingress
  annotations:
    alb.ingress.kubernetes.io/backend-scheduler: "uch" # 必要に応じて uch を wrr、sch、または wlc に置き換えます。
    alb.ingress.kubernetes.io/backend-scheduler-uch-value: "test" # このパラメーターは、負荷分散アルゴリズムが uch の場合にのみ必要です。 スケジューリングアルゴリズムが wrr、sch、または wlc の場合は、このパラメーターを設定する必要はありません。
  name: cafe-ingress
spec:
  ingressClassName: alb
  rules:
  - host: demo.alb.ingress.top
    http:
      paths:
      - path: /tea
        pathType: ImplementationSpecific
        backend:
          service:
            name: tea-svc
            port:
              number: 80

alb.ingress.kubernetes.io/backend-scheduler アノテーションでは、次の値がサポートされています。

  • wrr: これはデフォルト値です。 リクエストは、その重みに基づいてバックエンドサーバーに分散されます。 重みが大きいバックエンドサーバーほど、より多くのリクエストを受信します。

  • wlc: リクエストは、その重みと既存の接続数に基づいてバックエンドサーバーに分散されます。 バックエンドサーバーの重みが同じ場合、接続数が最も少ないサーバーが選択されます。

  • sch: 同じ送信元 IP アドレスからのリクエストは、同じバックエンドサーバーにルーティングされます。

  • uch: 同じ URL パラメーターを含むリクエストは、同じバックエンドサーバーにルーティングされます。 スケジューリングアルゴリズムを uch に設定した場合、alb.ingress.kubernetes.io/backend-scheduler-uch-value アノテーションを使用して、一貫したハッシュの URL パラメーターを指定できます。

CORS の設定

次のコードブロックは、ALB Ingress でサポートされているオリジン間リソース共有 (CORS) のサンプル構成を示しています。

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: alb-ingress
  annotations:
    alb.ingress.kubernetes.io/enable-cors: "true"
    alb.ingress.kubernetes.io/cors-expose-headers: ""
    alb.ingress.kubernetes.io/cors-allow-methods: "GET,POST"
    alb.ingress.kubernetes.io/cors-allow-credentials: "true"
    alb.ingress.kubernetes.io/cors-max-age: "600"

spec:
  ingressClassName: alb
  rules:
  - host: demo.alb.ingress.top
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: cloud-nodeport
            port:
              number: 80

パラメーター

説明

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

ブラウザを使用してオリジンサーバー上のリソースにアクセスするために使用できる URL。 複数の URL はコンマ (,) で区切ります。 各 URL は http:// または https:// で始まり、有効なドメイン名またはトップレベルのワイルドカードドメイン名を含む必要があります。

デフォルト値: *。 例: alb.ingress.kubernetes.io/cors-allow-origin: "https://example.com:4443, http://aliyundoc.com, https://example.org:1199"

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

許可される HTTP メソッド。 値では大文字と小文字は区別されません。 複数の HTTP メソッドはコンマ (,) で区切ります。

デフォルト値: GET, PUT, POST, DELETE, PATCH, OPTIONS。 例: alb.ingress.kubernetes.io/cors-allow-methods: "PUT, GET, POST, OPTIONS"

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

許可されるリクエストヘッダー。 リクエストヘッダーには、文字、数字、アンダースコア (_)、およびハイフン (-) を含めることができます。 複数のリクエストヘッダーはコンマ (,) で区切ります。

デフォルト値: DNT,X-CustomHeader,Keep-Alive,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Authorization。 例: alb.ingress.kubernetes.io/cors-allow-headers: "X-Forwarded-For, X-app123-XPTO"

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

公開できるヘッダー。 ヘッダーには、文字、数字、アンダースコア (_)、ハイフン (-)、およびアスタリスク (*) を含めることができます。 複数のヘッダーはコンマ (,) で区切ります。

デフォルト値: empty。 例: alb.ingress.kubernetes.io/cors-expose-headers: "*, "X-CustomResponseHeader"

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

CORS リクエストに認証情報を含めるかどうかを指定します。

デフォルト値: true。 例: alb.ingress.kubernetes.io/cors-allow-credentials: "false"

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

OPTIONS メソッドを使用するプリフライトリクエストをキャッシュできる最大期間。 複雑なリクエストに対してこのパラメーターを設定します。 有効な値: -1~172800。 単位: 秒。

デフォルト値: 172800

バックエンドの持続的接続

従来のロードバランサーは、短命の接続を使用してバックエンドサーバーグループにアクセスします。 各リクエストでは、新しい TCP 接続を確立してから終了する必要があります。 これにより、パフォーマンス専有型システムでネットワーク接続のボトルネックが発生する可能性があります。 Server Load Balancer は、バックエンドサーバーへの持続的接続をサポートしています。 この機能により、接続レイヤーのリソース消費が削減され、処理パフォーマンスが大幅に向上します。 alb.ingress.kubernetes.io/backend-keepalive アノテーションを使用して、ALB Ingress の持続的接続を有効にできます。 次の例は、サンプル構成を示しています。

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: alb-ingress
  annotations:
    alb.ingress.kubernetes.io/backend-keepalive: "true"
spec:
  ingressClassName: alb
  rules:
  - host: demo.alb.ingress.top
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: cloud-nodeport
            port:
              number: 80

QPS スロットリングの設定

ALB は、転送ルールのクエリ/秒 (QPS) スロットリングをサポートしています。 スロットリング値は 1~100,000 の整数である必要があります。 ALB Ingress の場合は、alb.ingress.kubernetes.io/traffic-limit-qps アノテーションを設定するだけです。 次の例は、サンプル構成を示しています。

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: cafe-ingress
  annotations:
    alb.ingress.kubernetes.io/traffic-limit-qps: "50"
spec:
  ingressClassName: alb
  rules:
   - host: demo.alb.ingress.top
     http:
      paths:
      - path: /tea
        pathType: ImplementationSpecific
        backend:
          service:
            name: tea-svc
            port:
              number: 80
      - path: /coffee
        pathType: ImplementationSpecific
        backend:
          service:
            name: coffee-svc
            port:
              number: 80