[[256258]]

雖然 Kubernetes 在許多方面非常有用，例如可伸縮性、可移植性和管理能力，但它不支持存儲狀態(tài)。幾乎所有的生產(chǎn)應(yīng)用程序都是有狀態(tài)的，即需要某種外部存儲。

像 Kubernetes 這樣的容器編排工具正在徹底改變應(yīng)用程序的開發(fā)和部署方式。隨著微服務(wù)架構(gòu)的興起，以及基礎(chǔ)架構(gòu)與應(yīng)用程序邏輯從開發(fā)人員的角度解耦，開發(fā)人員越來越關(guān)注構(gòu)建軟件和交付價值。

Kubernetes 對管理的物理機器進行抽象。使用 Kubernetes，你可以通過描述獲取所需的內(nèi)存總量和計算能力，而無需擔(dān)心底層基礎(chǔ)架構(gòu)。

在管理 Docker 鏡像時，Kubernetes 還讓應(yīng)用程序變得可移植。一旦使用 Kubernetes 開發(fā)容器化架構(gòu)，它們就可以部署在任何地方 - 公有云、混合云、本地 - 無需對底層代碼進行任何更改。

雖然 Kubernetes 在許多方面非常有用，例如可伸縮性、可移植性和管理能力，但它不支持存儲狀態(tài)。幾乎所有的生產(chǎn)應(yīng)用程序都是有狀態(tài)的，即需要某種外部存儲。

Kubernetes 的架構(gòu)是不斷變化的。容器的創(chuàng)建和銷毀，取決于負(fù)載和開發(fā)人員的規(guī)范。容器組和容器可以自我修復(fù)和復(fù)制。從本質(zhì)上講，它們的生命周期是短暫的。

但是，持久化存儲解決方案無法承受這種動態(tài)行為。持久化存儲不能綁定到動態(tài)創(chuàng)建和銷毀的規(guī)則上。

當(dāng)有狀態(tài)應(yīng)用需要部署在另一個基礎(chǔ)架構(gòu)，可能是另一個云提供商、本地或混合模型上時，它們在可移植性方面面臨挑戰(zhàn)。持久化存儲解決方案會綁定到特定的云提供商。

此外，云原生應(yīng)用程序的存儲版圖不容易理解。Kubernetes 存儲術(shù)語可能會造成混淆，因為許多術(shù)語都有復(fù)雜的含義和微妙的變化。此外，在做出決策之前，開發(fā)人員必須考慮許多選項，包括原生 Kubernetes、開源框架、托管或付費服務(wù)。

在下面的 CNCF 版圖中可以看到列出的云原生存儲解決方案：

首先想到的可能就是在 Kubernetes 中部署數(shù)據(jù)庫：選擇適合你需求的數(shù)據(jù)庫解決方案，將其容器化并在本地磁盤上運行，然后將其作為另一個工作負(fù)載部署在集群中。但是，由于數(shù)據(jù)庫的固有屬性，這種方法不是特別好。

容器是基于無狀態(tài)原則構(gòu)建的。這使得容器很容易進行伸縮。由于不需要保存和遷移數(shù)據(jù)，通常來說，集群不需要處理很密集的磁盤讀寫操作。

使用數(shù)據(jù)庫，需要保存狀態(tài)。如果數(shù)據(jù)庫以容器方式部署在集群上，不進行遷移或者頻繁伸縮，那么實際的數(shù)據(jù)存儲將起作用。理想情況下，將使用數(shù)據(jù)的容器與數(shù)據(jù)庫位于同一個容器中。

這并不是說在容器中部署數(shù)據(jù)庫是一個壞主意 - 在某些用例中，這種方法可能就足夠了。在測試環(huán)境中，或者對于不需要生產(chǎn)級數(shù)據(jù)量的任務(wù)，由于所保存的數(shù)據(jù)規(guī)模較小，因此集群中的數(shù)據(jù)庫可能是有意義的。

在生產(chǎn)中，開發(fā)人員通常依賴外部存儲。

Kubernetes 如何與存儲通信?它使用控制平面接口。這些接口將 Kubernetes 與外部存儲相關(guān)聯(lián)。這些與 Kubernetes 連接的外部存儲解決方案稱為卷插件。卷插件可以抽象存儲并賦予存儲可移植性。

以前，卷插件使用 Kubernetes 核心代碼庫構(gòu)建、鏈接、編譯和發(fā)布。這極大地限制了開發(fā)人員的靈活性，并帶來了額外的維護成本。添加新的存儲選項需要更改 Kubernetes 代碼庫。

通過引入 CSI 和 Flexvolume，可以在集群上部署卷插件，而無需更改代碼庫。

Kubernetes 原生和存儲

Kubernetes 原生如何處理存儲?Kubernetes 自身提供了一些管理存儲的解決方案：臨時選項、持久化存儲卷、持久化存儲卷聲明、存儲類和有狀態(tài)副本集。這可能很混亂。

持久化存儲卷(PV)是由管理員配置的存儲單元。它們獨立于任何一個容器組，使它們擺脫容器組的短暫生命周期。

另一方面，持久化存儲卷聲明(PVC)是對存儲的請求，即 PVs。使用 PVC，可以將存儲綁定到特定節(jié)點，使其可供該節(jié)點使用。

有兩種處理存儲的方法：靜態(tài)和動態(tài)。

