作者 | 車漾 阿里巴巴高級(jí)技術(shù)專家

本文整理自《CNCF x Alibaba 云原生技術(shù)公開課》第 20 講。

關(guān)注“阿里巴巴云原生”公眾號(hào)，回復(fù)關(guān)鍵詞**“入門”**，即可下載從零入門 K8s 系列文章 PPT。

導(dǎo)讀：2016 年，隨著 AlphaGo 的走紅和 TensorFlow 項(xiàng)目的異軍突起，一場(chǎng)名為 AI 的技術(shù)革命迅速從學(xué)術(shù)圈蔓延到了工業(yè)界，所謂 AI 革命從此拉開了帷幕。該熱潮的背后推手正是云計(jì)算的普及和算力的巨大提升。

需求來源

經(jīng)過近幾年的發(fā)展，AI 有了許許多多的落地場(chǎng)景，包括智能客服、人臉識(shí)別、機(jī)器翻譯、以圖搜圖等功能。其實(shí)機(jī)器學(xué)習(xí)或者說是人工智能，并不是什么新鮮的概念。而這次熱潮的背后，云計(jì)算的普及以及算力的巨大提升，才是真正將人工智能從象牙塔帶到工業(yè)界的一個(gè)重要推手。

與之相對(duì)應(yīng)的，從 2016 年開始，Kubernetes 社區(qū)就不斷收到來自不同渠道的大量訴求：希望能在 Kubernetes 集群上運(yùn)行 TensorFlow 等機(jī)器學(xué)習(xí)框架。這些訴求中，除了之前文章所介紹的，像 Job 這些離線任務(wù)的管理之外，還有一個(gè)巨大的挑戰(zhàn)：深度學(xué)習(xí)所依賴的異構(gòu)設(shè)備及英偉達(dá)的 GPU 支持。

我們不禁好奇起來：Kubernetes 管理 GPU 能帶來什么好處呢？

本質(zhì)上是成本和效率的考慮。由于相對(duì) CPU 來說，GPU 的成本偏高。在云上單 CPU 通常是一小時(shí)幾毛錢，而 GPU 的花費(fèi)則是從單 GPU 每小時(shí) 10 元 ~ 30 元不等，這就要想方設(shè)法的提高 GPU 的使用率。

為什么要用 Kubernetes 管理以 GPU 為代表的異構(gòu)資源？

具體來說是三個(gè)方面：

• 加速部署：通過容器構(gòu)想避免重復(fù)部署機(jī)器學(xué)習(xí)復(fù)雜環(huán)境；
• 提升集群資源使用率：統(tǒng)一調(diào)度和分配集群資源；
• 保障資源獨(dú)享：利用容器隔離異構(gòu)設(shè)備，避免互相影響。

首先是加速部署，避免把時(shí)間浪費(fèi)在環(huán)境準(zhǔn)備的環(huán)節(jié)中。通過容器鏡像技術(shù)，將整個(gè)部署過程進(jìn)行固化和復(fù)用，如果同學(xué)們關(guān)注機(jī)器學(xué)習(xí)領(lǐng)域，可以發(fā)現(xiàn)許許多多的框架都提供了容器鏡像。我們可以借此提升 GPU 的使用效率。

通過分時(shí)復(fù)用，來提升 GPU 的使用效率。當(dāng) GPU 的卡數(shù)達(dá)到一定數(shù)量后，就需要用到 Kubernetes 的統(tǒng)一調(diào)度能力，使得資源使用方能夠做到用即申請(qǐng)、完即釋放，從而盤活整個(gè) GPU 的資源池。

而此時(shí)還需要通過 Docker 自帶的設(shè)備隔離能力，避免不同應(yīng)用的進(jìn)程運(yùn)行同一個(gè)設(shè)備上，造成互相影響。在高效低成本的同時(shí)，也保障了系統(tǒng)的穩(wěn)定性。

GPU 的容器化

上面了解到了通過 Kubernetes 運(yùn)行 GPU 應(yīng)用的好處，通過之前系列文章的學(xué)習(xí)也知道，Kubernetes 是容器調(diào)度平臺(tái)，而其中的調(diào)度單元是容器，所以在學(xué)習(xí)如何使用 Kubernetes 之前，我們先了解一下如何在容器環(huán)境內(nèi)運(yùn)行 GPU 應(yīng)用。

