Container Storage Interface 基本介紹
本文開始又是嶄新的一篇,開始探討也是非常重要的儲存資源,儲存方面也有相關的標準再發展,其目的與 CRI 以及 CNI 一致,都是希望透過標準化接口能夠使得第三方的解決方案開發更加活絡且流暢,本文會開始來介紹儲存方面的基本概念以及為什麼需要 Container Storage Interface
本文開始又是嶄新的一篇,開始探討也是非常重要的儲存資源,儲存方面也有相關的標準再發展,其目的與 CRI 以及 CNI 一致,都是希望透過標準化接口能夠使得第三方的解決方案開發更加活絡且流暢,本文會開始來介紹儲存方面的基本概念以及為什麼需要 Container Storage Interface
本文針對 Container Storage Interface 的標準進行介紹,探討 CSI 本身標準涵蓋的範圍與流程,以及部署上的一些常見做法,包含多種服務器各自的角色與地位。
本篇文章著重於 Kubernetes 本身與 CSI 的關係,一直以來 kubernetes 甚至到 1.16 來說, CSI 都不是一個必需的設定,反而是依賴大量 in-tree 的整合程式碼來處理各式各樣的儲存後端,這雖然使用方便但是對於後續的擴充性,維護性,彈性都帶來的很大的危害。也因此 CSI 才有誕生的機會,所以對於長期使用 in-tree 的管理人員來說,勢必有一天要轉移到 CSI才有機會想到新的功能以及相關功能的修復
前述分享了關於不少 Container Storage Interface 的事情,接下來我們直接使用 NFS 作為範例,來看看要如何透過 CSI 的架構來掛載 NFS 到 kubernetes cluster 中供運算資源使用
本篇文章作為 Storage 的最後一塊,就沒有特別針對主題探討,反而是聊聊閒聊一些 Storage 方面的議題,順便聊聊 Mount 這個東西除了常見的功能之外,還有什麼參數可以使用,並且有什麼樣的效果。