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

Question

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

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

在这种方法中，所有来自运行在 kube-system 命名空间和用户定义命名空间中的 pod 的日志都将通过 beats（在 K8-abc 上运行）获取并放入配置在 Linux Bare Metals 上的 ES 集群中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 相比，它具有许多优点。仅举几例：

1. self-healing cluster,
2. service discovery和集成load balancing，
3. 与 VM 相比，这种解决方案更容易扩展 (HPA)，
4. 存储编排。 Kubernetes 允许您自动挂载您选择的存储系统，例如本地存储、公共云提供商和 many more，包括 Dynamic Volume Provisioning 机制。

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

5. 看起来 Elastic 正在他们的 website 上积极推广 Kubernetes 的使用。另见this 文章。
6. 他们还提供了一个官方的elasticsearch helm chart，所以它已经得到了Elastic的很好的支持。

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