“云原生”(Cloud Native)一詞在 2019 年被技術界廣泛使用，但是卻沒有關于這個詞一個特別明確的定義。主要的困惑在于，“云原生”與您的應用程序部署到的環境幾乎沒有關系，該術語同樣適用于私有云和公共云。該術語更多的是指應用程序和體系結構的特征。

在 Cloud Native Computing Foundation (CNCF 云原生計算基金會) 對該術語的最新定義中我們可以找到一些相關信息：

云原生技術使組織能夠在現代、動態環境(例如公共云，私有云和混合云)中構建和運行可擴展應用程序。容器、服務網格、微服務、不變的基礎結構和聲明性API 就是這種方法的例證。

這些技術使松散耦合的系統具有彈性，可管理性和可監控。結合強大的自動化功能，它們使工程師能夠以最小的工作量頻繁且可預測地進行重大的更改。

那么，存儲是云原生意味著什么呢?簡而言之，它必須以與云原生生態系統中其他所有事物相同的動態，API 驅動的方式運行。有兩個相關的指標可以確定一個存儲系統是否云原生，它們是：

• 是否專為 Kubernetes 打造
• 是否兼容亞馬遜的 S3 API

下面我們將更詳細地解讀這些指標。

云原生存儲是對象存儲

現代應用程序體系結構基于對象存儲，默認情況下，S3 是云的 API 語言。因為對象存儲是唯一一種旨在處理云本機應用程序生成的數據量的存儲，并且提供公司可以負擔得起的價格以及用戶期望的速度運行 —— 它在現代存儲中占主導地位。與塊文件存儲系統相比，對象存儲的其他屬性包括出色的分發特性，更好的彈性和更高的可用性。

這都是云原生應用程序期望的屬性。

Amazon S3 API 是對象存儲的事實上的標準，每個對象存儲軟件供應商都宣稱自己對 S3 API 兼容。AWS S3 實際上是二進制兼容的。適用于所有的場景，要么完全不適用。

也就是說，S3 API 基本上可以滿足絕大多數的場景，其中包括你可能不會想到的極端情況。這是開源軟件具有顯著優勢的領域。考慮到應用程序、操作系統和硬件體系結構的規模和多樣性，可以表明他們已經看到了大多數極端情況，而且能很好的滿足這些場景。

這對應用程序創建者來說很重要，因為你需要針對那些供應商來測試你的應用程序。而開源使您可以輕松評估和測試供應商的方案，如果測試通過，很可能是云原生的。如果不是，則不是。

專為 Kubernetes 設計

“云原生”的第二個標準是使用利用外部容器編排平臺的分布式架構。這意味著架構必須對 Kubernetes 友好。在容器編排方面，Kubernetes已經是顯而易見的行業贏家，因此將其構建為與 Kubernetes 協同工作對于將存儲解決方案視為云原生是至關重要的。

存儲對 Kubernetes 友好意味著什么?我們認為有六個主要標準。

1. 讓 Kubernetes 編排存儲節點

Kubernetes 是一個功能強大的編排器，可用于處理計算和存儲編排。像 MinIO 這樣的真正云原生存儲方案與 Kubernetes 集成在一起，允許操作員使用 Kubernetes 界面管理存儲，而 Kubernetes 可以處理從存儲提供到卷放置的所有事務。

2. 多租戶

多租戶允許多個客戶使用一個應用程序的單個實例，如果實施正確，則可以減少運營開銷，降低成本并降低復雜性，尤其是在規模方面。但是，這也需要嚴格的資源隔離，以便多個用戶可以訪問計算資源或存儲資源，而不會影響其他用戶。真正的云原生存儲解決方案將提供足夠的資源隔離，以確保多租戶架構安全，高可用性和高性能。

在對象存儲世界中，意味著 Kubernetes 基礎架構需要隔離和管理存儲租戶。如果 Kubernetes 沒有管理基礎架構，那么它并不是真正的云原生平臺。這使那些具有 CSI 或 Operator 集成功能的設備供應商失去資格。

3. 輕巧

除非存儲系統非常輕巧并且能夠與應用程序堆棧打包在一起，否則多租戶是不可能的。如果存儲系統占用太多資源或包含太多API，則無法在同一基礎架構上打包許多租戶。

4. 可擴展

可擴展性是云原生系統的關鍵屬性之一。Kubernetes 的優點之一是它已在各種規模上得以驗證。Kubernetes 也可用于管理存儲擴展，但前提是基礎存儲系統與 Kubernetes 集成，并且將存儲供應和取消功能移交給 Kubernetes。

5. API 驅動

通常，Kubernetes 和云原生系統的核心原則之一是通過自動化來盡可能多地進行管理。為了使存儲系統真正成為云原生，它必須通過 API 與 Kubernetes 集成，并允許動態的、由 API 驅動的編排。

6. 用戶空間

最后的考慮也許是最困難的。為了使對象存儲解決方案成為云原生，它必須完全在用戶空間中運行且沒有內核依賴性。這不是大多數對象存儲系統(尤其是硬件設備)構建的方式。但是，如果您想對存儲進行容器化并將其部署在任何 Kubernetes 集群上，則必須遵守這些限制。根據定義，這意味著需要內核修補或具有專用硬件的解決方案將不是云原生的。

結論

盡管在某種程度上很簡單，但這兩個要求“云原生”狀態的標準實際上在實踐中非常困難。公共云對象存儲供應商在對抗它們方面做得很好。實際上，如果 Google 是 Kubernetes 的源頭，而 Amazon 是 S3 的源頭，則確實可以期望他們這樣做。私有云對象存儲供應商要通過這些測試要困難得多。雖然有些人聲稱與S3兼容，但仔細檢查卻發現并非如此。對于絕大多數傳統廠商來說，Kubernetes 根本就不在他們的基因范圍之內，甚至常常不在計劃之列。因為這里面困難重重。

而 MinIO 是專為云原生工作負載而構建，設計時就考慮了 Kubernetes ，并遵循 Kubernetes 的方式。MinIO 與 S3 兼容，但也可以與 Google、Azure 或私有云一起使用，從而使多云和混合云成為可能。

高性能的云原生對象存儲是獲得云原生應用程序所需的性能、可靠性和可伸縮性的唯一方法。