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

[[285268]]

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

通常，這些都是標準的 NodeJS Express 應用或用 Flask 編寫的基于 Python 的 API。

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

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

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

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

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

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

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

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

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

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

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

2.運行有狀態(tài)應用的可用選項

以下是一些關于如何在 Kubernetes 上部署數(shù)據(jù)庫的幾個選項。

（1）StatefulSet

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

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

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

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

下面是一些使用 StatefulSet 的開源數(shù)據(jù)庫部署實現(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ù)庫的約束聚簇構造(unique cluster formation)或主 / 從架構進行建模。

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

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

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

（2）Operator

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

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

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

kubectl get EtcdBackup example-etcd-cluster 

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

不幸的是，由于編寫新的 Operator 除了需要了解有狀態(tài)應用的細節(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 推出的旨在簡化復雜有狀態(tài)應用管理的框架，它是一個感知應用狀態(tài)的控制器，通過擴展 Kubernetes API 來自動創(chuàng)建、管理和配置應用實例。Operator 基于 Third Party Resources (CRD)擴展了新的應用資源，并通過控制器來保證應用處于預期狀態(tài)。比如 etcd operator 通過下面的三個步驟模擬了管理 etcd 集群的行為：通過 Kubernetes API 觀察集群的當前狀態(tài);分析當前狀態(tài)與期望狀態(tài)的差別;調用 etcd 集群管理 API 或 Kubernetes API 消除這些差別。

（3）其他

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

有時，除了 StatefulSet 或專用的 Operator 實現(xiàn)之外，還有其他可用的選項。

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

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

3.總結

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

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

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

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

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

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

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

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

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