我们在Docker中运行我们的prod DB，效果很好。
现在我们将进入管理型K8并将弹性搜索放入其中并且感觉不太好。在解决了卷的问题后（使用PersistentVolumeClaimTemplates），聚类很难找到我们。集群中的节点根本找不到彼此（在弹性搜索配置中使用无头服务的几个小时之后）。
所以，我猜这样做是不明智的，我们应该将数据库保留在K8s群集之外的虚拟机上，例如由Ansible管理。
您对此有何看法？
答案 0 :(得分：2)
我的一些集群早在Kubernetes 1.2-alpha时就已经出现了，当时很明显，真正有状态的服务（我的情况下是MySQL Galera集群是主要服务集群）需要保留在kube集群之外。这对我来说并没有太大改变，即使安装了1.8，我的数据库仍然是外部的。但它也很大并且是分开的（在每个主机上只有mysql是有意义的）我也不会使用k8s功能来升级它或限制资源。
在我看来，这仍然是一个非常可行的选择，特别适用于大型数据存储，它们可以隔离/保留完整节点容量。
另一方面，如果你要部署wordpress博客，那么将db作为其掌舵图的一部分是完全合理的。即使在上面的情况下，虽然prod具有单独的DB，但stage和dev envs具有--set devdb.enabled=true能力，可以在kube集群内部建立数据库，而不是连接到外部数据库。我的另一个例子是prometheus，我完全部署在kubernetes上。虽然在这两种情况下我都不必为集群而苦苦挣扎。
最重要的是，最适合您情况的是适合您的解决方案：）
答案 1 :(得分：2)
就个人而言，我更喜欢在Kubernetes（k8s）或任何其他容器编排框架（从此处将其称为COF）之外保持尽可能多的重要状态，并且我询问此主题的大多数人都有同感。 最后，COF是动态管理容器的软件（如果你必须保持状态，它们的专用驱动器......）。 虽然这对于无状态组件来说非常酷，但对于重要的状态我并不感到轻松。 COF的动态是通过额外的复杂层实现的，并且我不希望管理重要状态的额外复杂性，因为更复杂也意味着更多的bug表面。与Ansible或SaltStack等配置管理工具相比，它们在您决定的时间内以受控方式运行，COF算法始终独立运行，并且可以做出可能影响数据库容器和驱动器的决策。这意味着COF配置中或COF算法本身内的错误可能会在您可能没有做好准备的任何时候产生严重后果。我的关键数据层中是否需要这种动态？具有受控配置管理的独立机器在这里感觉更可靠和更简单。
关于k8s，另一点是运行自我管理的群集。手动升级生产集群是一种非常棒的体验，如果在最糟糕的情况下无法破坏整个状态，感觉会更安全。
最后，这里还有一场哲学冲突。我认为理想情况下，容器应该是完全无状态的和一次性的，这与数据库的目的完全相反。当然，我们并不是生活在一个理想的世界中，迟早你会达到必须在容器中保留一定量状态才能使其发挥作用的程度。我们被允许安装持久卷，我认为对于非关键数据，这是一个很好的折衷方案。但是，关键数据是否应该由主要为无状态概念设计的东西来管理，即使它现在提供了管理状态的方法呢？意见在这里有所不同，但我说不。
话虽如此，在我们目前的项目中，我们仍然在生产的k8s中运行ES集群，从未遇到过严重的问题或数据丢失。我们将ES群集用于日志/度量标准数据和其他非关键数据，以便在完全失败时轻松重新导入。 由于ES提供了简单的复制和扩展，如果您将复制因子保持在高水平，那么在k8s中将非关键数据用于非关键数据并不完全错误。 另一方面，像Postgres这样严格的主从数据库我不会在生产环境中使用k8s。 我们在k8s测试集群中使用Postgres容器来节省成本，但在生产中我们使用k8s之外的托管DB。此外，我们在k8s中运行Redis主实例，但我们仅将它们用于缓存目的 - 所以再次没有包含关键状态。