在過去的幾年里， NVIDIA 以各種方式利用 GPU 容器來測試、開發和大規模運行生產中的 AI 工作負載。為 NVIDIA GPUs 優化的容器和 DGX 和 OEM NGC Ready 服務器等系統可作為 NGC 的一部分提供。

但是用 GPUs 可靠地提供服務器并擴展人工智能應用程序可能會很棘手。 Kubernetes 憑借其豐富的應用程序可擴展性和高性能特性迅速構建在其平臺上。

Kubernetes 通過設備插件 框架 提供對特殊硬件資源的訪問，如 NVIDIA GPUs 、 NICs 、 Infiniband 適配器和其他設備。但是，使用這些硬件資源配置和管理節點需要配置多個軟件組件，例如驅動程序、容器運行時或其他庫，這些組件很難并且容易出錯。

Kubernetes 中的 運營商框架 采用操作業務邏輯，并允許使用標準的 Kubernetes API 和 kubectl 創建用于在 Kubernetes 內部署應用程序的自動化框架。這里介紹的 NVIDIA GPU 操作程序基于操作員框架，并自動管理所有 NVIDIA 軟件在 Kubernetes 中提供 GPUs 所需的組件。 NVIDIA 、 redhat 和社區中的其他人合作創建了 GPU 操作符。 GPU 運營商是 NVIDIA EGX 軟件定義平臺的一個重要組成部分，該平臺旨在使大規模混合云和邊緣操作成為可能和高效。

NVIDIA GPU 操作員

要在 Kubernetes 集群中配置 GPU 個工作節點，需要以下 NVIDIA 軟件組件 – 驅動程序、容器運行時、設備插件和監控。如圖 1 所示，這些組件需要在集群可用的 GPU 資源之前手動配置，并且在集群運行期間也需要進行管理。 GPU 運營商通過將所有組件打包并使用標準 Kubernetes api 自動化和管理這些組件（包括版本控制和升級），簡化了組件的初始部署和管理。 GPU 操作符是完全開源的，可以在我們的 GitHub 庫 上使用。

圖 1 手動安裝（某些組件需要安裝在裸金屬上）與 GPU 操作員使用全集裝箱化組件進行自動化的對比

操作員狀態機

GPU 運算符基于 Kubernetes 中的 運營商框架 。操作符被構建為一個新的自定義資源定義（ CRD ） API ，并帶有相應的控制器。該操作符在自己的命名空間（稱為“ GPU -operator ”）中運行，底層的 NVIDIA 組件在單獨的命名空間中編排（稱為“ GPU -operator resources ”）。與 Kubernetes 中的任何標準操作符一樣，控制器監視名稱空間的更改，并使用協調循環（通過 reconcile （）函數）來實現一個簡單的狀態機來啟動每個 NVIDIA 組件。狀態機在每個狀態下都包含一個驗證步驟，如果失敗，協調循環將退出并返回錯誤。如圖 2 所示。

圖 2 GPU 操作員狀態機

GPU 運算符應該在配備了 GPUs 的節點上運行。為了確定哪些節點具有 GPUs ，操作符依賴于 Kubernetes 中的 節點功能發現 （ NFD ）。 NFD worker 檢測節點上的各種硬件功能–例如， PCIe 設備標識、內核版本、內存和其他屬性。然后它使用節點標簽向 Kubernetes 發布這些特性。然后， GPU 操作員使用這些節點標簽（通過檢查 PCIe 設備 id ）來確定是否應在節點上配置 NVIDIA 軟件組件。在這個初始版本中， GPU 操作員當前部署了 NVIDIA 容器運行時 、 NVIDIA 集裝箱驅動程序 和 NVIDIA 調速器設備插件 。未來，運營商還將管理其他組件，如 基于 DCGM 監控。

讓我們簡單地看一下不同的狀態。

狀態容器工具包

此狀態將部署一個守護進程，該守護進程通過 容器 在主機系統上安裝 NVIDIA 容器運行時。守護進程使用 NFD 標簽中的 PCIe 設備 id ，僅在具有 GPU 資源的節點上安裝運行時。 PCIe 設備 id 0x10DE 是 NVIDIA 的供應商 id 。

nodeSelector： feature.node.kubernetes.io/pci-10de.present： “true”

狀態驅動程序

此狀態將部署一個帶有容器化的 NVIDIA 驅動程序的守護進程。您可以閱讀有關驅動程序容器 在這里 的更多信息。在啟動時，驅動程序容器可以構建最終的 NVIDIA 內核模塊，并將它們加載到主機上的 Linux 內核中，以準備運行 CUDA 應用程序并在后臺運行。驅動程序容器包括應用程序所需的驅動程序的用戶模式組件。同樣，守護進程使用 NFD 標簽來選擇要在其上部署驅動程序容器的節點。

