elasticsearch - Kubernetes 集群与虚拟机上的 Elasticsearch 集群

Question

我想设置弹性堆栈( Elasticsearch 、logstash、beats 和 kibana)来监控我在本地裸机上运行的 kubernetes 集群。我需要关于以下两种方法的一些建议，比如哪一种更健壮、容错和生产级。假设我有一个名为 K8-abc 的 K8 集群。

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

在这种方法中，所有来自运行在 kube-system 命名空间和用户定义命名空间中的 pod 的日志都将由 beats(在 K8-abc 上运行)获取，并通过 Logstash(也在虚拟机上运行)。而为了获取 kubernetes 节点日志，在各个 VM(参与形成 K8-abc)上运行的节拍将获取日志并将其放入在 VM 上配置的 ES 集群中。这里需要注意的是，用于形成 ES Cluster 的 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 相比，它具有许多优点。仅举几例:

self-healing cluster ,

service discovery 并集成load balancing ,

与虚拟机

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

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

以上所有要点都可以轻松应用于任何其他工作负载，并且可以视为 Kubernetes 总体优势，让我们看看为什么要使用它来实现 弹性堆栈 :

看起来像 弹力正在积极推广使用 Kubernetes 在他们的website .另见 this文章。

他们还提供官方 elasticsearch helm chart 所以 已经很好地支持它了弹力 .

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