Amazon Web Services ブログ

AWS Load Balancer Controller を利用した TargetGroupBinding のパターン

クラスターから直接ロードバランサーをプロビジョニングすることは、サービスを公開するための Kubernetes ネイティブの方法でしたが、場合によってはアプリケーションのアーキテクチャと合わないプロビジョニングプロセスになることがあります。そのため、別のメカニズムが必要とされます。この投稿で説明するユースケースでは、新しいロードバランサーをプロビジョニングせず、既存の Application Load Balancer (ALB)/Network Load Balancer (NLB) のトラフィックを直接 service にルーティングする機能を提供します。TargetGroupBinding と呼ばれるこの機能は、カスタムリソース (CR) で、既存の ALB TargetGroup または NLB TargetGroup を使用して pod を公開できます。AWS Load Balancer Controller は、ingress および service リソースのサポート機能としても内部的に TargetGroupBinding を使用しています。TargetGroupBinding を使用すると、ユーザーはロードバランサーの作成と削除を service と ingress のライフサイクルから切り離すことができます。その結果、ユーザーは AWS インフラストラクチャのロードバランサーをネイティブの Kubernetes リソースから抽象化し、分離することができます。

図1 – TargetGroupBindingを使ってロードバランサーからEKSワークロードに接続

TargetGroupBinding は、インスタンスまたは IP のターゲットタイプのターゲットグループをサポートしています。ターゲットタイプが明示的に指定されていない場合、mutating webhook が自動的にターゲットグループのターゲットタイプを検出して正しい値に設定します。

明示的にロードバランサーのインフラストラクチャをプロビジョニングおよび管理するユースケースでは、Kubernetes ingress との分離が必要です。そして、TargetGroupBinding を使用すると、それぞれの service へのトラフィックをルーティングするための完全にダイナミックなソリューションを実現できます。

TargetGroupBinding パターン

この記事では、Kubernetes ネイティブリソースでロードバランサーのライフサイクルを管理することが理想的でない使用例とアーキテクチャパターンを探ります。そのような場合、Kubernetes ネイティブリソース外でロードバランサーインフラストラクチャを管理する必要があり、TargetGroupBinding を使用して構成を動的に保つことができます。ハンズオンガイドについては、このコンテナ記事を参照してください。この記事では、AWS Load Balancer Controller における TargetGroupBinding と ingress リソース共有について詳しく説明しています。

グローバルトラフィックの分散

Kubernetes ワークロードに対するグローバルロードバランシングソリューションを探しているユーザーは、AWS Global Accelerator と統合したロードバランサーの管理方法を必要としています。AWS Global Accelerator は、グローバルユーザーに提供するアプリケーションの可用性とパフォーマンスを向上させるネットワークサービスです。

次に、ユーザーは AWS Global Accelerator とロードバランサーを Kubernetes リソースプロビジョニングサイクルの外で作成および管理する必要があり、Kubernetes ワークロードにトラフィックをルーティングする方法が必要です。完全にダイナミックなソリューションを実現するには、TargetGroupBinding を使用すると、外部で管理される AWS Global Acceleratorとロードバランサーを Kubernetes service に連携させることができます。ユーザーは、選択したInfrastructure-as-Code (IaC) ツールで AWS Global Accelerator、ロードバランサー、Amazon Elastic Kubernetes Service (Amazon EKS) インフラストラクチャをプロビジョニングし、TargetGroupBinding を使用してロードバランサーのターゲットグループを Amazon EKS に動的に関連付けることができます。

図 2 – AWS Global Accelerator と TargetGroupBinding を使用した Load Balancer を経由して EKS ワークロードへ

Amazon EKS と AWS Global Accelerator を使用してマルチリージョンのグローバルアプリケーションを運用する詳細については、こちらの投稿を参照してください。完全にダイナミックなソリューションを実現するには、TargetGroupBinding を使用できます。

L4 および L7 リクエストの単一エンドポイント

