NVIDIA 運營商簡化了 Kubernetes 上的 GPU 和 SmartNIC 管理。這篇文章展示了如何使用預裝的驅動程序將 NVIDIA 運營商集成到新的 edge AI 平臺中。這是一個由兩部分組成的系列文章的第一篇。下一篇文章將介紹如何使用自定義驅動程序容器集成 NVIDIA 操作符。

面向未來的邊緣人工智能平臺

如今，每個行業都在使用 edge AI 。部署在飛機、商店和工廠中的服務器實時響應物聯網傳感器。它們分別是 天氣預測 、 阻止盜竊 和 保證制造質量 。

人工智能使傳感器數據可操作。經過訓練的人工智能模型能夠識別模式并觸發響應。經過訓練的人工智能模型代表公司的商業智能。正如原油提煉成石油后變得有價值一樣，人工智能將傳感器數據轉化為洞察力。

但與石油不同， 物聯網傳感器數據量呈指數增長 。在邊緣生成的大量數據可能會壓倒邊緣服務器處理數據的能力。

這就是為什么 邊緣人工智能需要加速 。 NVIDIA GPU 和 SmartNICs 是一個面向未來的邊緣 AI 平臺，可抵御指數級數據增長。

Edge AI 是云本地的

這篇文章描述了如何將 NVIDIA 加速器與 Kubernetes 集成。為什么要關注庫伯內特斯？因為 edge AI 是云本地的 。大多數人工智能應用程序都是基于容器的微服務。 Kubernetes 是容器編排的非官方標準。

Edge AI 平臺基于 Kubernetes 的靈活性而構建。 Kubernetes API 支持聲明式自動化，并可通過自定義資源定義進行擴展。強健的軟件生態系統支持 Kubernetes 的第一天和第二天操作。

NVIDIA Fleet Command 是基于 Kubernetes 的 Edge AI 平臺的一個示例。 Fleet Command 是一種為安全性和性能而設計的混合云服務。它管理裸機邊緣節點上的 AI 應用程序生命周期。 Fleet Command 還與 NGC 集成，后者是 NVIDIA 管理的 700 多個 GPU 優化應用程序的注冊中心。

雖然 Fleet Command 支持 NVIDIA GPU 和 SmartNIC ，但許多邊緣平臺不支持。對于這些， NVIDIA 提供了開源 Kubernetes operators 來啟用 GPU 和 SmartNIC 加速。有兩個運營商：NVIDIA GPU Operator 及 英偉達網絡運營商 。

英偉達 GPU 運營商自動化 GPU 部署和管理上的 KubNeNETs 。 NGC 上有 GPU 操作員舵圖。它包括幾個組成部分：

這個NVIDIA GPU 驅動程序容器自動安裝 GPU 驅動程序。

NVIDIA 容器工具 允許用戶構建和運行支持 GPU 的容器。

NVIDIA K8s 設備插件 向吊艙和 Kubernetes 調度程序公開 GPU 。

NVIDIA DCGM 和 NVIDIA DCGM 導出器 自動執行 GPU 遙測采集和管理。

NVIDIA GPU 功能發現根據 GPU 特征標記 Kubernetes 工人。

NVIDIA MIG 管理器監視器多實例 GPU（ MIG ）用于配置更改并應用它們。

圖 1 。這些組件構成英偉達 GPU 算子。

英偉達網絡運營商為 Kubernetes PODs 實現了需要快速聯網的 CONTROX 智能配置。它也作為舵圖交付。網絡運營商使用 Multus CNI 插件 向 pod 添加第二個網絡接口。它支持遠程直接內存訪問（ RDMA ）和共享根 I / O 虛擬化（ SRIOV ）。

英偉達網絡運營商包括以下組件：

NVIDIA OFED 驅動程序容器 可自動安裝網絡驅動程序和庫。

Kubernetes RDMA 共享設備插件 將 RDMA 設備連接到 POD 。它支持 Infiniband 和基于聚合以太網（ RoCE ）的 RDMA 。

