創作不易，在滿足創作共用版權協議的基礎上可以轉載，但請以超鏈接形式註明出處。
為了方便閱讀，微信公眾號已按分類排版，後續的文章將在移動端首發，想學習雲原生相關知識，請關注我。
一、前言
Kubernetes的目標不僅是使分佈式應用程序的部署和運維變得簡單可靠，還旨在能輕鬆地創建“雲原生”應用程序，即易於創建在雲環境中運行的分佈式應用程序和服務，於是從1.18版本開始K8S將原生支持生命週期類型為SideCar的容器。
在雲原生時代，通過將應用的非業務功能提到SideCar容器實現解耦，避免重複建設，給運維人員提供更為豐富而深入的控制同時，也大大減輕了開發人員的負擔。
隨著越來越多的應用程序開始實施這種模式，在K8S中出現了很多的問題。很快，Kubernetes意識到應該提供一種邊車模式的容器，並以不同的方式處理此類容器的生命週期。
二、痛點
Sidecar容器的所有問題都與容器生命週期相關性有關。由於Pod中的常規容器之間沒有區別，因此無法控制哪個容器首先啟動或最後終止，但是先正確運行Sidecar容器通常是應用程序容器正確運行的要求。
Pod啟動
讓我們看一個Istio服務網格示例。Envoy邊車負責將所有傳入和傳出流量代理到應用程序容器。因此，在代理啟動並運行之前，應用程序應該無法發送或接收流量。此時，如果應用程序嘗試出站訪問，則K8S的就緒性探針便形同虛設。如果應用容器先啟動，您會在日誌中看到很多莫名的錯誤消息，明明應用已啟動了，為什麼還報503呢？但如果代理容器正常啟動，但業務容器遭遇CrashLoopBackoffs時，應用容器根本啟動失敗，此時代理容器該何去何從？
其實這也不是一個非常棘手的問題，我們可以在應用程序容器的啟動腳本中添加幾秒鐘的延遲，通過一個醜陋的解決方法間接地解決此問題，這也是Istio當下的做法。
三、解決方案
為了徹底解決上述痛點，從1.18版本開始，K8S內置的Sidecar功能將確保邊車在正常業務流程開始之前就啟動並運行，即通過更改pod的啟動生命週期，在init容器完成後啟動sidecar容器，在sidecar容器就緒後啟動業務容器，從啟動流程上保證順序性。
四、新功能的影響
作業完成
如果Kubernetes作業具有Sidecar容器，則即使主容器完成後它仍將繼續運行，並且作業本身永遠不會達到完成狀態。因為解決該問題的唯一方法是在業務過程完成時以某種方式發送信號給sidecar容器以退出。
這種解決方法存在一些問題：這意味著使用自定義邏輯擴展所有作業，並以某種方式在容器之間進行同步：通過共享的暫存卷或某些臨時解決方案，例如Envoy的/quitquitquit終結點。
故從Kubernetes 1.18開始，如果所有普通容器都已到達終端狀態（Succeededfor restartPolicy=OnFailure或Succeeded/Failedfor restartPolicy=Never），則將向所有sidecar容器發送 SIGTERM信號。
Pod關閉
Pod關閉與Pod啟動類似。如果Sidecar在業務過程之前終止，則在正常拆除業務應用程序期間可能會導致大量錯誤。在正常關閉期間，應用程序可以執行某種清除邏輯，例如關閉長期連接，回滾事務或將狀態保存到外部存儲(例如s3)。如果首先殺死了邊車，則可能會導致清理邏輯無法正常運行。
一個很好的例子是argo項目中報告的一個問題。Argo嘗試將容器日誌存儲在s3中，但是如果istio-proxy先殺死則無法這樣做，因為所有流量都應流經該容器。
此類問題的解決方案類似於啟動問題。通過更改Pod終止生命週期，首先向所有應用容器發送一個SIGTERM信號，等所有應用容器全部正常終止後，再向所有邊車容器發送SIGTERM信號。在正常的平滑期(TerminationGracePeriod)內，如果所有的應用容器還未終止，像以前一樣發送SIGKILL信號強制終止，然後發送SIGTERM信號給邊車容器。
五、如何使用新功能？
通過更改Pod規範中的container.lifecycle.type將容器標記為邊車類型：Sidecar，默認為Standard，如下：
<code>apiVersion: v1kind: Podmetadata: name: bookings-v1-b54bc7c9c-v42f6 labels: app: demoappspec: containers: - name: bookings image: banzaicloud/allspark:0.1.1 ... - name: istio-proxy image: docker.io/istio/proxyv2:1.4.3 lifecycle: type: Sidecar .../<code>
注意：在k8s 1.18版本，邊車模式僅僅作為支撐功能，故需要通過Api Server顯示啟用。
六、總結
本篇先詳細介紹了K8S即將推出的重磅功能，可以說此功能專為雲原生而設計，這也是為什麼K8S會越來越受歡迎的原因，然後進一步分析了當下K8S實施邊車模式的痛點，以及引入新功能的一些影響，最後通過例子演示瞭如何應用邊車模式到Pod中，可以看出此功能將從根本上解決目前很多使用邊車模式存在的問題。
七、最後
如果有什麼疑問和見解，歡迎評論區交流。
如果覺得本篇有幫助的話，歡迎推薦和轉發。
如果覺得本篇非常不錯的話，可以請作者吃個雞腿，創作的源泉將如滔滔江水連綿不斷，嘿嘿。
https://banzaicloud.com/blog/k8s-sidecars
https://github.com/kubernetes/enhancements/issues/753
https://kubernetes.io/blog/2016/06/container-design-patterns
閱讀更多 大數據與雲原生 的文章
