Kubernetes已经成为集群调度领域最火的开源项目之一。使用Kubernetes部署和管理Web应用程序、移动后端和API服务相对容易，因为这些应用程序通常是无状态应用程序，通过基本的KubernetesAPI运行，无需额外知识即可扩展。从失败中恢复。但是如何使用Kubernetes运行有状态应用程序呢？像数据库、缓存和监控系统。这给我们带来了不小的挑战。因为这些系统需要应用程序领域知识才能正确扩展、升级和重新配置，以防止数据丢失或不可用。LeonidMirsky解释了如何在Kubernetes上部署和管理有状态应用程序。本文以在Kubernetes上运行数据库为例。您会在网上找到的许多Kubernetes示例都专注于运行无状态应用程序。通常，这些是标准的NodeJSExpress应用程序或用Flask编写的基于Python的API。现在，在Kubernetes上运行这些类型的应用程序相对容易。您拥有大规模管理和操作它们所需的一切：滚动部署、入口控制器、终止超时控制等。但是，如果您运行的有状态应用程序偶尔需要将数据写入磁盘并确保数据在容器重启之间持续存在，或者当容器被重新安排到另一个节点时，该怎么办？只是事情并没有那么简单。幸运的是，Kubernetes及其充满活力的社区为如何运行这些有状态工作负载提供了许多选项。我们将深入探讨这些选项，但这里有一些您可能会问的问题……1.为什么很难在Kubernetes上部署有状态应用程序？我们可以将卷附加到Pod模板吗？这还不够吗？理论上如上所述，您的应用程序现在可以写入磁盘，但如果容器重新启动或移动到另一个节点，那么卷将重新附加到容器的新位置。对于简单的情况，它确实如此。但是对于Elasticsearch、etcd、Consul这样的服务，情况就复杂多了。这些服务有一些常规Kubernetes部署控制器无法满足的要求。例如，您可能希望为每个Pod提供一个可预测的DNS名称，以简化初始集群的形成。或者，您部署的系统可能需要确保Pod将以某种预定义的顺序启动容器。此外，您可能希望为每个Pod创建并附加单独的卷，这些卷将在Pod的整个生命周期中绑定到它。对于常规Pod，您只能附加一个卷，并且该卷将在同一部署创建的所有Pod之间共享。我们也没有提到如何操作数据库。您还需要确保您有计划何时以及如何执行备份，或者在发生错误时如何执行恢复/故障转移。2.运行有状态应用程序的可用选项这里有一些关于如何在Kubernetes上部署数据库的选项。（1）StatefulSetStatefulSet是一个内置的控制器（译者注：原名PetSet，最早出现在Kubernetes1.4，后来在1.5改名为StatefulSet），本质上类似于Kubernetes的部署。最终，它将根据您指定的Pod模板创建和管理一组Pod。主要区别在于它为底层应用程序提供了以下保证：每个Pod都有一个稳定的、唯一的网络标识符。每个Pod可能有一个稳定、持久的存储卷。部署、扩展或终止都将以有序和优雅的方式执行。以下是一些使用StatefulSets实现开源数据库部署的示例：PauloPires的KubernetesElasticsearchClusterhttps://github.com/pires/kubernetes-elasticsearch-cluster/tree/master/statefulConsulonKubernetesbyKelseyHightowerhttps://github.com/kelseyhightower/consul-on-kubernetesStatefulSets是通用的，因此您可以使用它们来模拟数据库的独特集群形成或主/从架构。但是，最终的结果在操控方面会有些欠缺。您将需要添加额外的资源或自动化以确保可以执行定期备份或添加脚本来处理故障转移等边缘情况。最终，使用StatefulSets为更复杂的有状态服务建模可能会感觉有点笨拙，不是Kubernetes原生的，并且如上所述，将缺乏管理自动化。这就是Operator发挥作用的地方：StatefulSet是Kubernetes提供的负载管理控制器API，用于管理有状态的应用程序。在Pod管理的基础上，保证Pod的顺序和一致性。和Deployment一样，StatefulSet也是使用容器的Spec来创建Pod。与StatefulSet不同的是，StatefulSet创建的Pod在生命周期中会维护一个持久化的标记（比如PodName）。简单的说，StatefulSet就是一个controller，为Pod提供一个唯一标识，可以保证部署和扩展的顺序。(2)Operator如果你决定在Kubernetes上运行数据的原因之一是为了统一管理所有应用组件，那么Operator可能会提供你想要的体验！与其将应用程序放入StatefulSet模型，不如编写（或使用其他人的）自定义控制器。作为用户，这允许您使用KubectlCLI将有状态应用程序作为本地Kubernetes资源进行控制。例如，如果您部署了etcdOperator，则可以使用以下kubectl命令检查集群的备份状态：kubectlgetEtcdBackupexample-etcd-clusteroperations有状态应用程序是独一无二的。您无需担心向使用StatefulSet实现的Elasticsearch集群添加备份cron。使用Operator，您只需指定存储此备份的存储桶。不幸的是，由于编写一个新的Operator除了有状态应用程序的细节之外还需要Kubernetes及其API的知识，因此可用的Operator并不多，而且现有的Operator仍然相对较新。以下是运算符的一些示例，因此您可以自己测试这些概念：CoreOS的Prometheus运算符https://github.com/coreos/prometheus-operator-operator译注：Operator是CoreOS推出的一个框架，用于简化复杂有状态应用的管理。它是一个控制器，通过扩展KubernetesAPI来感知应用程序状态并自动创建、管理和配置应用程序实例。Operator基于ThirdPartyResources（CRD）扩展新的应用资源，通过controller保证应用处于预期的状态。例如，etcdoperator通过以下三个步骤模拟管理一个etcd集群的行为：通过KubernetesAPI观察集群的当前状态；分析当前状态与预期状态之间的差异；调用etcd集群管理API或KubernetesAPI来消除这些差异。(3)其他本节提到的定义较少，主要是为了说明对于特定的数据库，比如我们后面会看到的PostgreSQL例子，还有其他的选择，可以作为Docker容器在Kubernetes上进行部署和管理。有时，除了StatefulSet或专用的Operator实现之外，还有其他可用选项。例如，Stolon是一个“用于PostgreSQL高可用性的云原生PostgreSQL管理器”，虽然我个人没有机会使用它，但我看到一些帖子提到了Stolon。要在Kubernetes上部署Stolon，您可以使用提供的StatefulSet定义。但是，由于Stolon的功能，您无需添加自己的集群管理自动化来控制PostgreSQL集群。Stolon为此提供了自己的CLI。3.总结这里有一个快速决策树，希望能帮助您决定如何最好地在Kubernetes上部署和维护有状态工作负载：您能避免维护自己的数据库吗？是的。然后忘记这篇文章并付钱给别人为你做。不能。然后继续阅读。您是否已经在Kubernetes上运行了大部分应用程序？否。以与其他应用程序类似的方式部署数据库。根据您的方便，使用物理服务器、云实例或虚拟机的组合。是的。您能为您选择的数据库找到成熟的Operator吗？你能找到一个像Stolon（上面提到的）这样的独立项目来简化管理吗？你能找到基于StatefulSet的部署吗？它“生产就绪”了吗？对于无状态应用程序，Kubernetes是一个非常直观的平台。但是，在处理数据库等服务时，您需要更多地考虑它们在Kubernetes上的部署和管理方式。好消息和坏消息是有多种选择可供选择。
