近期釋出的 JuiceFS CSI Driver v0.18 版本中，我們提供了一種全新的方式訪問檔案系統，即 JuiceFS 客戶端以 Sidecar 方式執行於應用 Pod 中，且客戶端與應用同生命週期。
這個全新的功能將幫助使用者在 Serverless Kubernetes 環境中使用 JuiceFS；與傳統的 Mount Pod 模式相比，問題排查更方便、客戶端管理更簡單。
今天在這篇文章中，將為大家介紹 Sidecar 模式的工作原理以及應用場景， 另外在文末還附上了使用者關心的問題與解答。
What is a sidecar in cloud?
Sidecar 是一種常見的設計模式，這個概念在容器和微服務的領域中非常流行。回到 sidecar 的字面意思，如下圖所示，就是指摩托車邊上安裝的這個小車，以增加摩托車的承載能力，它非常形象地表達了Sidecar 容器和應用容器的關係。在雲環境中，他們成為一體，共享 Kubernetes pod 的環境，並且同一 pod 內的所有容器生命週期一致。
基礎介紹
一些名詞解釋
• Pod：可以在 Kubernetes 中建立和管理的、最小的可部署的計算單元
• Deployment / DaemonSet / StatefulSet / Job：宣告式資源，對 Pod 的不同管理方式
• PV（PersistentVolume）：叢集中的一塊儲存
• PVC（PersistentVolumeClaim）：表達的是使用者對儲存的請求
• StorageClass：為管理員提供了描述儲存 "類" 的方法
• CSI（Container Storage Interface）：容器儲存介面
如何使用
儲存的管理是一個與計算例項的管理完全不同的問題。PV 表示的是叢集中的一塊儲存，可以由管理員事先建立；或者使用 StorageClass 來動態建立，然後使用者在 Pod 中透過指定 PVC 來使用。根據 PV 的建立方式，可以分為靜態配置和動態配置兩種使用方式，下面一一介紹。
靜態配置
由系統管理員建立若干 PV，在 PV 中宣告包含了 JuiceFS 系統引數的 Secret，以備使用者使用。使用者建立 PVC，宣告使用具體的 PV，在應用 Pod 中配置使用 PVC 即可。
資源間的關係如下圖所示：
靜態配置每一個應用使用都需要系統管理員對應建立一個 PV，在簡單測試場景或者應用間資料共享時使用比較廣泛。
動態配置
由系統管理員建立 StorageClass，在 StorageClass 中宣告包含了 JuiceFS 系統引數的 Secret；然後使用者建立 PVC，宣告使用具體的 StorageClass，PVC 建立之後，Kubernetes 會根據 StorageClass 自動建立出一個 PV 與 PVC 進行繫結，最後使用者在應用 Pod 中配置使用 PVC。
資源間的關係如下圖所示：
JuiceFS CSI Driver 的工作原理
使用者透過在 PV / StorageClass 中指定 JuiceFS 的引數，進而在叢集中使用 JuiceFS。JuiceFS CSI Driver 則負責掛載 JuiceFS 檔案系統。
JuiceFS CSI Driver 提供了兩種方式掛載檔案系統，一種是現有的 Mount Pod 模式，另一種則是本次釋出的版本中提供的 Sidecar 容器的方式。下面一一介紹兩種模式以及二者的對比。
Mount Pod 模式
元件
Mount Pod 模式涉及到的元件包括 CSI Controller Service 和 CSI Node Service，職責分別為：
• Controller Service：以 PV id 為名，在 JuiceFS 檔案系統中建立子目錄。
• Node Service：建立 Mount Pod（JuiceFS 客戶端），並掛載應用 Pod。下文會詳細介紹其工作機制。
這種模式對環境的要求：
• 可以使用 FUSE 裝置，在容器中體現為需要特權（Privilege）；
• 可以執行 DaemonSet ，預設每臺機器上都需要執行一個 CSI Node pod。
工作原理
CSI Node Service 的工作機制如下圖所示：
- 使用者建立應用 Pod，Pod 中宣告使用 JuiceFS 的 PVC；
- CSI Node 負責在應用 Pod 所在節點建立 Mount Pod；
- Mount Pod 啟動，執行 JuiceFS 客戶端掛載，執行 JuiceFS 客戶端，掛載路徑暴露在宿主機上；
- CSI Node 等待 Mount Pod 啟動成功後，將 PV 對應的 JuiceFS 子目錄 bind 到容器內，路徑為其宣告的 VolumeMount 路徑；
- Kubelet 建立應用 Pod。
PVC 與 Mount Pod 的關係
PVC、PV 和 Pod 的關係可以用下圖表示，即在同一個節點上，一個 PVC 會對應一個 Mount Pod。
Sidecar 模式
元件
JuiceFS FUSE 客戶端以 sidecar 容器的方式與應用容器一起執行在同一個 Pod 中。
CSI Driver 元件只有 CSI Controller Service。其職責為：
- 以 PV id 為名在 JuiceFS 檔案系統中建立子目錄；
- 向 ApiServer 註冊 webhook，在 pod 中注入 JuiceFS 客戶端的 sidecar 容器。
工作原理
工作機制如下圖所示：
- CSI Controller 啟動時向 ApiServer 註冊 webhook；
- 應用 Pod 指定使用 JuiceFS 的 PVC；
- ApiServer 在建立應用 Pod 前呼叫 CSI Controller 的 webhook 介面；
- CSI Controller 嚮應用 Pod 中注入 JuiceFS 客戶端容器（sidecar）；
- ApiServer 建立 Pod，sidecar 容器啟動後執行掛載，並執行 JuiceFS 客戶端，客戶端則按需訪問後設資料引擎和物件儲存；應用容器啟動後可直接訪問檔案系統。
PVC 與 Sidecar 的關係
PVC、PV 和 Pod 的關係可以用下圖表示，即每個應用 pod 單獨擁有自己的 JuiceFS 客戶端，應用的掛載點相互隔離。
這種模式下，對環境的要求是可以使用 FUSE 裝置，在容器中體現為需要特權（Privilege）容器。
Sidecar 容器的資源請求預設為 1 CPU 和 1GiB 記憶體，資源約束預設為 2 CPU 和 5GiB 記憶體。當叢集資源緊俏時，我們還可以在 PV/StorageClass 中對 Sidecar 容器的使用資源進行配置。
另外，Sidecar 容器和應用容器的掛載點共享是透過 HostPath 實現的，不是直接共享，所以當 Sidecar 容器發生意外重啟後，應用容器中的掛載點不會自行恢復，需要整個 Pod 重新建立。
兩種模式的優缺點及使用場景
Sidecar 模式：
• 優勢：故障排查簡單；所有環境都可用；
• 缺點：資源開銷大，每個應用 Pod 獨享 JuiceFS 客戶端；
• 使用場景：Serverless Kubernetes 環境（可以使用 FUSE）；應用任務量不大的標準 Kubernetes 環境。
Mount Pod 模式：
• 優勢：資源開銷小，使用相同 PVC 的所用應用 Pod 共享同一個 JuiceFS 客戶端；
• 缺點：故障排查複雜；Serverless 環境不可用。
• 使用場景：應用任務較多、標準的 Kubernetes 環境。