Red Hat OpenShift 是一个企业级 Kubernetes 平台，用于大规模管理 Kubernetes 集群，由 Red Hat 开发和支持。它提供了一种方法来改变组织如何在本地以及跨混合云管理复杂的基础设施
人工智能计算给现代商业带来了深远的变革，包括金融服务中的欺诈检测以及娱乐和电子商务的推荐引擎。 2018 年 CTA 市场研究报告显示，与不采用人工智能的公司相比，将人工智能技术作为公司战略核心的公司的利润率提高了 15% 。
为这些新的、大量计算密集型的工作负载提供基础设施的责任落在了 IT 的肩上，许多组织都在为 AI 部署 IT 认可的基础设施所带来的复杂性、时间和成本上苦苦挣扎。多达 40% 的希望部署人工智能的组织将基础设施视为主要障碍。为人工智能工作负载部署集群通常会在网络拓扑、计算和存储资源的规模确定等方面提出问题。 NVIDIA 因此为典型应用创建了参考架构，以减轻猜测。
例如 DGX-POD, 它包含了多个 DGX-1 系统及来自多个供应商的存储系统。 NVIDIA 根据部署在世界上最大的研究和企业环境中的数千个前沿加速计算节点的经验，开发了 DGX POD 。然而，要确保人工智能在规模上取得成功，就需要一个软件平台，如 KubernetesTM ，以确保人工智能基础设施的可管理性。
红帽 OpenShift 4 是一个主要的发行版，它结合了红帽收购 CoreOS 的技术。其核心（不是双关语）是基于 Red Hat Enterprise Linux CoreOS （ RHCOS ）的不可变系统映像。它遵循了一个新的范例，即安装在部署之后永远不会被修改或更新，而是被整个系统映像的更新版本所取代。这就提供了更高的可靠性和一致性，并提供了更可预测的部署过程。
这篇文章首先介绍了 OpenShift 4 和 GPU 操作符在 OpenShift 参考架构上的 AI 工作负载。我们基于一个需要一些手动步骤的软件预览，这将在最终版本中解决。
安装和运行 OpenShift 需要一个 Red Hat 帐户和其他订阅。官方安装说明见 在裸机上安装群集 。
测试设置概述
OpenShift 集群的最小配置包括三个 主人 节点和两个 工人 节点（也称为 计算 节点）。集群的初始设置需要一个额外的 引导 节点，可以在安装过程中删除或重新调整其用途。有三个主节点的要求确保了高可用性（避免了大脑分裂的情况），并允许主节点不间断地升级。
我们在一台 x86 机器上使用虚拟机作为引导和主节点，两个 DGX-1 系统用于计算节点（裸机）。负载平衡器在单独的虚拟机中运行，以将请求分发到节点。使用循环 DNS 也起到了作用，但要正确地配置结果却很棘手。需要将 virsh 网络设置为桥接模式，而不是 NAT ，以便节点可以相互通信（有关详细信息，请参见 Libvirt 网络 ）。
Red Hat OpenShift 4 还没有为裸机系统提供完全自动化的安装方法，但需要外部基础设施来提供和执行初始安装（ OpenShift 文档将其称为 用户提供的基础设施（ UPI ） 。在我们的例子中，我们使用 x86 服务器通过 PXE 引导来配置和引导节点。一旦安装，节点将自动执行升级。
创建系统配置
Red Hat Enterprise Linux CoreOS 使用点火进行系统配置。点火提供了与 cloud init 类似的功能，并允许在第一次引导期间配置系统。
点火文件由 OpenShift 起始页 安装程序从配置文件 install-config.yaml 生成。它通过各种参数描述集群，还包括一个 SSH 密钥和用于从 redhat 容器存储库提取容器的凭据。可以从 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 ...
参数 baseDomain 和 metadata:name 构成集群的域名（ dgxpod.nvidia.com ）。网络参数描述了 OpenShift 集群的内部网络，只有在与外部网络冲突时才需要修改。
以下命令为节点创建点火文件，并为集群创建身份验证文件。因为这些命令删除了 安装 – 组态软件 ，所以我们在 ignition 目录之外保留了它的一个副本。生成的身份验证文件（ ignition/auth/kubeconfig ）应重命名并复制到 $USERHOME/.kube/config
mkdir ignition cp install-config.yaml ignition openshift-install --dir ignition create ignition-configs
DHCP 和 PXE 引导
设置 PXE 引导当然不是一件容易的事；提供详细的说明超出了本文的范围。读者应具备设置 PXE 引导和 DHCP 的知识。以下代码段仅介绍 dnsmasq 的 DNS 配置。
dnsmasq 配置文件中的 address 指令允许使用通配符来解析任何带有负载平衡器地址的*. apps 请求。 SRV 条目允许集群访问 etcd 服务。
# 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
相应的 /etc/hosts.dnsmasq 文件列出了 IP 地址和主机名。注意， OpenShift 要求每个主机的第一个条目是节点名，例如 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 引导配置的示例。它定义内核和初始 ramdisk ，并提供额外的命令行参数。注意，前缀为 coreos 的参数被传递给 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
内核、 initramfs 和 raw 映像可以从 OpenShift 镜像 获得。安装说明 在裸机上安装群集 提供了最新版本和下载路径。应将上一步骤中的映像文件和点火配置复制到 http 目录。请确保为所有这些文件设置了正确的 http SELinux 标签。请注意， DGX-1 系统仅支持 UEFI 进行网络引导，因此需要不同的文件集。
负载平衡器
负载平衡器处理跨在线节点的分布式请求。我们在一个单独的虚拟机中运行 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
创建引导节点和主节点
virt install 命令允许轻松部署引导和主节点。 节点名称 应替换为节点的实际名称， 节点 MAC 应替换为节点的相应网络地址（ 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 监视虚拟机的状态。重新启动 virsh start <NODE-NAME> 节点时 virsh start <NODE-NAME> 会再次重新启动 virsh start <NODE-NAME> 节点。
假设设置和配置正确，集群的整个安装过程应该不到一个小时。可以使用以下命令监视初始引导进程。
openshift-install --dir wait-for bootstrap-complete
引导完成后，可以删除引导节点。接下来，等待整个安装过程完成，使用：
openshift-install --dir wait-for install-complete
安装程序的预发布版本有时报告错误，但最终成功完成。因为它也没有自动批准挂起的证书（ 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 继续合作，为部署和管理 GPU 驱动程序提供了一个简单明了的机制。 节点特征发现操作符 （ NFD ）和 GPU 算子为这种改进的机制奠定了基础，并且可以从胡德帽操作中心获得。这允许随时部署和优化软件堆栈。以下说明描述了安装这些操作器的手动步骤。
NFD 检测 OpenShift 集群中的硬件特性和配置，例如 CPU 类型和扩展，或者在我们的例子中是 NVIDIA GPUs 。
git clone https://github.com/openshift/cluster-nfd-operator cd cluster-nfd-operator/manifests oc create -f . oc create -f cr/nfd_cr.yaml
安装完成后， NVIDIA GPU 应该会出现在 worker 节点的特性列表中；最终的软件将提供一个人类可读的名称，而不是供应商 ID （ 0x10de 表示 NVIDIA ）。
oc describe node worker-0|grep 10de feature.node.kubernetes.io/pci-10de.present=true
特种资源运营商 （ SRO ）为加速卡提供了一个模板。当检测到组件并安装正确的驱动程序和其他软件组件时，它将激活。
特殊资源运营商的开发版本已经包含了对 NVIDIA GPUs 的支持，并将在可用时并入 NVIDIA GPU 运营商。它管理所有必需的 NVIDIA 驱动程序和软件组件的安装过程。
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.yaml file defines a Kubernetes Pod that can be used for a quick validation. It allocates a single GPU and runs the nvidia-smi command.
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 脚本创建并运行 pod 。要监视 pod 创建的进度，请使用 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 。
结论
引入运营商和构建在 Red Hat Enterprise Linux CoreOS 之上的不可变基础设施，为 OpenShift 4 带来了令人兴奋的改进。它简化了多节点大规模 GPU 加速数据中心的优化软件堆栈的部署和管理。这些新功能现在看起来相当可靠，我们认为客户将来会很乐意使用它们的。
