Container Service for Kubernetes:ALB Ingress の転送ルールのカスタマイズ

転送条件

説明

ドメイン名

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

alb.ingress.kubernetes.io/conditions.service-name: | # サービス名は spec.rules のバックエンドサービス名と一致する必要があります。これらの条件はそのサービスに適用されます。
  [{
      "type": "Host",
      "hostConfig": {
        "values": [
          "anno.example.com"
        ]
      }
  }]

• type：一致タイプ。ドメイン名で一致させるには、値を Host に設定します。

• hostConfig：一致させるドメイン名。複数のドメイン名を指定した場合、それらは OR 論理で評価されます。

パス

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

alb.ingress.kubernetes.io/conditions.service-name: | # サービス名は spec.rules のバックエンドサービス名と一致する必要があります。これらの条件はそのサービスに適用されます。
  [{
    "type": "Path",
    "pathConfig": {
      "values": [
        "/pathvalue1",
        "/pathvalue2"
      ]
    }
  }]

• type：一致タイプ。リクエストパスと一致させるには、値を Path に設定します。

• pathConfig：一致させるパス。複数のパスを指定した場合、それらは OR 論理で評価されます。

ヘッダー

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

alb.ingress.kubernetes.io/conditions.service-name: | # サービス名は spec.rules のバックエンドサービス名と一致する必要があります。これらの条件はそのサービスに適用されます。
  [{
    "type": "Header",
    "headerConfig": {
      "key": "headername",
      "values": [
        "headervalue1",
        "headervalue2"
      ]
     }
  }]

• type：一致タイプ。リクエストヘッダーと一致させるには、Header に設定します。

• headerConfig：ヘッダーのキーと値。複数のヘッダー値を指定した場合、それらは OR 論理で評価されます。

クエリ文字列

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

alb.ingress.kubernetes.io/conditions.service-name: | # サービス名は spec.rules のバックエンドサービス名と一致する必要があります。これらの条件はそのサービスに適用されます。
  [{
    "type": "QueryString",
    "queryStringConfig": {
      "values": [
        {
           "key":"querystringkey1",
           "value":"querystringvalue2"
        }
      ]
    }
  }]

• type：一致タイプ。リクエストのクエリ文字列と一致させるには、値を QueryString に設定します。

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

ユースケースと例については、「ユースケース 3：クエリ文字列、複数のヘッダー、複数のパスに基づくトラフィックのルーティング」をご参照ください。

リクエストメソッド

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

alb.ingress.kubernetes.io/conditions.service-name: | # サービス名は spec.rules のバックエンドサービス名と一致する必要があります。これらの条件はそのサービスに適用されます。
  [{
    "type": "Method",
    "methodConfig": {
      "values": [
        "GET",
        "HEAD"
      ]
    }
  }]

• type：一致タイプ。リクエストメソッドと一致させるには、これを Method に設定します。

• methodConfig：リクエストメソッド。サポートされている値：GET、POST、PUT、DELETE、HEAD、OPTIONS、PATCH。複数のメソッドを指定した場合、それらは OR 論理で評価されます。

Cookie

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

alb.ingress.kubernetes.io/conditions.service-name: | # サービス名は spec.rules のバックエンドサービス名と一致する必要があります。これらの条件はそのサービスに適用されます。
  [{
    "type": "Cookie",
    "cookieConfig": {
      "values": [
        {
           "key":"cookiekey1",
           "value":"cookievalue2"
        }
      ]
     }
  }]

• type：一致タイプ。Cookie と一致させるには、値を Cookie に設定します。

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

ユースケースと例については、「ユースケース 2：ドメイン名、リクエストメソッド、Cookie に基づくトラフィックのルーティング」をご参照ください。

ソース IP

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

alb.ingress.kubernetes.io/conditions.service-name: | # サービス名は spec.rules のバックエンドサービス名と一致する必要があります。これらの条件はそのサービスに適用されます。
  [{
    "type": "SourceIp",
    "sourceIpConfig": {
      "values": [
        "192.168.0.0/16",
        "172.16.0.0/16"
      ]
    }
  }]

• type：一致タイプ。リクエストのソース IP と一致させるには、値を SourceIP に設定します。

