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

Container Compute Service:ALB Ingress のカスタム転送ルール

最終更新日:Sep 15, 2026

ALB Ingress は、カスタムルーティングルールをサポートしています。ルーティングルールは、ルーティング条件とアクションで構成されます。ドメイン名、パス、リクエストヘッダー、クエリ文字列、リクエストメソッド、Cookie、またはソース IP アドレスに一致するようにルーティング条件をカスタマイズできます。また、固定レスポンスの返却、リクエストのリダイレクト、リクエストヘッダーの挿入、リクエストヘッダーの削除、トラフィックのミラーリング、複数のバックエンドサーバーグループへのリクエスト転送、またはリクエストの書き換えを行うアクションを指定することもできます。このトピックでは、ALB Ingress のルーティングルールをカスタマイズする方法について説明します。

前提条件

v2.5.0 以降の ALB Ingress コントローラーが必要です。アドオンをアップグレードするには、「アドオンの管理」をご参照ください。

説明

コンソールでカスタムルーティングルールを設定する機能は、カナリアリリース中です。この機能を使用するには、チケットを送信してアクセスをリクエストしてください。

ルーティング条件

重要
  • 1 つのルーティングルールには、最大 10 個のルーティング条件を設定できます。

  • ResponseHeader および ResponseStatusCode ルーティング条件は、レスポンスをカスタマイズするルーティングルールに対してのみ有効です。

条件タイプ

ALB Ingress では、alb.ingress.kubernetes.io/conditions.<サービス名> アノテーションを使用してルーティング条件を設定します。別々のブロックにある条件は論理 AND で評価され、同じブロック内の複数の値は論理 OR で評価されます。たとえば、2 つの別々の Header 条件ブロックは AND でリンクされますが、1 つの Header ブロック内の複数の値は OR でリンクされます。

条件

説明

ドメイン名

ドメイン名に基づいてリクエストをルーティングします。以下に例を示します。

alb.ingress.kubernetes.io/conditions.host-example: |
  [{
      "type": "Host",
      "hostConfig": {
        "values": [
          "anno.example.com"
        ]
      }
  }]
  • type:ルーティング条件のタイプ。ドメイン名に基づいてリクエストを照合するには、値を Host に設定します。

  • hostConfig:照合するドメイン名。複数のドメイン名を指定した場合、論理 OR が実行されます。

パス

パスに基づいてリクエストをルーティングします。以下に例を示します。

alb.ingress.kubernetes.io/conditions.path-example: |
  [{
    "type": "Path",
    "pathConfig": {
      "values": [
        "/pathvalue1",
        "/pathvalue2"
      ]
    }
  }]
  • type:ルーティング条件のタイプ。リクエストパスに基づいてリクエストを照合するには、値を Path に設定します。

  • pathConfig:照合するリクエストパス。複数のパスを指定した場合、論理 OR が実行されます。

ヘッダー

リクエストヘッダーに基づいてリクエストをルーティングします。以下に例を示します。

alb.ingress.kubernetes.io/conditions.http-header-example: |
  [{
    "type": "Header",
    "headerConfig": {
      "key": "headername",
      "values": [
        "headervalue1",
        "headervalue2"
      ]
     }
  }]
  • type:ルーティング条件のタイプ。リクエストヘッダーに基づいてリクエストを照合するには、値を Header に設定します。

  • headerConfig:リクエストヘッダーのキーと値のペア。同じキーに複数の値を指定した場合、値に対して論理 OR が実行されます。

クエリ文字列

クエリ文字列に基づいてリクエストをルーティングします。以下に例を示します。

alb.ingress.kubernetes.io/conditions.query-string-example: |
  [{
    "type": "QueryString",
    "queryStringConfig": {
      "values": [
        {
           "key":"querystringkey1",
           "value":"querystringvalue2"
        }
      ]
    }
  }]
  • type:ルーティング条件のタイプ。クエリ文字列に基づいてリクエストを照合するには、値を QueryString に設定します。

  • queryStringConfig:クエリ文字列のキーと値のペア。キーと値の長さは 1~100 文字である必要があります。小文字、表示可能な文字、ワイルドカードのアスタリスク (*) と疑問符 (?) を含めることができます。スペースおよび次の文字はサポートされていません:#[]{}\|<>&。複数のキーと値のペアを指定した場合、論理 OR が実行されます。

リクエストメソッド

リクエストメソッドに基づいてリクエストをルーティングします。以下に例を示します。

alb.ingress.kubernetes.io/conditions.http-method-example: |
  [{
    "type": "Method",
    "methodConfig": {
      "values": [
        "GET",
        "HEAD"
      ]
    }
  }]
  • type:ルーティング条件のタイプ。リクエストメソッドに基づいてリクエストを照合するには、値を Method に設定します。

  • methodConfig:照合するリクエストメソッド。サポートされているメソッドには、GET、POST、PUT、DELETE、HEAD、OPTIONS、PATCH があります。複数のメソッドを指定した場合、論理 OR が実行されます。

Cookie

Cookie に基づいてリクエストをルーティングします。以下に例を示します。

alb.ingress.kubernetes.io/conditions.http-cookie-example: |
  [{
    "type": "Cookie",
    "cookieConfig": {
      "values": [
        {
           "key":"cookiekey1",
           "value":"cookievalue2"
        }
      ]
     }
  }]
  • type:ルーティング条件のタイプ。Cookie に基づいてリクエストを照合するには、値を Cookie に設定します。

  • cookieConfig:Cookie のキーと値のペア。キーと値の長さは 1~100 文字である必要があります。小文字、表示可能な文字、ワイルドカードのアスタリスク (*) と疑問符 (?) を含めることができます。スペースおよび次の文字はサポートされていません:#[]{}\|<>&。複数のキーと値のペアを指定した場合、論理 OR が実行されます。

