重磅！K8S 1.18版本將內置支持SideCar容器。

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

1、前言

Kubernetes的目標不只是使分佈式應用程序的部署和運維變得簡單可靠，還旨在能輕鬆地建立「雲原生」應用程序，即易於建立在雲環境中運行的分佈式應用程序和服務，因而從1.18版本開始K8S將原生支持生命週期類型爲SideCar的容器。

在雲原生時代，經過將應用的非業務功能提到SideCar容器實現解耦，避免重複建設，給運維人員提供更爲豐富而深刻的控制同時，也大大減輕了開發人員的負擔。

隨着愈來愈多的應用程序開始實施這種模式，在K8S中出現了不少的問題。很快，Kubernetes意識到應該提供一種邊車模式的容器，並以不一樣的方式處理此類容器的生命週期。

2、痛點

Sidecar容器的全部問題都與容器生命週期相關性有關。因爲Pod中的常規容器之間沒有區別，所以沒法控制哪一個容器首先啓動或最後終止，可是先正確運行Sidecar容器一般是應用程序容器正確運行的要求。

Pod啓動

讓咱們看一個Istio服務網格示例。Envoy邊車負責將全部傳入和傳出流量代理到應用程序容器。所以，在代理啓動並運行以前，應用程序應該沒法發送或接收流量。此時，若是應用程序嘗試出站訪問，則K8S的就緒性探針便形同虛設。若是應用容器先啓動，您會在日誌中看到不少莫名的錯誤消息，明明應用已啓動了，爲何還報503呢？但若是代理容器正常啓動，但業務容器遭遇CrashLoopBackoffs時，應用容器根本啓動失敗，此時代理容器該何去何從？

其實這也不是一個很是棘手的問題，咱們能夠在應用程序容器的啓動腳本中添加幾秒鐘的延遲，經過一個醜陋的解決方法間接地解決此問題，這也是Istio當下的作法。

3、解決方案

爲了完全解決上述痛點，從1.18版本開始，K8S內置的Sidecar功能將確保邊車在正常業務流程開始以前就啓動並運行，即經過更改pod的啓動生命週期，在init容器完成後啓動sidecar容器，在sidecar容器就緒後啓動業務容器，從啓動流程上保證順序性。

4、新功能的影響

做業完成

若是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信號給邊車容器。

5、如何使用新功能？

經過更改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顯示啓用。

6、總結

本篇先詳細介紹了K8S即將推出的重磅功能，能夠說此功能專爲雲原生而設計，這也是爲何K8S會愈來愈受歡迎的緣由，而後進一步分析了當下K8S實施邊車模式的痛點，以及引入新功能的一些影響，最後經過例子演示瞭如何應用邊車模式到Pod中，能夠看出此功能將從根本上解決目前不少使用邊車模式存在的問題。

7、最後

若是有什麼疑問和看法，歡迎評論區交流。

若是以爲本篇有幫助的話，歡迎推薦和轉發。

若是以爲本篇很是不錯的話，能夠請做者吃個雞腿，創做的源泉將如滔滔江水連綿不斷，嘿嘿。

8、參考資料

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

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

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

原文出處：https://www.cnblogs.com/justmine/p/12292861.html