本篇文章為大家展示了如何理解RuntimeClass與 Pod Overhead，內(nèi)容簡(jiǎn)明扼要并且容易理解，絕對(duì)能使你眼前一亮，通過(guò)這篇文章的詳細(xì)介紹希望你能有所收獲。

網(wǎng)站建設(shè)哪家好，找創(chuàng)新互聯(lián)公司！專注于網(wǎng)頁(yè)設(shè)計(jì)、網(wǎng)站建設(shè)、微信開(kāi)發(fā)、微信小程序開(kāi)發(fā)、集團(tuán)企業(yè)網(wǎng)站建設(shè)等服務(wù)項(xiàng)目。為回饋新老客戶創(chuàng)新互聯(lián)還提供了烏達(dá)免費(fèi)建站歡迎大家使用！

一、RuntimeClass 需求來(lái)源

容器運(yùn)行時(shí)的演進(jìn)過(guò)程

我們首先了解一下容器運(yùn)行時(shí)的演進(jìn)過(guò)程，整個(gè)過(guò)程大致分為三個(gè)階段：

• 第一個(gè)階段：2014 年 6 月

Kubernetes 正式開(kāi)源，Docker 是當(dāng)時(shí)唯一的、也是默認(rèn)的容器運(yùn)行時(shí)；

• 第二個(gè)階段：Kubernetes v1.3

rkt 合入 Kubernetes 主干，成為了第二個(gè)容器運(yùn)行時(shí)。

• 第三個(gè)階段：Kubernetes v.15

與此同時(shí)，越來(lái)越多的容器運(yùn)行時(shí)也想接入到 Kubernetes 中。如果還是按 rkt 和 Docker 一樣內(nèi)置支持的話，會(huì)給 Kubernetes 的代碼維護(hù)和質(zhì)量保障帶來(lái)嚴(yán)重挑戰(zhàn)。

社區(qū)也意識(shí)到了這一點(diǎn)，所以在 1.5 版本時(shí)推出了 CRI，它的全稱是 Container Runtime Interface。這樣做的好處是：實(shí)現(xiàn)了運(yùn)行時(shí)和 Kubernetes 的解耦，社區(qū)不必再為各種運(yùn)行時(shí)做適配工作，也不用擔(dān)心運(yùn)行時(shí)和 Kubernetes 迭代周期不一致所帶來(lái)的版本維護(hù)問(wèn)題。比較典型的，比如 containerd 中的 cri-plugin 就實(shí)現(xiàn)了 CRI、kata-containers、gVisor 這樣的容器運(yùn)行時(shí)只需要對(duì)接 containerd 就可以了。

隨著越來(lái)越多的容器運(yùn)行時(shí)的出現(xiàn)，不同的容器運(yùn)行時(shí)也有不同的需求場(chǎng)景，于是就有了多容器運(yùn)行時(shí)的需求。但是，如何來(lái)運(yùn)行多容器運(yùn)行時(shí)還需要解決以下幾個(gè)問(wèn)題：

• 集群里有哪些可用的容器運(yùn)行時(shí)？

• 如何為 Pod 選擇合適的容器運(yùn)行時(shí)？

• 如何讓 Pod 調(diào)度到裝有指定容器運(yùn)行時(shí)的節(jié)點(diǎn)上？

• 容器運(yùn)行時(shí)在運(yùn)行容器時(shí)會(huì)產(chǎn)生有一些業(yè)務(wù)運(yùn)行以外的額外開(kāi)銷，這種「額外開(kāi)銷」需要怎么統(tǒng)計(jì)？

RuntimeClass 的工作流程

為了解決上述提到的問(wèn)題，社區(qū)推出了 RuntimeClass。它其實(shí)在 Kubernetes v1.12 中就已被引入，不過(guò)最初是以 CRD 的形式引入的。v1.14 之后，它又作為一種內(nèi)置集群資源對(duì)象 RuntimeClas 被引入進(jìn)來(lái)。v1.16 又在 v1.14 的基礎(chǔ)上擴(kuò)充了 Scheduling 和 Overhead 的能力。

下面以 v1.16 版本為例，講解一下 RuntimeClass 的工作流程。如上圖所示，左側(cè)是它的工作流程圖，右側(cè)是一個(gè) YAML 文件。

YAML 文件包含兩個(gè)部分：上部分負(fù)責(zé)創(chuàng)建一個(gè)名字叫 runv 的 RuntimeClass 對(duì)象，下部分負(fù)責(zé)創(chuàng)建一個(gè) Pod，該P(yáng)od 通過(guò) spec.runtimeClassName 引用了 runv 這個(gè) RuntimeClass。

