如何應對Kubernetes中的存儲管理挑戰？

【IT168 編譯】Kubernetes是Google開源的一個容器編排引擎，它支持自動化部署、大規模可伸縮、應用容器化管理。對於那些工作負載多樣化、不斷變化的企業來說，使用Kubernetes是非常有利的。

與容器一樣，Kubernetes也支持高度動態、無狀態的操作，不斷地創建和銷毀容器，以適應不同的工作負載。不過，Kubernetes的存儲可能問題比較會棘手。許多操作都需要數據在容器的生命周期之外保留，這似乎與容器的特性不太一致。

經過多年的努力，Kubernetes開發人員已經將卷插件（Volume Plugins）集成到了Kubernetes平台中，以解決持久存儲的需求。卷插件是擴展Kubernetes介面的模塊，支持與物理存儲卷的連接。

卷插件可提供一種有效的方法來實現數據在容器生命周期之外的持久化保存，但是它們也帶來了一些挑戰。為了解決這些挑戰，Kubernetes引入了FlexVolume插件，但是FlexVolume也有一些問題。最近，Kubernetes推出了一個符合新的容器存儲介面(CSI)標準的插件，該標準可以簡化數據保存到各種存儲平台的過程。

Kubernetes環境

Kubernetes是一個可移植和擴展的平台，同時支持自動化和聲明性的配置方式。Kubernetes環境包含一組獨立的控制流程，用於通過跨Kubernetes集群的計算、網路和存儲資源的編排來管理用戶工作負載。

Kubernetes的優點包括，能夠支持幾乎任何可以在容器中運行的應用程序，從而能夠實現多種多樣且不斷變動的工作負載。每個容器都有自己的文件系統，並且與其他容器和主機隔離。因此，容器不能看到彼此的進程。此外，由於容器與底層基礎設施解耦，所以它們可以跨雲和OS發行版進行移植。

Kubernetes集群由主系統和節點系統組成。主伺服器維護集群，並作為與外部資源通信的主要節點。節點是運行容器工作負載的物理伺服器或虛擬機。

Kubernetes集群支持以下對象類型來實現容器化工作負載:

·Pod：用於管理和運行一組相關容器的邏輯結構。Pod中的所有容器共享存儲和網路資源，它是Kubernetes集群中最小的可部署計算單元。

·卷：在Pod級別定義的邏輯目錄，該目錄可由該Pod中的容器訪問。卷和Pod的使用壽命相同，這意味著它可以比Pod中的任何容器壽命都長。

·Service：一個REST對象，作為訪問Pod邏輯集的抽象層，以便將前端客戶端與後端操作解耦。

·命名空間：一組基於相同物理集群的虛擬集群。命名空間面向支持多個團隊或項目的許多用戶的環境。

Kubernetes提供了基於這些基本對象的控制器，以此來交付額外的功能。Kubernetes還包含一個API，它映射到每個對象類型，以提供使用Kubernetes環境的機制。

此外，每個Kubernetes集群都包含一個用於管理環境和自動化操作的控制平面。控制平面是在主系統和節點系統上運行的進程的集合。主進程運行多個進程，用於運行控制器、管理Pod以及公開Kubernetes API。每個節點運行進程以維護網路規則、執行連接轉發且確保容器正在運行。

Kubernetes中的數據存儲

Pod提供了部署容器化工作負載的主要構建塊。它包含一個或多個容器、共享存儲資源和惟一的網路IP地址。Pod還包括了控制容器如何運行的選項。在大多數情況下，Pod只支持應用程序的一個實例，對於其他實例需要添加更多的Pod。

Kubernetes的存儲發生在Pod級別。一個Pod可以配置一組存儲卷，使Pod中的容器能夠共享存儲並實現數據的持久化保存，在容器重啟後也可以存活。Kubernetes提供了非常多的卷類型，如Azure Disk、CephFS、iSCSI、vSphere卷、Portworx卷和Amazon Elastic Block Store等等。

Kubernetes提供了一種特殊類型的卷，用於在容器和Pod的生命周期之外持久存儲數據。它被稱為PersistentVolume (PV)，它抽象了有關存儲如何提供給Pod容器或由Pod容器使用的詳細信息。

Kubernetes將PV實現為卷插件，其生命周期獨立於Pod。卷插件擴展了Kubernetes介面，以方便與外部存儲的連接。該插件是入樹（in-tree）模塊構建，並直接編譯到核心Kubernetes二進位文件中，這樣就可以在需要的時候向容器交付存儲。

由於插件內置於Kubernetes代碼中，添加一個新的存儲系統意味著供應商必須直接將插件代碼檢入主代碼庫，這可能會給Kubernetes平台帶來不穩定和安全問題。這個過程還將供應商與Kubernetes的發布周期聯繫起來，同時迫使他們向訪問Kubernetes代碼的任何人開放插件源代碼。

為了解決這些限制，Kubernetes引入了FlexVolume插件，它提供了一個出樹（out-of-tree）插件介面，支持與存儲相關的通信。通過這種方式，存儲供應商可以開發部署到Kubernetes環境中的驅動程序，在那裡，FlexVolume插件可以訪問這些驅動程序。

雖然Kubernetes的這種存儲方法能夠使一些供應商受益，但也帶來了一些挑戰。例如，插件很難部署，並且需要訪問每個集群機器上的根文件系統。

CSI卷插件

最近，Kubernetes推出了一個新的CSI卷插件，可以解決這些問題。它提供了一個符合CSI標準的出樹解決方案。CSI將存儲系統暴露給容器編排工具(如Kubernetes)管理的容器工作負載。這一新標準使供應商能夠開發一個單一驅動程序來支持任何符合CSI的容器編排解決方案。

隨著1.13版的發布，CSI插件開始對Kubernetes普遍可用。與FlexVolume插件一樣，供應商可以開發部署到Kubernetes環境中符合CSI的驅動程序，同時避免了FlexVolume插件帶來的許多挑戰。供應商不必接觸Kubernetes代碼，也不必擔心Kubernetes是如何實現的。一旦安裝了驅動程序，用戶就可以使用CSI卷插件執行附加或掛載卷以保存數據等任務。

雖然Kubernetes在最初設計之時，僅支持無狀態操作，但它在編排容器工作負載方面極具優勢。過去，將數據保存到容器或Pod的生命周期之外往往伴隨著挑戰。隨著CSI插件的引入，有望使企業更容易地為其工作負載應用容器技術，特別是隨著更多存儲供應商提供符合CSI的驅動程序。對於許多IT團隊來說，CSI會是他們向Kubernetes過渡時需要的一大動力，能夠輕鬆為Kubernetes實現存儲。

原文作者：Robert Sheldon

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！