OpenKruise如何實(shí)現(xiàn)K8s社區(qū)首個(gè)規(guī)?；R像預(yù)熱能力

這篇文章將為大家詳細(xì)講解有關(guān)OpenKruise如何實(shí)現(xiàn) K8s 社區(qū)首個(gè)規(guī)模化鏡像預(yù)熱能力，文章內(nèi)容質(zhì)量較高，因此小編分享給大家做個(gè)參考，希望大家閱讀完這篇文章后對(duì)相關(guān)知識(shí)有一定的了解。

10年積累的做網(wǎng)站、網(wǎng)站建設(shè)經(jīng)驗(yàn)，可以快速應(yīng)對(duì)客戶對(duì)網(wǎng)站的新想法和需求。提供各種問(wèn)題對(duì)應(yīng)的解決方案。讓選擇我們的客戶得到更好、更有力的網(wǎng)絡(luò)服務(wù)。我雖然不認(rèn)識(shí)你，你也不認(rèn)識(shí)我。但先網(wǎng)站制作后付款的網(wǎng)站建設(shè)流程，更有雨山免費(fèi)網(wǎng)站建設(shè)讓你可以放心的選擇與我們合作。

背景：為什么鏡像預(yù)熱能力是必要的

“鏡像” 也算是 Docker 為容器領(lǐng)域帶來(lái)的一大創(chuàng)新。在 Docker 之前，雖然 Linux 已經(jīng)提供了 cgroup 隔離，盡管阿里巴巴從 2011 年已經(jīng)逐漸基于 LXC 開始容器化，但都缺乏鏡像這種對(duì)運(yùn)行環(huán)境的封裝。不過(guò)呢，盡管鏡像為我們帶來(lái)了諸多好處，但不可否認(rèn)在實(shí)際場(chǎng)景中我們也面臨各種各樣拉鏡像帶來(lái)的問(wèn)題，其中最常見的一點(diǎn)就是拉鏡像的耗時(shí)。

我們過(guò)去聽到過(guò)很多用戶對(duì)容器化的期待和認(rèn)識(shí)，比如 “極致彈性”、“秒級(jí)擴(kuò)容”、“高效發(fā)布” 等等，但結(jié)合 Kubernetes 中一個(gè)標(biāo)準(zhǔn)的 Pod 創(chuàng)建過(guò)程來(lái)看，和用戶的期望還是有一定差距的（假設(shè) Pod 中包含 sidecar、app 兩個(gè)容器）：

正常來(lái)說(shuō)，對(duì)于小規(guī)模集群中調(diào)度、分配/掛載遠(yuǎn)程盤、分配網(wǎng)絡(luò)等操作耗時(shí)較小，對(duì)于大規(guī)模集群需要做一定優(yōu)化，但都還在可控的范圍內(nèi)。然而對(duì)于拉鏡像的耗時(shí)，在大規(guī)模彈性的集群中則尤為棘手，即使采用了 P2P 等技術(shù)手段來(lái)優(yōu)化，對(duì)于一個(gè)較大的業(yè)務(wù)鏡像還是可能需要較長(zhǎng)的時(shí)間來(lái)拉取，與用戶所期望的擴(kuò)容、發(fā)布速度不符。

而我們?nèi)绻茏龅綄?sidecar 容器的鏡像、以及業(yè)務(wù)容器的基礎(chǔ)鏡像提前在節(jié)點(diǎn)上拉取好，則 Pod 創(chuàng)建過(guò)程可以大幅縮短，其中拉鏡像的耗時(shí)甚至能優(yōu)化 70% 以上：

而 Kubernetes 自身是沒(méi)有提供任何面向鏡像的操作能力的，圍繞 Kubernetes 的生態(tài)來(lái)看，目前也沒(méi)有比較成熟的規(guī)模化鏡像預(yù)熱產(chǎn)品。這是我們?cè)?OpenKruise 中提供鏡像預(yù)熱的原因，并且這套鏡像預(yù)熱能力已經(jīng)在阿里巴巴內(nèi)部的云原生環(huán)境大面積落地，在后文的實(shí)踐中也會(huì)簡(jiǎn)單介紹我們的基本用法。

