文章根據 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✿)