SourceIP

ソース IP アドレスに基づいてリクエストをルーティングします。以下に例を示します。

alb.ingress.kubernetes.io/conditions.source-ip-example: |
  [{
    "type": "SourceIp",
    "sourceIpConfig": {
      "values": [
        "192.168.0.0/16",
        "172.16.0.0/16"
      ]
    }
  }]
  • type:ルーティング条件のタイプ。ソース IP アドレスに基づいてリクエストを照合するには、値を SourceIP に設定します。

  • sourceIpConfig:照合するソース IP アドレスまたは CIDR ブロック。複数のエントリを指定した場合、論理 OR が実行されます。

ResponseHeader

レスポンスヘッダーに基づいてレスポンスをカスタマイズします。以下に例を示します。

alb.ingress.kubernetes.io/conditions.response-header-example: |
  [{
    "type": "ResponseHeader",
    "headerConfig": {
      "key": "headername",
      "values": [
        "headervalue1",
        "headervalue2"
      ]
     }
  }]
  • type:ルーティング条件のタイプ。レスポンスヘッダーに基づいてレスポンスを照合するには、値を ResponseHeader に設定します。

  • headerConfig:レスポンスヘッダーのキーと値のペア。同じキーに複数の値を指定した場合、値に対して論理 OR が実行されます。

ResponseStatusCode

レスポンスステータスコードに基づいてレスポンスをカスタマイズします。以下に例を示します。

alb.ingress.kubernetes.io/conditions.response-code-example: |
  [{
    "type": "ResponseStatusCode",
    "responseStatusCodeConfig": {
      "values": [
        "statuscode1",
        "statuscode2"
      ]
    }
  }]
  • type:ルーティング条件のタイプ。レスポンスステータスコードに基づいてレスポンスを照合するには、値を ResponseStatusCode に設定します。

  • responseStatusCodeConfig:照合するレスポンスステータスコード。複数のステータスコードを指定した場合、論理 OR が実行されます。

ユースケース 1:ソース IP とヘッダー

重要

1 つのルーティングルールにつき、最大 5 つの SourceIp 条件を指定できます。

次の YAML 設定は、リクエストのソース IP アドレス、特定のヘッダー、およびリクエストパスに基づいてトラフィックをルーティングする方法を示しています。

リクエストが gray-hello サービスにルーティングされるのは、次のすべての基準を満たす場合のみです:ソース IP が 192.168.0.0/16 または 172.16.0.0/16 からであり、リクエストに gray-hello という名前のヘッダーが含まれ、その値が value1 または value2 であり、リクエストパスが /hello である場合。他のすべてのリクエストは他のサービスにルーティングされます。

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
   alb.ingress.kubernetes.io/order: "1"
   alb.ingress.kubernetes.io/conditions.gray-hello: |
     [{
       "type": "Header",
       "headerConfig": {
          "key":"gray-hello",
           "values": [
              "value1",
              "value2"
           ]
       }
      },
      {
         "type": "SourceIp",
         "sourceIpConfig": {
           "values": [
             "192.168.0.0/16",
             "172.16.0.0/16"
           ]
         }
     }]
  name: gray-hello
spec:
  ingressClassName: alb
  rules:
   - http:
      paths:
      - path: /hello
        pathType: ImplementationSpecific
        backend:
          service:
            name: gray-hello
            port:
              number: 88

alb.ingress.kubernetes.io/order:Ingress の優先度を指定します。数値が小さいほど優先度が高くなります。

ユースケース 2:ドメイン名、リクエストメソッド、および Cookie

次の YAML 設定は、ドメイン名、リクエストメソッド、および Cookie に基づいてトラフィックをルーティングする方法を示しています。

リクエストが service-a サービスにルーティングされるのは、次のすべての基準を満たす場合のみです:リクエストメソッドが GET または HEAD であり、ドメイン名が www.hostvalue1.edu または www.hostvalue2.edu であり、リクエストにキーが cookiekey1 で値が cookievalue1 の Cookie が含まれ、リクエストパスが /test である場合。一致しないリクエストは service-b サービスにルーティングされます。

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
   alb.ingress.kubernetes.io/conditions.service-a: |
     [{
       "type": "Cookie",
       "cookieConfig": {
         "values": [
           {
             "key":"cookiekey1",
             "value":"cookievalue1"
           }
        ]
       }
      },
      {
       "type": "Method",
       "methodConfig": {
         "values": [
           "GET",
           "HEAD"
         ]
       }
      },
     {
       "type": "Host",
       "hostConfig": {
           "values": [
              "www.hostvalue1.edu",
              "www.hostvalue2.edu"
           ]
       }
      }]
  name: ingress-example
spec:
  ingressClassName: alb
  rules:
   - http:
      paths:
      - path: /test
        pathType: ImplementationSpecific
        backend:
          service:
            name: service-a
            port:
              number: 88
      - path: /test
        pathType: ImplementationSpecific
        backend:
          service:
            name: service-b
            port:
              number: 88

ユースケース 3:クエリ文字列、ヘッダー、およびパス

次の YAML 設定は、特定のパスに対してクエリ文字列と複数のヘッダーの条件を組み合わせてトラフィックをルーティングする方法を示しています。