ユーザーは、このネットワーキングとコンテンツ配信の投稿で説明されているように、ALB の前に NLB を設定する必要がさまざまな理由で生じる場合があります。このような設定では、アプリケーションが L4 と L7 の両方で単一のエンドポイントを共有する必要がある場合や、アプリケーションの静的 IP アドレスを公開する場合や、ALB 用のエンドポイントを提供する必要がある場合があります。つまり、Kubernetes service の管理ライフサイクル (NLB から ALB へのルーティングの構成など) に関係なく、NLB と ALB の両方がプロビジョニングされ、構成されていることを確認する必要があります。この場合、TargetGroupBinding は、静的または事前定義された負荷分散構成を持つための機能を提供し、pod をターゲットとして動的に登録できるようになります。

図 3 – TargetGroupBinding を使用した EKS ワークロードへのレイヤー 7 とレイヤー 4 のトラフィックルーティング

クラスターの blue/green アップグレード

多くの場合、ローリングアップデートを使用して EKS クラスターを直接アップグレードできます。ただし、ダウンタイムを減らし、前の状態に素早くロールバックできるようにするために、ユーザーは blue/green のアップグレードを好む場合があります。ユーザーは、新しい EKS クラスターを作成し、新旧クラスターで同一のロードバランサーを利用することで、blue/green のアップグレード戦略を実現できます。ユーザーは、各 EKS クラスター用に 1 つずつターゲットグループを作成したロードバランサーを使用できます。次に、TargetGroupBinding CRD を使用すると、Amazon EKS を作成されたターゲットグループに動的に関連付けることができます。ロードバランサーのルール内で、各ターゲットグループに送信するリクエストの重みを設定して、クラスター間のリクエストの移行を制御します。このソリューションの利点は、ユーザーがドメインネームサーバー (DNS)、存続可能時間 (TTL)、またはクライアントマシン上のキャッシュに依存しないことです。

図 4 – TargetGroupBinding を用いた EKS ワークロードへの blue/green トラフィックルーティング

ハイブリッドデプロイ

blue/green デプロイメントの場合と同様に、Amazon EKS ベースのアプリケーションと Amazon EKS ベースでないアプリケーション (Amazon Elastic Compute Cloud (Amazon EC2) ベースのアプリケーションや AWS 外のアプリケーション) を並行して実行する必要がある場合、このパターンが役立ちます。TargetGroupBinding を使用すると、同じロードバランサーを使って並列の EKS クラスターにユーザートラフィックをルーティングできます。このパターンでは、TargetGroupBinding ユーザーは新しいターゲットグループを追加することで、同一のロードバランサーを使って新しい Amazon EKS ワークロードにトラフィックをルーティングできます。CR は、作成されたターゲットグループに service を動的にバインドする処理を行います。

図 5 – TargetGroupBinding を使用したハイブリッド (EKS と非 EKS) ワークロードへのトラフィックルーティング

この同じ戦略は、コンテナ化されていない環境、オンプレミス環境、または他のコンテナプラットフォームから Amazon EKS へのワークロードトラフィックの移行を計画する際にも適用できます。

まとめ

この投稿では、ALB と Kubernetes service のライフサイクルを分離することが最適な一般的なユースケースについて説明しました。これにより、AWS Load Balancer Controller で TargetGroupBinding 機能を使用するタイミングを選択できます。アプリケーションに最適なアーキテクチャを設計することをお勧めします。Kubernetes service/ingress 構成のライフサイクルに合わせて「無理に」設計する必要はありません。ただし、アプリケーションのルーティング構成を実装する場合は、すべての構成にメリットとデメリットがあることに注意してください。TargetGroupBinding を使用すると、Kubernetes 外で作成される ALB/NLB に Kubernetes service をバインドする明示的な手段の恩恵を受けられる一方で、Kubernetes インストールに付属していないカスタム CRD 実装 (ローカル開発クラスターなど) を使用する必要があります。ALB と TargetGroupBinding のすべての潜在的な構成の詳細については、ドキュメントを参照してください。

翻訳はソリューションアーキテクト祖父江が担当しました。原文はこちらです。