SRIOV 設備插件將 SRIOV 虛擬功能（ VF ）連接到 POD 。

Containernetworking CNI 插件是擴展 Kubernetes 網絡功能的標準接口。

下落 CNI 插件管理集群范圍的自動 IP 地址創建和分配。

MACVLAN CNI 用作虛擬交換機，將 POD 連接到網絡功能。

Multus CNI 插件可將多個網絡設備連接到 Kubernetes 吊艙。

主機設備 CNI 插件將現有設備（如 SRIOV VF ）從主機移動到 pod 的網絡名稱空間。

圖 2 。這些組件構成英偉達網絡運營商組件。

兩個操作員都使用 節點特征發現 。此服務標識哪些群集節點具有 GPU 和 SmartNIC 。

操作員一起工作或單獨工作。將它們部署在一起可啟用 GPUDirect RDMA 。此功能繞過主機緩沖以提高 NIC 和 GPU 之間的吞吐量。

英偉達運營商是開源軟件。它們已經支持在 NVIDIA 認證服務器 上運行的流行 Kubernetes 發行版。但許多邊緣平臺運行運營商不支持的定制 Linux 發行版。這篇文章解釋了如何將 NVIDIA 運營商與這些平臺集成。

兩條路，一條路

圖 3 。此圖表示集成 NVIDIA 操作程序的兩種方法：預裝驅動程序或自定義驅動程序容器

可移植性是云本地軟件的主要優點之一。容器將應用程序與其依賴項捆綁在一起。這使它們能夠在不同的平臺上運行、擴展和遷移，而不會產生摩擦。

NVIDIA 運營商是基于容器的云本地應用程序。大多數運營商服務不需要任何集成就可以在新平臺上運行。但這兩個操作符都包含驅動程序容器，驅動程序是例外。驅動程序依賴于內核。將 NVIDIA 運營商與新平臺集成需要重建目標內核的驅動程序容器。該平臺可能正在運行不受支持的 Linux 發行版或自定義編譯內核。

提供自定義驅動程序有兩種方法：

首先，在安裝操作員之前將驅動程序安裝到主機上。許多邊緣平臺在其基本操作系統映像中提供簽名驅動程序，以支持 安全和有尺寸的靴子 。需要簽名驅動程序的平臺不能使用操作員部署的驅動程序容器。英偉達艦隊司令部遵循這種模式。網絡和 GPU 運營商都通過禁用自己的驅動程序容器來支持預裝驅動程序。

第二種方法是將操作員的驅動程序容器替換為自定義容器。具有不可變文件系統的邊緣平臺更喜歡這種方法。邊緣服務器通常作為設備運行。他們使用只讀文件系統來提高安全性并防止配置漂移。在內存中運行驅動程序和應用程序容器，而不是將它們添加到不可變映像中，可以減少其大小和復雜性。這還允許同一映像在具有不同硬件配置文件的節點上運行。

這篇文章解釋了如何設置這兩種模式。本文的第一部分介紹了驅動程序的預安裝。第二部分介紹如何構建和安裝自定義驅動程序容器。

除了驅動程序容器外，其余的運營商服務通常在新平臺上運行，無需修改。 NVIDIA 在 主要容器運行時 上測試這兩個操作符，例如 Docker Engine 、 CRI-O 和 Containerd 。 GPU 運算符還支持 運行時類資源 進行每吊艙運行時選擇。

預裝驅動程序集成

本文的其余部分將展示如何將 NVIDIA 運營商與自定義邊緣平臺集成。它包括驅動程序預安裝和驅動程序容器方法的逐步過程。

表 1 描述了用于演示這些程序的測試系統。

表 1 ：測試系統說明

兩個操作員都不支持測試系統上的操作系統、 Linux 內核和容器運行時組合。 Linux 內核是自定義編譯的，因此預編譯驅動程序不可用。測試系統還使用 Cri-o 容器運行時，這比 Containerd 和 Docker Engine 等替代方案更不常見。

準備系統

1. 首先，驗證 CONNECTX SmartNIC 和 NVIDIA GPU 在測試系統上是否可見。

