Red Hat OpenShift 是一個企業(yè)級 Kubernetes 平臺，用于大規(guī)模管理 Kubernetes 集群，由 Red Hat 開發(fā)和支持。它提供了一種方法來改變組織如何在本地以及跨混合云管理復(fù)雜的基礎(chǔ)設(shè)施

人工智能計算給現(xiàn)代商業(yè)帶來了深遠的變革，包括金融服務(wù)中的欺詐檢測以及娛樂和電子商務(wù)的推薦引擎。 2018 年 CTA 市場研究報告顯示，與不采用人工智能的公司相比，將人工智能技術(shù)作為公司戰(zhàn)略核心的公司的利潤率提高了 15% 。

為這些新的、大量計算密集型的工作負載提供基礎(chǔ)設(shè)施的責(zé)任落在了 IT 的肩上，許多組織都在為 AI 部署 IT 認(rèn)可的基礎(chǔ)設(shè)施所帶來的復(fù)雜性、時間和成本上苦苦掙扎。多達 40% 的希望部署人工智能的組織將基礎(chǔ)設(shè)施視為主要障礙。為人工智能工作負載部署集群通常會在網(wǎng)絡(luò)拓撲、計算和存儲資源的規(guī)模確定等方面提出問題。 NVIDIA 因此為典型應(yīng)用創(chuàng)建了參考架構(gòu)，以減輕猜測。

例如 DGX-POD， 它包含了多個 DGX-1 系統(tǒng)及來自多個供應(yīng)商的存儲系統(tǒng)。 NVIDIA 根據(jù)部署在世界上最大的研究和企業(yè)環(huán)境中的數(shù)千個前沿加速計算節(jié)點的經(jīng)驗，開發(fā)了 DGX POD 。然而，要確保人工智能在規(guī)模上取得成功，就需要一個軟件平臺，如 KubernetesTM ，以確保人工智能基礎(chǔ)設(shè)施的可管理性。

紅帽 OpenShift 4 是一個主要的發(fā)行版，它結(jié)合了紅帽收購 CoreOS 的技術(shù)。其核心（不是雙關(guān)語）是基于 Red Hat Enterprise Linux CoreOS （ RHCOS ）的不可變系統(tǒng)映像。它遵循了一個新的范例，即安裝在部署之后永遠不會被修改或更新，而是被整個系統(tǒng)映像的更新版本所取代。這就提供了更高的可靠性和一致性，并提供了更可預(yù)測的部署過程。

這篇文章首先介紹了 OpenShift 4 和 GPU 操作符在 OpenShift 參考架構(gòu)上的 AI 工作負載。我們基于一個需要一些手動步驟的軟件預(yù)覽，這將在最終版本中解決。

安裝和運行 OpenShift 需要一個 Red Hat 帳戶和其他訂閱。官方安裝說明見 在裸機上安裝群集 。

測試設(shè)置概述

OpenShift 集群的最小配置包括三個 主人 節(jié)點和兩個 工人 節(jié)點（也稱為 計算 節(jié)點）。集群的初始設(shè)置需要一個額外的 引導(dǎo) 節(jié)點，可以在安裝過程中刪除或重新調(diào)整其用途。有三個主節(jié)點的要求確保了高可用性（避免了大腦分裂的情況），并允許主節(jié)點不間斷地升級。

我們在一臺 x86 機器上使用虛擬機作為引導(dǎo)和主節(jié)點，兩個 DGX-1 系統(tǒng)用于計算節(jié)點（裸機）。負載平衡器在單獨的虛擬機中運行，以將請求分發(fā)到節(jié)點。使用循環(huán) DNS 也起到了作用，但要正確地配置結(jié)果卻很棘手。需要將 virsh 網(wǎng)絡(luò)設(shè)置為橋接模式，而不是 NAT ，以便節(jié)點可以相互通信。

Red Hat OpenShift 4 還沒有為裸機系統(tǒng)提供完全自動化的安裝方法，但需要外部基礎(chǔ)設(shè)施來提供和執(zhí)行初始安裝（ OpenShift 文檔將其稱為 用戶提供的基礎(chǔ)設(shè)施（ UPI ） 。在我們的例子中，我們使用 x86 服務(wù)器通過 PXE 引導(dǎo)來配置和引導(dǎo)節(jié)點。一旦安裝，節(jié)點將自動執(zhí)行升級。