RuntimeClass 對(duì)象中比較核心的是 handler，它表示一個(gè)接收創(chuàng)建容器請(qǐng)求的程序，同時(shí)也對(duì)應(yīng)一個(gè)容器運(yùn)行時(shí)。比如示例中的 Pod 最終會(huì)被 runv 容器運(yùn)行時(shí)創(chuàng)建容器；scheduling 決定 Pod 最終會(huì)被調(diào)度到哪些節(jié)點(diǎn)上。

結(jié)合左圖來(lái)說(shuō)明一下 RuntimeClass 的工作流程：

1. K8s-master 接收到創(chuàng)建 Pod 的請(qǐng)求；

2. 方格部分表示三種類型的節(jié)點(diǎn)。每個(gè)節(jié)點(diǎn)上都有 Label 標(biāo)識(shí)當(dāng)前節(jié)點(diǎn)支持的容器運(yùn)行時(shí)，節(jié)點(diǎn)內(nèi)會(huì)有一個(gè)或多個(gè) handler，每個(gè) handler 對(duì)應(yīng)一種容器運(yùn)行時(shí)。比如第二個(gè)方格表示節(jié)點(diǎn)內(nèi)有支持 runc 和 runv 兩種容器運(yùn)行時(shí)的 handler；第三個(gè)方格表示節(jié)點(diǎn)內(nèi)有支持 runhcs 容器運(yùn)行時(shí)的 handler；

3. 根據(jù) scheduling.nodeSelector, Pod 最終會(huì)調(diào)度到中間方格節(jié)點(diǎn)上，并最終由 runv handler 來(lái)創(chuàng)建 Pod。

二、RuntimeClass 功能介紹

RuntimeClass 的結(jié)構(gòu)體定義

我們還是以 Kubernetes v1.16 版本中的 RuntimeClass 為例。首先介紹一下 RuntimeClass 的結(jié)構(gòu)體定義。

一個(gè) RuntimeClass 對(duì)象代表了一個(gè)容器運(yùn)行時(shí)，它的結(jié)構(gòu)體中主要包含 Handler、Overhead、Scheduling 三個(gè)字段。

• 在之前的例子中我們也提到過(guò) Handler，它表示一個(gè)接收創(chuàng)建容器請(qǐng)求的程序，同時(shí)也對(duì)應(yīng)一個(gè)容器運(yùn)行時(shí)；

• Overhead 是 v1.16 中才引入的一個(gè)新的字段，它表示 Pod 中的業(yè)務(wù)運(yùn)行所需資源以外的額外開(kāi)銷；

• 第三個(gè)字段Scheduling 也是在 v1.16 中被引入的，該 Scheduling 配置會(huì)被自動(dòng)注入到 Pod 的 nodeSelector 中。

RuntimeClass 資源定義例子

在 Pod 中引用 RuntimeClass 的用法非常簡(jiǎn)單，只要在 runtimeClassName 字段中配置好 RuntimeClass 的名字，就可以把這個(gè) RuntimeClass 引入進(jìn)來(lái)。

Scheduling 結(jié)構(gòu)體的定義

顧名思義，Scheduling 表示調(diào)度，但這里的調(diào)度不是說(shuō) RuntimeClass 對(duì)象本身的調(diào)度，而是會(huì)影響到引用了 RuntimeClass 的 Pod 的調(diào)度。

Scheduling 中包含了兩個(gè)字段，NodeSelector 和 Tolerations。這兩個(gè)和 Pod 本身所包含的 NodeSelector 和 Tolerations 是極為相似的。

NodeSelector 代表的是支持該 RuntimeClass 的節(jié)點(diǎn)上應(yīng)該有的 label 列表。一個(gè) Pod 引用了該 RuntimeClass 后，RuntimeClass admission 會(huì)把該 label 列表與 Pod 中的 label 列表做一次合并。如果這兩個(gè) label 中有沖突的，會(huì)被 admission 拒絕。這里的沖突是指它們的 key 相同，但是 value 不相同，這種情況就會(huì)被 admission 拒絕。另外需要注意的是，RuntimeClass 并不會(huì)自動(dòng)為 Node 設(shè)置 label，需要用戶在使用前提前設(shè)置好。

Tolerations 表示 RuntimeClass 的容忍列表。一個(gè) Pod 引用該 RuntimeClass 之后，admission 也會(huì)把 toleration 列表與 Pod 中的 toleration 列表做一個(gè)合并。如果這兩處的 Toleration 有相同的容忍配置，就會(huì)將其合并成一個(gè)。