OpenKruise 是如何實(shí)現(xiàn)鏡像預(yù)熱的

OpenKruise 實(shí)現(xiàn)鏡像預(yù)熱的原理，要先從它的運(yùn)行架構(gòu)看起：

從 v0.8.0 開始，安裝了 Kruise 之后，有兩個(gè)在 kruise-system 命名空間下的組件：kruise-manager 與 kruise-daemon。前者是一個(gè)由 Deployment 部署的中心化組件，一個(gè) kruise-manager 容器（進(jìn)程）中包含了多個(gè) controller 和 webhook；后者則由 DaemonSet 部署到集群中的節(jié)點(diǎn)上，通過(guò)與 CRI 交互來(lái)繞過(guò) Kubelet 完成一些擴(kuò)展能力（比如拉取鏡像、重啟容器等）。

因此，Kruise 會(huì)為每個(gè)節(jié)點(diǎn)（Node）創(chuàng)建一個(gè)同名對(duì)應(yīng)的自定義資源：NodeImage，而每個(gè)節(jié)點(diǎn)的 NodeImage 里寫明了在這個(gè)節(jié)點(diǎn)上需要預(yù)熱哪些鏡像，因此這個(gè)節(jié)點(diǎn)上的 kruise-daemon 只要按照 NodeImage 來(lái)執(zhí)行鏡像的拉取任務(wù)即可：

如上圖所示，我們?cè)?NodeImage 中能指定要拉取的鏡像名、tag、拉取的策略，比如單次拉取的超時(shí)、失敗重試次數(shù)、任務(wù)的 deadline、TTL 時(shí)間等等。

有了 NodeImage，我們也就擁有了最基本的鏡像預(yù)熱能力了，不過(guò)還不能完全滿足大規(guī)模場(chǎng)景的預(yù)熱需求。在一個(gè)有 5k 個(gè)節(jié)點(diǎn)的集群中，要用戶去一個(gè)個(gè)更新 NodeImage 資源來(lái)做預(yù)熱顯然是不夠友好的。因此，Kruise 還提供了一個(gè)更高抽象的自定義資源 ImagePullJob：

如上圖所示，在 ImagePullJob 中用戶可以指定一個(gè)鏡像要在哪些范圍的節(jié)點(diǎn)上批量做預(yù)熱，以及這個(gè) job 的拉取策略、生命周期等。一個(gè) ImagePullJob 創(chuàng)建后，會(huì)被 kruise-manager 中的 imagepulljob-controller 接收到并處理，將其分解并寫入到所有匹配節(jié)點(diǎn)的 NodeImage 中，以此來(lái)完成規(guī)模化的預(yù)熱。

整體的流程如下：

而有了鏡像預(yù)熱能力后，我們?cè)趺慈ナ褂盟?，或者說(shuō)什么場(chǎng)景下需要來(lái)使用呢？接下來(lái)我們介紹下鏡像預(yù)熱在阿里巴巴中的幾種常見使用方式。

常見的鏡像預(yù)熱使用方式有哪些

1. 基礎(chǔ)鏡像 – 集群維度預(yù)熱

最常見的預(yù)熱場(chǎng)景，是在整個(gè)集群維度持續(xù)預(yù)熱一些基礎(chǔ)鏡像：

apiVersion: apps.kruise.io/v1alpha1
kind: ImagePullJob
metadata:
  name: base-image-job
spec:
  image: xxx/base-image:latest
  parallelism: 10
  completionPolicy:
    type: Never
  pullPolicy:
    backoffLimit: 3
    timeoutSeconds: 300

如上述 ImagePullJob 有幾個(gè)特征：

1. 不配置 selector 規(guī)則，即默認(rèn)整個(gè)集群維度預(yù)熱

1. 存量的節(jié)點(diǎn)上統(tǒng)一預(yù)熱