$ lspci | egrep 'nox|NVI'
23:00.0 3D controller: NVIDIA Corporation Device 20f1 (rev a1)
49:00.0 Ethernet controller: Mellanox Technologies MT2892 Family [ConnectX-6 Dx]
49:00.1 Ethernet controller: Mellanox Technologies MT2892 Family [ConnectX-6 Dx]
5e:00.0 Ethernet controller: Mellanox Technologies MT27710 Family [ConnectX-4 Lx]
e3:00.0 Ethernet controller: Mellanox Technologies MT2892 Family [ConnectX-6 Dx]
e3:00.1 Ethernet controller: Mellanox Technologies MT2892 Family [ConnectX-6 Dx]
e6:00.0 3D controller: NVIDIA Corporation Device 20f1 (rev a1)

2 .查看操作系統和 Linux 內核版本。在本例中， Centos 7 3 . 10 . 0-1160 . 45 . 1 內核被重新編譯為 3 . 10 . 0-1160 . 45 . 1 . el7 . custom . x86 _ 64 。

$ cat /etc/redhat-release CentOS Linux release 7.9.2009 (Core) $ uname -r
3.10.0-1160.45.1.el7.custom.x86_64

3 .查看 Kubernetes 版本、網絡配置和群集節點。此輸出顯示了單節點集群，這是邊緣 AI 部署的典型模式。該節點正在運行 Kubernetes 1 . 21 版。

$ kubectl get nodes
NAME STATUS ROLES AGE VERSION
cgx-20 Ready control-plane 23d v1.21.3

4 .查看已安裝的容器運行時。此示例顯示了 cri-o 容器運行時。

$ kubectl get node cgx-20 -o yaml | grep containerRuntime containerRuntimeVersion: cri-o://1.21.3

5 . NVIDIA 通過頭盔圖表為操作員提供服務。查看已安裝的舵機版本。

$ helm version
version.BuildInfo{Version:"v3.3.3", GitCommit:"55e3ca022e40fe200fbc855938995f40b2a68ce0", GitTreeState:"clean", GoVersion:"go1.14.9"}

使用預裝的驅動程序安裝網絡運營商

Mellanox OpenFabrics Linux 企業發行版為高性能網絡安裝開源驅動程序和庫。 NVIDIA 網絡操作員可選地安裝一個 MOFE 容器，將這些驅動程序和庫加載到 Kubernetes 上。本節介紹在無法使用附帶的驅動程序容器的情況下在主機上預安裝 MOFED 驅動程序的過程。

1. 安裝先決條件。

$ yum install -y perl numactl-libs gtk2 atk cairo gcc-gfortran tcsh libnl3 tcl tk python-devel pciutils make lsof redhat-rpm-config rpm-build libxml2-python ethtool iproute net-tools openssh-clients git openssh-server wget fuse-libs

2 .下載并解壓縮 Linux 發行版的 MOFED 歸檔文件。

$ wget https://www.mellanox.com/downloads/ofed/MLNX_OFED-5.4-1.0.3.0/MLNX_OFED_LINUX-5.4-1.0.3.0-rhel7.9-x86_64.tgz $ tar zxf MLNX_OFED_LINUX-5.4-1.0.3.0-rhel7.9-x86_64.tgz

3 .使用 mlnxofedinstall 安裝內核空間驅動程序。安裝腳本可能會自動更新 CONNECTX SmartNIC 固件。

$ cd MLNX_OFED_LINUX-5.4-1.0.3.0-rhel7.9-x86_64 $ ./mlnxofedinstall --without-rshim-dkms --without-iser-dkms --without-isert-dkms --without-srp-dkms --without-kernel-mft-dkms --without-mlnx-rdma-rxe-dkms 

4 .重新啟動以加載新的驅動程序。

$ sudo shutdown -r now

5 .重新啟動后，確保已加載驅動程序。

