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 でリンクされます。
条件 | 説明 |
ドメイン名 | ドメイン名に基づいてリクエストをルーティングします。以下に例を示します。
|
パス | パスに基づいてリクエストをルーティングします。以下に例を示します。
|
ヘッダー | リクエストヘッダーに基づいてリクエストをルーティングします。以下に例を示します。
|
クエリ文字列 | クエリ文字列に基づいてリクエストをルーティングします。以下に例を示します。
|
リクエストメソッド | リクエストメソッドに基づいてリクエストをルーティングします。以下に例を示します。
|
Cookie | Cookie に基づいてリクエストをルーティングします。以下に例を示します。
|
SourceIP | ソース IP アドレスに基づいてリクエストをルーティングします。以下に例を示します。
|
ResponseHeader | レスポンスヘッダーに基づいてレスポンスをカスタマイズします。以下に例を示します。
|
ResponseStatusCode | レスポンスステータスコードに基づいてレスポンスをカスタマイズします。以下に例を示します。
|
ユースケース 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: 88alb.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 であり、リクエストヘッダーに headerkey1 と headerkey2 が含まれている必要があります。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 にする必要があります。
インバウンドルーティングアクション
アクション | 説明 |
固定レスポンス | クライアントに固定レスポンスを返します。レスポンスステータスコード、ボディ、コンテンツタイプを設定できます。
|
リダイレクト | HTTP 3xx ステータスコードを使用して、クライアントリクエストを別の URL にリダイレクトします。 重要 httpCode 以外に、リダイレクト設定で少なくとも 1 つのパラメーターを指定する必要があります。
|
トラフィックミラーリング | リクエストをコピーし、トラフィックミラーリングサーバーグループに転送します。 重要
|
複数のバックエンドサーバーグループへの転送 | リクエストを複数のバックエンドサーバーグループに転送します。ServerGroupID を使用してバックエンドサーバーグループを指定するか、ServiceName と 重要
|
書き換え | リクエストのホスト、パス、またはクエリ文字列を書き換えます。 重要
詳細については、「書き換えの設定」をご参照ください。 |
ヘッダーの挿入 | リクエストにヘッダーを挿入します。同じ名前のヘッダーが既に存在する場合、上書きされます。
|
ヘッダーの削除 | リクエストから指定されたヘッダーを削除します。
|
レート制限 | 全体の秒間クエリ数 (QPS) と特定のクライアント IP アドレスからの QPS に基づいてリクエストのレートを制限します。 重要
|
アウトバウンドルーティングアクション
アクション | 説明 |
リクエストヘッダーの挿入 | 指定された名前と値を持つヘッダーを挿入します。同じ名前のヘッダーが既に存在する場合、上書きされます。
|
リクエストヘッダーの削除 | リクエストから指定されたヘッダーを削除します。
|
シナリオ 1:固定の 503 レスポンスとコンテンツを設定
コンソール
-
ACS コンソールにログインします。左側のナビゲーションウィンドウで、クラスターリスト をクリックします。
-
クラスターリスト ページで、対象のクラスターの名前をクリックします。左側のナビゲーションウィンドウで、ネットワーク > Ingress を選択します。
Ingress ページで Ingress の作成 をクリックし、Ingress の作成 ダイアログボックスで Ingress を設定します。
パラメーター | 説明 | 例 |
ゲートウェイタイプ | ビジネスニーズに応じて、ゲートウェイタイプとして ALB または MSE Ingress を選択します。 | ALB |
名前 | Ingress のカスタム名。 | ingress |
Ingress クラス | Ingress のカスタムクラス。 | alb |
リスナー / ポート | AlbConfig で定義されている ALB インスタンスのリスナーポートとプロトコル。この設定は、ロードバランサーがインバウンドトラフィックを受信して処理する方法を指定します。 | HTTP:80 |
ルール | +ルールの追加 をクリックして、複数のルーティングルールを追加します。
|
|
TLS 設定 | TLS を設定して、安全なルーティングサービスを有効にします。
| TLS 設定 を無効にします。この例では必須ではありません。 |
その他 |
| カナリアリリースを無効にします。プロトコルと書き換えパスはデフォルトのままにします。これらの設定はこの例では必須ではありません。 |
カスタム転送ルール | 説明 コンソールでカスタム転送ルールを設定する機能はカナリアリリース中です。この機能を使用するには、チケットを送信。 カスタム転送ルールを使用して、インバウンドトラフィックを詳細に管理します。 説明 転送ルールには最大 10 個の条件を追加できます。
複数の条件 (ドメイン、パス、または HTTP ヘッダーに基づく) とアクション (バックエンドへの転送や固定レスポンスの返却など) を組み合わせることができます。 |
|
アノテーション | キーと値を指定してカスタムアノテーションを追加するか、キーでアノテーションを選択または検索できます。Ingress アノテーションの詳細については、「ALB Ingress アノテーションリファレンス」をご参照ください。 + アノテーションの追加 をクリックして、Ingress に複数のアノテーションを追加します。 | このパラメーターはこの例では必須ではありません。 |
ラベル | Ingress に追加するラベルを指定します。ラベルは、識別属性を指定するためにオブジェクトにアタッチされるキーと値のペアです。 | このパラメーターはこの例では必須ではありません。 |
構成が完了したら、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:複数のバックエンドグループへのリクエスト転送
コンソールでの設定
-
ACS コンソールにログインします。左側のナビゲーションウィンドウで、クラスターリスト をクリックします。
-
クラスターリスト ページで、対象のクラスターの名前をクリックします。左側のナビゲーションウィンドウで、ネットワーク > Ingress を選択します。
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 を保護するために有効にします。
ドメイン名:カスタムドメイン名。
シークレット:シークレットを選択します。シークレットを作成するには、次の手順を実行します。
Secret の右側で、作成を続ける をクリックします。
Secret の作成 ダイアログボックスで、シークレットの 名前、[証明書]、および [キー] を指定してから、OK をクリックします。
Secret ドロップダウンリストから、作成したシークレットを選択します。
TLS 設定 をオフにします。この例では必須ではありません。
その他
-
カナリアリリース: この機能を有効にすると、カナリアリリースを設定できます。カナリアルールは、リクエストヘッダー、 Cookie 、またはトラフィックの重みに基づいて設定できます。
説明これらの条件のうち 1 つだけを設定できます。複数の条件を設定した場合、Ingress コントローラーはリクエストヘッダー、Cookie、そして重みの順で評価します。
-
リクエストヘッダーに基づく: リクエストヘッダーに基づいてトラフィックを分割します。これにより、
nginx.ingress.kubernetes.io/canary-by-header、nginx.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 に追加するラベルを指定します。ラベルは、識別属性を指定するためにオブジェクトにアタッチされるキーと値のペアです。
このパラメーターはこの例では必須ではありません。
-
構成を完了したら、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.backendのservicePortフィールドを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.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 である必要があります。