作者：justmine
頭條號：大資料與雲原生
微信公眾號：大資料與雲原生
創作不易，在滿足創作共用版權協議的基礎上可以轉載，但請以超連結形式註明出處。
為了方便閱讀，微信公眾號已按分類排版，後續的文章將在移動端首發，想學習雲原生相關知識，請關注我。

一、前言

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，如下：

apiVersion: v1
kind: Pod
metadata:
  name: bookings-v1-b54bc7c9c-v42f6
  labels:
    app: demoapp
spec:
  containers:
  - name: bookings
    image: banzaicloud/allspark:0.1.1
    ...
  - name: istio-proxy
    image: docker.io/istio/proxyv2:1.4.3
    lifecycle:
      type: Sidecar
    ...

注意：在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-patte