Kubernetes集群与VM上的弹性搜索集群

Question

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

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

在这种方法中，来自在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本身上设置弹性堆栈会好吗？

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

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

Answer 1

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

1. 自愈集群
2. 服务发现和集成负载平衡 ，
3. 与虚拟机相比，这种解决方案更容易扩展（ HPA ），
4. 存储编排。 Kubernetes允许您自动挂载您选择的存储系统，例如本地存储，公共云提供程序，以及包括动态卷配置机制在内的更多存储系统。

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

5. 看起来Elastic正在积极地在他们的网站上推广Kubernetes的使用。 又见此文章。
6. 他们还提供了一个官方的Elasticsearch掌舵表，因此Elastic已经很好地支持了它。

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