1. 容器環(huán)境下使用 GPU 應(yīng)用

在容器環(huán)境下使用 GPU 應(yīng)用，實(shí)際上不復(fù)雜。主要分為兩步：

• 構(gòu)建支持 GPU 的容器鏡像；
• 利用 Docker 將該鏡像運(yùn)行起來，并且把 GPU 設(shè)備和依賴庫映射到容器中。

2. 如何準(zhǔn)備 GPU 容器鏡像

有兩個(gè)方法準(zhǔn)備：

• 直接使用官方深度學(xué)習(xí)容器鏡像

比如直接從 docker.hub 或者阿里云鏡像服務(wù)中尋找官方的 GPU 鏡像，包括像 TensorFlow、Caffe、PyTorch 等流行的機(jī)器學(xué)習(xí)框架，都有提供標(biāo)準(zhǔn)的鏡像。這樣的好處是簡(jiǎn)單便捷，而且安全可靠。

• 基于 Nvidia 的 CUDA 鏡像基礎(chǔ)構(gòu)建

當(dāng)然如果官方鏡像無法滿足需求時(shí)，比如你對(duì) TensorFlow 框架進(jìn)行了定制修改，就需要重新編譯構(gòu)建自己的 TensorFlow 鏡像。這種情況下，我們的最佳實(shí)踐是：依托于 Nvidia 官方鏡像繼續(xù)構(gòu)建，而不要從頭開始。

如下圖中的 TensorFlow 例子所示，這個(gè)就是以 Cuda 鏡像為基礎(chǔ)，開始構(gòu)建自己的 GPU 鏡像。

3. GPU 容器鏡像原理

要了解如何構(gòu)建 GPU 容器鏡像，先要知道如何要在宿主機(jī)上安裝 GPU 應(yīng)用。

如下圖左邊所示，最底層是先安裝 Nvidia 硬件驅(qū)動(dòng)；再到上面是通用的 Cuda 工具庫；最上層是 PyTorch、TensorFlow 這類的機(jī)器學(xué)習(xí)框架。

上兩層的 CUDA 工具庫和應(yīng)用的耦合度較高，應(yīng)用版本變動(dòng)后，對(duì)應(yīng)的 CUDA 版本大概率也要更新；而最下層的 Nvidia 驅(qū)動(dòng)，通常情況下是比較穩(wěn)定的，它不會(huì)像 CUDA 和應(yīng)用一樣，經(jīng)常更新。

同時(shí) Nvidia 驅(qū)動(dòng)需要內(nèi)核源碼編譯，如上圖右側(cè)所示，英偉達(dá)的 GPU 容器方案是：在宿主機(jī)上安裝 Nvidia 驅(qū)動(dòng)，而在 CUDA 以上的軟件交給容器鏡像來做。同時(shí)把 Nvidia 驅(qū)動(dòng)里面的鏈接以 Mount Bind 的方式映射到容器中。

這樣的一個(gè)好處是：當(dāng)你安裝了一個(gè)新的 Nvidia 驅(qū)動(dòng)之后，你就可以在同一個(gè)機(jī)器節(jié)點(diǎn)上運(yùn)行不同版本的 CUDA 鏡像了。

4. 如何利用容器運(yùn)行 GPU 程序

有了前面的基礎(chǔ)，我們就比較容易理解 GPU 容器的工作機(jī)制。下圖是一個(gè)使用 Docker 運(yùn)行 GPU 容器的例子。

我們可以觀察到，在運(yùn)行時(shí)刻一個(gè) GPU 容器和普通容器之間的差別，僅僅在于需要將宿主機(jī)的設(shè)備和 Nvidia 驅(qū)動(dòng)庫映射到容器中。

上圖右側(cè)反映了 GPU 容器啟動(dòng)后，容器中的 GPU 配置。右上方展示的是設(shè)備映射的結(jié)果，右下方顯示的是驅(qū)動(dòng)庫以 Bind 方式映射到容器后，可以看到的變化。

通常大家會(huì)使用 Nvidia-docker 來運(yùn)行 GPU 容器，而 Nvidia-docker 的實(shí)際工作就是來自動(dòng)化做這兩個(gè)工作。其中掛載設(shè)備比較簡(jiǎn)單，而真正比較復(fù)雜的是 GPU 應(yīng)用依賴的驅(qū)動(dòng)庫。