リクエストパスが /pathvalue1/pathvalue2、または /test であり、クエリ文字列のキーが querystringkey1 でその値が querystringvalue2 であり、リクエストヘッダーに headerkey1headerkey2 が含まれている必要があります。headerkey1 ヘッダーの値は headervalue1 または headervalue2 でなければならず、headerkey2 ヘッダーの値は headervalue3 または headervalue4 でなければなりません。これらの条件を満たす場合、リクエストは service-a にルーティングされます。それ以外の場合、リクエストは service-b にルーティングされます。

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
   alb.ingress.kubernetes.io/conditions.service-a: |
     [{
       "type": "Path",
       "pathConfig": {
           "values": [
              "/pathvalue1",
              "/pathvalue2"
           ]
       }
      },
      {
       "type": "QueryString",
       "queryStringConfig": {
         "values": [
           {
             "key":"querystringkey1",
             "value":"querystringvalue2"
           }
        ]
       }
      },
     {
       "type": "Header",
       "headerConfig": {
          "key":"headerkey1",
           "values": [
              "headervalue1",
              "headervalue2"
           ]
       }
     },
     {
       "type": "Header",
       "headerConfig": {
          "key":"headerkey2",
           "values": [
              "headervalue3",
              "headervalue4"
           ]
       }
     }]
  name: ingress-example
spec:
  ingressClassName: alb
  rules:
   - http:
      paths:
      - path: /test
        pathType: ImplementationSpecific
        backend:
          service:
            name: service-a
            port:
              number: 88
      - path: /test
        pathType: ImplementationSpecific
        backend:
          service:
            name: service-b
            port:
              number: 88

転送アクション

転送アクション

ALB Ingress では、alb.ingress.kubernetes.io/actions.<サービス名> アノテーションを使用してルーティングアクションを設定できます。固定レスポンスの返却、リクエストのリダイレクト、リクエストヘッダーの挿入、リクエストヘッダーの削除、トラフィックミラーリング、複数のバックエンドサーバーグループへのリクエスト転送、リクエストの書き換えなどのアクションを追加できます。これらのアクションにより、リクエストとレスポンスのルーティングルールを柔軟に制御できます。

重要
  • alb.ingress.kubernetes.io/actions.<サービス名> アノテーションのサービス名は、rule フィールドの backend で指定されたサービス名と一致する必要があります。

  • 同じルーティングルール内で、リダイレクト、固定レスポンス、複数のサーバーグループへの転送などの終端アクションは相互に排他的です。

  • リダイレクト、固定レスポンス、または複数のサーバーグループへの転送を設定する場合、rule フィールドの backend セクションにある servicePort の名前は use-annotation にする必要があります。

インバウンドルーティングアクション

アクション

説明

固定レスポンス

クライアントに固定レスポンスを返します。レスポンスステータスコード、ボディ、コンテンツタイプを設定できます。

alb.ingress.kubernetes.io/actions.response-503: |
  [{
      "type": "FixedResponse",
      "FixedResponseConfig": {
          "contentType": "text/plain",
          "httpCode": "503",
          "content": "503 error text"
      }
  }]
  • type:転送アクションのタイプ。固定レスポンスを設定するには FixedResponse に設定します。

  • contentType:レスポンスボディのコンテンツタイプ。

  • httpCode:レスポンスステータスコード。

  • content:レスポンスボディ。

リダイレクト

HTTP 3xx ステータスコードを使用して、クライアントリクエストを別の URL にリダイレクトします。

重要

httpCode 以外に、リダイレクト設定で少なくとも 1 つのパラメーターを指定する必要があります。

alb.ingress.kubernetes.io/actions.redirect: |
  [{
      "type": "Redirect",
      "RedirectConfig": {
          "host": "${host}",
          "path": "${path}",
          "port": "${port}",
          "protocol": "${protocol}",
          "query": "${query}",
          "httpCode": "301"
      }
  }]
  • type:転送アクションのタイプ。リダイレクトを設定するには Redirect に設定します。

  • host:リダイレクトの宛先ドメイン名。

  • path:リダイレクトの宛先パス。

  • port:リダイレクトの宛先ポート。

  • protocol:リダイレクトの宛先プロトコル。

  • query:リダイレクトの宛先クエリ文字列。

  • httpCode:ステータスコード。

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

リクエストをコピーし、トラフィックミラーリングサーバーグループに転送します。

重要
  • トラフィックミラーリング転送アクションは、転送、ヘッダー挿入、ヘッダー削除、レート制限アクションとのみ使用できます。書き換え、固定レスポンス、リダイレクトアクションとは互換性がありません。

  • トラフィックミラーリングサーバーグループは、ServerGroupID を使用してのみ関連付けることができます。

alb.ingress.kubernetes.io/actions.traffic-mirror: |
      [{
          "type": "TrafficMirror",
          "TrafficMirrorConfig": {
              "TargetType" : "ForwardGroupMirror",
              "MirrorGroupConfig": {
                  "ServerGroupTuples" : [{
                      "ServerGroupID": "sgp-2auud2fxj1r46*****"
                  }]
              }
           }
      }]
  • type:転送アクションのタイプ。トラフィックミラーリングを設定するには TrafficMirror に設定します。

  • TargetType:ミラーリングターゲットのタイプ。現在、サーバーグループにリクエストをミラーリングする ForwardGroupMirror のみがサポートされています。

  • ServerGroupID:トラフィックミラーリングサーバーグループの ID。

複数のバックエンドサーバーグループへの転送

リクエストを複数のバックエンドサーバーグループに転送します。ServerGroupID を使用してバックエンドサーバーグループを指定するか、ServiceNameServicePort の組み合わせを使用して作成または関連付けることができます。また、各サーバーグループに重みを設定してリクエストを分散させることもできます。

