Kubernetes 多集群监控架构

网友投稿 927 2022-10-29

本站部分文章、图片属于网络上可搜索到的公开信息,均用于学习和交流用途,不能代表睿象云的观点、立场或意见。我们接受网民的监督,如发现任何违法内容或侵犯了您的权益,请第一时间联系小编邮箱jiasou666@gmail.com 处理。

Kubernetes 多集群监控架构

本文介绍了监控多个 Kubernetes 多集群的监控架构。它不涉及如何实现和相关代码。

带有 Grafana 的 Prometheus 是一种流行的 Kubernetes 集群监控设置。虽然这很有效,并且有时对于单个集群来说是开箱即用的,但是当您的集群越来越大时会发生什么?

我们想要达到的目标如下:

查看所有集群的指标的集中位置集中存储来自所有集群的所有指标集中式警报管理器实例为我们添加的任何新集群提供一致且可扩展的设置

简单来说,Thanos是一个从多个 Prometheus 实例聚合指标的工具。

这是当前架构的图,我将介绍组件和每个组件的职责

每个 Prometheus 实例都将配置外部标签来标识实例(例如:集群名称)。external-labels是

在与外部系统通信时将添加到任何时间序列或警报中的标签

external_labels: cluster: cluster-a another_label: somevalue

Sidecar 是在 Prometheus 实例旁边运行的容器。它将从 Prometheus 实例中读取指标。它还将这些指标备份到存储后端。可以从图中看到从Sidecar到存储的指向箭头。

以下是Thanos支持的存储客户端

https://thanos.io/tip/thanos/storage.md/

S3GCSAzureOpenStack SwiftTencent COSAliYun OSSBaidu BOSFilesystem

Query 组件是无状态的并且可以水平扩展,并且可以使用任意数量的副本进行部署。连接到Sidecars 后,它会自动检测需要联系哪些 Prometheus 服务器以获取给定的 PromQL 查询。Query 还实现了 Prometheus 的官方 HTTP API,因此可以与 Grafana 等外部工具一起使用。它还提供 Prometheus 的 UI 的衍生版本,用于临时查询和存储状态。

现在,如果您在架构图中注意到,每个集群都有一个指向本地 Thanos sidecar 的 Thanos 查询组件。

最终,可观察性集群中的 Thanos 查询实例将指向其他集群的 Thanos 查询实例。

https://github.com/bitnami/charts/tree/master/bitnami/thanos

使用Thanos helm 图表,我们的可观察性集群中的 Thanos 如下所示。

query: stores: - cluster-a.thanos-query.domain.internal:10901 - cluster-b.thanos-query.domain.internal:10901 - thanos-sidecar.monitoring:10901 # <- local thanos sidecar

可观察性查询实例将在 Grafana 中用作 Prometheus 源。然后我们将能够看到来自所有集群的指标。

随着 sidecar 将数据备份到您选择的对象存储中,您可以减少 Prometheus 保留并减少本地存储。但是,我们需要一种方法来再次查询所有这些历史数据。存储网关通过实现与边车相同的 gRPC 数据 API 来实现这一点,但使用它可以在您的对象存储桶中找到的数据来支持它。就像 sidecars 和 query 节点一样,store gateway 暴露了 StoreAPI,需要被 Thanos Querier 发现

我们可以将 Storegateway 添加到我们的集中式 Thanos 查询实例

query: stores: - ... # <- the above configuration - thanos-storegateway.monitoring:10901

本地 Prometheus 安装会定期压缩旧数据以提高查询效率。由于 sidecar 会尽快备份数据,因此我们需要一种方法将相同的过程应用于对象存储中的数据。压缩器组件简单地扫描对象存储并在需要时处理压缩。同时它负责创建数据的采样副本以加快查询速度。

根据我们的架构图,我们将使用集中式警报管理器并利用 Thanos Ruler组件。

它在给定的 Thanos Querier 端点之上进行规则和警报评估。

根据我们的架构图,我们将在每个集群中设置一个Thanos Ruler。这意味着 Ruler只会评估来自同一集群中查询实例的指标。

使用Thanos helm 图表,这是我们的 Ruler实例配置的代码。

ruler: enabled: true alertmanagers: - http://alertmanager.domain.internal extraFlags - --label=cluster="cluster-a"

这--label是要添加到警报/指标以识别标尺实例的标签。这类似于普罗米修斯external-labels。稍后我们将cluster在警报管理器配置中使用该标签。

每个 Kubernetes 集群都将进行相同的设置(当然,标签中的集群名称值不同)。

现在我们已经设置好了,我们需要配置我们的警报管理器如何路由警报由于这由您来配置,因此我将仅链接到Prometheus 团队在 GitHub 上的示例。

https://github.com/prometheus/alertmanager/blob/main/doc/examples/simple.yml

我在生产中使用Thanos已经一年多了,它满足了我想要实现的所有要点/目标。Thanos 还支持多租户,有兴趣的也可以参考下文的案例。

https://thanos.io/tip/operating/multi-tenancy.md/

参考链接:https://medium.com/@ibraheemalsaady/kubernetes-multi-cluster-monitoring-architecture-50f0315371a1

上一篇:硬件运维技能攻略
下一篇:针对以上网络运维工程师的职责,作为一个合格的网络运维工程师应该具备和掌握以下维护技能或知识
相关文章

 发表评论

暂时没有评论,来抢沙发吧~