隨著雲原生時代的到來，越來越多的企業開始采用 Kubernetes《K8s》加速現代應用的開發和部署過程。
為了適應容器環境敏捷、可移植等特點，存儲作為 IT 基礎設施的核心組件，也需要進行雲化轉型，以滿足現代化應用在數據持久化和高效運行方面的需求。
目前，用戶在挑選容器存儲時，經常會聽到『K8s 持久化存儲』、『雲原生存儲』、『容器原生存儲』、『K8s 原生存儲』等不同的方案類型。
這些存儲方案有什麼區別？本文中，我們將深入探討這四個概念，幫助讀者更好地理解、選擇合適的容器存儲方案。
什麼是 K8s 持久化存儲
首先需要明確的是，相較於作為一種存儲方案類型，『K8s 持久化存儲』更常被用作為一種概念，與 K8s 上隨 Pod 銷毀或移動而無法持久化保存數據的存儲卷《Volume》相區分。
K8s 支持很多類型的卷，包括持久卷《PersistentVolume》和臨時卷《EphemeralVolume》。
臨時卷的生命周期與 Pod 一致，如 emptyDir，其存儲的數據會隨著 Pod 的銷毀而消失，僅可用作臨時存儲空間。
而持久卷的生命周期比 Pod 長，即使 Pod 銷毀也可保留下來。
值得注意的是，HostPath 雖然也是一種持久卷，但若 Pod 漂移到其他 Node 或當前 Node 故障，也無法保證數據持久化，因此有時被稱為『半持久化存儲』。
綜上所述，『K8s 持久化存儲』是指 K8s 在管理 Pod 數據時使用的一組抽象概念和資源。
這些概念包括 PersistentVolume《PV》、PersistentVolumeClaim《PVC》和 StorageClass。
它們為 K8s 中的應用程序提供了一種持久存儲數據的方法。
而雲原生存儲、K8s 原生存儲等則是實現 『K8s 持久化存儲』的具體技術、產品、方案。
也就是說，所有支持 K8s 環境中的應用數據持久化存儲的方案，都是『K8s 持久化存儲』，包括文中提到的雲原生存儲、容器原生存儲和 K8s 原生存儲。
什麼是雲原生存儲
雲原生存儲《Cloud Native Storage》是一種基於雲原生架構理念設計的存儲方案，雲原生計算基金會《CNCF》對此這樣形容：
雲原生存儲是針對新的雲原生環境而量身定制的：傳統存儲硬件與基礎設施緊密綁定，不同數據中心也可能使用不同的存儲接口，存儲置備也難以自動操作；而雲原生架構極具流動性、靈活性和彈性，容器化應用程序會不斷地創建和刪除，容器運行的物理位置也會發生變化，這些變化都對存儲方案提出了新的要求：
- 為容器提供雲原生存儲選項；
- 將容器和存儲提供商之間的接口標準化；
- 通過備份和恢復操作提供數據保護。
這意味著雲原生存儲需要使用雲原生兼容的容器存儲接口，並且可以自動進行置備，消除人為操作瓶頸，實現自動縮放和自我修復。
在 K8s 環境下，雲原生存儲使用提供標準 API 的容器存儲接口《CSI》提供存儲服務。
CNCF 認證的雲原生存儲包括開源的和商用的存儲產品《見下圖》。
CNCF Cloud Native Landscape – Cloud Native Storage
由此可見，『雲原生存儲』是一個廣泛的范疇，重點強調存儲方案對雲原生環境和接口標準化的支持特性，而並不區分存儲類型、存儲架構、部署環境、支持的應用負載等。
例如，用戶可以選擇基於分佈式塊存儲的商用閉源存儲方案，支持 I/O 密集的應用場景，也可以采用公有雲或開源的分佈式文件存儲產品，支持大數據量的文件存儲場景。
因此，當面對一個『雲原生存儲』產品時，用戶需要首先了解該存儲方案支持的存儲類型、存儲接入方式、存儲協議、兼容的容器運行時、對 CSI 的支持程度、支持的 K8s 資源類型《如 PersistentVolume、StorageClass 等》以及適用的應用場景。
CNCF Webinar Series – Cloud Native Storage
另外，雖然雲原生存儲為 K8s 提供數據持久化保存，但不是所有的 K8s 持久化存儲都是雲原生存儲，因為傳統的存儲解決方案也可以被用於 K8s。
例如，用戶依舊可以將本地磁盤作為『K8s 持久卷』，但這種方式並不能算作雲原生存儲產品或方案。
什麼是容器原生存儲和 K8s 原生存儲
一些雲原生廠商也將它們的存儲方案精確細分為『容器原生存儲《Container Native Storage》』類別。
根據 Gartner 的報告『2022 Strategic Roadmap for Storage』，『容器原生存儲是專門為支持容器工作負載而設計的，重點解決雲原生環境下獨特的規模、粒度和性能需求，同時與 K8s 容器管理系統深度集成』這些方案與雲原生存儲方案的主要區別在於，容器原生存儲與 K8s 的集成程度更深，能夠更好地支持在 K8s 運行的工作負載。
而且，由於 K8s 已經成為雲原生時代既定的容器編排工具，整個容器應用生態均以 K8s 為標準，因此『容器原生存儲』與『K8s 原生存儲』並沒有本質上的區別。
K8s 具備跨環境的一致性特性，它能夠支持應用在不同雲環境中實現自動彈性擴縮容、滾動更新和自我修復。
同時，K8s API 為應用部署和管理的標準化與自動化提供了堅實基礎。
因此，與核心業務緊密關聯的有狀態應用，如 MySQL、PostgreSQL、Cassandra 和 RabbitMQ 等，越來越多地運行在 K8s 環境中，期望其獲得與 K8s 同樣的彈性、標準化和自動化能力。
這些數據庫和消息中間件類應用在數據可靠性和性能方面，對 K8s 持久化存儲方案提出了更高的要求，推動了由雲原生存儲向容器/K8s 原生存儲的需求轉變。
容器/K8s 原生存儲方案通常具備以下特性：
- 基於分佈式、軟件定義的統一存儲池。
- 具有容器級別的數據服務粒度。
- 具備自動化存儲資源運維能力。
- API 驅動。
- 與 K8s 緊密集成《如支持與 K8s 工具鏈集成》。
- 可支持多種部署形式《如本地、邊緣》。
- 多種集成的高級數據服務《如容災備份、加密、數據縮減》。
由此可見，容器/K8s 原生存儲包含在雲原生存儲的范疇，但不是所有的雲原生存儲都可以被稱為容器/K8s 原生存儲。
基於此，我們可以將 K8s 持久化存儲、雲原生存儲、容器原生存儲和 K8s 原生存儲之間的關系，以下圖呈現：
在選擇容器存儲時，用戶應結合容器承載的應用需求和自身的建設條件，選擇合適的存儲方案。
尤其是對於 K8s 集群上的數據庫類、消息中間件類應用，應優先考慮采用性能更高、穩定性更強的容器/K8s 原生存儲方案《基於分佈式塊存儲》。
為了充分滿足現代化應用的存儲需求，SmartX 將在近期發佈 K8s 原生存儲新品，敬請期待！
參考文章：
1. Cloud Native Storage，CNCFhttps://landscape.cncf.io/guide#runtime–cloud-native-storage
2. CNCF Cloud Native Landscape
https://landscape.cncf.io/
3. 2022 Strategic Roadmap for Storage，Gartnerhttps://www.gartner.com/document/4012543
4. Cloud Native Storage – Webinar，CNCFhttps://www.cncf.io/wp-content/uploads/2020/08/CNCF-Storage-Final-1.pdf
- SmartX 發佈 K8s 雲原生存儲 IOMesh，加速有狀態應用容器化進程
- SmartX 發佈 SKS 1.0，一站式構建生產級 K8s 集群
- 如何部署運維 K8s？我們整理了 3 份 Gartner 報告，得到這些建議
- 選型 K8s 管理平臺需關注哪些核心能力？『附 Gartner 選型建議』
- 接管 K8s 部署運維，基礎架構團隊是否做好準備？丨SmartX 趨勢分享
- 如何利用 knest 構建數據中心的 Kubernetes as a Service？
- K8s 多租戶現有實現機制分析與優化
- Virtink：更輕量的 Kubernetes 原生虛擬化管理引擎
- 雲原生時代需要什麼樣的存儲系統
繼續閱讀
微信公眾訂閱號
掃一掃關注微信，獲取最前沿的 SmartX 資訊
資源
獲取相關資料
- 超融合從評估到落地：用戶常見問題解答
- SmartX 行業客戶案例集
- SmartX 超融合基礎設施及 SMTX Halo 一體機產品介紹
博客
- SmartX 發佈 K8s 雲原生存儲 IOMesh，加速有狀態應用容器化進程
- K8s 多租戶現有實現機制分析與優化
- 如何部署運維 K8s？我們整理了 3 份 Gartner 報告，得到這些建議
- 接管 K8s 部署運維，基礎架構團隊是否做好準備？｜SmartX 趨勢分享