ALB Ingress のアノテーションを設定して、ルーティング、HTTPS リダイレクト、ヘルスチェック、カナリアリリースを構成します。
前提条件
開始する前に、以下を確認してください:
-
インターネットにアクセスするための ACK サーバーレスクラスター、Virtual Private Cloud (VPC)、および NAT Gateway があること。
-
クラスターに kubectl が接続されている。
-
AlbConfig が作成されていること。
アノテーションのクイックリファレンス
ALB Ingress の機能は、metadata.annotations フィールドのアノテーションで設定されます。次の表は、サポートされているアノテーションをカテゴリ別に示しています。
| カテゴリ | アノテーション | 説明 |
|---|---|---|
| ヘルスチェック | alb.ingress.kubernetes.io/healthcheck-enabled |
ヘルスチェックを有効または無効にする |
alb.ingress.kubernetes.io/healthcheck-path |
ヘルスチェックパス | |
alb.ingress.kubernetes.io/healthcheck-protocol |
プロトコル:HTTP、HTTPS、TCP、GRPC |
|
alb.ingress.kubernetes.io/healthcheck-httpversion |
HTTP バージョン:HTTP1.0、HTTP1.1 |
|
alb.ingress.kubernetes.io/healthcheck-method |
メソッド:HEAD、POST、GET |
|
alb.ingress.kubernetes.io/healthcheck-code |
期待される状態コード (healthcheck-httpcode よりも優先) |
|
alb.ingress.kubernetes.io/healthcheck-httpcode |
期待される HTTP ステータスコード (1.19 より前のクラスター) | |
alb.ingress.kubernetes.io/healthcheck-timeout-seconds |
タイムアウト (秒) (1–300) | |
alb.ingress.kubernetes.io/healthcheck-interval-seconds |
チェック間隔 (秒) (1–50) | |
alb.ingress.kubernetes.io/healthy-threshold-count |
正常とマークするための連続成功回数 (2–10) | |
alb.ingress.kubernetes.io/unhealthy-threshold-count |
異常とマークするための連続失敗回数 (2–10) | |
alb.ingress.kubernetes.io/healthcheck-connect-port |
ヘルスチェック用のポート (0 = バックエンドポート) | |
| TLS / HTTPS | alb.ingress.kubernetes.io/ssl-redirect |
HTTP ポート 80 を HTTPS ポート 443 にリダイレクトする |
| バックエンドプロトコル | alb.ingress.kubernetes.io/backend-protocol |
バックエンドプロトコル:https、grpc |
| パスマッチング | alb.ingress.kubernetes.io/use-regex |
パスルールで正規表現を有効にする |
| 書き換え | alb.ingress.kubernetes.io/rewrite-target |
転送前にリクエストパスを書き換える |
| リスナーポート | alb.ingress.kubernetes.io/listen-ports |
カスタムリスナーポート、例:[{"HTTP": 80},{"HTTPS": 443}] |
| 転送優先度 | alb.ingress.kubernetes.io/order |
転送ルールの優先度 (1–1000; 値が小さいほど優先度が高い) |
| カナリアリリース | alb.ingress.kubernetes.io/canary |
カナリアルーティングを有効にする |
alb.ingress.kubernetes.io/canary-by-header |
リクエストヘッダー名でルーティングする | |
alb.ingress.kubernetes.io/canary-by-header-value |
ヘッダーの完全一致値でルーティングする | |
alb.ingress.kubernetes.io/canary-by-cookie |
クッキー名でルーティングする (always または never) |
|
alb.ingress.kubernetes.io/canary-weight |
カナリアにルーティングするトラフィックの割合 (0–100) | |
| セッション維持 | alb.ingress.kubernetes.io/sticky-session |
セッション維持を有効にする |
alb.ingress.kubernetes.io/sticky-session-type |
クッキーモード:Insert または Server |
|
alb.ingress.kubernetes.io/cookie-timeout |
クッキーのタイムアウト (秒) (1–86400) | |
alb.ingress.kubernetes.io/cookie |
カスタムクッキー名 (タイプが Server の場合に必須) |
|
| 負荷分散アルゴリズム | alb.ingress.kubernetes.io/backend-scheduler |
アルゴリズム:wrr、wlc、sch、uch |
alb.ingress.kubernetes.io/backend-scheduler-uch-value |
uch ハッシュ化のための URL パラメーター名 |
|
| CORS | alb.ingress.kubernetes.io/enable-cors |
オリジン間リソース共有 (CORS) を有効にする |
alb.ingress.kubernetes.io/cors-allow-origin |
許可されたオリジン | |
alb.ingress.kubernetes.io/cors-allow-methods |
許可された HTTP メソッド | |
alb.ingress.kubernetes.io/cors-allow-headers |
許可されたリクエストヘッダー | |
alb.ingress.kubernetes.io/cors-expose-headers |
ブラウザに公開されるヘッダー | |
alb.ingress.kubernetes.io/cors-allow-credentials |
認証情報を許可するかどうか | |
alb.ingress.kubernetes.io/cors-max-age |
プリフライトのキャッシュ期間 (秒) (−1–172800) | |
| バックエンド接続 | alb.ingress.kubernetes.io/backend-keepalive |
バックエンドの永続的な接続を有効にする |
| レート制限 | alb.ingress.kubernetes.io/traffic-limit-qps |
転送ルールごとの QPS 制限 (1–100,000) |
| スロースタート | alb.ingress.kubernetes.io/slow-start-enabled |
新しい Pod のスロースタートを有効にする |
alb.ingress.kubernetes.io/slow-start-duration |
ランプアップ期間 (秒) (30–900) | |
| 接続ドレイン | alb.ingress.kubernetes.io/connection-drain-enabled |
接続ドレインを有効にする |
alb.ingress.kubernetes.io/connection-drain-timeout |
ドレインタイムアウト (秒) (0–900) |
ドメイン名に基づくリクエストの転送
ドメイン名でリクエストを転送する Ingress を作成します。ALB Ingress は、標準ドメイン名と空のドメイン名をサポートしています。
標準ドメイン名に基づくリクエストの転送
次の例では、ルーティングパスを /hello に設定します。demo.domain.ingress.top/hello へのリクエストは、バックエンドのサービスに転送されます。
-
次のテンプレートをデプロイして、サービス、デプロイメント、および Ingress を作成します。リクエストは、Ingress のドメイン名を通じてサービスに転送されます。
-
ルーティングをテストします。
ADDRESSを ALB インスタンスのドメイン名に置き換えます (kubectl get ingを使用して取得します)。curl -H "host: demo.domain.ingress.top" <ADDRESS>/hello期待される出力:
{"hello":"coffee"}
空のドメイン名に基づくリクエストの転送
host フィールドが空の場合、Ingress はドメインに関係なくすべてのリクエストに一致します。次の例では、<ADDRESS>/hello へのリクエストをバックエンドのサービスにルーティングします。
-
次のテンプレートをデプロイして Ingress を作成します。
-
ルーティングをテストします。
ADDRESSを ALB インスタンスのドメイン名に置き換えます。curl <ADDRESS>/hello期待される出力:
{"hello":"coffee"}
URL パスに基づくリクエストの転送
ALB Ingress は、pathType フィールドを使用して URL パスに基づいてリクエストを転送します。3 つのマッチングタイプがサポートされています:
pathType |
動作 |
|---|---|
Prefix |
パスのプレフィックスに一致します。セグメントごとに、大文字と小文字を区別します |
Exact |
完全一致のみ |
ImplementationSpecific |
ALB Ingress コントローラーによって完全一致 (Exact) として処理されます。path が設定されていない場合、ALB はデフォルトとして / を使用します |
pathType が Exact または Prefix に設定されている場合、path は空でない絶対パスである必要があります。そうでない場合、Ingress の作成は検証エラーで失敗します。複数の URL マッチングルールが競合する場合、ALB は転送ルールの優先度によってそれらを評価します。
パスマッチングのリファレンス
シンプルなパス (`/`, `/foo`, `/foo/`)
| マッチングタイプ | ルールパス | リクエストパス | 一致したか? |
|---|---|---|---|
| Prefix | / |
/ (すべてに一致) |
はい |
| Prefix | /foo |
/foo |
はい |
| Prefix | /foo |
/foo/ |
はい |
| Prefix | /foo/ |
/foo |
はい |
| Prefix | /foo/ |
/foo/ |
はい |
| Prefix | /aaa |
/ccc |
いいえ — プレフィックスが一致しません |
| Exact または ImplementationSpecific | /foo |
/foo |
はい |
| Exact または ImplementationSpecific | /foo |
/bar |
いいえ |
| Exact または ImplementationSpecific | /foo |
/foo/ |
いいえ |
| Exact または ImplementationSpecific | /foo/ |
/foo |
いいえ |
階層的なパス (`/aaa/bb`, `/aaa/bbb`, `/aaa/bbb/`)
| マッチングタイプ | ルールパス | リクエストパス | 一致したか? |
|---|---|---|---|
| Prefix | /aaa/bb |
/aaa/bbb |
いいえ |
| Prefix | /aaa/bbb |
/aaa/bbb |
はい |
| Prefix | /aaa/bbb/ |
/aaa/bbb |
はい — ルールの末尾のスラッシュは無視されます |
| Prefix | /aaa/bbb |
/aaa/bbb/ |
はい — リクエストの末尾のスラッシュは一致します |
| Prefix | /aaa/bbb |
/aaa/bbb/ccc |
はい — サブパスが一致します |
複数のルールパス
| マッチングタイプ | ルールパス | リクエストパス | 一致したか? |
|---|---|---|---|
| Prefix | /、/aaa |
/aaa/ccc |
はい — / プレフィックスに一致します |
| Prefix | /aaa、/ |
/aaa/ccc |
はい — /aaa プレフィックスに一致します |
| Prefix | /aaa、/ |
/ccc |
はい — / プレフィックスに一致します |
| Prefix | /aaa、/bbb |
/ccc |
いいえ — プレフィックスが一致しません |
プレフィックスマッチ (Prefix)
プレフィックスマッチングは、/ で区切られたパスセグメントを比較し、大文字と小文字を区別します。次の例では、ルールパスを / に設定しており、これは /hello を含むすべてのパスに一致します。
-
次のテンプレートをデプロイして Ingress を作成します。
-
ルーティングをテストします。
ADDRESSを ALB インスタンスのドメイン名に置き換えます。curl <ADDRESS>/hello期待される出力:
{"hello":"coffee"}
完全一致 (Exact または ImplementationSpecific)
次の例では、ルールパスを /hello に設定します。完全なパス /hello のみが一致します。
-
次のテンプレートをデプロイして Ingress を作成します。
-
ルーティングをテストします。
ADDRESSを ALB インスタンスのドメイン名に置き換えます。curl <ADDRESS>/hello期待される出力:
{"hello":"coffee"}
HTTP から HTTPS へのリダイレクト
alb.ingress.kubernetes.io/ssl-redirect: "true" アノテーションを追加して、HTTP リクエストを HTTPS ポート 443 にリダイレクトします。
このアノテーションは、リスナーポート 80 の HTTP 転送ルールにのみ適用されます。この機能は、RemoveHeader、InsertHeader、およびクロスドメイン CORS アノテーションでのみ機能します。このアノテーションを追加する前に、AlbConfig で ポート 443 に HTTPS リスナーを設定してください。
Kubernetes 1.19 以降を実行するクラスター
apiVersion: v1
kind: Service
metadata:
name: demo-service-ssl
namespace: default
spec:
ports:
- name: port1
port: 80
protocol: TCP
targetPort: 8080
selector:
app: demo-ssl
sessionAffinity: None
type: ClusterIP
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: demo-ssl
namespace: default
spec:
replicas: 1
selector:
matchLabels:
app: demo-ssl
template:
metadata:
labels:
app: demo-ssl
spec:
containers:
- image: registry.cn-hangzhou.aliyuncs.com/alb-sample/cafe:v1
imagePullPolicy: IfNotPresent
name: demo-ssl
ports:
- containerPort: 8080
protocol: TCP
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
annotations:
alb.ingress.kubernetes.io/ssl-redirect: "true"
name: demo-ssl
namespace: default
spec:
ingressClassName: alb
tls:
- hosts:
- ssl.alb.ingress.top
rules:
- host: ssl.alb.ingress.top
http:
paths:
- backend:
service:
name: demo-service-ssl
port:
number: 80
path: /
pathType: Prefix
Kubernetes 1.19 より前のバージョンを実行するクラスター
apiVersion: v1
kind: Service
metadata:
name: demo-service-ssl
namespace: default
spec:
ports:
- name: port1
port: 80
protocol: TCP
targetPort: 8080
selector:
app: demo-ssl
sessionAffinity: None
type: ClusterIP
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: demo-ssl
namespace: default
spec:
replicas: 1
selector:
matchLabels:
app: demo-ssl
template:
metadata:
labels:
app: demo-ssl
spec:
containers:
- image: registry.cn-hangzhou.aliyuncs.com/alb-sample/cafe:v1
imagePullPolicy: IfNotPresent
name: demo-ssl
ports:
- containerPort: 8080
protocol: TCP
---
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
annotations:
alb.ingress.kubernetes.io/ssl-redirect: "true"
name: demo-ssl
namespace: default
spec:
ingressClassName: alb
tls:
- hosts:
- ssl.alb.ingress.top
rules:
- host: ssl.alb.ingress.top
http:
paths:
- backend:
serviceName: demo-service-ssl
servicePort: 80
path: /
pathType: Prefix
ヘルスチェックの設定
次のアノテーションを使用して、バックエンドサーバーグループのヘルスチェックを設定します。
バックエンドプロトコルとしての HTTPS と gRPC の使用
alb.ingress.kubernetes.io/backend-protocol アノテーションを追加して、バックエンドプロトコルとして HTTPS または gRPC を使用します。
Ingress が作成された後、バックエンドプロトコルは変更できません。プロトコルを切り替えるには、Ingress を削除して新しいものを作成してください。
Ingress を介して gRPC トラフィックを転送する場合、ドメイン名に TLS 証明書を設定し、通信に TLS を使用してください。
| アノテーション | 値 | 説明 |
|---|---|---|
alb.ingress.kubernetes.io/backend-protocol |
https |
バックエンドサービスは HTTPS を使用します |
grpc |
バックエンドサービスは gRPC を使用します。ドメイン名に TLS 設定が必要です |
正規表現の設定
alb.ingress.kubernetes.io/use-regex: "true" アノテーションを使用して、パスルールで正規表現マッチングを有効にします。このアノテーションは、pathType: Prefix を持つパスルールにのみ適用されます。
| アノテーション | 説明 |
|---|---|
alb.ingress.kubernetes.io/use-regex: "true" |
パスルールで正規表現を有効にします |
alb.ingress.kubernetes.io/conditions.<YOUR-SVC-NAME> |
カスタム転送条件を設定します。<YOUR-SVC-NAME> を実際のサービス名に置き換えます。このサービス名は backend.service.name |
正規表現マッチングルール:
| ターゲット | プレフィックス | ルール例 | クライアントパス | 一致したか? | 注意 |
|---|---|---|---|---|---|
| ドメイン名 | ~ |
~test.example.com |
test.EXAMPLE.com |
はい | ドメイン名は、大文字と小文字を区別しないマッチングをサポートします |
| パス | ~ |
~/api |
/API |
はい | 大文字と小文字を区別しないマッチング |
| パス | ~* |
~*/api |
/Api |
いいえ | 大文字と小文字を区別するマッチング |
書き換えの設定
ALB Ingress は、転送前にリクエストパスを書き換えます。2 つのアノテーションが書き換えの動作を制御します:
-
alb.ingress.kubernetes.io/rewrite-target: /<path>/${number}— 書き換えを有効にし、ターゲットパスを設定します。${number}形式を使用して、元のパスからキャプチャグループを参照します (最大 3 つのグループ:${1}、${2}、${3})。pathTypeはPrefixである必要があります。 -
alb.ingress.kubernetes.io/use-regex— パスで正規表現を使用するかどうかを指定します。rewrite-targetが設定されている場合、自動的に有効になります。"false"に設定して無効にすることもできます。正規表現が無効な場合、特殊文字 (%#;!()[]^,"\") を含むパスは作成できないことに注意してください。
シナリオ 1:プレフィックスの削除
パス path: /something(/|$)(.*) は 3 つのキャプチャグループを使用します:
-
/something— 削除するプレフィックスに一致します -
(/|$)— 最初のグループ:/またはパスの末尾に一致します -
(.*)— 2 番目のグループ:/something/の後にあるすべてをキャプチャし、書き換えターゲットで${2}として参照されます
書き換えターゲット / + ${2} は /something プレフィックスを削除します:
| 元のパス | 一致したか? | 書き換えられたパス |
|---|---|---|
/something |
はい (2 番目のグループは空です) | / |
/something/ |
はい (2 番目のグループは空です) | / |
/something/new |
はい (2 番目のグループ:new) |
/new |
/something-new/item |
いいえ | 503 |
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: rewrite-ingress
annotations:
alb.ingress.kubernetes.io/use-regex: "true"
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/(.*)/(.*)/(.*) は 3 つのセグメントをキャプチャします。書き換えターゲット /${2}?code=${3} は、2 番目と 3 番目のグループを使用して URL を再構築します。
このパターンには、正確に 4 つのパスセグメントが必要です。クライアントは固定のパス形式を使用する必要があります。
| 元のパス | 一致したか? | 書き換えられたパス |
|---|---|---|
/items/electronics/computers/554 |
はい (グループ 2:computers、グループ 3:554) |
/computers?code=554 |
/items/produce/fruits/12 |
はい (グループ 2:fruits、グループ 3:12) |
/fruits?code=12 |
/items/headphones/5 |
いいえ | 503 |
/drinks/41 |
いいえ | 503 |
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: rewrite-ingress
annotations:
alb.ingress.kubernetes.io/use-regex: "true"
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} → /app-c/${2} を持つ 2 つのパスルールを定義することで実現します。
| 元のパス | 一致したか? | 書き換えられたパス |
|---|---|---|
/app-a/item1 |
はい (グループ 2:item1) |
/app-c/item1 |
/app-a/item2 |
はい (グループ 2:item2) |
/app-c/item2 |
/app-a または /app-a/ |
はい (グループ 2 は空です) | /app-c/ |
/drinks/41 |
いいえ | 503 |
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: rewrite-ingress
annotations:
alb.ingress.kubernetes.io/use-regex: "true"
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:ドメイン名の書き換え
rewrite-target アノテーションはパスのみを書き換えます。ドメイン名やクエリパラメーターなど、URL の他の部分を書き換えるには、カスタム転送ルールを使用します。
ローカルでの書き換えルールの検証
デプロイする前に、sed を使用してパスの正規表現マッチをテストし、書き換えられた結果をプレビューします。
次の例では、シナリオ 2 のパス正規表現 /items/(.*)/(.*)/(.*) と書き換えルール /${2}?code=${3} をテストします。
-
テストパスを
path2.txtに保存します:/items/electronics/computers/554 /items/produce/fruits/12 /items/headphones/5 /drinks/41 -
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
カスタムリスナーポートの設定
alb.ingress.kubernetes.io/listen-ports アノテーションを使用して、HTTP 80 や HTTPS 443 などの複数のポートでサービスを公開します。
ALB は Ingress からリスナーを作成しません。まず AlbConfig で必須のリスナーポートとプロトコルを作成してから、Ingress に関連付けます。
| アノテーション | 説明 |
|---|---|
alb.ingress.kubernetes.io/listen-ports: '[{"HTTP": 80},{"HTTPS": 443}]' |
サービスがポート 80 とポート 443 の両方でリッスンするように設定します |
転送ルールの優先度の設定
デフォルトでは、ALB は転送ルールを次の順序でソートします:
-
Ingress 間:
namespace/nameの辞書順でソートされます。値が小さいほど優先度が高くなります。最初に名前空間が比較され、次に名前が比較されます。 -
同じ Ingress 内:
rulesフィールドの順序でソートされます。先にリストされているルールほど優先度が高くなります。rules: - host: www.example.com # 優先度が高い http: ... - host: www.test.com # 優先度が低い http: ...
Ingress の名前を変更せずにデフォルトのソート順をオーバーライドするには、alb.ingress.kubernetes.io/order アノテーションを使用します。
同じリスナー内の優先度は一意でなければなりません。
| アノテーション | 範囲 | デフォルト | 説明 |
|---|---|---|---|
alb.ingress.kubernetes.io/order |
[1, 1000] | 10 | 転送ルールの優先度。値が小さいほど優先度が高くなります |
アノテーションを使用したカナリアリリースの実装
ALB は、リクエストヘッダー、クッキー、およびトラフィックの重みに基づくカナリアリリースをサポートしています。本番 Ingress とは別に、カナリア Ingress を作成します。
カナリアルーティングの優先度:ヘッダー > クッキー > 重み (高い順)。
カナリアリリース中は、本番 Ingress を削除しないでください。カナリアリリースの検証後、本番 Ingress のバックエンドサービスを更新して新しいバージョンを指すようにし、その後カナリア Ingress を削除します。
「ALB イングレスを使用して段階的リリースを実装する」をご参照ください。
ヘッダーによるルーティング
canary-by-header と canary-by-header-value を一緒に使用して、特定のヘッダー値に一致するリクエストをカナリアサービスにルーティングします。一致しないリクエストは、次のカナリアルール (クッキーまたは重み) にフォールスルーします。
この設定では、location: hz を持つリクエストはカナリアサービスにルーティングされます。他のすべてのリクエストは、次のカナリアルールにフォールスルーします。
| アノテーション | 説明 |
|---|---|
alb.ingress.kubernetes.io/canary-by-header |
一致させるリクエストヘッダー名 |
alb.ingress.kubernetes.io/canary-by-header-value |
一致させるヘッダーの完全な値。両方のアノテーションを一緒に設定する必要があります |
クッキーによるルーティング
canary-by-cookie を使用して、クッキー名に基づいてリクエストをルーティングします。クッキーの値を always に設定すると常にカナリアサービスにルーティングされ、never に設定すると常に除外されます。
この設定では、Cookie: demo=always を持つリクエストはカナリアサービスにルーティングされます。Cookie: demo=never を持つリクエストは、カナリアサービスを完全にバイパスします。
| アノテーション | 値 | 説明 |
|---|---|---|
alb.ingress.kubernetes.io/canary-by-cookie |
always |
すべてのリクエストがカナリアサービスにルーティングされます |
never |
カナリアサービスにルーティングされるリクエストはありません |
クッキーベースのカナリアルーティングは、always と never のみをサポートします。カスタムクッキー値はサポートされていません。
重みによるルーティング
canary-weight を使用して、トラフィックの一定の割合をカナリアサービスに送信します。次の例では、トラフィックの 50% をカナリアにルーティングします:
| アノテーション | 範囲 | 説明 |
|---|---|---|
alb.ingress.kubernetes.io/canary-weight |
0–100 | カナリアサービスにルーティングされるリクエストの割合 |
アノテーションを使用したセッション維持の実装
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: "Insert" # カスタムクッキーには "Server" を使用
alb.ingress.kubernetes.io/cookie-timeout: "1800"
alb.ingress.kubernetes.io/cookie: "test"
spec:
...
| アノテーション | 説明 | デフォルト |
|---|---|---|
alb.ingress.kubernetes.io/sticky-session |
セッション維持を有効にする:true または false |
false |
alb.ingress.kubernetes.io/sticky-session-type |
クッキー処理モード。 Insert: ALB が SERVERID クッキーを挿入し、後続のリクエストを同じバックエンドにルーティングします。 Server: ALB がルーティング用にカスタムクッキーを書き換えます。 サーバーグループで StickySessionEnabled を true に設定する必要があります。 詳細については「サーバーグループの作成 |
Insert |
alb.ingress.kubernetes.io/cookie-timeout |
クッキーのタイムアウト (秒)。範囲:[1, 86400]。sticky-session-type が Insert |
1000 |
alb.ingress.kubernetes.io/cookie |
カスタムクッキー名。sticky-session-type が Server |
"" |
負荷分散アルゴリズムの指定
alb.ingress.kubernetes.io/backend-scheduler アノテーションを使用して、バックエンドサーバーグループの負荷分散アルゴリズムを設定します。
| 値 | アルゴリズム | 説明 |
|---|---|---|
wrr |
加重ラウンドロビン | 重みが大きいバックエンドサーバーほど多くのリクエストを受け取ります。デフォルトのアルゴリズム |
wlc |
加重最小接続 | アクティブな接続数が最も少ないサーバーにルーティングし、サーバーの重みで加重します |
sch |
送信元 IP 一貫性ハッシュ | 同じクライアント IP からのリクエストを同じバックエンドサーバーにルーティングします |
uch |
URL パラメーター一貫性ハッシュ | URL パラメーターのハッシュでルーティングします。alb.ingress.kubernetes.io/backend-scheduler-uch-value |
オリジン間リソース共有 (CORS) の設定
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"
spec:
ingressClassName: alb
rules:
- host: demo.alb.ingress.top
http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: cloud-nodeport
port:
number: 80
| アノテーション | 説明 | デフォルト |
|---|---|---|
alb.ingress.kubernetes.io/cors-allow-origin |
許可されたオリジン。http:// または https:// で始まり、有効なドメインまたはトップレベルのワイルドカードドメインが続く必要があります。複数のオリジンはカンマで区切ります。例:"https://example.com:4443, http://aliyundoc.com, https://example.org:1199" |
* |
alb.ingress.kubernetes.io/cors-allow-methods |
許可されたクロスオリジンメソッド。大文字と小文字を区別しません。複数のメソッドはカンマで区切ります。例:"PUT, GET, POST, OPTIONS" |
GET, PUT, POST, DELETE, PATCH, OPTIONS |
alb.ingress.kubernetes.io/cors-allow-headers |
許可されたリクエストヘッダー。ヘッダーには、文字、数字、アンダースコア (_)、およびハイフン (-) を含めることができます。複数のヘッダーはカンマで区切ります。例:"X-Forwarded-For, X-app123-XPTO" |
DNT,X-CustomHeader,Keep-Alive,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Authorization |
alb.ingress.kubernetes.io/cors-expose-headers |
ブラウザに公開されるヘッダー。文字、数字、アンダースコア (_)、ハイフン (-)、およびアスタリスク (*) を含めることができます。複数のヘッダーはカンマで区切ります。例:"*, X-CustomResponseHeader" |
空 |
alb.ingress.kubernetes.io/cors-allow-credentials |
クロスオリジンリクエストで認証情報を許可するかどうか。例:"false" |
true |
alb.ingress.kubernetes.io/cors-max-age |
OPTIONS プリフライト応答の最大キャッシュ期間 (秒)。範囲:[−1, 172800] | 172800 |
バックエンドの永続的な接続の有効化
バックエンドの永続的な接続は、バックエンドサーバーへの TCP 接続を再利用し、リクエストごとに接続を開閉するオーバーヘッドを削減します。
この機能を有効にするには、alb.ingress.kubernetes.io/backend-keepalive: "true" アノテーションを追加します:
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: alb-ingress
annotations:
alb.ingress.kubernetes.io/backend-keepalive: "true"
spec:
ingressClassName: alb
rules:
- host: demo.alb.ingress.top
http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: cloud-nodeport
port:
number: 80
QPS レート制限の設定
alb.ingress.kubernetes.io/traffic-limit-qps アノテーションを追加して、転送ルールレベルで QPS の速度制限を設定します:
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: cafe-ingress
annotations:
alb.ingress.kubernetes.io/traffic-limit-qps: "50"
spec:
ingressClassName: alb
rules:
- host: demo.alb.ingress.top
http:
paths:
- path: /tea
pathType: ImplementationSpecific
backend:
service:
name: tea-svc
port:
number: 80
- path: /coffee
pathType: ImplementationSpecific
backend:
service:
name: coffee-svc
port:
number: 80
| アノテーション | 範囲 | 説明 |
|---|---|---|
alb.ingress.kubernetes.io/traffic-limit-qps |
[1, 100,000] | 転送ルールの最大 QPS |
新しい Pod のスロースタートの設定
スロースタートは、設定された期間にわたって新しい Pod へのトラフィックを徐々に増加させ、コールド Pod に完全なトラフィックがヒットすることによる一時的な CPU またはメモリのスパイクを防ぎます。
| アノテーション | 説明 | デフォルト |
|---|---|---|
alb.ingress.kubernetes.io/slow-start-enabled |
スロースタートを有効にする:true または false |
false |
alb.ingress.kubernetes.io/slow-start-duration |
ランプアップ期間 (秒)。期間が長いほど、トラフィックの増加が遅くなります。範囲:[30, 900] | 30 |
接続ドレインの設定
Pod が Terminating 状態に入ると、ALB はそれをバックエンドサーバーグループから削除します。接続ドレインがない場合、既存の接続上の処理中のリクエストが失敗する可能性があります。
接続ドレインは、設定された期間、アクティブな接続を開いたままにし、Pod がオフラインになる前に処理中のリクエストが完了できるようにします。
ドレインタイムアウトが終了する前に、ALB は Pod が正常な状態を維持することを保証できません。Pod で spec.terminationGracePeriodSeconds を設定するか、preStop フックを使用して、Terminating 状態における Pod の可用性をコントロールします。
詳細については、「ALB の接続ドレインによるスムーズな業務のオフライン化」をご参照ください。
| アノテーション | 説明 | デフォルト |
|---|---|---|
alb.ingress.kubernetes.io/connection-drain-enabled |
接続ドレインを有効にする:true または false |
false |
alb.ingress.kubernetes.io/connection-drain-timeout |
Pod が削除されたり、ヘルスチェックに失敗したりした後、ALB が接続を閉じるまでに待機する最大時間 (秒)。範囲:[0, 900] | 300 |