客座文章作者：Evan Powell，CEO @MayaData
或者，雲服務怎麼會不是雲原生的呢？
歐洲KubeCon在很多方面都很偉大。一個驚喜是，因為KubeCon是一個虛擬活動，這導致我與各種儲存供應商和專案的對話比之前的KubeCon更多。KubeCon儲存的交流頻道召集了許多聰明的供應商，他們通常合作，試圖為終端使用者解決問題；我受到了鼓舞，試著盡我的一份力來跟上。
這就是本文起點，作為容器附加儲存（Container Attached Storage，CAS）定義的原始作者，接下來為更廣泛的社群建立一個部落格是有意義的。
引發這次更新的問題來自一個傳統儲存供應商的工程師，他問--我稍微引用一下：“如果鬆散耦合對於雲原生架構如此重要，這是否意味著，依賴於一個給定的雲本身就不是雲原生的？換句話說，雲服務本身不是雲原生的嗎？”我不得不回答--是的--但故事還有更多內容。
回顧--什麼是CAS？
容器附加儲存是一種模式，它非常符合資料分解的趨勢，以及執行小型、鬆散耦合的工作負載的小型、自治團隊。換句話說，我的團隊可能需要為我們的微服務使用Postgres，而你的團隊可能依賴於Redis和MongoDB。我們的一些用例可能需要效能，一些可能在20分鐘內就用完，其他的是寫密集型的，其他的是讀密集型的等等。在大型組織中，團隊依賴的技術，會隨著組織規模的增長，和組織越來越信任團隊選擇他們自己的工具，而變得越來越多。Kubernetes支援這種模式--有時被討論為資料網格（data mesh）和多語言資料（polyglot data）的興起--來自ThoughtWorks的Zhamak Dehghani和其他人有相關的討論。
瞭解更多關於CAS：
- 早在2018年4月，我在CNCF的網站上建立了CAS一詞的部落格：
- 7月的CNCF網路研討會，由OpenEBS專案負責人Kiran Mova主持：
這是來自Kiran社群網路研討會的一張規範圖片，並附有一些解釋：
CAS意味著開發者，可以在不考慮其組織儲存架構的底層需求的情況下工作。對於CAS，雲磁碟與SAN相同，SAN與裸機或虛擬主機相同。我們沒有召開會議來選擇下一個儲存供應商，或討論設定來支援我們的用例，我們使用我們需要的儲存或localPV管理來啟動我們自己的CAS容器，然後繼續前進。
好的，^^這就是CAS，但是雲有什麼不是原生雲的呢？
Kubernetes的一個被忽視的方面是，它最初建立的目的，是確保我們可以以雲原生方式執行雲。讓我來解釋一下。
在Kubernetes之前，很難宣佈意圖（intent），並知道將要執行此意圖，而不論其部署環境是本地部署，還是A、B或C雲。相反，企業被建議選擇一家主要的雲，並且加倍他們與該雲的專業知識和關係。
因此，整個組織和他們編寫的所有軟體都隱式地依賴於該雲，因此與雲耦合。這種緊密耦合通常並不重要，直到它變得重要為止。只有像Netflix這樣的組織，他們的系統架構既能解決AWS的漏洞，又能通過混沌工程積極地、不懈地驗證自己的容錯性，才能挺過各種各樣的AWS當機。據推測，他們轉移至少一部分工作負載的能力，比如基於Spinnaker的CI/CD，也有助於他們與AWS協商更好的價格。
簡而言之，如果你將雲原生定義為能夠在底層雲中斷時存活，那麼與雲緊密耦合本身就是一種反模式。
Kubernetes之所以成為我們這個時代最重要的開源專案之一，部分原因在於它意識到了這種緊密耦合的風險和阻抗挑戰。而且，對於一個傳統的共享一切的儲存硬體供應商來說，這裡有些敏感，這種邏輯在他們銷售的系統上雙倍適用。
如果你想構建鬆散耦合的系統，就像你不能簡單地在一個雲上，並且只在那個雲上執行一樣，你也不能假設一個聲稱可擴充套件到數千個節點的儲存系統在所有情況下都能工作。
如果我們接受雲原生核心的“構建失敗”信條，我們必須承認共享的所有儲存將會崩潰。它的行為方式並不適合每個團隊的工作負載。它將以非Kubernetes原生方式執行，所有這些依賴關係將超出我們控制的風險引入到我們的環境中，這對我們的團隊來說是不透明的。
好的，那麼CAS有什麼新東西呢？
當CAS首次出現時，它被用於較少任務關鍵型工作負載，這並不奇怪。很好的例子包括各種“半永久性”工作負載，其中你希望資料在CI/CD執行期間保留，或者用於一些資料科學工作，然後你希望它消失。對於這些示例，CAS允許工作負載快速且一致地啟動非常重要。第二個也是重要的需求是，無論底層環境如何，CAS的行為方式都是相同的。
當Kubernetes排程工作負載時，即使是相當典型的32秒的EBS附加時間，如果執行時間為5分鐘，而你每天執行它幾十次，則需要不少時間。你可以在早期OpenEBS採納者列表中看到這種模式，早期的公共引用往往傾向於持續時間相對較短的工作負載。
幾年前，Kubernetes上的較長持續時間的工作負載以兩種方式之一處理。
- 要麼通過雲中的託管服務，或
- 增加額外彈性級別的NoSql資料庫。
一開始我們認為CAS在這兩種情況下都不適用，因為傳統的共享儲存肯定不適用；然而，我們很快意識到NoSQL資料庫和Kafka這樣的解決方案，可以在我們稱為動態LocalPV的地方得到幫助。
通過保持對底層環境（包括可用的雲卷和物理磁碟）的瞭解，像OpenEBS的LocalPV這樣的CAS解決方案，降低了在Kubernetes上執行這些工作負載的操作工作量。CAS解決方案這樣做的方式，減少了對給定底層雲或儲存系統的鎖定或依賴。
第一個新的CAS要求
因此，我們可以相應地更新CAS定義。我們現在知道CAS解決方案需要包括LocalPV支援。同樣，幫助使用LocalPV執行資料應用程式的相關Kubernetes操作器也是如此。
最近，我們看到許多工作負載都在增加，對於這些工作負載，本地節點效能非常重要。
效能問題同樣可以通過使用LocalPV來解決。一個挑戰是，許多工作負載現在既需要效能又需要多節點HA。僅僅通過Restic或其他專案或產品備份節點是不夠的。
考慮執行在PostgreSQL或MySql上的高效能工作負載--例如執行在MySql上的Magento。僅僅備份資料是不夠的，MySql通常希望能夠立即訪問另一個節點上的資料。也許不足為奇的是，許多這些工作負載在雲出現之前就存在了。傳統的SQL，如MySql、PostgreSQL和其他SQL，幾乎總是部署故障轉移和副本。有時，這些傳統的工作負載甚至可以通過Kafka或類似的方式整合在一起，以交付一個統一的資料網格，就像前面ThoughtWorks的文章中提到的那樣。我們的夢想是為企業提供關注點，比如從所有資料中學習，同時也允許小型獨立團隊的自治和敏捷性。
第二個新的CAS要求
因此，我們可以用第二種方式更新CAS定義。我們現在知道CAS解決方案需要以LocalPV速度包含多節點HA。
這個需求的唯一問題是，到目前為止，能夠滿足這個需求的解決方案非常少。據我所知，致力於滿足這一需求的唯一CAS解決方案是OpenEBS Mayastor；它將在2020年9月達到測試版0.4。
第三和第四項附加的CAS要求
第三個更新在這兩個更新之後的邏輯上進行。CAS解決方案在其架構中應該是雲原生的。如果我們想成功地支援所有型別的工作負載，比如NoSql工作負載的LocalPV，以及對許多效能敏感的PostgreSQL等部署具有彈性的高效能，那麼CAS必須提供多種儲存資料的方法。
在OpenEBS的情況，該專案利用雲原生架構提供了不少於4個“資料引擎”（如果計算可用的所有不同風格的LocalPV，會更多）。早期的CAS解決方案在本質上更加單一。我認為所有的CAS都需要以Kubernetes作為基底的思想來構建，從而實現可插拔的非單體架構。
最後，開源似乎是明顯的。理性的人可能不同意這一點，因為有一些明顯的CAS模式的早期貢獻者依賴於專有軟體。但是，專有軟體引入了供應商依賴，這與雲原生固有的“可移植性”精神相沖突。
綜上所述，從成千上萬的容器附加儲存使用者那裡，我們可以自信地說，CAS的定義應該擴充套件到包括：
- CAS必須支援pass-through模式（我們在Kubernetes生態系統中稱之為LocalPV）
- CAS必須支援LocalPV速度的多節點HA
- CAS軟體在架構上應該是雲原生的--根據工作負載支援多個資料引擎
- CAS應該是開源的，以避免引入供應商依賴關係。
總結
在過去的幾年裡，我們看到了來自更廣泛的雲原生社群的大量反饋和支援，這些社群致力於如何在處理資料時最大限度地利用Kubernetes和雲原生方法。我們必須付出才能得到。而且，我比以往任何時候都高興，因為MayaData將OpenEBS捐贈給了CNCF。我們很自然地將Litmus也捐贈給了關注有狀態工作負載的混沌工程。我們非常自豪的是，根據這篇來自CNCF的DevStats報告，截止到2020年8月底，MayaData是CNCF專案的第5大主要貢獻者：
https://all.devstats.cncf.io/...
最近，我們幫助啟動了Data on Kubernetes社群專案，在這供應商中立空間中討論操作人員、資料庫、用例等等。來自使用Kubernetes組織的工程師像Optoro和Arista等，以及Kafka/Confluent和Cassandra/DataStax等專案進行了發言。歡迎並鼓勵所有人與獨立組織者取得聯絡，以任何你想要的方式參與。
CAS現在被看作是把Kubernetes轉換成資料平面的關鍵部分。CAS補充了底層雲端儲存服務、本地CSI可訪問儲存，甚至是本地節點中可用的原始磁碟和記憶體。
我們使用CAS（特別是OpenEBS）的經驗表明，使用者已經熟悉了這種模式。CAS的新需求反映了這模型的增長和成熟度。
我對未來幾年我們將走向何方感到興奮。當我們在Kubernetes上探索更多資料密集型的工作負載時，我們的需求將如何發展？不管是什麼，我們都渴望和你一起找出答案。我們在MayaData這裡傾聽，並繼續發展CAS模式以滿足新的需求。
CNCF (Cloud Native Computing Foundation)成立於2015年12月，隸屬於Linux Foundation，是非營利性組織。
CNCF（雲原生計算基金會）致力於培育和維護一個廠商中立的開源生態系統，來推廣雲原生技術。我們通過將最前沿的模式民主化，讓這些創新為大眾所用。掃描二維碼關注CNCF微信公眾號。
