文章根據 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?)
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/348208.html
標籤：其他