Kubernetes 已經(jīng)成為了集群調(diào)度領(lǐng)域炙手可熱的開(kāi)源項(xiàng)目之一。用 Kubernetes 來(lái)部署和管理 Web 應(yīng)用、移動(dòng)后端和 API 服務(wù)等相對(duì)容易，因?yàn)檫@些應(yīng)用通常都是無(wú)狀態(tài)應(yīng)用，通過(guò)基本的 Kubernetes API 就能運(yùn)行，可以在沒(méi)有其他知識(shí)的情況下進(jìn)行擴(kuò)展并從故障中恢復(fù)。但要是用 Kubernetes 來(lái)運(yùn)行有狀態(tài)應(yīng)用呢?比如數(shù)據(jù)庫(kù)、緩存和監(jiān)控系統(tǒng)。這就為我們帶來(lái)了不小的挑戰(zhàn)。因?yàn)檫@些系統(tǒng)需要應(yīng)用領(lǐng)域的知識(shí)才能正確擴(kuò)展、升級(jí)和重新配置，從而防止數(shù)據(jù)丟失或不可用。Leonid Mirsky 為我們闡述了如何在 Kubernetes 部署和管理有狀態(tài)應(yīng)用，本文以在 Kubernetes 上運(yùn)行數(shù)據(jù)庫(kù)為例講解。

[[285268]]

你在網(wǎng)上所能找到的許多 Kubernetes 示例，大都集中于運(yùn)行無(wú)狀態(tài)應(yīng)用。

通常，這些都是標(biāo)準(zhǔn)的 NodeJS Express 應(yīng)用或用 Flask 編寫(xiě)的基于 Python 的 API。

現(xiàn)在，在 Kubernetes 上運(yùn)行這些類(lèi)型的應(yīng)用相對(duì)比較容易了。你擁有大規(guī)模管理和運(yùn)營(yíng)它們所需的一切：滾動(dòng)部署、入口控制器、終止超時(shí)控制，等等。

但是，如果運(yùn)行一個(gè)有狀態(tài)應(yīng)用，它偶爾需要在磁盤(pán)上寫(xiě)入數(shù)據(jù)，并確保這些數(shù)據(jù)在容器重啟之間，或容器重新調(diào)度到另一個(gè)節(jié)點(diǎn)時(shí)仍然保持不變，又該如何做呢?

這就是事情沒(méi)有那么簡(jiǎn)單的地方。幸運(yùn)的是，Kubernetes 及其充滿活力的社區(qū)，為如何運(yùn)行這些有狀態(tài)的工作負(fù)載提供了許多選擇。

我們將更深入研究這些選擇，但你可能會(huì)問(wèn)以下這些問(wèn)題……

1.為何在 Kubernetes 上部署有狀態(tài)應(yīng)用比較困難?

我們能不能在 Pod 模板上附加一個(gè)卷?這難道還不夠嗎?從理論上講，你的應(yīng)用現(xiàn)在就可以寫(xiě)入磁盤(pán)，但如果容器重啟或移動(dòng)到另一個(gè)節(jié)點(diǎn)的話，那么這個(gè)卷將會(huì)被重新附加到容器的新位置。

對(duì)于簡(jiǎn)單的案例來(lái)說(shuō)，確實(shí)如此。但是對(duì)于 Elasticsearch、etcd、Consul 等服務(wù)來(lái)說(shuō)，情況就要復(fù)雜得多了。

這些服務(wù)有一些常規(guī) Kubernetes 部署控制器無(wú)法滿足的要求。

例如，你可能需要為每個(gè) Pod 提供可預(yù)測(cè)的 DNS 名稱(chēng)，以便使初始集群形成更加容易?；蛘撸悴渴鸬南到y(tǒng)，可能需要確保 Pod 將按某種預(yù)定義的順序來(lái)啟動(dòng)容器。

此外，你還可能希望為每個(gè) Pod 創(chuàng)建并附加單獨(dú)的卷，這些卷將在整個(gè) Pod 的生命周期中與其綁定。對(duì)于常規(guī) Pod，你只能附加一個(gè)卷，這個(gè)卷將在同一部署創(chuàng)建的所有 Pod 之間共享。

