Application Load Balancer (ALB) Ingress は、Kubernetes クラスター内のサービスへの外部アクセスを管理するためのレイヤー 7 の負荷分散を提供する API オブジェクトです。 このトピックでは、Alibaba Cloud Container Compute Service (ACS) クラスターで ALB Ingress を使用して、ドメイン名と URL パスに基づいてバックエンドサーバーグループにリクエストを転送し、HTTP リクエストを HTTPS にリダイレクトし、カナリアリリースを実装する方法について説明します。
前提条件
ACS クラスターが作成されていること。 詳細については、「ACS クラスターの作成」をご参照ください。
AlbConfig オブジェクトが作成されていること。 詳細については、「ALB Ingress の概要」をご参照ください。
ドメイン名に基づくリクエストの転送
次の手順を実行して、ドメイン名を持つ Ingress とドメイン名のない Ingress を作成し、それらの Ingress を使用してリクエストを転送します。
通常のドメインに基づくリクエストの転送
次のテンプレートを使用して、Deployment、Service、および Ingress を作成します。 Ingress のドメイン名へのリクエストは Service に転送されます。
apiVersion: v1 kind: Service metadata: name: demo-service namespace: default spec: ports: - name: port1 port: 80 protocol: TCP targetPort: 8080 selector: app: demo sessionAffinity: None type: ClusterIP --- apiVersion: apps/v1 kind: Deployment metadata: name: demo namespace: default spec: replicas: 1 selector: matchLabels: app: demo template: metadata: labels: app: demo spec: containers: - image: registry.cn-hangzhou.aliyuncs.com/alb-sample/cafe:v1 imagePullPolicy: IfNotPresent name: demo ports: - containerPort: 8080 protocol: TCP --- apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: demo namespace: default spec: ingressClassName: alb rules: - host: demo.domain.ingress.top http: paths: - backend: service: name: demo-service port: number: 80 path: /hello pathType: ImplementationSpecific次のコマンドを実行して、指定されたドメイン名を使用してアプリケーションにアクセスします。
[ADDRESS] を ALB インスタンスのドメイン名に置き換えます。これは
kubectl get ingコマンドを実行して取得できます。curl -H "host: demo.domain.ingress.top" <ADDRESS>/hello期待される出力:
{"hello":"coffee"}
ドメイン名なしの Ingress の作成
次のテンプレートは、Ingress の構成を示しています。
apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: demo namespace: default spec: ingressClassName: alb rules: - host: "" http: paths: - backend: service: name: demo-service port: number: 80 path: /hello次のコマンドを実行して、ドメイン名を使用してアプリケーションにアクセスします。
[ADDRESS] を ALB インスタンスのドメイン名に置き換えます。 このドメイン名は、
kubectl get ingコマンドを実行して取得できます。curl <ADDRESS>/hello期待される出力:
{"hello":"coffee"}
URL パスに基づくリクエストの転送
ALB Ingress は、URL パスに基づいてリクエストを転送できます。 pathType フィールドを設定して、URL 一致ポリシーを指定できます。 pathType は、Exact、ImplementationSpecific (デフォルト)、および Prefix の 3 つの一致タイプをサポートしています。
URL 一致ポリシーは互いに競合する可能性があります。 競合する URL 一致ポリシーが存在する場合、リクエストはポリシーの優先度の降順でこれらのポリシーと照合されます。 詳細については、「転送ルールの優先度の設定」をご参照ください。
一致モード | ルール | URL パス | URL パスがルールに一致するかどうか |
プレフィックス | / | (すべてのパス) | はい |
プレフィックス | /foo |
| はい |
プレフィックス | /foo/ |
| はい |
プレフィックス | /aaa/bb | /aaa/bbb | いいえ |
プレフィックス | /aaa/bbb | /aaa/bbb | はい |
プレフィックス | /aaa/bbb/ | /aaa/bbb | はい。 URL パスは、ルールの末尾のスラッシュ (/) を無視します。 |
プレフィックス | /aaa/bbb | /aaa/bbb/ | はい。 ルールは、URL パスの末尾のスラッシュ (/) に一致します。 |
プレフィックス | /aaa/bbb | /aaa/bbb/ccc | はい。 ルールは、URL パスのサブパスに一致します。 |
プレフィックス | 同時に 2 つのルールを設定します:
| /aaa/ccc | はい。 リクエストパスは、ルールパスの |
プレフィックス | 同時に 2 つのルールを設定します:
| /aaa/ccc | はい。 リクエストパスは、ルールパスの |
プレフィックス | 同時に 2 つのルールを設定します:
| /ccc | はい。 リクエストパスは、ルールパスの |
プレフィックス | /aaa | /ccc | いいえ |
Exact または ImplementationSpecific | /foo | /foo | はい |
Exact または ImplementationSpecific | /foo | /bar | いいえ |
Exact または ImplementationSpecific | /foo | /foo/ | いいえ |
Exact または ImplementationSpecific | /foo/ | /foo | いいえ |
3 つの一致方法の例を次に示します。
Exact
次のテンプレートは、Ingress の構成を示しています。
apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: demo-path namespace: default spec: ingressClassName: alb rules: - http: paths: - path: /hello backend: service: name: demo-service port: number: 80 pathType: Exact次のコマンドを実行して、アプリケーションにアクセスします。
[ADDRESS] を ALB インスタンスのドメイン名に置き換えます。 ドメイン名は
kubectl get ingコマンドを実行して取得できます。curl <ADDRESS>/hello期待される出力:
{"hello":"coffee"}
ImplementationSpecific: デフォルトの一致ポリシー
ALB Ingress では、このポリシーは Exact ポリシーと同じ方法で処理されます。
次のテンプレートは、Ingress の構成を示しています。
apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: demo-path namespace: default spec: ingressClassName: alb rules: - http: paths: - path: /hello backend: service: name: demo-service port: number: 80 pathType: ImplementationSpecific次のコマンドを実行して、アプリケーションにアクセスします。
[ADDRESS] を ALB インスタンスのドメイン名に置き換えます。これは
kubectl get ingコマンドを実行して取得できます。curl <ADDRESS>/hello期待される出力:
{"hello":"coffee"}
Prefix
このポリシーは、/ で区切られた URL パス要素に対して、大文字と小文字を区別するプレフィックスマッチを実行します。
次のテンプレートは、Ingress の構成を示しています。
apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: demo-path-prefix namespace: default spec: ingressClassName: alb rules: - http: paths: - path: / backend: service: name: demo-service port: number: 80 pathType: Prefix次のコマンドを実行して、アプリケーションにアクセスします。
[ADDRESS] を ALB インスタンスのドメイン名に置き換えます。これは
kubectl get ingコマンドを実行して取得できます。curl <ADDRESS>/hello期待される出力:
{"hello":"coffee"}
ヘルスチェックの設定
次のアノテーションを使用して、ALB Ingress のヘルスチェックを設定できます。 次の YAML テンプレートは、ヘルスチェックが有効になっている Ingress を作成する方法の例を示しています。
次の YAML テンプレートは、ヘルスチェックが有効になっている 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-method: "HEAD"
alb.ingress.kubernetes.io/healthcheck-httpcode: "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:
ingressClassName: alb
rules:
- http:
paths:
# コンテキストパスを設定します。
- path: /tea
backend:
service:
name: tea-svc
port:
number: 80
# コンテキストパスを設定します。
- path: /coffee
backend:
service:
name: coffee-svc
port:
number: 80次の表に、YAML テンプレートのパラメーターを示します。
パラメーター | 説明 |
alb.ingress.kubernetes.io/healthcheck-enabled | (オプション) ヘルスチェックを有効にするかどうかを指定します。 デフォルトでは、この機能は無効 (false) になっています。 |
alb.ingress.kubernetes.io/healthcheck-path | オプション。 ヘルスチェックが実行される URL パス。 デフォルト値: /。
|
alb.ingress.kubernetes.io/healthcheck-protocol | オプション。 ヘルスチェックに使用されるプロトコル。
|
alb.ingress.kubernetes.io/healthcheck-method | オプション。 ヘルスチェックに使用されるリクエストメソッド。
|
alb.ingress.kubernetes.io/healthcheck-httpcode | バックエンドサーバーがヘルスチェックに合格したときに返されるステータスコード。 有効な値: http_2xx (デフォルト)、http_3xx、http_4xx、および http_5xx。 |
alb.ingress.kubernetes.io/healthcheck-timeout-seconds | ヘルスチェックのタイムアウト期間。 バックエンドサーバーが指定されたタイムアウト期間内に応答しない場合、サーバーはヘルスチェックに失敗します。 有効な値: 1~300。 デフォルト値: 5。 単位: 秒。 |
alb.ingress.kubernetes.io/healthcheck-interval-seconds | 2 つの連続するヘルスチェックの間隔。 単位: 秒。 有効な値: 1~50。 デフォルト値: 2。 単位: 秒。 |
alb.ingress.kubernetes.io/healthy-threshold-count | 異常なバックエンドサーバーが正常と見なされるまでに連続してヘルスチェックに合格する必要がある回数。 有効な値: 2~10。 デフォルト値: 3。 |
alb.ingress.kubernetes.io/unhealthy-threshold-count | 正常なバックエンドサーバーが異常と見なされるまでに連続してヘルスチェックに失敗する必要がある回数。 有効な値: 2~10。 デフォルト値: 3。 |
HTTP リクエストから HTTPS リクエストへのリダイレクトの設定
ALB Ingress で alb.ingress.kubernetes.io/ssl-redirect: "true" アノテーションを設定して、HTTP リクエストを HTTPS ポート 443 にリダイレクトできます。
ALB Ingress を使用してリスナーを作成することはできません。 ALB Ingress が期待どおりに機能するようにするには、AlbConfig でリスナーのポートとプロトコルを指定し、リスナーを ALB Ingress のサービスに関連付ける必要があります。 ALB リスナーの作成方法の詳細については、「AlbConfig を使用して ALB リスナーを設定する」をご参照ください。
例:
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バックエンドプロトコルとして HTTPS または gRPC を設定する
ALB は、バックエンドプロトコルとして HTTPS と gRPC をサポートしています。 ALB Ingress のバックエンドプロトコルを設定するには、alb.ingress.kubernetes.io/backend-protocol: "grpc" または alb.ingress.kubernetes.io/backend-protocol: "https" アノテーションを設定するだけです。 Ingress を使用して gRPC サービスを転送するには、対応するドメイン名に SSL 証明書があり、TLS プロトコルを使用している必要があります。 次の例は、gRPC プロトコルのサンプル構成を示しています。
バックエンドプロトコルは変更できません。 プロトコルを変更するには、Ingress を削除して再構築してください。
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
annotations:
alb.ingress.kubernetes.io/backend-protocol: "grpc"
name: lxd-grpc-ingress
spec:
ingressClassName: alb
tls:
- hosts:
- demo.alb.ingress.top
rules:
- host: demo.alb.ingress.top
http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: grpc-demo-svc
port:
number: 9080正規表現の設定
カスタム転送条件を設定するには、path フィールドに正規表現を記述します。 次の例は、サンプル構成を示しています。
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
annotations:
alb.ingress.kubernetes.io/use-regex: "true" # path フィールドで正規表現をサポートします。
alb.ingress.kubernetes.io/conditions.service-a: | # アノテーションで指定された Service はクラスター内に存在する Service である必要があり、Service 名は rule フィールドの backend の Service 名と同じである必要があります。
[{
"type": "Path",
"pathConfig": {
"values": [
"~*^/pathvalue1", # 正規表現は正規表現フラグ ~ * に従う必要があります。
"/pathvalue2" # 完全一致の場合、パスの前に ~ * を追加する必要はありません。
]
}
}]
name: ingress-example
spec:
ingressClassName: alb
rules:
- http:
paths:
- path: /test
pathType: Prefix
backend:
service:
name: service-a
port:
number: 88書き換えルールの設定
ALB は書き換え機能をサポートしています。 ALB Ingress でこの機能を設定するには、alb.ingress.kubernetes.io/rewrite-target: /path/${2} アノテーションを追加します。 次のルールが適用されます。
rewrite-targetアノテーションでは、${number}形式の変数を、pathType が Prefix に設定されているpathで設定する必要があります。デフォルトでは、
*や?などの正規表現記号をpathフィールドで使用することはできません。 正規表現記号を使用するには、rewrite-targetアノテーションを設定する必要があります。pathは/で始まる必要があります。
書き換えルールで正規表現を指定する場合は、次の点に注意してください。
Ingress の
pathフィールドには、複数の括弧()を含む 1 つ以上の正規表現を記述できます。 ただし、rewrite-targetアノテーションの書き換えパスでは、最大 3 つの変数${1}、${2}、および${3}を使用できます。正規表現に一致する変数が連結されて、元のパスを上書きするパスが形成されます。
正規表現の置換による書き換えのロジックは次のとおりです: クライアントリクエストは、複数の括弧
()を含む正規表現に一致し、rewrite-targetアノテーションには${1}、${2}、および${3}変数の 1 つ以上が含まれます。
たとえば、Ingress の path が /sys/(.*)/(.*)/aaa に設定され、rewrite-target アノテーションが /${1}/${2} に設定されている場合、クライアントがパス /sys/ccc/bbb/aaa にリクエストを送信すると、path は /sys/(.*)/(.*)/aaa に一致します。 rewrite-target アノテーションは、${1} を ccc に、${2} を bbb に置き換えます。 バックエンドサーバーが受信する最終的なリクエストパスは /ccc/bbb です。
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
annotations:
alb.ingress.kubernetes.io/use-regex: "true" # path フィールドで正規表現をサポートします。
alb.ingress.kubernetes.io/rewrite-target: /path/${2} # 正規表現に一致する変数が連結されて、元のパスを上書きするパスが形成されます。
name: rewrite-ingress
spec:
ingressClassName: alb
rules:
- host: demo.alb.ingress.top
http:
paths:
- path: /something(/|$)(.*)
pathType: Prefix
backend:
service:
name: rewrite-svc
port:
number: 9080カスタムリスニングポートの設定
ALB Ingress では、カスタムリスニングポートを設定できます。 これにより、ポート 80 と 443 を同時に介してサービスを公開できます。
ALB Ingress を使用してリスナーを作成することはできません。 ALB Ingress が期待どおりに機能するようにするには、AlbConfig でリスナーのポートとプロトコルを指定し、リスナーを ALB Ingress のサービスに関連付ける必要があります。 ALB リスナーの作成方法の詳細については、「AlbConfig を使用して ALB リスナーを設定する」をご参照ください。
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: cafe-ingress
annotations:
alb.ingress.kubernetes.io/listen-ports: '[{"HTTP": 80},{"HTTPS": 443}]'
spec:
ingressClassName: alb
tls:
- hosts:
- demo.alb.ingress.top
rules:
- host: demo.alb.ingress.top
http:
paths:
- path: /tea
pathType: ImplementationSpecific
backend:
service:
name: tea-svc
port:
number: 80転送ルールの優先度の設定
デフォルトでは、転送ルールは次のルールに基づいて優先順位が付けられます。
Ingress は、
namespace/nameの辞書順でソートされます。 値が小さいほど、優先度が高くなります。同じ Ingress 内では、ルールは
ruleフィールドでの順序に基づいてソートされます。 以前に設定されたルールほど、優先度が高くなります。
Ingress の namespace/name を変更したくない場合は、次の Ingress アノテーションを設定して、転送ルールの優先度を定義できます。
ルールの優先度は、同じリスナー内で一意である必要があります。 alb.ingress.kubernetes.io/order アノテーションを使用して、Ingress の優先度を指定できます。 値は 1~1,000 の整数である必要があります。 値が小さいほど、優先度が高くなります。 デフォルトの優先度は 10 です。 より高い優先度を割り当てるには、より小さい値を指定します。
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: cafe-ingress
annotations:
alb.ingress.kubernetes.io/order: "2"
spec:
ingressClassName: alb
rules:
- host: demo.alb.ingress.top
http:
paths:
- path: /tea
pathType: ImplementationSpecific
backend:
service:
name: tea-svc
port:
number: 80アノテーションを使用した段階的リリースの実行
ALB は複雑なルーティング機能を提供し、ヘッダー、Cookie、および重みに基づくカナリアリリースをサポートします。 アノテーションを設定することで、カナリアリリースを実装できます。 カナリアリリースを有効にするには、alb.ingress.kubernetes.io/canary: "true" アノテーションを設定する必要があります。 さまざまなアノテーションを使用して、さまざまなカナリアリリース機能を実装できます。
異なるルールを使用するカナリアリリースは、ヘッダーベース > Cookie ベース > 重みベースの順に有効になります。
カナリアリリースを実行して新しいアプリケーションバージョンをテストするときは、元の Ingress ルールを変更しないでください。 そうしないと、アプリケーションへのアクセスが中断される可能性があります。 新しいアプリケーションバージョンがテストに合格したら、以前のアプリケーションバージョンで使用されていたバックエンド Service を、新しいアプリケーションバージョンで使用されているバックエンド Service に置き換えます。 次に、カナリアリリースを実装するための Ingress ルールを削除します。
alb.ingress.kubernetes.io/canary-by-headerおよびalb.ingress.kubernetes.io/canary-by-header-value: このルールはリクエストヘッダーの値を指定し、alb.ingress.kubernetes.io/canary-by-headerと一緒に使用する必要があります。リクエストの
headerとheader-valueが設定値と一致する場合、リクエストは段階的リリースサービスエンドポイントに割り当てられます。他の
header値の場合、headerは無視され、リクエストトラフィックは段階的リリースの優先度に基づいて、他のルールによって設定された段階的リリースサービスに割り当てられます。
リクエストヘッダーが
location: hzの場合、リクエストはカナリアリリースサービスにルーティングされます。 他のヘッダーを持つリクエストは、カナリアリリースの重みに基づいてルーティングされます。 次の例は、サンプル構成を示しています。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 namespace: default spec: ingressClassName: alb rules: - http: paths: - backend: service: name: demo-service-hello port: number: 80 path: /hello pathType: ImplementationSpecificalb.ingress.kubernetes.io/canary-by-cookie: Cookie に基づいてトラフィックを分割します。cookieの値がalwaysに設定されている場合、リクエストトラフィックは段階的リリースサービスエンドポイントに割り当てられます。cookieの値がneverに設定されている場合、リクエストトラフィックは段階的リリースサービスエンドポイントに割り当てられません。
説明Cookie ベースのカナリアリリースは、
alwaysとneverの値のみをサポートします。 カスタム値はサポートされていません。リクエスト Cookie が
demo=alwaysの場合、リクエストはカナリアリリースサービスにルーティングされます。 次の例は、サンプル構成を示しています。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 namespace: default spec: ingressClassName: alb rules: - http: paths: - backend: service: name: demo-service-hello port: number: 80 path: /hello pathType: ImplementationSpecificalb.ingress.kubernetes.io/canary-weight: カナリアサービスにルーティングされるリクエストの割合を指定します。 値は 0~100 の整数である必要があります。次の例では、新しいアプリケーションバージョンにルーティングされるリクエストの割合が 50% に設定されています。
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 namespace: default spec: ingressClassName: alb rules: - http: paths: - backend: service: name: demo-service-hello port: number: 80 path: /hello pathType: ImplementationSpecific
アノテーションを使用したセッション維持の設定
ALB Ingress では、次のアノテーションを使用してセッション維持を設定できます。
alb.ingress.kubernetes.io/sticky-session: セッション維持を有効にするかどうかを指定します。 有効な値:trueまたはfalse。 デフォルト値:false。alb.ingress.kubernetes.io/sticky-session-type: Cookie の処理方法。 有効な値:InsertまたはServer。 デフォルト値:Insert。Insert: Cookie を挿入します。 クライアントが最初のリクエストを送信すると、Server Load Balancer は応答に Cookie (SERVERID) を挿入します。 クライアントがこの Cookie を使用して次のリクエストを送信すると、Server Load Balancer はリクエストを以前に記録されたバックエンドサーバーに転送します。Server: Cookie を書き換えます。 Server Load Balancer がユーザー定義の Cookie を見つけると、元の Cookie を書き換えます。 クライアントが新しい Cookie を使用して次のリクエストを送信すると、Server Load Balancer はリクエストを以前に記録されたバックエンドサーバーに転送します。
説明このパラメーターは、サーバーグループに対して
StickySessionEnabledがtrueに設定されている場合にのみ有効になります。alb.ingress.kubernetes.io/cookie-timeout: Cookie のタイムアウト期間 (秒)。 1~86,400 の整数を指定できます。 デフォルト値は1000です。
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"
alb.ingress.kubernetes.io/cookie-timeout: "1800"
spec:
ingressClassName: alb
rules:
- http:
paths:
# コンテキストパスを設定します。
- path: /tea2
backend:
service:
name: tea-svc
port:
number: 80
# コンテキストパスを設定します。
- path: /coffee2
backend:
service:
name: coffee-svc
port:
number: 80バックエンドサーバーグループの負荷分散アルゴリズムの指定
ALB Ingress では、Ingress アノテーション alb.ingress.kubernetes.io/backend-scheduler を設定することで、サーバーグループの負荷分散アルゴリズムを指定できます。 次の例は、サンプル構成を示しています。 デフォルトでは、クラスターのバージョンは 1.19 以降である必要があります。
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: cafe-ingress
annotations:
alb.ingress.kubernetes.io/backend-scheduler: "uch" # 必要に応じて uch を wrr、sch、または wlc に置き換えます。
alb.ingress.kubernetes.io/backend-scheduler-uch-value: "test" # このパラメーターは、負荷分散アルゴリズムが uch の場合にのみ必要です。 スケジューリングアルゴリズムが wrr、sch、または wlc の場合は、このパラメーターを設定する必要はありません。
name: cafe-ingress
spec:
ingressClassName: alb
rules:
- host: demo.alb.ingress.top
http:
paths:
- path: /tea
pathType: ImplementationSpecific
backend:
service:
name: tea-svc
port:
number: 80alb.ingress.kubernetes.io/backend-scheduler アノテーションでは、次の値がサポートされています。
wrr: これはデフォルト値です。 リクエストは、その重みに基づいてバックエンドサーバーに分散されます。 重みが大きいバックエンドサーバーほど、より多くのリクエストを受信します。wlc: リクエストは、その重みと既存の接続数に基づいてバックエンドサーバーに分散されます。 バックエンドサーバーの重みが同じ場合、接続数が最も少ないサーバーが選択されます。sch: 同じ送信元 IP アドレスからのリクエストは、同じバックエンドサーバーにルーティングされます。uch: 同じ URL パラメーターを含むリクエストは、同じバックエンドサーバーにルーティングされます。 スケジューリングアルゴリズムをuchに設定した場合、alb.ingress.kubernetes.io/backend-scheduler-uch-valueアノテーションを使用して、一貫したハッシュの 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"
spec:
ingressClassName: alb
rules:
- host: demo.alb.ingress.top
http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: cloud-nodeport
port:
number: 80パラメーター | 説明 |
| ブラウザを使用してオリジンサーバー上のリソースにアクセスするために使用できる URL。 複数の URL はコンマ (,) で区切ります。 各 URL は http:// または https:// で始まり、有効なドメイン名またはトップレベルのワイルドカードドメイン名を含む必要があります。 デフォルト値: |
| 許可される HTTP メソッド。 値では大文字と小文字は区別されません。 複数の HTTP メソッドはコンマ (,) で区切ります。 デフォルト値: |
| 許可されるリクエストヘッダー。 リクエストヘッダーには、文字、数字、アンダースコア (_)、およびハイフン (-) を含めることができます。 複数のリクエストヘッダーはコンマ (,) で区切ります。 デフォルト値: |
| 公開できるヘッダー。 ヘッダーには、文字、数字、アンダースコア (_)、ハイフン (-)、およびアスタリスク (*) を含めることができます。 複数のヘッダーはコンマ (,) で区切ります。 デフォルト値: |
| CORS リクエストに認証情報を含めるかどうかを指定します。 デフォルト値: |
| OPTIONS メソッドを使用するプリフライトリクエストをキャッシュできる最大期間。 複雑なリクエストに対してこのパラメーターを設定します。 有効な値: -1~172800。 単位: 秒。 デフォルト値: |
バックエンドの持続的接続
従来のロードバランサーは、短命の接続を使用してバックエンドサーバーグループにアクセスします。 各リクエストでは、新しい TCP 接続を確立してから終了する必要があります。 これにより、パフォーマンス専有型システムでネットワーク接続のボトルネックが発生する可能性があります。 Server Load Balancer は、バックエンドサーバーへの持続的接続をサポートしています。 この機能により、接続レイヤーのリソース消費が削減され、処理パフォーマンスが大幅に向上します。 alb.ingress.kubernetes.io/backend-keepalive アノテーションを使用して、ALB Ingress の持続的接続を有効にできます。 次の例は、サンプル構成を示しています。
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: 80QPS スロットリングの設定
ALB は、転送ルールのクエリ/秒 (QPS) スロットリングをサポートしています。 スロットリング値は 1~100,000 の整数である必要があります。 ALB Ingress の場合は、alb.ingress.kubernetes.io/traffic-limit-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