登録済みクラスター内のApplication Load Balancer (ALB) Ingressは、クラスター内のサービスへの外部ユーザーアクセスを管理し、レイヤー7の負荷分散機能を提供するために使用されるAPIオブジェクトです。 このトピックでは、ALB Ingressを作成して、異なるドメイン名またはURL宛てのトラフィックをバックエンドサーバーグループにルーティングし、HTTPからHTTPSにリクエストをリダイレクトし、カナリアリリースを実行する方法について説明します。
前提条件
登録済みクラスターが作成され、データセンターにデプロイされている外部クラスターが登録済みクラスターに接続されます。 詳細については、「ACKコンソールでの登録済みクラスターの作成」をご参照ください。
ドメイン名に基づいてリクエストを転送する
次の手順を実行して、ドメイン名を持つIngressとドメイン名を持たないIngressを作成し、Ingressを使用してリクエストを転送します。
ドメイン名でIngressを作成する
次のテンプレートを使用して、展開、サービス、およびIngressを作成します。 Ingressのドメイン名に対する要求は、サービスに転送される。
Kubernetes 1.19以降を実行するクラスター
apiVersion: v1 種類: サービス メタデータ: 名前: demo-service namespace: デフォルト spec: ポート: -name: port1 port: 80 protocol: TCP targetPort: 8080 セレクタ: アプリ: デモ sessionAffinity: None タイプ: NodePort --- apiVersion: apps/v1 kind: 配置 メタデータ: 名前: デモ namespace: デフォルト spec: replicas: 1 セレクタ: matchLabels: アプリ: デモ template: metadata: labels: アプリ: デモ 仕様: containers: -画像: registry.cn-hangzhou.aliyuncs.com/alb-sample/cafe:v1 imagePullPolicy: IfNotPresent 名前: デモ ポート: - containerPort: 8080 プロトコル: TCP --- apiVersion: networking.k8s.io/v1 kind: Ingress メタデータ: 名前: デモ namespace: デフォルト spec: ingressClassName: alb rules: -host: demo.domain.ingress.top http: paths: - backend: service: 名前: demo-service port: number: 80 パス: /hello pathType: ImplementationSpecific1.19より前のバージョンのKubernetesを実行するクラスター
apiVersion: v1 種類: サービス メタデータ: 名前: demo-service namespace: デフォルト spec: ポート: -name: port1 port: 80 protocol: TCP targetPort: 8080 セレクタ: アプリ: デモ sessionAffinity: None タイプ: NodePort --- apiVersion: apps/v1 kind: 配置 メタデータ: 名前: デモ namespace: デフォルト spec: replicas: 1 セレクタ: matchLabels: アプリ: デモ template: metadata: labels: アプリ: デモ 仕様: containers: -画像: registry.cn-hangzhou.aliyuncs.com/alb-sample/cafe:v1 imagePullPolicy: IfNotPresent 名前: デモ ポート: - containerPort: 8080 プロトコル: TCP --- apiVersion: networking.k8s.io/v1beta1 kind: Ingress メタデータ: 名前: デモ namespace: デフォルト spec: ingressClassName: alb rules: -host: demo.domain.ingress.top http: paths: - backend: serviceName: デモサービス servicePort: 80 パス: /hello pathType: ImplementationSpecific次のコマンドを実行して、指定したドメイン名を使用してアプリケーションにアクセスします。
ADDRESSを関連するALBインスタンスのIPアドレスに置き換えます。
kubectl get ingコマンドを実行して、IPアドレスを照会できます。curl -H "ホスト: demo.domain.ingress.top" <ADDRESS>/hello期待される出力:
{"hello":"coffee"}
ドメイン名なしでIngressを作成する
次のテンプレートは、Ingressの設定を示しています。
Kubernetes 1.19以降を実行するクラスター
apiVersion: networking.k8s.io/v1 kind: Ingress メタデータ: 名前: デモ namespace: デフォルト spec: ingressClassName: alb rules: -host: "" http: paths: - backend: service: 名前: demo-service port: number: 80 パス: /hello1.19より前のバージョンのKubernetesを実行するクラスター
apiVersion: networking.k8s.io/v1beta1 kind: Ingress メタデータ: 名前: デモ namespace: デフォルト spec: ingressClassName: alb rules: -host: "" http: paths: - backend: serviceName: デモサービス servicePort: 80 パス: /hello pathType: ImplementationSpecific次のコマンドを実行して、ドメイン名を使用せずにアプリケーションにアクセスします。
ADDRESSを関連するALBインスタンスのIPアドレスに置き換えます。
kubectl get ingコマンドを実行して、IPアドレスを照会できます。curl <ADDRESS>/hello期待される出力:
{"hello":"coffee"}
URLパスに基づいてリクエストを転送する
ALB Ingressは、URLパスに基づいてリクエストを転送できます。 pathTypeパラメーターを使用して、さまざまなURL一致ポリシーを設定できます。 pathTypeの有効な値は、Exact、ImplementationSpecific、Prefixです。
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 | はい。 URLパスは |
接頭辞 | 2つのルールを同時に設定します。
| /aaa/ccc | はい。 URLパスは |
接頭辞 | 2つのルールを同時に設定します。
| /ccc | はい。 URLパスは |
接頭辞 | /aaa | /ccc | 選択可能 |
正確または実装固有 | /foo | /foo | 必須 |
正確または実装固有 | /foo | /バー | 選択可能 |
正確または実装固有 | /foo | /foo / | 選択可能 |
正確または実装固有 | /foo / | /foo | 選択可能 |
さまざまなURL一致ポリシーを設定するには、次の手順を実行します。
正確
次のテンプレートは、Ingressの設定を示しています。
Kubernetes 1.19以降を実行するクラスター
apiVersion: networking.k8s.io/v1 kind: Ingress メタデータ: 名前: デモパス namespace: デフォルト spec: ingressClassName: alb rules: - http: paths: -パス: /hello backend: service: 名前: demo-service port: number: 80 pathType: 正確1.19より前のバージョンのKubernetesを実行するクラスター
apiVersion: networking.k8s.io/v1beta1 kind: Ingress メタデータ: 名前: デモパス namespace: デフォルト spec: ingressClassName: alb rules: - http: paths: -パス: /hello backend: serviceName: デモサービス servicePort: 80 pathType: 正確次のコマンドを実行して、アプリケーションにアクセスします。
ADDRESSを関連するALBインスタンスのIPアドレスに置き換えます。
kubectl get ingコマンドを実行して、IPアドレスを照会できます。curl <ADDRESS>/hello期待される出力:
{"hello":"coffee"}
ImplementationSpecific: デフォルトの一致ポリシー
ALB Ingressの設定は、完全一致ポリシーの設定と同じです。
次のテンプレートは、Ingressの設定を示しています。
次のコマンドを実行して、アプリケーションにアクセスします。
ADDRESSを関連するALBインスタンスのIPアドレスに置き換えます。
kubectl get ingコマンドを実行して、IPアドレスを照会できます。
Kubernetes 1.19以降を実行するクラスター
apiVersion: networking.k8s.io/v1
kind: Ingress
メタデータ:
名前: デモパス
namespace: デフォルト
spec:
ingressClassName: alb
rules:
- http:
paths:
-パス: /hello
backend:
service:
名前: demo-service
port:
number: 80
pathType: ImplementationSpecific 1.19より前のバージョンのKubernetesを実行するクラスター
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
メタデータ:
名前: デモパス
namespace: デフォルト
spec:
ingressClassName: alb
rules:
- http:
paths:
-パス: /hello
backend:
serviceName: デモサービス
servicePort: 80
pathType: ImplementationSpecific curl <ADDRESS>/hello期待される出力:
{"hello":"coffee"}接頭辞
指定したプレフィックスをURLパスと照合します。 URLパスの要素は、スラッシュ (/) で区切ります。 プレフィックスは大文字と小文字が区別され、パスの各要素と照合されます。
次のテンプレートは、Ingressの設定を示しています。
次のコマンドを実行して、アプリケーションにアクセスします。
ADDRESSを関連するALBインスタンスのIPアドレスに置き換えます。
kubectl get ingコマンドを実行して、IPアドレスを照会できます。
Kubernetes 1.19以降を実行するクラスター
apiVersion: networking.k8s.io/v1
kind: Ingress
メタデータ:
名前: demo-path-prefix
namespace: デフォルト
spec:
ingressClassName: alb
rules:
- http:
paths:
- path: /
backend:
service:
名前: demo-service
port:
number: 80
pathType: プレフィックス 1.19より前のバージョンのKubernetesを実行するクラスター
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
メタデータ:
名前: demo-path-prefix
namespace: デフォルト
spec:
ingressClassName: alb
rules:
- http:
paths:
- path: /
backend:
serviceName: デモサービス
servicePort: 80
pathType: プレフィックス curl <ADDRESS>/hello期待される出力:
{"hello":"coffee"}ヘルスチェックの設定
次のアノテーションを使用して、ALB Ingressのヘルスチェックを設定できます。 次のYAMLテンプレートは、ヘルスチェックが有効になっているIngressを作成する方法の例を示しています。
次のYAMLテンプレートは、ヘルスチェックが有効になっているIngressを作成する方法の例を示しています。
Kubernetes 1.19以降を実行するクラスター
apiVersion: networking.k8s.io/v1
kind: Ingress
メタデータ:
name: cafe-ingress
アノテーション:
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:
ingressClassName: alb
rules:
- http:
paths:
# コンテキストパスを設定します。
- path: /tea
backend:
service:
name: tea-svc
port:
number: 80
# コンテキストパスを設定します。
- path: /coffee
backend:
service:
name: coffee-svc
port:
番号: 80 1.19より前のバージョンのKubernetesを実行するクラスター
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
メタデータ:
name: cafe-ingress
アノテーション:
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:
serviceName: tea-svc
servicePort: 80
# コンテキストパスを設定します。
- path: /coffee
backend:
serviceName: coffee-svc
servicePort: 80 パラメーター | 説明 |
alb.ingress.kubernetes.io/healthcheck-enabled | バックエンドサーバーグループのヘルスチェックを有効にするかどうかを指定します。
デフォルト値: |
alb.ingress.kubernetes.io/healthcheck-path | ヘルスチェックが実行されるURLパス。 デフォルト値: |
alb.ingress.kubernetes.io/healthcheck-protocol | ヘルスチェックに使用されるプロトコル。
デフォルト値: |
alb.ingress.kubernetes.io/healthcheck-httpversion | HTTPプロトコルのバージョン。 このパラメーターは、
デフォルト値: |
alb.ingress.kubernetes.io/healthcheck-method | ヘルスチェックに使用されるリクエストメソッド。
デフォルト値: 重要
|
alb.ingress.kubernetes.io/healthcheck-httpcode | ヘルスチェック用に返されるステータスコード。 バックエンドサーバーは、ヘルスチェックリクエストが成功し、指定されたステータスコードのいずれかが返された場合にのみ正常と見なされます。 次の1つ以上のステータスコードを選択し、複数のステータスコードをコンマ (,) で区切ることができます。
デフォルト値は、 |
alb.ingress.kubernetes.io/healthcheck-code | ヘルスチェック用に返されるステータスコード。 バックエンドサーバーは、ヘルスチェックリクエストが成功し、指定されたステータスコードのいずれかが返された場合にのみ正常と見なされます。 このパラメーターと このパラメーターの値は、
|
alb.ingress.kubernetes.io/healthcheck-timeout-seconds | ヘルスチェックのタイムアウト期間。 単位は秒です。 有効な値:1 から 300。 デフォルト値: |
alb.ingress.kubernetes.io/healthcheck-interval-seconds | 連続した 2 回のヘルスチェックの時間間隔を設定します 単位は秒です。 有効値:1 〜 50 。 デフォルト値: |
alb.ingress.kubernetes.io/healthy-threshold-count | バックエンドサーバーが正常と見なされるまでにヘルスチェックに合格する必要がある回数。 設定可能な値は 1 から 100 です。 デフォルト値: |
alb.ingress.kubernetes.io/unhealthy-threshold-count | バックエンドサーバーが正常でないと見なされるまでに、バックエンドサーバーが連続してヘルスチェックに失敗する必要がある回数。 設定可能な値は 1 から 100 です。 デフォルト値: |
alb.ingress.kubernetes.io/healthcheck-connect-port | ヘルスチェックに使用されるポート。 デフォルト値: 説明 値 |
HTTPリクエストからHTTPSリクエストへのリダイレクトの設定
ALB. Ingress. kubernetes.io/ssl-redirect: "true" という注釈を追加して、HTTPリクエストをHTTPSポート443にリダイレクトするようにalb ingressを設定できます。
ALB Ingressを使用してリスナーを作成することはできません。 ALB Ingressが期待どおりに機能するようにするには、AlbConfigでリスナーのポートとプロトコルを指定し、ALB Ingressでリスナーをサービスに関連付ける必要があります。
例:
Kubernetes 1.19以降を実行するクラスター
apiVersion: v1
種類: サービス
メタデータ:
名前: demo-service-ssl
namespace: デフォルト
spec:
ポート:
-name: port1
port: 80
protocol: TCP
targetPort: 8080
セレクタ:
アプリ: デモ-ssl
sessionAffinity: None
タイプ: NodePort
---
apiVersion: apps/v1
kind: 配置
メタデータ:
名前: demo-ssl
namespace: デフォルト
spec:
replicas: 1
セレクタ:
matchLabels:
アプリ: デモ-ssl
template:
metadata:
labels:
アプリ: デモ-ssl
仕様:
containers:
-画像: registry.cn-hangzhou.aliyuncs.com/alb-sample/cafe:v1
imagePullPolicy: IfNotPresent
名前: demo-ssl
ポート:
- containerPort: 8080
プロトコル: TCP
---
apiVersion: networking.k8s.io/v1
kind: Ingress
メタデータ:
アノテーション:
alb.ingress.kubernetes.io/ssl-redirect: "true"
名前: demo-ssl
namespace: デフォルト
spec:
ingressClassName: alb
tls:
- hosts:
-ssl.alb.ingress.top
rules:
-host: ssl.alb.ingress.top
http:
paths:
- backend:
service:
名前: demo-service-ssl
port:
number: 80
path: /
pathType: プレフィックス 1.19より前のバージョンのKubernetesを実行するクラスター
apiVersion: v1
種類: サービス
メタデータ:
名前: demo-service-ssl
namespace: デフォルト
spec:
ポート:
-name: port1
port: 80
protocol: TCP
targetPort: 8080
セレクタ:
アプリ: デモ-ssl
sessionAffinity: None
タイプ: NodePort
---
apiVersion: apps/v1
kind: 配置
メタデータ:
名前: demo-ssl
namespace: デフォルト
spec:
replicas: 1
セレクタ:
matchLabels:
アプリ: デモ-ssl
template:
metadata:
labels:
アプリ: デモ-ssl
仕様:
containers:
-画像: registry.cn-hangzhou.aliyuncs.com/alb-sample/cafe:v1
imagePullPolicy: IfNotPresent
名前: demo-ssl
ポート:
- containerPort: 8080
プロトコル: TCP
---
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
メタデータ:
アノテーション:
alb.ingress.kubernetes.io/ssl-redirect: "true"
名前: demo-ssl
namespace: デフォルト
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: プレフィックス バックエンドプロトコルとしてHTTPSまたはgRPCを設定する
ALB Ingressは、バックエンドプロトコルとしてHTTPSまたはgRPCをサポートしています。 HTTPSまたはgRPCを設定するには、alb.ingress.kubernetes.io/backend-protocol: "grpc" またはalb.ingress.kubernetes.io/backend-protocol: "https" アノテーションを追加します。 Ingressを使用して要求をgRPCサービスに配信する場合は、gRPCサービスのSSL証明書を設定し、TLSプロトコルを使用してgRPCサービスと通信する必要があります。 例:
バックエンドプロトコルは変更できません。 プロトコルを変更する必要がある場合は、Ingressを削除して再構築します。
Kubernetes 1.19以降を実行するクラスター
apiVersion: networking.k8s.io/v1
kind: Ingress
メタデータ:
アノテーション:
alb.ingress.kubernetes.io/backend-protocol: "grpc"
名前: lxd-grpc-ingress
spec:
ingressClassName: alb
tls:
- hosts:
-demo.alb.ingress.top
rules:
-host: demo.alb.ingress.top
http:
paths:
- path: /
pathType: プレフィックス
backend:
service:
名前: grpc-demo-svc
port:
番号: 9080 1.19より前のバージョンのKubernetesを実行するクラスター
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
メタデータ:
アノテーション:
alb.ingress.kubernetes.io/backend-protocol: "grpc"
名前: lxd-grpc-ingress
spec:
ingressClassName: alb
tls:
- hosts:
-demo.alb.ingress.top
rules:
-host: demo.alb.ingress.top
http:
paths:
- backend:
serviceName: grpc-demo-svc
servicePort: 9080
path: /
pathType: プレフィックス 書き換えルールの設定
ALB Ingressは書き換えルールをサポートしています。 書き換えルールを設定するには、alb.ingress.kubernetes.io/rewrite-target: /path/${2} という注釈を追加します。 次のルールが適用されます。
rewrite-targetアノテーションで、${number}型の変数のpathTypeフィールドをPrefixに設定する必要があります。デフォルトでは、
pathパラメーターは、アスタリスク (*) や疑問符 (?) などの正規表現でサポートされている文字をサポートしていません。 パスパラメーターで正規表現で使用される文字を指定するには、rewrite-targetアノテーションを追加する必要があります。pathパラメーターの値は、スラッシュ (/) で始まる必要があります。
書き換えルールで正規表現を指定する場合は、次の項目に注意してください。
ALB Ingressの
pathフィールドで1つ以上の正規表現を指定し、括弧()を使用して正規表現を囲むことができます。 ただし、rewrite-targetアノテーションで最大3つの変数 (${1}、${2}、${3}) を使用して、元のパスを上書きするパスを作成できます。正規表現に一致する変数は、元のパスを上書きするパスを形成するために連結される。
元のパスは、次の要件が満たされている場合にのみ、正規表現に一致する変数によって上書きされます。括弧で囲まれた複数の正規表現
()が指定され、書き換え対象のアノテーションは、${1}、${2}、${3}のいずれかの変数に設定されます。
ALB Ingressのpathパラメーターが /sys/(.*)/(.*)/aaaに設定され、書き換え対象のアノテーションが /${1}/${2} に設定されているとします。 クライアントが /sys/ccc/bbb/aaaパスにリクエストを送信した場合、リクエストは正規表現 /sys/(.*)/(.*)/aaaと一致します。 rewrite-targetアノテーションが有効になり、${1} がcccに、${2} がbbbに置き換えられます。 その結果、リクエストは /ccc/bbbにリダイレクトされます。
Kubernetes 1.19以降を実行するクラスター
apiVersion: networking.k8s.io/v1
kind: Ingress
メタデータ:
アノテーション:
alb.ingress.kubernetes.io/use-regex: "true"# パスフィールドの正規表現をサポートします。
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: プレフィックス
backend:
service:
名前: rewrite-svc
port:
番号: 9080 1.19より前のバージョンのKubernetesを実行するクラスター
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
メタデータ:
アノテーション:
alb.ingress.kubernetes.io/use-regex: "true"# パスフィールドの正規表現をサポートします。
alb.ingress.kubernetes.io/rewrite-target: /path/${2} # 正規表現に一致する変数は、元のパスを上書きするパスを形成するために連結されます。
name: rewrite-ingress
spec:
ingressClassName: alb
rules:
-host: demo.alb.ingress.top
http:
paths:
- backend:
serviceName: rewrite-svc
servicePort: 9080
パス: /something(/|$)(.*)
pathType: プレフィックス カスタムリスニングポートの設定
ALB Ingressを使用すると、カスタムリスニングポートを設定できます。 これにより、ポート80と443を介してサービスを同時に公開できます。
ALB Ingressを使用してリスナーを作成することはできません。 ALB Ingressが期待どおりに機能するようにするには、AlbConfigでリスナーのポートとプロトコルを指定し、ALB Ingressでリスナーをサービスに関連付ける必要があります。
Kubernetes 1.19以降を実行するクラスター
apiVersion: networking.k8s.io/v1
kind: Ingress
メタデータ:
name: cafe-ingress
アノテーション:
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:
番号: 80 1.19より前のバージョンのKubernetesを実行するクラスター
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
メタデータ:
アノテーション:
alb.ingress.kubernetes.io/listen-ports: '[{"HTTP": 80 },{ "HTTPS": 443}]'
名前: cafe-ingress
spec:
ingressClassName: alb
tls:
- hosts:
-demo.alb.ingress.top
rules:
-host: demo.alb.ingress.top
http:
paths:
- backend:
serviceName: tea-svc
servicePort: 80
パス: /tea-svc
pathType: ImplementationSpecific 転送ルールの優先度の設定
デフォルトでは、転送ルールは次のルールに基づいて優先順位が付けられます。
異なるALB Ingressの転送ルールは、
namespace/nameパラメーターの値の辞書式順序で優先順位が付けられます。 名前空間 /名前の値が辞書式順序のすべての転送ルールの中で最初に表示される転送ルールの優先度が最も高くなります。ALB Ingressの転送ルールは、
ruleパラメーターで優先度の高い順に表示されます。
ALB Ingressのnamespace/nameパラメーターを使用して転送ルールに優先順位を付けたくない場合は、代わりに次のアノテーションを使用できます。
リスナー内の各転送ルールの優先度は一意である必要があります。 注釈alb.ingress.kubernetes.io/orderを使用して、ALB Ingressの転送ルールの優先順位を指定できます。 有効な値: 1 ~ 1000 数字が小さいほど、優先度が高くなります。 デフォルト値は 10 です。
Kubernetes 1.19以降を実行するクラスター
apiVersion: networking.k8s.io/v1
kind: Ingress
メタデータ:
name: cafe-ingress
アノテーション:
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:
番号: 80 1.19より前のバージョンのKubernetesを実行するクラスター
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
メタデータ:
アノテーション:
alb.ingress.kubernetes.io/order: "2"
名前: cafe-ingress
spec:
ingressClassName: alb
rules:
-host: demo.alb.ingress.top
http:
paths:
- backend:
serviceName: tea-svc
servicePort: 80
パス: /tea-svc
pathType: ImplementationSpecific アノテーションを使用して段階的リリースを実行する
ALBを使用すると、リクエストヘッダー、Cookie、および重みに基づいてカナリアリリースを設定し、複雑なトラフィックルーティングを処理できます。 alb.ingress.kubernetes.io/canary: "true" を追加して、カナリアリリース機能を有効にします。 次に、次の注釈を使用して、さまざまなカナリアリリースルールを設定できます。
異なるルールを使用するカナリアリリースは、ヘッダーベース> クッキーベース> 重みベースの順に有効になります。
カナリアリリースを実行して新しいアプリケーションバージョンをテストするときは、元のIngressルールを変更しないでください。 そうでなければ、アプリケーションへのアクセスが中断される。 新しいアプリケーションバージョンがテストに合格したら、以前のアプリケーションバージョンで使用されていたバックエンドサービスを新しいアプリケーションバージョンで使用されているバックエンドサービスに置き換えます。 次に、カナリアリリースを実装するためのIngressルールを削除します。
alb.ingress.kubernetes.io/canary-by-headerおよびalb.ingress.kubernetes.io/canary-by-header-value: このルールは、リクエストのヘッダーとヘッダー値を照合します。 このルールを使用する場合は、両方の注釈を追加する必要があります。リクエストの
ヘッダーとヘッダー値がルールと一致する場合、リクエストは新しいアプリケーションバージョンにルーティングされます。リクエストの
ヘッダーがヘッダーベースのルールと一致しない場合、リクエストはルールの優先度に基づいて他のタイプのルールと照合されます。
alb.ingress.kubernetes.io/canary-by-headerアノテーションを
location: hzに設定した場合、ルールに一致するリクエストは新しいアプリケーションバージョンにルーティングされます。 ルールに一致しないリクエストは、重みベースのルールに基づいてルーティングされます。 例:Kubernetes 1.19以降を実行するクラスター
apiVersion: networking.k8s.io/v1 kind: Ingress メタデータ: アノテーション: 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" 名前: demo-canary namespace: デフォルト spec: ingressClassName: alb rules: - http: paths: - backend: service: 名前: demo-service-hello port: number: 80 パス: /hello pathType: ImplementationSpecific1.19より前のバージョンのKubernetesを実行するクラスター
apiVersion: networking.k8s.io/v1beta1 kind: Ingress メタデータ: アノテーション: 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" 名前: demo-canary namespace: デフォルト spec: ingressClassName: alb rules: - http: paths: - backend: serviceName:demo-service-hello servicePort: 80 パス: /hello pathType: ImplementationSpecificalb.ingress.kubernetes.io/canary-by-cookie: このルールはリクエストのcookieと一致します。cookieを常にに設定した場合、ルールに一致するリクエストは新しいアプリケーションバージョンにルーティングされます。cookieをneverに設定した場合、ルールに一致するリクエストは古いアプリケーションバージョンにルーティングされます。
説明Cookieベースのカナリアリリースルールは、他の設定をサポートしていません。 cookieの値は、
常にまたは絶対ではありません。demo=alwayscookieを含むリクエストは、新しいアプリケーションバージョンにルーティングされます。 例:Kubernetes 1.19以降を実行するクラスター
apiVersion: networking.k8s.io/v1 kind: Ingress メタデータ: アノテーション: alb.ingress.kubernetes.io/order: "2" alb.ingress.kubernetes.io/canary: "true" alb.ingress.kubernetes.io/canary-by-cookie: "demo" 名前: demo-canary-cookie namespace: デフォルト spec: ingressClassName: alb rules: - http: paths: - backend: service: 名前: demo-service-hello port: number: 80 パス: /hello pathType: ImplementationSpecific1.19より前のバージョンのKubernetesを実行するクラスター
apiVersion: networking.k8s.io/v1beta1 kind: Ingress メタデータ: アノテーション: alb.ingress.kubernetes.io/order: "2" alb.ingress.kubernetes.io/canary: "true" alb.ingress.kubernetes.io/canary-by-cookie: "demo" 名前: demo-canary-cookie namespace: デフォルト spec: ingressClassName: alb rules: - http: paths: - backend: serviceName:demo-service-hello servicePort: 80 パス: /hello pathType: ImplementationSpecificalb.ingress.kubernetes.io/canary-weight: このルールでは、指定したサービスに送信されるリクエストの割合を設定できます。 0から100までの整数を入力できます。次の例では、新しいアプリケーションバージョンにルーティングされるリクエストの割合を50% に設定します。
Kubernetes 1.19以降を実行するクラスター
apiVersion: networking.k8s.io/v1 kind: Ingress メタデータ: アノテーション: alb.ingress.kubernetes.io/order: "3" alb.ingress.kubernetes.io/canary: "true" alb.ingress.kubernetes.io/canary-weight: "50" 名前: demo-canary-weight namespace: デフォルト spec: ingressClassName: alb rules: - http: paths: - backend: service: 名前: demo-service-hello port: number: 80 パス: /hello pathType: ImplementationSpecific1.19より前のバージョンのKubernetesを実行するクラスター
apiVersion: networking.k8s.io/v1beta1 kind: Ingress メタデータ: アノテーション: alb.ingress.kubernetes.io/order: "3" alb.ingress.kubernetes.io/canary: "true" alb.ingress.kubernetes.io/canary-weight: "50" 名前: demo-canary-weight namespace: デフォルト spec: ingressClassName: alb rules: - http: paths: - backend: serviceName: demo-service-hello servicePort: 80 パス: /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を挿入します。 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単位は秒です。
Kubernetes 1.19以降を実行するクラスター
apiVersion: networking.k8s.io/v1
kind: Ingress
メタデータ:
名前: cafe-ingress-v3
アノテーション:
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:
# コンテキストパスを設定します。
-パス: /tea2
backend:
service:
name: tea-svc
port:
number: 80
# コンテキストパスを設定します。
-パス: /coffee2
backend:
service:
name: coffee-svc
port:
番号: 80 1.19より前のバージョンのKubernetesを実行するクラスター
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
メタデータ:
名前: cafe-ingress-v3
アノテーション:
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:
# コンテキストパスを設定します。
-パス: /tea2
backend:
serviceName: tea-svc
servicePort: 80
# コンテキストパスを設定します。
-パス: /coffee2
backend:
serviceName: coffee-svc
servicePort: 80 バックエンドサーバーグループの負荷分散アルゴリズムの指定
ALB ingressでは、注釈alb.ingress.kubernetes.io/backend-schedulerを使用して、バックエンドサーバーグループの負荷分散アルゴリズムを指定できます。 例:
Kubernetes 1.19以降を実行するクラスター
apiVersion: networking.k8s.io/v1
kind: Ingress
メタデータ:
name: cafe-ingress
アノテーション:
alb.ingress.kubernetes.io/backend-scheduler: "uch"# ビジネス要件に基づいてuchをwrr、sch、またはwlcに置き換えます。
alb.ingress.kubernetes.io/backend-scheduler-uch-value: "test"# このパラメーターは、負荷分散アルゴリズムがuchの場合にのみ必要です。 スケジューリングアルゴリズムがwrr、sch、またはwlcの場合、このパラメーターを設定する必要はありません。
名前: cafe-ingress
spec:
ingressClassName: alb
rules:
-host: demo.alb.ingress.top
http:
paths:
- path: /tea
pathType: ImplementationSpecific
backend:
service:
name: tea-svc
port:
番号: 80 1.19より前のバージョンのKubernetesを実行するクラスター
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
メタデータ:
アノテーション:
alb.ingress.kubernetes.io/backend-scheduler: "uch"# ビジネス要件に基づいてuchをwrr、sch、またはwlcに置き換えます。
alb.ingress.kubernetes.io/backend-scheduler-uch-value: "test"# このパラメーターは、負荷分散アルゴリズムがuchの場合にのみ必要です。 スケジューリングアルゴリズムがwrr、sch、またはwlcの場合、このパラメーターを設定する必要はありません。
名前: cafe-ingress
spec:
ingressClassName: alb
rules:
-host: demo.alb.ingress.top
http:
paths:
- backend:
serviceName: tea-svc
servicePort: 80
パス: /tea-svc
pathType: ImplementationSpecific 次の説明に基づいて、注釈alb.ingress.kubernetes.io/backend-schedulerを設定します。
wrr: 重みの大きいバックエンドサーバーは、重みの小さいバックエンドサーバーよりも多くのリクエストを受け取ります。 デフォルト値です。wlc: リクエストは、各バックエンドサーバーの重みと負荷に基づいて分散されます。 負荷とは、バックエンドサーバーへの接続数を指します。 複数のバックエンドサーバーの重みが同じ場合、リクエストは接続が最も少ないバックエンドサーバーに転送されます。sch: ソースIPアドレスに基づくコンシステントハッシング。uch: URLパラメータに基づくコンシステントハッシング。alb.ingress.kubernetes.io/backend-scheduler-uch-valueをALB Ingressに追加して、バックエンドサーバーグループの負荷分散アルゴリズムがuchの場合に、コンシステントハッシングのURLパラメーターを指定できます。
CORS の設定
次のコードブロックは、ALB Ingressでサポートされているクロスオリジンリソース共有 (CORS) 設定の例を示しています。
apiVersion: networking.k8s.io/v1
kind: Ingress
メタデータ:
名前: alb-ingress
アノテーション:
alb.ingress.kubernetes.io/enable-cors: "true"
alb.ingress.kubernetes.io/cors-exposure-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: プレフィックス
backend:
service:
名前: cloud-nodeport
port:
番号: 80 パラメーター | 説明 |
| 参照を使用してオリジンサーバー上のリソースにアクセスするために使用できるURL。 複数のURLはコンマ (,) で区切ります。 各URLはhttp:// またはhttps:// で始まり、有効なドメイン名または最上位レベルのワイルドカードドメイン名を含む必要があります。 デフォルト値: |
| 許可されているHTTPメソッド。 値は大文字と小文字を区別しません。 複数のHTTPメソッドはコンマ (,) で区切ります。 デフォルト値: |
| 許可されているリクエストヘッダー。 リクエストヘッダーには、英数字、アンダースコア (_) 、およびハイフン (-) を使用できます。 複数のリクエストヘッダーはコンマ (,) で区切ります。 デフォルト値: |
| 公開できるヘッダー。 ヘッダーには、英数字、アンダースコア (_) 、ハイフン (-) 、およびアスタリスク (*) を使用できます。 複数のヘッダーはコンマ (,) で区切ります。 デフォルト値: |
| CORSリクエストに資格情報を含めるかどうかを指定します。 デフォルト値: |
| OPTIONSメソッドを使用するプリフライト要求をキャッシュできる最大期間。 複雑なリクエストに対してこのパラメーターを設定します。 有効値: -1 ~ 172800 単位は秒です。 デフォルト値: |
永続TCP接続の設定
従来のロードバランサーは、短期間の接続でバックエンドサーバーにアクセスします。 従来のロードバランサーは、接続を作成し、ロードバランサーがバックエンドサーバーにリクエストを転送するたびに接続を閉じる必要があります。 その結果、ネットワーク接続が性能のボトルネックになる。 ネットワーク接続の確立に使用されるリソースの量を減らし、転送パフォーマンスを向上させるために、永続的なTCP接続機能を使用できます。 永続的なTCP接続機能を有効にするには、alb ingressにALB. Ingress. kubernetes.io/backend-keepaliveアノテーションを追加します。 例:
apiVersion: networking.k8s.io/v1
kind: Ingress
メタデータ:
名前: alb-ingress
アノテーション:
alb.ingress.kubernetes.io/backend-keepalive: "true"
spec:
ingressClassName: alb
rules:
-host: demo.alb.ingress.top
http:
paths:
- path: /
pathType: プレフィックス
backend:
service:
名前: cloud-nodeport
port:
番号: 80 QPSスロットリングの設定
ALBは、転送ルールに基づくQPSスロットリングをサポートしています。 QPSを1〜100000の範囲に制限できます。 alb.ingress.kubernetes.io/traffic-limit-qpsアノテーションをALB Ingressに追加して、QPSスロットリング機能を有効にすることができます。 例:
apiVersion: networking.k8s.io/v1
kind: Ingress
メタデータ:
name: cafe-ingress
アノテーション:
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:
番号: 80