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

Container Compute Service:ALB Ingress のルーティング規則のカスタマイズ

最終更新日:Jan 17, 2025

Application Load Balancer (ALB) Ingress を使用すると、カスタムルーティング規則を構成できます。ルーティング規則は、ルーティング条件と操作で構成されます。リクエスト内のドメイン名、パス、リクエストヘッダー、クエリ文字列、リクエストメソッド、Cookie、または送信元 IP アドレスに一致するルーティング条件を追加できます。また、固定のレスポンスを返す、リクエストをリダイレクトする、リクエストヘッダーを挿入する、リクエストヘッダーを削除する、トラフィックをミラーリングする、複数のバックエンドサーバーグループにリクエストを転送する、またはリクエストを書き換えるルーティング操作を追加することもできます。このトピックでは、ALB Ingress のルーティング規則をカスタマイズする方法について説明します。

前提条件

ALB Ingress コントローラー 2.5.0 以降がクラスターにインストールされています。詳細については、「コンポーネントの管理」をご参照ください。

説明

ALB コンソールで ALB Ingress のカスタムルーティング規則を構成できます。この機能はカナリーリリースされています。この機能を使用するには、チケットを送信する 必要があります。

ルーティング条件

重要
  • 1 つのルーティング規則には最大 10 個のルーティング条件を追加できます。

  • ルーティング条件 ResponseHeader および ResponseStatusCode は、カスタムアウトバウンドルーティング規則でのみ有効です。

ルーティング条件の概要

ALB Ingress を使用すると、alb.ingress.kubernetes.io/conditions.<サービス名> アノテーションでルーティング条件を構成できます。異なるルールブロック間の論理関係は AND です。1 つのルールブロックで複数の値が指定されている場合、値間の論理関係は OR です。たとえば、2 つのヘッダールールブロックを構成する場合、2 つのヘッダールールブロック間の論理関係は AND です。ヘッダールールブロックで複数のヘッダーを構成する場合、ヘッダー間の論理関係は OR です。次の表に、ALB Ingress に作成できるルーティング規則を示します。

ルーティング条件

説明

ドメイン名

指定されたドメイン名宛てのリクエストのみをルーティングするために、この条件を追加できます。次のサンプルコードは、テンプレートの例を示しています。

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

  • HostConfig: リクエストの照合に使用されるドメイン名。複数のドメイン名を指定した場合、ドメイン名間の論理関係は OR です。

リクエストがリダイレクトされる URL

指定されたパスに送信されたリクエストのみをルーティングするために、この条件を追加できます。次のサンプルコードは、テンプレートの例を示しています。

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: リクエストの照合に使用されるキーと値のペア。キーと値の長さは 1 ~ 100 文字で、小文字、表示可能な文字、アスタリスク (*)、疑問符 (?) を使用できます。キーと値には、スペース文字または次の特殊文字を含めることはできません: # [] {} \ | <> &。複数の Cookie を指定した場合、Cookie 間の論理関係は 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 アドレス。複数の送信元 IP アドレスを指定した場合、送信元 IP アドレス間の論理関係は 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 つの送信元 IP アドレスを追加できます。

次のコードブロックは、送信元 IP アドレス、リクエストヘッダー、およびパスに基づいてパケットをルーティングするために使用されます。

次のコードブロックでは、送信元 IP アドレスは 192.168.0.0/16 と 172.16.0.0/16 に設定され、ヘッダーキーは gray-hello に設定され、ヘッダー値は value1value2 に設定され、パスは /hello に設定されています。送信元 IP アドレス、ヘッダー、およびパスが上記のすべての条件に一致するリクエストのみが gray-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 に基づいてトラフィックをルーティングする

次のコードブロックは、ドメイン名、リクエストメソッド、および Cookie に基づいてパケットをルーティングするために使用されます。

次のコードブロックでは、リクエストメソッドは GETHEAD に設定され、ドメイン名は www.hostvalue1.eduwww.hostvalue2.edu に設定され、Cookie のキーは cookiekey1 に設定され、Cookie の値は cookievalue1 に設定され、パスは /test に設定されています。ドメイン名、リクエストメソッド、Cookie、およびパスが上記のすべての条件に一致するリクエストのみが gray-hello サービスにルーティングされます。その他のリクエストは 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: クエリ文字列、複数のリクエストヘッダー、および複数のパスに基づいてトラフィックをルーティングする