重要
  • 標準の ALB インスタンスは、最大 5 つのサーバーグループに関連付けることができます。

  • ServerGroupIDServiceName+ServicePort の両方を使用してサーバーグループをアタッチする場合、システムは ServerGroupID を優先してバックエンドサーバーグループを照合します。

alb.ingress.kubernetes.io/actions.forward: |
       [{
           "type": "ForwardGroup",
           "ForwardConfig": {
             "ServerGroups" : [{
               "ServiceName": "tea-svc",
               "Weight": 30,
               "ServicePort": 80
             },
             {
               "ServiceName": "coffee-svc",
               "Weight": 20,
               "ServicePort": 80
             },
             {
               "ServerGroupID": "sgp-71aexb9y93ypo*****",
               "Weight": 20
             },
             {
               "ServerGroupID": "sgp-slygpbvm2cydo*****",
               "Weight": 30
             }]
           }
       }]
  • type:転送アクションのタイプ。リクエストを複数のバックエンドサーバーグループに転送するには ForwardGroup に設定します。

  • ForwardConfig:バックエンドサーバーグループの設定。複数のサーバーグループが指定されている場合、リクエストはそれらの重みに基づいて分散されます。

  • ServerGroupID:サーバーグループの ID。

  • ServiceName:サービスの名前。

  • ServicePort:サービスのポート。

  • Weight:サーバーグループの重み。これは、サーバーグループに転送されるリクエストの割合を決定します。

書き換え

リクエストのホスト、パス、またはクエリ文字列を書き換えます。

重要
  • 書き換え転送アクションは rewrite-target アノテーションと競合します。両方を設定しないでください。

  • このアクションは、固定レスポンスまたはリダイレクト転送アクションとは使用できません。

alb.ingress.kubernetes.io/actions.rewrite: |
       [{
           "type": "Rewrite",
           "RewriteConfig": {
               "Host": "demo.domain.ingress.top",
               "Path": "/test",
               "Query": "querystring"
           }
       }]
  • type:転送アクションのタイプ。書き換えを設定するには Rewrite に設定します。

  • RewriteConfig:書き換えのパラメーター。

  • Host:リクエストのホストが書き換えられるドメイン名。

  • Path:リクエストのパスが書き換えられるパス。

  • Query:リクエストのクエリ文字列が書き換えられるクエリ文字列。

詳細については、「書き換えの設定」をご参照ください。

ヘッダーの挿入

リクエストにヘッダーを挿入します。同じ名前のヘッダーが既に存在する場合、上書きされます。

alb.ingress.kubernetes.io/actions.insert-header: |
  [{
      "type": "InsertHeader",
      "InsertHeaderConfig": {
          "key": "key",
          "value": "value",
          "valueType": "UserDefined"
      }
  }]
  • type:転送アクションのタイプ。ヘッダーを挿入するには InsertHeader に設定します。

  • key:ヘッダーフィールドの名前。

  • value:ヘッダーフィールドの値。

  • valueType:値のタイプ。

ヘッダーの削除

リクエストから指定されたヘッダーを削除します。

alb.ingress.kubernetes.io/actions.remove-header: |
     [{
         "type": "RemoveHeader",
         "RemoveHeaderConfig": {
             "key": "key"
         }
     }]

type:転送アクションのタイプ。リクエストヘッダーを削除するには、値を RemoveHeader に設定します。

key:リクエストヘッダーフィールドの名前。

レート制限

全体の秒間クエリ数 (QPS) と特定のクライアント IP アドレスからの QPS に基づいてリクエストのレートを制限します。

重要
  • レート制限転送アクションは、サーバーグループにリクエストを転送するアクションと併用する必要があります。

  • X-Forwarded-For リクエストヘッダーに複数の IP アドレスが含まれている場合 (例:X-Forwarded-For: <client-ip-address>, <proxy1>, <proxy2>)、左端のアドレスが実際のクライアント IP アドレスです。クライアント IP アドレスに基づくレート制限を使用するには、リスナーでクライアント IP アドレスを取得するオプションを有効にする必要があります。これにより、ALB は X-Forwarded-For ヘッダーから実際のクライアント IP アドレスを識別できます。詳細については、「XForwardedForConfig」をご参照ください。

 annotations:
    alb.ingress.kubernetes.io/actions.traffic-limit: |
      [{
          "type": "TrafficLimit",
          "TrafficLimitConfig": {
              "QPS": "1000",
              "QPSPerIp": "100"
          }
      }]
  • type:転送アクションのタイプを指定します。このパラメーターを TrafficLimit に設定します。この値は、トラフィックの速度制限設定を示します。

  • QPS:全体のリクエストレート制限。1 秒間に処理できるリクエストの数です。有効な値の範囲は [1,1000000] です。リクエストレートが指定された制限を超えると、超過した新しい接続リクエストは拒否され、クライアントは HTTP 503 ステータスコードを受け取ります。

  • QPSPerIp:各クライアント IP アドレスに基づくリクエストレート制限を指定します。値の範囲は [1,1000000] です。QPS (全体的なレート制限) と QPSPerIp (IP ごとのレート制限) の両方が設定されている場合、QPSPerIp の値は QPS の値より小さくなければなりません。リクエストレートが設定された制限を超えると、超過したリクエストは拒否され、クライアントは HTTP 503 ステータスコードを受け取ります。

アウトバウンドルーティングアクション

アクション

説明

リクエストヘッダーの挿入

指定された名前と値を持つヘッダーを挿入します。同じ名前のヘッダーが既に存在する場合、上書きされます。