$ /etc/init.d/openibd status HCA driver loaded Configured Mellanox EN devices:
enp94s0
ens13f0
ens13f1
ens22f0
ens22f1 Currently active Mellanox devices:
enp94s0
ens13f0
ens13f1
ens22f0
ens22f1 The following OFED modules are loaded: rdma_ucm rdma_cm ib_ipoib mlx5_core mlx5_ib ib_uverbs ib_umad ib_cm ib_core mlxfw

一旦成功安裝 MOFED 并加載驅動程序，就開始安裝英偉達網絡運營商。

6 .標識輔助網絡設備名稱。這將是作為輔助網絡接口插入 pod 的一個或多個設備。

$ ibdev2netdev
mlx5_0 port 1 ==> ens13f0 (Up)
mlx5_1 port 1 ==> ens13f1 (Down)
mlx5_2 port 1 ==> enp94s0 (Up)
mlx5_3 port 1 ==> ens22f0 (Up)
mlx5_4 port 1 ==> ens22f1 (Down)

7 .默認情況下，網絡運營商不會部署到 Kubernetes 主機。從節點中刪除主標簽以適應一體式集群部署。

$ kubectl label nodes --all node-role.kubernetes.io/master- --overwrite

注意：這是一個臨時解決方案，允許網絡運營商將 POD 調度到單節點群集中的主節點。網絡運營商的未來版本將增加容忍度和節點親和性，以避免這種解決方法。

8 .添加 Mellanox Helm 圖表存儲庫。

$ helm repo add mellanox https://mellanox.github.io/network-operator
$ helm repo update
$ helm repo ls
NAME URL mellanox https://mellanox.github.io/network-operator

9 創建 values . yaml 以指定網絡運營商配置。本例部署 RDMA 共享設備插件，并將 ens13f0 指定為支持 RDMA 的接口。

$ cat roce_shared_values.yaml nfd: enabled: true
deployCR: true
sriovDevicePlugin: deploy: false
rdmaSharedDevicePlugin: deploy: true resources: - name: rdma_shared_device_a vendors: [15b3] deviceIDs: [101d] ifNames: [ens13f0]

10 安裝網絡運營商 Helm 圖表，使用新配置文件覆蓋 default values . yaml 。

$ helm install -f ./roce_shared_values.yaml -n network-operator --create-namespace --wait network-operator mellanox/network-operator

11 驗證所有網絡運營商吊艙是否處于運行狀態。

$ kubectl get pods -n nvidia-network-operator-resources
NAME READY STATUS RESTARTS AGE
cni-plugins-ds-fcrsq 1/1 Running 0 3m44s
kube-multus-ds-4n526 1/1 Running 0 3m44s
rdma-shared-dp-ds-5rq4x 1/1 Running 0 3m44s
whereabouts-9njxm 1/1 Running 0 3m44s

請注意，某些版本的印花布與某些 Multus CNI 版本不兼容。在 Multus 守護程序啟動后更改 Multus API 版本。

$ sed -i 's/0.4.0/0.3.1/' /etc/cni/net.d/00-multus.conf

12Helm 圖表創建一個 configMap ，用于使用 values . yaml 文件中定義的選擇器標記節點。驗證 NFD 是否正確標記了節點，以及是否創建了 RDMA 共享設備。

$ kubectl describe cm -n nvidia-network-operator-resources rdma-devices | grep 15b3
{ "configList": [ { "resourceName": "rdma_shared_device_a", "rdmaHcaMax": 1000, "selectors": { "vendors": ["15b3"], "deviceIDs": ["101d"], "drivers": [], "ifNames": ["ens13f0"], "linkTypes": [] } } ] } $ kubectl describe node cgx-20 | egrep '15b3|rdma_shared' feature.node.kubernetes.io/pci-15b3.present=true feature.node.kubernetes.io/pci-15b3.sriov.capable=true rdma/rdma_shared_device_a: 1k rdma/rdma_shared_device_a: 1k rdma/rdma_shared_device_a 0 0

使用預裝的驅動程序安裝 GPU 操作器

按照相同的過程安裝帶有預編譯驅動程序的 GPU 操作符。

