為什麼Kubernetes的儲存如此艱難?

　　 隨著像Kubernetes這樣的容器編排工具的大火，應用程式的開發與部署方式正經歷著一場巨大的變革。微服務體系結構的興起，以及從開發人員的角度，將基礎架構與應用程式邏輯間相互解耦，使得開發人員越來越關注於構建軟體和交付價值。

　　Kubernetes能夠將它所管理的物理機抽象出來，藉此，開發人員可以透過描述所需的記憶體數量和計算能力，獲取相應的資源，而不必考慮底層基礎設施。

　　在管理Docker映像時，Kubernetes還能夠為應用程式提供可移植性。一旦使用Kubernetes的容器架構開發應用程式，它們就可以部署到任何地方——公共雲、混合雲、本地——而且不需要對底層程式碼進行任何更改。

　　雖然Kubernetes在許多方面非常有優勢，比如可伸縮性、可移植性和管理能力，但它也存在一個問題，就是不支援狀態儲存。幾乎所有的生產應用都是有狀態的，即需要某種外部儲存。

　　而Kubernetes的架構是動態的，容器的建立和銷燬取決於負載以及開發人員規範，Pod和容器可以自我修復和複製。本質上來說，它們的生命是短暫的。

　　然而，持久儲存解決方案無法承受這種動態行為，持久儲存不能被繫結到動態建立和銷燬的規則上。

　　當需要將有狀態的應用程式部署到另一個基礎設施(可能是另一個雲服務提供商、本地或混合雲)上時，它們在可移植性上面臨著挑戰。持久儲存解決方案會被捆綁到特定的雲提供商上。

　　此外，雲原生應用程式的儲存環境並不容易理解。Kubernetes的儲存術語可能會令人綱到困惑，因為許多術語都有複雜的含義和微妙的變化。此外，在原生Kubernetes、開源框架和託管或付費服務之間有許多選項，開發人員在做出決定之前必須考慮這些選項。

　　下面是 公佈的雲原生儲存解決方案一覽圖(其中一部分，具體可點選連結檢視):

　　可能大家首先想到的是在Kubernetes中部署資料庫:選擇滿足你需要的資料庫解決方案，將其容器化以在本地磁碟上執行，並將其作為另一個工作負載部署到叢集中。然而，由於資料庫的固有屬性，這並不能很好地工作。

　　容器是基於無狀態原則構建的，這使得容器的spin up和spin down更容易。由於沒有要儲存和遷移的資料，所以叢集不需要處理磁碟讀寫這種通常來說非常密集的工作。

　　對於資料庫，狀態往往需要被儲存。如果以容器方式部署在叢集上的資料庫沒有遷移，或者沒有頻繁地spin up，那麼資料儲存的物理特性就會發揮作用。理想情況下，使用資料的容器應該與資料庫位於同一個Pod中。

　　這並不是說在容器中部署資料庫是一個壞主意——在某些用例中，這種方法就足夠了。在測試環境中，或者對於那些不需要生產級別的資料量的任務，叢集中的資料庫是有意義的，因為所儲存的資料規模很小。

　　 在生產環境中，開發人員通常比較依賴外部儲存。

　　Kubernetes如何與儲存通訊?使用控制平面介面。這些介面將Kubernetes與外部儲存連線起來。這些連線到Kubernetes的外部儲存解決方案稱為卷外掛(Volume Plugin)，卷外掛支援抽象儲存並賦予儲存可移植性。

　　以前，卷外掛是與核心的Kubernetes程式碼庫一起構建、連結、編譯和釋出的。這大大限制了開發人員的靈活性，並帶來了額外的維護成本。新增新的儲存選項需要更改Kubernetes程式碼庫。

　　隨著CSI和Flexvolume的引入，卷外掛可以部署在叢集上，而無需更改程式碼庫。

　　 原生Kubernetes及儲存

　　原生Kubernetes如何處理儲存?Kubernetes提供了一些管理儲存的解決方案:臨時選項、持久卷的持久儲存、持久卷宣告、儲存類或狀態集……等等。

　　持久卷(PV)是由管理員提供的儲存單元，它們獨立於任何單個Pod，這樣可以將它們從Pod短暫的生命週期中解放出來。

　　另外，持久卷宣告(PVC)是對儲存的請求。使用PVC可以將儲存繫結到特定節點，使該節點能夠使用儲存。

　　處理儲存的方法有兩種:靜態或動態。