alb.ingress.kubernetes.io/actions.insert-header: |
  [{
      "type": "InsertHeader",
      "InsertHeaderConfig": {
          "key": "key",
          "value": "value",
          "valueType": "UserDefined"
      }
  }]
  • type:転送アクションのタイプ。リクエストヘッダーを挿入するには InsertHeader に設定します。

  • key:ヘッダーフィールド名。

  • value:ヘッダーフィールド値。

  • valueType:値のタイプ。

リクエストヘッダーの削除

リクエストから指定されたヘッダーを削除します。

alb.ingress.kubernetes.io/actions.remove-header: |
     [{
         "type": "RemoveHeader",
         "RemoveHeaderConfig": {
             "key": "key"
         }
     }]

type:転送アクションのタイプ。リクエストヘッダーを削除するには RemoveHeader に設定します。

key:ヘッダーフィールド名。

シナリオ 1:固定の 503 レスポンスとコンテンツを設定

コンソール

  1. ACS コンソールにログインします。左側のナビゲーションウィンドウで、クラスターリスト をクリックします。

  2. クラスターリスト ページで、対象のクラスターの名前をクリックします。左側のナビゲーションウィンドウで、ネットワーク > Ingress を選択します。

Ingress ページで Ingress の作成 をクリックし、Ingress の作成 ダイアログボックスで Ingress を設定します。

パラメーター

説明

ゲートウェイタイプ

ビジネスニーズに応じて、ゲートウェイタイプとして ALB または MSE Ingress を選択します。

ALB

名前

Ingress のカスタム名。

ingress

Ingress クラス

Ingress のカスタムクラス。

alb

リスナー / ポート

AlbConfig で定義されている ALB インスタンスのリスナーポートとプロトコル。この設定は、ロードバランサーがインバウンドトラフィックを受信して処理する方法を指定します。

HTTP:80

ルール

+ルールの追加 をクリックして、複数のルーティングルールを追加します。

  • ドメイン名: カスタムドメイン名。

  • マッピング:以下のパラメーターを設定します。

    • パス: サービスにアクセスするための URL パスです。この例では、ルートパス / を使用するため、このパラメーターは空のままにします。

    • ルール: Prefix (前方一致)Exact (完全一致)、および ImplementationSpecific (デフォルト値) に対応しています。

    • サービス:Kubernetes サービスであるターゲットバックエンドです。

    • ポート: サービスが公開するポートです。

  • Ingress は、同一ドメイン名配下で複数のパスをサポートします。新しいパスを追加するには、+追加 をクリックします。

  • ドメイン名: 空白のままにします。

  • マッピング

    • パス: /

    • ルール: デフォルト (プレフィックス)

    • サービス: response-503

    • ポート: 80

TLS 設定

TLS を設定して、安全なルーティングサービスを有効にします。

  • ドメイン名: カスタムドメイン名。

  • シークレット:必要に応じてシークレットを選択します。

TLS 設定 を無効にします。この例では必須ではありません。

その他

  • カナリアリリース: この機能を有効にすると、カナリアリリースを設定できます。リクエストヘッダー、 Cookie、またはトラフィックの重みに基づいてカナリアルールを設定できます。

    説明

    これらの条件のうち 1 つだけを設定できます。複数の条件を設定した場合、Ingress コントローラーはリクエストヘッダー、Cookie、そして重みの順で評価します。

    • リクエストヘッダーに基づく: リクエストヘッダーに基づいてトラフィックを分割します。これにより、nginx.ingress.kubernetes.io/canary-by-headernginx.ingress.kubernetes.io/canary-by-header-value、または nginx.ingress.kubernetes.io/canary-by-header-pattern アノテーションが追加されます。

    • Cookie に基づく: Cookie に基づいてトラフィックを分割します。これにより、nginx.ingress.kubernetes.io/canary-by-cookie アノテーションが追加されます。

    • 重みに基づく: 指定されたサービスにルーティングされるリクエストのパーセンテージ (0 から 100 までの整数) です。これにより、nginx.ingress.kubernetes.io/canary-weight アノテーションが追加されます。

  • プロトコル: バックエンドサービスとの通信に使用されるプロトコルです。これにより nginx.ingress.kubernetes.io/backend-protocol アノテーションが追加されます。

    HTTP、HTTPS、gRPC、および gRPCS がサポートされています。

  • 書き換えパス: バックエンドサービスに送信する前に、クライアントリクエストのパスを書き換えます。これにより、nginx.ingress.kubernetes.io/rewrite-target アノテーションが追加されます。

カナリアリリースを無効にします。プロトコルと書き換えパスはデフォルトのままにします。これらの設定はこの例では必須ではありません。

カスタム転送ルール

説明

コンソールでカスタム転送ルールを設定する機能はカナリアリリース中です。この機能を使用するには、チケットを送信

カスタム転送ルールを使用して、インバウンドトラフィックを詳細に管理します。

説明