狀態驅動程序驗證

如上所述，操作員狀態機包括驗證步驟，以確保組件已成功啟動。操作員調度一個簡單的 CUDA 工作負載（在本例中是一個 vectorAdd 示例）。如果應用程序運行時沒有任何錯誤，則容器狀態為“成功”。

狀態設備插件

此狀態為 NVIDIA Kubernetes 設備插件部署守護進程。它將節點上的 GPUs 列表注冊到 kubelet 中，這樣就可以將 GPUs 分配給 CUDA 個工作負載。

狀態設備插件驗證

在這種狀態下，驗證容器請求 Kubernetes 分配 GPU ，并運行一個簡單的 CUDA 工作負載（如上所述），以檢查設備插件是否注冊了資源列表以及工作負載是否成功運行（即容器狀態為“ Success ”）。

為了簡化 GPU 操作員本身的部署， NVIDIA 提供了一個舵圖。用戶可以使用驅動程序自定義的插件版本（值。 yaml ）在舵圖上。然后，操作員使用模板值在節點上提供所需的軟件版本。這為用戶提供了一個參數化級別。

運行 GPU 運算符

讓我們快速了解一下如何部署 GPU 操作符并運行 CUDA 工作負載。在這一點上，我們假設您有一個 Kubernetes 集群在運行（即主控制平面可用，工作節點已經加入集群）。為了讓這篇博文更簡單，我們將使用一個運行 ubuntu18.04 。 3lts 的 NVIDIA Tesla T4GPU 的單節點 Kubernetes 集群。

GPU 操作符本身并沒有解決 Kubernetes 集群的設置問題，目前有很多解決方案 可獲得的 可以用于此目的。 NVIDIA 正在與不同的合作伙伴合作，將 GPU 運營商整合到他們管理 GPUs 的解決方案中。

讓我們驗證一下我們的 Kubernetes 集群（以及帶有 Tiller 的 Helm 設置）是否可以運行。請注意，雖然節點有一個 GPU ，但節點上沒有部署 NVIDIA 軟件組件–我們將使用 GPU 操作符來配置組件。

$ sudo kubectl get pods --all-namespaces NAMESPACE NAME READY STATUS RESTARTS AGE
kube-system calico-kube-controllers-6fcc7d5fd6-n2dnt 1/1 Running 0 6m45s
kube-system calico-node-77hjv 1/1 Running 0 6m45s
kube-system coredns-5c98db65d4-cg6st 1/1 Running 0 7m10s
kube-system coredns-5c98db65d4-kfl6v 1/1 Running 0 7m10s
kube-system etcd-ip-172-31-5-174 1/1 Running 0 6m5s
kube-system kube-apiserver-ip-172-31-5-174 1/1 Running 0 6m11s
kube-system kube-controller-manager-ip-172-31-5-174 1/1 Running 0 6m26s
kube-system kube-proxy-mbnsg 1/1 Running 0 7m10s
kube-system kube-scheduler-ip-172-31-5-174 1/1 Running 0 6m18s
kube-system tiller-deploy-8557598fbc-hrrhd 1/1 Running 0 21s

一個單節點 Kubernetes 集群（主節點未被污染，因此可以運行工作負載）

$ kubectl get nodes
NAME STATUS ROLES AGE VERSION
ip-172-31-5-174 Ready master 3m2s v1.15.3

我們可以看到節點有一個 NVIDIA GPU ，但沒有安裝驅動程序或其他軟件工具。

$ lspci | grep -i nvidia
00:1e.0 3D controller: NVIDIA Corporation Device 1eb8 (rev a1) $ nvidia-smi
nvidia-smi: command not found

作為先決條件，讓我們確保在系統上設置了一些內核模塊。這些模塊的 NVIDIA 依賴于某些驅動程序。

$ sudo modprobe -a i2c_core ipmi_msghandler

現在，讓我們繼續部署 GPU 操作符。為此，我們將使用 NGC 提供的舵面圖。首先，添加 Helm 回購：

$ helm repo add nvidia https://helm.ngc.nvidia.com/nvidia
"nvidia" has been added to your repositories $ helm repo update
Hang tight while we grab the latest from your chart repositories...
...Skip local chart repository
...Successfully got an update from the "nvidia" chart repository
...Successfully got an update from the "stable" chart repository
Update Complete.

然后用圖表部署操作員

$ helm install --devel nvidia/gpu-operator -n test-operator --wait
$ kubectl apply -f https://raw.githubusercontent.com/NVIDIA/gpu-operator/master/manifests/cr/sro_cr_sched_none.yaml
specialresource.sro.openshift.io/gpu created

