ALB Ingress は、Alibaba Cloud の Application Load Balancer (ALB) サービスをベースにしています。クラスター内のサービスに統一されたエントリポイントを提供します。Nginx Ingress と比較して、ALB Ingress はフルマネージドサービスであり、メンテナンスを行う必要がありません。Kubernetes クラスター内の Ingress リソースの変更を自動的に検出し、事前定義されたルールに基づいてバックエンドサービスにトラフィックを分散します。さらに、ALB Ingress は堅牢な弾力的なスケーリングメカニズムを備えており、動的なトラフィックの変動に自動的に適応し、システムの安定した運用を保証します。
はじめに
ALB Ingress を使用する前に、このドキュメントを読むことで、ALB Ingress の特徴をより深く理解できます。
このドキュメントを読む前に、Kubernetes の公式ドキュメントである Ingress を参照して、Ingress と IngressClass の基本概念を理解することを推奨します。
ALB Ingress の仕組み
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： Kubernetes において、Pod は一時的で動的なリソースです。Service は、同じ機能を持つ Pod に対して、安定した統一されたエントリポイントを提供します。他のアプリケーションやサービスは、Service の仮想 IP アドレス (VIP) とポートにアクセスすることで、Pod の変更を追跡することなくバックエンドの Pod と通信できます。Service の詳細については、「サービス管理」をご参照ください。
ロードバランシングコンソールを介して手動で ALB インスタンスの設定を変更すると、ALB Ingress の自動同期メカニズムによって上書きされる可能性があります。これにより、設定が失われたり、インスタンスが利用できなくなったりする可能性があります。公式のガイダンスに従わずに、ACK によって管理されている ALB インスタンスの設定をロードバランシングコンソールから直接変更しないでください。
ALB インスタンスと ALB Ingress の論理的な関係を理解するために、次の図をご参照ください：
ALB Ingress の使用フロー
上記プロセスを完了するには、「ALB Ingress を作成してサービスを公開する」をご参照ください。
NGINX Ingress の代わりに ALB Ingress を使用するケース
ALB Ingress は Alibaba Cloud によって管理されます。各 ALB インスタンスは、最大 100 万 QPS、数千万の同時接続、自動スケーリング、および 99.995% のサービス可用性をサポートします。NGINX Ingress は自己管理型であり、手動でのスケーリングが必要です。詳細な比較については、「NGINX Ingress と ALB Ingress の比較」をご参照ください。
ALB Ingress は、以下のシナリオにより適しています：
持続的接続
IoT、インターネット金融、オンラインゲームなど、頻繁な対話を必要とするアプリケーションは、持続的接続に依存します。ALB Ingress は、持続的接続を中断することなく、ホットリロードを通じて設定変更を適用します。NGINX Ingress は、設定変更時にプロセスを再読み込みする必要があり、これにより持続的接続が一時的に切断されます。
高い同時接続性
IoT サービスは、端末デバイスから多数の同時接続を維持します。ALB Ingress はクラウドネットワーク管理プラットフォーム上で実行され、大規模なセッションを管理します。各 ALB インスタンスは、数千万の接続をサポートします。
高い QPS
プロモーション活動や速報イベントでは、高い QPS 容量が求められます。ALB Ingress は自動スケーリングをサポートし、QPS の増加に応じて仮想 IP アドレスを自動的に追加します。各 ALB インスタンスは、最大 100 万 QPS をサポートします。
ワークロードの変動
E コマースやゲームサービスでは、大きなワークロードの変動が発生します。ALB は従量課金の課金方法をサポートし、ロードバランサーキャパシティーユニット (LCU) を使用します。オフピーク時には消費される LCU が少なくなり、手動でのリソース予約なしで ALB が自動的にスケーリングします。
ゾーン冗長性と地理的冗長性
ソーシャルネットワーキングやストリーミングメディアなど、高可用性を必要とするアプリケーションでは、Distributed Cloud Container Platform for Kubernetes (ACK One) を使用して ALB マルチクラスターゲートウェイを作成し、「ALB Ingress を使用したマルチクラスターのトラフィック管理」を行うことで、アクティブ地理的冗長性とアクティブなゾーン冗長性を実装します。
ALB Ingress のリージョンとゾーン
ALB Ingress がサポートするリージョンとゾーンについては、「ALB がサポートするリージョンとゾーン」をご参照ください。
大規模クラスターにおける ALB Ingress の推奨事項
ALB Ingress は、Alibaba Cloud OpenAPI を通じて設定変更を駆動します。大規模なクラスター、多数の ALB インスタンス、および多数の Ingress ルールが存在するシナリオでは、バッチ操作 (Ingress の一括作成または削除、大規模な Pod のローリングアップグレード、頻繁なエンドポイントの更新など) を実行する際に、転送ルールの更新やバックエンドサーバーグループの同期などの操作に遅延が発生する可能性があります。設定の有効化時間は ALB OpenAPI の応答時間に依存します。設定可能なリソースの数は、ALB のクォータ制限に従います。
ビジネスニーズで大規模な変更が必要な場合は、事前に容量評価とストレステストを完了させる必要があります。処理遅延やクォータ超過によるサービス中断やアクセス異常を避けるために、変更のペースを計画してください。
ALB Ingress の制限事項
ALB Ingress のクォータ制限については、「ALB のクォータ計算方法」をご参照ください。
ALB Ingress Controller の変更履歴
ALB Ingress の機能変更履歴については、「ALB Ingress Controller」をご参照ください。