転送ルールには最大 10 個の条件を追加できます。

  • 転送条件 ドロップダウンリストから、条件を選択します:

    • ドメイン名

      ドメイン名に基づいてリクエストを照合します。複数のドメイン名を指定した場合、それらの関係は論理 OR です。この条件を設定すると、alb.ingress.kubernetes.io/conditions.host-example アノテーションが追加されます。

    • パス

      リクエストパスに基づいてリクエストを照合します。複数のパスを指定した場合、それらの関係は論理 OR です。この条件を設定すると、alb.ingress.kubernetes.io/conditions.path-example アノテーションが追加されます。

    • HTTP ヘッダー:

      リクエストヘッダーのキーと値のペアに基づいてリクエストを照合します。 たとえば、キー:headername に、値:headervalue1 に設定できます。 複数のヘッダー値を指定した場合、それらの関係は論理 OR になります。 この条件を設定すると、alb.ingress.kubernetes.io/conditions.http-header-example アノテーションが追加されます。

  • 転送操作 ドロップダウンリストから、操作を選択します:

    • 転送先

      複数のバックエンドサーバーグループにリクエストを転送します。サービス では、ターゲットサービスを選択します。ポート では、ターゲットポート番号を選択します。次に、カスタムの重み値を設定します。

      説明
      • クラスターが Flannel ネットワークプラグインを使用している場合、ClusterIP タイプのサービスはサポートされません。

      • このアクションを選択した場合、ルールにパスマッピングを設定する必要はありません。

    • 固定のレスポンスを返す

      ALB インスタンスがクライアントに固定レスポンスを返すように設定します。 応答ステータスコード、コンテンツ、およびコンテンツタイプを設定できます。 必要に応じて、レスポンスステータスコードレスポンスボディタイプ (オプション)、およびレスポンスボディ (オプション) を設定します。

      レスポンスコンテンツタイプ

      • text/plain:プレーンテキスト形式。

      • text/css:CSS 形式。

      • text/html:HTML 形式。

      • application/javascript:JavaScript 形式。

      • application/json:JSON 形式。

複数の条件 (ドメイン、パス、または HTTP ヘッダーに基づく) とアクション (バックエンドへの転送や固定レスポンスの返却など) を組み合わせることができます。

  • 転送条件: [パス] を選択します。(デフォルト設定のままにします)

  • 転送操作:固定応答を返す

    • レスポンスステータスコード: 503

    • レスポンスボディタイプ (オプション)text/plain

    • レスポンスボディ (オプション): error

アノテーション

キーと値を指定してカスタムアノテーションを追加するか、キーでアノテーションを選択または検索できます。Ingress アノテーションの詳細については、「ALB Ingress アノテーションリファレンス」をご参照ください。

+ アノテーションの追加 をクリックして、Ingress に複数のアノテーションを追加します。

このパラメーターはこの例では必須ではありません。

ラベル

Ingress に追加するラベルを指定します。ラベルは、識別属性を指定するためにオブジェクトにアタッチされるキーと値のペアです。

このパラメーターはこの例では必須ではありません。

  1. 構成が完了したら、OK をクリックします。

kubectl

次の YAML は、ルールに一致するリクエストに対してステータスコード 503 とコンテンツ 503 error text を返す Ingress を定義します。

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  namespace: default
  name: ingress
  annotations:
    alb.ingress.kubernetes.io/actions.response-503: |
      [{
          "type": "FixedResponse",
          "FixedResponseConfig": {
              "contentType": "text/plain",
              "httpCode": "503",
              "content": "503 error text"
          }
      }]
spec:
  ingressClassName: alb
  rules:
    - http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: response-503
                port:
                  name: use-annotation # Service ポートの `name` は `use-annotation` である必要があります。

シナリオ 2:HTTPS ポートへの 301 リダイレクト

次のコードブロックは、サービスリクエストを対応する HTTPS ポートにリダイレクトします。

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  namespace: default
  name: ingress
  annotations:
    alb.ingress.kubernetes.io/actions.redirect: |
      [{
          "type": "Redirect",
          "RedirectConfig": {
              "host": "${host}",
              "path": "${path}",
              "port": "${port}",
              "protocol": "https",
              "query": "${query}",
              "httpCode": "301"
          }
      }]
spec:
  ingressClassName: alb
  rules:
    - http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: redirect
                port:
                  name: use-annotation # サービスポート名は 'use-annotation' である必要があります。

シナリオ 3:「source: alibaba」リクエストヘッダーの追加

このコードブロックは、サービスリクエストのリクエストヘッダーを source: alibaba で上書きします。

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  namespace: default
  name: ingress
  annotations:
  # 参照される Service はクラスター内に存在し、その名前はルールの `backend` フィールドの名前と一致する必要があります。
    alb.ingress.kubernetes.io/actions.insert-header: |
      [{
          "type": "InsertHeader",
          "InsertHeaderConfig": {
              "key": "source",
              "value": "alibaba",
              "valueType": "UserDefined"
          }
      }]
spec:
  ingressClassName: alb
  rules:
    - http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: insert-header
                port:
                  number: 80

シナリオ 4:トラフィックミラーリング

次のコードは、リクエストをトラフィックミラーリングサーバーグループにコピーする方法を示しています。

Application Load Balancer (ALB) コンソールにログインします。左側のナビゲーションウィンドウで、ALB > サーバーグループ を選択し、サーバーグループ ID を見つけます。

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: traffic-mirror-ingress
  annotations:
  # アノテーション内のサービスはクラスター内に存在し、そのサービス名はルールフィールドのバックエンド内のサービス名と一致する必要があります。
   alb.ingress.kubernetes.io/actions.traffic-mirror: |
       [{
           "type": "TrafficMirror",
           "TrafficMirrorConfig": {
              "TargetType" : "ForwardGroupMirror",
              "MirrorGroupConfig": {
                  "ServerGroupTuples" : [{
                      "ServerGroupID": "sgp-2auud2fxj1r46*****"
                  }]
              }
           }
       }]
spec:
  ingressClassName: alb
  rules:
   - host: demo.domain.ingress.top
     http:
      paths:
      - path: /test
        pathType: Prefix
        backend:
          service:
            name: traffic-mirror
            port:
              number: 80

シナリオ 5:複数のバックエンドグループへのリクエスト転送