我們可以驗證 GPU 操作符是否在它自己的命名空間中運行，并且正在監視另一個命名空間中的組件。

$ kubectl get pods -n gpu-operator
NAME READY STATUS RESTARTS AGE
special-resource-operator-7654cd5d88-w5jbf 1/1 Running 0 98s

幾分鐘后， GPU 操作員將部署所有 NVIDIA 軟件組件。輸出還顯示了作為 GPU 操作符狀態機一部分運行的驗證容器。示例 CUDA 容器（ vectorAdd ）已作為狀態機的一部分成功完成。

$ kubectl get pods -n gpu-operator-resources
NAME READY STATUS RESTARTS AGE
nvidia-container-toolkit-daemonset-wwzfn 1/1 Running 0 3m36s
nvidia-device-plugin-daemonset-pwfq7 1/1 Running 0 101s
nvidia-device-plugin-validation 0/1 Completed 0 92s
nvidia-driver-daemonset-skpn7 1/1 Running 0 3m27s
nvidia-driver-validation 0/1 Completed 0 3m $ kubectl -n gpu-operator-resources logs -f nvidia-device-plugin-validation
[Vector addition of 50000 elements]
Copy input data from the host memory to the CUDA device
CUDA kernel launch with 196 blocks of 256 threads
Copy output data from the CUDA device to the host memory
Test PASSED
Done

我們還可以看到 NFD 用不同的屬性標記了節點。已為 NVIDIA GPU 設置了具有 PCIe 設備 id 0x10DE 的節點標簽。

$ kubectl -n node-feature-discovery logs -f nfd-worker-zsjsp
2019/10/21 00:46:25 cpu-cpuid.AVX512F = true
2019/10/21 00:46:25 cpu-hardware_multithreading = true
2019/10/21 00:46:25 cpu-cpuid.AVX = true
2019/10/21 00:46:25 cpu-cpuid.AVX512VL = true
2019/10/21 00:46:25 cpu-cpuid.AVX512CD = true
2019/10/21 00:46:25 cpu-cpuid.AVX2 = true
2019/10/21 00:46:25 cpu-cpuid.FMA3 = true
2019/10/21 00:46:25 cpu-cpuid.ADX = true
2019/10/21 00:46:25 cpu-cpuid.AVX512DQ = true
2019/10/21 00:46:25 cpu-cpuid.AESNI = true
2019/10/21 00:46:25 cpu-cpuid.AVX512BW = true
2019/10/21 00:46:25 cpu-cpuid.MPX = true
2019/10/21 00:46:25 kernel-config.NO_HZ = true
2019/10/21 00:46:25 kernel-config.NO_HZ_IDLE = true
2019/10/21 00:46:25 kernel-version.full = 4.15.0-1051-aws
2019/10/21 00:46:25 kernel-version.major = 4
2019/10/21 00:46:25 kernel-version.minor = 15
2019/10/21 00:46:25 kernel-version.revision = 0
2019/10/21 00:46:25 pci-10de.present = true
2019/10/21 00:46:25 pci-1d0f.present = true
2019/10/21 00:46:25 storage-nonrotationaldisk = true
2019/10/21 00:46:25 system-os_release.ID = ubuntu
2019/10/21 00:46:25 system-os_release.VERSION_ID = 18.04
2019/10/21 00:46:25 system-os_release.VERSION_ID.major = 18
2019/10/21 00:46:25 system-os_release.VERSION_ID.minor = 04

讓我們啟動一個 TensorFlow 筆記本。 GitHub repo 上有一個示例清單，讓我們使用它

$ kubectl apply -f https://nvidia.github.io/gpu-operator/notebook-example.yml

一旦 pod 被創建，我們就可以使用令牌在瀏覽器窗口中查看筆記本。

$ kubectl logs -f tf-notebook
[C 02:52:44.849 NotebookApp] Copy/paste this URL into your browser when you connect for the first time, to login with a token: http://localhost:8888/?token=b7881f90dfb6c8c5892cff7e8232684f201c846c48da81c9

我們可以使用端口轉發或使用節點端口 30001 到達容器。使用上面日志中的 URL 在瀏覽器中打開 Jupyter 筆記本。

$ kubectl port-forward tf-notebook 8888:8888

現在您可以看到 Jupyter 主頁并繼續您的工作流 – 所有這些都在 Kubernetes 中運行，并通過 GPUs 加速！

結論

如果您有任何問題或意見，請在下面的評論部分留下。對于有關安裝和使用的技術問題，我們建議在 GitHub 上提交一個問題。

關于作者

Pramod Ramarao 是 NVIDIA 加速計算的產品經理。他領導 CUDA 平臺和數據中心軟件的產品管理，包括容器技術。

審核編輯：郭婷