對(duì)于深度學(xué)習(xí)，視頻處理等不同場(chǎng)景，所使用的一些驅(qū)動(dòng)庫并不相同。這又需要依賴 Nvidia 的領(lǐng)域知識(shí)，而這些領(lǐng)域知識(shí)就被貫穿到了 Nvidia 的容器之中。

Kubernetes 的 GPU 管理

1. 如何部署 GPU Kubernetes

首先看一下如何給一個(gè) Kubernetes 節(jié)點(diǎn)增加 GPU 能力，我們以 CentOS 節(jié)點(diǎn)為例。

如上圖所示：

• 首先安裝 Nvidia 驅(qū)動(dòng)

由于 Nvidia 驅(qū)動(dòng)需要內(nèi)核編譯，所以在安裝 Nvidia 驅(qū)動(dòng)之前需要安裝 gcc 和內(nèi)核源碼。

• 第二步通過 yum 源，安裝 Nvidia Docker2

安裝完 Nvidia Docker2 需要重新加載 docker，可以檢查 docker 的 daemon.json 里面默認(rèn)啟動(dòng)引擎已經(jīng)被替換成了 nvidia，也可以通過 docker info 命令查看運(yùn)行時(shí)刻使用的 runC 是不是 Nvidia 的 runC。

• 第三步是部署 Nvidia Device Plugin

從 Nvidia 的 git repo 下去下載 Device Plugin 的部署聲明文件，并且通過 kubectl create 命令進(jìn)行部署。

這里 Device Plugin 是以 deamonset 的方式進(jìn)行部署的。這樣我們就知道，如果需要排查一個(gè) Kubernetes 節(jié)點(diǎn)無法調(diào)度 GPU 應(yīng)用的問題，需要從這些模塊開始入手，比如我要查看一下 Device Plugin 的日志，Nvidia 的 runC 是否配置為 docker 默認(rèn) runC 以及 Nvidia 驅(qū)動(dòng)是否安裝成功。

2. 驗(yàn)證部署 GPU Kubernetes 結(jié)果

當(dāng) GPU 節(jié)點(diǎn)部署成功后，我們可以從節(jié)點(diǎn)的狀態(tài)信息中發(fā)現(xiàn)相關(guān)的 GPU 信息。

• 一個(gè)是 GPU 的名稱，這里是 nvidia.com/gpu；
• 另一個(gè)是它對(duì)應(yīng)的數(shù)量，如下圖所示是 2，表示在該節(jié)點(diǎn)中含有兩個(gè) GPU。
  

3. 在 Kubernetes 中使用 GPU 的 yaml 樣例

站在用戶的角度，在 Kubernetes 中使用 GPU 容器還是非常簡(jiǎn)單的。

只需要在 Pod 資源配置的 limit 字段中指定 nvidia.com/gpu 使用 GPU 的數(shù)量，如下圖樣例中我們?cè)O(shè)置的數(shù)量為 1；然后再通過 kubectl create 命令將 GPU 的 Pod 部署完成。

4. 查看運(yùn)行結(jié)果

部署完成后可以登錄到容器中執(zhí)行 nvidia-smi 命令觀察一下結(jié)果，可以看到在該容器中使用了一張 T4 的 GPU 卡。說明在該節(jié)點(diǎn)中的兩張 GPU 卡其中一張已經(jīng)能在該容器中使用了，但是節(jié)點(diǎn)的另外一張卡對(duì)于改容器來說是完全透明的，它是無法訪問的，這里就體現(xiàn)了 GPU 的隔離性。

工作原理

1. 通過擴(kuò)展的方式管理 GPU 資源

Kubernetes 本身是通過插件擴(kuò)展的機(jī)制來管理 GPU 資源的，具體來說這里有兩個(gè)獨(dú)立的內(nèi)部機(jī)制。

• 第一個(gè)是 Extend Resources，允許用戶自定義資源名稱。而該資源的度量是整數(shù)級(jí)別，這樣做的目的在于通過一個(gè)通用的模式支持不同的異構(gòu)設(shè)備，包括 RDMA、FPGA、AMD GPU 等等，而不僅僅是為 Nvidia GPU 設(shè)計(jì)的；