コンソールでの設定

  1. ACS コンソールにログインします。左側のナビゲーションウィンドウで、クラスターリスト をクリックします。

  2. クラスターリスト ページで、対象のクラスターの名前をクリックします。左側のナビゲーションウィンドウで、ネットワーク > Ingress を選択します。

  3. Ingress ページで、Ingress の作成 をクリックし、Ingress の作成 ダイアログボックスで Ingress を設定します。

    パラメーター

    説明

    ゲートウェイタイプ

    ゲートウェイタイプとして ALB または MSE Ingress を選択します。

    ALB

    名前

    Ingress のカスタム名。

    forward-ingress

    Ingress クラス

    Ingress のカスタムクラス。

    alb

    リスナー / ポート

    AlbConfig で定義されている ALB インスタンスのリスナーポートとプロトコル。この設定は、ロードバランサーがインバウンドトラフィックを処理する方法を指定します。

    HTTP:80

    ルール

    +ルールの追加 をクリックして、複数のルーティングルールを追加します。

    • ドメイン名: カスタムドメイン名。

    • マッピング:以下のパラメーターを設定します。

      • パス:サービスにアクセスするための URL パスです。この例では、ルートパス / を使用するため、このパラメーターは空のままにします。

      • ルール: Prefix (前方一致)Exact (完全一致)、および ImplementationSpecific (デフォルト値) をサポートします。

      • サービス: ターゲットバックエンドである Kubernetes サービスです。

      • ポート: サービスが公開するポートです。

    • Ingress は、同一ドメイン名で複数のパスをサポートします。+ 追加 をクリックして新しいパスを追加します。

    • ドメイン名: demo.domain.ingress.top

    • マッピング

      • パス: /path

      • ルール:デフォルト (前方一致)

      • サービス: 転送

      • ポート: 80

    TLS 設定

    TLS で Ingress を保護するために有効にします。

    • ドメイン名:カスタムドメイン名。

    • シークレット:シークレットを選択します。シークレットを作成するには、次の手順を実行します。

    1. Secret の右側で、作成を続ける をクリックします。

    2. Secret の作成 ダイアログボックスで、シークレットの 名前[証明書]、および [キー] を指定してから、OK をクリックします。

    3. Secret ドロップダウンリストから、作成したシークレットを選択します。

    TLS 設定 をオフにします。この例では必須ではありません。

    その他

    • カナリアリリース: この機能を有効にすると、カナリアリリースを設定できます。カナリアルールは、リクエストヘッダー、 Cookie 、またはトラフィックの重みに基づいて設定できます。

      説明

      これらの条件のうち 1 つだけを設定できます。複数の条件を設定した場合、Ingress コントローラーはリクエストヘッダー、Cookie、そして重みの順で評価します。

      • リクエストヘッダーに基づく: リクエストヘッダーに基づいてトラフィックを分割します。これにより、nginx.ingress.kubernetes.io/canary-by-headernginx.ingress.kubernetes.io/canary-by-header-value、または nginx.ingress.kubernetes.io/canary-by-header-pattern アノテーションが追加されます。

      • Cookie に基づく: cookie に基づいてトラフィックを分割します。これにより、nginx.ingress.kubernetes.io/canary-by-cookie アノテーションが追加されます。

      • 重みに基づく: 指定されたサービスにルーティングされるリクエストの割合をパーセンテージ (0~100 の整数) で示します。これにより、nginx.ingress.kubernetes.io/canary-weight アノテーションが追加されます。

    • プロトコル:バックエンドサービスとの通信に使用されるプロトコル。これにより nginx.ingress.kubernetes.io/backend-protocol アノテーションが追加されます。

      HTTP、HTTPS、gRPC、および gRPCS がサポートされています。

    • 書き換えパス: バックエンドサービスに送信する前に、クライアントリクエストのパスを書き換えます。これにより、nginx.ingress.kubernetes.io/rewrite-target アノテーションが追加されます。

    カナリアリリースをオフにします。プロトコルとパスの書き換えにはデフォルト値を使用します。これらの設定はこの例では必須ではありません。

    カスタム転送ルール

    説明

    この機能はカナリアリリース中です。この機能を使用するには、チケットを送信

    このスイッチをオンにして、インバウンドトラフィックの詳細な管理を有効にします。

    説明

    転送ルールには最大 10 個の条件を追加できます。

    • 転送条件 のドロップダウンリストから、条件を選択します:

      • ドメイン名

        ドメイン名に基づいてリクエストを照合します。複数のドメイン名を指定した場合、それらの論理関係は OR です。この条件を設定すると、alb.ingress.kubernetes.io/conditions.host-example アノテーションが追加されます。

      • パス

        リクエストパスに基づいてリクエストを照合します。複数のパスを指定した場合、それらの論理関係は OR です。この条件を設定すると、alb.ingress.kubernetes.io/conditions.path-example アノテーションが追加されます。

      • HTTP ヘッダー

        リクエストヘッダーのキーと値のペアに基づいてリクエストを照合します。 たとえば、キー:headername に、値:headervalue1 に設定できます。 複数のヘッダー値を指定した場合、それらの間の論理関係は OR になります。 この条件を設定すると、alb.ingress.kubernetes.io/conditions.http-header-example アノテーションが追加されます。

    • 転送操作 ドロップダウンリストから、アクションを選択します:

      • 転送先

        複数のバックエンドサーバーグループにリクエストを転送します。サービス フィールドでターゲットサービスを選択し、ポート フィールドでターゲットポート番号を選択します。次に、カスタムの重み値を設定します。

        説明
        • クラスターが Flannel ネットワークプラグインを使用している場合、ClusterIP サービスはサポートされません。

        • [転送先] を選択した場合、ルールにパスマッピングは必要ありません。

      • 固定のレスポンスを返す

        ALB インスタンスからクライアントに固定レスポンスを返します。 応答状態コード、コンテンツ、およびコンテンツタイプを設定できます。 必要に応じて、レスポンスステータスコードレスポンスボディタイプ (オプション)、および 応答コンテンツ (オプション) パラメーターを設定します。

        レスポンスコンテンツタイプ

        • text/plain:プレーンテキストコンテンツ。

        • text/css:CSS 形式のコンテンツ。

        • text/html:HTML 形式のコンテンツ。

        • application/javascript:JavaScript 形式のコンテンツ。

        • application/json:JSON 形式のコンテンツ。

    • 転送条件[ドメイン] を選択します。ドメイン:demo.domain.ingress.top

    • 転送アクション転送先

      • サービス名:tea-svc

      • ポート:80

      • 重み:80

    • サービスの追加

      • サービス名:coffee-svc

      • ポート:80

      • 重み:20

    アノテーション

    キーと値を指定してカスタムアノテーションを追加するか、キーでアノテーションを選択または検索できます。Ingress アノテーションの詳細については、「ALB Ingress アノテーションリファレンス」をご参照ください。

    +アノテーションの追加 をクリックすると、Ingress にアノテーションを無制限に追加できます。

    このパラメーターはこの例では必須ではありません。

    ラベル

    Ingress に追加するラベルを指定します。ラベルは、識別属性を指定するためにオブジェクトにアタッチされるキーと値のペアです。

    このパラメーターはこの例では必須ではありません。

  4. 構成を完了したら、Ingress の作成 ページの左下隅にある OK をクリックします。