• sourceIpConfig：ソース IP アドレスまたは CIDR ブロック。複数の IP アドレスまたは CIDR ブロックを指定した場合、それらは OR 論理で評価されます。

ユースケースと例については、「ユースケース 1：ソース IP とヘッダーに基づくトラフィックのルーティング」をご参照ください。

レスポンスヘッダー

レスポンスヘッダーを照合し、正しいヘッダーを含むレスポンスに対してのみ転送アクションを実行します。これは alb.ingress.kubernetes.io/rule-direction.<service-name>: Response アノテーションと組み合わせて使用する必要があることに注意してください。以下に例を示します。

alb.ingress.kubernetes.io/conditions.service-name: | # サービス名は spec.rules のバックエンドサービス名と一致する必要があります。これらの条件はそのサービスに適用されます。
  [{
    "type": "ResponseHeader",
    "headerConfig": {
      "key": "headername",
      "values": [
        "headervalue1",
        "headervalue2"
      ]
     }
  }]

• type：条件タイプ。レスポンス内のヘッダーと一致させるには、これを ResponseHeader に設定します。

• headerConfig：ヘッダーのキーと値。複数のヘッダー値を指定した場合、それらは OR 論理で評価されます。

レスポンスステータスコード

レスポンスステータスコードを照合します。サービスには、正しいステータスコードが返された場合にのみアクセスできます。この機能は、レスポンス方向の転送アクションとレスポンス方向の転送ルールアノテーション alb.ingress.kubernetes.io/rule-direction.<service-name>: Response と組み合わせて使用する必要があることに注意してください。以下に例を示します。

alb.ingress.kubernetes.io/conditions.service-name: | # サービス名は spec.rules のバックエンドサービス名と一致する必要があります。これらの条件はそのサービスに適用されます。
  [{
    "type": "ResponseStatusCode",
    "responseStatusCodeConfig": {
      "values": [
        "statuscode1",
        "statuscode2"
      ]
    }
  }]

• type：一致タイプ。レスポンスステータスコードと一致させるには、ResponseStatusCode に設定します。

• responseStatusCodeConfig：レスポンスステータスコード。複数のステータスコードを指定した場合、それらは OR 論理で評価されます。

アクション

説明

固定レスポンス

Application Load Balancer (ALB) からクライアントに固定レスポンスを送信します。レスポンスのステータスコード、コンテンツ、コンテンツタイプを設定できます。以下のコードは例です。

alb.ingress.kubernetes.io/actions.service-name: | # 注：このアノテーションの "service-name" は、spec.rules で設定されたバックエンドサービスの名前と一致する必要があります。転送アクションはそのバックエンドサービスに適用されます。
  [{
      "type": "FixedResponse",
      "FixedResponseConfig": {
          "contentType": "text/plain",
          "httpCode": "503",
          "content": "503 error text"
      }
  }]

• type：転送アクションのタイプ。このアクションでは FixedResponse に設定します。

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

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

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

ユースケースと例については、「ユースケース 1：固定レスポンスの設定」をご参照ください。

リダイレクト

alb.ingress.kubernetes.io/actions.service-name: | # 注：このアノテーションの "service-name" は、spec.rules で設定されたバックエンドサービスの名前と一致する必要があります。転送アクションはそのバックエンドサービスに適用されます。
  [{
      "type": "Redirect",
      "RedirectConfig": {
          "host": "${host}",
          "path": "/test",
          "port": "443",
          "protocol": "https",
          "query": "querystring",
          "httpCode": "301"
      }
  }]

• type：転送アクションのタイプ。このアクションでは Redirect に設定します。

• host：リクエストがリダイレクトされるホスト。

• path：リクエストがリダイレクトされるパス。

• port：リクエストがリダイレクトされるポート。

• protocol：リクエストがリダイレクトされるプロトコル。

• query：リダイレクトされたリクエストのクエリ文字列。

• httpCode：リダイレクト後に返されるステータスコード。

ユースケースと例については、「ユースケース 2：301 リダイレクトの使用」をご参照ください。

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