次のコードブロックでは、パケットはクエリ文字列、リクエストヘッダー、およびパスに基づいてルーティングされます。

次のコードブロックでは、パスは /pathvalue1/pathvalue2、および /test に設定され、クエリ文字列キーは querystringkey1 に設定され、クエリ文字列値は querystringvalue2 に設定されています。さらに、コードブロックでは、リクエストに headerkey1headerkey2 が含まれている必要があることが指定されています。headerkey1 のヘッダー値は headervalue1 または headervalue2 である必要があり、headervalue2 のヘッダー値は 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 を使用すると、必要に応じてリクエストとレスポンスを処理するために、さまざまなルーティング操作を定義できます。

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

  • 同じルーティング規則では、複数の終了操作を同時に追加することはできません。たとえば、固定のレスポンスを返す、リクエストをリダイレクトする、または複数のバックエンドサーバーグループにリクエストを転送するルーティング操作を同時に追加することはできません。

  • 固定のレスポンスを返す、リクエストをリダイレクトする、または複数のバックエンドサーバーグループにリクエストを転送するルーティング操作を追加する場合、サービスポートrule フィールドの backend で指定された servicePort の名前は、use-annotation である必要があります。

インバウンドルーティング規則のルーティング操作

ルーティング操作

説明

固定のレスポンスを返す

クライアントに固定のコンテンツを返すように ALB Ingress を構成できます。クライアントに返されるステータスコード、コンテンツ、およびコンテンツのタイプを指定できます。次のサンプルコードは、テンプレートの例を示しています。

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 ステータスコードを使用して、リクエストを他のサービスアドレスにリダイレクトできます。次のサンプルコードは、テンプレートの例を示しています。

重要

httpCode 以外のすべてのリダイレクトパラメーターにデフォルト設定を同時に保持することはできません。

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: リダイレクトされたリクエストのステータスコード。

トラフィックをミラーリングする

トラフィックをミラーリングするサーバーグループの ID を指定できます。次のサンプルコードは、テンプレートの例を示しています。

重要
  • トラフィックミラーリング操作は、リクエストの転送、ヘッダーの書き込み、ヘッダーの削除、およびトラフィックの調整に使用される操作と組み合わせてのみ使用できます。この操作は、リクエストの書き換え、固定のレスポンスの返却、およびリクエストのリダイレクトに使用される操作と相互に排他的です。

  • ServerGroupID パラメーターのみを使用して、トラフィックがミラーリングされるサーバーグループを指定できます。

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

  • TargetType: トラフィックがミラーリングされる宛先のタイプ。トラフィックを指定されたサーバーグループにミラーリングするには、値を ForwardGroupMirror に設定します。

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

複数のバックエンドサーバーグループにリクエストを転送する

複数のバックエンドサーバーグループにリクエストを転送するには、ServerGroupID フィールドを設定してサーバーグループ ID を指定するか、ServiceName と ServicePort フィールドを設定してサーバーグループを作成または関連付ける必要があります。また、各バックエンドサーバーグループの重みを指定することもできます。次のサンプルコードは、テンプレートの例を示しています。

重要
  • 標準の 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: ALB インスタンスを使用して公開されるサービスの名前。

  • ServicePort: サービスポート。

  • Weight: サーバーグループの重み。

リクエストを書き換える

ALB インスタンスの書き換え規則を構成すると、リクエストのドメイン名、パス、およびクエリ文字列が書き換えられます。

重要
  • 書き換え操作は、rewrite-target アノテーションと競合します。書き換え操作を構成する場合は、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 スロットリング

ALB インスタンスの転送規則を構成する場合、グローバルリクエストレート制限と、クライアント IP アドレスに基づくリクエストレート制限を設定できます。

サンプルコード:

重要
  • 1 秒あたりのクエリ数 (QPS) スロットリング操作は、サーバーグループへのリクエスト転送操作と組み合わせて使用する必要があります。

  • X-Forwarded-For ヘッダーに複数の IP アドレス (X-Forwarded-For: <client-ip-address>, <proxy1>, <proxy2>, ... など) が含まれている場合、左端のアドレスがクライアント IP アドレスになります。クライアント IP アドレスに基づいてリクエストレート制限を構成する場合は、リスナー詳細ページでクライアント IP アドレスを取得するためのスイッチをオンにする必要があります。このようにして、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 と固定のコンテンツを返す

