ALB イングレスは、Alibaba Cloud Application Load Balancer (ALB) を基盤としたレイヤー 7 トラフィック管理機能を提供し、HTTP、HTTPS、および QUIC をサポートします。本チュートリアルでは、URL パスに基づいてトラフィックを異なるバックエンドサービスにルーティングする方法を説明します。
ALB イングレスの仕組み
基本概念:
ALB イングレスコントローラ:このコンポーネントは Ingress リソースを管理します。クラスターの API Server から Ingress および AlbConfig リソースの変更を動的に取得し、それに応じて ALB インスタンスを更新します。NGINX イングレスコントローラとは異なり、ALB イングレスコントローラは ALB インスタンスのコントロールプレーンとして機能します。ALB インスタンス自体を管理しますが、ユーザーのトラフィックを直接処理することはありません。代わりに、ALB インスタンスがユーザーのトラフィックを転送します。ALB イングレスコントローラは、クラスターの API Server から Ingress リソースの変更を動的に取得し、Ingress で定義された転送ルールに基づいて ALB インスタンスを更新します。
AlbConfig:ALB イングレスコントローラによって作成されるクラスターレベルのカスタムリソース定義 (CRD) です。各 AlbConfig には、単一の ALB インスタンスの構成を定義するパラメーターが含まれます。ALB インスタンスはトラフィックのエントリーポイントとして機能し、リクエストをバックエンドサービスに転送します。これは Application Load Balancer (ALB) によってフルマネージドされます。Nginx イングレスコントローラとは異なり、ALB イングレスは運用・保守 (O&M) の手間が不要で、より高い弾力性を提供します。
IngressClass:Ingress と AlbConfig の関連付けを定義します。
Ingress:Kubernetes において、Ingress は外部トラフィックのルーティングおよびアクセスルールを定義するリソースオブジェクトです。ALB イングレスコントローラは Ingress リソースの変更を監視し、ALB インスタンスを更新してトラフィック転送を実現します。
-
Service:同じ機能を持つ Pod グループへの安定したエントリーポイントです。他のアプリケーションは、Service の仮想 IP およびポートを通じてバックエンドの Pod にアクセスし、個々の Pod の変更から切り離されます。
次の図は、ALB インスタンスと ALB イングレスの関係を示しています。
制限事項
AlbConfig、namespace、ingress、および service リソース名は、aliyun で始まってはいけません。
ユースケース
本チュートリアルでは、4 つの Nginx Pod をデプロイし、同じドメイン下で URL パスに基づいて ALB イングレスによるトラフィックルーティングを設定します。
|
フロントエンドリクエスト |
バックエンドサービス |
|
|
|
|
|
|
前提条件
-
ご利用のクラスターの VPC 内に、異なる可用性ゾーンに 2 つの vSwitch を作成済みである必要があります。vSwitch の作成と管理をご参照ください。
ステップ 1:バックエンドサービスのデプロイ
コンソールを使用する方法
-
ACS コンソールにログインします。左側のナビゲーションウィンドウで、クラスターリストをクリックします。
-
クラスターリストページで、対象のクラスター名をクリックします。左側のナビゲーションウィンドウで、Workloads > Deploymentsを選択します。
-
Deploymentsページの右上隅で、YAML から作成をクリックします。
-
Createページで、パラメーターを設定します。
-
Sample Template: Customを選択します。
-
Template: 2 つのデプロイメント(
coffeeおよびtea)と 2 つのサービス(coffee-svcおよびtea-svc)をデプロイするための YAML 構成を入力します。
-
-
Createをクリックします。「作成完了」というメッセージが表示されます。
-
デプロイメントおよびサービスが作成されたことを確認します。
-
左側のナビゲーションウィンドウで、ワークロード > ステートレスを選択します。
coffeeおよびteaという名前のデプロイメントが表示されます。 -
左側のナビゲーションウィンドウで、ネットワーク > サービスを選択します。
coffee-svcおよびtea-svcという名前のサービスが表示されます。
-
kubectl を使用する方法
-
次の内容を含む
cafe-service.yamlという名前のファイルを作成します。これにより、2 つのデプロイメント(coffeeおよびtea)と 2 つのサービス(coffee-svcおよびtea-svc)がデプロイされます。 -
次のコマンドを実行してリソースをデプロイします。
kubectl apply -f cafe-service.yaml期待される出力:
deployment "coffee" created service "coffee-svc" created deployment "tea" created service "tea-svc" created -
デプロイメントおよびサービスを確認します。
-
デプロイメントを確認します。
kubectl get deployment期待される出力:
NAME READY UP-TO-DATE AVAILABLE AGE coffee 2/2 2 2 2m26s tea 2/2 2 2 2m26s -
サービスを確認します。
kubectl get svc期待される出力:
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE coffee-svc ClusterIP 172.16.XX.XX <none> 80/TCP 9m38s tea-svc ClusterIP 172.16.XX.XX <none> 80/TCP 9m38s
-
ステップ 2:AlbConfig の作成
コンソール
-
ACS コンソールにログインします。左側のナビゲーションウィンドウで、クラスターリストをクリックします。
-
クラスターリストページで、対象のクラスター名をクリックします。左側のナビゲーションウィンドウで、Workloads > カスタムリソースを選択します。
-
CRDs タブで、Create from YAMLをクリックします。
-
Sample Template: Customを選択します。
-
Template: YAML マニフェストを貼り付けます。
次の表は、パラメーターの説明です。
パラメーター
必須
説明
metadata.nameはい
AlbConfig の名前。
説明AlbConfig 名はクラスター内で一意である必要があります。重複を避けてください。
spec.config.nameいいえ
ALB インスタンスの名前。
spec.config.addressTypeいいえ
ALB インスタンスのネットワークタイプ。有効な値:
-
Internet(デフォルト):インターネット経由でパブリックな負荷分散サービスを提供します。
説明インターネット向け ALB インスタンスは EIP を使用します。EIP インスタンス、帯域幅、データ転送に対して課金されます。従量課金をご参照ください。
-
Intranet:VPC 内でプライベートな負荷分散サービスを提供します。
spec.config.zoneMappingsはい
ALB インスタンス用の vSwitch ID。vSwitch の作成方法については、「vSwitch の作成と管理」をご参照ください。
説明-
vSwitch は ALB がサポートする可用性ゾーンにあり、かつクラスターと同じ VPC 内にある必要があります。ALB がサポートするリージョンと可用性ゾーンをご参照ください。
-
ご利用のリージョンに複数の可用性ゾーンがある場合は、高可用性のために少なくとも 2 つの異なるゾーンから vSwitch を選択することを推奨します。
spec.listenersいいえ
リスナーポートおよびプロトコル。この例では、ポート 80 の HTTP を使用します。
ALB イングレスにはリスナーが必要です。手動での構成を避けるため、このデフォルト設定を維持してください。
-
-
-
Createをクリックします。「作成完了」というメッセージが表示されます。
-
ALB インスタンスを確認します。
-
上部のナビゲーションバーで、インスタンスのリージョンを選択します。
-
インスタンスページで、インスタンスリストに alb-test という名前の ALB インスタンスが表示されることを確認します。
kubectl
-
次の内容を alb-test.yaml という名前のファイルにコピーして、AlbConfig を作成します。
次の表は、パラメーターの説明です。
パラメーター
必須
説明
metadata.nameはい
AlbConfig の名前。
説明AlbConfig 名はクラスター内で一意である必要があります。重複を避けてください。
spec.config.nameいいえ
ALB インスタンスの名前。
spec.config.addressTypeいいえ
ALB インスタンスのネットワークタイプ。有効な値:
-
Internet(デフォルト):インターネット経由でパブリックな負荷分散サービスを提供します。
説明インターネット向け ALB インスタンスは EIP を使用します。EIP インスタンス、帯域幅、データ転送に対して課金されます。従量課金をご参照ください。
-
Intranet:VPC 内でプライベートな負荷分散サービスを提供します。
spec.config.zoneMappingsはい
ALB インスタンス用の vSwitch ID。vSwitch の作成方法については、「vSwitch の作成と管理」をご参照ください。
説明-
vSwitch は ALB がサポートする可用性ゾーンにあり、かつクラスターと同じ VPC 内にある必要があります。ALB がサポートするリージョンと可用性ゾーンをご参照ください。
-
ご利用のリージョンに複数の可用性ゾーンがある場合は、高可用性のために少なくとも 2 つの異なるゾーンから vSwitch を選択することを推奨します。
spec.listenersいいえ
リスナーポートおよびプロトコル。この例では、ポート 80 の HTTP を使用します。
ALB イングレスにはリスナーが必要です。手動での構成を避けるため、このデフォルト設定を維持してください。
-
-
次のコマンドを実行して AlbConfig を作成します。
kubectl apply -f alb-test.yaml期待される出力:
albconfig.alibabacloud.com/alb-demo createdこの出力により、AlbConfig が正常に作成されたことが確認できます。
ステップ 3:IngressClass の作成
各 AlbConfig ごとに 1 つの IngressClass を作成することを推奨します。
コンソール
-
ACS コンソールにログインします。左側のナビゲーションウィンドウで、クラスターリストをクリックします。
-
クラスターリストページで、対象のクラスター名をクリックします。左側のナビゲーションウィンドウで、Workloads > カスタムリソースを選択します。
-
CRDs タブで、Create from YAMLをクリックします。
-
Sample Template: Customを選択します。
-
Template: YAML マニフェストを入力します。
次の表は、パラメーターの説明です。
パラメーター
必須
説明
metadata.name
はい
IngressClass の名前。
説明名前はクラスター内で一意である必要があります。
spec.parameters.name
はい
関連付ける AlbConfig の名前。
-
-
Createをクリックします。確認メッセージが表示されます。
-
IngressClass が作成されたことを確認します。
-
左側のナビゲーションウィンドウで、を選択します。
-
リソースオブジェクトタブをクリックします。
-
API グループ検索ボックスに IngressClass と入力します。作成した IngressClass が表示されます。
-
kubectl
-
次の内容を含む alb.yaml という名前のファイルを作成します。
次の表は、パラメーターの説明です。
パラメーター
必須
説明
metadata.nameはい
IngressClass の名前。
説明名前はクラスター内で一意である必要があります。
spec.parameters.nameはい
関連付ける AlbConfig の名前。
-
次のコマンドを実行して IngressClass を作成します。
kubectl apply -f alb.yaml期待される出力:
ingressclass.networking.k8s.io/alb created
ステップ 4:Ingress の作成
コンソール
-
ACS コンソールにログインします。左側のナビゲーションウィンドウで、クラスターリストをクリックします。
-
クラスターリストページで、対象のクラスター名をクリックします。左側のナビゲーションウィンドウで、ネットワーク > Ingressを選択します。
-
Ingressesページで、Ingress の作成をクリックします。Ingress の作成ダイアログボックスで、Ingress を設定します。
パラメーター
説明
例
ゲートウェイタイプ
ゲートウェイタイプを選択します。オプションには ALB と MSE があります。
ALB イングレス
名前
Ingress のカスタム名。
cafe-ingress
IngressClass
Ingress のカスタムクラス。
alb
ルール
+ルールの追加をクリックして、複数のルーティングルールを追加します。
-
ドメイン名: カスタムドメイン名。
-
マッピング: 次のパラメーターを設定します。
-
パス: サービスにアクセスするための URL パス。この例では、ルートパス / を使用するために、このパラメーターを空のままにします。
-
ルール: Prefix (前方一致)、Exact (完全一致)、および ImplementationSpecific (デフォルト値)をサポートします。
-
サービス: Kubernetes Service であるバックエンドターゲット。
-
ポート: サービスが公開するポート。
-
-
1 つの Ingress で、同じドメイン名の下に複数のパスをサポートします。+追加をクリックして、新しいパスを追加します。
-
ドメイン名: demo.domain.ingress.top
-
パスマッピング:
-
パス: /tea
-
ルール: ImplementationSpecific
-
サービス: tea-svc
-
ポート: 80
-
-
マッピング:
-
パス: /coffee
-
ルール: ImplementationSpecific
-
サービス: coffee-svc
-
ポート: 80
-
TLS 設定
TLS 証明書(HTTPS)を使用して Ingress を保護するには、このオプションを有効にします。
-
ドメイン名: カスタムドメイン名を入力します。
-
シークレット: TLS 証明書を含むシークレットを選択します。
シークレットを作成するには、次の手順を実行します。
-
シークレットの右側で、Createをクリックします。
-
Secret の作成ダイアログボックスで、名前、Cert、および Key を設定し、OKをクリックします。
-
シークレットドロップダウンリストから、作成したシークレットを選択します。
-
追加をクリックして、複数の TLS 設定を構成できます。
詳細については、「暗号化通信のための HTTPS 証明書の設定」をご参照ください。
TLS 設定は無効のままにしてください。この例では、この構成は必要ありません。
その他
-
カナリアリリース: カナリアリリースを有効にします。リクエストヘッダー、Cookie、および重みに基づいてカナリアルールを設定できます。
説明ルールの種類(リクエストヘッダー、Cookie、または重み)は 1 種類のみ設定できます。複数の種類を設定した場合、リクエストヘッダー、Cookie、重みの順にマッチングされます。
-
リクエストヘッダーに基づく: リクエストヘッダーに基づいてトラフィックを分割します。これにより、
alb.ingress.kubernetes.io/canary-by-headerアノテーションおよびalb.ingress.kubernetes.io/canary-by-header-valueアノテーションが追加されます。 -
Cookie に基づく: Cookie に基づいてトラフィックを分割します。これにより、
alb.ingress.kubernetes.io/canary-by-cookieアノテーションが追加されます。 -
重みに基づく: 特定のサービスにルーティングするリクエストの割合(0 ~ 100 の整数)を指定します。これにより、
alb.ingress.kubernetes.io/canary-weightアノテーションが追加されます。
-
-
プロトコル: バックエンドサービスの HTTPS および gRPC プロトコルを有効にし、
alb.ingress.kubernetes.io/backend-protocolアノテーションを追加します。 -
書き換えパス: クライアントリクエストのパスは、バックエンドサービスに送信される前に書き換えられます。この設定を構成すると、alb.ingress.kubernetes.io/rewrite-target アノテーションが追加されます。
カナリアリリースは無効のままにして、プロトコルおよびパス書き換えの設定はデフォルト値のままにしてください。この例では、これらの構成は必要ありません。
カスタム転送ルール
カスタム転送ルールを有効にして、インバウンドトラフィックを詳細に制御します。
説明転送ルールには最大 10 個の条件エントリーを追加できます。
-
転送条件ドロップダウンリストからオプションを選択します。
-
ドメイン名:
リクエストドメインと一致させます。複数のドメインを指定した場合、いずれかのドメインを使用したリクエストが一致します。この条件を構成すると、
alb.ingress.kubernetes.io/conditions.host-exampleアノテーションが追加されます。 -
パス:
リクエストパスと一致させます。複数のパスを指定した場合、いずれかのパスを使用したリクエストが一致します。この条件を構成すると、
alb.ingress.kubernetes.io/conditions.path-exampleアノテーションが追加されます。 -
HTTP ヘッダー:
キーと値のペアとしてリクエストヘッダーと一致させます。たとえば、キー:は
headername、値:はheadervalue1です。複数のヘッダー値を構成した場合、それらの関係は OR になります。この条件を構成すると、alb.ingress.kubernetes.io/conditions.http-header-exampleアノテーションが追加されます。
-
-
転送操作ドロップダウンリストからオプションを選択します。
-
転送先
重みに基づいて、1 つ以上のバックエンドサービスにリクエストを転送します。サービスフィールドで、ターゲットサービスを選択します。ポートフィールドで、ターゲットポート番号を選択します。次に、重みを指定します。
説明このアクションを選択した場合、ルール内のパスマッピングを構成する必要はありません。
-
固定のレスポンスを返す
ALB がクライアントに固定レスポンスを返すように構成します。レスポンスのステータスコード、本文コンテンツ、およびコンテンツタイプを設定できます。必要に応じて、レスポンスステータスコード、レスポンスボディタイプ (オプション)、および レスポンスボディ (オプション)を構成します。
レスポンス本文タイプ:
-
text/plain: プレーンテキスト。
-
text/css: CSS コンテンツ。
-
text/html: HTML コンテンツ。
-
application/javascript: JavaScript コンテンツ。
-
application/json: JSON コンテンツ。
-
-
カスタム転送ルールでは、ドメイン、パス、または HTTP ヘッダーに基づく条件と、サービスへの転送や固定レスポンスの返信などのアクションをサポートします。「ALB イングレスの転送ルールのカスタマイズ」をご参照ください。
カスタム転送ルールは無効のままにしてください。この例では、この構成は必要ありません。
アノテーション
カスタムアノテーション名と値を指定するか、アノテーションを選択または検索して構成できます。Ingress アノテーションの詳細については、「アノテーション」をご参照ください。
この例では必要ありません。
ラベル
Ingress に追加するラベルを指定します。ラベルは、オブジェクトに識別属性を指定するためにアタッチされるキーと値のペアです。
この例では必要ありません。
-
-
ingress の作成ページの左下隅で、OKをクリックします。
-
Ingress を確認します。
-
左側のナビゲーションウィンドウで、ネットワーク > ルートを選択します。cafe-ingress Ingress が表示されます。
-
cafe-ingress の エンドポイント列にエンドポイントアドレスが表示されます。
-
kubectl
-
cafe-ingress.yaml という名前のファイルを作成し、次の内容を追加します。
次の表は、パラメーターの説明です。
パラメーター
必須
説明
metadata.nameはい
Ingress の名前。
説明名前はクラスター内で一意である必要があります。競合を避けてください。
spec.ingressClassNameはい
関連付ける IngressClass の名前。
spec.rules.hostいいえ
HTTP
Hostヘッダーのドメイン名。ご自身のドメイン名を設定してください。Kubernetes は、受信した Host ヘッダーを Ingress ルールと照合し、一致したリクエストを指定されたバックエンドサービスにルーティングします。
説明-
カスタムドメイン名を使用する場合、中国本土からのアクセスには有効な ICP 登録が必要です。ICP 登録プロセスをご参照ください。
-
このパラメーターを設定しない場合、Ingress ルールは Ingress コントローラに到達したすべてのリクエストに一致します。
spec.rules.http.paths.pathはい
転送パスの URL。
spec.rules.http.paths.pathTypeはい
URL の一致ルール。URL パスに基づくリクエストのルーティングをご参照ください。
spec.rules.http.paths.backend.service.nameはい
バックエンドサービスの名前。
spec.rules.http.paths.backend.service.port.numberはい
バックエンドサービスのポート番号。
このポートがサービス定義と一致していることを確認してください。
-
-
次のコマンドを実行して、
pathベースのルーティングを使用してcoffeeサービスとteaサービスの Ingress を作成します。kubectl apply -f cafe-ingress.yaml期待される出力:
ingress.networking.k8s.io/cafe-ingress created -
(任意)Ingress に割り当てられた ALB DNS 名を取得します。
kubectl get ingress期待される出力:
NAME CLASS HOSTS ADDRESS PORTS AGE cafe-ingress alb demo.domain.ingress.top alb-m551oo2zn63yov****.cn-hangzhou.alb.aliyuncs.com 80 50s
(任意)ステップ 5:ドメイン名解決の設定
spec.rules.host にカスタムドメインを指定した場合は、ドメイン名解決を有効にするために、そのドメイン名に ALB DNS 名を指す CNAME レコードを追加します。
-
クラスター名をクリックして、クラスター管理ページを開きます。
-
左側のナビゲーションウィンドウで、ネットワーク > ルートを選択します。
-
cafe-ingress の エンドポイント列で、DNS 名をコピーします。
-
CNAME レコードを追加します。
-
Alibaba Cloud DNS コンソールにログインします。
-
ドメイン名解決ページで、ドメイン名の追加をクリックします。
-
ドメイン名の追加ダイアログボックスで、ドメイン名を入力し、OKをクリックします。
重要TXT レコードを使用してドメイン名を検証する必要があります。
-
対象のドメインについて、解決設定を Actions列でクリックします。
-
解決設定ページで、Add Recordをクリックします。
-
Add Recordパネルで、CNAME レコードの次の設定を構成し、OKをクリックします。
パラメーター
説明
レコードタイプ
ドロップダウンリストから CNAME を選択します。
ホストレコード
ドメイン名のプレフィックス(例:
www)。DNS リクエストソース
デフォルト値を選択します。
レコード値
エンドポイント列からコピーした DNS 名を入力します。
TTL
DNS レコードが DNS サーバーにキャッシュされる期間。デフォルト値を使用します。
-
ステップ 6:トラフィック転送のテスト
ブラウザにテストドメインと URL パスを入力して、トラフィックルーティングを確認します。
-
カスタムドメインを構成した場合は、そのドメインを使用します。
-
カスタムドメインを構成していない場合は、cafe-ingress エンドポイントの DNS 名を使用します。
この例では、ドメインは demo.domain.ingress.top です。
-
demo.domain.ingress.top/coffeeを入力します。coffee-svc バックエンドページが表示されます。
-
demo.domain.ingress.top/teaを入力します。tea-svc バックエンドページが表示されます。
関連ドキュメント
-
ALB イングレスサービスの高度な使用方法では、ヘルスチェック、HTTPS リダイレクト、カナリアリリース、カスタムリスナーポートについて説明しています。