リクエストをコピーし、トラフィックミラーリングサーバーグループに転送します。サーバーグループの ID を指定する必要があります。以下のコードは例です。

alb.ingress.kubernetes.io/actions.service-name: | # 注：このアノテーションの "service-name" は、spec.rules で設定されたバックエンドサービスの名前と一致する必要があります。転送アクションはそのバックエンドサービスに適用されます。
      [{
          "type": "TrafficMirror",
          "TrafficMirrorConfig": {
              "TargetType" : "ForwardGroupMirror",
              "MirrorGroupConfig": {
                  "ServerGroupTuples" : [{
                      "ServerGroupID": "sgp-2auud2fxj1r46*****"
                  }]
              }
           }
      }]

• type：転送アクションのタイプ。トラフィックミラーリングを設定するには、これを TrafficMirror に設定します。

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

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

ユースケースと例については、「ユースケース 4：トラフィックのミラーリング」をご参照ください。

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

ALB リクエストを複数のバックエンドサーバーグループに転送します。ServerGroupID を使用してバックエンドサーバーグループを指定するか、ServiceName+ServicePort を使用してサーバーグループを作成またはアタッチできます。また、各バックエンドサーバーグループに転送の重みを設定し、サーバーグループ間のセッション維持を有効にすることもできます。

alb.ingress.kubernetes.io/actions.service-name: | # 注：このアノテーションの "service-name" は、spec.rules で設定されたバックエンドサービスの名前と一致する必要があります。転送アクションはそのバックエンドサービスに適用されます。
       [{
           "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
             }],
             "ServerGroupStickySession": {
              "Enabled": true,
              "Timeout": 80
             }
           }
       }]

• type：転送アクションのタイプ。複数のバックエンドサーバーグループへの転送を設定するには、これを ForwardGroup に設定します。

• ForwardConfig：バックエンドサーバーグループのパラメーター。複数のサーバーグループを設定した場合、リクエストは各サーバーグループの重みに基づいて転送されます。

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

• ServiceName：サービスの名前。

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

• Weight：各サーバーグループにリクエストを転送するための重み。

• Enabled：サーバーグループ間のセッション維持を有効にするかどうかを指定します。

• Timeout：サーバーグループ間のセッション維持のタイムアウト期間。

ユースケースと例については、「ユースケース 5：複数のサーバーグループへの転送」をご参照ください。

書き換え

バックエンドに転送する前にリクエストを書き換えます。Application Load Balancer (ALB) は、リクエストのホスト、パス、クエリ文字列を変更できます。

alb.ingress.kubernetes.io/actions.service-name: | # 注：このアノテーションの "service-name" は、spec.rules で設定されたバックエンドサービスの名前と一致する必要があります。転送アクションはそのバックエンドサービスに適用されます。
       [{
           "type": "Rewrite",
           "RewriteConfig": {
               "Host": "demo.domain.ingress.top",
               "Path": "/test",
               "Query": "querystring"
           }
       }]

• type：転送アクションのタイプ。書き換え機能を使用するには、これを Rewrite に設定します。

• host：書き換えられたリクエストで使用されるホスト。これを ${host} に設定するか、空のままにするか ("host": "")、またはパラメーターを含めない場合、元のリクエストの値が使用されます。

• path：書き換えられたリクエストで使用されるパス。これを ${path} に設定するか、空のままにするか ("path": "")、またはパラメーターを含めない場合、元のリクエストの値が使用されます。

• query：書き換えられたリクエストのクエリ文字列。これを ${query} に設定するか、空のままにするか ("query": "")、またはパラメーターを含めない場合、元のリクエストの値が使用されます。

ユースケースと例については、「ユースケース 6：リクエストの書き換え」をご参照ください。

ヘッダーの挿入

ヘッダーフィールド名とコンテンツを設定します。これにより、リクエスト内の同じ名前の既存のヘッダーが上書きされます。以下のコードは例です。

alb.ingress.kubernetes.io/actions.service-name: | # 注：このアノテーションの "service-name" は、spec.rules で設定されたバックエンドサービスの名前と一致する必要があります。転送アクションはそのバックエンドサービスに適用されます。
  [{
      "type": "InsertHeader",
      "InsertHeaderConfig": {
          "key": "key",
          "value": "value",
          "valueType": "UserDefined"
      }
  }]

