CSI 介紹

我們知道Kubernetes中關于使用存儲卷的機制有In-Tree、Flexvolume模式，那為何還要提出CSI方式呢？

In-Tree Volume: 這種方式需要将後端存儲的代碼邏輯放到K8S的代碼中運作，調用引擎與插件間屬于強耦合。插件的邏輯代碼需要K8S負責維護，可能會引起與K8S其他部件之間的互相影響。

Flexvolume: Kubelet通過調用一個主機的可執行程式包的方式執行存儲卷的挂載使用。解決了In-Tree方式的強耦合，不過由于Flexvolume作為指令行調用的方式，在主機安全性、部署依賴的容器化、與K8S服務之間的互相擴充性等方面存在不足。

Flexvolume運作在host 空間，不能使用rbac授權機制通路Kubernetes API，導緻其功能極大的受限。

CSI: 基于上述模式存在的不足，CSI标準使K8S和存儲提供者之間将徹底解耦，将存儲的所有的部件作為容器形式運作在K8S上。

在FlexVolume中Kubelet通過使用作業系統CLI實作調用Driver接口，而CSI采用的是grpc方式，grpc調用的一個優勢就是可以将grpc服務運作在socket上，這樣服務端就可以運作在socket端點的任何地方，即可以運作在容器裡。另外CSI接口使用同步方式進行調用，保證了存儲插件實作的簡單性。

從平台支援上，CSI不僅僅支援Kubernetes平台存儲插件接口，而是作為雲原生生态中容器存儲接口的标準，Mesos、CloudFoundry、Swarm等平台也同時支援CSI。

下圖給出了CSI接口在雲原生應用中的位置。

我們回顧一下CSI版本釋出曆程：

從2017年初發展到今天，CSI用了2了兩年的時間釋出了自己的穩定版本，且K8S對CSI的支援也進入到GA階段。