ACS コンソールの使用

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

  2. [クラスター] ページで、管理するクラスターを見つけて、その ID をクリックします。クラスター詳細ページの左側のナビゲーションウィンドウで、[ネットワーク] > [ingress] を選択します。

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

    パラメーター

    説明

    ゲートウェイタイプ

    ビジネス要件に基づいて、ALB または MSE Ingress を選択できます。

    ALB

    アプリケーション名

    Ingress の名前を指定します。

    ingress

    Ingress クラス

    Ingress のクラスを指定します。

    alb

    リスナー/ポート

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

    HTTP:80

    ルール

    [+ルールの追加] をクリックして、Ingress ルールを追加します。

    • ドメイン名: カスタムドメイン名を入力します。

    • マッピング: 次のパラメーターを指定します。

      • パス: バックエンドサービスの URL パスを入力します。この例では、ルートパス / が使用されます。

      • ルール: [プレフィックス (プレフィックスベースの照合)][完全一致 (完全一致)]、または [implementationspecific (デフォルト値)] を選択できます。

      • サービス: バックエンドサービスを選択します。

      • ポート: 公開するサービスポートを指定します。

    • ドメイン名に複数のパスを構成できます。[+ 追加] をクリックして、パスを追加します。

    • ドメイン名: このパラメーターは空のままにします。

    • マッピング:

      • パス: /

      • ルール: プレフィックス (プレフィックスベースの照合) がデフォルトで選択されています。

      • サービス: response-503

      • ポート: 80.

    TLS 設定

    TLS 認証を有効にするかどうかを指定します。Ingress の TLS 認証を有効にできます。

    • ドメイン名: カスタムドメイン名を入力します。

    • シークレット: クラスターで使用されるシークレット。ビジネス要件に基づいてシークレットを選択します。

    [TLS 設定] をオフにします。この例では、TLS 証明書を構成する必要はありません。

    詳細

    • カナリーリリース: カナリーリリースを有効にします。リクエストヘッダー、Cookie、および重みに基づいてカナリーリリースルールを構成できます。

      説明

      リクエストヘッダー、Cookie、および重みのいずれか 1 つの要素のみに基づいてカナリーリリースルールを構成できます。また、リクエストヘッダー、Cookie、および重みに基づいてカナリーリリースルールを同時に構成することもできます。この場合、リクエストヘッダー、Cookie、および重みは、優先順位の高い順に有効になります。

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

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

      • 重みに基づく: nginx.ingress.kubernetes.io/canary-weight アノテーションを追加することにより、サービスの重み (0 ~ 100 の整数) に基づいてトラフィックを分散します。

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

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

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

    カナリーリリースをオフにします。プロトコルとパスの書き換えパラメーターのデフォルト値を使用します。この例では、これらのパラメーターを構成する必要はありません。

    カスタム転送ルール

    説明

    ALB コンソールで ALB Ingress のカスタムルーティング規則を構成できます。この機能はカナリーリリースされています。この機能を使用するには、チケットを送信する 必要があります。

    カスタム転送ルールを有効にして、インバウンドトラフィックをきめ細かく管理できます。

    説明

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

    • [条件の追加] ドロップダウンリストでは、次の条件タイプを使用できます。

      • ドメイン名:

        指定された 1 つ以上のドメイン名を含むリクエストのみがルーティングされます。複数のドメイン名間の論理関係は OR です。ドメイン名を指定すると、システムは alb.ingress.kubernetes.io/conditions.host-example アノテーションを追加します。

      • パス:

        指定された 1 つ以上のパスを含むリクエストのみがルーティングされます。複数のパス間の論理関係は OR です。パスを指定すると、システムは alb.ingress.kubernetes.io/conditions.path-example アノテーションを追加します。

      • HTTP ヘッダー:

        指定された 1 つ以上の HTTP ヘッダーを含むリクエストのみがルーティングされます。各 HTTP リクエストヘッダーはキーと値のペアです。たとえば、キーheadername に、headervalue1 に設定できます。複数のヘッダー値を指定した場合、ヘッダー値間の論理関係は OR です。ヘッダーを指定すると、システムは alb.ingress.kubernetes.io/conditions.http-header-example アノテーションを追加します。

    • [操作] ドロップダウンリストでは、次の操作を使用できます。

      • 転送先

        インバウンドトラフィックを複数のバックエンドサーバーグループに転送します。インバウンドトラフィックを転送するには、次の操作を実行します。[サービス] ドロップダウンリストからアクセスするサービスを選択します。[ポート] ドロップダウンリストからサービスへの接続に使用するポートを選択します。各バックエンドサーバーグループのカスタムの重みを指定します。

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

        • [操作] ドロップダウンリストから [転送先] を選択した場合、ルールの [マッピング] パラメーターを構成する必要はありません。

      • 固定レスポンスを返す

        ALB インスタンスがクライアントに固定のコンテンツを返すように指定します。クライアントに返されるステータスコード、コンテンツ、およびコンテンツのタイプを指定できます。ビジネス要件に基づいて、[レスポンスステータスコード][レスポンスコンテンツタイプ (オプション)]、および [レスポンスコンテンツ (オプション)] パラメーターを構成します。

        [レスポンスコンテンツタイプ] パラメーターの有効な値:

        • text/plain: コンテンツがプレーンテキストであることを示します。

        • text/css: コンテンツが XML 形式であることを示します。

        • text/html: コンテンツが HTML 形式であることを示します。

        • application/javascript: コンテンツが JavaScript 形式であることを示します。

        • application/json: コンテンツが JSON 形式であることを示します。

    カスタム転送ルールでは、複数の条件と操作を指定できます。ドメイン名、パス、および HTTP リクエストヘッダーを転送条件として構成し、インバウンドトラフィックをバックエンドサーバーグループに転送したり、クライアントに固定のコンテンツを返したりできます。

    • [条件の追加] ドロップダウンリストでは、[パス] がデフォルトで選択されています。(デフォルト設定を保持)

    • [操作] ドロップダウンリストでは、[固定レスポンスを返す] が選択されています。

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

      • レスポンスコンテンツタイプ (オプション): text/plain

      • レスポンスコンテンツ (オプション): error

    アノテーション

    カスタムアノテーション名と値を入力できます。ドロップダウンリストから名前でアノテーションを選択または検索することもできます。Ingress アノテーションの詳細については、「ALB Ingress GlobalConfiguration ディクショナリ」をご参照ください。

    [+アノテーションの追加] をクリックして、アノテーションを追加します。ACS は、追加できる Ingress アノテーションの数に制限を設けていません。

    この例では、アノテーションを構成する必要はありません。

    ラベル

    Ingress の特性を説明するラベルを追加できます。

    [+ラベルの追加] をクリックして、ラベルを追加します。追加できる Ingress ラベルの数に制限はありません。

    この例では、ラベルを構成する必要はありません。

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