• type：転送アクションのタイプ。リクエストヘッダーを挿入するには、これを InsertHeader に設定します。

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

• value：ヘッダーフィールドのコンテンツ。

• valueType：値のタイプ。

ユースケースと例については、「ユースケース 3：リクエストヘッダーの挿入」をご参照ください。

ヘッダーの削除

リクエストからヘッダーを削除します。以下のコードは例です。

alb.ingress.kubernetes.io/actions.service-name: | # 注：このアノテーションの "service-name" は、spec.rules で設定されたバックエンドサービスの名前と一致する必要があります。転送アクションはそのバックエンドサービスに適用されます。
     [{
         "type": "RemoveHeader",
         "RemoveHeaderConfig": {
             "key": "key"
         }
     }]

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

key：削除するヘッダーフィールドの名前。

QPS 制限

このアクションは、リクエストレートを秒間クエリ数 (QPS) で制限します。全体的な制限と、クライアントのソース IP ごとの個別の制限を設定できます。

以下のコードは設定例です：

 annotations:
    alb.ingress.kubernetes.io/actions.service-name: | # 注：このアノテーションの "service-name" は、spec.rules で設定されたバックエンドサービスの名前と一致する必要があります。転送アクションはそのバックエンドサービスに適用されます。
      [{
          "type": "TrafficLimit",
          "TrafficLimitConfig": {
              "QPS": "1000",
              "QPSPerIp": "100"
          }
      }]

• type：転送アクションのタイプを指定します。レート制限を設定するには、これを TrafficLimit に設定します。

• QPS：秒間クエリ数 (QPS) での全体的なリクエストレート制限。値は 1～1,000,000 の範囲である必要があります。リクエストレートが指定された制限を超えると、超過したリクエストは拒否され、クライアントは HTTP 503 ステータスコードを受け取ります。

• QPSPerIp：クライアントのソース IP ごとのリクエストレート制限 (QPS)。値は 1～1,000,000 の範囲である必要があります。QPS (全体制限) と QPSPerIp (IP ごとの制限) の両方が設定されている場合、QPSPerIp の値は QPS の値より小さくなければなりません。単一の IP アドレスからのリクエストレートが指定された制限を超えると、超過したリクエストは拒否され、クライアントは HTTP 503 ステータスコードを受け取ります。

アクション

説明

ヘッダーの挿入

レスポンスルールに適用されると、このアクションはレスポンスにヘッダーフィールドとその値を設定します。これにより、同じ名前の既存のレスポンスヘッダーが上書きされます。以下のコードは例です。

alb.ingress.kubernetes.io/actions.service-name: | # 注：このアノテーションの "service-name" は、spec.rules で設定されたバックエンドサービスの名前と一致する必要があります。転送アクションはそのバックエンドサービスに適用されます。
  [{
      "type": "InsertHeader",
      "InsertHeaderConfig": {
          "key": "key",
          "value": "value",
          "valueType": "UserDefined"
      }
  }]

• type：転送アクションのタイプ。レスポンスヘッダーを挿入するには、これを InsertHeader に設定します。

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

• value：ヘッダーフィールドのコンテンツ。

• valueType：値のタイプ。

レスポンスヘッダーの変更に関するユースケースと例については、「ユースケース 7：レスポンスヘッダーの変更」および「ユースケース 8：ステータスコードによるレスポンスヘッダーの変更」をご参照ください。

ヘッダーの削除

レスポンスルールに適用されると、このアクションはレスポンスからヘッダーを削除します。以下のコードは例です。

alb.ingress.kubernetes.io/actions.service-name: | # 注：このアノテーションの "service-name" は、spec.rules で設定されたバックエンドサービスの名前と一致する必要があります。転送アクションはそのバックエンドサービスに適用されます。
     [{
         "type": "RemoveHeader",
         "RemoveHeaderConfig": {
             "key": "key"
         }
     }]

type：転送アクションのタイプ。レスポンスヘッダーを削除するには、これを RemoveHeader に設定します。

key：削除するヘッダーフィールドの名前。