elasticsearch - Kubernetes集群与VM上的 Elasticsearch 集群

我想设置 flex 堆栈( flex 搜索，logstash，beats和kibana)以监视运行在本地裸机上的kubernetes集群。我需要针对以下两种方法提出一些建议，例如哪种方法更可靠，容错且具有生产等级。假设我有一个名为K8-abc的K8集群。

方法1-在kubernetes集群外部设置 flex 堆栈会好吗？

在这种方法中，来自在kube-system命名空间和用户定义的命名空间中运行的pod的所有日志将被beats(在K8-abc上运行)获取，并放入通过Logstash在Linux Bare Metals上配置的ES群集中​​(也正在VM上运行)。为了获取kubernetes节点日志，在各个VM(参与形成K8-abc)上运行的心跳将获取日志并将其放入在VM上配置的ES群集中​​。这里要注意的是，用于形成ES群集的VM不是K8-abc的一部分。

方法2-在Kubernetes集群k8-abc本身上设置 flex 堆栈会好吗？

在这种方法中，所有来自在kube-system命名空间和用户定义的命名空间中运行的pod的日志都将通过logstash和beats(均在K8-abc上运行)发送到在K8-abc上配置的Elastic搜索集群。为了获取K8-abc节点日志，在VM(参与形成K8-abc的虚拟机)上运行的心跳会将日志通过在k8-abc上运行的logstash放入在K8-abc上运行的ES中。

有人可以帮助我评估上述两种方法的优缺点吗？即使提供了指向博客和案例研究的相关链接，也会很有帮助。

最佳答案

我会更倾向于第二种解决方案。与第一个相比，它具有许多优点，但是在初始设置方面似乎更为复杂。实际上，当要将任何其他类型的工作负载迁移到 Kubernetes 时，您实际上可以提出类似的问题。与VM相比，它具有许多优势。仅举几例:

self-healing cluster ，

service discovery 和集成load balancing，

与虚拟机

相比，这种解决方案更易于扩展(HPA)

存储业务流程。 Kubernetes 允许您自动挂载您选择的存储系统，例如本地存储，公共(public)云提供商和many more，其中包括 Dynamic Volume Provisioning 机制。

以上所有这些点都可以轻松地应用于任何其他工作负载，并且通常被视为 Kubernetes 的优点，因此，让我们看看为什么将其用于实现 Elastic Stack :

看起来 flex 正在积极促进在其website上使用 Kubernetes 。另请参见this文章。

他们还提供了官方的 elasticsearch helm chart ，因此 Elastic 已经很好地支持了它。

可能还有许多其他原因支持 Kubernetes 解决方案，我在这里没有提到。 Here您可以找到有关在Kubernetes上设置高度可用和可扩展Elasticsearch的动手文章。