文章根據 Juicedata 工程師朱唯唯，在雲原生 Meetup 杭州站所作主題演講《JuiceFS CSI Driver 的最佳實踐》整理而成。
大家好，我是來自 Juicedata 的朱唯唯，現在主要負責 JuiceFS CSI Driver 方面的開發，很高興今天有這個機會跟大家做一個分享和交流，我今天分享的題目是 “JuiceFS CSI Driver 的最佳實踐”。主要會從以下幾個方面給大家做一個分享：
- Kubernetes 儲存方案
- 如何在 Kubernetes 中使用 JuiceFS
- JuiceFS CSI Driver 架構設計實踐
Kubernetes 儲存方案
在 Kubernetes 裡面對儲存有三個概念，第一個是 PV，也就是持久卷，代表的是叢集中的一份儲存，可以定義儲存的型別、大小等，比如指定它是哪一種型別， NFS 或 GlusterFS ，也可以指定它是 CSI 的。第二個概念是 PVC，持久卷申明，代表的是 Pod 使用儲存的一份請求，Pod 不直接使用 PV 而是通過 PVC 來使用 PV。另一個是 StorageClass，持久卷型別，代表的是叢集中的儲存型別，它不定義儲存的大小，只定義型別，在使用的時候 Kubernetes 會根據 StorageClass 自動建立 PV。以上就是 Kubernetes 對 Pod 使用儲存所定義的三種資源。
apiVersion: v1 aversion: v1 apiVersion: v1
kind: PersistentVolume kind: PersistentVolumeClaim kind: Pod
metadata: metadata: metadata:
name: pv0001 name: myclaim name: pv-recycler
labels: spec: spec:
pv: pv0001 accessModes containers:
spec: - ReadWriteMany - name: pv-recycler
capacity: volumeMode: Filesystem image: "nginx"
storage: 5Gi resources volumeMounts:
volumeMode: Filesystem requests: - name: my-volume
accessModes: storage: 5Gi mountPath: /root/data
- ReadWriteMany selector: volumes:
hostPath: matchLabels: - name: my-volume
path: /root/data/test pv: pv0001 persistentVolumeClaim:
claimName: myclaim
我們再來看一下在 Kubernetes 中 Pod 怎樣使用儲存，主要有兩種方式，第一種是靜態儲存，就是 PV 加 PVC 的方式，可以看上圖的幾個 yaml 檔案，第一個就是 PV 的 yaml 檔案。一般由系統管理員先在叢集中建立一份 PV，然後在使用的時候建立一個 PVC ，指定使用哪個 PV，但是一個 PV 只能被一個 Pod 使用，每當有新的 Pod 需要使用儲存時，系統管理員也要建立相應的 PV，並在 PV 裡面是指定它有多大的儲存量，用什麼樣的訪問方式以及它是什麼型別的，文中給出來的例子就是 hostPath，當然也可以在這裡指定它為 Kubernetes 內建的一些儲存型別，比如 NFS 、CSI，如果是 CSI 的話，那就需要我們第三方去實現關於 CSI 的一個外掛。
PV 定義好了之後，在叢集裡面就代表有這麼一份儲存可以用，當 Pod 在使用該 PV 的時候，需要使用者提前先去建立一個 PVC 的資源，然後在 PVC 中去指定用什麼樣的方式去訪問儲存，以及需要用多大的容量，當然這個容量不能超過 PV 中指定的已有容量。也可以用 label select 的方式去指定這個 PVC 使用哪個 PV ，以上就完成了一個 PVC 資源的建立。
當 PVC 建立好了之後 Pod 就可以直接使用了，使用的方式就是當掛載在 volume 的時候指定一下 Claim 是哪一個 PVC 就可以了。這是靜態儲存的方案，但是這種方案有一個問題，一個 PV 只能被一個 PVC 使用，當 Pod 被執行起來在使用 PV 的時候， PV 的狀態也就會被 Kubernetes 改成 Bound 狀態，它一旦是 Bound 狀態，另一個 Pod 的 PVC 就不能使用了。那也就意味著每當有新的 Pod 需要使用儲存時，系統管理員也要建立相應的 PV，可想而知系統管理員的工作量會很大。
apiVersion: storage.k8s.io/v1 aversion: v1 apiVersion: v1
kind: StorageClass kind: PersistentVolumeClaim kind: Pod
metadata: metadata: metadata:
name: example-nfs name: myclaim name: pv-recycler
provisioner: example.com/external-nfs spec: spec:
parameters: accessModes: containers:
server: nfs-server.example.com - ReadWriteMany - name: pv-recycler
path: /share volumeMode: Filesystem image: "nginx"
readOnly: false resources: volumeMounts:
requests: - name: my-volume
storage: 5Gi mountPath: /root/data
storageClassName: example-nfs volumes:
- name: my-volume
persistentVolumeClaim:
claimName: myclaim
另一種方式是動態儲存，動態儲存的方式就是 StorageClass + PVC 使用方式也類似，就是系統管理員先在叢集中建立一份 StorageClass，只需指定儲存型別，以及它的一些訪問引數。在 Pod 在使用的時候依然是建立一個 PVC 指定它需要使用多大容量以及它的訪問方式，再指定 StorageClass ，然後 Pod 裡面使用和上文是一樣的。但在該方案中當 Kubernetes 在建立 Pod 之前會根據 StorageClass 中指定的型別和 PVC 中指定的容量大小等引數，自動建立出對應的 PV，這種方式相比之下解放了系統管理員。
無論是 PV 還是 StorageClass，在指定儲存型別的時候，可以使用 Kubernetes 內建的儲存型別，比如 hostPath、NFS 等，還有一種方式就是 CSI，第三方雲廠商通過實現 CSI 介面來為 Pod 提供儲存服務。JuiceFS 也實現了自己的 CSI Driver。
什麼是 JuiceFS
JuiceFS 是一款面向雲環境設計的高效能共享檔案系統，可以被多臺主機同時掛載讀寫，使用物件儲存來作為底層的儲存層，我們沒有重複造輪子，而是選擇了站在物件儲存的肩膀上。物件儲存大家都知道它有很多好處，一個是低價排量、高吞吐、高可用性，但是它同時也有很多缺點，比如很重要的一點就是它沒有目錄的管理能力，對於檔案系統來說，使用者訪問起來不是很方便，同時它就只有HTTP介面，並且是按照呼叫次數收費的。
針對物件儲存的這種問題，我們引入了後設資料服務，通過這方式我們可以在物件儲存的基礎上提供完備的 POSIX 相容性。我們對外提供各種各樣的介面，包括 POSIX 介面，各種網路儲存協議以及各種各樣的 SDK，通過這樣的一種架構，我們可以將海量低價的雲端儲存作為本地磁碟使用成為了一種可能。
如何在 Kubernetes 中使用 JuiceFS？
Kubernetes 是目前最流行的一種應用編排引擎，將資源池化，使得使用者不再需要關心底層的基礎設施和基礎資源，這一點 JuiceFS 的設計理念是相同的。同時 Kubernetes 也提供了一些宣告式 API 並且它的可擴充性很強，它提供了一種 CSI 的一種接入方式，讓 JuiceFS 可以很方便的接入進來，
在 Kubernetes 中使用 JuiceFS 十分簡單，我們提供了兩種安裝方式，helm chart 安裝和 Kubernetes yaml 直接 apply，任意一種方式都可以做到一鍵安裝部署。然後再準備一個後設資料引擎和物件儲存服務就可以直接通過 Kubernetes 原生方式，在 Pod 裡直接使用 Juicefs 型別的儲存了。
在 KubeSphere 中使用 JuiceFS 就更簡單了。在介面上通過「應用模板」上傳 chart 包或者在「應用倉庫」中新增 JuiceFS 的官網 chart 倉庫地址，就可以直接安裝 Juicefs CSI Driver 了，然後在 KubeSphere 中使用和原生的 Kubernetes 使用方式是一樣的，後續我們會把 JuiceFS 做為 Kubesphere 的原生外掛，在部署 Kubesphere 之後即可直接使用，大家可以期待一下。
CSI 工作原理
如果大家平時使用過 CSI 或者接觸過它的一些原理的話，我們會知道它其實很複雜，CSI 的官方提供了很多外掛，主要有兩種方式，一種是 CSI 內部的元件，另一種是外部的，內部的話我們在這裡就不介紹了，我們只介紹外部的兩類外掛，一類是需要我們自己去實現的外掛，CSI Controller，CSI Node 和 CSI Identity ，還有一類就是官方提供的一些 SideCar，這些 SideCar 全部都是配合以上三個外掛去完成儲存的所有功能。
CSI Controller，它是以 deployment 的形式執行在叢集裡面，主要負責 provision 和 attach 工作。當然 attach 不是每一個儲存都會用到的，而 provision 就是在使用 StorageClass 的時候會動態建立 PV 的過程，所以 CSI Controller 在實現 provision 這個功能的時候，是 external-provisioner 這個 SideCar 去配合實現的，在實現 attach 功能的時候是 external-attacher 配合它一起完成的。
CSI Node 和 CSI Identity 通常是部署在一個容器裡面的，它們是以 daemonset 的形式執行在叢集裡面，保證每一個節點會有一個 Pod 部署出來，這兩個元件會和 CSI Controller 一起完成 volume 的 mount 操作。CSI Identity 是用來告訴 Controller，我現在是哪一個 CSI 外掛，它實現的介面會被 node-driver-registrar 呼叫給 Controller 去註冊自己。CSI Node 會實現一些 publish volume 和 unpublished volume 的介面，Controller 會去呼叫來完成 volume 的 mount 的操作，我們只需要實現這幾個外掛的介面就可以了。
Provision 過程
上文介紹的 Kubernetes 中的動態儲存方案，是管理員只需要建立 StorageClass，然後使用者建立 PVC，由 Kubernetes 自動的幫你建立 PV 的這麼一個過程，其中具體的流程如上圖所示，首先是 PVController 會去向 API Server 監聽 PVC 資源的建立，它監聽到 PVC 資源的建立會給 PVC 打上一個註解，註解裡告訴 Kubernetes 是現在 PVC 使用的是哪一個 CSI 然後同時 external-provisioner 這個 SideCar 也會去監聽 PVC 的資源，如果註解資訊和自己的 CSI 是一樣的話，它就會去呼叫 CSI controller 的介面去實現建立 volume 的邏輯，這個介面呼叫成功之後，external-provisioner 就會認為 volume 已經建立好了，然後就會去對應的建立 PV。
Mount 過程
PV 建立好了之後就到了 Mount 的過程，還是那張圖，但是呼叫介面不一樣，在 Mount 過程中參與的元件是 Kubelet 和 CSI Node。Kubelet 在建立 Pod 之前會去幫它準備各種各樣的執行環境，包括需要宣告儲存的環境，這些環境準備好之後 Kubelet 才會去建立 Pod，那麼準備 volume 的環境就是 Kubelet 去呼叫 CSI Node Plugin 的介面去實現的，在這個介面裡面去實現 volume 的 mount 過程就完成了整個 Pod 所需要的一些儲存環境。這些整個完成之後，Kubelet 的才會建立 Pod。
JuiceFS CSI Driver 的設計
CSI Driver 遇到的挑戰
JuiceFS CSI Driver 最初的架構設計是這樣的，我們實現了 CSI 的幾個介面和常見的基本一樣，不同的就是我們在 NodeService 元件裡面，我們會去實現 JuiceFS mount 這個過程。
由於 JuiceFS 是使用者態檔案系統，CSI 在完成 Mount 工作的時候，首先是會在節點上建立一個掛載點，同時會 fork 出一個 mount 程式，也就是 JuiceFS 客戶端。而程式它是直接執行在 CSI Node 的 Pod 裡的，掛載點準備好之後，我們還會在介面裡面把這個機器上的掛載點 bind 到 kubelet target 路徑。這個程式直接執行在 CSI Pod 裡，有多少 Volume 就會有多少程式同時執行在這個 Pod 裡，這樣的實現就會帶來一系列的問題。
首先，JuiceFS 客戶端之間沒有資源隔離，而且程式直接執行在 CSI Pod 裡會導致 Kubernetes 叢集對客戶端程式無感知，當客戶端程式意外退出的時候，在叢集中是看不出任何變化的；最關鍵的是 CSI Driver 不能平滑升級，升級的唯一方式就是，先把使用者所有使用到 JuiceFS 的 Pod 全部停掉，然後升級，升級完再把所有的業務 Pod 一個個再執行起來。這樣的升級方式對於運維同學來說簡直是災難；另外一個問題是 CSI Driver 的爆炸半徑過大，跟第三點類似，CSI Driver 一旦退出，那執行在裡面的 JuiceFS 客戶端都不能正常使用。
CSI Driver 架構升級
針對這些問題，我們對 CSI Driver 的架構設計進行了一些改進。具體的做法就是將執行 volume 掛載的操作在單獨的 Pod 裡執行，這樣 fork 出來的程式就可以執行在 Pod 裡了。如果有多個的業務 Pod 共用一份儲存，mount Pod 會在 annotation 進行引用計數，確保不會重複建立。每當有業務 Pod 退出時，mount Pod 會刪除對應的計數，只有當最後一個記錄被刪除時 mount Pod 才會被刪除。還有一點是 CSI Node 會通過 APIService watch mount Pod 的狀態變化，以管理其生命週期。我們一旦觀察到它意外退出，及它 Pod 的退出了，但是它的 annotation 還有計數，證明它是意外退出，並不是正常的一個被刪除，這樣的話我們會把它重新起來，然後在業務的容器的 target 路徑重新執行 mount bind，這是我們目前還在開發的一個功能。
架構升級的益處
- 最直接的好處就是 CSI Driver 被解耦出來了，CSI driver無論做什麼操作都不會影響到客戶端，做升級不會再影響到業務容器了，
- 將 JuiceFS 客戶端獨立在 Pod 中執行也就使其在 Kubernetes 的管控內，可觀測性更強；
- 同時 Pod 的好處我們也能享受到，比如隔離性更強，可以單獨設定客戶端的資源配額等。
未來展望
對於未來我們還會去做一些工作，目前我們把 JuiceFS 客戶端的程式執行在單獨的 Pod 裡，但是對於 FUSE 程式在容器環境的高可用性依然存在很大的挑戰，這也是我們今後會一直關注探討的問題。另外我們也在持續摸索對於 JuiceFS 在雲原生環境更多的可能性，比如使用方式上面除了 CSI 還會有 Fluid、Paddle-operator 等方式。
推薦閱讀：
百億級小檔案儲存，JuiceFS 在自動駕駛行業的最佳實踐
專案地址： Github （https://github.com/juicedata/juicefs）如有幫助的話歡迎關注我們喲！ (0ᴗ0✿)