Application Load Balancer (ALB) Ingressは、Kubernetesクラスター内のサービスへの外部アクセスを管理するためのレイヤー7負荷分散を提供するAPIオブジェクトです。 このトピックでは、ALB Ingressを使用して、ドメイン名とURLパスに基づいてリクエストをバックエンドサーバーグループに転送し、HTTPリクエストをHTTPSにリダイレクトし、カナリアリリースを実装する方法について説明します。
目次
前提条件
ACKマネージドクラスターまたはACK専用クラスターが作成され、クラスターはKubernetes 1.18以降を実行します。 詳細については、「マネージド Kubernetes クラスターの作成」および「Kubernetes クラスターの作成」をご参照ください。
異なるゾーンに存在する2つのvSwitchが作成され、ACKクラスターと同じ仮想プライベートクラウド (VPC) にデプロイされます。 詳細については、「vSwitchの作成と管理」をご参照ください。
ALB Ingressコントローラーがクラスターにインストールされています。 詳細については、「Manage the ALB Ingress controller」をご参照ください。
説明ALB Ingressを使用してACK専用クラスターにデプロイされたサービスにアクセスするには、まずALB Ingressコントローラーが必要とする権限をクラスターに付与する必要があります。 詳細については、「Authorize an ACK専用クラスター to access the ALB Ingress controller」をご参照ください。
AlbConfigオブジェクトが作成されます。 詳細については、「AlbConfigオブジェクトの作成」をご参照ください。
ドメイン名に基づいてリクエストを転送する
次の手順を実行して、ドメイン名を持つIngressとドメイン名を持たないIngressを作成し、Ingressを使用してリクエストを転送します。
ドメイン名でIngressを作成する
次のテンプレートを使用して、展開、サービス、およびIngressを作成します。 Ingressのドメイン名に対する要求は、サービスに転送される。
Kubernetes 1.19以降を実行するクラスター
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: NodePort --- 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
1.19より前のバージョンのKubernetesを実行するクラスター
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: NodePort --- 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/v1beta1 kind: Ingress metadata: name: demo namespace: default spec: ingressClassName: alb rules: - host: demo.domain.ingress.top http: paths: - backend: serviceName: demo-service servicePort: 80 path: /hello pathType: ImplementationSpecific
次のコマンドを実行して、指定したドメイン名を使用してアプリケーションにアクセスします。
ADDRESSを関連するALBインスタンスのIPアドレスに置き換えます。
kubectl get ing
コマンドを実行して、IPアドレスを照会できます。curl -H "host: 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 パス: /hello
1.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
metadata:
name: demo-path-prefix
namespace: default
spec:
ingressClassName: alb
rules:
- http:
paths:
- path: /
backend:
service:
name: demo-service
port:
number: 80
pathType: Prefix
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を作成する方法の例を示しています。
Kubernetes 1.19以降を実行するクラスター
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:
ingressClassName: alb
rules:
- http:
paths:
# Configure a context path.
- path: /tea
backend:
service:
name: tea-svc
port:
number: 80
# Configure a context path.
- path: /coffee
backend:
service:
name: coffee-svc
port:
number: 80
1.19より前のバージョンのKubernetesを実行するクラスター
apiVersion: networking.k8s.io/v1beta1
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:
# Configure a context path.
- path: /tea
backend:
serviceName: tea-svc
servicePort: 80
# Configure a context path.
- 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
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: NodePort
---
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
1.19より前のバージョンのKubernetesを実行するクラスター
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: NodePort
---
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は、バックエンドプロトコルとして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
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
1.19より前のバージョンのKubernetesを実行するクラスター
apiVersion: networking.k8s.io/v1beta1
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:
- backend:
serviceName: grpc-demo-svc
servicePort: 9080
path: /
pathType: Prefix
正規表現の設定
path
フィールドで、ルーティング条件として正規表現を指定できます。 例:
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
annotations:
alb.ingress.kubernetes.io/use-regex: "true" # Supports regular expressions in the path field.
alb.ingress.kubernetes.io/conditions.service-a: | # The Service specified in the annotation must be an existing Service in the cluster, and the Service name must be the same as the Service name in backend of the rule field.
[{
"type": "Path",
"pathConfig": {
"values": [
"~*^/pathvalue1", # The regular expression must follow the regular expression flag ~*.
"/pathvalue2" # No need to add ~* before the path for exact match.
]
}
}]
name: ingress-example
spec:
ingressClassName: alb
rules:
- http:
paths:
- path: /test
pathType: Prefix
backend:
service:
name: service-a
port:
number: 88
書き換えルールの設定
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
metadata:
annotations:
alb.ingress.kubernetes.io/use-regex: "true" # Supports regular expressions in the path field.
alb.ingress.kubernetes.io/rewrite-target: /path/${2} # Variables that match the regular expressions are concatenated to form the path that overwrites the original path.
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
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
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
1.19より前のバージョンのKubernetesを実行するクラスター
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
annotations:
alb.ingress.kubernetes.io/listen-ports: '[{"HTTP": 80},{"HTTPS": 443}]'
name: 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
path: /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
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
1.19より前のバージョンのKubernetesを実行するクラスター
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
annotations:
alb.ingress.kubernetes.io/order: "2"
name: cafe-ingress
spec:
ingressClassName: alb
rules:
- host: demo.alb.ingress.top
http:
paths:
- backend:
serviceName: tea-svc
servicePort: 80
path: /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 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
1.19より前のバージョンのKubernetesを実行するクラスター
apiVersion: networking.k8s.io/v1beta1 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: serviceName:demo-service-hello servicePort: 80 path: /hello pathType: ImplementationSpecific
alb.ingress.kubernetes.io/canary-by-cookie
: このルールはリクエストのcookieと一致します。cookie
を常に
に設定した場合、ルールに一致するリクエストは新しいアプリケーションバージョンにルーティングされます。cookie
をnever
に設定した場合、ルールに一致するリクエストは古いアプリケーションバージョンにルーティングされます。
説明Cookieベースのカナリアリリースルールは、他の設定をサポートしていません。 cookieの値は、
常に
または絶対
ではありません。demo=always
cookieを含むリクエストは、新しいアプリケーションバージョンにルーティングされます。 例:Kubernetes 1.19以降を実行するクラスター
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
1.19より前のバージョンのKubernetesを実行するクラスター
apiVersion: networking.k8s.io/v1beta1 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: serviceName:demo-service-hello servicePort: 80 path: /hello pathType: ImplementationSpecific
alb.ingress.kubernetes.io/canary-weight
: このルールでは、指定したサービスに送信されるリクエストの割合を設定できます。 0から100までの整数を入力できます。次の例では、新しいアプリケーションバージョンにルーティングされるリクエストの割合を50% に設定します。
Kubernetes 1.19以降を実行するクラスター
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
1.19より前のバージョンのKubernetesを実行するクラスター
apiVersion: networking.k8s.io/v1beta1 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: serviceName: demo-service-hello servicePort: 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を挿入します。 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
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:
# Configure a context path.
- path: /tea2
backend:
service:
name: tea-svc
port:
number: 80
# Configure a context path.
- path: /coffee2
backend:
service:
name: coffee-svc
port:
number: 80
1.19より前のバージョンのKubernetesを実行するクラスター
apiVersion: networking.k8s.io/v1beta1
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:
# Configure a context path.
- path: /tea2
backend:
serviceName: tea-svc
servicePort: 80
# Configure a context path.
- path: /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
metadata:
name: cafe-ingress
annotations:
alb.ingress.kubernetes.io/backend-scheduler: "uch" # Replace uch with wrr, sch, or wlc based on your business requirements.
alb.ingress.kubernetes.io/backend-scheduler-uch-value: "test" # This parameter is required only if the load balancing algorithm is uch. You do not need to configure this parameter if the scheduling algorithm is wrr, sch, or 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
1.19より前のバージョンのKubernetesを実行するクラスター
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
annotations:
alb.ingress.kubernetes.io/backend-scheduler: "uch" # Replace uch with wrr, sch, or wlc based on your business requirements.
alb.ingress.kubernetes.io/backend-scheduler-uch-value: "test" # This parameter is required only when the load balancing algorithm is uch. You do not need to configure this parameter when the scheduling algorithm is wrr, sch, or wlc.
name: cafe-ingress
spec:
ingressClassName: alb
rules:
- host: demo.alb.ingress.top
http:
paths:
- backend:
serviceName: tea-svc
servicePort: 80
path: /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
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接続機能を使用できます。 永続的なTCP接続機能を有効にするには、alb ingressにALB. Ingress. kubernetes.io/backend-keepalive
アノテーションを追加します。 例:
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 Ingressに追加して、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が新しいポッドにトラフィックをすぐに配信すると、CPUまたはメモリの使用量が急激に増加し、アクセスの問題が発生する可能性があります。 スロースタートモードでは、ALB Ingressはトラフィックを徐々に新しいポッドにシフトして、突然のトラフィックサージの影響を緩和します。 次のサンプルコードは例を示しています。
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
annotations:
alb.ingress.kubernetes.io/slow-start-enabled: "true"
alb.ingress.kubernetes.io/slow-start-duration: "100"
name: alb-ingress
spec:
ingressClassName: alb
rules:
- host: alb.ingress.alibaba.com
http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: tea-svc
port:
number: 80
パラメーター | 説明 |
alb.ingress.kubernetes.io/slow-start-enabled | スロースタートモードを有効にするかどうかを指定します。
デフォルトでは、このモードは無効になっています。 |
alb.ingress.kubernetes.io/slow-start-duration | スロースタートが徐々にトラフィックを増やすのにかかる時間。 持続時間が長いほど、トラフィックの増加は遅くなります。 単位は秒です。 有効な値: 30 ~ 900 既定値: |
接続のドレイン
ポッドが終了状態になると、ALB Ingressはそれをバックエンドから削除します。 しかしながら、進行中の要求は、確立された接続に依然として存在し得、ALB Ingressがすべての接続を直ちに閉じる場合、エラーが発生し得る。 接続ドレインを有効にすると、ALB Ingressは、ポッドが削除された後も指定された期間接続を開いたままにし、現在の要求が完了するとスムーズなシャットダウンを保証します。 接続ドレインモードは次のとおりです。
無効: ポッドが終了状態になると、ALB Ingressはバックエンドからポッドを削除し、すぐにすべての接続を閉じます。
有効: ポッドが終了状態になると、ALB Ingressは進行中のリクエストを開いたままにしますが、新しいリクエストは受け付けません。
進行中の要求がある場合、ALB Ingressはすべての接続を閉じ、タイムアウトに達するとポッドを削除します。
ポッドがタイムアウト前にすべての要求を完了した場合、ALB Ingressはすぐにそれを削除します。
接続のドレインが終了する前に、ALB Ingressはポッドとの接続を終了しませんが、ポッドが実行されたままであることを保証できません。 spec.terminationGracePeriodSeconds
を設定するか、preStopフックを使用して、終了状態のポッドの可用性を制御できます。
次のサンプルコードは、接続ドレインを設定する例を示しています。
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
annotations:
alb.ingress.kubernetes.io/connection-drain-enabled: "true"
alb.ingress.kubernetes.io/connection-drain-timeout: "199"
name: alb-ingress
spec:
ingressClassName: alb
rules:
- host: alb.ingress.alibaba.com
http:
paths:
- path: /test
pathType: Prefix
backend:
service:
name: tea-svc
port:
number: 80
パラメーター | 説明 |
alb.ingress.kubernetes.io/connection-drain-enabled | 接続ドレインを有効にするかどうかを指定します。
デフォルトでは、接続のドレインは無効になっています。 |
alb.ingress.kubernetes.io/connection-drain-timeout | 接続ドレインのタイムアウト期間。 単位は秒です。 有効な値: 0 ~ 900 デフォルト値: |