如何在Kubernetes 上部署有狀態(tài)的云原生應(yīng)用

如何在Kubernetes 上部署有狀態(tài)的云原生應(yīng)用，針對(duì)這個(gè)問題，這篇文章詳細(xì)介紹了相對(duì)應(yīng)的分析和解答，希望可以幫助更多想解決這個(gè)問題的小伙伴找到更簡(jiǎn)單易行的方法。

Kubernetes 的出現(xiàn)使得廣大開發(fā)同學(xué)也能運(yùn)維復(fù)雜的分布式系統(tǒng)，它大幅降低了容器化應(yīng)用部署的門檻，用戶通過它提供的 Deployment、ReplicaSet 控制器可以方便地部署一套高可用、可擴(kuò)展的分布式無狀態(tài)服務(wù)，這類應(yīng)用的特點(diǎn)是不在本地存儲(chǔ)數(shù)據(jù)，通過簡(jiǎn)單的負(fù)載均衡策略可實(shí)現(xiàn)請(qǐng)求分發(fā)。但是越來越多的開發(fā)人員希望把項(xiàng)目中依賴的數(shù)據(jù)庫(kù)這類有狀態(tài)服務(wù)也部署到Kubernetes里面，通過其進(jìn)行編排部署，使應(yīng)用與所依賴的后端存儲(chǔ)盡量靠近一些，因?yàn)橛袪顟B(tài)服務(wù)的復(fù)雜性，這一過程并不容易。

在 Kubernetes 中有多種運(yùn)行有狀態(tài)應(yīng)用程序的技術(shù)，每種技術(shù)各有優(yōu)缺點(diǎn)。本文試圖介紹在 Kubernetes 中運(yùn)行有狀態(tài)應(yīng)用程序的關(guān)鍵方法，并探討了在 Kubernetes 上部署有狀態(tài)的服務(wù)的幾種可行方案。

第一種方法是將 Kubernetes 集群與 Samba、NFS 或 GlusterFS 等傳統(tǒng)的存儲(chǔ)基礎(chǔ)設(shè)施集成在一起，這種方法可以輕松擴(kuò)展到基于云的共享文件系統(tǒng)，例如 Amazon EFS、Azure 文件和 Google Cloud Filestore，在這種架構(gòu)中，存儲(chǔ)層與 Kubernetes 管理的計(jì)算層完全脫鉤。由于底層存儲(chǔ)的持久性，工作負(fù)載完全與其分離，這使得 Pod 可以在任何節(jié)點(diǎn)上進(jìn)行調(diào)度，而無需定義節(jié)點(diǎn)親和性。

但是，這種方法對(duì)于需要高 I/O 吞吐量的有狀態(tài)工作負(fù)載并不理想。共享文件系統(tǒng)并非旨在提供關(guān)系型數(shù)據(jù)、NoSQL 數(shù)據(jù)庫(kù)和其他寫入密集型工作負(fù)載所需的 IOPS。此方法的典型應(yīng)用場(chǎng)景應(yīng)該是內(nèi)容管理系統(tǒng)，機(jī)器學(xué)習(xí)系統(tǒng)和數(shù)字資產(chǎn)管理系統(tǒng)等。

第二種方法是通過 Kubernetes 的控制器來維護(hù)所需的配置狀態(tài)，Deployment、ReplicaSet、DaemonSet 和 StatefulSet 是一些常用的控制器， 其中 StatefulSet 是一種特殊的控制器。集群工作負(fù)載通?？梢跃哂幸粋€(gè)或多個(gè)主服務(wù)器和多個(gè)從服務(wù)器，大多數(shù)數(shù)據(jù)庫(kù)都設(shè)計(jì)為在集群模式下運(yùn)行，以提供高可用性和容錯(cuò)能力，有狀態(tài)的集群工作負(fù)載持續(xù)在主服務(wù)器和從服務(wù)器之間復(fù)制數(shù)據(jù)。為此，集群基礎(chǔ)架構(gòu)希望參與的實(shí)體（主從）具有一致暴露的端點(diǎn)，借以可靠地同步狀態(tài)。但是在 Kubernetes 中，Pod 被設(shè)計(jì)為臨時(shí)的，不能保證具有固定的名稱和 IP 地址。有狀態(tài)集群工作負(fù)載的另一個(gè)要求是持久的存儲(chǔ)后端，該后端具有容錯(cuò)能力并且能夠滿足 IOPS 的需求。