采用靜態(tài)配置，管理員在實際請求之前，為他們認(rèn)為可能需要的容器組提供 PVs，并且通過明確指定的 PVCs，將這些 PV 手動綁定到指定的容器組。

實際上，靜態(tài)定義的 PV 與 Kubernetes 的可移植結(jié)構(gòu)不兼容，因為正在使用的存儲可能依賴于環(huán)境，例如 AWS EBS 或 GCE Persistent Disk。手動綁定需要更改 YAML 文件以指向特定供應(yīng)商的存儲解決方案。

在開發(fā)人員如何考慮資源方面，靜態(tài)配置也違背了 Kubernetes 的思維方式：CPU 和內(nèi)存未事先分配并綁定到容器組或容器。它們是動態(tài)授予的。

動態(tài)配置使用存儲類完成。集群管理員無需事先手動創(chuàng)建 PV。他們改為創(chuàng)建多個存儲配置文件，就像模板一樣。當(dāng)開發(fā)人員創(chuàng)建 PVC 時，根據(jù)請求的要求，在請求時創(chuàng)建其中一個模板，并將其附加到容器組。

這是對外部存儲通常如何使用原生 Kubernetes 進行處理的一個寬泛的概述。但是，還有許多其他選擇需要考慮。

CSI - 容器存儲接口

在繼續(xù)之前，我想介紹容器存儲接口(CSI)。CSI 是由 CNCF 存儲工作組創(chuàng)建的統(tǒng)一工作，旨在定義標(biāo)準(zhǔn)容器存儲接口，使存儲驅(qū)動程序能夠在任何容器編排器上工作。

CSI 規(guī)范已經(jīng)適用于 Kubernetes，并且在 Kubernetes 集群上有大量驅(qū)動程序插件可供部署。開發(fā)人員可以 Kubernetes 上使用 CSI 卷類型訪問 CSI 兼容卷驅(qū)動程序公開的存儲。

隨著 CSI 的引入，存儲可以被視為另一個工作負(fù)載容器化，并在 Kubernetes 集群上部署。

開源項目

圍繞云原生技術(shù)的工具和項目大幅增加。作為生產(chǎn)環(huán)境中最突出的問題之一，有相當(dāng)多的開源項目致力于解決云原生架構(gòu)上的存儲問題。

關(guān)于存儲的***的項目是 Ceph 和 Rook。

Ceph 是一個動態(tài)管理，可水平擴展的分布式存儲集群。Ceph 提供了對存儲資源的邏輯抽象。它被設(shè)計為沒有單點故障，可自我管理并基于軟件。Ceph 為同一存儲集群同時提供塊、對象和文件系統(tǒng)接口。

Ceph 的架構(gòu)很復(fù)雜，有許多底層技術(shù)，如 RADOS、librados、RADOSGW、RDB、CRUSH 算法，以及監(jiān)視器、OSD 和 MDS 等組件。Ceph 是一個分布式存儲集群，不需要深入研究其體架構(gòu)，關(guān)鍵在于，它是一個分布式存儲集群，可以更輕松地實現(xiàn)可擴展性，在不犧牲性能的情況下消除單點故障，并提供了對對象、塊和文件的訪問的統(tǒng)一存儲。

當(dāng)然，Ceph 已經(jīng)適應(yīng)了云原生環(huán)境?？梢酝ㄟ^多種方式部署 Ceph 集群，例如使用 Ansible?？梢詮?Kubernetes 集群中使用 CSI 和 PVC 接口訪問部署的 Ceph 集群。

Ceph 架構(gòu)

另一個有趣且頗受歡迎的項目是 Rook，一個旨在融合 Kubernetes 和 Ceph 的工具 - 將計算和存儲集中在一個集群中。

Rook 是一個云原生存儲編排器。它擴展了 Kubernetes。Rook 本質(zhì)上允許將 Ceph 放入容器中，并提供集群管理邏輯，以便在 Kubernetes 上可靠地運行 Ceph。Rook 自動化部署、引導(dǎo)、配置、擴展、負(fù)載均衡，即集群管理員需要做的工作。

Rook 允許通過 yaml 文件部署 Ceph 集群，就像 Kubernetes 一樣。此文件用作集群管理員在集群中所需內(nèi)容的高級聲明。Rook 整合集群，并開始積極監(jiān)控。Rook 充當(dāng)運維人員或控制器，確保 yaml 文件中聲明的期望狀態(tài)得到保證。Rook 在一個協(xié)調(diào)循環(huán)中運行，觀察狀態(tài)并根據(jù)檢測到的差異采取行動。

Rook 沒有自己的持久化狀態(tài)，也不需要管理。它的確是根據(jù) Kubernetes 的原則構(gòu)建的。

Rook 架構(gòu)

Rook 將 Ceph 和 Kubernetes 結(jié)合在一起，是***的云原生存儲解決方案之一，在 Github 上擁有近 4000 顆星，1630 萬 下載量和 100 多名貢獻者。

作為被 CNCF 接受的***存儲項目，Rook 近期已進入孵化階段。

對于應(yīng)用程序中的任何問題，確定需求，設(shè)計系統(tǒng)和選擇相應(yīng)工具非常重要。云原生環(huán)境中的存儲也不例外。雖然問題非常復(fù)雜，但仍有許多工具和方法。隨著云原生世界的發(fā)展，無疑也會出現(xiàn)新的解決方案。

查看英文原文：https://softwareengineeringdaily.com/2019/01/11/why-is-storage-on-kubernetes-is-so-hard/