我們也沒(méi)有提到如何操作數(shù)據(jù)庫(kù)。你還需要確保制定一個(gè)計(jì)劃，確定何時(shí)以及如何執(zhí)行備份，或者在發(fā)生錯(cuò)誤時(shí)如何執(zhí)行恢復(fù) / 故障轉(zhuǎn)移。

2.運(yùn)行有狀態(tài)應(yīng)用的可用選項(xiàng)

以下是一些關(guān)于如何在 Kubernetes 上部署數(shù)據(jù)庫(kù)的幾個(gè)選項(xiàng)。

（1）StatefulSet

StatefulSet，是一個(gè)內(nèi)置的控制器(譯者注：原稱(chēng) PetSet，首次出現(xiàn)在 Kubernetes 1.4，后在 1.5 更名為 StatefulSet)，本質(zhì)上類(lèi)似于 Kubernetes 的部署。

最終，它將基于你將指定的 Pod 模板創(chuàng)建和管理一組 Pod。

主要區(qū)別在于，它為底層應(yīng)用提供了以下保證：

• 每個(gè) Pod 都有一個(gè)穩(wěn)定、唯一的網(wǎng)絡(luò)標(biāo)識(shí)符。
• 每個(gè) Pod 可能有一個(gè)穩(wěn)定的、持久的存儲(chǔ)卷。
• 部署、擴(kuò)展或終止都將是有序而優(yōu)雅地執(zhí)行。

下面是一些使用 StatefulSet 的開(kāi)源數(shù)據(jù)庫(kù)部署實(shí)現(xiàn)的示例：

• Kubernetes Elasticsearch Cluster，作者：Paulo Pires

https://github.com/pires/kubernetes-elasticsearch-cluster/tree/master/stateful

• Consul on Kubernetes，作者：Kelsey Hightower

https://github.com/kelseyhightower/consul-on-kubernetes

StatefulSet 是通用的，因此你可以使用它們來(lái)對(duì)數(shù)據(jù)庫(kù)的約束聚簇構(gòu)造(unique cluster formation)或主 / 從架構(gòu)進(jìn)行建模。

然而，最終的結(jié)果將在操作方面有所欠缺。你將需要添加其他資源或自動(dòng)化，以確保能夠執(zhí)行定期備份或添加處理諸如故障轉(zhuǎn)移等邊緣情況的腳本。

最終，使用 StatefulSet 為更復(fù)雜的有狀態(tài)服務(wù)建?？赡軙?huì)有點(diǎn)笨拙的感覺(jué)，并且還不是 Kubernetes 原生的，而且，如上所述，它還將缺乏管理自動(dòng)化。這就是 Operator 發(fā)揮作用之處：

StatefulSet 是 Kubernetes 提供的管理有狀態(tài)應(yīng)用的負(fù)載管理控制器 API。在 Pod 管理的基礎(chǔ)上，保證 Pod 的順序和一致性。與 Deployment 一樣，StatefulSet 也是使用容器的 Spec 來(lái)創(chuàng)建 Pod，與之不同 StatefulSet 創(chuàng)建的 Pod 在生命周期中會(huì)保持持久的標(biāo)記(例如 Pod Name)。簡(jiǎn)單地說(shuō)，StatefulSet 是一個(gè)給 Pod 提供唯一標(biāo)志的控制器，它可以保證部署和擴(kuò)展的順序。

（2）Operator

如果你決定在 Kubernetes 上運(yùn)行數(shù)據(jù)的原因之一，是為了統(tǒng)一所有應(yīng)用程序組件的管理，那么 Operator 可能會(huì)提供你想要擁有的體驗(yàn)!

與其將應(yīng)用程序放入 StatefulSet 模型中，不如編寫(xiě)(或者使用其他人的)自定義控制器。

作為用戶(hù)，這允許你使用 Kubectl CLI 來(lái)控制有狀態(tài)應(yīng)用，將其作為本地 Kubernetes 資源。例如，如果你部署了 etcd Operator，那么可以使用下面的 kubectl 命令檢查集群的備份狀態(tài)：

kubectl get EtcdBackup example-etcd-cluster 

與 StatefulSet 相比，Operator 的主要優(yōu)勢(shì)在于，它們添加了一個(gè)自動(dòng)化層，該層對(duì)于其操作的有狀態(tài)應(yīng)用是獨(dú)有的。你無(wú)需擔(dān)心如何在 Elasticsearch 集群中添加備份 cron，該集群使用 StatefulSet 實(shí)現(xiàn)。使用 Operator，你只需指定存儲(chǔ)此備份的存儲(chǔ)桶即可。