kubectl

次のコードブロックは、ステータスコード 503 と 503 error text を返すために使用されます。

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 # サービスポートの名前は use-annotation である必要があります。

シナリオ 2: 301 リダイレクトを使用してリクエストを HTTPS ポートにリダイレクトする

次のコードブロックは、リクエストを 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:
  # アノテーションで指定されたサービスは、クラスター内の既存のサービスである必要があり、サービス名は rule フィールドの 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: トラフィックをサーバーグループにミラーリングする

次のコードブロックは、トラフィックを指定されたサーバーグループにミラーリングするために使用されます。

サーバーロードバランサー (SLB) コンソール にログインします。左側のナビゲーションウィンドウで、[ALB] > サーバーグループ を選択します。[サーバーグループ] ページで、サーバーグループの ID を表示できます。服务器组

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: traffic-mirror-ingress
  annotations:
  # アノテーションで指定されたサービスは、クラスター内の既存のサービスである必要があり、サービス名は rule フィールドの backend で指定されたサービス名と同じである必要があります。
   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: 複数のバックエンドサーバーグループにリクエストを転送する

ACS コンソールの使用

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

  2. [クラスター] ページで、管理するクラスターを見つけて、その ID をクリックします。クラスター詳細ページの左側のナビゲーションウィンドウで、[ネットワーク] > [ingress] を選択します。

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

    パラメーター

    説明

    ゲートウェイタイプ

    ビジネス要件に基づいて、ALB または MSE Ingress を選択できます。

    ALB

    アプリケーション名

    Ingress の名前を指定します。

    forward-ingress

    Ingress クラス

    Ingress のクラスを指定します。

    alb

    リスナー/ポート

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

    HTTP:80

    ルール

    [+ルールの追加] をクリックして、Ingress ルールを追加します。

    • ドメイン名: カスタムドメイン名を入力します。

    • マッピング: 次のパラメーターを指定します。

      • パス: バックエンドサービスの URL パスを入力します。この例では、ルートパス / が使用されます。

      • ルール: [プレフィックス (プレフィックスベースの照合)][完全一致 (完全一致)]、または [implementationspecific (デフォルト値)] を選択できます。

      • サービス: バックエンドサービスを選択します。

      • ポート: 公開するサービスポートを指定します。

    • ドメイン名に複数のパスを構成できます。[+ 追加] をクリックして、パスを追加します。

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

    • マッピング:

      • パス: /path

      • ルール: プレフィックス (プレフィックスベースの照合) がデフォルトで選択されています。

      • サービス: forward

      • ポート: 80.

    TLS 設定

    TLS 認証を有効にするかどうかを指定します。Ingress の TLS 認証を有効にできます。

    • ドメイン名: カスタムドメイン名を入力します。

    • シークレット: クラスターで使用されるシークレット。ビジネス要件に基づいてシークレットを選択します。シークレットを作成する場合は、次の手順を実行します。

    1. [シークレット] の右側にある [作成] をクリックします。

    2. [シークレットの作成] ダイアログボックスで、[名前][証明書]、および [キー] パラメーターを構成します。次に、[OK] をクリックします。

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

    [TLS 設定] をオフにします。この例では、TLS 証明書を構成する必要はありません。

    詳細

    • カナリーリリース: カナリーリリースを有効にします。リクエストヘッダー、Cookie、および重みに基づいてカナリーリリースルールを構成できます。

      説明

      リクエストヘッダー、Cookie、および重みのいずれか 1 つの要素のみに基づいてカナリーリリースルールを構成できます。また、リクエストヘッダー、Cookie、および重みに基づいてカナリーリリースルールを同時に構成することもできます。この場合、リクエストヘッダー、Cookie、および重みは、優先順位の高い順に有効になります。

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

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

      • 重みに基づく: nginx.ingress.kubernetes.io/canary-weight アノテーションを追加することにより、サービスの重み (0 ~ 100 の整数) に基づいてトラフィックを分散します。

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

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

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

    カナリーリリースをオフにします。プロトコルとパスの書き換えパラメーターのデフォルト値を使用します。この例では、これらのパラメーターを構成する必要はありません。

    カスタム転送ルール

    説明

    ALB コンソールで ALB Ingress のカスタムルーティング規則を構成できます。この機能はカナリーリリースされています。この機能を使用するには、チケットを送信する 必要があります。

    カスタム転送ルールを有効にして、インバウンドトラフィックをきめ細かく管理できます。

    説明

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

    • [条件の追加] ドロップダウンリストでは、次の条件タイプを使用できます。

      • ドメイン名:

        指定された 1 つ以上のドメイン名を含むリクエストのみがルーティングされます。複数のドメイン名間の論理関係は OR です。ドメイン名を指定すると、システムは alb.ingress.kubernetes.io/conditions.host-example アノテーションを追加します。

      • パス:

        指定された 1 つ以上のパスを含むリクエストのみがルーティングされます。複数のパス間の論理関係は OR です。パスを指定すると、システムは alb.ingress.kubernetes.io/conditions.path-example アノテーションを追加します。

      • HTTP ヘッダー:

        指定された 1 つ以上の HTTP ヘッダーを含むリクエストのみがルーティングされます。各 HTTP リクエストヘッダーはキーと値のペアです。たとえば、キーheadername に、headervalue1 に設定できます。複数のヘッダー値を指定した場合、ヘッダー値間の論理関係は OR です。ヘッダーを指定すると、システムは alb.ingress.kubernetes.io/conditions.http-header-example アノテーションを追加します。

    • [操作] ドロップダウンリストでは、次の操作を使用できます。

      • 転送先

        インバウンドトラフィックを複数のバックエンドサーバーグループに転送します。インバウンドトラフィックを転送するには、次の操作を実行します。[サービス] ドロップダウンリストからアクセスするサービスを選択します。[ポート] ドロップダウンリストからサービスへの接続に使用するポートを選択します。各バックエンドサーバーグループのカスタムの重みを指定します。

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

        • [操作] ドロップダウンリストから [転送先] を選択した場合、ルールの [マッピング] パラメーターを構成する必要はありません。

      • 固定レスポンスを返す

        ALB インスタンスがクライアントに固定のコンテンツを返すように指定します。クライアントに返されるステータスコード、コンテンツ、およびコンテンツのタイプを指定できます。ビジネス要件に基づいて、[レスポンスステータスコード][レスポンスコンテンツタイプ (オプション)]、および [レスポンスコンテンツ (オプション)] パラメーターを構成します。

        [レスポンスコンテンツタイプ] パラメーターの有効な値:

        • text/plain: コンテンツがプレーンテキストであることを示します。

        • text/css: コンテンツが XML 形式であることを示します。

        • text/html: コンテンツが HTML 形式であることを示します。

        • application/javascript: コンテンツが JavaScript 形式であることを示します。

        • application/json: コンテンツが JSON 形式であることを示します。

    カスタム転送ルールでは、複数の条件と操作を指定できます。ドメイン名、パス、および HTTP リクエストヘッダーを転送条件として構成し、インバウンドトラフィックをバックエンドサーバーグループに転送したり、クライアントに固定のコンテンツを返したりできます。

    • [条件の追加] ドロップダウンリストでは、[ドメイン名] が選択されています。ドメイン名: demo.domain.ingress.top

    • [操作] ドロップダウンリストでは、[転送先] が選択されています。

      • サービス: tea-svc

      • ポート: 80.

      • 重み: 80

    • サービスの追加

      • サービス: coffee-svc

      • ポート: 80.

      • 重み: 20

    アノテーション

    カスタム アノテーション名と値を入力できます。また、ドロップダウン リストから名前でアノテーションを選択または検索することもできます。Ingress アノテーションの詳細については、「ALB Ingress GlobalConfiguration ディクショナリ」をご参照ください。

    [+アノテーションの追加] をクリックして、アノテーションを追加します。ACS は、追加できる Ingress アノテーションの数に制限を設けていません。

    この例では、アノテーションを構成する必要はありません。

    ラベル

    Ingress の特性を説明するラベルを追加できます。

    [+ラベルの追加] をクリックして、ラベルを追加します。追加できる Ingress ラベルの数に制限はありません。

    この例では、ラベルを構成する必要はありません。

  4. 構成が完了したら、[OK][ingress の作成] パネルの左下隅にある をクリックします。

