Application Load Balancer(ALB)Ingress は、Kubernetes クラスター内のサービスへの外部アクセスを管理するためのレイヤー 7 ロードバランシングを提供する API オブジェクトです。このトピックでは、ALB Ingress を使用して、ドメイン名と URL パスに基づいてバックエンドサーバーグループにリクエストを転送する方法、HTTP リクエストを HTTPS にリダイレクトする方法、およびカナリアリリースを実装する方法について説明します。
目次
カテゴリ | 例 |
ALB Ingress の構成 | |
ポートとプロトコルの構成 | |
転送ルールの構成 | |
高度な構成 |
前提条件
ALB Ingress コントローラーがクラスターにインストールされていること。詳細については、「ALB Ingress コントローラーを管理する」をご参照ください。
説明ALB Ingress を使用して ACK 専用クラスター にデプロイされたサービスにアクセスするには、まず、クラスターに ALB Ingress コントローラーに必要な権限を付与する必要があります。詳細については、「ACK 専用クラスターに ALB Ingress コントローラーへのアクセスを承認する」をご参照ください。
AlbConfig オブジェクトが作成されていること。詳細については、「AlbConfig オブジェクトを作成する」をご参照ください。
ドメイン名に基づいてリクエストを転送する
次の手順を実行して、ドメイン名を持つ 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
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/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 の構成を示しています。
Kubernetes 1.19 以降を実行するクラスター
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 pathType: ImplementationSpecific
Kubernetes 1.19 より前のバージョンを実行するクラスター
apiVersion: networking.k8s.io/v1beta1 kind: Ingress metadata: name: demo namespace: default spec: ingressClassName: alb rules: - host: "" http: paths: - backend: serviceName: demo-service servicePort: 80 path: /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 パスがルールと一致するかどうか |
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
次のテンプレートは、Ingress の構成を示しています。
Kubernetes 1.19 以降を実行するクラスタ
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
Kubernetes 1.19 より前のバージョンを実行するクラスタ
apiVersion: networking.k8s.io/v1beta1 kind: Ingress metadata: name: demo-path namespace: default spec: ingressClassName: alb rules: - http: paths: - path: /hello backend: serviceName: demo-service servicePort: 80 pathType: Exact
次のコマンドを実行して、アプリケーションにアクセスします。
[ADDRESS] を、関連する ALB インスタンスの IP アドレスに置き換えます。
kubectl get ing
コマンドを実行することで、IP アドレスを照会できます。curl <ADDRESS>/hello
予期される出力:
{"hello":"coffee"}
ImplementationSpecific: デフォルトの一致ポリシー
ALB Ingress の構成は、Exact
一致ポリシーの構成と同じです。
次のテンプレートは、Ingress の構成を示しています。
次のコマンドを実行して、アプリケーションにアクセスします。
[ADDRESS] を、関連する ALB インスタンスの IP アドレスに置き換えます。
kubectl get ing
コマンドを実行することで、IP アドレスを照会できます。
Kubernetes 1.19 以降を実行するクラスタ
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
Kubernetes 1.19 より前のバージョンを実行するクラスタ
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
name: demo-path
namespace: default
spec:
ingressClassName: alb
rules:
- http:
paths:
- path: /hello
backend:
serviceName: demo-service
servicePort: 80
pathType: ImplementationSpecific
curl <ADDRESS>/hello
予期される出力:
{"hello":"coffee"}
Prefix
指定されたプレフィックスを 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
Kubernetes 1.19 より前のバージョンを実行するクラスタ
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
name: demo-path-prefix
namespace: default
spec:
ingressClassName: alb
rules:
- http:
paths:
- path: /
backend:
serviceName: demo-service
servicePort: 80
pathType: Prefix
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:
# コンテキストパスを設定します。
- path: /tea
backend:
service:
name: tea-svc
port:
number: 80
# コンテキストパスを設定します。
- path: /coffee
backend:
service:
name: coffee-svc
port:
number: 80
Kubernetes 1.19 より前のバージョンを実行するクラスタ
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:
# コンテキストパスを設定します。
- 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 | サーバーが正常と見なされる前に、バックエンドサーバーがヘルスチェックに連続して合格する必要がある回数。 有効値: 2 ~ 10。 デフォルト値: |
alb.ingress.kubernetes.io/unhealthy-threshold-count | サーバーが異常と見なされる前に、バックエンドサーバーがヘルスチェックに連続して失敗する必要がある回数。 有効値: 2 ~ 10。 デフォルト値: |
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
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/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 をサポートしています。alb.ingress.kubernetes.io/backend-protocol: "grpc"
または alb.ingress.kubernetes.io/backend-protocol: "https"
アノテーションを追加することで、HTTPS または gRPC を構成できます。Ingress を使用して gRPC サービスにリクエストを分散する場合は、gRPC サービスの SSL 証明書を構成し、TLS プロトコルを使用して gRPC サービスと通信する必要があります。例:
Ingress の作成後、バックエンドプロトコルを変更することはできません。プロトコルを変更するには、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
Kubernetes 1.19 より前のバージョンを実行するクラスタ
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" # 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 Ingress は書き換えルールをサポートしています。alb.ingress.kubernetes.io/rewrite-target: /path/${2}
アノテーションを追加することで、書き換えルールを構成できます。次のルールが適用されます。
rewrite-target
アノテーションでは、${number}
タイプの変数に対してpathType
フィールドを Prefix に設定する必要があります。デフォルトでは、
path
パラメーターは、アスタリスク (*
) や疑問符 (?
) など、正規表現でサポートされている文字をサポートしていません。 path パラメーターで正規表現で使用される文字を指定するには、alb.ingress.kubernetes.io/use-regex: "true" アノテーションを追加する必要があります。path
パラメーターの値は、スラッシュ (/
) で始まる必要があります。
書き換えルールで正規表現を指定する場合、次の点に注意してください。
ALB Ingress の
path
フィールドには、1 つ以上の正規表現を指定し、括弧()
で囲むことができます。ただし、rewrite-target
アノテーションでは、最大 3 つの変数 (${1}
、${2}
、${3}
) を使用して、元のパスを上書きするパスを形成できます。正規表現に一致する変数は連結され、元のパスを上書きするパスが形成されます。
元のパスは、次の要件が満たされた場合にのみ、正規表現に一致する変数によって上書きされます。括弧
()
で囲まれた複数の正規表現が指定されており、rewrite-target
アノテーションが次の変数の 1 つ以上に設定されている必要があります。${1}
、${2}
、${3}
。
ALB Ingress の path
パラメーターが /sys/(.*)/(.*)/aaa
に設定され、rewrite-target
アノテーションが /${1}/${2}
に設定されているとします。クライアントが /sys/ccc/bbb/aaa
path
にリクエストを送信すると、リクエストは正規表現 /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" # 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
Kubernetes 1.19 より前のバージョンを実行するクラスタ
apiVersion: networking.k8s.io/v1beta1
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:
- backend:
serviceName: rewrite-svc
servicePort: 9080
path: /something(/|$)(.*)
pathType: Prefix
カスタム リスニング ポートを構成する
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
Kubernetes 1.19 より前のバージョンを実行するクラスタ
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 パラメーターの値の辞書順で優先順位が付けられます。
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
Kubernetes 1.19 より前のバージョンを実行するクラスタ
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"
を追加することで、カナリアリリース機能を有効にできます。 その後、以下のアノテーションを使用して、さまざまなカナリアリリースルールを設定できます。
異なるルールを使用するカナリアリリースは、ヘッダーベース > Cookie ベース > 重みベースの順に有効になります。
新しいアプリケーションバージョンのテストにカナリアリリースを実行する場合、元の Ingress ルールを変更しないでください。 変更すると、アプリケーションへのアクセスが中断される可能性があります。 新しいアプリケーションバージョンがテストに合格したら、以前のアプリケーションバージョンで使用されていたバックエンド サービス を新しいアプリケーションバージョンで使用されているバックエンド サービス に置き換えます。 その後、カナリアリリースを実装するための Ingress ルールを削除します。
alb.ingress.kubernetes.io/canary-by-header
およびalb.ingress.kubernetes.io/canary-by-header-value
: このルールは、リクエストのヘッダーとヘッダー値に一致します。 このルールを使用する場合は、両方のannotations
を追加する必要があります。リクエストの
header
とheader value
がルールと一致する場合、リクエストは新しいアプリケーションバージョンにルーティングされます。リクエストの
header
がheader
ベースのルールと一致しない場合、リクエストはルールの優先順位に基づいて他のタイプのルールと照合されます。
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
Kubernetes 1.19 より前のバージョンを実行するクラスタ
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
をalways
に設定すると、ルールに一致するリクエストは新しいアプリケーションバージョンにルーティングされます。cookie
をnever
に設定すると、ルールに一致するリクエストは古いアプリケーションバージョンにルーティングされます。
説明Cookie ベースのカナリアリリースルールは、他の設定をサポートしていません。 Cookie 値は、
always
またはnever
である必要があります。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
Kubernetes 1.19 より前のバージョンを実行するクラスタ
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
Kubernetes 1.19 より前のバージョンを実行するクラスタ
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
。単位: 秒。alb.ingress.kubernetes.io/cookie
: カスタム Cookie を指定します。タイプ: 文字列。デフォルト値:""
。
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" # カスタム Cookie をサポートするには、挿入される Cookie のタイプを Server
に設定する必要があります。
alb.ingress.kubernetes.io/cookie-timeout: "1800"
alb.ingress.kubernetes.io/cookie: "test"
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
Kubernetes 1.19 より前のバージョンを実行するクラスタ
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" # カスタム Cookie をサポートするには、挿入される Cookie のタイプを Server
に設定する必要があります。
alb.ingress.kubernetes.io/cookie-timeout: "1800"
alb.ingress.kubernetes.io/cookie: "test"
spec:
ingressClassName: alb
rules:
- http:
paths:
# コンテキストパスを設定します。
- path: /tea2
backend:
serviceName: tea-svc
servicePort: 80
# コンテキストパスを設定します。
- 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" # ビジネス要件に基づいて、uch を wrr、sch、または wlc に置き換えます。
alb.ingress.kubernetes.io/backend-scheduler-uch-value: "test" # このパラメーターは、負荷分散アルゴリズムが uch の場合にのみ必須です。スケジューリングアルゴリズムが wrr、sch、または wlc の場合は、このパラメーターを設定する必要はありません。
spec:
ingressClassName: alb
rules:
- host: demo.alb.ingress.top
http:
paths:
- path: /tea
pathType: ImplementationSpecific
backend:
service:
name: tea-svc
port:
number: 80
Kubernetes 1.19 より前のバージョンを実行するクラスタ
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
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:
- backend:
serviceName: tea-svc
servicePort: 80
path: /tea-svc
pathType: ImplementationSpecific
次の説明に基づいて、アノテーション alb.ingress.kubernetes.io/backend-scheduler
を設定します。
wrr
: 重みの大きいバックエンドサーバーは、重みの小さいバックエンドサーバーよりも多くのリクエストを受け取ります。これはデフォルト値です。wlc
: リクエストは、各バックエンドサーバーの重みと負荷に基づいて分散されます。負荷とは、バックエンドサーバーへの接続数を指します。複数のバックエンドサーバーの重みが同じ場合、リクエストは接続数が最も少ないバックエンドサーバーに転送されます。sch
: ソース IP アドレスに基づく一貫したハッシュです。uch
: URL パラメーターに基づく一貫したハッシュです。バックエンドサーバーグループの負荷分散アルゴリズムがuch
の場合、一貫したハッシュの URL パラメーターを指定するために、ALB Ingress にアノテーションalb.ingress.kubernetes.io/backend-scheduler-uch-value
を追加できます。
CORS の構成
次のコードブロックは、ALB Ingress でサポートされているクロスオリジンリソースシェアリング(CORS)構成の例を示しています。
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: alb-ingress
annotations:
alb.ingress.kubernetes.io/enable-cors: "true" # CORS を有効にする
alb.ingress.kubernetes.io/cors-expose-headers: "" # 公開するヘッダー
alb.ingress.kubernetes.io/cors-allow-methods: "GET,POST" # 許可する HTTP メソッド
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 (キャッシュ無効)から 172,800 (48 時間)です。 デフォルト値: |
持続的接続の設定
従来のロードバランサーは、短期間の接続でバックエンドサーバーにアクセスします。 従来のロードバランサーは、バックエンドサーバーにリクエストを転送するたびに接続を作成して接続を閉じる必要があります。 その結果、ネットワーク接続がパフォーマンスボトルネックになります。 ネットワーク接続の確立に使用されるリソースの量を削減し、転送パフォーマンスを向上させるために、TCP 持続的接続機能を使用できます。 alb.ingress.kubernetes.io/backend-keepalive
アノテーションを ALB Ingress に追加して、TCP 持続的接続機能を有効にできます。 例:
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: alb-ingress
annotations:
alb.ingress.kubernetes.io/backend-keepalive: "true" # TCP持続的接続を有効にする
spec:
ingressClassName: alb
rules:
- host: demo.alb.ingress.top
http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: cloud-nodeport
port:
number: 80
バックエンドサーバーグループで IPv6 を有効にする
バックエンドサーバーグループで IPv6 を有効にした後、デュアルスタック ポッドをサーバーグループにアタッチする必要がある場合は、クラスタで IPv4/IPv6 デュアルスタックが有効になっており、対応する Service に ipFamilies
と ipFamilyPolicy
が定義されていることを確認してください。デュアルスタック構成では、次のようになります。
ipFamilies
はIPv4
またはIPv6
に設定する必要があります。ipFamilyPolicy
はRequireDualStack
またはPreferDualStack
に設定する必要があります。
ALB Ingress でアノテーション alb.ingress.kubernetes.io/enable-ipv6: "true"
を追加することで、特定のサーバーグループに対して IPv6 を有効にできます。デュアルスタック ALB インスタンスを作成した後、バックエンドサーバーグループに対して IPv6 を有効にするかどうかを指定できます。サーバーグループには、IPv4 と IPv6 の両方のバックエンドサーバーをマウントできます。
IPv6 を有効にする際の制限事項は次のとおりです。
サーバーグループに関連付けられている仮想プライベートクラウド (VPC) で IPv6 が有効になっていない場合、そのサーバーグループに対して IPv6 を有効にすることはできません。
カスタム転送を介してマウントされた IP タイプのサーバーグループ、または Function Compute タイプのサーバーグループに対しては、IPv6 を有効にすることはできません。
IPv4 専用の ALB インスタンスに関連付けられている場合、Ingress に対して IPv6 を有効にすることはできません。
apiVersion: v1
kind: Service
metadata:
name: tea-svc
annotations:
spec:
# デュアルスタック構成の場合: ipFamilies を IPv4 または IPv6 に設定し、ipFamilyPolicy を RequireDualStack または PreferDualStack に設定します。
ipFamilyPolicy: RequireDualStack
ipFamilies:
- IPv4
- IPv6
ports:
- port: 80
targetPort: 80
protocol: TCP
selector:
app: tea
type: NodePort
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: tea
spec:
replicas: 2
selector:
matchLabels:
app: tea
template:
metadata:
labels:
app: tea
spec:
containers:
- name: tea
image: registry.cn-hangzhou.aliyuncs.com/acs-sample/nginxdemos:latest
ports:
- containerPort: 80
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: cafe-ingress
annotations:
alb.ingress.kubernetes.io/enable-ipv6: "true"
spec:
ingressClassName: alb
rules:
- host: demo.alb.ingress.top
http:
paths:
- path: /tea
pathType: Prefix
backend:
service:
name: tea-svc
port:
number: 80
QPS スロットリングの設定
ALB は転送ルールに対して QPS スロットリングをネイティブでサポートしており、有効な値の範囲は 1 ~ 1,000,000 です。alb.ingress.kubernetes.io/traffic-limit-qps
アノテーションを設定することで、ALB Ingress でこれを有効にできます。例:
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: cafe-ingress
annotations:
alb.ingress.kubernetes.io/traffic-limit-qps: "50" # 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。 デフォルト値: |
接続ドレイン
ポッドが Terminating 状態になると、ALB Ingress はバックエンドからポッドを削除します。ただし、確立された接続には進行中のリクエストがまだ存在する可能性があり、ALB Ingress がすぐにすべての接続を閉じるとエラーが発生する可能性があります。接続ドレインを有効にすると、ポッドが削除された後、ALB Ingress は指定された期間接続を開いたままにし、現在のリクエストが完了したらスムーズにシャットダウンできるようにします。接続ドレインモードは次のとおりです。
無効: ポッドが Terminating 状態になると、ALB Ingress はバックエンドからポッドを削除し、すぐにすべての接続を閉じます。
有効: ポッドが Terminating 状態になると、ALB Ingress は進行中のリクエストを開いたままにしますが、新しいリクエストは受け入れません。
進行中のリクエストがある場合、ALB Ingress はタイムアウトに達するとすべての接続を閉じてポッドを削除します。
タイムアウト前にポッドがすべてのリクエストを完了した場合、ALB Ingress はすぐにポッドを削除します。
接続ドレインが終了する前に、ALB Ingress はポッドとの接続を終了しませんが、ポッドの実行状態を保証することはできません。spec.terminationGracePeriodSeconds
を設定するか、preStop フックを使用することで、Terminating 状態のポッドの可用性を制御できます。
次のサンプルコードは、接続ドレインを設定する例を示しています。
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。 デフォルト値: |
ゾーン間の転送を無効にする
デフォルトでは、ALB はゾーン間の転送を有効にしており、トラフィックを同じリージョン内の異なるアベイラビリティーゾーンにあるバックエンド サービスに均等に分散します。 ALB サーバー グループでこの機能が無効になっている場合、トラフィックはリージョン内の同じゾーンにあるバックエンド サービスにのみ分散されます。
ゾーン間の転送を無効にする前に、次の点を確認してください。
各ゾーンに ALB で使用可能なバックエンド サービスが構成されていることを確認します。
各ゾーンのバックエンド サーバーに十分なリソースがあることを確認します。
サービスの中断を避けるために、慎重に作業を進めてください。
次のサンプル コードは、ゾーン間の転送を無効にする方法を示しています。
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
annotations:
alb.ingress.kubernetes.io/cross-zone-enabled: "false" # ゾーン間の転送を無効化
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/cross-zone-enabled | ゾーン間の転送を有効にするかどうかを指定します。
デフォルトでは、ゾーン間の転送は有効になっています。 |