在 Red Hat OpenShift 中统一多厂商 DPU

数据处理器代表了数据中心架构的一次重大演进。通过将网络、安全和存储等基础设施任务从主 CPU 卸载，它们有望释放出新的云计算能力水平。Red Hat OpenShift 4.20 在解决 DPU 采用的主要挑战——供应商锁定方面，实现了一项重大突破。

这项新功能在单个集群内为不同的 DPU 提供了统一的、与厂商无关的支持。这是我们基于标准的重点战略的成果。我们通过在 Red Hat OpenShift 4.19 中引入对首个 DPU（Intel IPU）的技术预览支持，开始了这段旅程。通过基于 Open Programmable Infrastructure 项目的开放标准，我们在 4.20 版本的工作将支持范围扩展到了另外两款 DPU：Senao SX904 和 Marvell Octeon 10。

这直接解决了行业面临的最大 DPU 挑战：碎片化格局。直到现在，组织仍被迫局限于孤立的、特定于供应商的环境，每个环境都有专有的工具、驱动程序和 API。这种方法消除了这种碎片化。正如我们在 DPU 的云原生赋能 中所讨论的，我们的目标是使 DPU 成为 Red Hat OpenShift 中一个平滑集成且抽象的组件。

异构硬件的统一管理平台

我们的集成工作以标准的 Red Hat OpenShift 集群为中心。关键区别在于工作节点：每个节点都配备了来自不同硬件供应商（包括 Intel 和 Marvell）的 DPU。

通过一个基于 OPI 的通用管理层，OpenShift 能够发现、管理异构硬件并向其部署工作负载。这消除了对供应商特定工具链的需求，并允许运维人员从 OpenShift 平台管理其整个基础设施——从主机 CPU 到 DPU。

通过抽象实现标准化发现

在传统的多供应商环境中，运维人员可能需要使用单独的工具来识别其集群中的硬件。我们的方法将这一过程简化为一个单一的、熟悉的命令。

通过运行 oc get dpu，运维人员可以立即查询集群，并通过 OPI API 接收所有检测到的 DPU、其供应商及其当前运行状态的完整列表。

1
2
3
4
5
6
7
8

$ oc get dpu
NAME                                 DPU PRODUCT                    DPU SIDE        MODE NAME               STATUS
030001163eec00ff-host                Intel Netsec Accelerator       false           worker-host-ptl-243     True
d4-e5-c9-00-ec-3v-dpu                Intel Netsec Accelerator       true            worker-dpu-ptl-243      True
intel-ipu-0000-06-00.0-host          Intel IPU E2100                false           worker-host-ipu-219     True
intel-ipu-dpu                        Intel IPU E2100                true            worker-dpu-ipu-219      True
marvell-dpu-0000-87-00.0-host        Marvell DPU                    false           worker-host-marvell-41  True
marvell-dpu-ipu                      Marvell DPU                    true            worker-dpu-marvell-41   True

这是可能的，因为硬件特定的逻辑被包含在遵循 OPI 标准的供应商特定插件中。底层的复杂性被从用户面前抽象掉了——无论是部署应用程序的开发人员还是管理集群的平台运维人员。OpenShift 只是看到一个可供使用的“DPU”资源池。

虽然这里的输出显示了一个集群中管理的所有 DPU，但我们的基于 Operator 的架构也支持多集群部署（其中 DPU 是单独集群的一部分）。这只是一个部署细节；用户体验和基于 OPI 的管理在这两种模型中保持一致。

使用 Kubernetes 原生原语部署工作负载

这种抽象最显著的好处是能够使用团队已经熟悉的标准声明式工具来部署工作负载。当集群准备好接受工作负载时，跨 DPU 部署和移动工作负载就变得很直接。

无需学习专有的 SDK 或为每个 DPU 编写自定义脚本。我们可以使用标准的 Kubernetes YAML 文件直接将容器化工作负载部署到任何 DPU。唯一需要的区别是使用简单的 nodeSelector 来指定在哪个 DPU 上运行；无论供应商细节如何，系统都将相应地调度工作负载。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

apiVersion: v1
kind: Pod
metadata:
-  name: "intel-netsec-accelerator-pod"
+  name: "marvell-dpu-pod"
   namespace: openshift-dpu-operator
...
-    kubernetes.io/hostname: worker-dpu-ptl-243
+    kubernetes.io/hostname: worker-dpu-marvell-41
     dpu.config.openshift.io/dpuside: "dpu"

这将云原生运营模式带到了 DPU 加速的基础设施中。它使开发人员能够像使用集群中的任何其他资源一样使用 DPU 资源，极大地降低了采用门槛。

实现真正的工作负载可移植性和互操作性

这种统一性深入到网络中。OPI 网络 API 允许 OpenShift 构建一个统一的数据平面覆盖网络，该网络跨越所有 DPU（无论供应商如何）以及主机节点。

这创建了一个流线型、可编程的网络，所有工作负载都可以在其中通信。运行在一个供应商 DPU 上的 Pod 可以直接与运行在另一个供应商 DPU 上的 Pod 通信。在下面的图表中，绿色和蓝色的 Pod 属于同一个网络。这展示了真正的工作负载可移植性，同样重要的是，互操作性，允许所有 Pod 自由通信。

这对 Red Hat 客户意味着什么

这项能力是我们 Red Hat OpenShift 上 DPU 卸载基础设施战略的基础。

我们的计划是继续扩展这种支持，将每个 DPU 供应商的独特优势和加速器集成到 OpenShift 平台中。

目标很简单：提供一个向 DPU 集群的流线型过渡，而无需供应商锁定。这种统一的、基于 Operator 的方法意味着您可以先从一个没有 DPU 的 OpenShift 集群开始，然后在您准备好时随时将 DPU 添加到工作节点中。

我们承担了抽象硬件级复杂性的繁重工作，因此您可以专注于您的应用程序，而不是供应商特定的驱动程序或专有 SDK。在我们将这些功能从技术预览版推向正式发布版的过程中，我们正在积极与客户和合作伙伴合作。

如果您正在运行 OpenShift 4.20 或更高版本，并且刚刚开始您的 DPU 之旅，或者希望摆脱现有的供应商锁定，现在是时候与 Red Hat 合作了。无需从头开始重新安装或重新架构您的集群，即可开始利用 DPU 技术。看看这个统一平台如何简化您的基础设施路线图，并允许您按照自己的节奏发展您的集群。