Application Load Balancer (ALB) Ingressを使用すると、カスタムルーティングルールを設定できます。 ルーティングルールは、ルーティング条件とアクションで構成されます。 ドメイン名、パス、リクエストヘッダー、クエリ文字列、リクエストメソッド、Cookie、またはリクエストの送信元IPアドレスに一致するルーティング条件を追加できます。 ルーティングアクションを追加して、固定応答の返信、リクエストのリダイレクト、リクエストヘッダーの挿入、リクエストヘッダーの削除、トラフィックのミラーリング、複数のバックエンドサーバーグループへのリクエストの転送、またはリクエストの書き換えを行うこともできます。 Container Service for Kubernetes (ACK) コンソールで、またはIngressでAnnotations
パラメーターを設定することで、ALB Ingressのルーティングルールをカスタマイズできます。
目次
カスタムルール | シナリオ |
ルーティング条件 | |
ルーティングアクション | |
ルーティング条件とアクションの設定方法 |
前提条件
ALB Ingressコントローラー2.5.0以降がクラスターにインストールされています。 詳細については、「コンポーネントの管理」をご参照ください。
ルーティング条件
1つのルーティングルールに最大10のルーティング条件を追加できます。
ルーティング条件ResponseHeaderおよびResponseStatusCodeは、カスタム送信ルーティングルールでのみ有効です。
ルーティング条件の概要
ALB ingressでは、alb.ingress.kubernetes.io/conditions.<Service name>
アノテーションでルーティング条件を設定できます。 異なるルールブロック間の論理関係はANDである。 ルールブロックに複数の値を指定した場合, 値の論理関係はORです。 たとえば、2つのヘッダールールブロックを設定した場合、2つのヘッダールールブロック間の論理関係はANDです。 ヘッダールールブロックで複数のヘッダーを設定した場合、ヘッダー間の論理的な関係はORです。 次の表に、ALB Ingressに対して作成できるルーティングルールを示します。
ルーティング条件 | 説明 |
ドメイン名 | この条件を追加して、指定したドメイン名宛てのリクエストのみをルーティングできます。 サンプルコード:
|
パス | この条件を追加して、指定したパスに送信されたリクエストのみをルーティングできます。 サンプルコード:
|
ヘッダー | この条件を追加して、指定したヘッダーを含むリクエストのみをルーティングできます。 サンプルコード:
|
クエリ文字列 | この条件を追加して、指定したクエリ文字列を含むリクエストのみをルーティングできます。 サンプルコード:
|
リクエストメソッド | この条件を追加して、指定したリクエストメソッドを使用するリクエストのみをルーティングできます。 サンプルコード:
|
Cookie | この条件を追加して、指定したCookieを含むリクエストのみをルーティングできます。 サンプルコード:
|
SourceIP | この条件を追加して、指定した送信元IPアドレスからのリクエストのみをルーティングできます。 サンプルコード:
|
ResponseHeader | この条件を追加して、指定したレスポンスヘッダーを含むレスポンスのみをルーティングできます。 サンプルコード:
|
ResponseStatusCode | この条件を追加して、指定したステータスコードを返すリクエストのみをルーティングできます。 サンプルコード:
|
シナリオ1: 送信元IPアドレスとリクエストヘッダーに基づいてトラフィックをルーティングする
1つのルーティングルールに対して、最大5つのソースIPアドレスをカスタム条件に追加できます。
次のコードブロックは、送信元IPアドレス、リクエストヘッダー、およびパスに基づいてパケットをルーティングするために使用されます。
次のコードブロックでは、ソースIPアドレスは192.168.0.0/16および172.16.0.0/16に設定され、ヘッダーキーはgray-helloに設定され、ヘッダー値はvalue1およびvalue2に設定され、パスは /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に基づいてパケットをルーティングするために使用されます。
次のコードブロックでは、リクエストメソッドはGETとHEADに設定され、ドメイン名はexample.comと *.eduに設定され、cookieのキーはcookiekey1に設定され、cookieの値はcookievalue1に設定され、パスは /testに設定されます。 ドメイン名、リクエストメソッド、Cookie、およびパスが上記のすべての条件と一致するリクエストのみが、gray-helloサービスにルーティングされます。 その他のリクエストは、サービス-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": [
"example.com",
"*.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に設定されます。 さらに、コードブロックは、リクエストにheaderkey1とheaderkey2を含める必要があることを指定します。 headerkey1のヘッダー値はheadervalue1またはheadervalue2で、headervalue2のヘッダー値はheadervalue3またはheadervalue4である必要があります。 クエリ文字列、リクエストヘッダー、およびパスが上記のすべての条件と一致するリクエストのみが、サービス-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.<Service name>
アノテーションで、インバウンドおよびアウトバウンドルーティングルールのルーティングアクションを設定できます。 ルーティングアクションを追加して、固定応答の返信、リクエストのリダイレクト、リクエストヘッダーの挿入、リクエストヘッダーの削除、トラフィックのミラーリング、複数のバックエンドサーバーグループへのリクエストの転送、またはリクエストの書き換えを行うことができます。 ALB Ingressでは、要求と応答をオンデマンドで処理するためのさまざまなルーティングアクションを定義できます。
alb.ingress.kubernetes.io/actions.<Service name>
アノテーションのサービス名は、ルール
フィールドのバックエンド
で指定されたサービス名と同じである必要があります。同じルーティングルールでは、複数の終了アクションを同時に追加することはできません。 たとえば、ルーティングアクションを追加して、固定応答を返す、リクエストをリダイレクトする、または複数のバックエンドサーバーグループにリクエストを同時に転送することはできません。
ルーティングアクションを追加して、固定応答を返す、リクエストをリダイレクトする、またはリクエストを複数のバックエンドサーバーグループに転送する場合、
ルール
フィールドのバックエンド
に指定されたサービスポートの名前はuse-annotationである必要があります。
受信ルーティングルールのルーティングアクション
ルーティングアクション | 説明 |
固定レスポンスを返す | 固定コンテンツをクライアントに返すようにALB Ingressを設定できます。 クライアントに返されるステータスコード、コンテンツ、およびコンテンツの種類を指定できます。 サンプルコード:
|
リダイレクトリクエスト数 | HTTP 3XXステータスコードを使用して、リクエストを他のサービスアドレスにリダイレクトできます。 サンプルコード: 重要 httpCodeを除くすべてのリダイレクトパラメータのデフォルト設定を同時に維持することはできません。
|
ミラートラフィック | サーバーグループのIDを指定して、指定したサーバーグループにトラフィックをミラーリングできます。 サンプルコード: 重要
|
複数のバックエンドサーバーグループにリクエストを転送する | リクエストを複数のバックエンドサーバーグループに転送するには、ServerGroupIDフィールドを設定してサーバーグループIDを指定するか、ServiceNameとServicePortフィールドを設定してサーバーグループを作成または関連付ける必要があります。 各バックエンドサーバーグループの重みを指定し、サーバーグループのセッション維持を有効にすることもできます。 重要
|
書き換えリクエスト | ALBインスタンスの書き換えルールを設定すると、リクエストのドメイン名、パス、およびクエリ文字列が書き換えられます。 サンプルコード: 重要
書き換えルールの詳細については、「書き換えルールの設定」をご参照ください。 |
リクエストヘッダーの挿入 | ヘッダーフィールドの名前と値を指定して、リクエスト内の既存のヘッダー変数を上書きできます。 サンプルコード:
|
リクエストヘッダーの削除 | リクエストヘッダーのキーと値を削除できます。 サンプルコード:
|
QPSスロットル | ALBインスタンスの転送ルールを設定する場合、クライアントIPアドレスに基づいてグローバルリクエストレート制限とリクエストレート制限を設定できます。 サンプルコード: 重要
|
アウトバウンドルーティング規則のルーティングアクション
ルーティングアクション | 説明 |
リクエストヘッダーの挿入 | ヘッダーフィールドの名前と値を指定して、リクエスト内の既存のヘッダー変数を上書きできます。 サンプルコード:
|
リクエストヘッダーの削除 | リクエストヘッダーのキーと値を削除できます。 サンプルコード:
|
シナリオ1: ステータスコード503と固定コンテンツを返す
ACKコンソールの使用
ACKコンソールにログインします。 左側のナビゲーションウィンドウで、[クラスター] をクリックします。
[クラスター] ページで、管理するクラスターの名前をクリックします。 左側のウィンドウで、 を選択します。
[Ingress] ページで、[Ingressの作成] をクリックします。 [Ingressの作成] ダイアログボックスで、パラメーターを設定します。
パラメーター
説明
例
ゲートウェイタイプ
要件に基づいて、ALB、MSE Cloud-native Gateway、またはNginxを選択できます。
3つのゲートウェイタイプの違いの詳細については、「NGINX Ingress、ALB Ingress、およびMSE Ingressの比較」をご参照ください。
ALB
名前
Ingressの名前を指定します。
Ingress
Ingressクラス
Ingressに関連付けられたIngressClassを指定します。
alb
ルール
[+ ルールの追加] をクリックして、Ingressルールを追加します。
ドメイン名: カスタムドメイン名を指定します。
マッピング: 次のパラメーターを指定します。
パス: バックエンドサービスのURLパスを指定します。 この例では、ルートパス /が使用されます。
ルール: [プレフィックス (プレフィックスベースの一致)] 、[完全一致] 、または [ImplementationSpecific (デフォルト値)] を選択できます。
サービス: バックエンドサービスを選択します。
ポート: 公開するサービスポートを指定します。
ドメイン名に複数のパスを設定できます。 [+ 追加] をクリックしてパスを追加します。
ドメイン名: このパラメーターは空のままにします。
マッピング:
パス: /。
ルール: デフォルトではプレフィックス (プレフィックスベースの一致) が選択されています。
サービス: 応答503。
ポート: 80。
TLS設定
TLS認証を有効にするかどうかを指定します。 IngressのTLS認証を有効にできます。
ドメイン名: カスタムドメイン名。
シークレット: 使用するシークレットを選択します。
シークレットを作成するには、次の手順を実行します。
Secretフィールドの右側にある [作成] をクリックします。
[シークレットの作成] ダイアログボックスで、[名前] 、[証明書] 、および [キー] パラメーターを設定します。 [OK] をクリックします。
[シークレット] ドロップダウンリストから作成したシークレットを選択します。
[+ 追加] をクリックすると、さらにTLS証明書を追加できます。
Ingress設定の詳細については、「高度なNGINX Ingress設定」をご参照ください。
TLS設定をオフにします。 この例では、TLS証明書を設定する必要はありません。
その他
カナリアリリース: カナリアリリースを有効にします。 リクエストヘッダー、Cookie、および重みに基づいてカナリアリリースルールを設定できます。
説明
カナリアリリースルールは、リクエストヘッダー、Cookie、および重みのいずれかの要素のみに基づいて設定できます。 リクエストヘッダー、Cookie、および重みに基づいて、カナリアリリースルールを同時に設定することもできます。 この場合、リクエストヘッダー、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に基づく:
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
アノテーションを追加して、リクエストがバックエンドサービスに転送される前にクライアントリクエストのパスを書き換えます。
カナリアリリースをオフにします。 ProtocolおよびRewrite Pathパラメーターのデフォルト値を使用します。 この例では、これらのパラメーターを設定する必要はありません。
カスタム転送ルール
カスタム転送ルールを有効にして、受信トラフィックをきめ細かく管理できます。
説明転送ルールには最大10の条件を追加できます。
[条件の追加] ドロップダウンリストでは、次の条件タイプを使用できます。
ドメイン名:
指定されたドメイン名を含むリクエストのみがルーティングされるように指定します。 複数のドメイン名の論理関係はORです。 ドメイン名を指定すると、
alb.ingress.kubernetes.io/conditions.host-example
アノテーションが追加されます。パス:
指定された1つ以上のパスを含むリクエストのみがルーティングされるように指定します。 複数のパスはOR関係で扱われます。 パスを指定すると、
alb.ingress.kubernetes.io/conditions.path-example
アノテーションが追加されます。HTTPヘッダー:
指定されたHTTPヘッダーを含むリクエストのみがルーティングされるように指定します。 各HTTPリクエストヘッダーはキーと値のペアです。 たとえば、keyを
headername
に設定し、valueをheadervalue1
に設定できます。 複数のヘッダー値を指定した場合, ヘッダー値の論理関係はORになります。 ヘッダーを指定すると、alb.ingress.kubernetes.io/conditions.http-header-example
アノテーションが追加されます。
[アクション] ドロップダウンリストでは、次のアクションを使用できます。
リターン固定レスポンス
ALBインスタンスによって固定コンテンツがクライアントに返されることを指定します。 クライアントに返されるステータスコード、コンテンツ、およびコンテンツの種類を指定できます。 ビジネス要件に基づいて、応答ステータスコード、応答コンテンツタイプ (オプション) 、および応答コンテンツ (オプション) パラメーターを設定します。
応答コンテンツタイプパラメーターの有効な値:
text/plain: コンテンツがプレーンテキストであることを示します。
text/css: コンテンツがXML形式であることを示します。
text/html: コンテンツがHTML形式であることを示します。
application/javascript: コンテンツがJavaScript形式であることを示します。
application/json: コンテンツがJSON形式であることを示します。
[条件の追加] ドロップダウンリストで、デフォルトで [パス] が選択されています。
[アクション] ドロップダウンリストで、[固定応答を返す] が選択されています。
応答ステータスコード: 503。
応答コンテンツタイプ (オプション): text/plain
応答内容 (オプション): エラー。
注釈
カスタム注釈の名前と値を入力できます。 ドロップダウンリストから名前で注釈を選択または検索することもできます。 Ingressアノテーションの詳細については、「ALB Ingress GlobalConfigurationディクショナリ」をご参照ください。
[+ 注釈の追加] をクリックして注釈を追加します。 ACKは、追加できるIngressアノテーションの数を制限しません。
この例では、注釈を設定する必要はありません。
ラベル
Ingressの特性を表すラベルを追加できます。
[+ ラベルの追加] をクリックしてラベルを追加します。 ACKは、追加できるIngressラベルの数を制限しません。
この例では、ラベルを設定する必要はありません。
設定が完了したら、をクリックします。OK.
kubectl
次のコードブロックは、ステータスコード503と503エラーテキスト
を返すために使用されます。
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 # The name of the Service port must be 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": "443",
"protocol": "https",
"query": "${query}",
"httpCode": "301"
}
}]
spec:
ingressClassName: alb
rules:
- http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: redirect
port:
name: use-annotation # The name of the Service port must be use-annotation.
シナリオ3: リクエストにsource: alibabaヘッダーを挿入する
次のコードブロックは、リクエスト内の既存のヘッダーをソースalibabaヘッダーで上書きするために使用されます。
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
namespace: default
name: ingress
annotations:
# The Service specified in the annotation must be an existing Service in the cluster, and the Service name must be the same as the Service name specified in the backend parameter of the rule field.
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: サーバーグループへのトラフィックのミラーリング
次のコードブロックは、トラフィックを指定されたサーバーグループにミラーリングするために使用されます。
Server Load Balancer (SLB) コンソールにログインします。 左側のナビゲーションウィンドウで、 を選択します。 [サーバーグループ] ページで、サーバーグループのIDを表示できます。
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: traffic-mirror-ingress
annotations:
# mirror-svc must be one of the backend services specified below.
# ALB Ingress will mirror the traffic forwarded to mirror-svc to the backend server specified in the ServerGroupID field.
# If multiple Services need to configure traffic mirroring, add an annotation for each Service.
alb.ingress.kubernetes.io/actions.mirror-svc: |
[{
"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: mirror-svc
port:
number: 80
シナリオ5: 複数のバックエンドサーバーグループにリクエストを転送する
ACKコンソールの使用
ACKコンソールにログインします。 左側のナビゲーションウィンドウで、[クラスター] をクリックします。
[クラスター] ページで、管理するクラスターの名前をクリックします。 左側のウィンドウで、 を選択します。
[Ingress] ページで、[Ingressの作成] をクリックします。 [Ingressの作成] ダイアログボックスで、パラメーターを設定します。
パラメーター
説明
例
ゲートウェイタイプ
要件に基づいて、ALB、MSE Cloud-native Gateway、またはNginxを選択できます。
3つのゲートウェイタイプの違いの詳細については、「NGINX Ingress、ALB Ingress、およびMSE Ingressの比較」をご参照ください。
ALB
名前
Ingressの名前を指定します。
forward-ingress
Ingressクラス
Ingressに関連付けられたIngressClassを指定します。
alb
ルール
[+ ルールの追加] をクリックして、Ingressルールを追加します。
ドメイン名: カスタムドメイン名を指定します。
マッピング: 次のパラメーターを指定します。
パス: バックエンドサービスのURLパスを指定します。 この例では、ルートパス /が使用されます。
ルール: [プレフィックス (プレフィックスベースの一致)] 、[完全一致] 、または [ImplementationSpecific (デフォルト値)] を選択できます。
サービス: バックエンドサービスを選択します。
ポート: 公開するサービスポートを指定します。
ドメイン名に複数のパスを設定できます。 [+ 追加] をクリックしてパスを追加します。
ドメイン名: demo. Domain. ingress.top
マッピング:
パス: /Path。
ルール: デフォルトではプレフィックス (プレフィックスベースの一致) が選択されています。
サービス: forward。
ポート: 80。
TLS設定
TLS認証を有効にするかどうかを指定します。 IngressのTLS認証を有効にできます。
ドメイン名: カスタムドメイン名。
シークレット: 使用するシークレットを選択します。 シークレットを作成するには、次の手順を実行します。
Secretフィールドの右側にある [作成] をクリックします。
[シークレットの作成] ダイアログボックスで、[名前] 、[証明書] 、および [キー] パラメーターを設定します。 [OK] をクリックします。
[シークレット] ドロップダウンリストから作成したシークレットを選択します。
TLS設定をオフにします。 この例では、TLS証明書を設定する必要はありません。
その他
カナリアリリース: カナリアリリースを有効にします。 リクエストヘッダー、Cookie、および重みに基づいてカナリアリリースルールを設定できます。
説明
カナリアリリースルールは、リクエストヘッダー、Cookie、および重みのいずれかの要素のみに基づいて設定できます。 リクエストヘッダー、Cookie、および重みに基づいて、カナリアリリースルールを同時に設定することもできます。 この場合、リクエストヘッダー、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に基づく:
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
アノテーションを追加して、リクエストがバックエンドサービスに転送される前にクライアントリクエストのパスを書き換えます。
カナリアリリースをオフにします。 ProtocolおよびRewrite Pathパラメーターのデフォルト値を使用します。 この例では、これらのパラメーターを設定する必要はありません。
カスタム転送ルール
カスタム転送ルールを有効にして、受信トラフィックをきめ細かく管理できます。
説明転送ルールには最大10の条件を追加できます。
[条件の追加] ドロップダウンリストでは、次の条件タイプを使用できます。
ドメイン名:
指定されたドメイン名を含むリクエストのみがルーティングされるように指定します。 複数のドメイン名の論理関係はORです。 ドメイン名を指定すると、
alb.ingress.kubernetes.io/conditions.host-example
アノテーションが追加されます。パス:
指定された1つ以上のパスを含むリクエストのみがルーティングされるように指定します。 複数のパスはOR関係で扱われます。 パスを指定すると、
alb.ingress.kubernetes.io/conditions.path-example
アノテーションが追加されます。HTTPヘッダー:
指定されたHTTPヘッダーを含むリクエストのみがルーティングされるように指定します。 各HTTPリクエストヘッダーはキーと値のペアです。 たとえば、keyを
headername
に設定し、valueをheadervalue1
に設定できます。 複数のヘッダー値を指定した場合, ヘッダー値の論理関係はORになります。 ヘッダーを指定すると、alb.ingress.kubernetes.io/conditions.http-header-example
アノテーションが追加されます。
[アクション] ドロップダウンリストでは、次のアクションを使用できます。
転送先
受信トラフィックを複数のバックエンドサーバーグループに転送します。 [サービス名] ドロップダウンリストからアクセスするサービスを選択します。 [ポート] ドロップダウンリストから、サービスへの接続に使用するポートを選択します。 各バックエンドサーバーグループのカスタム重みを指定します。
説明クラスターがFlannelコンポーネントを使用する場合、ClusterIPサービスはサポートされません。
[アクション] ドロップダウンリストから [転送] を選択した場合、ルールの [マッピング] パラメーターを設定する必要はありません。
[条件の追加] ドロップダウンリストで、[ドメイン名] が選択されます。 ドメイン名: demo. Domain. ingress.top
[操作] ドロップダウンリストで、[転送先] が選択されます。
サービス: tea-svc.
ポート: 80。
重量: 80。
サービスの追加
サービス: coffee-svc.
ポート: 80。
重量: 20。
注釈
カスタム注釈の名前と値を入力できます。 ドロップダウンリストから名前で注釈を選択または検索することもできます。 Ingressアノテーションの詳細については、「ALB Ingress GlobalConfigurationディクショナリ」をご参照ください。
[+ 注釈の追加] をクリックして注釈を追加します。 ACKは、追加できるIngressアノテーションの数を制限しません。
この例では、注釈を設定する必要はありません。
ラベル
Ingressの特性を表すラベルを追加できます。
[+ ラベルの追加] をクリックしてラベルを追加します。 ACKは、追加できるIngressラベルの数を制限しません。
この例では、ラベルを設定する必要はありません。
設定が完了したら、[Ingressの作成] パネルの左下隅にある [OK] をクリックします。
kubectl
次のコードブロックは、クラスター内の複数のサービスにリクエストを転送するIngressを定義します。
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: forward-ingress
annotations:
# The Service specified in the annotation must be an existing Service in the cluster, and the Service name must be the same as the Service name specified in backend of the rule field.
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 # The name of the Service port must be 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: 80
シナリオ7: ResponseHeaderに基づいて応答ヘッダーを変更する
デフォルトでは、カスタムルーティングルールはインバウンド方向で有効になります。 カスタムルーティングルールをアウトバウンド方向で有効にするには、アノテーション
alb.ingress.kubernetes.io/rule-direction.<Service name>
をResponseに設定します。 アノテーションはデフォルトでリクエストに設定されています。カスタム送信ルーティングルールを作成する場合、
ingressSpec.ru les.backend
フィールドのサービスポート
の名前はuse-annotation
である必要があります。
次のコードブロックでは、レスポンスヘッダー
が一致すると (ヘッダーに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 # The name of the Service port must be use-annotation.
シナリオ8: 応答ステータスコードに基づいて応答ヘッダーを変更する
デフォルトでは、カスタムルーティングルールはインバウンド方向で有効になります。 カスタムルーティングルールをアウトバウンド方向で有効にするには、アノテーション
alb.ingress.kubernetes.io/rule-direction.<Service name>
をResponseに設定します。 アノテーションはデフォルトでリクエストに設定されています。カスタム送信ルーティングルールを作成する場合、
ingressSpec.ru les.backend
フィールドのサービスポート
の名前は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 # The name of the Service port must be use-annotation.
ルーティング条件とアクションの設定方法
シナリオ1: ドメイン名ベースのルーティング条件とアクションを設定して、トラフィックを特定のサービスにルーティングする
このセクションでは、ACKコンソールでドメイン名ベースのルーティング条件とアクションを設定して、トラフィックを特定のサービスにルーティングする方法について説明します。
ALB Ingressを作成する前に、次の手順を実行してバックエンドサービスをデプロイし、AlbConfigとIngressClassを作成します。
ACKコンソールにログインします。 左側のナビゲーションウィンドウで、[クラスター] をクリックします。
[クラスター] ページで、管理するクラスターの名前をクリックします。 左側のウィンドウで、 を選択します。
[Ingress] ページで、[Ingressの作成] をクリックします。 [Ingressの作成] ダイアログボックスで、パラメーターを設定します。
パラメーター
説明
例
ゲートウェイタイプ
要件に基づいて、ALB、MSE Cloud-native Gateway、またはNginxを選択できます。
3つのゲートウェイタイプの違いの詳細については、「NGINX Ingress、ALB Ingress、およびMSE Ingressの比較」をご参照ください。
ALB
名前
Ingressの名前。
alb_ingress
Ingressクラス
Ingressに関連付けられたIngressClassを指定します。
alb
ルール
[+ ルールの追加] をクリックして、Ingressルールを追加します。
ドメイン名: カスタムドメイン名を指定します。
マッピング: 次のパラメーターを指定します。
パス: バックエンドサービスのURLパスを指定します。 この例では、ルートパス /が使用されます。
ルール: [プレフィックス (プレフィックスベースの一致)] 、[完全一致] 、または [ImplementationSpecific (デフォルト値)] を選択できます。
サービス: バックエンドサービスを選択します。
ポート: 公開するサービスポートを指定します。
ドメイン名に複数のパスを設定できます。 [+ 追加] をクリックしてパスを追加します。
ドメイン名: * .example.com
マッピング:
パス: /tes
ルール: ImplementationSpecific。 デフォルト値です。
サービス: tea-svc.
ポート: 80。
TLS設定
TLS認証を有効にするかどうかを指定します。 IngressのTLS認証を有効にできます。
ドメイン名: カスタムドメイン名。
シークレット: 使用するシークレットを選択します。
シークレットを作成するには、次の手順を実行します。
Secretフィールドの右側にある [作成] をクリックします。
[シークレットの作成] ダイアログボックスで、[名前] 、[証明書] 、および [キー] パラメーターを設定します。 [OK] をクリックします。
[シークレット] ドロップダウンリストから作成したシークレットを選択します。
[+ 追加] をクリックすると、さらにTLS証明書を追加できます。
詳細については、「ALB Ingressを使用したHTTPSリスナーの証明書の設定」をご参照ください。
TLS設定をオフにします。 この例では、TLS証明書を設定する必要はありません。
その他
カナリアリリース: カナリアリリースを有効にします。 リクエストヘッダー、Cookie、および重みに基づいてカナリアリリースルールを設定できます。
説明
カナリアリリースルールは、リクエストヘッダー、Cookie、および重みのいずれかの要素のみに基づいて設定できます。 リクエストヘッダー、Cookie、および重みに基づいて、カナリアリリースルールを同時に設定することもできます。 この場合、リクエストヘッダー、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に基づく:
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
アノテーションを追加して、リクエストがバックエンドサービスに転送される前にクライアントリクエストのパスを書き換えます。
カナリアリリースをオフにします。 ProtocolおよびRewrite Pathパラメーターのデフォルト値を使用します。 この例では、これらのパラメーターを設定する必要はありません。
カスタム転送ルール
カスタム転送ルールを有効にして、受信トラフィックをきめ細かく管理できます。
説明転送ルールには最大10の条件を追加できます。
[条件の追加] ドロップダウンリストでは、次の条件タイプを使用できます。
ドメイン名:
指定されたドメイン名を含むリクエストのみがルーティングされるように指定します。 複数のドメイン名の論理関係はORです。 ドメイン名を指定すると、
alb.ingress.kubernetes.io/conditions.host-example
アノテーションが追加されます。パス:
指定された1つ以上のパスを含むリクエストのみがルーティングされるように指定します。 複数のパスはOR関係で扱われます。 パスを指定すると、
alb.ingress.kubernetes.io/conditions.path-example
アノテーションが追加されます。重要転送条件を設定すると、Ingressはパス
/created-by-<ALB-ID>
の転送ルールを自動的に追加します。HTTPヘッダー:
指定されたHTTPヘッダーを含むリクエストのみがルーティングされるように指定します。 各HTTPリクエストヘッダーはキーと値のペアです。 たとえば、keyを
headername
に設定し、valueをheadervalue1
に設定できます。 複数のヘッダー値を指定した場合, ヘッダー値の論理関係はORになります。 ヘッダーを指定すると、alb.ingress.kubernetes.io/conditions.http-header-example
アノテーションが追加されます。
[アクション] ドロップダウンリストでは、次のアクションを使用できます。
転送先
受信トラフィックを複数のバックエンドサーバーグループに転送します。 [サービス名] ドロップダウンリストからアクセスするサービスを選択します。 [ポート] ドロップダウンリストから、サービスへの接続に使用するポートを選択します。 各バックエンドサーバーグループのカスタム重みを指定します。
説明クラスターにFlannelコンポーネントを使用する場合、ClusterIPサービスはサポートされません。
[アクション] ドロップダウンリストから [転送] を選択した場合、ルールの [マッピング] パラメーターを設定する必要はありません。
[条件の追加] ドロップダウンリストで、[ドメイン名] 、[パス] 、および [HTTPヘッダー] が選択されます。
ドメイン名: example.com [+ ホストの追加] をクリックすると、s test.comなどのドメイン名を追加できます。
[操作] ドロップダウンリストで、[転送先] が選択されます。
サービス: tea-svc.
ポート: 80。
重量: 100。
注釈
カスタム注釈の名前と値を入力できます。 ドロップダウンリストから名前で注釈を選択または検索することもできます。 Ingressアノテーションの詳細については、「アノテーション」をご参照ください。
[+ 注釈の追加] をクリックして注釈を追加します。 ACKは、追加できるIngressアノテーションの数を制限しません。
この例では、注釈を設定する必要はありません。
ラベル
Ingressの特性を表すラベルを追加できます。
[+ ラベルの追加] をクリックしてラベルを追加します。 ACKは、追加できるIngressラベルの数を制限しません。
この例では、ラベルを設定する必要はありません。
設定が完了したら、[Ingressの作成] パネルの左下隅にある [OK] をクリックします。
Ingressが作成されたことを確認します。
左側のウィンドウで、[ネットワーク]> [Ingress] を選択します。 Ingressのページには、cafe-ingressという名前のIngressが表示されます。
cafe-ingressの [エンドポイント] 列で、エンドポイントを表示します。