作者 | 徐迪、張曉宇
導讀：本文根據徐迪和張曉宇在 KubeCon NA 2019 大會分享整理。分享将會從以下幾個方面進行切入：首先會簡單介紹一下什麼是 Sidecar 容器；其次，會分享幾個阿裡巴巴經濟體的通用場景，以及他們是如何解決這些挑戰的。
Sidecar 簡介
Sidecar 容器并不是一個新鮮事物。它是一種設計模式，主要用來做一些輔助的工作，比如網絡連通性、下載下傳拷貝檔案之類的事情；如果大家熟悉 Docker Swarm 的話，就會發現 Docker Ambassador 其實就是 Sidecar。
如上所示，Service Consumer 和 Redis Provider 強耦合，部署在同一個節點上。如果這個時候，Redis Provider 出現問題，需要連接配接到另外一個 Redis 執行個體上，需要重新配置，并重新開機 Service Provider。
那麼在引入了 Ambassador 以後，問題變得相對簡單些，隻需要重新開機這裡的 Redis Ambassador 即可，并不需要 Service Consumer 進行任何變動。
當然這種模式，還可以進行跨節點通信，比如下圖。這樣 Service Consumer 和 Redis Provider 就可以部署在不同的節點上。在某種程度上，很容易地就将兩種服務進行了解耦。
Sidecar 案例分享
1. Sidecar 容器能用來幹什麼？
一般來講，Sidecar 容器可以：
- 日志代理/轉發，例如 fluentd；
- Service Mesh，比如 Istio，Linkerd；
- 代理，比如 Docker Ambassador；
- 探活：檢查某些元件是不是正常工作；
- 其他輔助性的工作，比如拷貝檔案，下載下傳檔案等；
2. 僅此而已？
事實上，Sidecar 越來越被大家接受，并且使用越來越廣泛。Sidecar 容器通常和業務容器（非 Sidecar 容器）部署在同一個 Pod 裡，共享相同的生命周期，為業務容器提供輔助功能。這是一個非常好的模式，能夠極大程度解耦應用，并且支援異構元件，降低技術壁壘。
但目前 Kubernetes 對 Sidecar 的管理還不完善，越來越不滿足我們的使用，尤其是在生産環境中使用 Sidecar。
3. 幾個典型案例
順序依賴
假設我們在一個 Pod 内注入了多個 Sidecar，但是 Sidecar 之間或者 Sidecar 和業務容器之間有互相依賴關系。如下這個例子，我們需要先啟動 proxy Sidecar 容器用于建立網絡連接配接，這樣 mysql client 才能連接配接到遠端的 mysql 叢集，并在本地暴露服務。而後主的業務容器才能正常工作。
#1 proxy_container (sidecar)
#2 mysql_client
#3 svc_container 當然，有的人會覺得這個地方，可以通過諸如更改鏡像啟動腳本延遲啟動等方法來解決。但是這些方法侵入性太強，不利于擴充，還很難進行準确的配置。
Sidecar 管理
我們來看看另外一個案例。Sidecar 容器和業務容器耦合在同一個 Pod 内，共享相同的生命周期。是以，單獨來管控 Sidecar 容器非常不方，比如更新 Sidecar 的鏡像。
比如，我們已經給很多 Pod 注入了 Istio Proxy 這樣的 Sidecar 容器，目前運作狀态良好。但是如果這個時候我們想更新這個 Proxy 鏡像的話，該怎麼辦？
如果按照
Istio 社群官方的文檔，我們需要重新注入這些 Sidecar 容器。具體來說，需要删除原有 Pod，重新生成一份新的 Pod（有些 workload 關聯的 Pod，會由相應的 workload 控制器自動生成）。
那如果我們有很多個這樣的 Pod 需要處理的話，怎麼辦？通過指令行的話，太不友善，而且容易出錯。通過自己單獨寫的代碼的話，可擴充性是個問題，需要頻繁更改這些代碼。
而且這裡還有另外一個問題，我們肯定不會一下子更新所有的 Sidecar，肯定要有個灰階的過程，也就是隻更新一部分 Sidecar，這個時候又該怎麼辦呢？
社群進展
1. 上遊社群
這裡我們非常感謝 Joseph Irving (@Joseph-Irving) 提出了一個
Sidecar kep，通過定義 LifecycleType 來區分是否是 Sidecar 容器。
未來隻需要在 Pod Spec 中，按如下方式标記即可：
name: sidecarContainer
image: foo
lifecycle:
type: Sidecar Pod 内容器的啟動順序按照：初始化容器->Sidecar 容器->業務容器 的順序依次啟動。
其中上述 kep 的
kubelet 端實作正在進行中。
為了支援 Sidecar 更多的使用場景，我們以此為基礎提出了 PreSidecar 和 PostSidecar，分别用于在業務容器之前和之後啟動。
具體的使用場景見 我們的
PR。
為什麼我們覺得 Sidecar 應該區分前置和後置呢？
這是因為在一些場景下，我們需要 Sidecar 容器優先于應用容器啟動，幫助做一些準備工作。例如分發證書，建立共享卷，或者拷貝下載下傳一些其他檔案等。
而在另外一些場景下，我們需要一些 Sidecar 容器在應用容器之後啟動。考慮到解耦和版本管理的因素，我們将應用分為兩部分，應用容器專注于業務本身，而一些資料和個性化的配置放在 Sidecar 容器中。通常情況下，這兩個容器将會共享一個存儲卷，後置的 Sidecar 容器會更新替換掉一些預設和過時資料。
當然考慮到未來更複雜的場景，我們可能還會對容器的啟動順序做 DAG 編排，當然這個需要視生産實際需要而定。
2. 螞蟻金服及阿裡巴巴如何應對
為了解決 Sidecar 的管理工作，我們需要一個更細粒度的 workload 友善我們進行管理。這個 workload 我們命名為 SidecarSet，目前已經開源，生産可用。大家可以通路
OpenKruise這個項目，可以在項目的
roadmap裡了解我們目前的一些新進展。OpenKruise 這個項目目前有三個生産可用的 workload，分别是 Advanced StatefulSet、BroadcastJob、SidecarSet。另外2個 workload（AdvancedHPA 和 PodHealer）正在加緊開發中， 很快會開源出來，敬請期待。相關使用 Demo，大家可以觀看 Lachlan Evenson 的
嘗鮮視訊 spec 中的 SidecarContainer 的定義就是 Kubernetes 代碼庫中的 corev1.Container 定義。通過額外的一個 labelSelector，可以很友善地對指定的容器組進行操作。我們支援滾動更新（RollingUpdate）的方式，讓使用者可以分批的更新 Sidecar，同時也提供了 pause 功能，可以在緊急情況下暫停 Sidecar 的更新。
如果隻是簡單更新 Sidecar 的鏡像， SidecarSet 控制器僅僅會 patch 原有 pod 的，非常友善的就可以一鍵更新鏡像。
其他的挑戰
我們在生産實踐過程中，還發現了一些其他的挑戰，目前還在尋找比較好的解法。
1. Sidecar 容器的資源管理
一般來講 Sidecar 容器占用的資源都比較小，那麼這個資源要不要計算到整個 pod 當中？還是可以直接共享業務容器的資源即可？相同的 Sidecar 在和不同的應用容器搭配使用，如何準确給 Sidecar 容器配置設定資源這些都需要進行考慮。
2. Sidecar 容器的容錯性
一般來講，Sidecar 容器都是非主要容器，那麼這類容器出現問題時，比如 liveness 探活，要不要對主容器的狀态或者整個 pod 的狀态也産生影響。再或者，Sidecar 鏡像更新出現問題時，要不要直接标記整個 pod 出現問題。當然，還有一些其他的挑戰，我們隻是列舉了幾個通用的。對于這些挑戰，我們需要大家一起集思廣益，找到比較合理的解法。
小結
随着 Sidecar 在生産環境使用越來越廣泛，對其的管理愈發需要重視。Sidecar 雖然和業務容器部署在同一個 Pod 内，但是其本質上隻是輔助性的容器。本文介紹了目前 Sidecar 的典型使用案例，以及面臨的挑戰，同時跟上遊社群一起合作，将阿裡經濟體的技術解決方案在社群落地，幫助更多的使用者.
作者簡介：
徐迪 螞蟻金服技術專家：負責螞蟻金融雲 PaaS 平台建設，Kubernetes 社群老兵，核心代碼庫貢獻量社群前50；
張曉宇 阿裡雲技術專家：負責阿裡巴巴雲原生應用容器平台的生态建設，主要設計和研發節點穩定性和資源使用率相關解決方案，同時也是 Kubernetes 社群熱心的成員和貢獻者。
“ 阿裡巴巴雲原生 關注微服務、Serverless、容器、Service Mesh 等技術領域、聚焦雲原生流行技術趨勢、雲原生大規模的落地實踐，做最懂雲原生開發者的技術圈。”