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

[[285268]]

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

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

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

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

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

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

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

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

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

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

例如，你可能需要為每個(gè) Pod 提供可預(yù)測的 DNS 名稱，以便使初始集群形成更加容易。或者，你部署的系統(tǒng)，可能需要確保 Pod 將按某種預(yù)定義的順序來啟動(dòng)容器。

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

我們也沒有提到如何操作數(shù)據(jù)庫。你還需要確保制定一個(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ù)庫的幾個(gè)選項(xiàng)。

（1）StatefulSet

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

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

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

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

下面是一些使用 StatefulSet 的開源數(shù)據(jù)庫部署實(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 是通用的，因此你可以使用它們來對數(shù)據(jù)庫的約束聚簇構(gòu)造(unique cluster formation)或主 / 從架構(gòu)進(jìn)行建模。

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

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

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

（2）Operator

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

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

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

kubectl get EtcdBackup example-etcd-cluster 

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

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

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

• Prometheus operator，作者：CoreOS

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

• Elastic Search operator，作者：UPMC Enterprises

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

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

（3）其他

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

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

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

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

3.總結(jié)

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

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

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

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

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

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

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

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

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