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

Question

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

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

在这种方法中，运行在kube-system命名空间和用户定义的命名空间中的pod的所有日志都将由beats（在K8-abc上运行）获取，并放入通过Linux Bare Metals配置的ES群集中Logstash（也在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. self-healing cluster ，
2. service discovery 并集成load balancing，
3. 与虚拟机相比，这种解决方案更易于扩展（HPA），
4. 存储流程。 Kubernetes 允许您自动挂载您选择的存储系统，例如本地存储，公共云提供商和many more，包括 Dynamic Volume Provisioning 机制。

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

1. 弹性似乎正在积极促进在其website上使用 Kubernetes 。另请参见this文章。
2. 他们还提供了官方的 elasticsearch helm chart ，因此 Elastic 已经为它提供了很好的支持。

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