• Device Plugin Framework 允許第三方設(shè)備提供商以外置的方式對(duì)設(shè)備進(jìn)行全生命周期的管理，而 Device Plugin Framework 建立 Kubernetes 和 Device Plugin 模塊之間的橋梁。它一方面負(fù)責(zé)設(shè)備信息的上報(bào)到 Kubernetes，另一方面負(fù)責(zé)設(shè)備的調(diào)度選擇。

2. Extended Resource 的上報(bào)

Extend Resources 屬于 Node-level 的 api，完全可以獨(dú)立于 Device Plugin 使用。而上報(bào) Extend Resources，只需要通過一個(gè) PACTH API 對(duì) Node 對(duì)象進(jìn)行 status 部分更新即可，而這個(gè) PACTH 操作可以通過一個(gè)簡(jiǎn)單的 curl 命令來完成。這樣，在 Kubernetes 調(diào)度器中就能夠記錄這個(gè)節(jié)點(diǎn)的 GPU 類型，它所對(duì)應(yīng)的資源數(shù)量是 1。

當(dāng)然如果使用的是 Device Plugin，就不需要做這個(gè) PACTH 操作，只需要遵從 Device Plugin 的編程模型，在設(shè)備上報(bào)的工作中 Device Plugin 就會(huì)完成這個(gè)操作。

3. Device Plugin 工作機(jī)制

介紹一下 Device Plugin 的工作機(jī)制，整個(gè) Device Plugin 的工作流程可以分成兩個(gè)部分：

• 一個(gè)是啟動(dòng)時(shí)刻的資源上報(bào)；
• 另一個(gè)是用戶使用時(shí)刻的調(diào)度和運(yùn)行。

Device Plugin 的開發(fā)非常簡(jiǎn)單。主要包括最關(guān)注與最核心的兩個(gè)事件方法：

• 其中 ListAndWatch 對(duì)應(yīng)資源的上報(bào)，同時(shí)還提供健康檢查的機(jī)制。當(dāng)設(shè)備不健康的時(shí)候，可以上報(bào)給 Kubernetes 不健康設(shè)備的 ID，讓 Device Plugin Framework 將這個(gè)設(shè)備從可調(diào)度設(shè)備中移除；

• 而 Allocate 會(huì)被 Device Plugin 在部署容器時(shí)調(diào)用，傳入的參數(shù)核心就是容器會(huì)使用的設(shè)備 ID，返回的參數(shù)是容器啟動(dòng)時(shí)，需要的設(shè)備、數(shù)據(jù)卷以及環(huán)境變量。

4. 資源上報(bào)和監(jiān)控

對(duì)于每一個(gè)硬件設(shè)備，都需要它所對(duì)應(yīng)的 Device Plugin 進(jìn)行管理，這些 Device Plugin 以客戶端的身份通過 GRPC 的方式對(duì) kubelet 中的 Device Plugin Manager 進(jìn)行連接，并且將自己監(jiān)聽的 Unis socket api 的版本號(hào)和設(shè)備名稱比如 GPU，上報(bào)給 kubelet。

我們來看一下 Device Plugin 資源上報(bào)的整個(gè)流程。總的來說，整個(gè)過程分為四步，其中前三步都是發(fā)生在節(jié)點(diǎn)上，第四步是 kubelet 和 api-server 的交互。

• 第一步是 Device Plugin 的注冊(cè)，需要 Kubernetes 知道要跟哪個(gè) Device Plugin 進(jìn)行交互。這是因?yàn)橐粋€(gè)節(jié)點(diǎn)上可能有多個(gè)設(shè)備，需要 Device Plugin 以客戶端的身份向 Kubelet 匯報(bào)三件事情：我是誰？就是 Device Plugin 所管理的設(shè)備名稱，是 GPU 還是 RDMA；我在哪？就是插件自身監(jiān)聽的 unis socket 所在的文件位置，讓 kubelet 能夠調(diào)用自己；交互協(xié)議，即 API 的版本號(hào)；

• 第二步是服務(wù)啟動(dòng)，Device Plugin 會(huì)啟動(dòng)一個(gè) GRPC 的 server。在此之后 Device Plugin 一直以這個(gè)服務(wù)器的身份提供服務(wù)讓 kubelet 來訪問，而監(jiān)聽地址和提供 API 的版本就已經(jīng)在第一步完成了；

