Container Service for Kubernetes:ALB Ingress overview

始める前に

ALB Ingress の機能をよく理解するために、ALB Ingress を使用する前にこのトピックを読むことをお勧めします。

このトピックを読む前に、公式の Ingress ドキュメントを読み、Ingress および IngressClass に関連する用語を学習することをお勧めします。

ALB Ingress のしくみ

ALB Ingress に関連する用語:

• ALB Ingress コントローラー: Ingress リソースを管理するコンポーネント。 ALB Ingress コントローラーは、API サーバー を使用して Ingress および AlbConfig リソースの変更を動的に取得し、ALB インスタンスを更新します。 NGINX Ingress コントローラーとは異なり、ALB Ingress コントローラーは ALB インスタンスのコントロールプレーンです。 ALB インスタンスを管理しますが、トラフィックは分散しません。 トラフィックは ALB インスタンスによって分散されます。 ALB Ingress コントローラーは、クラスター内の API サーバー を使用して Ingress リソースの変更を動的に取得し、Ingress ルーティングルールに基づいて ALB インスタンスを更新します。

• AlbConfig: AlbConfig は、ALB Ingress コントローラーによって作成されたカスタムリソース定義 (CRD) です。 AlbConfig のパラメーターは、ALB インスタンスの構成を定義します。 各 AlbConfig は 1 つの ALB インスタンスに対応します。 ALB インスタンスは、バックエンドサービスにトラフィックを分散するためのイングレスとして機能します。 ALB インスタンスは、ALB によって完全にホストされています。 NGINX Ingress コントローラーと比較して、ALB Ingress は運用管理が不要で、非常に柔軟です。

• IngressClass: IngressClass は、Ingress と AlbConfig の間の関連付けを定義します。

• Ingress: Ingress は、外部トラフィックルーティングルールとアクセス制御ルールを定義するリソースオブジェクトです。 ALB Ingress コントローラーは、Ingress リソースの変更を監視し、ALB インスタンスを更新してトラフィックを分散します。

• サービス: Kubernetes では、ポッドは変化する一時的なリソースです。 サービスは、同じ機能を提供するポッドへの統合イングレスです。 他のアプリケーションまたはサービスは、ポッドの変更を気にすることなく、サービスの仮想 IP アドレスとポートを介してポッドと通信できます。 サービスの詳細については、「サービス管理」をご参照ください。

次の図は、ALB インスタンスと ALB Ingress の論理的な関係を示しています。

ALB Ingress の使用方法

「ALB Ingress を作成する」を参照して、前の図のワークフローを完了してください。

メリット

ALB Ingress は Alibaba Cloud によって完全に管理されており、非常に高い処理能力を提供します。 一方、NGINX Ingress は高度にカスタマイズ可能ですが、手動管理が必要です。 NGINX Ingress と ALB Ingress は、異なるサービス範囲、アーキテクチャ、処理能力、およびセキュリティ機能を提供します。 詳細については、「NGINX Ingress と ALB Ingress の比較」をご参照ください。

ALB Ingress は、次のシナリオで NGINX Ingress よりも優れています。

• 持続的接続

  持続的接続は、IoT、インターネット金融、オンラインゲームなど、頻繁なインタラクションが必要なシナリオに最適です。 構成が変更されると、NGINX Ingress はプロセスを再読み込みし、持続的接続を一時的に閉じます。 これにより、サービスが中断される可能性があります。 この問題を防ぐために、ALB Ingress はローリングアップデートを使用して持続的接続の安定性を確保します。

• 高同時実行性

  IoT サービスは、端末デバイスから開始される多数の同時接続を維持することが期待されています。 ALB Ingress は Alibaba Cloud のクラウドネットワーク管理プラットフォーム上で実行され、セッションを効率的に管理できます。 各 ALB インスタンスは数千万の接続をサポートします。 NGINX Ingress は、手動での運用管理が必要な限られた数のセッションのみをサポートします。 NGINX Ingress のスケールアウトはクラスター内のリソースを消費し、手動操作が必要です。 スケールアウトの費用は比較的高くなります。

• 高 QPS

  インターネットサービスは、プロモーション活動や重大なイベントなど、ほとんどのシナリオで高 QPS に耐えることが期待されています。 ALB Ingress は自動スケーリングをサポートしています。 QPS 値が増加すると、仮想 IP アドレスが自動的に追加されます。 各 ALB インスタンスは最大 100 万 QPS をサポートしているため、ALB Ingress は NGINX Ingress よりも低いネットワークレイテンシをサポートします。 また、NGINX Ingress はクラスター内のリソースに依存しており、高 QPS シナリオではパフォーマンスボトルネックが発生する可能性があります。

• 大きなワークロードの変動

  ALB は、e コマースやゲームサービスなど、ワークロードの変動が大きいサービスに最適な、より費用対効果の高い料金モデルを提供します。 ALB は従量課金制をサポートしています。 オフピーク時には、消費されるロードバランサー容量ユニット (LCU) が少なくなります。 また、ALB は自動スケーリングをサポートしています。 トラフィックフローをリアルタイムでチェックする必要はありません。 ただし、NGINX はオフピーク時にアイドル状態のリソースを自動的に解放しません。 ワークロードの変動に対応するために、クラスター内に一定量のリソースを手動で予約する必要があります。

• アクティブなゾーン冗長性とアクティブな地理的冗長性

  ソーシャルネットワーキングやストリーミングメディアサービスなど、高い業務継続性と信頼性を必要とする業界およびアプリケーションシナリオでは、Distributed Cloud Container Platform for Kubernetes (ACK One) を使用して ALB マルチクラスターゲートウェイ を作成し、ALB Ingress を使用してマルチクラスタートラフィックを管理 できます。 これらにより、アクティブなゾーン冗長性とアクティブな地理的冗長性を実装できます。

ALB Ingress をサポートするリージョンとゾーン

詳細については、「ALB が利用可能なリージョンとゾーン」をご参照ください。

ALB Ingress の制限

• 詳細については、「ALB クォータの計算方法」をご参照ください。

• Flannel を使用する場合、ALB Ingress は NodePort および LoadBalancer サービスへのリクエストの転送のみをサポートし、ClusterIP サービスはサポートしていません。

ALB Ingress コントローラー リリースノート

詳細については、「ALB Ingress コントローラー」をご参照ください。