2. 后續(xù)新增（導(dǎo)入）的節(jié)點(diǎn)上也會(huì)立即自動(dòng)做預(yù)熱

2. 采用 Never 的 completionPolicy 策略來(lái)長(zhǎng)期運(yùn)行

1. Never 策略表明這個(gè) job 持續(xù)做預(yù)熱，不會(huì)結(jié)束（除非被刪除）

2. Never 策略下，ImagePullJob 每隔 24h 左右會(huì)觸發(fā)在所有匹配的節(jié)點(diǎn)上重試?yán)∫淮?，也就是每天都?huì)確保一次鏡像存在

根據(jù)我們的經(jīng)驗(yàn)，一個(gè)集群中預(yù)熱基礎(chǔ)鏡像的 ImagePullJob 在 10~30 個(gè)左右，具體視集群以及業(yè)務(wù)場(chǎng)景而定。

2. sidecar 鏡像 – 集群維度預(yù)熱

我們同樣也可以對(duì)一些 sidecar 的鏡像做預(yù)熱，尤其是那些基本上每個(gè)業(yè)務(wù) Pod 中都會(huì)帶有的基礎(chǔ) sidecar：

apiVersion: apps.kruise.io/v1alpha1
kind: ImagePullJob
metadata:
  name: sidecar-image-job
spec:
  image: xxx/sidecar-image:latest
  parallelism: 20
  completionPolicy:
    type: Always
    activeDeadlineSeconds: 1800
    ttlSecondsAfterFinished: 300
  pullPolicy:
    backoffLimit: 3
    timeoutSeconds: 300

如上述 ImagePullJob 有幾個(gè)特征：

1. 不配置 selector，默認(rèn)整個(gè)集群維度預(yù)熱，這一點(diǎn)與基礎(chǔ)鏡像類似

2. 采用 Always 策略一次性預(yù)熱

1. 所有節(jié)點(diǎn)做一次預(yù)熱

2. 整個(gè) job 預(yù)熱超時(shí)時(shí)間 30min

3. job 完成后過(guò) 5min 自動(dòng)刪除

當(dāng)然，這里的 sidecar 預(yù)熱也可以配置為 Never 策略，視場(chǎng)景而定。以我們的經(jīng)驗(yàn)來(lái)看，尤其在 sidecar 做版本迭代、鏡像升級(jí)的時(shí)候，提前做一次規(guī)?；溺R像預(yù)熱，可以大幅提升后續(xù) Pod 擴(kuò)容、發(fā)布的速度。

3. 特殊業(yè)務(wù)鏡像 – 資源池維度預(yù)熱

對(duì)于一些多租的 Kubernetes 集群中會(huì)存在多個(gè)不同的業(yè)務(wù)資源池，其中可能需要將一些特定的業(yè)務(wù)鏡像按資源池維度來(lái)預(yù)熱：

apiVersion: apps.kruise.io/v1alpha1
kind: ImagePullJob
metadata:
  name: serverless-job
spec:
  image: xxx/serverless-image:latest
  parallelism: 10
  completionPolicy:
    type: Never
  pullPolicy:
    backoffLimit: 3
    timeoutSeconds: 300
  selector:
    matchLabels:
      resource-pool: serverless

如上述 ImagePullJob 有幾個(gè)特征：

1. 采用 Never 策略長(zhǎng)期預(yù)熱

2. 指定 selector 預(yù)熱范圍，是匹配 resource-pool=serverless 標(biāo)簽的節(jié)點(diǎn)

當(dāng)然，這里只是以資源池為例，用戶可以根據(jù)自身的場(chǎng)景來(lái)定義在哪些節(jié)點(diǎn)上預(yù)熱某種鏡像。

版本前瞻：原地升級(jí)與預(yù)熱的結(jié)合

最后，再來(lái)介紹下 OpenKruise 的下個(gè)版本（v0.9.0）中，我們會(huì)基于當(dāng)前的鏡像預(yù)熱實(shí)現(xiàn)怎樣的增強(qiáng)能力呢？