創(chuàng)建系統(tǒng)配置

Red Hat Enterprise Linux CoreOS 使用點火進行系統(tǒng)配置。點火提供了與 cloud init 類似的功能，并允許在第一次引導(dǎo)期間配置系統(tǒng)。

點火文件由 OpenShift 起始頁 安裝程序從配置文件 install-config.yaml 生成。它通過各種參數(shù)描述集群，還包括一個 SSH 密鑰和用于從 redhat 容器存儲庫提取容器的憑據(jù)。可以從 OpenShift 下載 OpenShift 工具和 Pull Secret 。

apiVersion: v1
baseDomain: nvidia.com
compute:
- hyperthreading: Enabled name: worker platform: {} replicas: 2
controlPlane: hyperthreading: Enabled name: master platform: {} replicas: 3
metadata: creationTimestamp: null name: dgxpod
networking: clusterNetwork: - cidr: 10.128.0.0/14 hostPrefix: 23 networkType: OpenShiftSDN machineCIDR: 10.0.0.0/16 serviceNetwork: - 172.30.0.0/16
platform: none: {}
pullSecret: '{"auths": ….}'
sshKey: ssh-rsa ...

參數(shù)baseDomain和metadata:name構(gòu)成集群的域名（dgxpod.nvidia.com）。網(wǎng)絡(luò)參數(shù)描述了 OpenShift 集群的內(nèi)部網(wǎng)絡(luò)，只有在與外部網(wǎng)絡(luò)沖突時才需要修改。

以下命令為節(jié)點創(chuàng)建點火文件，并為集群創(chuàng)建身份驗證文件。因為這些命令刪除了安裝 – 組態(tài)軟件，所以我們在ignition目錄之外保留了它的一個副本。生成的身份驗證文件（ignition/auth/kubeconfig）應(yīng)重命名并復(fù)制到$USERHOME/.kube/config

mkdir ignition
cp install-config.yaml ignition
openshift-install --dir ignition create ignition-configs

DHCP 和 PXE 引導(dǎo)

設(shè)置 PXE 引導(dǎo)當(dāng)然不是一件容易的事；提供詳細的說明超出了本文的范圍。讀者應(yīng)具備設(shè)置 PXE 引導(dǎo)和 DHCP 的知識。以下代碼段僅介紹 dnsmasq 的 DNS 配置。

dnsmasq 配置文件中的 address 指令允許使用通配符來解析任何帶有負載平衡器地址的*. apps 請求。 SRV 條目允許集群訪問 etcd 服務(wù)。

# Add hosts file
addn-hosts=/etc/hosts.dnsmasq # Forward all *.apps.dgxpod.nvidia.com to the load balancer
address=/apps.dgxpod.nvidia.com/10.33.3.54/ # SRV DNS records
srv-host=_etcd-server-ssl._tcp.dgxpod.nvidia.com,etcd-0.dgxpod.nvidia.com,2380,0,10
srv-host=_etcd-server-ssl._tcp.dgxpod.nvidia.com,etcd-1.dgxpod.nvidia.com,2380,0,10
srv-host=_etcd-server-ssl._tcp.dgxpod.nvidia.com,etcd-2.dgxpod.nvidia.com,2380,0,10

相應(yīng)的/etc/hosts.dnsmasq文件列出了 IP 地址和主機名。注意， OpenShift 要求每個主機的第一個條目是節(jié)點名，例如master-0。api-int和api項指向負載平衡器。

10.33.3.44 worker-0.dgxpod.nvidia.com
10.33.3.46 worker-1.dgxpod.nvidia.com 10.33.3.50 master-0.dgxpod.nvidia.com etcd-0.dgxpod.nvidia.com
10.33.3.51 master-1.dgxpod.nvidia.com etcd-1.dgxpod.nvidia.com
10.33.3.52 master-2.dgxpod.nvidia.com etcd-2.dgxpod.nvidia.com 10.33.3.53 bootstrap.dgxpod.nvidia.com 10.33.3.54 api-int.dgxpod.nvidia.com api.dgxpod.nvidia.com

下面的pxelinux.cfg文件是一個非 EFI-PXE 引導(dǎo)配置的示例。它定義內(nèi)核和初始 ramdisk ，并提供額外的命令行參數(shù)。注意，前綴為coreos的參數(shù)被傳遞給 CoreOS 安裝程序。