為什么引入 Pod Overhead？

上圖左邊是一個(gè) Docker Pod，右邊是一個(gè) Kata Pod。我們知道，Docker Pod 除了傳統(tǒng)的 container 容器之外，還有一個(gè) pause 容器，但我們?cè)谟?jì)算它的容器開(kāi)銷的時(shí)候會(huì)忽略 pause 容器。對(duì)于 Kata Pod，除了 container 容器之外，kata-agent, pause, guest-kernel 這些開(kāi)銷都是沒(méi)有被統(tǒng)計(jì)進(jìn)來(lái)的。像這些開(kāi)銷，多的時(shí)候甚至能超過(guò) 100MB，這些開(kāi)銷我們是沒(méi)法忽略的。

這就是我們引入 Pod Overhead 的初衷。它的結(jié)構(gòu)體定義如下：

它的定義非常簡(jiǎn)單，只有一個(gè)字段 PodFixed。它這里面也是一個(gè)映射，它的 key 是一個(gè) ResourceName，value 是一個(gè) Quantity。每一個(gè) Quantity 代表的是一個(gè)資源的使用量。因此 PodFixed 就代表了各種資源的占用量，比如 CPU、內(nèi)存的占用量，都可以通過(guò) PodFixed 進(jìn)行設(shè)置。

Pod Overhead 的使用場(chǎng)景與限制

Pod Overhead 的使用場(chǎng)景主要有三處：

• Pod 調(diào)度

在沒(méi)有引入 Overhead 之前，只要一個(gè)節(jié)點(diǎn)的資源可用量大于等于 Pod 的 requests 時(shí)，這個(gè) Pod 就可以被調(diào)度到這個(gè)節(jié)點(diǎn)上。引入 Overhead 之后，只有節(jié)點(diǎn)的資源可用量大于等于 Overhead 加上 requests 的值時(shí)才能被調(diào)度上來(lái)。

• ResourceQuota

它是一個(gè) namespace 級(jí)別的資源配額。假設(shè)我們有這樣一個(gè) namespace，它的內(nèi)存使用量是 1G，我們有一個(gè) requests 等于 500 的 Pod，那么這個(gè) namespace 之下，最多可以調(diào)度兩個(gè)這樣的 Pod。而如果我們?yōu)檫@兩個(gè) Pod 增添了 200MB 的 Overhead 之后，這個(gè) namespace 下就最多只可調(diào)度一個(gè)這樣的 Pod。

• Kubelet Pod 驅(qū)逐

引入 Overhead 之后，Overhead 就會(huì)被統(tǒng)計(jì)到節(jié)點(diǎn)的已使用資源中，從而增加已使用資源的占比，最終會(huì)影響到 Kubelet Pod 的驅(qū)逐。

以上是 Pod Overhead 的使用場(chǎng)景。除此之外，Pod Overhead 還有一些使用限制和注意事項(xiàng)：

• Pod Overhead 最終會(huì)永久注入到 Pod 內(nèi)并且不可手動(dòng)更改。即便是將 RuntimeClass 刪除或者更新，Pod Overhead 依然存在并且有效；

• Pod Overhead 只能由 RuntimeClass admission 自動(dòng)注入（至少目前是這樣的），不可手動(dòng)添加或更改。如果這么做，會(huì)被拒絕；

• HPA 和 VPA 是基于容器級(jí)別指標(biāo)數(shù)據(jù)做聚合，Pod Overhead 不會(huì)對(duì)它們?cè)斐捎绊憽?/p>

三、多容器運(yùn)行時(shí)示例

目前阿里云 ACK 安全沙箱容器已經(jīng)支持了多容器運(yùn)行時(shí)，我們以上圖所示環(huán)境為例來(lái)說(shuō)明一下多容器運(yùn)行時(shí)是怎么工作的。

如上圖所示有兩個(gè) Pod，左側(cè)是一個(gè) runc 的 Pod，對(duì)應(yīng)的 RuntimeClass 是 runc，右側(cè)是一個(gè) runv 的Pod，引用的 RuntimeClass 是 runv。對(duì)應(yīng)的請(qǐng)求已用不同的顏色標(biāo)識(shí)了出來(lái)，藍(lán)色的代表是 runc 的，紅色的代表是 runv 的。圖中下半部分，其中比較核心的部分是 containerd，在 containerd 中可以配置多個(gè)容器運(yùn)行時(shí)，最終上面的請(qǐng)求也會(huì)到達(dá)這里進(jìn)行請(qǐng)求的轉(zhuǎn)發(fā)。