不幸的是，由于編寫(xiě)新的 Operator 除了需要了解有狀態(tài)應(yīng)用的細(xì)節(jié)之外，還需要了解 Kubernetes 及其 API，因此，目前可用的 Operator 并不多，而且現(xiàn)有的 Operator 仍然相對(duì)較新。

下面是一些 Operator 的示例，你可以自己測(cè)試概念：

• Prometheus operator，作者：CoreOS

https://github.com/coreos/prometheus-operator

• Elastic Search operator，作者：UPMC Enterprises

https://github.com/upmc-enterprises/elasticsearch-operator

譯注：Operator 是 CoreOS 推出的旨在簡(jiǎn)化復(fù)雜有狀態(tài)應(yīng)用管理的框架，它是一個(gè)感知應(yīng)用狀態(tài)的控制器，通過(guò)擴(kuò)展 Kubernetes API 來(lái)自動(dòng)創(chuàng)建、管理和配置應(yīng)用實(shí)例。Operator 基于 Third Party Resources (CRD)擴(kuò)展了新的應(yīng)用資源，并通過(guò)控制器來(lái)保證應(yīng)用處于預(yù)期狀態(tài)。比如 etcd operator 通過(guò)下面的三個(gè)步驟模擬了管理 etcd 集群的行為：通過(guò) Kubernetes API 觀察集群的當(dāng)前狀態(tài);分析當(dāng)前狀態(tài)與期望狀態(tài)的差別;調(diào)用 etcd 集群管理 API 或 Kubernetes API 消除這些差別。

（3）其他

本節(jié)提到的定義較少，主要是為了說(shuō)明對(duì)于特定的數(shù)據(jù)庫(kù)，比如我們稍后將看到的 PostgreSQL 示例，還有其他選項(xiàng)可以將它們作為 Docker 容器在 Kubernetes 上部署和管理。

有時(shí)，除了 StatefulSet 或?qū)Ｓ玫?Operator 實(shí)現(xiàn)之外，還有其他可用的選項(xiàng)。

例如，Stolon 是一個(gè)“PostgreSQL 高可用性的云原生 PostgreSQL 管理器”，雖然我個(gè)人還沒(méi)有機(jī)會(huì)使用它，但看到過(guò)一些帖子中提到了 Stolon。

要在 Kubernetes 上部署 Stolon，可以使用提供的 StatefulSet 定義。但是，由于 Stolon 的功能，你不需要添加自己的集群管理自動(dòng)化來(lái)控制 PostgreSQL 集群。Stolon 為此提供了自己的 CLI。

3.總結(jié)

下面是一棵快速?zèng)Q策樹(shù)，希望它能夠幫助你作出如何在 Kubernetes 上進(jìn)行優(yōu)秀部署和維護(hù)有狀態(tài)工作負(fù)載的決策：

你能避免維護(hù)自己的數(shù)據(jù)庫(kù)嗎?

• 能。那就忘掉本文吧，付錢(qián)給別人，讓他幫你做這件事。
• 不能。那就繼續(xù)讀下去。

你是否已經(jīng)在 Kubernetes 上運(yùn)行了大部分應(yīng)用程序?

• 沒(méi)有。以與其他應(yīng)用程序類(lèi)似的方式部署數(shù)據(jù)庫(kù)。根據(jù)你的方便程度，組合使用物理服務(wù)器、云實(shí)例或虛擬機(jī)。
• 是的。

你能為所選擇的數(shù)據(jù)庫(kù)找到成熟的 Operator 嗎?

你能找到一個(gè)像 Stolon(上面提到的)這樣的獨(dú)立項(xiàng)目來(lái)使管理變得更容易嗎?

你可以找到基于 StatefulSet 的部署嗎?它是否“生產(chǎn)準(zhǔn)備就緒”?

當(dāng)涉及到無(wú)狀態(tài)應(yīng)用程序時(shí)，Kubernetes 是一個(gè)非常直觀的平臺(tái)。然而，在處理類(lèi)似數(shù)據(jù)庫(kù)的服務(wù)時(shí)，你需要更多考慮如何在 Kubernetes 上部署和管理它們。好消息和壞消息就是，都有幾個(gè)選項(xiàng)可供選擇。