• 第三步，當(dāng)該 GRPC server 啟動(dòng)之后，kubelet 會(huì)建立一個(gè)到 Device Plugin 的 ListAndWatch 的長連接， 用來發(fā)現(xiàn)設(shè)備 ID 以及設(shè)備的健康狀態(tài)。當(dāng) Device Plugin 檢測(cè)到某個(gè)設(shè)備不健康的時(shí)候，就會(huì)主動(dòng)通知 kubelet。而此時(shí)如果這個(gè)設(shè)備處于空閑狀態(tài)，kubelet 會(huì)將其移除可分配的列表。但是當(dāng)這個(gè)設(shè)備已經(jīng)被某個(gè) Pod 所使用的時(shí)候，kubelet 就不會(huì)做任何事情，如果此時(shí)殺掉這個(gè) Pod 是一個(gè)很危險(xiǎn)的操作；

• 第四步，kubelet 會(huì)將這些設(shè)備暴露到 Node 節(jié)點(diǎn)的狀態(tài)中，把設(shè)備數(shù)量發(fā)送到 Kubernetes 的 api-server 中。后續(xù)調(diào)度器可以根據(jù)這些信息進(jìn)行調(diào)度。

需要注意的是 kubelet 在向 api-server 進(jìn)行匯報(bào)的時(shí)候，只會(huì)匯報(bào)該 GPU 對(duì)應(yīng)的數(shù)量。而 kubelet 自身的 Device Plugin Manager 會(huì)對(duì)這個(gè) GPU 的 ID 列表進(jìn)行保存，并用來具體的設(shè)備分配。而這個(gè)對(duì)于 Kubernetes 全局調(diào)度器來說，它不掌握這個(gè) GPU 的 ID 列表，它只知道 GPU 的數(shù)量。

這就意味著在現(xiàn)有的 Device Plugin 工作機(jī)制下，Kubernetes 的全局調(diào)度器無法進(jìn)行更復(fù)雜的調(diào)度。比如說想做兩個(gè) GPU 的親和性調(diào)度，同一個(gè)節(jié)點(diǎn)兩個(gè) GPU 可能需要進(jìn)行通過 NVLINK 通訊而不是 PCIe 通訊，才能達(dá)到更好的數(shù)據(jù)傳輸效果。在這種需求下，目前的 Device Plugin 調(diào)度機(jī)制中是無法實(shí)現(xiàn)的。

5. Pod 的調(diào)度和運(yùn)行的過程

Pod 想使用一個(gè) GPU 的時(shí)候，它只需要像之前的例子一樣，在 Pod 的 Resource 下 limits 字段中聲明 GPU 資源和對(duì)應(yīng)的數(shù)量 (比如nvidia.com/gpu: 1)。Kubernetes 會(huì)找到滿足數(shù)量條件的節(jié)點(diǎn)，然后將該節(jié)點(diǎn)的 GPU 數(shù)量減 1，并且完成 Pod 與 Node 的綁定。

綁定成功后，自然就會(huì)被對(duì)應(yīng)節(jié)點(diǎn)的 kubelet 拿來創(chuàng)建容器。而當(dāng) kubelet 發(fā)現(xiàn)這個(gè) Pod 的容器請(qǐng)求的資源是一個(gè) GPU 的時(shí)候，kubelet 就會(huì)委托自己內(nèi)部的 Device Plugin Manager 模塊，從自己持有的 GPU 的 ID 列表中選擇一個(gè)可用的 GPU 分配給該容器。

此時(shí) kubelet 就會(huì)向本機(jī)的 DeAvice Plugin 發(fā)起一個(gè) Allocate 請(qǐng)求，這個(gè)請(qǐng)求所攜帶的參數(shù)，正是即將分配給該容器的設(shè)備 ID 列表。

Device Plugin 收到 AllocateRequest 請(qǐng)求之后，它就會(huì)根據(jù) kubelet 傳過來的設(shè)備 ID，去尋找這個(gè)設(shè)備 ID 對(duì)應(yīng)的設(shè)備路徑、驅(qū)動(dòng)目錄以及環(huán)境變量，并且以 AllocateResponse 的形式返還給 kubelet。

