Kubernetes是發展最快的基礎設施項目之一。在短短五年的時間裡，它已經成熟，成為現代基礎設施的基礎。從公有云中的託管容器即服務（CaaS）到數據中心中的企業平臺即服務（PaaS），Kubernetes正變得無處不在。
在Kubernetes早期，它主要被認為是運行web級無狀態服務的平臺。有狀態的服務（如數據庫和分析工作負載）要麼在虛擬機中運行，要麼作為基於雲的託管服務運行。但隨著Kubernetes成為最受歡迎的基礎設施層，其生態系統努力使有狀態應用程序成為Kubernetes領域的重要一份子。
在Kubernetes中運行有狀態應用程序有多種技術，每種技術都有其優缺點。
本文重點介紹在Kubernetes中運行有狀態應用程序的關鍵方法、可用的選擇以及與每種方法對應的工作負載類型。你需要熟悉Kubernetes存儲基礎設施的關鍵構建塊，如持久卷、持久卷聲明和存儲類。
集群共享存儲
第一種方法是將Kubernetes集群與通過Samba、NFS或GlusterFS公開的傳統存儲基礎設施集成。這種方法可以很容易地擴展到基於雲的共享文件系統，如Amazon EFS、Azure Files和Google Cloud Filestore。
在這個架構中，存儲層與由Kubernetes管理的計算層完全分離。有兩種方法可以使用Kubernetes Pods中的共享存儲：
1） 本機配置：幸運的是，大多數共享文件系統都在上游Kubernetes發行版中內置了卷插件，或者有一個容器存儲接口（CSI）驅動程序。這使集群管理員能夠使用特定於共享文件系統或託管服務的參數以聲明方式定義持久卷（PV）。
2） 基於主機的配置：在這種方法中，啟動腳本在負責裝載共享存儲的每個節點上運行。Kubernetes集群中的每個節點都有一個一致的、眾所周知的、對工作負載公開的掛載點。持久卷通過hostPath或Local PV指向主機目錄。
由於底層存儲管理耐用性和持久性，因此工作負載與之完全分離。這使得Pod可以在任何節點上得到調度，而無需定義節點關聯性，從而確保Pod始終在所選節點上調度。
但是，對於需要高I/O吞吐量的有狀態工作負載，這種方法並不理想。共享文件系統的設計不是為了提供關係數據庫、NoSQL數據庫和其他寫密集型工作負載所需的IOPS。
存儲選擇：GlusterFS、Samba、NFS、Amazon EFS、Azure Files、Google雲文件存儲。
典型工作負載：內容管理系統、機器學習訓練/推理作業和數字資產管理系統。
StatefulSet
Kubernetes通過控制器維護所需的配置狀態。Deployment、ReplicaSet、DaemonSet和StatefulSet是一些常用的控制器。
StatefulSet是一種特殊類型的控制器，它使在Kubernetes中運行集群工作負載變得容易。集群工作負載通常可能有一個或多個主服務器和多個從服務器。大多數數據庫設計為以集群模式運行，以提供高可用性和容錯性。
有狀態的集群工作負載不斷地在主服務器和從服務器之間複製數據。為此，集群基礎設施期望參與實體（主實體和從實體），以具有一致且眾所周知的端點來可靠地同步狀態。但是在Kubernetes中，Pods被設計成暫態的，不能保證它有相同的名稱和IP地址。
有狀態集群工作負載的另一個需求是持久的存儲後端——它是容錯的，並且能夠處理IOPS。
為了便於在Kubernetes中運行有狀態集群工作負載，引入了StatefulSet。確保屬於StatefulSet的Pod具有穩定、唯一的標識符。它們遵循可預測的命名約定，還支持有序、“優雅”的部署和擴展。
參與StatefulSet的每個Pod都有一個對應的持久卷聲明（PVC），該聲明遵循類似的命名約定。當一個Pod被終止並在另一個節點上重新調度時，Kubernetes控制器將確保該Pod與相同的PVC相關聯，這將保證狀態是完整的。
由於StatefulSet中的每個Pod都有一個專用的PVC和PV，因此沒有使用共享存儲的硬性規定。但StatefulSet需要一個快速、可靠、持久的存儲層作為後盾，比如基於SSD的塊存儲設備。在確保寫入完全提交到磁盤之後，可以從塊存儲設備中獲取常規備份和快照。
存儲選擇：SSD、塊存儲設備（如Amazon EBS、Azure Disks、GCE PD）。
典型工作負載：Apache ZooKeeper、Apache Kafka、Percona Server for MySQL、PostgreSQL Automatic Failover和JupyterHub。
雲原生存儲
Kubernetes的崛起創造了一個新的細分市場。由於存儲是雲原生基礎設施的關鍵組成部分之一，雲原生存儲市場的一個新細分市場在最近幾年迅速發展。
雲原生存儲為Kubernetes帶來了傳統的存儲原語和工作流。與其他服務一樣，它是從底層硬件和操作系統中抽象出來的。從供應到退役，工作流遵循與典型Kubernetes資源相同的生命週期。雲原生存儲是以應用程序為中心的，這意味著它理解工作負載的上下文，而不是集群外部的獨立層。與其他資源一樣，雲原生存儲可以根據工作負載條件和特性進行擴展和收縮。它能夠將連接到每個節點的單個磁盤集中起來，並將它們作為一個統一的邏輯卷公開給Kubernetes Pod。
從安裝存儲集群到調整卷大小，雲原生存儲使Kubernetes管理員能夠使用由功能強大的kubectl CLI管理的常見YAML構件。雲原生存儲具有動態資源配置、對多個文件系統的支持、快照、本地和遠程備份、動態卷大小調整等功能。
雲原生存儲平臺唯一的期望是集群內原始存儲的可用性——這些原始存儲可以聚合並彙集到一個邏輯卷中。原始存儲可以是本地集群的直連存儲（DAS），也可以是公有云中運行的託管集群的塊存儲。
雲原生存儲對於容器就像塊存儲對於虛擬機一樣。兩者都是從底層物理存儲中分割出來的邏輯存儲塊。塊存儲連接到VM，雲原生存儲則通過容器使用的持久卷可用。
大多數雲原生存儲平臺都帶有一個自定義調度程序，以支持存儲和計算的超融合。自定義調度程序與Kubernetes的內置調度程序一起工作，以確保Pod始終位於擁有數據的同一節點上。
存儲選擇：NetApp Trident、Maya Data、Portworx、Reduxio、Red Hat OpenShift Container Storage、Robin Systems、Rook、StorageOS。
典型工作負載：任何期望耐用性和持久性的工作負載。
