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的動手文章 。