![頭圖.png](https://ucc.alicdn.com/pic/developer-ecology/f1100ca513194334880c75dbb60d13c6.png)

作者| 郡寶 阿里雲技術專家

**參與文末留言互動，即有機會獲得贈書福利！**

導讀：儲存服務支撐了應用的狀態、資料的持久化，是計算機系統中的重要組成部分，也是所有應用得以執行的基礎，其重要性不言而喻。在儲存服務演進過程中，每一種業務型別、新技術方向都會對儲存的架構、效能、可用性、穩定性等提出新的要求，而在當今技術浪潮走到雲原生技術普及的時代，儲存服務需要哪些特性來支援應用呢？

從本文開始，我們將用一個系列文章對雲原生儲存進行方方面面的探析，該系列文章將從雲原生儲存服務的概念、特點、需求、原理、使用、案例等方面，和大家一起探討雲原生儲存技術新的機遇與挑戰，歡迎大家討論：

```
"There is no such thing as a 'stateless' architecture" - Jonas Boner
```

> 雲原生儲存系列文章(一)：雲原生應用的基石
> 雲原生儲存系列文章(二)：容器儲存與K8S儲存卷
> 雲原生儲存系列文章(三)：Kubernetes儲存架構
> 雲原生儲存系列文章(四)：K8S儲存實踐-Flexvolume
> 雲原生儲存系列文章(五)：K8S儲存實踐-CSI
> 雲原生儲存系列文章(六)：儲存卷高可用方案
> 雲原生儲存系列文章(七)：儲存排程與容量感知
> 雲原生儲存系列文章(八)：資料卷擴縮容能力
> 雲原生儲存系列文章(九)：雲原生儲存安全
> 雲原生儲存系列文章(十)：高效能運算場景的儲存最佳化

本節會介紹雲原生儲存的基本概念和常用的儲存方案。

# 雲原生儲存

## 1.概念

要理解雲原生儲存，我們首先要了解雲原生技術的概念，CNCF 對雲原生定義如下：

> 雲原生技術有利於各組織在公有云、私有云和混合雲等新型動態環境中，構建和執行可彈性擴充套件的應用。雲原生的代表技術包括容器、服務網格、微服務、不可變基礎設施和宣告式 API。
> 這些技術能夠構建容錯性好、易於管理和便於觀察的松耦合系統。結合可靠的自動化手段，雲原生技術使工程師能夠輕鬆地對系統作出頻繁和可預測的重大變更。

簡言之：雲原生應用和傳統應用並沒有一個標準的劃分界限，其描述的是一種技術傾向，即越符合以下特徵的應用越雲原生：

- 應用容器化
- 服務網格化
- 宣告式 API
- 執行可彈性擴充套件
- 自動化的 DevOps
- 故障容忍和自愈
- 平臺無關，可移植的

雲原生應用是一簇應用特徵能力的集合，而實現了這些能力的應用在可用性、穩定性、擴充套件性、效能等核心能力都會有大幅的最佳化。優異的能力代表了技術的方向，雲原生應用正在引領各個應用領域實現雲原生化，同時也在深刻改變著應用服務的方方面面。儲存作為應用執行的基石，也在服務雲原生化過程中提出了更多的需求。

雲原生儲存的概念來源於雲原生應用，顧名思義：一個應用為了滿足雲原生特性的要求，其對儲存所要求的特性是雲原生儲存的特性，而滿足這些特性的儲存方案，可以稱其為傾向雲原生的儲存。

## 2.雲原生儲存特徵

### 1）可用性

儲存系統的可用性定義了在系統故障情況下訪問資料的能力，故障可以是由儲存介質、傳輸、控制器或系統中的其他元件造成的。可用性定義系統故障時如何繼續訪問資料，以及在部分節點不可用時如何將對資料的訪問重新路由到其他的可訪問節點。

可用性定義了故障的恢復時間目標（RTO），即故障發生與服務恢復之間的時長。可用性通常計算為應用執行時間中的可用時間的百分比（例如 99.9%），以及以時間單位度量的 MTTF（平均故障時間）或 MTTR（平均修復時間）來度量。

### 2）可擴充套件性

儲存的可擴充套件性主要衡量以下引數指標：

- 擴充套件可以訪問儲存系統的客戶端數量的能力，例如：一個 NAS 儲存卷同時支援多少客戶端掛載使用；
- 擴充套件單個介面的吞吐量和 IO 效能；
- 擴充套件儲存服務單例項的容量能力，例如：雲盤的擴容能力。

### 3）效能

衡量儲存的效能通常有兩個標準：

- 每秒支援的最大儲存運算元 - IOPS；
- 每秒支援的最大儲存讀寫量 - 吞吐量；

雲原生應用在大資料分析、AI 等場景得到廣泛應用，在這些重吞吐 / IO 場景中對儲存的需求也非常高，同時雲原生應用的快速擴容、極致伸縮等特性也會考驗儲存服務在短時間內迎接峰值流量的能力。

### 4）一致性

儲存服務的一致性是指在提交新資料或更新資料後，訪問這些新資料的能力；根據資料一致性的延遲效果，可以將儲存分為：“最終一致”和“強一致”儲存。

不同的服務對儲存一致性的敏感度是不一樣的，像資料庫這類對底層資料準確性和時效性要求非常高的應用，對儲存的要求是具有強一致性的能力。

### 5）永續性

多個因素應用資料的永續性：

- 系統冗餘等級；
- 儲存介質的耐久性（如：SSD 或 HDD）；
- 檢測資料損壞的能力，以及使用資料保護功能重建或恢復損壞資料的能力。

## 3.資料訪問介面

在雲原生應用系統中，應用訪問儲存服務有多種方式。從訪問介面型別上可以分為：資料卷方式、API 方式。

![1.png](https://ucc.alicdn.com/pic/developer-ecology/be49cd51c64b4cd693dc91972750adf7.png)

> 資料卷：將儲存服務對映為塊或檔案系統方式共應用直接訪問，使用方式類似於應用在作業系統中直接讀寫本地目錄檔案。例如：可以將塊儲存、檔案儲存掛載到本地，應用可以像訪問本地檔案一樣對資料捲進行訪問；
> API：有些儲存型別並不能使用掛載資料卷的方式進行訪問，而需要透過呼叫 API 的方式進行。例如：資料庫儲存、KV 儲存、物件儲存，都是透過 API 的方式進行資料的讀寫。

需要說明的是物件儲存型別，其標準使用方式是透過 Restful API 對外提供了檔案的讀寫能力，但也可以使用使用者態檔案系統的方式進行儲存掛載，使用方式模擬了塊、檔案儲存資料卷掛載的方式。

下面表格列舉了各種儲存介面的優缺點：

![2.jpg](https://ucc.alicdn.com/pic/developer-ecology/6e33287ea2434ce6a232e906bd7e5fcc.jpg)

## 4.雲原生儲存分層

![3.png](https://ucc.alicdn.com/pic/developer-ecology/c7316317903a41c09b3381bd305686ac.png)

### 1）編排和作業系統層

這一層定義了儲存資料的對外訪問介面，即應用訪問資料時儲存所表現的形式。同上節所述，可以分為資料卷方式和 API 訪問方式。這一層是容器服務儲存編排團隊關注的重點，雲原生儲存對敏捷性、可操作性、擴充套件性等方面的需求都在這一層整合、實現。

### 2）儲存拓撲層

這一層定義了儲存系統的拓撲結構和架構設計，定義了系統不同部分是如何相互關聯和連線的（如儲存裝置、計算節點和資料）。拓撲結構在構建時影響儲存系統的許多屬性，因此必須加以考慮。

儲存拓撲可以是集中式的、分散式的、或超融合的。

### 3）資料保護層

定義如何透過冗餘的方式對資料進行保護。在儲存系統出現故障時，如何透過資料冗餘對資料進行保護、恢復非常重要。通常有以下幾種資料保護方案：

- RAID（獨立磁碟冗餘陣列）：用於在多個磁碟之間的分發資料技術，同時考慮到冗餘；
- 擦除編碼：資料被分成多個片段，這些片段被編碼，並與多個冗餘集合一起儲存，保證資料可恢復；
- 副本：將資料分佈在多個伺服器上，實現資料集的多個完整副本。

### 4）資料服務

資料服務補充了核心儲存功能以外的儲存能力，例如可以提供儲存快照、資料恢復、資料加密等服務。
資料服務所提供的補充能力也正是雲原生儲存所需要的，雲原生儲存正是透過整合豐富資料服務來實現其敏捷、穩定、可擴充套件等能力。

### 5）物理層

這一層定義了儲存資料的實際物理硬體。物理硬體的選擇影響系統的整體效能和儲存資料的持續性。

## 5.儲存編排

雲原生意味著容器化，而容器服務場景中通常需要某種管理系統或者應用編排系統。這些編排系統與儲存系統的互動可以實現工作負載與儲存資料的關聯。

![4.png](https://ucc.alicdn.com/pic/developer-ecology/59ce7c4cfb6440139ade268a38895a03.png)

如上圖所示：

- 負載：表示應用例項，會消費底層儲存資源；
- 編排系統：類似於 K8s 一樣的容器編排系統，負責應用的管理和排程；
- 控制平面介面：指編排系統排程、運維底層儲存資源的標準介面，例如 K8s 裡面的 Flexvolume，已經容器儲存通用的 CSI 介面；
- 工具集：指控制平面介面運維儲存資源時所依賴的三方工具、框架；
- 儲存系統：分為控制平臺資料資料平面。控制檯平面對外暴露介面，提供儲存資源的接入、接出能力。資料平面提供資料儲存服務。

當應用負載定義了儲存資源需求時，編排系統會為應用負載去準備這些儲存資源。編排系統透過呼叫控制平面介面，進而實現對儲存系統控制平面的呼叫，這樣就實現了應用負載對儲存服務的接入、接出操作。當實現了儲存系統接入後，應用負載可以直接訪問儲存系統的資料平面，即可以直接訪問資料。

# 常見的雲原生儲存方案

## 1.公有云儲存

每個公有云服務提供商都會提供各種雲資源，其中也包含了各種雲端儲存服務。以阿里云為例，其幾乎提供了能夠滿足所有業務需要的儲存型別，包括：物件儲存、塊儲存、檔案儲存、資料庫等等。公有云儲存的優勢是規模效應，足夠大的體量實現了巨大研發、運維投入的同時，提供低廉的價格優勢。而且公有云儲存在穩定性、效能、擴充套件性方面都能輕鬆滿足您的業務需求。

隨著雲原生技術的發展，各個公有云廠商都開始對其雲服務進行雲原生化改造或適配，提供更加敏捷、高效的服務來適應雲原生應用的需求。阿里雲端儲存服務也在雲原生應用適配做了很多最佳化，阿里雲容器服務團隊實現的 CSI 儲存驅動無縫的銜接了雲原生應用和儲存服務之間的資料介面。實現了使用者使用儲存資源時對底層儲存無感知，而專注於自己的業務開發。

![5.png](https://ucc.alicdn.com/pic/developer-ecology/b31944233f40446ba2053fcd2c15a94c.png)

**優點如下所示：**

- **高可靠性**：多數雲廠商都可以提供服務穩定性、資料可考慮下都非常優異的服務，例如：阿里雲ebs提供了9個9的可靠性的服務，為您的資料安全提供了強有力的基礎保障能力；

- **高效能**：公有云對不同的服務提供了不同等級的儲存效能適配，幾乎可以滿足所有應用型別對儲存效能的需求。阿里雲 EBS 可以提供百萬級別的 IOPS 能力，接近本地盤的訪問效能。NAS 服務最大提供每秒數十 G 的吞吐能力，在資料共享的應用場景滿足您的高效能需求。而 CPFS 高效能併發檔案系統最高可以提供近 TB 級別的吞吐能力，更是可以滿足一些極端高效能運算對儲存的需求；

- **擴充套件性好**：公有云儲存服務一般都提供了容量擴容能力，讓您在應用對儲存的需求增加的時候可以動態的實現容量伸縮，且實現應用的無感知；

- **安全性高**：不同的雲端儲存服務都提供了資料安全的保護機制，透過 KMS、AES 等加密技術實現資料的加密儲存，同時也實現了客戶端到服務的鏈路加密方案，讓資料傳輸過程中也得到加密保護；

- **成熟的雲原生儲存介面**：提供了相容所有儲存型別的雲原生儲存介面，讓您的應用無縫的接入不同儲存服務。阿里雲容器服務提供的 CSI 介面驅動已經支援了：雲盤、OSS、NAS、本地盤、記憶體、LVM等多種儲存型別，可以讓應用無感知的訪問任何的儲存服務型別；

- **免運維**：相對於自建儲存服務來說，公有云儲存方案省去了運維的難度

**缺點如下所示：**

- **定製化能力差**：由於公有云儲存方案需要服務所有使用者場景，其能力主要集中在一些通用需求，而對某些使用者個性化需求很難滿足。

## 2.商業化雲端儲存

在很多私有云環境中，業務方為了實現資料的高可靠性通常會購買商業化的儲存服務。這種方案為使用者提供了高可用、高效、便捷的儲存服務，且運維服務、後期保障等也都有保證。私有云儲存提供商也意識到雲原生應用的普及，也會為使用者提供完善的、成熟的雲原生儲存介面實現方案。

**優點如下所示：**

- **安全性好**：私有云部署，可以從物理上實現資料的安全隔離；
- **高可靠、高效能**：很多雲端儲存提供商都是在儲存技術上深耕多年，具有優異的技術能力和運維能力，其商業化儲存服務可以滿足多數應用的效能、可靠性的需求；
- **雲原生儲存介面**：從多家儲存服務提供商開源的專案可以看出，其對雲原生應用的支援已經實現或者展開。

**缺點如下所示：**

- **貴**：商業化的儲存服務加個多數都很昂貴；
- **雲原生儲存介面相容性**：商業化的雲原生儲存介面都是針對其一家的儲存型別。多數使用者會使用不同的儲存型別，而使用了不同家的儲存服務，很難實現統一的儲存接入能力。

## 3.自建儲存服務

對於一些 SLA 要是不是很高的業務資料，很多公司都會選擇使用自建的方式提供儲存服務。業務方需要透過當前的開源的儲存方案，並結合自建的業務需求進行方案選擇。

- **檔案儲存**：考慮 CephFS、GlusterFS、NFS 等方案。其中 CephFS，GlusterFS 在技術的成熟度上還需要進一步驗證，且在高可靠、高效能場景上也存在不足。而 NFS 雖然已經成熟，但是自建叢集在效能上很難達到高效能應用的需求。

- **塊儲存**：例如 RBD、SAN 等是常見的塊儲存方案，技術也相對比較成熟，已經有較多的公司將其應用在自己的業務上。但其複雜度也相對很高，需要有專業的團隊來運維支援。

**優點如下所示：**

- **業務匹配度高、靈活性好**：可以在眾多開源方案中選擇最適合自己業務的方案，且可以在原生程式碼的基礎上進行二次開發來最佳化業務場景；
- **安全性好**：如果搭建在公司內部使用，則具有物理隔離的安全性；
- **雲原生儲存介面**：常用的開源儲存方案都可以在社群找到雲原生儲存介面的實現，且可以在其基礎上進行開發、最佳化。

**缺點如下所示：**

- **效能欠佳**：多數開源的儲存方案其原生的效能表現並不是很好。當然您可以透過架構設計、物理硬體升級、二次開發等方案進行最佳化；
- **可靠性差**：開源儲存方案在可靠性方面無法和商業化的儲存比較，所以更多場景是應用在 SLA 低的資料儲存場景；
- **雲原生儲存外掛魚龍混雜**：目前網上開源的雲原生儲存驅動版本眾多，且質量參差不齊，有些專案存在 bug，且長期無人維護，所以使用時需要更多的甄別和調測工作；
- **專業的團隊支撐**：自己搭建的服務需要自己負責，面對並不是十分成熟的開源方案，需要組建一個具有較強技術能力的專業團隊來運維、開發儲存系統。

## 4.本地儲存

一些業務型別不需要高可用分散式儲存服務，而會選擇使用效能表現更優的本地儲存方案。

資料庫類服務：對儲存的 IO 效能、訪問時延有很多的要求，一般的塊儲存服務並不能很好的滿足這方面的需求。且其應用本身已經實現了資料的高可用設計，不再需要底層實現多副本的能力，即分散式儲存的多副本設計對這類應用是一種浪費。

儲存作為快取：部分應用期望儲存一些不重要的資料，資料在程式執行完成即可以丟掉，且對儲存的效能要求較高，其本質是將儲存作為快取使用。雲盤的高可用能力對這樣的業務並沒有太大的意義，且雲盤在 IO 效能、價格方面的表現（相對本地盤）也沒有優勢。

所以本地盤儲存在很多關鍵能力上要比分散式塊儲存弱很多，但在特定場景下仍然有其使用的優勢。阿里雲端儲存服務提供了基於 NVMe 的本地盤儲存方案，以更好的效能表現和更低的價格優勢，在特定的應用場景得到了使用者的青睞。

![6.png](https://ucc.alicdn.com/pic/developer-ecology/58b92e388fcc4e37ac24466ba9ecc7a4.png)

阿里雲 CSI 驅動供了雲原生應用使用本地儲存的接入實現，支援：lvm 卷、本地盤裸裝置、本地目錄對映等多種接入形式，實現資料的高效能訪問、quota、iops 配置等眾多適配能力。

**優點如下所示：**

- **效能高**：提供相對分散式儲存更優的 IOPS、吞吐能力；
- **低價**：透過物理裸裝置直接提供本地盤，在價格上相對於多副本的分散式儲存具有優勢。

**缺點如下所示：**

- **資料可靠性差**：本地盤儲存的資料丟失後不能找回，需要從應用層實現資料的高可用設計；
- **靈活性差**：不能像雲盤一樣實現資料遷移到其他節點使用。

## 5.開源容器儲存

隨著雲原生技術的發展，社群提供了一些開源的雲原生儲存方案。

### 1）Rook

Rook 作為第一個 CNCF 儲存專案，是一個整合了 Ceph、Minio 等分散式儲存系統的雲原生儲存方案，意圖實現一鍵式部署、管理方案，且和容器服務生態深度融合，提供適配雲原生應用的各種能力。從實現上，可以認為 Rook 是一個提供了 Ceph 叢集管理能力的 Operator。其使用 CRD 方式來對 Ceph、Minio 等儲存資源進行部署和管理。

![7.png](https://ucc.alicdn.com/pic/developer-ecology/b8f41a66dbea401abcc57b0db1ceee0c.png)

Rook 元件：

- **Operator**：實現自動啟動儲存叢集，並監控儲存守護程式，並確儲存儲叢集的健康；
- **Agent**：在每個儲存節點上執行，並部署一個 CSI / FlexVolume 外掛，和 Kubernetes 的儲存卷控制框架進行整合。Agent 處理所有的儲存操作，例如掛載儲存裝置、載入儲存卷以及格式化檔案系統等；
- **Discovers**：檢測掛接到儲存節點上的儲存裝置。

Rook 將 Ceph 儲存服務作為 Kubernetes 的一個服務進行部署，MON、OSD、MGR 守護程式會以 pod 的形式在 Kubernetes 進行部署，而 rook 核心元件對 ceph 叢集進行運維管理操作。

Rook 透過 ceph 可以對外提供完備的儲存能力，支援物件、塊、檔案儲存服務，讓你透過一套系統實現對多種儲存服務的需求。同時 rook 預設部署雲原生儲存介面的實現，透過 CSI / Flexvolume 驅動將應用服務與底層儲存進行銜接，其設計之初即為 Kubernetes 生態所服務，對容器化應用的適配非常友好。

Rook 官方文件參考：[https://rook.io/](https://rook.io/)

### 2）OpenEBS

OpenEBS 是一種模擬了 AWS 的 EBS、阿里雲的雲盤等塊儲存實現的開源版本。OpenEBS 是一種基於 CAS 理念的容器解決方案，其核心理念是儲存和應用一樣採用微服務架構，並透過 Kubernetes 來做資源編排。其架構實現上，每個卷的 Controller 都是一個單獨的 Pod，且與應用 Pod 在同一個 Node，卷的資料使用多個 Pod 進行管理。

![8.png](https://ucc.alicdn.com/pic/developer-ecology/e0f06014cc89465fa6f77dfad78875b1.png)

架構上可以分為資料平面（Data Plane）和控制平面（Control Plane）兩部分：

- 資料平面：為應用程式提供資料儲存；
- 控制平面：管理 OpenEBS 卷容器，通常會用到容器編排軟體的功能；

**資料平面**：

> OpenEBS 持久化儲存卷透過 Kubernetes 的 PV 來建立，使用 iSCSI 來實現，資料儲存在 node 節點上或者雲端儲存中。OpenEBS 的卷完全獨立於使用者的應用的生命週期來管理，和 Kuberentes 中 PV 的思路一致。
> OpenEBS 卷為容器提供持久化儲存，具有針對系統故障的彈性，更快地訪問儲存，快照和備份功能。同時還提供了監控使用情況和執行 QoS 策略的機制。

**控制平面**：

> OpenEBS 控制平面 maya 實現了建立超融合的 OpenEBS，並將其掛載到如 Kubernetes 排程引擎上，用來擴充套件特定的容器編排系統提供的儲存功能；
> OpenEBS 的控制平面也是基於微服務的，透過不同的元件實現儲存管理功能、監控、容器編排外掛等功能。

更多關於 OpenEBS 的介紹可以參考：[https://openebs.io/](https://openebs.io/)

### 3）Heketi

類似於 Rook 是 Ceph 開源儲存系統在雲原生編排平臺（Kubernetes）的一個落地方案，Glusterfs 同樣也有一個雲原生實踐方案。Heketi 提供了一個 Restful 管理介面，可用於管理 Gluster 儲存卷的生命週期。使用 Heketi，Kubernetes 可以動態地為 Gluster 儲存卷提供任何支援的永續性型別。Heketi 將自動確定叢集中 brick 的位置，確保在不同的故障域中放置 brick 及其副本。Heketi 還支援任意數量的 Gluster 儲存叢集，為雲服務提供網路檔案儲存。

使用 Heketi，管理員不再管理或配置塊、磁碟或儲存池。Heketi 服務將為系統管理所有硬體，使其能夠按需分配儲存。任何在 Heketi 註冊的物理儲存必須以裸裝置方式提供，然後 Heketi 在提供的磁碟上使用 LVM 進行管理。

![9.png](https://ucc.alicdn.com/pic/developer-ecology/753b325b69fe424c96495c1a61d14534.png)

更多詳解參考：[https://github.com/heketi/heketi)](https://github.com/heketi/heketi)

## 6. 優勢

- 上述幾種雲原生儲存方案其設計之初既充分考慮了儲存與雲原生編排系統的融合，具有很好的容器資料卷接入能力；
- 在 Quota 配置、QoS 限速、ACL 控制、快照、備份等方面有較好的雲原生整合實現，雲原生應用使用儲存資源時更加靈活、便利；
- 開源方案，社群較為活躍，網路資源、使用方案豐富，讓您更容易入手。

## 7. 劣勢

- 成熟度較低，目前上述方案多在公司內部測試環境或者 SLA 較低的應用中使用，很少儲存關鍵應用資料；
- 效能差：和公有云儲存、商業化儲存相比，上述雲原生儲存方案在 IO 效能、吞吐、時延等方面都表現欠佳，很難應用在高效能服務場景；
- 後期維護成本高：雖然上面方案部署、入門都很簡單，但一旦執行中出現問題解決起來非常棘手。上述專案屬於初期階段，並不具備生產級別的服務能力，如果使用此方案需要有強有力的技術團結加以保障。

# 現狀和挑戰

## 1.敏捷化需求

雲原生應用場景對服務的敏捷度、靈活性要求非常高，很多場景期望容器的快速啟動、靈活的排程，這樣即需要儲存卷也能敏捷的根據 Pod 的變化而調整。

需求表現在：

- 雲盤掛載、解除安裝效率提高：可以靈活的將塊裝置在不同節點進行快速的掛載切換；
- 儲存裝置問題自愈能力增強：提供儲存服務的問題自動修復能力，減少人為干預；
- 提供更加靈活的卷大小配置能力。

## 2.監控能力需求

多數儲存服務在底層檔案系統級別已經提供了監控能力，然後從雲原生資料卷角度的監控能力仍需要加強，目前提供的PV監控資料維度較少、監控力度較低；

具體需求：
> 提供更細力度（目錄）的監控能力；
> 提供更多維度的監控指標：讀寫時延、讀寫頻率、IO 分佈等指標；

## 3.效能要求

在大資料計算場景同時大量應用訪問儲存的需求很高，這樣對儲存服務帶來的效能需求成為應用執行效率的關鍵瓶頸。

具體需求：

- 底層儲存服務提供更加優異的儲存效能服務，最佳化 CPFS、GPFS 等高效能儲存服務滿足業務需求；
- 容器編排層面：最佳化儲存排程能力，實現儲存就近訪問、資料分散儲存等方式降低單個儲存卷的訪問壓力。

## 4.共享儲存的隔離性

共享儲存提供了多個 Pod 共享資料的能力，方便了不同應用對資料的統一管理、訪問，但在多租的場景中，不同租戶對儲存的隔離性需求成為一個需要解決的問題。

> 底層儲存提供目錄間的強隔離能力，讓共享檔案系統的不同租戶之間實現檔案系統級別的隔離效果。
> 容器編排層實現基於名詞空間、PSP 策略的編排隔離能力，保證不同租戶從應用部署側即無法訪問其他租戶的儲存卷服務。

<p style="text-align:center">![圖片1.jpg](https://ucc.alicdn.com/pic/developer-ecology/140713fec17a4f59a656b91dd8ed422e.jpg)</p>

6 月 12 日 17：00 前在“阿里巴巴雲原生”公眾號留言區**歡迎大家討論交流雲原生儲存新的機遇與挑戰**，精選留言點贊第 1 名即可免費獲得此書！

# 課程推薦

為了更多開發者能夠享受到 Serverless 帶來的紅利，這一次，我們集結了 10+ 位阿里巴巴 Serverless 領域技術專家，打造出最適合開發者入門的 Serverless 公開課，讓你即學即用，輕鬆擁抱雲端計算的新正規化——Serverless。

點選即可免費觀看課程：[https://developer.aliyun.com/learning/roadmap/serverless](https://developer.aliyun.com/learning/roadmap/serverless)

> “[阿里巴巴雲原生](http://mp.weixin.qq.com/s?__biz=MzUzNzYxNjAzMg==&mid=2247491123&idx=1&sn=f26148614c50e8fd8fa5b348d4f5a518&chksm=fae515fccd929cea4c1dc5f95464b2fce70cb645b1e63741f81597af2f90805705a61d1165aa&token=780266989&lang=zh_CN#rd)關注微服務、Serverless、容器、Service Mesh 等技術領域、聚焦雲原生流行技術趨勢、雲原生大規模的落地實踐，做最懂雲原生開發者的公眾號。”

雲原生儲存系列文章(一)：雲原生應用的基石

相關文章