AllocateResponse 中所攜帶的設(shè)備路徑和驅(qū)動(dòng)目錄信息，一旦返回給 kubelet 之后，kubelet 就會(huì)根據(jù)這些信息執(zhí)行為容器分配 GPU 的操作，這樣 Docker 會(huì)根據(jù) kubelet 的指令去創(chuàng)建容器，而這個(gè)容器中就會(huì)出現(xiàn) GPU 設(shè)備。并且把它所需要的驅(qū)動(dòng)目錄給掛載進(jìn)來，至此 Kubernetes 為 Pod 分配一個(gè) GPU 的流程就結(jié)束了。

本文思考與實(shí)踐

1. 本文總結(jié)

在本文中，我們一起學(xué)習(xí)了在 Docker 和 Kubernetes 上使用 GPU。

• GPU 的容器化：如何去構(gòu)建一個(gè) GPU 鏡像；如何直接在 Docker 上運(yùn)行 GPU 容器；

• 利用 Kubernetes 管理 GPU 資源：如何在 Kubernetes 支持 GPU 調(diào)度；如何驗(yàn)證 Kubernetes 下的 GPU 配置；調(diào)度 GPU 容器的方法；

• Device Plugin 的工作機(jī)制：資源的上報(bào)和監(jiān)控；Pod 的調(diào)度和運(yùn)行；

• 思考：目前的缺陷；社區(qū)常見的 Device Plugin。

2. Device Plugin 機(jī)制的缺陷

最后我們來思考一個(gè)問題，現(xiàn)在的 Device Plugin 是否完美無缺？

需要指出的是 Device Plugin 整個(gè)工作機(jī)制和流程上，實(shí)際上跟學(xué)術(shù)界和工業(yè)界的真實(shí)場(chǎng)景有比較大的差異。這里最大的問題在于 GPU 資源的調(diào)度工作，實(shí)際上都是在 kubelet 上完成的。

而作為全局的調(diào)度器對(duì)這個(gè)參與是非常有限的，作為傳統(tǒng)的 Kubernetes 調(diào)度器來說，它只能處理 GPU 數(shù)量。一旦你的設(shè)備是異構(gòu)的，不能簡(jiǎn)單地使用數(shù)目去描述需求的時(shí)候，比如我的 Pod 想運(yùn)行在兩個(gè)有 nvlink 的 GPU 上，這個(gè) Device Plugin 就完全不能處理。

更不用說在許多場(chǎng)景上，我們希望調(diào)度器進(jìn)行調(diào)度的時(shí)候，是根據(jù)整個(gè)集群的設(shè)備進(jìn)行全局調(diào)度，這種場(chǎng)景是目前的 Device Plugin 無法滿足的。

更為棘手的是在 Device Plugin 的設(shè)計(jì)和實(shí)現(xiàn)中，像 Allocate 和 ListAndWatch 的 API 去增加可擴(kuò)展的參數(shù)也是沒有作用的。這就是當(dāng)我們使用一些比較復(fù)雜的設(shè)備使用需求的時(shí)候，實(shí)際上是無法通過 Device Plugin 來擴(kuò)展 API 實(shí)現(xiàn)的。

因此目前的 Device Plugin 設(shè)計(jì)涵蓋的場(chǎng)景其實(shí)是非常單一的， 是一個(gè)可用但是不好用的狀態(tài)。這就能解釋為什么像 Nvidia 這些廠商都實(shí)現(xiàn)了一個(gè)基于 Kubernetes 上游代碼進(jìn)行 fork 了自己解決方案，也是不得已而為之。

3. 社區(qū)的異構(gòu)資源調(diào)度方案

• 第一個(gè)是 Nvidia 貢獻(xiàn)的調(diào)度方案，這是最常用的調(diào)度方案；

• 第二個(gè)是由阿里云服務(wù)團(tuán)隊(duì)貢獻(xiàn)的 GPU 共享的調(diào)度方案，其目的在于解決用戶共享 GPU 調(diào)度的需求，歡迎大家一起來使用和改進(jìn)；

• 下面的兩個(gè) RDMA 和 FPGA 是由具體廠商提供的調(diào)度方案。

“阿里巴巴云原生關(guān)注微服務(wù)、Serverless、容器、Service Mesh 等技術(shù)領(lǐng)域、聚焦云原生流行技術(shù)趨勢(shì)、云原生大規(guī)模的落地實(shí)踐，做最懂云原生開發(fā)者的技術(shù)圈。”

總結(jié)

以上是生活随笔為你收集整理的从零开始入门 K8s | GPU 管理和 Device Plugin 工作机制的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。