kubectl

次のコードブロックは、クラスター内の複数のサービスにリクエストを転送する Ingress を定義します。

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: forward-ingress
  annotations:
  # アノテーションで指定されたサービスは、クラスター内の既存のサービスである必要があり、サービス名は rule フィールドの backend で指定されたサービス名と同じである必要があります。
    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 を定義します。

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  namespace: default
  name: rewrite-ingress
  annotations:
    alb.ingress.kubernetes.io/actions.rewrite: |
       [{
           "type": "Rewrite",
           "RewriteConfig": {
               "Host": "demo.domain.ingress.top",
               "Path": "/test",
               "Query": "querystring"
           }
       }]
spec:
  ingressClassName: alb
  rules:
    - http:
        paths:
          - path: /path
            pathType: Prefix
            backend:
              service:
                name: rewrite
                port:
                  number: 80

シナリオ 7: ResponseHeader に基づいてレスポンスヘッダーを変更する

重要
  • デフォルトでは、カスタムルーティング規則はインバウンド方向に有効になります。カスタムルーティング規則をアウトバウンド方向に有効にするには、alb.ingress.kubernetes.io/rule-direction.<サービス名> アノテーションを Response に設定します。アノテーションはデフォルトで Request に設定されています。

  • カスタムアウトバウンドルーティング規則を作成する場合、ingressSpec.rules.backend フィールドの servicePort の名前は use-annotation である必要があります。

次のコードブロックは、response header が一致する場合 (ヘッダーに response-hello が含まれ、値が value1 または value2 である必要がある場合) に、新しいリクエストヘッダー 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.kubernetes.io/rule-direction.<サービス名> アノテーションを Response に設定します。アノテーションはデフォルトで Request に設定されています。

  • カスタムアウトバウンドルーティング規則を作成する場合、ingressSpec.rules.backend フィールドの servicePort の名前は use-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 である必要があります。