1. 首先，禁用 nouveau GPU 驅動程序，將其從加載中列入黑名單，并重建初始 RAMdisk 。

$ cat << EOF | sudo tee /etc/modprobe.d/blacklist-nouveau.conf
blacklist nouveau
options nouveau modeset=0
EOF $ sudo dracut --force

2 .下載 Linux 的英偉達 GPU 驅動程序安裝腳本。在本例中，我們使用的是驅動程序版本 470 . 57 . 02 。

$ wget https://us.download.nvidia.com/tesla/470.57.02/NVIDIA-Linux-x86_64-470.57.02.run

3 .運行安裝腳本。該腳本自動編譯目標操作系統內核的驅動程序。

$ sh NVIDIA-Linux-x86_64-470.57.02.run -q -a -n -X -s

4 .驗證驅動程序是否已成功加載。

$ modinfo -F version nvidia
470.57.02

5 .在 Cri-o 容器運行時配置中禁用 SELinux 并重新啟動服務。

請注意， SELinux 在測試系統上處于允許模式。當 SELinux 處于強制模式時，需要執行其他步驟。

$ cat << EOF | sudo tee /etc/crio/crio.conf
[crio]
[crio.runtime]
selinux = false
hooks_dir = [ "/usr/share/containers/oci/hooks.d", "/run/containers/oci/hooks.d",
]
[crio.network]
plugin_dirs = [ "/opt/cni/bin", "/usr/libexec/cni",
]
[crio.metrics]
enable_metrics = true
metrics_port = 9537
EOF $ systemctl restart crio.service

6 .刪除調度到主節點時的污點。

$ kubectl taint nodes --all node-role.kubernetes.io/master-
node/cgx-20 untainted

7 .安裝 GPU 操作員舵圖存儲庫。

$ helm repo add nvidia https://nvidia.github.io/gpu-operator $ helm repo update # helm repo ls
NAME URL nvidia https://nvidia.github.io/gpu-operator mellanox	https://mellanox.github.io/network-operator

8 .安裝 GPU 操作員舵圖。將 driver . enabled 參數重寫為 false 將禁用驅動程序容器安裝。還指定 crio 作為容器運行時。

$ helm install --generate-name nvidia/gpu-operator --set driver.enabled=false --set toolkit.version=1.7.1-centos7 --set operator.defaultRuntime=crio $ helm ls
NAME NAMESPACE	REVISION	UPDATED STATUS CHART APP VERSION
gpu-operator-1635194696	default 1 2021-10-25 16:44:57.237363636 -0400 EDT	deployed	gpu-operator-v1.8.2	v1.8.2 

9 查看 GPU 操作員資源。所有吊艙應處于運行或完成狀態。

$ kubectl get pods -n gpu-operator-resources
NAME READY STATUS RESTARTS AGE
gpu-feature-discovery-6kpxt 1/1 Running 0 114s
nvidia-container-toolkit-daemonset-sprjb 1/1 Running 0 114s
nvidia-cuda-validator-ndc78 0/1 Completed 0 90s
nvidia-dcgm-exporter-n9xnp 1/1 Running 0 114s
nvidia-dcgm-pfknx 1/1 Running 0 114s
nvidia-device-plugin-daemonset-4qnh6 1/1 Running 0 114s
nvidia-device-plugin-validator-845pw 0/1 Completed 0 84s
nvidia-mig-manager-rf7vz 1/1 Running 0 114s
nvidia-operator-validator-5ngbk 1/1 Running 0 114s

10 查看驗證 pod 日志以驗證驗證測試是否已完成。

$ kubectl logs -n gpu-operator-resources nvidia-device-plugin-validator-845pw
device-plugin workload validation is successful $ kubectl logs -n gpu-operator-resources nvidia-cuda-validator-ndc78 cuda workload validation is successful

11 從驗證器容器中運行 nvidia smi 以顯示 GPU 、驅動程序和 CUDA 版本。這還驗證了容器運行時預啟動掛鉤是否按預期工作。

