クラウドノード自動プロビジョニングガイド

異なるワークロードには、マシンタイプ、サイズ、地理的位置など、さまざまなハードウェア仕様が必要です。ML/LLMの台頭により、適切なハードウェアの選択が非常に重要になっています。OSタイプ、アーキテクチャ、プロセッサ、GPUタイプ、ストレージなどのハードウェア仕様に基づいて選択を行う必要があります。Kubernetesは、類似のワークロード間でリソースをオーケストレーションおよび分散するのに役立ちますが、これらのリソースをオンデマンドで動的にプロビジョニングすることは依然として課題です。

A Kubernetes （K8s）クラスターは、コンテナ化されたアプリケーションを効率的、自動的、分散的、かつスケーラブルに実行するノードのグループです。Kubernetesクラスター内の各ノードには、マシンタイプ、サイズ、場所などの特定の属性があります。

このブログでは、Kubernetesクラスター内で多様なワークロード要件を自動的に管理するためのクラウドノード自動プロビジョナーの必要性について探ります。また、AWS、GCP、Azureなどの主要なクラウドプロバイダーが提供するソリューションについても考察します。最後に、TrueFoundryがプラットフォームとしてこれらの課題にどのように対処しているかについて詳しく説明します。

はじめに

ノードの自動プロビジョニングは、未スケジュールのPodの制約に基づいて適切なノードグループのプロビジョニングを自動化し、インフラストラクチャコストを最適化します。Kubernetesクラスターにおけるノード自動プロビジョナーは、以下の役割を担います。

• スケジューリング：未スケジュールのPodに応じてノードを起動し、スケジューリングの制約を解決して最適なマシンタイプとサイズを決定すること。
• 停止：有効期限切れ、 統合、ドリフト、または中断により不要になったノードの削除。

ノード自動プロビジョニングの必要性

Kubernetesでは、ノードはマシンタイプ、サイズ、容量タイプなどの特定のハードウェア構成を持つワーカーマシンとして機能し、ノードプールとは、このような共通のワーカーマシンの集合を指します。ノード自動プロビジョナーがない場合、ワークロードに特定のハードウェア構成を割り当てる唯一の方法は、ノードプールを選択することでした。これには、ユーザーがクラウドに必要な構成のノードプールを作成し、その後ノード アフィニティ をPodの仕様に追加する必要がありました。

このメカニズムは、以下のステップで構成されます。

1. ハードウェア要件の事前定義。
2. 指定された要件に最適なマシンタイプとサイズを検索し、選択すること。
3. 選択されたノードプールのプロビジョニング。

ノードプールの要件の組み合わせは多数になる可能性があり、特にML/LLMワークロードの実験フェーズでは顕著です。開発中にDevOpsチームとプラットフォームチーム間の調整にかなりの時間を要する可能性があります。そのため、要件を動的に評価し、インフラストラクチャを自動的にプロビジョニングするコントローラーが不可欠となります。

ノードの自動プロビジョニングはどのように機能しますか？

ノードの自動プロビジョニングは、ユーザーが高レベルの要件を制約として追加できるようにすることで、ノードプールを事前に作成する手動のステップを排除します。これにより、ワークロードに最適なマシンタイプまたは利用可能なノードが自動的に決定されます。

一般的に使用される制約の一部：

• cpu: 必要なCPU 例： 2
• memory: ワークロードに必要なメモリ 例： 1000
• gpu-type: 必要なGPUタイプ 例： t4, a100
• capacity type: 購入オプション 例： オンデマンド または スポット
• ゾーン：地理的ロケーション 例： us-east-1a
• オペレーティングシステム：マシンのOS 例： Linux または Windows
• アーキテクチャ：マシンのアーキテクチャ 例： arm64 または amd64

ノードの自動プロビジョニングを提供するクラウドプロバイダー

各クラウドプロバイダーは独自の自動プロビジョニングメカニズムを提供しています。AWSではKarpenterのようなツールのインストールが必要ですが、GCPは組み込みソリューションを提供しています。Azureは最近、現在プレビューモードである自動プロビジョナープロジェクトを発表しました。

AWS Karpenter

Karpenter、Kubernetes向けに設計されたオープンソースのノードライフサイクル管理プロジェクトであり、クラスター上でワークロードを実行する際の効率とコスト効率を大幅に向上させます。リソース要求、ノードセレクター、アフィニティ、トレランス、トポロジースプレッド制約などのスケジューリング制約を考慮することで、Karpenterは必要に応じてノードをインテリジェントにプロビジョニングおよび割り当て解除します。

GCP ノード自動プロビジョニング

ノード自動プロビジョニング、クラスターオートスケーラーに統合されており、スケジュールできないPodの仕様に基づいて既存のノードプールをスケーリングします。GCPの自動プロビジョニング機能は、CPU、メモリ、エフェメラルストレージ、GPUリクエスト、ノードアフィニティ、ラベルセレクターを考慮することで、最適なリソース利用を保証します。

Azure ノード自動プロビジョニング

Azureの ノード自動プロビジョニング (NAP) プロジェクト、現在プレビューモードであり、オープンソースのKarpenterプロジェクトを活用し、ワークロードを効率的かつ費用対効果の高い方法で実行するための最適なVM構成を決定します。NAPはAKSクラスターにKarpenterを自動的にデプロイおよび管理し、ユーザーにシームレスなエクスペリエンスを提供します。

💡

AKS向けノード自動プロビジョニング (NAP) は現在プレビュー中です。この新しいプロジェクトに大変期待しており、お客様のために活用できることを楽しみにしています。 詳細はこちら

TrueFoundry - ノード自動プロビジョニングのような体験を

TrueFoundryは、ノードプール向けに高度なフィルタリング機能を提供し、ノード自動プロビジョニングのような体験をシミュレートします。

これを実現するために、私たちはいくつかの簡単な手順を踏みました。

• マシンタイプとキャパシティタイプのあらゆる組み合わせでノードプールをプログラム的に作成し、オートスケーリングを有効にしつつ、ゼロに最小化します。
• ノードプールをそのマシンタイプ、CPU、メモリ、GPUタイプ、および数にリンクさせます。
• 次に、要件に基づいてこれらのノードプールをフィルタリングし、エンドユーザーが適切なインフラストラクチャを簡単に選択できるようにします。

このアプローチにより、開発者やデータサイエンティストは、自身の要件を分析することで、ワークロードに最適なノードプールを選択できます。このシンプルな仕組みにより、まだ自動プロビジョナーの組み込みサポートがないクラウドに対しても、同様のエクスペリエンスを提供することが可能になります。

まとめ

インフラストラクチャの要件が進化し続けるにつれて、クラウドプロバイダーは、多様なワークロードに最適なインフラストラクチャを選択するプロセスを合理化することに注力しています。当社では、 トゥルーファウンドリー、私たちはこのコミットメントを共有し、開発者がワークロードをシームレスにデプロイできるよう、必要なツールと知識を身につけられるよう努めています。