kubectl の使用

この YAML マニフェストは、クラスター内の複数のサービスにリクエストを転送する Ingress を定義します。

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: forward-ingress
  annotations:
  # このアノテーションの Service はクラスター内に存在し、ルールの `backend` の下の ServiceName と一致する必要があります。
    alb.ingress.kubernetes.io/actions.forward: |
       [{
           "type": "ForwardGroup",
           "ForwardConfig": {
             "ServerGroups" : [{
               "ServiceName": "tea-svc",
               "Weight": 80,
               "ServicePort": 80
             },
             {
               "ServiceName": "coffee-svc",
               "Weight": 20,
               "ServicePort": 80
             }]
           }
       }]
spec:
  ingressClassName: alb
  rules:
   - host: demo.domain.ingress.top
     http:
      paths:
      - path: /path
        pathType: Prefix
        backend:
          service:
            name: forward
            port:
              name: use-annotation # ポート名は use-annotation である必要があります。

シナリオ 6:リクエストの書き換え

このコードブロックは、リクエストのドメイン名、パス、およびクエリ文字列を書き換える Ingress を定義します。

シナリオ 7:レスポンスヘッダーの変更

重要
  • デフォルトでは、ALB Ingress のルーティングルールはインバウンド方向に適用されます。アウトバウンド方向のルーティングルールを作成するには、alb.ingress.kubernetes.io/rule-direction.<サービス名> アノテーションを Response に設定します。デフォルト値は Request です。

  • アウトバウンド方向のルーティングルールを作成する場合、ingressSpec.rules.backendservicePort フィールドを use-annotation に設定する必要があります。

次のコードブロックは、ヘッダー response-hello の値が value1 または value2 のいずれかである ResponseHeader の一致がある場合に、リクエストヘッダー source: alibaba を挿入します。

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
   alb.ingress.kubernetes.io/rule-direction.response-header: Response
   alb.ingress.kubernetes.io/conditions.response-header: |
     [{
         "type": "ResponseHeader",
         "responseHeaderConfig": {
            "key": "response-hello",
            "values": [
               "value1",
               "value2"
            ]
         }
     }]
   alb.ingress.kubernetes.io/actions.response-header: |
     [{
         "type": "InsertHeader",
         "InsertHeaderConfig": {
             "key": "source",
             "value": "alibaba",
             "valueType": "UserDefined"
         }
     }]
  name: response-header
spec:
  ingressClassName: alb
  rules:
   - http:
      paths:
      - path: /
        pathType: ImplementationSpecific
        backend:
          service:
            name: response-header
            port:
              name: use-annotation # サービスポート名は use-annotation である必要があります。

シナリオ 8:ステータスコードによるレスポンスヘッダーの変更

重要
  • デフォルトでは、カスタム ALB Ingress ルーティングルールはリクエストに適用されます。レスポンス用のルーティングルールを作成するには、alb.ingress.kubernetes.io/rule-direction.<サービス名> アノテーションを Response に設定します。デフォルトでは、このアノテーションは Request に設定されています。

  • レスポンス用のルーティングルールを作成する場合、ingressSpec.rules.backendservicePortuse-annotation である必要があります。

次のコードブロックのルールは、レスポンスステータスコードが 200 または 300 の場合にのみ、response-hello リクエストヘッダーを削除します。

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
   alb.ingress.kubernetes.io/rule-direction.response-hello: Response
   alb.ingress.kubernetes.io/conditions.response-hello: |
     [{
       "type": "ResponseStatusCode",
       "responseStatusCodeConfig": {
         "values": [
             "200",
             "300"
         ]
       }
     }]
   alb.ingress.kubernetes.io/actions.response-hello: |
     [{
         "type": "RemoveHeader",
         "RemoveHeaderConfig": {
             "key": "response-hello"
         }
     }]
  name: response-hello
spec:
  ingressClassName: alb
  rules:
   - http:
      paths:
      - path: /*
        pathType: ImplementationSpecific
        backend:
          service:
            name: response-hello
            port:
              name: use-annotation # サービスポート名は use-annotation である必要があります。