$ kubectl exec -n gpu-operator-resources -i -t nvidia-operator-validator-5ngbk --container nvidia-operator-validator -- nvidia-smi
Mon Oct 25 20:57:28 2021 +-----------------------------------------------------------------------------+
| NVIDIA-SMI 470.57.02 Driver Version: 470.57.02 CUDA Version: 11.4 |
|-------------------------------+----------------------+----------------------+
| GPU Name Persistence-M| Bus-Id Disp.A | Volatile Uncorr. ECC |
| Fan Temp Perf Pwr:Usage/Cap| Memory-Usage | GPU-Util Compute M. |
| | | MIG M. |
|===============================+======================+======================|
| 0 NVIDIA A100-PCI... Off | 00000000:23:00.0 Off | 0 |
| N/A 26C P0 32W / 250W | 0MiB / 40536MiB | 0% Default |
| | | Disabled |
+-------------------------------+----------------------+----------------------+
| 1 NVIDIA A100-PCI... Off | 00000000:E6:00.0 Off | 0 |
| N/A 26C P0 32W / 250W | 0MiB / 40536MiB | 0% Default |
| | | Disabled |
+-------------------------------+----------------------+----------------------+ +-----------------------------------------------------------------------------+
| Processes: |
| GPU GI CI PID Type Process name GPU Memory |
| ID ID Usage |
|=============================================================================|
| No running processes found |
+-----------------------------------------------------------------------------+

測試預安裝的驅動程序集成

通過創建測試吊艙來測試預裝的驅動程序集成。

1 .創建網絡附件定義。網絡連接定義是一種自定義資源，允許 POD 連接到一個或多個網絡。此網絡連接定義定義了一個 MAC VLAN 網絡，用于跨輔助接口橋接多個 POD 。下落 CNI 自動為連接到輔助網絡的 POD 分配 IP 地址。

$ cat << EOF | sudo tee rdma_shared_macvlan_net.yaml
apiVersion: mellanox.com/v1alpha1
kind: MacvlanNetwork
metadata: name: roce-shared-macvlan-network
spec: networkNamespace: "default" master: "ens13f0" mode: "bridge" mtu: 1500 ipam: | { "type": "whereabouts", "datastore": "kubernetes", "kubernetes": { "kubeconfig": "/etc/cni/net.d/whereabouts.d/whereabouts.kubeconfig" }, "range": "192.168.2.225/28", "exclude": [ "192.168.2.229/30", "192.168.2.236/32" ], "log_file" : "/var/log/whereabouts.log", "log_level" : "info", "gateway": "192.168.2.1" }
EOF

2 .應用網絡附件定義。

$ kubectl create -f roce_shared_macvlan_net.yaml $ kubectl describe network-attachment-definition roce-shared-macvlan-network | grep Config Config: { "cniVersion":"0.4.0", "name":"roce-shared-macvlan-network", "type":"macvlan","master": "ens13f0","mode" : "bridge","mtu" : 1500,"ipam":{"type":"whereabouts","datastore":"kubernetes","kubernetes":{"kubeconfig":"/etc/cni/net.d/whereabouts.d/whereabouts.kubeconfig"},"range":"192.168.2.225/28","exclude":["192.168.2.229/30","192.168.2.236/32"],"log_file":"/var/log/whereabouts.log","log_level":"info","gateway":"192.168.2.1"} }

3 .創建測試吊艙規范文件。 spec 文件應包括 RDMA 設備的網絡附件和資源限制的注釋。

$ cat << EOF | sudo tee roce_shared_macvlan_pod.yaml apiVersion: v1
kind: Pod
metadata: name: roce-shared-pod annotations: k8s.v1.cni.cncf.io/networks: roce-shared-macvlan-network
spec: restartPolicy: OnFailure containers: - image: mellanox/rping-test name: mofed-test-ctr securityContext: capabilities: add: [ "IPC_LOCK","NET_RAW" ] resources: requests: rdma/rdma_shared_device_a: 1 limits: rdma/rdma_shared_device_a: 1 command: - sh - -c - | ls -l /dev/infiniband /sys/class/net sleep 1000000
EOF