DEFAULT rhcos
PROMPT 0
TIMEOUT 0 LABEL rhcos kernel rhcos/rhcos-410.8.20190425.1-installer-kernel initrd rhcos/rhcos-410.8.20190425.1-installer-initramfs.img append ip=dhcp rd.neednet=1 console=tty0 console=ttyS0 coreos.inst=yes coreos.inst.install_dev=vda coreos.inst.image_url=http://10.33.3.18/rhcos/rhcos-410.8.20190412.1-metal-bios.raw coreos.inst.ignition_url=http://10.33.3.18/rhcos/ignition/master.ign

內(nèi)核、 initramfs 和 raw 映像可以從 OpenShift 鏡像 獲得。安裝說明 在裸機上安裝群集 提供了最新版本和下載路徑。應(yīng)將上一步驟中的映像文件和點火配置復(fù)制到 http 目錄。請確保為所有這些文件設(shè)置了正確的 http SELinux 標(biāo)簽。請注意， DGX-1 系統(tǒng)僅支持 UEFI 進行網(wǎng)絡(luò)引導(dǎo)，因此需要不同的文件集。

負載平衡器

負載平衡器處理跨在線節(jié)點的分布式請求。我們在一個單獨的虛擬機中運行 CentOS 的實例，并使用 HAProxy 進行以下配置。

listen ingress-http bind *:80 mode tcp server worker-0 worker-0.dgxpod.nvidia.com:80 check server worker-1 worker-1.dgxpod.nvidia.com:80 check listen ingress-https bind *:443 mode tcp server worker-0 worker-0.dgxpod.nvidia.com:443 check server worker-1 worker-1.dgxpod.nvidia.com:443 check listen api bind *:6443 mode tcp server bootstrap bootstrap.dgxpod.nvidia.com:6443 check server master-0 master-0.dgxpod.nvidia.com:6443 check server master-1 master-1.dgxpod.nvidia.com:6443 check server master-2 master-2.dgxpod.nvidia.com:6443 check listen machine-config-server bind *:22623 mode tcp server bootstrap bootstrap.dgxpod.nvidia.com:22623 check server master-0 master-0.dgxpod.nvidia.com:22623 check server master-1 master-1.dgxpod.nvidia.com:22623 check server master-2 master-2.dgxpod.nvidia.com:22623 check

創(chuàng)建引導(dǎo)節(jié)點和主節(jié)點

virt install 命令允許輕松部署引導(dǎo)和主節(jié)點。 節(jié)點名稱 應(yīng)替換為節(jié)點的實際名稱， 節(jié)點 MAC 應(yīng)替換為節(jié)點的相應(yīng)網(wǎng)絡(luò)地址（ MAC ）。

virt-install --connect qemu:///system --name --ram 8192 --vcpus 4 --os-type=linux --os-variant=virtio26 --disk path=/var/lib/libvirt/images/.qcow2,device=disk,bus=virtio,format=qcow2,size=20 --pxe --network bridge=virbr0 -m --graphics vnc,listen=0.0.0.0 --noautoconsole

初始安裝完成后，虛擬機退出，必須手動重新啟動。可以使用打印所有活動虛擬機的sudo virsh list監(jiān)視虛擬機的狀態(tài)。重新啟動virsh start 節(jié)點時virsh start 會再次重新啟動virsh start 節(jié)點。

假設(shè)設(shè)置和配置正確，集群的整個安裝過程應(yīng)該不到一個小時。可以使用以下命令監(jiān)視初始引導(dǎo)進程。

openshift-install --dir wait-for bootstrap-complete

引導(dǎo)完成后，可以刪除引導(dǎo)節(jié)點。接下來，等待整個安裝過程完成，使用：

openshift-install --dir wait-for install-complete

安裝程序的預(yù)發(fā)布版本有時報告錯誤，但最終成功完成。因為它也沒有自動批準(zhǔn)掛起的證書（ CSR ），所以我們添加了以下 crontab 條目，每 10 分鐘運行一次。

*/10 * * * * dgxuser oc get csr -ojson | jq -r '.items[] | select(.status == {} ) | .metadata.name' | xargs oc adm certificate approve

GPU 支持

