作者：justmine
頭條號(hào)：大數(shù)據(jù)與云原生
微信公眾號(hào)：大數(shù)據(jù)與云原生
創(chuàng)作不易，在滿足創(chuàng)作共用版權(quán)協(xié)議的基礎(chǔ)上可以轉(zhuǎn)載，但請(qǐng)以超鏈接形式注明出處。
為了方便閱讀，微信公眾號(hào)已按分類(lèi)排版，后續(xù)的文章將在移動(dòng)端首發(fā)，想學(xué)習(xí)云原生相關(guān)知識(shí)，請(qǐng)關(guān)注我。

一、前言

Kubernetes的目標(biāo)不僅是使分布式應(yīng)用程序的部署和運(yùn)維變得簡(jiǎn)單可靠，還旨在能輕松地創(chuàng)建“云原生”應(yīng)用程序，即易于創(chuàng)建在云環(huán)境中運(yùn)行的分布式應(yīng)用程序和服務(wù)，于是從1.18版本開(kāi)始K8S將原生支持生命周期類(lèi)型為SideCar的容器。

在云原生時(shí)代，通過(guò)將應(yīng)用的非業(yè)務(wù)功能提到SideCar容器實(shí)現(xiàn)解耦，避免重復(fù)建設(shè)，給運(yùn)維人員提供更為豐富而深入的控制同時(shí)，也大大減輕了開(kāi)發(fā)人員的負(fù)擔(dān)。

隨著越來(lái)越多的應(yīng)用程序開(kāi)始實(shí)施這種模式，在K8S中出現(xiàn)了很多的問(wèn)題。很快，Kubernetes意識(shí)到應(yīng)該提供一種邊車(chē)模式的容器，并以不同的方式處理此類(lèi)容器的生命周期。

二、痛點(diǎn)

Sidecar容器的所有問(wèn)題都與容器生命周期相關(guān)性有關(guān)。由于Pod中的常規(guī)容器之間沒(méi)有區(qū)別，因此無(wú)法控制哪個(gè)容器首先啟動(dòng)或最后終止，但是先正確運(yùn)行Sidecar容器通常是應(yīng)用程序容器正確運(yùn)行的要求。

Pod啟動(dòng)

讓我們看一個(gè)Istio服務(wù)網(wǎng)格示例。Envoy邊車(chē)負(fù)責(zé)將所有傳入和傳出流量代理到應(yīng)用程序容器。因此，在代理啟動(dòng)并運(yùn)行之前，應(yīng)用程序應(yīng)該無(wú)法發(fā)送或接收流量。此時(shí)，如果應(yīng)用程序嘗試出站訪問(wèn)，則K8S的就緒性探針便形同虛設(shè)。如果應(yīng)用容器先啟動(dòng)，您會(huì)在日志中看到很多莫名的錯(cuò)誤消息，明明應(yīng)用已啟動(dòng)了，為什么還報(bào)503呢？但如果代理容器正常啟動(dòng)，但業(yè)務(wù)容器遭遇CrashLoopBackoffs時(shí)，應(yīng)用容器根本啟動(dòng)失敗，此時(shí)代理容器該何去何從？

其實(shí)這也不是一個(gè)非常棘手的問(wèn)題，我們可以在應(yīng)用程序容器的啟動(dòng)腳本中添加幾秒鐘的延遲，通過(guò)一個(gè)丑陋的解決方法間接地解決此問(wèn)題，這也是Istio當(dāng)下的做法。

三、解決方案

為了徹底解決上述痛點(diǎn)，從1.18版本開(kāi)始，K8S內(nèi)置的Sidecar功能將確保邊車(chē)在正常業(yè)務(wù)流程開(kāi)始之前就啟動(dòng)并運(yùn)行，即通過(guò)更改pod的啟動(dòng)生命周期，在init容器完成后啟動(dòng)sidecar容器，在sidecar容器就緒后啟動(dòng)業(yè)務(wù)容器，從啟動(dòng)流程上保證順序性。

四、新功能的影響

作業(yè)完成

如果Kubernetes作業(yè)具有Sidecar容器，則即使主容器完成后它仍將繼續(xù)運(yùn)行，并且作業(yè)本身永遠(yuǎn)不會(huì)達(dá)到完成狀態(tài)。因?yàn)榻鉀Q該問(wèn)題的唯一方法是在業(yè)務(wù)過(guò)程完成時(shí)以某種方式發(fā)送信號(hào)給sidecar容器以退出。

