Kubernetes的采用已经大规模加速，引领了一种新的、云原生的方法来构建和交付企业所需的软件，使用户满意，员工成功。缓慢而繁重的工作已经被可互换的、独立的软件对象所取代，这些对象可以通过简单的配置，并通过自动复制进行扩展。如果一个对象出现故障，它就会被替换。为了交付新的软件，对象在运动中被替换。
但不是所有的应用程序都是一样的。虽然Kubernetes容器编排自然适合无状态的应用程序，但有状态的应用程序管理及其固有的依赖性对编排范式提出了特殊的挑战。本篇文章探讨了使用Kubernetes协调有状态应用的组织可采用的解决方案路径，并介绍了一些可能有助于开发团队在这三者之间做出选择的因素。
Kubernetes中状态的挑战
协调的魔力--能够快速交换和更新容器--对于有状态的应用程序和数据库来说是一个很大的障碍。容器化的整个承诺，即能够快速自由地移动和管理，在应用数据库被拴在本地存储上时就会被打破。
为什么呢？因为Kubernetes的部署是通过复制取胜的。这就是DevOps如何以更少的努力和更大的信心建立、部署、扩展和回退。但复制对有状态的应用程序不起作用。
- 数据库复制不像其他容器那样可以互换，它们有独特的状态
- 数据库还需要与运行相同应用程序的其他节点紧密协调，以确保版本和其他，并需要仔细协调。
解决有状态的问题：通往成功的三条道路
通往有状态的Kubernetes的道路有三个大的交叉点，还有一些其他小的导航选项。我们将分别回顾这三条道路。
- 在Kubernetes之外运行。
- 使用云服务，
- 在本地Kubernetes中运行
最大的选择，最大的努力：在Kubernetes之外运行你的数据库
最直接的方法是简单地旋转一个新的虚拟机，在Kubernetes环境之外运行数据库。但不幸的是，这里的舒适度的高成本是你所承担的额外的操作工作量。因为即使Kubernetes有一个高质量的、自动化的版本，你还是会在整个过程中重复工作。
- 流程监控
- 配置管理
- 数据中心内的负载平衡
- 服务发现
- 监控和日志
其结果是最大的选择，但也是一个完整的管理工具堆栈，你必须在Kubernetes之外运行。
更少的控制，更少的努力：通过云服务运行你的数据库。
你也可以利用云服务，在Kubernetes之外运行你的数据库。这将消除管理旋转、扩展和管理数据库的需要，并通过外部服务消除这种冗余的基础设施栈。
缺点是你只能使用云服务提供商提供的DBaaS，这对那些在内部或内部运行的人来说更没有意义。而且，由于你不能直接访问运行数据库的基础设施，微调性能和管理合规性可能是一个问题。
本地控制，最小努力：在Kubernetes内运行你的数据库
Kubernetes确实有两个集成的本地控制器，用于在容器内运行数据库，就像部署无状态应用程序一样。这些控制器最大限度地提高了集成度和自动化程度，保留了更多的工作负载控制，并消除了前面列出的维护 "围绕数据库服务 "的单独堆栈所需的时间、成本和复杂性。
StatefulSet控制器
有状态应用程序的第一个控件是 StatefulSet 控制器。像部署一样，StatefulSet 管理基于相同的容器规格但不能互换的 pod。通过给每个pod分配一个持久的、唯一的ID（通过一个容易建立的Headless Service），应用程序和数据库都能保持连接，无论它们被分配到哪个节点。
这也意味着，随着应用程序的扩大和缩小，连接被维护，并实现持久性。这使得它们成为需要稳定、持久的存储和有序、自动扩展和更新的应用程序的理想选择。这包括像ZooKeeper这样的分布式控制器，以及像MySQL集群、Redis、Kafka、MongoDB等工作负载。
要了解更多关于StatefulSet如何通过LocalPersistentVolume的方式支持本地存储，请阅读这里。
DaemonSet 控制器
第二个原生的有状态控件是DaemonSet 控制器。
StatefulSets使用唯一的ID来保持应用程序和数据库在节点间的连接，而DaemonSets确保所有（或一些）节点运行一个pod的副本。当一个节点被添加时，所需的数据库pod也被添加。当节点被移除时，pod会通过垃圾收集器被移除。
正如你可能从名字中猜到的那样，DaemonSet控制器在运行后台进程（或守护进程）时特别有用，特别是围绕性能监控或日志收集和/或分析。
通过限制节点对数据库的支持，DaemonSets消除了由资源争夺和竞争引起的StatefulSets的潜在性能问题。
选择正确的控制器：DaemonSets vs StatefulSets
正如我们已经提到的，工作负载的性质，以及对其他Kubernetes最佳实践的遵守，必须推动对有状态Kubernetes控制器的选择。像PostgreSQL这样的事务性数据库应用是更灵活的StatefulSet控制器的理想选择，而预定的后台进程通常更适合DaemonSets。
Kubernetes中的状态管理指南
如果你想把所有的有状态的势头带入有状态的应用程序的部署中，你可以使用这个分步指南，演示在Kubernetes中管理状态的几种不同方式。
CockroachDB的架构反映了Kubernetes的架构，这使得CockroachDB非常适合上面提到的第三条路径 "Natrive control, minimum effort: running your database in Kubernetes"。