NVIDIA 和 Red Hat 繼續(xù)合作，為部署和管理 GPU 驅(qū)動程序提供了一個簡單明了的機制。 節(jié)點特征發(fā)現(xiàn)操作符 （ NFD ）和 GPU 算子為這種改進的機制奠定了基礎(chǔ)，并且可以從胡德帽操作中心獲得。這允許隨時部署和優(yōu)化軟件堆棧。以下說明描述了安裝這些操作器的手動步驟。

NFD 檢測 OpenShift 集群中的硬件特性和配置，例如 CPU 類型和擴展，或者在我們的例子中是 NVIDIA GPUs 。

git clone h?ttps://github.com/openshift/cluster-nfd-operator
cd cluster-nfd-operator/manifests
oc create -f .
oc create -f cr/nfd_cr.yaml

安裝完成后， NVIDIA GPU 應(yīng)該會出現(xiàn)在 worker 節(jié)點的特性列表中；最終的軟件將提供一個人類可讀的名稱，而不是供應(yīng)商 ID （0x10de表示 NVIDIA ）。

oc describe node worker-0|grep 10de feature.node.kubernetes.io/pci-10de.present=true

特種資源運營商 （ SRO ）為加速卡提供了一個模板。當(dāng)檢測到組件并安裝正確的驅(qū)動程序和其他軟件組件時，它將激活。

特殊資源運營商的開發(fā)版本已經(jīng)包含了對 NVIDIA GPUs 的支持，并將在可用時并入 NVIDIA GPU 運營商。它管理所有必需的 NVIDIA 驅(qū)動程序和軟件組件的安裝過程。

git clone https://github.com/zvonkok/special-resource-operator
cd special-resource-operator/manifests
oc create -f .
cd cr
oc create -f sro_cr_sched_none.yaml

以下nvidia-smi.yamlfile defines a Kubernetes Pod that can be used for a quick validation. It allocates a single GPU and runsthenvidia-smicommand.

apiVersion: v1
kind: Pod
metadata: name: nvidia-smi
spec: containers: - image: nvidia/cuda name: nvidia-smi command: [ nvidia-smi ] resources: limits: nvidia.com/gpu: 1 requests: nvidia.com/gpu: 1

oc create -f nvidia-smi.yaml腳本創(chuàng)建并運行 pod 。要監(jiān)視 pod 創(chuàng)建的進度，請使用oc describe pod nvidia-smi。完成后，可以使用oc logs nvidia-smi查看oc logs nvidia-smi-smi 命令的輸出：

+-----------------------------------------------------------------------------+
| NVIDIA-SMI 418.56 Driver Version: 418.56 CUDA Version: 10.1 |
|-------------------------------+----------------------+----------------------+
| GPU Name Persistence-M| Bus-Id Disp.A | Volatile Uncorr. ECC |
| Fan Temp Perf Pwr:Usage/Cap| Memory-Usage | GPU-Util Compute M. |
|===============================+======================+======================|
| 0 Tesla V100-SXM2... On | 00000000:86:00.0 Off | 0 |
| N/A 36C P0 41W / 300W | 0MiB / 16130MiB | 1% Default |
+-------------------------------+----------------------+----------------------+ +-----------------------------------------------------------------------------+
| Processes: GPU Memory |
| GPU PID Type Process name Usage |
|=============================================================================|
| No running processes found |
+-----------------------------------------------------------------------------+

最后，可以使用 oc delete pod nvidia-smi 刪除 pod 。

結(jié)論

引入運營商和構(gòu)建在 Red Hat Enterprise Linux CoreOS 之上的不可變基礎(chǔ)設(shè)施，為 OpenShift 4 帶來了令人興奮的改進。它簡化了多節(jié)點大規(guī)模 GPU 加速數(shù)據(jù)中心的優(yōu)化軟件堆棧的部署和管理。這些新功能現(xiàn)在看起來相當(dāng)可靠，我們認(rèn)為客戶將來會很樂意使用它們的。

關(guān)于作者

Chris Zankel 是 NVIDIA DGX 系統(tǒng)軟件的高級產(chǎn)品經(jīng)理。作為一名工程師轉(zhuǎn)為產(chǎn)品經(jīng)理，他擁有從嵌入式設(shè)備到大型企業(yè)系統(tǒng)的經(jīng)驗。在過去的工作中，他積極為 Linux 內(nèi)核做出貢獻，并致力于存儲、虛擬化和容器化

審核編輯：郭婷