Kubernetes 中引入 StatefulSet 控制器來運(yùn)行有狀態(tài)的集群工作負(fù)載，保證屬于 StatefulSet 的 Pod 具有穩(wěn)定的唯一標(biāo)識(shí)符，它們遵循可預(yù)測(cè)的命名約定，還支持有序、便捷的部署和擴(kuò)展。StatefulSet 中的每個(gè) Pod 都有一個(gè)對(duì)應(yīng)的持久卷聲明（PVC），該聲明遵循相似的命名約定。當(dāng) Pod 終止并在其他節(jié)點(diǎn)上重新調(diào)度時(shí)，Kubernetes 控制器將確保 Pod 與同一 PVC 關(guān)聯(lián)，以此來保證集群的狀態(tài)。

由于 StatefulSet 中的每個(gè) Pod 都有專用的 PVC 和 PV，因此使用共享存儲(chǔ)沒有特別的規(guī)定。但是可以預(yù)期 StatefulSet 能獲得快速、可靠、持久的存儲(chǔ)層（例如基于 SSD 的塊存儲(chǔ)設(shè)備）的支持，在確保將寫操作完全提交到磁盤后，可以從塊存儲(chǔ)設(shè)備中獲取常規(guī)備份和快照。典型的應(yīng)用場(chǎng)景如 Apache ZooKeeper，Apache Kafka，MySQL，PostgreSQL 等。

雖然用戶可以基于 StatefulSet 在 Kubernetes 中部署運(yùn)維一套高可用有狀態(tài)服務(wù)，如高 MySQL，PostgreSQL 等。但過程相對(duì)復(fù)雜，用戶既要熟悉各種 Kubernetes 資源對(duì)象，又要學(xué)習(xí)很多應(yīng)用相關(guān)的操作細(xì)節(jié)，同時(shí)還需維護(hù)一套復(fù)雜的管理腳本，為了降低在 Kubernetes 中部署復(fù)雜應(yīng)用的門檻 CoreOS 公司推出了 Operator。

Operator 是用來打包、部署和管理需要運(yùn)行在 Kubernetes 之上復(fù)雜應(yīng)用的一種方法，Operator將運(yùn)維人員對(duì)軟件操作的知識(shí)代碼化，同時(shí)綜合運(yùn)用 Kubernetes 中的各種資源對(duì)象來實(shí)現(xiàn)復(fù)雜應(yīng)用的部署和運(yùn)維。Operator 通過  CustomResourceDefinition（CRD）為服務(wù)定義了新的資源對(duì)象，同時(shí)通過自定義控制器來保證應(yīng)用處于預(yù)期狀態(tài)。

Operator 的工作流程可抽象成以下三個(gè)步驟：

• Observe - 通過 Kubernetes API 觀察目標(biāo)對(duì)象的狀態(tài)；

• Analyze - 分析當(dāng)前狀態(tài)與期望狀態(tài)的差別；

• Act - 執(zhí)行編排操作，將當(dāng)前狀態(tài)調(diào)整為期望狀。

由于開源社區(qū)的推進(jìn)，Operator 越來越普及。但是應(yīng)用于各種常規(guī)服務(wù)的 Operator 成熟度各不相同，具體細(xì)節(jié)請(qǐng)參考 github 開源項(xiàng)目 awesome-operators。Operator 典型的應(yīng)用場(chǎng)景有 MySQL 高可用集群、TiDB 集群、 TensorFlow 集群、Hadoop 生態(tài)相關(guān)集群等。

關(guān)于如何在Kubernetes 上部署有狀態(tài)的云原生應(yīng)用問題的解答就分享到這里了，希望以上內(nèi)容可以對(duì)大家有一定的幫助，如果你還有很多疑惑沒有解開，可以關(guān)注億速云行業(yè)資訊頻道了解更多相關(guān)知識(shí)。