AMD GPUプラグイン

アドオン・コンテナがリクエストするリソース数量を指定し、アドオン・コンテナが超過できないリソース使用量制限を設定できます。

プレーン・テキストまたはBase64エンコードされたJSON形式。

100ミリコアのCPUと100メガバイトのメモリーをリクエストするアドオン・コンテナを作成します。アドオンコンテナを500ミリコアのCPUと200メビバイトのメモリーに制限します。

プラグインがデバイス・ヘルス・ステータスでkubeletを更新する時間間隔(秒)。

ヘルス・チェックを無効にするには、0に設定します。

AMD GPUプラグイン・コンテナのCPUおよびメモリー・リクエストおよび制限を定義します。

プラグインは、すべてのGPUノードで実行されます。

合計リソース使用率は、GPUノードの数と直線的に増加します。

次のアクティビティが増加します。

• GPUヘルス・モニタリング
• kubeletへのデバイス状態レポート
• コンテナ・ランタイムとの相互作用

リソースのサイズが小さい場合:

• プラグインがノード上で不安定になる可能性があります。
• GPUが amd.com/gpu リソースとして正しく公開されない場合があります。
• GPUをリクエストしているポッドは、 Pending 状態のままになる場合があります。
• リソースがスケジューラに誤って報告される場合があります。

次の要因に基づいて、各ノードに割り当てられるメモリーおよびCPUを増やします。

• ノード上のGPUの数
• ワークロードの強度

kubeletログ、およびプラグインのCPUとメモリーの使用状況を監視します。

ラベルを使用して、プラグインが実行されるノードを制御します。

プラグインがAMD GPUノードでのみ実行されるようにします。

CPUのみのノードで不要なスケジューリングを防止します。

セレクタが指定されていない場合、プラグインはすべてのノードで実行され、リソースを浪費します。

間違ったセレクタが指定されている場合、プラグインはGPUノードで実行されず、GPUはKubernetesに表示されません。

ノードの1~2%に影響する構成ミスが少ない場合でも、構成が正しくないノードが何百個も存在し、GPUの可用性に一貫性がなくなり、スケジュールの失敗が予測できません。

厳密なノードラベル付けを使用します。

汚染されたGPUノードでプラグインを実行できるかどうかを制御します。

正しく構成されていない場合、AMD GPU Plugin DaemonSetがtaintsを使用してGPUノードでスケジュールに失敗し、GPUリソースが検出されず、GPUがワークロードのスケジューリングに使用できなくなります。

許容値が正しく構成されていない場合、プラグインはGPUノードで実行できず、GPUは使用できなくなります。

許容範囲がGPUノードに適用されるテイントと一致していることを確認します。

プラグインがGPUヘルス情報をkubeletに報告する頻度を制御します。

レポート頻度が高いほど、GPUのヘルス可視性は向上しますが、kubeletおよびAPIトラフィックは増加します。

レポート頻度が低いほど、オーバーヘッドは減少しますが、障害検出は遅延します。

更新の頻度が高すぎる場合、各ノードのCPUオーバーヘッドおよびkubeletの負荷が増加します。

更新の頻度が低すぎたり無効になったりすると、GPUの健全性情報が古くなり、スケジューラはワークロードを異常なGPUに割り当てる可能性があります。

健全性の可視性とオーバーヘッドのバランスをとる中程度の間隔を使用します。

過度に攻撃的な投票は避けましょう。

更新動作を制御します。

大規模なクラスタでは、多数のノードが同時に更新され、アップグレード中のGPUの可用性に影響する場合があります。

• GPUワークロードが中断される場合があります。
• GPUが一時的に使用できなくなる可能性があります。

制御されたローリング更新を使用して、広範囲にわたる中断を回避します。

この引数は、AMD GPUプラグインでは使用されません。