這種解決方法存在一些問(wèn)題：這意味著使用自定義邏輯擴(kuò)展所有作業(yè)，并以某種方式在容器之間進(jìn)行同步：通過(guò)共享的暫存卷或某些臨時(shí)解決方案，例如Envoy的/quitquitquit終結(jié)點(diǎn)。

故從Kubernetes 1.18開(kāi)始，如果所有普通容器都已到達(dá)終端狀態(tài)（Succeededfor?restartPolicy=OnFailure或Succeeded/Failedfor?restartPolicy=Never），則將向所有sidecar容器發(fā)送?SIGTERM信號(hào)。

Pod關(guān)閉

Pod關(guān)閉與Pod啟動(dòng)類(lèi)似。如果Sidecar在業(yè)務(wù)過(guò)程之前終止，則在正常拆除業(yè)務(wù)應(yīng)用程序期間可能會(huì)導(dǎo)致大量錯(cuò)誤。在正常關(guān)閉期間，應(yīng)用程序可以執(zhí)行某種清除邏輯，例如關(guān)閉長(zhǎng)期連接，回滾事務(wù)或?qū)顟B(tài)保存到外部存儲(chǔ)(例如s3)。如果首先殺死了邊車(chē)，則可能會(huì)導(dǎo)致清理邏輯無(wú)法正常運(yùn)行。

一個(gè)很好的例子是argo項(xiàng)目中報(bào)告的一個(gè)問(wèn)題。Argo嘗試將容器日志存儲(chǔ)在s3中，但是如果istio-proxy先殺死則無(wú)法這樣做，因?yàn)樗辛髁慷紤?yīng)流經(jīng)該容器。

此類(lèi)問(wèn)題的解決方案類(lèi)似于啟動(dòng)問(wèn)題。通過(guò)更改Pod終止生命周期，首先向所有應(yīng)用容器發(fā)送一個(gè)SIGTERM信號(hào)，等所有應(yīng)用容器全部正常終止后，再向所有邊車(chē)容器發(fā)送SIGTERM信號(hào)。在正常的平滑期(TerminationGracePeriod)內(nèi)，如果所有的應(yīng)用容器還未終止，像以前一樣發(fā)送SIGKILL信號(hào)強(qiáng)制終止，然后發(fā)送SIGTERM信號(hào)給邊車(chē)容器。

五、如何使用新功能？

通過(guò)更改Pod規(guī)范中的container.lifecycle.type將容器標(biāo)記為邊車(chē)類(lèi)型：Sidecar，默認(rèn)為Standard，如下：

apiVersion: v1 kind: Pod metadata:name: bookings-v1-b54bc7c9c-v42f6labels:app: demoapp spec:containers:- name: bookingsimage: banzaicloud/allspark:0.1.1...- name: istio-proxyimage: docker.io/istio/proxyv2:1.4.3lifecycle:type: Sidecar...

注意：在k8s 1.18版本，邊車(chē)模式僅僅作為支撐功能，故需要通過(guò)Api Server顯示啟用。

六、總結(jié)

本篇先詳細(xì)介紹了K8S即將推出的重磅功能，可以說(shuō)此功能專(zhuān)為云原生而設(shè)計(jì)，這也是為什么K8S會(huì)越來(lái)越受歡迎的原因，然后進(jìn)一步分析了當(dāng)下K8S實(shí)施邊車(chē)模式的痛點(diǎn)，以及引入新功能的一些影響，最后通過(guò)例子演示了如何應(yīng)用邊車(chē)模式到Pod中，可以看出此功能將從根本上解決目前很多使用邊車(chē)模式存在的問(wèn)題。

七、最后

如果有什么疑問(wèn)和見(jiàn)解，歡迎評(píng)論區(qū)交流。

如果覺(jué)得本篇有幫助的話，歡迎推薦和轉(zhuǎn)發(fā)。

如果覺(jué)得本篇非常不錯(cuò)的話，可以請(qǐng)作者吃個(gè)雞腿，創(chuàng)作的源泉將如滔滔江水連綿不斷，嘿嘿。

八、參考資料

https://banzaicloud.com/blog/k8s-sidecars

https://github.com/kubernetes/enhancements/issues/753

https://kubernetes.io/blog/2016/06/container-design-patterns

創(chuàng)作挑戰(zhàn)賽新人創(chuàng)作獎(jiǎng)勵(lì)來(lái)咯，堅(jiān)持創(chuàng)作打卡瓜分現(xiàn)金大獎(jiǎng)

總結(jié)

以上是生活随笔為你收集整理的重磅！K8S 1.18版本将内置支持SideCar容器。的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

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