アプリケーションロードバランサー(ALB)イングレスは、Kubernetesクラスター内のサービスへの外部アクセスを管理するためのレイヤー7ロードバランシングを提供するAPIオブジェクトです。このトピックでは、Alibaba Cloud Container Service(ACS)クラスターでALBイングレスを使用して、ドメイン名とURLパスに基づいてバックエンドサーバーグループにリクエストを転送する方法、HTTPリクエストをHTTPSにリダイレクトする方法、カナリアリリースを実装する方法について説明します。
前提条件
ACSクラスターが作成されていること。詳細については、ACSクラスターの作成を参照してください。
AlbConfigオブジェクトが作成されていること。詳細については、ALBイングレスの概要を参照してください。
ドメイン名に基づいてリクエストを転送する
次の手順を実行して、ドメイン名を持つイングレスとドメイン名を持たないイングレスを作成し、イングレスを使用してリクエストを転送します。
ドメイン名を持つイングレスを作成する
次のテンプレートを使用して、デプロイメント、サービス、およびイングレスを作成します。イングレスのドメイン名へのリクエストは、サービスに転送されます。
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インスタンスのIPアドレスに置き換えます。
kubectl get ing
コマンドを実行することで、IPアドレスを照会できます。curl -H "host: demo.domain.ingress.top" <ADDRESS>/hello
期待される出力:
{"hello":"coffee"}
ドメイン名を持たないイングレスを作成する
次のテンプレートは、イングレスの構成を示しています。
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インスタンスのIPアドレスに置き換えます。
kubectl get ing
コマンドを実行することで、IPアドレスを照会できます。curl <ADDRESS>/hello
期待される出力:
{"hello":"coffee"}
URLパスに基づいてリクエストを転送する
ALBイングレスは、URLパスに基づいてリクエストを転送できます。pathType
パラメーターを使用して、異なるURL一致ポリシーを構成できます。pathType
の有効な値は、Exact、ImplementationSpecific、およびPrefixです。
URL一致ポリシーは互いに競合する可能性があります。競合するURL一致ポリシーが存在する場合、リクエストはポリシーの優先順位の降順でこれらのポリシーと照合されます。詳細については、転送ルール優先順位の設定を参照してください。
一致モード | ルール | URLパス | URLパスがルールと一致するかどうか |
Prefix | / | (すべてのパス) | はい |
Prefix | /foo |
| はい |
Prefix | /foo/ |
| はい |
Prefix | /aaa/bb | /aaa/bbb | いいえ |
Prefix | /aaa/bbb | /aaa/bbb | はい |
Prefix | /aaa/bbb/ | /aaa/bbb | はい。URLパスはルールの末尾のスラッシュ(/)を無視します。 |
Prefix | /aaa/bbb | /aaa/bbb/ | はい。ルールはURLパスの末尾のスラッシュ(/)と一致します。 |
Prefix | /aaa/bbb | /aaa/bbb/ccc | はい。ルールはURLパスのサブパスと一致します。 |
Prefix | 同時に2つのルールを構成する:
| /aaa/ccc | はい。URLパスは |
Prefix | 同時に2つのルールを構成する:
| /aaa/ccc | はい。URLパスは |
Prefix | 同時に2つのルールを構成する:
| /ccc | はい。URLパスは |
Prefix | /aaa | /ccc | いいえ |
ExactまたはImplementationSpecific | /foo | /foo | はい |
ExactまたはImplementationSpecific | /foo | /bar | いいえ |
ExactまたはImplementationSpecific | /foo | /foo/ | いいえ |
ExactまたはImplementationSpecific | /foo/ | /foo | いいえ |
次の手順を実行して、異なるURL一致ポリシーを構成できます。
Exact
次のテンプレートは、イングレスの構成を示しています。
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インスタンスのIPアドレスに置き換えます。
kubectl get ing
コマンドを実行することで、IPアドレスを照会できます。curl <ADDRESS>/hello
期待される出力:
{"hello":"coffee"}
ImplementationSpecific:デフォルトの一致ポリシー
ALBイングレスの構成は、Exact
一致ポリシーの場合と同じです。
次のテンプレートは、イングレスの構成を示しています。
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インスタンスのIPアドレスに置き換えます。
kubectl get ing
コマンドを実行することで、IPアドレスを照会できます。curl <ADDRESS>/hello
期待される出力:
{"hello":"coffee"}
Prefix
指定されたプレフィックスをURLパスと照合します。URLパスの要素はスラッシュ(/
)で区切られます。プレフィックスは大文字と小文字が区別され、パスの各要素と照合されます。
次のテンプレートは、イングレスの構成を示しています。
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インスタンスのIPアドレスに置き換えます。
kubectl get ing
コマンドを実行することで、IPアドレスを照会できます。curl <ADDRESS>/hello
期待される出力:
{"hello":"coffee"}
ヘルスチェックを設定する
次のアノテーションを使用して、ALBイングレスのヘルスチェックを設定できます。次のYAMLテンプレートは、ヘルスチェックが有効になっているイングレスを作成する方法の例を示しています。
次のYAMLテンプレートは、ヘルスチェックが有効になっているイングレスを作成する方法の例を示しています。
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 | オプション。ヘルスチェックを有効にするかどうかを指定します。デフォルト値:true。 |
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.kubernetes.io/ssl-redirect: "true"
アノテーションを追加することで、HTTPリクエストをHTTPSポート443にリダイレクトするようにALBイングレスを設定できます。
ALBイングレスを使用してリスナーを作成することはできません。ALBイングレスが期待どおりに動作することを確実にするには、AlbConfigでリスナーのポートとプロトコルを指定し、リスナーをALBイングレスのサービスに関連付ける必要があります。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をサポートしています。HTTPSまたはgRPCを設定するには、alb.ingress.kubernetes.io/backend-protocol: "grpc"
またはalb.ingress.kubernetes.io/backend-protocol: "https"
アノテーションを追加します。イングレスを使用してgRPCサービスにリクエストを配信する場合は、gRPCサービスのSSL証明書を設定し、TLSプロトコルを使用してgRPCサービスと通信する必要があります。例:
バックエンドプロトコルを変更することはできません。プロトコルを変更する必要がある場合は、イングレスを削除して再構築してください。
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: | # アノテーションで指定されたサービスは、クラスター内の既存のサービスでなければならず、サービス名はruleフィールドのbackendのサービス名と同じである必要があります。
[{
"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.kubernetes.io/rewrite-target: /path/${2}
を追加します。次のルールが適用されます。
rewrite-target
アノテーションでは、pathType
フィールドを、${number}
タイプの変数に対して Prefix に設定する必要があります。デフォルトでは、
path
パラメーターは、アスタリスク(*
)や疑問符(?
)などの正規表現でサポートされている文字をサポートしていません。pathパラメーターで正規表現で使用される文字を指定するには、rewrite-target
アノテーションを追加する必要があります。path
パラメーターの値は、スラッシュ(/
)で始まる必要があります。
書き換えルールで正規表現を指定する場合は、次の項目に注意してください。
ALBイングレスの
path
フィールドに1つ以上の正規表現を指定し、括弧()
で囲むことができます。ただし、${1}
、${2}
、${3}
の最大3つの変数をrewrite-target
アノテーションで使用して、元のパスを上書きするパスを形成できます。正規表現に一致する変数は連結され、元のパスを上書きするパスが形成されます。
元のパスは、次の要件が満たされた場合にのみ、正規表現に一致する変数によって上書きされます。括弧
()
で囲まれた複数の正規表現が指定され、rewrite-target
アノテーションが次の変数の1つ以上に設定されている必要があります。${1}
、${2}
、${3}
。
ALBイングレスの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イングレスでは、カスタムリスニングポートを設定できます。これにより、ポート80と443を介して同時にサービスを公開できます。
ALBイングレスを使用してリスナーを作成することはできません。ALBイングレスが期待どおりに動作することを確実にするには、AlbConfigでリスナーのポートとプロトコルを指定し、リスナーをALBイングレスのサービスに関連付ける必要があります。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
転送ルール優先順位を設定する
デフォルトでは、転送ルールは次のルールに基づいて優先順位が付けられます。
異なるALBイングレスの転送ルールは、
namespace/name
パラメーターの値の辞書順で優先順位が付けられます。namespace/nameの値が辞書順ですべての転送ルールの中で最初に表示される転送ルールは、最も高い優先順位を持ちます。ALBイングレスの転送ルールは、
rule
パラメーターで優先順位の降順で表示されます。
ALBイングレスのnamespace/name
パラメーターを使用して転送ルールの優先順位を付けたくない場合は、代わりに次のアノテーションを使用できます。
リスナー内の各転送ルールの優先順位は一意である必要があります。アノテーションalb.ingress.kubernetes.io/order
を使用して、ALBイングレスの転送ルールの優先順位を指定できます。有効な値:1~1000。値が小さいほど優先順位が高くなります。デフォルト値は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ベース>重みベース。
カナリアリリースを実行して新しいアプリケーションバージョンをテストする場合、元のイングレスルールを変更しないでください。そうしないと、アプリケーションへのアクセスが中断される可能性があります。新しいアプリケーションバージョンがテストに合格したら、以前のアプリケーションバージョンで使用されていたバックエンドサービスを、新しいアプリケーションバージョンで使用されているバックエンドサービスに置き換えます。次に、カナリアリリースを実装するためのイングレスルールを削除します。
alb.ingress.kubernetes.io/canary-by-header
およびalb.ingress.kubernetes.io/canary-by-header-value
:このルールは、リクエストのヘッダーとヘッダー値と一致します。このルールを使用する場合は、両方のアノテーション
を追加する必要があります。リクエストの
header
とheader value
がルールと一致する場合、リクエストは新しいアプリケーションバージョンにルーティングされます。リクエストの
header
がheader
ベースのルールと一致しない場合、リクエストはルールの優先順位に基づいて他のタイプのルールと照合されます。
alb.ingress.kubernetes.io/canary-by-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: ImplementationSpecific
alb.ingress.kubernetes.io/canary-by-cookie
:このルールは、リクエストのCookieと一致します。cookie
をalways
に設定すると、ルールと一致するリクエストは新しいアプリケーションバージョンにルーティングされます。cookie
をnever
に設定すると、ルールと一致するリクエストは古いアプリケーションバージョンにルーティングされます。
説明Cookieベースのカナリアリリースルールは、他の設定をサポートしていません。Cookie値は
always
またはnever
である必要があります。demo=always
Cookieを含むリクエストは、新しいアプリケーションバージョンにルーティングされます。例: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: ImplementationSpecific
alb.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イングレスでは、次のアノテーションを使用してセッション永続性を設定できます。
alb.ingress.kubernetes.io/sticky-session
:セッション永続性を有効にするかどうかを指定します。有効な値:true
およびfalse
。デフォルト値:false
。alb.ingress.kubernetes.io/sticky-session-type
:Cookieの処理方法。有効な値:Insert
およびServer
。デフォルト値:Insert
。Insert
:Cookieを挿入します。ALBは、クライアントに送信される最初のHTTPまたはHTTPSレスポンスパケットにCookie(SERVERID)を挿入します。クライアントからの次のリクエストにはこのCookieが含まれ、リスナーはこのリクエストを記録されたバックエンドサーバーに配信します。Server
:Cookieを書き換えます。ALBは、ユーザー定義のCookieを検出すると、元のCookieをユーザー定義のCookieで上書きします。クライアントからの次のリクエストには、ユーザー定義のCookieが含まれ、リスナーはこのリクエストを記録されたバックエンドサーバーに配信します。
説明このパラメーターは、サーバーグループの
StickySessionEnabled
パラメーターがtrue
に設定されている場合に有効になります。alb.ingress.kubernetes.io/cookie-timeout
:Cookieのタイムアウト期間を指定します。有効な値:1~86400。デフォルト値: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イングレスでは、アノテーションalb.ingress.kubernetes.io/backend-scheduler
を使用して、バックエンドサーバーグループのロードバランシングアルゴリズムを指定できます。クラスターのKubernetesバージョンは、デフォルトで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: 80
次の説明に基づいて、アノテーションalb.ingress.kubernetes.io/backend-scheduler
を設定します。
wrr
:重み付けの高いバックエンドサーバーは、重み付けの低いバックエンドサーバーよりも多くのリクエストを受信します。これはデフォルト値です。wlc
:リクエストは、各バックエンドサーバーの重み付けと負荷に基づいて配信されます。負荷とは、バックエンドサーバーへの接続数を指します。複数のバックエンドサーバーの重み付けが同じ場合、リクエストは接続数が最も少ないバックエンドサーバーに転送されます。sch
:送信元IPアドレスに基づくコンシステントハッシュ。uch
:URLパラメーターに基づくコンシステントハッシュ。バックエンドサーバーグループのロードバランシングアルゴリズムがuch
の場合、アノテーションalb.ingress.kubernetes.io/backend-scheduler-uch-value
をALBイングレスに追加して、コンシステントハッシュのURLパラメーターを指定できます。
CORSを設定する
次のコードブロックは、ALBイングレスでサポートされているクロスオリジンリソースシェアリング(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接続機能を使用できます。alb.ingress.kubernetes.io/backend-keepalive
アノテーションをALBイングレスに追加して、持続的TCP接続機能を有効にできます。例:
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は、転送ルールに基づいてQPSスロットリングをサポートしています。QPSは1~100000の範囲に制限できます。alb.ingress.kubernetes.io/traffic-limit-qps
アノテーションをALBイングレスに追加して、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