我們先來(lái)看一下 runc 的請(qǐng)求，它先到達(dá) kube-apiserver，然后 kube-apiserver 請(qǐng)求轉(zhuǎn)發(fā)給 kubelet，最終 kubelet 將請(qǐng)求發(fā)至 cri-plugin（它是一個(gè)實(shí)現(xiàn)了 CRI 的插件），cri-plugin 在 containerd 的配置文件中查詢 runc 對(duì)應(yīng)的 Handler，最終查到是通過(guò) Shim API runtime v1 請(qǐng)求 containerd-shim，然后由它創(chuàng)建對(duì)應(yīng)的容器。這是 runc 的流程。

runv 的流程與 runc 的流程類似。也是先將請(qǐng)求到達(dá) kube-apiserver，然后再到達(dá) kubelet，再把請(qǐng)求到達(dá) cri-plugin，cri-plugin 最終還回去匹配 containerd 的配置文件，最終會(huì)找到通過(guò) Shim API runtime v2 去創(chuàng)建 containerd-shim-kata-v2，然后由它創(chuàng)建一個(gè) Kata Pod。

下面我們?cè)倏匆幌?containerd 的具體配置。

containerd 默認(rèn)放在 file:///etc/containerd/config.toml 這個(gè)位置下。比較核心的配置是在 plugins.cri.containerd 目錄下。其中 runtimes 的配置都有相同的前綴 plugins.cri.containerd.runtimes，后面有 runc, runv 兩種 RuntimeClass。這里面的 runc 和 runv 和前面 RuntimeClass 對(duì)象中 Handler 的名字是相對(duì)應(yīng)的。除此之外，還有一個(gè)比較特殊的配置 plugins.cri.containerd.runtimes.default_runtime，它的意思是說(shuō)，如果一個(gè) Pod 沒(méi)有指定 RuntimeClass，但是被調(diào)度到當(dāng)前節(jié)點(diǎn)的話，那么就默認(rèn)使用 runc 容器運(yùn)行時(shí)。

下面的例子是創(chuàng)建 runc 和 runv 這兩個(gè) RuntimeClass 對(duì)象，我們可以通過(guò) kubectl get runtimeclass 看到當(dāng)前所有可用的容器運(yùn)行時(shí)。

下圖從左至右分別是一個(gè) runc 和 runv 的 Pod，比較核心的地方就是在 runtimeClassName 字段中分別引用了 runc 和 runv 的容器運(yùn)行時(shí)。

最終將 Pod 創(chuàng)建起來(lái)之后，我們可以通過(guò) kubectl 命令來(lái)查看各個(gè) Pod 容器的運(yùn)行狀態(tài)以及 Pod 所使用的容器運(yùn)行時(shí)。我們可以看到現(xiàn)在集群中有兩個(gè) Pod：一個(gè)是 runc-pod，另一個(gè)是 runv-pod，分別引用的是 runc 和 runv 的 RuntimeClass，并且它們的狀態(tài)都是 Running。

• RuntimeClass 是 Kubernetes 一種內(nèi)置的集群資源，主要用來(lái)解決多個(gè)容器運(yùn)行時(shí)混用的問(wèn)題；

• RuntimeClass 中配置 Scheduling 可以讓 Pod 自動(dòng)調(diào)度到運(yùn)行了指定容器運(yùn)行時(shí)的節(jié)點(diǎn)上。但前提是需要用戶提前為這些 Node 設(shè)置好 label；

• RuntimeClass 中配置 Overhead，可以把 Pod 中業(yè)務(wù)運(yùn)行所需以外的開(kāi)銷統(tǒng)計(jì)進(jìn)來(lái)，讓調(diào)度、ResourceQuota、Kubelet Pod 驅(qū)逐等行為更準(zhǔn)確。

上述內(nèi)容就是如何理解RuntimeClass與 Pod Overhead，你們學(xué)到知識(shí)或技能了嗎？如果還想學(xué)到更多技能或者豐富自己的知識(shí)儲(chǔ)備，歡迎關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道。

文章題目：如何理解RuntimeClass與PodOverhead
URL地址：http://sd-ha.com/article6/popcog.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供手機(jī)網(wǎng)站建設(shè)、網(wǎng)站改版、電子商務(wù)、網(wǎng)站收錄、虛擬主機(jī)、自適應(yīng)網(wǎng)站

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng)，如需處理請(qǐng)聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來(lái)源： 創(chuàng)新互聯(lián)