之前對(duì) OpenKruise 了解過(guò)的同學(xué)一定知道，我們提供的一大特性就是 “原地升級(jí)”，即打破了 Kubernetes 原生 workload 發(fā)布時(shí)必須將 Pod 刪除、重建的模式，支持在原 Pod 上只更新其中某個(gè)容器的鏡像。對(duì)原地升級(jí)原理感興趣的同學(xué)可以讀這篇文章：《揭秘：如何為 Kubernetes 實(shí)現(xiàn)原地升級(jí)？》。

由于原地升級(jí)避免了 Pod 刪除、重建的過(guò)程，它本身已經(jīng)能為我們帶來(lái)了如下的好處：

• 節(jié)省了調(diào)度的耗時(shí)，Pod 的位置、資源都不發(fā)生變化

• 節(jié)省了分配網(wǎng)絡(luò)的耗時(shí)，Pod 還使用原有的 IP

• 節(jié)省了分配、掛載遠(yuǎn)程盤的耗時(shí)，Pod 還使用原有的 PV（且都是已經(jīng)在 Node 上掛載好的）

• 節(jié)省了大部分拉取鏡像的耗時(shí)，因?yàn)楣?jié)點(diǎn)上已經(jīng)存在了應(yīng)用的舊鏡像，當(dāng)拉取新版本鏡像時(shí)只需要下載少數(shù)的幾層 layer

• 原地升級(jí) Pod 中某個(gè)容器時(shí)，其他容器保持正常運(yùn)行，網(wǎng)絡(luò)、存儲(chǔ)均不受影響

其中，“節(jié)省了大部分拉取鏡像的耗時(shí)” 后，只需要下載新鏡像上層的部分 layer 即可。而我們有沒(méi)有可能把這個(gè)鏡像拉取時(shí)間徹底優(yōu)化掉呢？答案是肯定的。

如上圖所示，在下個(gè)版本中 OpenKruise 的 CloneSet 將支持發(fā)布過(guò)程自動(dòng)鏡像預(yù)熱。當(dāng)用戶還在灰度升級(jí)第一批 Pod 的時(shí)候，Kruise 會(huì)提前在后續(xù) Pod 所在節(jié)點(diǎn)上把新版本的鏡像預(yù)熱好。這樣一來(lái)，在后續(xù)批次的 Pod 做原地升級(jí)時(shí)候，新鏡像都已經(jīng)在節(jié)點(diǎn)上準(zhǔn)備好了，也就節(jié)省了真正發(fā)布過(guò)程中的拉鏡像耗時(shí)。

當(dāng)然，這種 “發(fā)布+預(yù)熱” 的模式也只適用于 OpenKruise 的原地升級(jí)場(chǎng)景。對(duì)于原生 workload 如 Deployment 而言，由于發(fā)布時(shí) Pod 是新建出來(lái)的，我們無(wú)法提前預(yù)知到它會(huì)被調(diào)度到的節(jié)點(diǎn)，自然也就沒(méi)辦法提前把鏡像預(yù)熱好了。

關(guān)于OpenKruise如何實(shí)現(xiàn) K8s 社區(qū)首個(gè)規(guī)模化鏡像預(yù)熱能力就分享到這里了，希望以上內(nèi)容可以對(duì)大家有一定的幫助，可以學(xué)到更多知識(shí)。如果覺(jué)得文章不錯(cuò)，可以把它分享出去讓更多的人看到。

新聞標(biāo)題：OpenKruise如何實(shí)現(xiàn)K8s社區(qū)首個(gè)規(guī)?；R像預(yù)熱能力
分享路徑：http://muchs.cn/article38/pihjpp.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供搜索引擎優(yōu)化、網(wǎng)站建設(shè)、外貿(mào)網(wǎng)站建設(shè)、軟件開發(fā)、、移動(dòng)網(wǎng)站建設(shè)

廣告

聲明：本網(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)