ルーティングルール、HTTPS リダイレクト、リライト、カナリアリリース、セッション維持など、ALB Ingress の高度な機能を設定します。
ドメイン名に基づくリクエストの転送
Ingress を作成して、ドメイン名または空のドメイン名に基づいてリクエストを転送します。
ドメイン名
この例では、ルーティングパスを /hello に設定します。 demo.domain.ingress.top/hello へのリクエストは、バックエンドサービスに転送されます。
-
次のマニフェストをデプロイして、Service、Deployment、および指定されたドメイン名に基づいてリクエストを転送する Ingress を作成します。
-
kubectl get ingを実行して ALB インスタンスのアドレスを取得します。 次に、ADDRESSをインスタンスのアドレスに置き換えて、次のコマンドを実行します。curl -H "host: demo.domain.ingress.top" ADDRESS/hello期待される出力:
{"hello":"coffee"}
空のドメイン名
空のドメイン名とルーティングパス /hello を使用すると、ADDRESS/hello へのリクエストはバックエンドサービスに転送されます。
-
次のマニフェストをデプロイして、Service、Deployment、および Ingress を作成します。
-
kubectl get ingを実行して ALB インスタンスのアドレスを取得します。 次に、ADDRESSをインスタンスのアドレスに置き換えて、次のコマンドを実行します。curl ADDRESS/hello期待される出力:
{"hello":"coffee"}
パスベースの転送
ALB Ingress は、URL パスに基づいてリクエストを転送します。pathType フィールドで一致モードを指定します。pathType には、3 つのモードがあります。
-
完全一致 (
Exact):URL パスと完全に一致します。 -
デフォルト (
ImplementationSpecific):ALB Ingress Controller はこれを完全一致として扱います。path が指定されていない場合、デフォルトで/になります。 -
前方一致 (
Prefix):URL パスのプレフィックスに一致します。
-
pathTypeがExactまたはPrefixの場合、path は空ではない絶対パスである必要があります。そうでない場合、検証に失敗します。 -
URL 一致ポリシーが競合する場合、リクエストは 転送ルールの優先度 に基づいて転送されます。
-
単純なパス (/, /foo, /foo/)
一致モード
ルールパス
リクエストパス
一致
前方一致 (Prefix)
/
/ (すべてのパスに一致)
はい
/foo
-
/foo
-
/foo/
はい
/foo/
-
/foo
-
/foo/
はい
/aaa
/ccc
いいえ。プレフィックスが一致しません。
完全一致 (Exact) またはデフォルト (ImplementationSpecific)
/foo
/foo
はい
/bar
いいえ
/foo/
いいえ
/foo/
/foo
いいえ
-
-
階層パス (/aaa/bb, /aaa/bbb, /aaa/bbb/)
一致モード
ルールパス
リクエストパス
一致
前方一致 (Prefix)
/aaa/bb
/aaa/bbb
いいえ
/aaa/bbb
/aaa/bbb
はい
/aaa/bbb/
/aaa/bbb
はい。ルールパスの末尾のスラッシュは無視されます。
/aaa/bbb
/aaa/bbb/
はい。リクエストパスの末尾のスラッシュが一致します。
/aaa/bbb/ccc
はい。ルールパスはリクエストパスのプレフィックスです。
-
2 つのルールパス
一致モード
ルールパス
リクエストパス
一致
前方一致 (Prefix)
-
/
-
/aaa
/aaa/ccc
はい。リクエストパスはルールパス
/aaaに一致します。-
/aaa
-
/
/aaa/ccc
はい。リクエストパスはルールパス
/aaaに一致します。/ccc
はい。リクエストパスはルールパス
/に一致します。-
/aaa
-
/bbb
/ccc
いいえ。プレフィックスが一致しません。
-
各一致モードの例:
前方一致 (Prefix)
このモードでは、/ で区切られた URL パス要素に対して、大文字と小文字を区別して前方一致します。
ルールパス / は、/ で始まるすべてのパス (例: /hello) に一致します。
-
次のマニフェストをデプロイして、Ingress リソースを作成します。
-
kubectl get ingを実行して ALB インスタンスのアドレスを取得します。次に、ADDRESSを取得したアドレスで置き換えて、次のコマンドを実行します。curl ADDRESS/hello出力例:
{"hello":"coffee"}
完全一致またはデフォルト
ルールパス /hello は、/hello へのリクエストにのみ一致します。
-
次のマニフェストをデプロイして、Ingress リソースを作成します。
-
kubectl get ingを実行して ALB インスタンスのアドレスを取得します。次に、ADDRESSを取得したアドレスで置き換えて、次のコマンドを実行します。curl ADDRESS/hello出力例:
{"hello":"coffee"}
ヘルスチェックの設定
アノテーションを使用して、ALB Ingress のヘルスチェックを設定します。
アノテーションの例:
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: cafe-ingress
annotations:
alb.ingress.kubernetes.io/healthcheck-enabled: "true"
alb.ingress.kubernetes.io/healthcheck-path: "/"
alb.ingress.kubernetes.io/healthcheck-protocol: "HTTP"
alb.ingress.kubernetes.io/healthcheck-httpversion: "HTTP1.1"
alb.ingress.kubernetes.io/healthcheck-method: "HEAD"
alb.ingress.kubernetes.io/healthcheck-code: "http_2xx"
alb.ingress.kubernetes.io/healthcheck-timeout-seconds: "5"
alb.ingress.kubernetes.io/healthcheck-interval-seconds: "2"
alb.ingress.kubernetes.io/healthy-threshold-count: "3"
alb.ingress.kubernetes.io/unhealthy-threshold-count: "3"
spec:
... ...
|
パラメーター |
説明 |
デフォルト |
|
|
バックエンドサーバーグループのヘルスチェックを有効にするかどうかを指定します。
|
|
|
|
ヘルスチェックに使用するパスです。 |
|
|
|
ヘルスチェックに使用するプロトコルです。
|
|
|
|
HTTP プロトコルのバージョンです。
|
|
|
|
ヘルスチェックに使用するメソッドです。
重要
|
|
|
|
バックエンドサーバーが正常であることを示すステータスコードです。 コンマで区切って1つ以上指定します。
|
|
|
|
バックエンドサーバーが正常であることを示すステータスコードです。両方を指定した場合は、 有効な値は
|
|
|
|
ヘルスチェックのタイムアウト (秒) です。有効な値:1~300。 |
|
|
|
ヘルスチェックの間隔 (秒) です。有効な値:1~50。 |
|
|
|
正常のしきい値は、バックエンドサーバーを正常と判定するために必要な、連続したヘルスチェック成功回数です。有効な値:2~10。 |
|
|
|
非正常のしきい値は、バックエンドサーバーを異常と判定するために必要な、連続したヘルスチェック失敗回数です。有効な値:2~10。 |
|
|
|
ヘルスチェックに使用するポートです。 |
説明
|
HTTP リクエストの HTTPS へのリダイレクト
次のアノテーションを追加して、HTTP リクエストを HTTPS ポート 443 にリダイレクトします。
-
この機能は、リスナーポート 80 の HTTP 転送ルールにのみ適用されます。
-
このアノテーションは、
RemoveHeader、InsertHeader、Corsなどのカスタム転送アクション用のアノテーションと併用する必要があります。 -
このアノテーションを使用する前に、AlbConfig でポート 443 に HTTPS リスナーが設定されていることを確認してください。 詳細については、「AlbConfig を使用した ALB リスナーの設定」をご参照ください。
|
パラメーター |
説明 |
アノテーションの例 |
|
|
HTTP リクエストを HTTPS ポート 443 にリダイレクトする。 |
|
バックエンドの HTTPS または gRPC の設定
バックエンドプロトコルとして HTTPS または gRPC を使用するには、次のアノテーションを追加します。
バックエンドプロトコルは Ingress の作成後に変更できません。変更するには、Ingress を削除して再作成してください。
|
パラメーター |
説明 |
YAML の例 |
|
|
|
|
正規表現の設定
alb.ingress.kubernetes.io/use-regex: "true" アノテーションを使用して、pathType: Prefix を持つ spec.rules のパスルールで正規表現マッチングを有効にします。
-
pathType: Prefixを持つパスルールにのみ適用されます。カスタム転送条件とは無関係に、spec.rulesのpathフィールドで正規表現構文を有効にします。 -
このアノテーションは、その値 (
trueまたはfalse) に関係なく、正規表現マッチングを有効にします。無効にするには、アノテーションを削除してください。 -
このアノテーションがない場合、パスに
=^()[]|, などのような特殊文字が含まれていると、Ingress の作成は失敗します。 -
カスタム転送条件 (
alb.ingress.kubernetes.io/conditions.YOUR-SVC-NAME) のパス値は ALB に直接渡されるため、use-regexアノテーションは不要です。正規表現マッチングを有効にするには、パス値に~*または~プレフィックスを追加してください。use-regexアノテーションは、spec.rulesのpathフィールドにのみ影響します。
カスタム転送ルール
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
annotations:
alb.ingress.kubernetes.io/conditions.YOUR-SVC-NAME: | ## YOUR-SVC-NAME を実際のサービス名に置き換えてください。これは、後述の backend.service.name と一致する必要があります。
[{
"type": "Path",
"pathConfig": {
"values": [
"~*/pathvalue1", ## 正規表現に ~* または ~ プレフィックスを追加してください。プレフィックスの後のテキストが正規表現自体です。~* は大文字と小文字を区別する一致、~ は大文字と小文字を区別しない一致を示します。
"/pathvalue2" ## 完全一致にはプレフィックスは不要です。
]
}
}]
name: ingress-example
spec:
ingressClassName: alb
rules:
- http:
paths:
- path: /test-path-for-alb
pathType: Prefix
backend:
service:
name: YOUR-SVC-NAME ## ここでの YOUR-SVC-NAME は、関連付けを定義するために、カスタム転送条件アノテーションで指定されたサービス名と一致する必要があります。
port:
number: 88
Spec.rules
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
annotations:
alb.ingress.kubernetes.io/use-regex: "true" ## spec.rules のパスで正規表現を使用できるようにします。
name: ingress-example
spec:
ingressClassName: alb
rules:
- http:
paths:
- path: /test-[a-z]-alb[()^]*
pathType: Prefix
backend:
service:
name: tea-svc
port:
number: 88
|
パラメーター |
説明 |
|
|
|
|
|
|
|
カスタム転送条件を設定します。 詳細については、「ALB Ingress のカスタム転送ルール」をご参照ください。
|
|
次の表に、正規表現のマッチング規則を示します。
|
オブジェクト |
プレフィックス |
ルール例 |
クライアントパス |
一致 |
説明 |
|
ドメイン名 |
|
|
test.EXAMPLE.com |
はい |
ドメイン名は、大文字と小文字を区別しない正規表現マッチングをサポートします。 |
|
パス |
|
|
/API |
はい |
パスは、大文字と小文字を区別しない正規表現マッチングをサポートします。 |
|
|
|
/Api |
いいえ |
パスは、大文字と小文字を区別する正規表現マッチングをサポートします。 |
正規表現の前方一致
正規表現マッチングは、デフォルトで「部分一致」になります。特定のコンテンツで始まるパスのみに一致させるには、式の先頭に ^ を追加します。たとえば、^/api は /api で始まるパスにのみ一致します。
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: ingress-example
annotations:
alb.ingress.kubernetes.io/use-regex: "true" ## 正規表現マッチングを有効にします。
alb.ingress.kubernetes.io/conditions.YOUR-SVC-NAME: | ## YOUR-SVC-NAME を実際のサービス名に置き換えてください。これは、後述の backend.service.name と一致する必要があります。
[
{
"type": "Path",
"pathConfig": {
"values": [
"~*^/pathvalue1", # ~* または ~ で始まるパスは正規表現マッチングを示します。キャレット (^) は「/pathvalue1で始まる」ことを示します。
"/pathvalue2" # 標準的な前方一致または完全一致の場合、~* または ~ は追加しません。
]
}
}
]
spec:
ingressClassName: alb
rules:
# 注:alb.ingress.kubernetes.io/conditions.* アノテーションを使用する場合、AWS Load Balancer Controller はこの spec.rules セクションを無視します。
# このセクションは、Ingress リソースのスキーマ検証を満たすためにのみ必要です。
- http:
paths:
- path: /test-path-for-alb
pathType: Prefix
backend:
service:
name: YOUR-SVC-NAME # 実際のサービス名に置き換えてください。この名前はアノテーションと一致する必要があります。
port:
number: 88
書き換えの設定
ALB Ingress は、リクエストをバックエンド Service に転送する前にリクエストパスを書き換えます。次の 2 つのアノテーションを使用します:
-
alb.ingress.kubernetes.io/rewrite-target: /path/${number}:リクエストの書き換え先のパスを指定します。重要-
${number}変数を使用して、Ingress パスの正規表現からキャプチャグループを参照します。${1}、${2}、および${3}を使用して、最大 3 つのキャプチャグループを参照できます。 -
Ingress の
pathTypeはPrefixに設定する必要があります。
-
-
alb.ingress.kubernetes.io/use-regex: true:パスで正規表現を有効にします。これは、rewrite-targetを設定するとデフォルトで有効になります。重要-
このアノテーションは、その値 (
trueまたはfalse) に関係なく、正規表現によるマッチングを有効にします。無効にするには、アノテーションを削除します。 -
このアノテーションがない場合、パスに
"%#;!()[]^,"\""などの特殊文字が含まれていると、Ingress の作成は失敗します。
-
設定例
例 1:プレフィックスの削除
次の YAML の例では、path: /something(/|$)(.*) は正規表現を使用して、クライアントリクエストパスを 3 つの部分に分割します:
-
/something:削除するプレフィックスに一致します。 -
(/|$):最初のキャプチャグループで、/somethingの後の/またはパスの末尾 ($) のいずれかに一致します。 -
(.*):2 番目のキャプチャグループで、/something/の後のすべての文字に一致し、書き換え後のパスでは${2}として参照されます。
alb.ingress.kubernetes.io/rewrite-target アノテーションは、書き換え後のパスを / の後に ${2} が続く形式で指定します。次の表に書き換え結果を示します。
|
元のクライアントパス |
パスの正規表現マッチ |
書き換え後のパス |
|
|
一致します。2 番目のキャプチャグループは空です。 |
|
|
|
一致します。2 番目のキャプチャグループは空です。 |
|
|
|
一致します。2 番目のキャプチャグループは |
|
|
|
一致しません。この例では、リクエストがどのルーティングルールにも一致しないため、ALB Ingress は 503 ステータスコードを返します。 |
|
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: rewrite-ingress
annotations:
alb.ingress.kubernetes.io/use-regex: "true" # path フィールドで正規表現を使用できるようにします。
alb.ingress.kubernetes.io/rewrite-target: /${2} # このアノテーションは正規表現による置換をサポートします。
spec:
ingressClassName: alb
rules:
- host: demo.alb.ingress.top
http:
paths:
- path: /something(/|$)(.*)
pathType: Prefix
backend:
service:
name: rewrite-svc
port:
number: 9080
例 2:複数の部分をキャプチャして再配置
次の例では、パス /items/(.*)/(.*)/(.*) の複数の部分をキャプチャして再配置します。また、パスセグメントをクエリパラメーターに変換するため、クライアント側の変更は不要です。書き換え後のパスは、/、2 番目のキャプチャグループ ${2}、文字列 ?code=、3 番目のキャプチャグループ ${3} の順で構築されます。次の表に書き換え結果を示します。
この例では、クライアントは 4 つのセグメントを持つ固定パス形式を使用する必要があります。
|
元のクライアントパス |
パスの正規表現マッチ |
書き換え後のパス |
|
|
一致します。2 番目のキャプチャグループは |
|
|
|
一致します。2 番目のキャプチャグループは |
|
|
|
一致しません。この例では、リクエストがどのルーティングルールにも一致しないため、ALB Ingress は 503 ステータスコードを返します。 |
|
|
|
一致しません。この例では、リクエストがどのルーティングルールにも一致しないため、ALB Ingress は 503 ステータスコードを返します。 |
|
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: rewrite-ingress
annotations:
alb.ingress.kubernetes.io/use-regex: "true" # path フィールドで正規表現を使用できるようにします。
alb.ingress.kubernetes.io/rewrite-target: /${2}?code=${3} # このアノテーションは正規表現による置換をサポートします。
spec:
ingressClassName: alb
rules:
- host: demo.alb.ingress.top
http:
paths:
- path: /items/(.*)/(.*)/(.*)
pathType: Prefix
backend:
service:
name: rewrite-svc
port:
number: 9080
例 3:複数のパスを単一のパスに書き換える
次の例では、正規表現を使用して複数のパス (/app-a(/|$)(.*) および /app-b(/|$)(.*)) に一致させ、それらを単一のパスに書き換えます。書き換え後のパスは /app-c/ の後に ${2} が続くパスです。次の表に書き換え結果を示します。
|
元のクライアントパス |
パスの正規表現マッチ |
書き換え後のパス |
|
|
一致します。2 番目のキャプチャグループは |
|
|
|
一致します。2 番目のキャプチャグループは |
|
|
|
一致します。2 番目のキャプチャグループは空です。 |
|
|
|
一致しません。この例では、リクエストがどのルーティングルールにも一致しないため、ALB Ingress は 503 ステータスコードを返します。 |
|
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: rewrite-ingress
annotations:
alb.ingress.kubernetes.io/use-regex: "true" # path フィールドで正規表現を使用できるようにします。
alb.ingress.kubernetes.io/rewrite-target: /app-c/${2} # このアノテーションは正規表現による置換をサポートします。
spec:
ingressClassName: alb
rules:
- host: demo.alb.ingress.top
http:
paths:
- path: /app-a(/|$)(.*)
pathType: Prefix
backend:
service:
name: rewrite-svc
port:
number: 9080
- path: /app-b(/|$)(.*)
pathType: Prefix
backend:
service:
name: rewrite-svc
port:
number: 9080
例 4:ドメイン名の書き換え
alb.ingress.kubernetes.io/rewrite-target アノテーションは、パスの変更のみをサポートします。ドメイン名やクエリパラメーターなど、URL の他の部分を変更するには、カスタム転送ルールを使用します。
書き換えルールのテスト
sed コマンドを使用して、クライアントのパスがパスの正規表現に一致するかどうかをテストし、書き換え後のパスをプレビューします。
この例では、例 2:複数の部分をキャプチャして再配置のキャプチャパス /items/(.*)/(.*)/(.*) と書き換えルール /${2}?code=${3} を使用します。
-
次のサンプルパスを
path2.txtという名前のファイルに保存します:/items/electronics/computers/554 /items/produce/fruits/12 /items/headphones/5 /drinks/41 -
パスが一致するかどうかを確認し、書き換え後のパスを表示します:
次のコマンドは、この例のパス正規表現 (
/items/(.*)/(.*)/(.*)) と書き換え後のパス (/${2}?code=${3}) を sed 用に調整します。sed を使用する場合、/のような特殊文字はバックスラッシュ (\) でエスケープする必要があり、キャプチャグループ参照は${2}ではなく\2と記述します。sed -E 's#\/items\/(.*)\/(.*)\/(.*)#Matched: [&] --- Rewritten: [/\2?code=\3]#' path2.txt次のような出力が得られます。最初の 2 つのパスはルールに一致して書き換えられますが、最後の 2 つは一致しないため変更されません。
Matched: [/items/electronics/computers/554] --- Rewritten: [/computers?code=554] Matched: [/items/produce/fruits/12] --- Rewritten: [/fruits?code=12] /items/headphones/5 /drinks/41
カスタムリスナーポートの設定
アノテーションを追加して、Ingress が使用するリスナーポートとしてポート 80 (HTTP) とポート 443 (HTTPS) を指定します。
ALB は、Ingress でリスナーを直接作成することをサポートしていません。まず AlbConfig で必要なリスナーポートとプロトコルを作成してから、Ingress でそれらを参照します。詳細については、「AlbConfig を使用した ALB リスナーの設定」をご参照ください。
|
パラメーター |
説明 |
YAML の例 |
|
|
Ingress が使用するリスナーポートを指定します。 |
|
転送ルールの優先度の設定
デフォルトでは、ALB は次の基準に基づいて転送ルールの優先度を決定します。
-
システムは
namespace/nameの辞書順で Ingress リソースをソートします。辞書順の値が小さい Ingress ほど、優先度が高くなります。まず名前空間が比較され、次に名前が文字ごとに比較されます。
-
1 つの Ingress 内では、ルールは
rulesフィールドでの順序によって優先されます。先にリストされているルールほど、優先度が高くなります。rules: - host: www.example.com http: ... - host: www.test.com http: ...
Ingress の namespace/name を変更せずに ALB 転送ルールの優先度を指定するには、次の Ingress アノテーションを追加します。
|
パラメーター |
説明 |
値 |
YAML の例 |
|
|
ALB 転送ルールの優先度を指定します。値が小さいほど優先度が高くなります。 各ルールの優先度は、同じリスナー内で一意にする必要があります。 |
[1, 1000] デフォルト:10 |
|
アノテーションを使用したカナリアリリースの実装
ALB は、ヘッダー、Cookie、重みに基づくカナリアリリースをサポートしています。ベストプラクティスについては、「ALB Ingress を使用してカナリアリリースを実装する」をご参照ください。
|
パラメーター |
説明 |
説明 |
|
|
カナリアリリース機能を有効にします。 |
|
-
指定したヘッダーに基づくカナリアトラフィックの分散
パラメーター
説明
YAML の例
alb.ingress.kubernetes.io/canary-by-headerこれらのアノテーションは、トラフィックルーティングのためのカスタムリクエストヘッダーと値を定義します。両方のアノテーションが必要です。
-
リクエスト内の
headerとheader-valueが設定値と一致する場合、リクエストトラフィックはカナリアサービスのエントリポイントに向けられます。 -
一致しないリクエストは、優先度の低いルールで評価されます。
apiVersion: networking.k8s.io/v1 kind: Ingress metadata: annotations: alb.ingress.kubernetes.io/order: "1" alb.ingress.kubernetes.io/canary: "true" alb.ingress.kubernetes.io/canary-by-header: "location" alb.ingress.kubernetes.io/canary-by-header-value: "hz" name: demo-canary spec: ... ...alb.ingress.kubernetes.io/canary-by-header-valueリクエストに
location: hzヘッダーが含まれている場合、ALB はトラフィックをカナリア Service にルーティングします。それ以外のリクエストは、Cookie または重みに基づくルールなど、優先度の低いルールで評価されます。 -
-
指定した Cookie に基づくカナリアトラフィックの分散
パラメーター
説明
YAML の例
alb.ingress.kubernetes.io/canary-by-cookie-
always: すべてのリクエストをカナリアサービスにルーティングします。 -
never: カナリアサービスにリクエストをルーティングしません。
Cookie ベースのカナリアリリースではカスタム値を使用できず、
alwaysとneverのみ指定できます。apiVersion: networking.k8s.io/v1 kind: Ingress metadata: annotations: alb.ingress.kubernetes.io/order: "2" alb.ingress.kubernetes.io/canary: "true" alb.ingress.kubernetes.io/canary-by-cookie: "demo" name: demo-canary-cookie spec: ... ...リクエストに
Cookie: demo=alwaysヘッダーが含まれている場合、ALB はトラフィックをカナリア Service にルーティングします。ヘッダーにCookie: demo=neverが含まれている場合、ALB はトラフィックをカナリア Service にルーティングしません。 -
-
重みによるトラフィックの分散
パラメーター
説明
YAML の例
alb.ingress.kubernetes.io/canary-weightカナリア Service にルーティングするトラフィックの割合です。有効な値:0~100。
apiVersion: networking.k8s.io/v1 kind: Ingress metadata: annotations: alb.ingress.kubernetes.io/order: "3" alb.ingress.kubernetes.io/canary: "true" alb.ingress.kubernetes.io/canary-weight: "50" name: demo-canary-weight spec: ... ...
アノテーションによるセッション維持の設定
次のアノテーションを使用して、ALB Ingress のセッション維持を設定します。
アノテーションの例:
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: cafe-ingress-v3
annotations:
alb.ingress.kubernetes.io/sticky-session: "true"
alb.ingress.kubernetes.io/sticky-session-type: "Server" # カスタムクッキーを使用するには、このアノテーションを Server に設定します。
alb.ingress.kubernetes.io/cookie-timeout: "1800"
alb.ingress.kubernetes.io/cookie: "test"
spec:
... ...
|
パラメーター |
説明 |
デフォルト |
|
|
セッション維持を有効にするかどうかを指定します。
|
|
|
|
ロードバランサーがクッキーをどのように処理するかを指定します。
説明
|
|
|
|
クッキータイムアウト (秒) です。有効な値: 1〜86400。
|
1000 |
|
|
カスタムクッキーの値です。
|
"" |
負荷分散アルゴリズムの指定
アノテーションを使用して、バックエンドサーバーグループの負荷分散アルゴリズムを指定します。
|
パラメーター |
値 |
説明 |
|
|
|
|
加重ラウンドロビン:重みが大きいサーバーほど、より多くのリクエストを受け取ります。(デフォルト) |
|
|
|
重みと現在の接続数に基づいてリクエストを分散します。重みが等しい場合、接続数が最も少ないサーバーを選択します。 |
||
|
|
同じソース IP からのリクエストを同じバックエンドサーバーにルーティングします。 |
||
|
|
指定された URL パラメーターのハッシュに基づいてリクエストをルーティングします。
|
CORS 設定
次のアノテーションを使用して、ALB Ingress のオリジン間リソース共有 (CORS) を設定します。
アノテーションの例:
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: alb-ingress
annotations:
alb.ingress.kubernetes.io/enable-cors: "true"
alb.ingress.kubernetes.io/cors-expose-headers: ""
alb.ingress.kubernetes.io/cors-allow-methods: "GET,POST"
alb.ingress.kubernetes.io/cors-allow-credentials: "true"
alb.ingress.kubernetes.io/cors-max-age: "600"
alb.ingress.kubernetes.io/cors-allow-origin: "Allowed origin domain name"
spec:
... ...
|
パラメーター |
説明 |
デフォルト |
|
|
オリジン間リソース共有 (CORS) を有効にします。 |
デフォルト値: |
|
|
サーバー上のリソースにアクセスできるオリジンを指定します。 複数のオリジンを指定する場合は、コンマ (,) で区切ります。各値は |
|
|
|
オリジン間リクエストで許可する HTTP メソッドを指定します。 値は大文字と小文字を区別しません。複数の HTTP メソッドを指定する場合は、コンマ (,) で区切ります。 |
|
|
|
オリジン間リクエストで許可するリクエストヘッダーを指定します。 このパラメーターを
|
|
|
|
クライアントに公開するレスポンスヘッダーを指定します。 このパラメーターを
|
|
|
|
オリジン間リクエストに認証情報を含めるかどうかを指定します。 |
|
|
|
プリフライトレスポンスのキャッシュ期間 (秒) です。有効な値:0~172,800。 |
デフォルト値: |
バックエンドの永続的接続
バックエンドの永続的接続を使用すると、ALB はバックエンドサーバーへの TCP 接続を再利用でき、高スループットのシナリオで接続オーバーヘッドを削減できます。
|
パラメーター |
説明 |
YAML の例 |
|
|
バックエンドの永続的接続を有効にし、TCP 接続オーバーヘッドを削減します。 |
|
サーバーグループの IPv6 バックエンドアタッチメント
IPv6 バックエンドアタッチメントを使用すると、サーバーグループ内に IPv4 と IPv6 の両方の Pod を含めることができますが、デュアルスタッククラスターが必要です。詳細については、「ACK マネージドクラスターの作成」をご参照ください。
IPv6 バックエンドアタッチメントを有効にすると、次の制限があります:
-
サーバーグループで IPv6 バックエンドアタッチメントを有効にするには、そのサーバーグループの VPC で IPv6 が有効である必要があります。
-
IPv6 バックエンドアタッチメントは、カスタム転送アクションを使用してアタッチする場合、IP タイプまたは Function Compute タイプの各サーバーグループではサポートされていません。
-
Ingress が IPv4 専用の ALB インスタンスに関連付けられている場合、それらのサーバーグループの IPv6 バックエンドアタッチメントは有効にできません。
デュアルスタック用に Service と ALB Ingress を設定します。デュアルスタックの ALB インスタンスを作成した後、IPv4 と IPv6 の両方のバックエンドサーバーをサーバーグループにアタッチできます。
|
設定オブジェクト |
パラメーター |
値 |
説明 |
YAML の例 |
|
Service |
|
|
Service で利用可能な IP アドレスタイプを指定します。 |
|
|
|
|
Service の IP ポリシーを設定し、デュアルスタックネットワーキングを有効にします。 |
||
|
ALB Ingress |
|
|
サーバーグループの IPv6 バックエンドアタッチメントを有効にします。 |
|
QPS スロットリングの設定
転送ルールの QPS スロットリングを有効にするには、次のアノテーションを追加します。
|
アノテーション |
説明 |
YAML の例 |
|
|
転送ルールの QPS 制限を指定します。有効な値:1 ~ 1,000,000。 |
|
スロースタート
スロースタートは、新しく追加された Pod へのトラフィックを段階的に増やし、急激なトラフィック増加による過負荷を防ぎます。
|
パラメーター |
説明 |
YAML の例 |
|
|
スロースタートを有効にするかどうかを指定します。デフォルトでは無効です。
|
|
|
|
スロースタートのランプアップ期間 (秒) を指定します。有効な値: 30~900。デフォルト: 30。 |
コネクションドレイニング
Pod が Terminating 状態になると、ALB Ingress はそれをサーバーグループから削除しますが、既存の接続をすぐに閉じるわけではありません。これにより、リクエストエラーが発生したり、グレースフルシャットダウンが妨げられたりする可能性があります。コネクションドレイニングは、設定可能なタイムアウト期間にわたって既存の接続を開いたままにし、その後に閉じます。詳細については、「ALB Ingress でコネクションドレイニングを使用してServiceをグレースフルシャットダウンする」をご参照ください。
ALB Ingress は、コネクションのドレインが完了するまで Pod が実行され続けることを保証しません。 終了中の Pod の可用性を制御するには、spec.terminationGracePeriodSeconds を設定するか、preStop フックを使用することができます。
|
パラメーター |
説明 |
YAML の例 |
|
|
コネクションドレイニングを有効にするかどうかを指定します。
|
|
|
|
コネクションドレイニングタイムアウトを秒単位で指定します。有効な値:[0, 900]。デフォルト:300。 |
クロスゾーン負荷分散の無効化
ALB はデフォルトでアベイラビリティーゾーン間でトラフィックを分散します。クロスゾーン負荷分散を無効にすると、トラフィックは同じゾーン内のバックエンドサービスに制限されます。
クロスゾーン負荷分散を無効にする場合は、各アベイラビリティーゾーンに十分なバックエンドリソースがあることを確認してください。
クロスゾーン負荷分散を無効にするには、次の例を使用します。
|
パラメーター |
説明 |
YAML の例 |
|
|
クロスゾーン負荷分散を有効にするかどうかを指定します。デフォルトでは有効です。
|
|