Kubernetes での AI と機械学習のワークロードの最適化

Kubernetes は、サービスからジョブ、ステートフル アプリケーションまで、あらゆる種類のコンテナ化されたワークロードに最適です。しかし、GPU を必要とする AI や機械学習のワークロードはどうでしょうか?はい、Kubernetes もそれらをサポートしていますが、微妙な違いがたくさんあります。

著者 Eugene Burd の「Kubernetes での AI および機械学習ワークロードの最適化」からの翻訳です。

この記事では、スケジューリング、オーバーサブスクリプションとタイムシェアリング、セキュリティ/分離など、Kubernetes が GPU をサポートする方法について説明します。さらに、3 つの主要なパブリック クラウド プロバイダーがこれらの機能をどのようにサポートしているか、また GPU ノードが GPU ワークロードでのみ使用されるようにする方法についても説明します。

デバイスプラグイン

まず、Kubernetes が GPU をサポートするメカニズムを見てみましょう。 Kubernetes 自体は GPU について何も知りません。代わりに、デバイス プラグインと呼ばれる拡張メカニズムを提供します。デバイス プラグイン フレームワークを使用すると、サードパーティは GPU、InfiniBand アダプターなど、ノードで利用可能な追加機能をアドバタイズできます。

デバイス プラグインは通常デーモンとして実装され、ノードの kubelet に自身を登録し、ノード上でスケジュール可能なリソースを kubelet にアドバタイズします。 Kubelet はこの情報を API サーバーに渡し、Kubernetes スケジューラはこの情報を使用して、各コンテナのリソースを要求するワークロードをノードにスケジュールします。

写真

ワークロードからGPUを要求する

Kubernetes が GPU を認識する仕組みがわかったので、コンテナが GPU を要求する仕組みについて説明しましょう。ワークロードは、CPU やメモリを要求するのと同様の方法で GPU を要求できますが、いくつかの違いがあります。 Kubernetes がネイティブにサポートする CPU とは異なり、GPU (および一般的なデバイス プラグイン) は制限のみをサポートします (リクエストを提供することはできますが、その場合は制限も提供する必要があり、2 つの値は等しくなければなりません)。制限も整数である必要があります (小数制限は許可されません)。

ポッドの例を見てみましょう。この場合、ポッドは 1 つの Nvidia GPU を要求しています。スケジューラは、まだ割り当てられていない利用可能な Nvidia GPU を持つノードを見つけ、そのノードにポッドを配置します。

 apiVersion: v1 kind: Pod metadata: name: my-gpu-pod spec: containers: - name: my-gpu-container image: nvidia/cuda:11.0.3-runtime-ubuntu20.04 command: ["/bin/bash", "-c", "--"] args: ["while true; do sleep 600; done;"] resources: requests: cpu: 100m memory: 500Mi limits: memory: 1000Mi nvidia.com/gpu: 1

オーバーサブスクリプションとタイムシェアリング

CPU タイムシェアリングは、linuxcgroups を使用して CNI によってネイティブに処理されます。これはリクエストと制限によって影響を受けます。CPU リクエストと制限を設定する方法 (および制限を回避する必要がある理由) に関する記事を参照してください。

GPU タイムシェアリングは、次の 2 つのメカニズムを通じて Nvidia GPU でサポートされています。

1. マルチインスタンス GPU (Nvidia A100、H100) は、複数のコンピューティング ユニットとメモリ ユニットをサポートします。この場合、公開するパーティションの数を設定できます。この構成により、デバイス プラグインは物理 GPU ごとに複数の「仮想 GPU」を表示します。これは、AWS、Azure、GCP でサポートされています。
2. シングルインスタンス GPU の場合、Nvidia の GPU スケジューラは、GPU 上のワークロードを時間スライスすることでタイムシェアリングをサポートします。これは AWS と GCP でのみサポートされます。

このアプローチでは GPU をオーバーサブスクライブできる可能性がありますが、CPU とは異なり、Completely Fair Scheduler (CFS) や cgroup の優先順位がないため、ワークロード間で時間を均等に分割することしかできず、ワークロードが不足する可能性があるため注意が必要です。

セキュリティ/隔離

CPU とは異なり、現在 GPU 内にはプロセスやメモリの分離はありません。つまり、GPU にスケジュールされたすべてのワークロードはメモリを共有するため、相互に信頼するワークロード間でのみ GPU を共有する必要があります。

GPUノードの作成

GPU をリクエストする方法がわかったので、GPU を備えたノードを作成する方法とデバイス プラグインをインストールする方法が気になるかもしれません。これは、使用する Kubernetes プロバイダーによって異なります。以下では、3 つの主要なものについて説明します。

アマゾン

AWS は、任意の EC2 GPU インスタンスタイプを使用したノードグループの作成をサポートしています。次の 2 つのオプションから選択できます。

1. Nvidia ドライバーがプリインストールされた EKS 高速化 Amazon Linux AMI を実行します。この場合、Nvidia デバイス プラグインを別途インストールする必要があります。
2. ノード グループで Nvidia の GPU Operator を実行します。この場合、アップグレードは手動で行われます。

アズール

Azure は、ノード プールを作成するための 3 つのオプションをサポートしています。

1. GPU ノード プールを作成します。これには GPU ドライバーが自動的に含まれますが、Nvidia デバイス プラグインを自分でインストールする必要があります。
2. GPU ドライバーと Nvidia デバイス プラグインを含む AKS GPU イメージ プレビューを使用します。この場合、アップグレードは手動で行われます。
3. ノード グループで Nvidia の GPU Operator を実行すると、すべてが処理されます。

グーグル

GKE は、ノード プールを作成するための 2 つのオプションをサポートしています。

1. GPU ドライバーのインストールとデバイス プラグインを Google が管理できるようにします。このオプションを使用すると、GKE はノードを自動的にアップグレードすることもできます。
2. GPUドライバーとデバイスプラグインを自分で管理する

GPU ノードを非 GPU ワークロードから保護する

最後に、GPU ノードを作成したので、クラスターで実行されている非 GPU ワークロードからこれらのノードを分離する必要があります。これは、汚染と寛容を通じて実現できます。ノード プールとグループを作成するときに、テイントを適用する必要があります。クラスターに非 GPU ノードプールがある場合、GKE はこれを自動的に実行します。他のプロバイダーはそうしませんので、必ずこれを実行する必要があります。

ポッドの場合、テイントを GPU ノードにスケジュールできるように、テイントに対する許容を提供する必要があります。次の例では、「nvidia.com/gpu」という名前のテイントの許容値を作成し、このポッドを nvidia GPU ノードで実行できるようにします。

 apiVersion: v1 kind: Pod metadata: name: my-gpu-pod spec: containers: - name: my-gpu-container image: nvidia/cuda:11.0.3-runtime-ubuntu20.04 command: ["/bin/bash", "-c", "--"] args: ["while true; do sleep 600; done;"] resources: requests: cpu: 100m memory: 500Mi limits: memory: 1000Mi nvidia.com/gpu: 1 tolerations: - key: "nvidia.com/gpu" operator: "Exists" effect: "NoSchedule"

AI と機械学習のワークロードが拡大し続ける中、より高価なクラウド プロバイダー独自のオプションではなく、Kubernetes での実行を検討していただければ幸いです。

Kubernetes で GPU ワークロードを実行してみたことはありますか?何がうまくいきましたか?どのような問題に遭遇しましたか?