问将DB放入容器编排工具中是否明智

EN

我的一些集群来自kubernetes1.2-alpha，当时很明显，真正的statefull服务(在我的例子中，MySQL Galera集群是主要的)需要保留在kube集群之外。这对我来说并没有太大的改变，即使安装了1.8，我的数据库仍然是外部的。但它也很大，而且是分开的(每个主机上只有mysql是有意义的)，我也不会使用k8s特性来升级它或限制资源。

在我看来，这仍然是一个完全可行的选择，特别是对于大型数据存储来说，隔离/保留全部节点容量是有意义的。

另一方面，如果你有一个wordpress博客要部署，那么将它的db作为其helm图表的一部分是完全合理的。即使在上面的情况下，虽然prod有单独的DB，但阶段和开发环境具有--set devdb.enabled=true功能，可以在kube集群内搭建数据库，而不是连接到外部数据库。我的另一个例子是prometheus，我将其完全部署在kubernetes上。尽管在这两种情况下，我都不需要纠结于集群。

底线是，最适合您的情况就是最适合您的解决方案:)

就我个人而言，我更喜欢在Kubernetes (k8s)或任何其他容器编排框架(从这里开始将其称为COF )之外保留尽可能多的重要状态，我询问的大多数人都有相同的感受。最后，COFs是动态管理你的容器的软件(如果你必须保持状态的话还有它们的专用驱动器)。虽然这对于无状态组件来说非常酷，但当涉及到重要状态时，我对此并不感到轻松。COFs的动态性是通过额外的复杂性实现的，我不想要管理重要状态的额外复杂性，因为更多的复杂性也意味着更多的bug表面。与Ansible或SaltStack等配置管理工具不同的是，这些工具在您决定的时间以受控的方式运行，而COF算法始终独立运行，并且可以做出可能影响数据库容器和驱动器的决策。这意味着，COF配置或COF算法本身中的错误可能会在您没有准备好的任何时候产生严重的后果。我的关键数据层中是否需要这种动态特性？具有受控配置管理的独立机器在这里感觉更可靠和更简单。

关于k8s，另一个要点是当你运行自管理集群时。手动升级生产集群是一种相当不错的体验，如果您不能在最坏的情况下销毁您的整个状态，它会感觉更安全。

最后，这里也存在着哲学上的冲突。我认为，理想情况下，容器应该是完全无状态和可处理的，这与数据库的目的完全相反。当然，我们并不生活在一个理想的世界里，迟早你会达到这样的地步，你必须在你的容器中保持一定数量的状态才能使它工作。我们可以挂载持久卷，我认为对于非关键数据，这是一个很好的折衷方案。但是，关键数据是否应该由主要为无状态概念设计的东西来管理，即使它现在也提供了管理状态的方法？这里有不同的意见，但我会说不。

话虽如此，在我们目前的项目中，我们仍然在生产中的k8s中运行ES集群，从未遇到过严重的问题或数据丢失。我们将ES集群用于日志/度量数据和其他非关键数据，这些数据可以在完全失败的情况下轻松地重新导入。由于ES提供了简单的复制和扩展，如果您保持较高的复制因子，那么在k8s中将其用于非关键数据并不是完全错误的。另一方面，在生产环境中，我不会在k8s中使用严格的主从数据库。我们在k8s测试集群中使用Postgres容器来节省成本，但在生产中，我们在k8s之外使用托管DB。此外，我们在k8s中运行Redis主实例，但我们仅将它们用于缓存目的-因此这里也没有包含关键状态。