ALB Ingress は、Alibaba Cloud Application Load Balancer (ALB) に基づくレイヤー 7 のトラフィック管理を提供し、HTTP、HTTPS、QUIC に対応しています。このチュートリアルでは、URL パスに基づいて、異なるバックエンドサービス にトラフィックをルーティングする方法を説明します。
ALB Ingress の仕組み
主要な概念:
ALB Ingress Controller: このコンポーネントは Ingress リソースを管理します。クラスターの API サーバーから Ingress および AlbConfig リソースの変更を動的に取得し、それに応じて ALB インスタンスを更新します。NGINX Ingress Controller とは異なり、ALB Ingress Controller は ALB インスタンスのコントロールプレーンとして機能します。ALB インスタンスを管理しますが、ユーザートラフィックを直接処理するわけではありません。代わりに、ALB インスタンスがユーザートラフィックを転送します。ALB Ingress Controller は、クラスターの API サーバーから Ingress リソースの変更を動的に取得し、Ingress で定義された転送ルールに基づいて ALB インスタンスを更新します。
AlbConfig: ALB Ingress Controller によって作成されるクラスターレベルの Custom Resource Definition (CRD) です。各 AlbConfig には、単一の ALB インスタンスの設定を定義するパラメーターが含まれています。ALB インスタンスはトラフィックのエントリポイントとして機能し、リクエストをバックエンドサービスに転送します。これは Application Load Balancer (ALB) によって完全に管理されます。Nginx Ingress Controller とは異なり、ALB Ingress は運用保守 (O&M) を必要とせず、より高い弾力性を提供します。
IngressClass: Ingress と AlbConfig の間の関連付けを定義します。
Ingress: Kubernetes において、Ingress は外部トラフィックのルーティングとアクセスルールを定義するリソースオブジェクトです。ALB Ingress Controller は Ingress リソースの変更を監視し、ALB インスタンスを更新してトラフィックの転送を実現します。
Service :同じ機能を持つ Pod グループの安定したエントリーポイントです。他のアプリケーションは、Service の仮想 IP とポートを通じてバックエンド Pod にアクセスするため、個々の Pod の変更に影響されません。
次の図は、ALB インスタンスと ALB Ingress の関係を示しています。
制限事項
AlbConfig、namespace、ingress、および service のリソース名は、aliyun で始まってはなりません。
シナリオ例
このチュートリアルでは、4 つの Nginx Pod をデプロイし、同じドメイン配下で URL パスによってトラフィックをルーティングするように ALB イングレスを設定します。
フロントエンドリクエスト | バックエンド Service |
|
|
|
|
前提条件
クラスターの VPC 内の 異なるアベイラビリティーゾーン に、2 つの VSwitch を作成していること。「VSwitch の作成と管理」をご参照ください。
ステップ 1: バックエンドサービスのデプロイ
コンソール
ACS コンソール にログインします。左側のナビゲーションペインで、クラスター をクリックします。
クラスター ページで、管理するクラスターを見つけ、その ID をクリックします。クラスター詳細ページの左側のナビゲーションペインで、 を選択します。
デプロイメント ページの右上隅にある YAML から作成 をクリックします。
作成を続ける ページで、パラメーターを設定します。
[Sample Template] : カスタム を選択します。
テンプレート : 2 つの Deployment (
coffeeとtea) と 2 つの Service (coffee-svcとtea-svc) をデプロイするための YAML 設定を入力します。
作成を続ける をクリックします。 「[作成完了]」というメッセージが表示されます。
Deployment と Service が作成されていることを確認します。
左側メニューで、[Workloads] > [Deployments] を選択します。
coffeeとteaの Deployment が表示されます。左側メニューで、[Network] > [Services] を選択します。
coffee-svcとtea-svcの Service が表示されます。
kubectl
次の内容で
cafe-service.yamlという名前のファイルを作成します。 これにより、2 つの Deployment (coffeeとtea) と 2 つの Service (coffee-svcとtea-svc) がデプロイされます。次のコマンドを実行して、リソースをデプロイします。
kubectl apply -f cafe-service.yaml期待される出力:
deployment "coffee" created service "coffee-svc" created deployment "tea" created service "tea-svc" createdDeployment と Service を確認します。
Deployment を確認します。
kubectl get deployment期待される出力:
NAME READY UP-TO-DATE AVAILABLE AGE coffee 2/2 2 2 2m26s tea 2/2 2 2 2m26sService を確認します。
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 コンソール にログインします。左側のナビゲーションペインで、クラスター をクリックします。
クラスター ページで、管理するクラスターを見つけ、その ID をクリックします。クラスター詳細ページの左側のナビゲーションペインで、ワークロード > カスタムリソース を選択します。
CRD タブで、[YAML から作成] をクリックします。
[サンプルテンプレート]: カスタム を選択します。
[テンプレート]: YAML マニフェストを貼り付けます。
パラメータの詳細は次の表をご参照ください。
パラメータ
必須
説明
metadata.nameはい
ALBConfig の名前。
説明名前の競合を避けるため、ALBConfig の名前はクラスター内で一意である必要があります。
spec.config.nameいいえ
ALB インスタンスの名前。
spec.config.addressTypeいいえ
ALB インスタンスのネットワークタイプ。有効な値:
[Internet] (デフォルト):インスタンスはインターネット経由でパブリック負荷分散サービスを提供します。説明インターネット向け ALB インスタンスは Elastic IP Address (EIP) を使用します。EIP インスタンス、帯域幅、データ転送に料金が発生します。詳細については、「従量課金」をご参照ください。
[Intranet] :インスタンスは VPC 内でプライベート負荷分散サービスを提供します。
spec.config.zoneMappingsはい
ALB インスタンスの vSwitch の ID。vSwitch の作成方法については、「vSwitch の作成と管理」をご参照ください。
説明vSwitch は、ALB がサポートするアベイラビリティーゾーンにあり、クラスターと同じ VPC 内にある必要があります。詳細については、「ALB がサポートするリージョンとアベイラビリティーゾーン」をご参照ください。
リージョンが複数のアベイラビリティーゾーンを提供している場合、高可用性を確保するため、少なくとも 2 つの異なるゾーンから vSwitch を選択することを推奨します。
spec.listenersいいえ
リスナーのポートとプロトコル。この例では、ポート 80 で HTTP を使用します。
ALB Ingress にはリスナーが必要です。手動設定を避けるため、このデフォルト設定を維持してください。
作成を続ける をクリックします。作成完了 というメッセージが表示されます。
ALB インスタンスを確認します。
上部のナビゲーションバーで、インスタンスのリージョンを選択します。
インスタンス ページで、alb-test という名前の ALB インスタンスがインスタンスリストに表示されることを確認します。
kubectl
以下のコンテンツを alb-test.yaml という名前のファイルにコピーし、ALBConfig を作成します。
パラメータの詳細は次の表をご参照ください。
パラメータ
必須
説明
metadata.nameはい
ALBConfig の名前。
説明名前の競合を避けるため、ALBConfig の名前はクラスター内で一意である必要があります。
spec.config.nameいいえ
ALB インスタンスの名前。
spec.config.addressTypeいいえ
ALB インスタンスのネットワークタイプ。有効な値:
[Internet] (デフォルト):インスタンスはインターネット経由でパブリック負荷分散サービスを提供します。説明インターネット向け ALB インスタンスは Elastic IP Address (EIP) を使用します。EIP インスタンス、帯域幅、データ転送に料金が発生します。詳細については、「従量課金」をご参照ください。
[Intranet] :インスタンスは VPC 内でプライベート負荷分散サービスを提供します。
spec.config.zoneMappingsはい
ALB インスタンスの vSwitch の ID。vSwitch の作成方法については、「vSwitch の作成と管理」をご参照ください。
説明vSwitch は、ALB がサポートするアベイラビリティーゾーンにあり、クラスターと同じ VPC 内にある必要があります。詳細については、「ALB がサポートするリージョンとアベイラビリティーゾーン」をご参照ください。
リージョンが複数のアベイラビリティーゾーンを提供している場合、高可用性を確保するため、少なくとも 2 つの異なるゾーンから vSwitch を選択することを推奨します。
spec.listenersいいえ
リスナーのポートとプロトコル。この例では、ポート 80 で HTTP を使用します。
ALB Ingress にはリスナーが必要です。手動設定を避けるため、このデフォルト設定を維持してください。
次のコマンドを実行して、ALBConfig を作成します。
kubectl apply -f alb-test.yaml想定される出力:
albconfig.alibabacloud.com/alb-demo createdこの出力は、ALBConfig が作成されたことを示します。
ステップ 3:IngressClass の作成
AlbConfig ごとに 1 つの IngressClass を作成することを推奨します。
コンソール
ACS コンソール にログインします。左側のナビゲーションペインで、クラスター をクリックします。
クラスター ページで、管理するクラスターを見つけ、その ID をクリックします。クラスター詳細ページの左側のナビゲーションペインで、ワークロード > カスタムリソース を選択します。
CRD タブで、[YAML から作成] をクリックします。
[サンプルテンプレート]: Custom を選択します。
テンプレート: YAML マニフェストを入力します。
次の表でパラメーターを説明します。
パラメーター
必須
説明
metadata.nameはい
IngressClass の名前。
説明名前はクラスター内で一意である必要があります。
spec.parameters.nameはい
関連付けられた AlbConfig の名前。
作成を続ける をクリックします。 確認メッセージが表示されます。
IngressClass が作成されたことを確認します:
左側のナビゲーションウィンドウで、 を選択します。
リソースオブジェクト タブをクリックします。
[API グループ] 検索ボックスに
networking.k8s.ioと入力します。 作成された 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 コンソール にログインします。左側のナビゲーションペインで、クラスター をクリックします。
クラスター ページで、管理するクラスターを見つけ、その ID をクリックします。クラスター詳細ページの左側のナビゲーションペインで、ネットワーク > イングレス を選択します。
ルート ページで、Ingress の作成 をクリックします。 Ingress の作成 ダイアログボックスで、Ingress を設定します。
パラメーター
説明
値の例
[ゲートウェイタイプ]
ゲートウェイタイプを選択します。 ALB と MSE から選択します。
ALB Ingress
[名前]
Ingress のカスタム名です。
cafe-ingress
IngressClass
Ingress のカスタムクラスです。
alb
[ルール]
ルールの追加 をクリックして、複数のルーティングルールを追加します。
-
[ドメイン名]:カスタムドメイン名です。
-
[マッピング]:次のパラメーターを設定します。
-
[パス]:サービスにアクセスするための URL パスです。この例では、ルートパス / を使用するため、このパラメーターは空のままにします。
-
[ルール]:[Prefix (前方一致)]、[Exact (完全一致)]、および [ImplementationSpecific (デフォルト値)] をサポートしています。
-
[サービス]:Ingress がトラフィックを転送するバックエンドの Kubernetes Service です。
-
[ポート]:Service が公開するポートです。
-
-
Ingress では、同じドメイン名に複数のパスを設定できます。追加 をクリックして、新しいパスを追加します。
[ドメイン名]:demo.domain.ingress.top
[パスのマッピング]:
[パス]:/tea
[ルール]:ImplementationSpecific
[サービス]:tea-svc
[ポート]:80
[マッピング]:
[パス]:/coffee
[ルール]:ImplementationSpecific
[サービス]:coffee-svc
[ポート]:80
[TLS 設定]
このオプションを有効にすると、Ingress が TLS 証明書 (HTTPS) で保護されます。
[ドメイン名]:カスタムドメイン名を入力します。
[シークレット]:TLS 証明書を含む Secret を選択します。
Secret を作成するには、次の手順を実行します:
シークレット の右側にある 作成を続ける をクリックします。
Secret の作成 ダイアログボックスで、名前、[Cert]、および [Key] を設定し、OK をクリックします。
シークレット ドロップダウンリストから、作成した Secret を選択します。
追加 をクリックして、複数の TLS 設定を構成します。
詳細については、「暗号化通信のための HTTPS 証明書の設定」をご参照ください。
TLS 設定 は無効のままにします。 この設定は、この例では不要です。
[その他]
-
[カナリアリリース]:カナリアリリースを有効にします。リクエストヘッダー、クッキー、または重みに基づいてカナリア ルールを設定できます。
説明ルールはリクエストヘッダー、クッキー、または重みに基づいて設定できます。複数のルールタイプを設定した場合、リクエストヘッダー、クッキー、重みの順で照合されます。
-
[リクエストヘッダーに基づく]:リクエストヘッダーに基づいてトラフィックを分割します。この設定を行うと、
alb.ingress.kubernetes.io/canary-by-headerおよびalb.ingress.kubernetes.io/canary-by-header-valueアノテーションが追加されます。 -
[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 のアノテーションの詳細については、「Annotations」をご参照ください。
この例では不要です。
[ラベル]
Ingress に追加するラベルを指定します。ラベルは、識別属性を指定するためにオブジェクトに付与されるキーと値のペアです。
この例では不要です。
-
ingress の作成 ページ左下の OK をクリックします。
Ingress の確認:
左側のナビゲーションペインで、[Network] > [Ingresses] を選択します。 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はい
バックエンドサービスのポート番号。
このポートが Service の定義と一致していることを確認してください。
次のコマンドを実行して、
coffeeおよびteaサービスへのpathベースのルーティングを持つ 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 レコードを追加します。
クラスター名をクリックして、クラスター管理ページを開きます。
左側メニューで、[Network] > [Routes] を選択します。
cafe-ingress の エンドポイント 列で、DNS 名をコピーします。
CNAME レコードを追加するには、次の手順を実行します。
Alibaba Cloud DNS console にログインします。
[ドメイン名解決] ページで、ドメイン名の追加 をクリックします。
ドメイン名の追加 ダイアログボックスで、ドメイン名を入力し、OK をクリックします。
重要TXT レコードを使用してドメイン名を検証する必要があります。
対象のドメインで、Actions 列の 解決設定 をクリックします。
解決設定 ページで、Add Record をクリックします。
Add Record パネルで、CNAME レコードを次のように設定し、OK をクリックします。
パラメーター
説明
[レコードタイプ]
ドロップダウンリストから CNAME を選択します。
[ホストレコード]
wwwなど、ドメイン名のプレフィックスです。[DNS リクエストソース]
デフォルト値を選択します。
[レコード値]
[Endpoint] 列からコピーした DNS 名を入力します。
TTL
DNS レコードが DNS サーバーにキャッシュされる時間です。デフォルト値を使用します。
ステップ 6:トラフィック転送のテスト
ブラウザにテストドメインと URL パスを入力して、トラフィックルーティングを確認します。
カスタムドメインを設定した場合は、そのドメインを使用してください。
カスタムドメインを設定していない場合は、cafe-ingress エンドポイントの DNS 名を使用してください。
この例では、ドメインは demo.domain.ingress.top です。
ブラウザに
demo.domain.ingress.top/coffeeを入力します。ページには coffee-svc バックエンドサービスが表示され、サーバー名は coffee Pod 名、URI は/coffeeと表示されます。これは、リクエストが coffee バックエンドサービスに正しくルーティングされていることを意味します。ブラウザに
demo.domain.ingress.top/teaを入力します。ページには tea-svc バックエンドサービスが表示され、URI は/tea、サーバー名はtea-6で始まる名前と表示されます。これは、リクエストが tea バックエンドサービスに正しくルーティングされていることを意味します。
関連ドキュメント
ALB イングレスサービスの高度な使用法では、ヘルスチェック、HTTPS リダイレクト、カナリアリリース、カスタムリスナーポートについて説明しています。