このトピックは、cGPU Basic EditionがインストールされているContainer Service for Kubernetes (ACK) 専用クラスターを対象としています。 このトピックでは、ACK専用クラスターのcGPU Basic EditionをcGPU Professional Editionにアップグレードした後に、GPU共有およびスケジューリングエラーのトラブルシューティングを行う方法について説明します。
発行
ACK専用クラスターのcGPU Basic EditionをcGPU Professional Editionにアップグレードすると、kube-schedulerのack-cgpuに関連するエクステンダ設定が失われます。 その結果、クラスター内のGPUリソースを共有またはスケジュールすることはできません。
原因
システムがcGPU Basic EditionをcGPU Professional Editionにアップグレードすると、現在のkube-scheduler設定がデフォルト設定によって上書きされます。 これは、エクステンダ構成の損失を引き起こす。
解決策
この問題をトラブルシューティングするには、次の手順を実行します。
ステップ1: エクステンダの設定を確認する
リモートで各制御プレーンにログオンします。
チェック
scheduler-extender-config.jsonに存在します。/etc/kubernetes /マニフェスト /kube-scheduler.yaml次の図に示すように、各制御プレーンのファイルを指定します。
scheduler-extender-config.jsonが存在しない場合は、ステップ2に進みます。 scheduler-extender-config.jsonが存在する場合、エクステンダ構成は失われず、修復は必要ない。 この場合、DingTalkグループ30421250に参加してテクニカルサポートをリクエストします。
ステップ2: 修復プログラムを実行する
制御プレーンにリモートでログオンします。
次のコマンドを実行して、修復ツールをダウンロードします。
sudo wget http://aliacs-k8s-cn-beijing.oss-cn-beijing.aliyuncs.com/gpushare/extender-config-update-linux -O /usr/local/bin/extender-config-update次のコマンドを実行して、修復ツールを実行可能にします。
sudo chmod + x /usr/local/bin/extender-config-update次のコマンドを実行して修復ツールを起動します。
sudo extender-config-update次のコマンドを実行して、kube-schedulerのステータスを照会します。 kube-schedulerが再起動して実行中かどうかを確認します。
kubectl get po -n kube-system -l component=kube-scheduler次の出力では、AGE列に14秒が表示されます。 これは、kube-schedulerが再起動および修復されたことを示します。
の名前準備ができているステータスの履歴書 kube-scheduler-cn-beijing.192.168.8.37 1/1ランニング0 14s kube-scheduler-cn-beijing.192.168.8.38 1/1ランニング0 14s kube-scheduler-cn-beijing.192.168.8.39 1/1ランニング0 14skube-scheduler.yamlファイルのエクステンダ設定が復元されていることを確認するには、「ステップ1: エクステンダ設定の確認」を参照して。 次に、ステップ3に進みます。
ステップ3: 結果を確認する
制御プレーンにリモートでログオンします。
という名前のファイルを作成します。/tmp/cgpu-test.yaml検証のため。
次の内容を
/tmp/cgpu-test.yamlファイルに追加します。apiVersion: batch/v1 種類: 仕事 メタデータ: 名前: tensorflow-mnist spec: parallelism: 1 template: metadata: ラベル： アプリ: tensorflow-mnist 仕様： コンテナ： -名: tensorflow-mnist 画像: registry.cn-beijing.aliyuncs.com/ai-samples/gpushare-sample:tensorflow-1.5 command: -python -tensorflow-sample-code/tfjob/docker/mnist/main.py --- max_steps=100000 --- data_dir=tensorflow-sample-code/data resources: limits: aliyun.com/gpu-mem: 3# GPUメモリのリクエスト3 GiB。 workingDir: /root restartPolicy: 決して次のコマンドを実行してジョブを作成します。
kubectl create -f /tmp /cpu-test.yaml次のコマンドを実行して、ポッドが実行されているかどうかを確認します。
kubectl get po -l app=tensorflow-mnist期待される出力:
の名前準備ができているステータスの履歴書 tensorflow-mnist-5htxh 1/1ランニング0 4m3 2s次のコマンドを実行して、ポッドに割り当てられたGPUメモリの実際の量が/tmp/cgpu-test.yamlファイルを作成します。
kubectlログtensorflow-mnist-5htxh | grep "totalMemory"期待される出力:
totalMemory: 3.15GiBフリーメモリ: 2.85GiB次のコマンドを実行して、ポッドに割り当てられたGPUメモリの実際の量が/tmp/cgpu-test.yamlファイルを作成します。
kubectl exec -ti tensorflow-mnist-5htxh -- nvidia-smi次の出力は、ポッドに割り当てられたGPUメモリの実際の容量がMiB 3,226であることを示しています。 量は /tmp/cgpu-test.yamlファイルの設定と同じです。 GPUリソースを共有またはスケジュールできない場合、ポッドに割り当てられるGPUメモリの実際の量は、ホストが提供するGPUメモリの合計に等しくなります。
月4月13日11:52:25 2020 + ----------------------------------------------------------------------------- + | NVIDIA-SMI 418.87.01ドライバのバージョン: 418.87.01 CUDAバージョン: 10.1 | | ------------------------------- + ---------------------- + ---------------------- + | GPU名永続性-M | Bus-Id Disp.A | Volatile Uncorr. ECC | | Fan Temp Perf Pwr: 使用量 /キャップ | メモリ使用量 | GPU-Util Compute M. | |=============================== + ====================== + ======================| | 0 Tesla V100-SXM2... オン | 00000000:00:07.0オフ | 0 | | N/A 33C P0 56W / 300W | 629MiB / 3226MiB | 1% のデフォルト | + ------------------------------- + ---------------------- + ---------------------- + + ----------------------------------------------------------------------------- + | プロセス: GPUメモリ | | GPU PIDタイププロセス名使用法 | |=============================================================================| + ----------------------------------------------------------------------------- +