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 に作成できるルーティング規則を示します。
ルーティング条件 | 説明 |
ドメイン名 | 指定されたドメイン名宛てのリクエストのみをルーティングするために、この条件を追加できます。次のサンプルコードは、テンプレートの例を示しています。
|
リクエストがリダイレクトされる URL | 指定されたパスに送信されたリクエストのみをルーティングするために、この条件を追加できます。次のサンプルコードは、テンプレートの例を示しています。
|
ヘッダー | 指定されたヘッダーを含むリクエストのみをルーティングするために、この条件を追加できます。次のサンプルコードは、テンプレートの例を示しています。
|
クエリ文字列 | 指定されたクエリ文字列を含むリクエストのみをルーティングするために、この条件を追加できます。次のサンプルコードは、テンプレートの例を示しています。
|
リクエストメソッド | 指定されたリクエストメソッドを使用するリクエストのみをルーティングするために、この条件を追加できます。次のサンプルコードは、テンプレートの例を示しています。
|
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: 88alb.ingress.kubernetes.io/order: Ingress の優先順位。値が小さいほど優先順位が高くなります。
シナリオ 2: ドメイン名、リクエストメソッド、および Cookie に基づいてトラフィックをルーティングする
次のコードブロックは、ドメイン名、リクエストメソッド、および Cookie に基づいてパケットをルーティングするために使用されます。
次のコードブロックでは、リクエストメソッドは GET と HEAD に設定され、ドメイン名は www.hostvalue1.edu と www.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 に設定されています。さらに、コードブロックでは、リクエストに headerkey1 と headerkey2 が含まれている必要があることが指定されています。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 を構成できます。クライアントに返されるステータスコード、コンテンツ、およびコンテンツのタイプを指定できます。次のサンプルコードは、テンプレートの例を示しています。
|
リクエストをリダイレクトする | HTTP 3XX ステータスコードを使用して、リクエストを他のサービスアドレスにリダイレクトできます。次のサンプルコードは、テンプレートの例を示しています。 重要 httpCode 以外のすべてのリダイレクトパラメーターにデフォルト設定を同時に保持することはできません。
|
トラフィックをミラーリングする | トラフィックをミラーリングするサーバーグループの ID を指定できます。次のサンプルコードは、テンプレートの例を示しています。 重要
|
複数のバックエンドサーバーグループにリクエストを転送する | 複数のバックエンドサーバーグループにリクエストを転送するには、ServerGroupID フィールドを設定してサーバーグループ ID を指定するか、ServiceName と ServicePort フィールドを設定してサーバーグループを作成または関連付ける必要があります。また、各バックエンドサーバーグループの重みを指定することもできます。次のサンプルコードは、テンプレートの例を示しています。 重要
|
リクエストを書き換える | ALB インスタンスの書き換え規則を構成すると、リクエストのドメイン名、パス、およびクエリ文字列が書き換えられます。 重要
書き換え規則の詳細については、「書き換え規則の構成」をご参照ください。 |
リクエストヘッダーを挿入する | ヘッダーフィールドの名前と値を指定して、リクエスト内の既存のヘッダー変数を上書きできます。次のサンプルコードは、テンプレートの例を示しています。
|
リクエストヘッダーを削除する | リクエストヘッダーのキーと値を削除できます。次のサンプルコードは、テンプレートの例を示しています。
|
QPS スロットリング | ALB インスタンスの転送規則を構成する場合、グローバルリクエストレート制限と、クライアント IP アドレスに基づくリクエストレート制限を設定できます。 サンプルコード: 重要
|
アウトバウンドルーティング規則のルーティング操作
ルーティング操作 | 説明 |
リクエストヘッダーを挿入する | ヘッダーフィールドの名前と値を指定して、リクエスト内の既存のヘッダー変数を上書きできます。次のサンプルコードは、テンプレートの例を示しています。
|
リクエストヘッダーを削除する | リクエストヘッダーのキーと値を削除できます。次のサンプルコードは、テンプレートの例を示しています。
|
シナリオ 1: ステータスコード 503 と固定のコンテンツを返す
ACS コンソールの使用
ACS コンソール にログインします。左側のナビゲーションウィンドウで、[クラスター] をクリックします。
[クラスター] ページで、管理するクラスターを見つけて、その ID をクリックします。クラスター詳細ページの左側のナビゲーションウィンドウで、[ネットワーク] > [ingress] を選択します。
[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-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アノテーションを追加して、クライアントリクエスト内のパスをバックエンドサービスに転送する前に書き換えます。
カナリーリリースをオフにします。プロトコルとパスの書き換えパラメーターのデフォルト値を使用します。この例では、これらのパラメーターを構成する必要はありません。
カスタム転送ルール
説明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 ラベルの数に制限はありません。
この例では、ラベルを構成する必要はありません。
構成が完了したら、[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) コンソール にログインします。左側のナビゲーションウィンドウで、 を選択します。[サーバーグループ] ページで、サーバーグループの 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 コンソールの使用
ACS コンソール にログインします。左側のナビゲーションウィンドウで、[クラスター] をクリックします。
[クラスター] ページで、管理するクラスターを見つけて、その ID をクリックします。クラスター詳細ページの左側のナビゲーションウィンドウで、[ネットワーク] > [ingress] を選択します。
[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 認証を有効にできます。
ドメイン名: カスタムドメイン名を入力します。
シークレット: クラスターで使用されるシークレット。ビジネス要件に基づいてシークレットを選択します。シークレットを作成する場合は、次の手順を実行します。
[シークレット] の右側にある [作成] をクリックします。
[シークレットの作成] ダイアログボックスで、[名前]、[証明書]、および [キー] パラメーターを構成します。次に、[OK] をクリックします。
[シークレット] ドロップダウンリストから作成したシークレットを選択します。
[TLS 設定] をオフにします。この例では、TLS 証明書を構成する必要はありません。
詳細
カナリーリリース: カナリーリリースを有効にします。リクエストヘッダー、Cookie、および重みに基づいてカナリーリリースルールを構成できます。
説明リクエストヘッダー、Cookie、および重みのいずれか 1 つの要素のみに基づいてカナリーリリースルールを構成できます。また、リクエストヘッダー、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アノテーションを追加して、クライアントリクエスト内のパスをバックエンドサービスに転送する前に書き換えます。
カナリーリリースをオフにします。プロトコルとパスの書き換えパラメーターのデフォルト値を使用します。この例では、これらのパラメーターを構成する必要はありません。
カスタム転送ルール
説明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 ラベルの数に制限はありません。
この例では、ラベルを構成する必要はありません。
構成が完了したら、[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 である必要があります。