4 .創建測試吊艙。

$ kubectl create -f roce_shared_pod.yaml $ kubectl get pods | grep roce
roce-shared-pod 1/1 Running 0 6m46s

5 .查看測試盒日志以驗證網絡連接。本例中的輔助接口名為 net1 。

$ kubectl describe pod roce-shared-pod | grep -B1 rdma Limits: rdma/rdma_shared_device_a: 1 Requests: rdma/rdma_shared_device_a: 1 $ kubectl logs roce-shared-pod
/dev/infiniband:
total 0
crw-rw-rw-. 1 root root 231, 64 Oct 13 22:48 issm0
crw-rw-rw-. 1 root root 10, 56 Oct 13 22:48 rdma_cm
crw-rw-rw-. 1 root root 231, 0 Oct 13 22:48 umad0
crw-rw-rw-. 1 root root 231, 192 Oct 13 22:48 uverbs0 /sys/class/net:
total 0
lrwxrwxrwx. 1 root root 0 Oct 13 22:48 eth0 -> ../../devices/virtual/net/eth0
lrwxrwxrwx. 1 root root 0 Oct 13 22:48 lo -> ../../devices/virtual/net/lo
lrwxrwxrwx. 1 root root 0 Oct 13 22:48 net1 -> ../../devices/virtual/net/net1
lrwxrwxrwx. 1 root root 0 Oct 13 22:48 tunl0 -> ../../devices/virtual/net/tunl0

6 .查看 net1 上的地址分配。

$ kubectl exec -ti roce-shared-pod -- ifconfig net1
 mtu 1500 inet 192.168.2.225 netmask 255.255.255.240 broadcast 192.168.2.239 inet6 fe80::6871:9cff:fe1b:afe4 prefixlen 64 scopeid 0x20 ether 6a:71:9c:1b:af:e4 txqueuelen 0 (Ethernet) RX packets 405 bytes 24300 (23.7 KiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 9 bytes 698 (698.0 B) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

7 . GPU 操作員創建 POD 以驗證驅動程序、容器運行時和 Kubernetes 設備插件。創建一個額外的 GPU 測試盒。

$ cat << EOF | kubectl create -f -
apiVersion: v1
kind: Pod
metadata: name: cuda-vectoradd
spec: restartPolicy: OnFailure containers: - name: cuda-vectoradd image: "nvidia/samples:vectoradd-cuda11.2.1" resources: limits: nvidia.com/gpu: 1
EOF

8 .查看結果。

$ kubectl get pod cuda-vectoradd
NAME READY STATUS RESTARTS AGE
cuda-vectoradd 0/1 Completed 0 34s $ kubectl logs cuda-vectoradd
[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

9 加載 nvidia peermem 驅動程序。它為 CONNECTX SmartNIC 提供 GPUDirect RDMA 。該驅動程序包含在 NVIDIA Linux GPU 驅動程序版本 470 及更高版本中。如果系統上同時存在 ib _ core 和 NVIDIA GPU 驅動程序源，則在 Linux 驅動程序安裝過程中會自動編譯該文件。這意味著 MOFED 驅動程序應該在 GPU 驅動程序之前安裝，以便 MOFED 源代碼可用于構建 nvidia peermem 驅動程序。

$ modprobe nvidia-peermem $ lsmod | grep nvidia_peermem
nvidia_peermem 13163 0 nvidia 35224507 113 nvidia_modeset,nvidia_peermem,nvidia_uvm
ib_core 357959 9 rdma_cm,ib_cm,iw_cm,mlx5_ib,ib_umad,nvidia_peermem,ib_uverbs,rdma_ucm,ib_ipoib

關于作者

Jacob Liberman 是 NVIDIA 企業和邊緣加速集團的產品經理。他利用 20 多年的技術計算經驗提供高性能、云計算原生邊緣人工智能解決方案。此前，他曾在紅帽、 AMD 和戴爾擔任產品管理和工程職務。

審核編輯：郭婷