　　透過靜態配置，管理員提供了他們認為Pod在發出實際請求之前可能需要的PV，並且這些PV透過顯式PVC手動繫結到特定的Pod。

　　在實踐中，靜態定義的PV與Kubernetes的可移植結構不相容，因為所使用的儲存可能與環境相關，比如AWS EBS或GCE持久磁碟。手動繫結需要更改YAML檔案以指向特定於提供商的儲存解決方案。

　　在開發人員如何考慮資源方面，靜態配置也違背了Kubernetes的思想:CPU和記憶體不是預先分配的，而是繫結到Pod或容器中，它們是動態授予的。

　　動態配置是透過儲存類完成的。叢集管理員不需要預先手動建立PV，而是建立多個儲存配置檔案，就像模板一樣。當開發人員建立PVC時，根據請求的要求，其中一個模板在請求時建立，並附加到Pod。

　　以上只是對外部儲存一般如何使用原生Kubernetes進行處理的一個非常寬泛的概述，除此之外，還有許多其他選擇需要考慮。

　　 容器儲存介面

　　首先介紹一下容器儲存介面(Container Storage Interface，CSI)，CSI是由CNCF儲存工作組進行的統一工作，旨在定義一個標準的容器儲存介面，該介面可以使儲存驅動程式在任何容器編排器上工作。

　　CSI規範已經被應用到Kubernetes中，許多驅動程式外掛可以部署在Kubernetes叢集上。開發人員可以在Kubernetes上訪問CSI相容的卷驅動程式與CSI卷型別公開的儲存。

　　隨著CSI的引入，儲存可以作為另一個工作負載進行容器化，並部署在Kubernetes叢集上。

　　 開源專案

　　圍繞雲原生技術的工具和專案正在大量湧現。作為生產中最突出的問題之一，有相當一部分開源專案致力於解決“在雲原生架構上處理儲存”這個問題。

　　目前最受歡迎的儲存專案是 Ceph 和 Rook 。

　　Ceph是一個動態管理的、水平可伸縮的分散式儲存叢集。Ceph提供了對儲存資源的邏輯抽象。它被設計成不存在單點故障、可自我管理和基於軟體的。Ceph同時為相同的儲存叢集提供塊、物件或檔案系統介面。

　　Ceph的架構非常複雜，有許多底層技術，如RADOS、librados、RADOSGW、RDB，它的CRUSH 演算法和監視器、OSD和MDS等元件。這裡不深入解讀其架構，關鍵在於，Ceph是一個分散式儲存叢集，它可提供更高的可伸縮性，在不犧牲效能的情況下消除了單點故障，並提供了對物件、塊和檔案的訪問的統一儲存。

　　很自然地，Ceph已經適應了雲原生環境。有許多方法可以部署Ceph叢集，例如使用Ansible。你可以使用CSI和PVC部署Ceph叢集，並在Kubernetes叢集中獲得一個介面。

Ceph架構

　　另一個有趣且非常受歡迎的專案是Rook，這是一個旨在聚合Kubernetes和Ceph的工具——將計算和儲存放在一個叢集中。

　　Rook是一個雲原生儲存編排器，它擴充套件了Kubernetes的功能。Rook本質上允許將Ceph放入容器中，並提供叢集管理邏輯，使得在Kubernetes上能夠可靠地執行Ceph。Rook能夠自動化部署、引導、配置、伸縮、再平衡，即叢集管理員會做的一系列工作。

　　Rook允許從YAML部署Ceph叢集，像Kubernetes一樣。YAML檔案用作叢集管理員希望在叢集中實現的高階宣告。Rook會啟動叢集，並開始積極監視。Rook充當控制器，確保YAML檔案中宣告的所需狀態是支援的。Rook執行在一個協調迴圈中，該迴圈會觀察狀態並根據檢測到的差異進行操作。

　　Rook沒有自己的持久狀態，無需管理，可見它確實是按照Kubernetes的原則建立的。

　　Rook將Ceph和Kubernetes結合在一起，是最受歡迎的雲原生儲存解決方案之一，在Github上擁有近4000顆星，1630萬次下載，以及100多名貢獻者。

　　作為被CNCF接受的首個儲存專案，Rook近期已進入孵化階段。

　　最後，對於應用程式中的任何問題，重要的是確定需求，並相應地設計系統或選擇工具。雲原生環境中的儲存也不例外。雖然問題相當複雜，但是有很多工具和方法。隨著雲端計算的發展，無疑也會不斷出現新的解決方案。

　　來源：Software Engineering Daily 作者：Gokhan Simsek