随着 HiredScore 的产品和客户群越来越大，已经开始向 Kubernetes 过渡并迅速采用它，它是我们重要的障碍之一，也可能是最大的监控基础设施。我们在使用 Prometheus / Grafana 堆栈进行监控方面有一些经验，了解到希望创建一个更好、高可用性和弹性的基础架构 ，具有可行且具有成本效益的数据保留，此外，它还允许 HiredScore 的高速增长做好准备。 CNCF 推广了多种基础设施，可以解决这些监控痛点，并实现具有高可用性、数据保留和成本效益的监控。 要求：
单点可观察性将聚合来自任何区域的所有集群的所有数据；
最终选择 Bitnami 的 Kube-Prometheus 解决方案和 Thanos -io 的 Kube-Thanos 解决方案，该解决方案效果很好，并成功满足了所有需求。现在来认识一下 players：
Prometheus — 是用于事件监控和警报的免费软件应用程序，它在使用 HTTP 拉取模型构建的时间序列数据库中记录实时指标，具有灵活的查询和实时警报；
Thanos — 一个基于 Prometheus 组件的开源 CNCF 沙盒项目，用于创建全球规模的高可用性监控系统，它通过几个简单的步骤无缝地扩展了 Prometheus。 正如下图所示，每个 EKS 集群在同一个名称空间中拥有两个 Prometheus pods，它们通过抓取集群行为来监视它们。每个 Prometheus pods 在专用 PVC 中保存最后几个小时，在规定的保留时间后，数据通过 Thanos sidecar 发送到 S3 桶。通过这种方式，可以在少量本地存储上节省成本，并将其他所有存储都集中在一个地方（S3）：
为了显示来自 k8s 集群的 Grafana 数据，创建一个专用集群，负责使用连接到 thanos-sidecar 容器的 GRPC 直接从每个集群收集所有实时（最近约 2 小时）数据（暴露默认情况下在端口 10901 上）并从 S3 存储桶（配置存储）中获取远程数据。 实现细节：
第二阶段是在“聚合”集群中实现 kube-thanos，它将负责从集群中收集所有集群的实时数据，并从发送到 S3 存储桶（ObjectStore）的保留数据中收集数据。 在这里，关注如何在我们要监控的每个集群中部署和配置 Prometheus 以及 Thanos sidecar，在每个集群中创建一个名为 monitoring 的命名空间： kubectl create ns monitoring
创建一个存储类以使 Prometheus 能够持久化日期： apiVersion: storage. k8s. io/ v1
kind: StorageClass
metadata:
name: prometheus - storage- class
provisioner: kubernetes. io/ aws- ebs
parameters:
type : gp3
reclaimPolicy: Retain
allowVolumeExpansion: true
volumeBindingMode: Immediate
kubectl apply - f prometheus - storage- class. yaml - n monitoring
helm repo add bitnami https: / / charts. bitnami. com/ bitnami
helm repo update
将要配置的相关值复制到本地文件夹中，需要在值中应用的一些更改。 第 1 步：
使 Prometheus 高可用：设置 Prometheus Replica Count— 所需的 Prometheus 副本数（超过 2 个）： ## @ param prometheus . replicaCount Number of Prometheus replicas desired
##
replicaCount: 2
第 2 步：定义 pod 资源限制 Prometheus 资源-定义它以避免 Prometheus 消耗所有服务资源： resources:
requests:
cpu: 512m
memory: 3072Mi
limits:
cpu: 512m
memory: 4096Mi
thanos:
## @ param prometheus . thanos. create Create a Thanos : true
第 4 步：
将 Thanos sidecar 服务类型从更改 ClusterIP 为 LoadBalancer- 它将创建一个 AWS 经典负载均衡器端点，该端点将在 GRPC 端口 10901 中公开 sidecar，然后可以使用此端点通过 route53 将其路由到某个 DNS 名称 thanos-prometheus -（cluster_name）。在自己的集群中公开 Thanos 端点 prometheus .thanos.service： service:
type : LoadBalancer
port: 10901
annotations:
service. beta. kubernetes. io/ aws- load- balancer- internal: "true"
现在，在创建 CLB 之后，需要在 kube-thanos 清单中实现它。 第 5 步：
禁用压缩并定义保留，这是通过 Thanos sidecar 上传数据的一个非常重要的步骤，为了使用 Thanos 边车上传，这两个值必须相等 --storage.tsdb.min-block-duration，–storage.tsdb.max-block-duration 默认情况下，它们设置为 2 小时，Prometheus 的保留时间建议不低于 min block duration 的 3 倍，即 6 小时： retention: 12h
disableCompaction: true
第 6 步：
启用配置密钥，通过启用对象存储配置，可以将数据写入 S3 或任何其他受支持的 BlockDevice，以确保长期数据的持久性： ## @ param prometheus . thanos. objectStorageConfig Support mounting a Secret for the objectStorageConfig of the sideCar container.
objectStorageConfig:
secretName: thanos- objstore- config
secretKey: thanos. yaml
虽然源文件 thanos-storage-config.yaml 必须采用这种形式： type : s3
config:
bucket: thanos- store #S3 bucket name
endpoint: s3. < region> . amazonaws. com #S3 Regional endpoint
access_key: < aws- account- id>
secret_key: < aws- account- secret>
值得一提的是，目前只能使用单个 S3 存储桶（ObjectStore） 使用以下命令创建密钥： kubectl - n monitoring create secret generic thanos- objstore- config - - from- file= thanos. yaml= thanos- storage- config. yaml
第 7 步：
现在可以使用相关自定义来安装/升级 helm chart： helm install kube- prometheus - f values. yaml bitnami/ kube- prometheus - n monitoring
helm upgrade kube- prometheus - f values. yaml bitnami/ kube- prometheus - n monitoring
现在应该已经运行带有 Thanos sidecar 容器的 Prometheus pod，一方面通过 GRPC 将抓取的数据发送到清单，另一方面，相同的 sidecar 发送（大约 2 小时后）数据到 S3 存储桶（配置存储）。 我们专注于如何在主要的可观察性集群上部署和配置 Thanos ，如前所述，它将负责在第一阶段部署的所有集群中收集所有数据。为此，使用 kube-thanos manifests，可以发现，只需要实现查询和存储部分。 第 1 步：
安装和自定义 kube-thanos：在主可观察性集群中，创建一个名为 thanos 的命名空间： kubectl create ns thanos
可以选择克隆 kube-thanos 存储库并使用清单文件夹或自己编译 kube-thanos 清单，最后一个不需要复制整个存储库，只需要清单文件。 第 2 步：
在通过第一阶段后，将负责 thanos-query-deployment.yaml 从第一阶段开始与其他集群之间的通信。为此，需要添加以下内容： - - - store= dnssrv+ _grpc. _tcp. thanos- prometheus - < cluster_name> . < domain_name> : 10901
进入 args，在上面公开和定义的 Thanos sidecar GRPC 端点部分： - args:
- query
- - - grpc- address= 0.0 . 0.0 : 10901
- - - http- address= 0.0 . 0.0 : 9090
- - - log. level= info
- - - log. format= logfmt
- - - query. replica- label= prometheus _replica
- - - query. replica- label= rule_replica
- - - store= dnssrv+ _grpc. _tcp. thanos- store. thanos. svc. cluster. local: 10901
- - - store= dnssrv+ _grpc. _tcp. thanos- receive- ingestor- default. thanos. svc. cluster. local: 10901
- - - store= dnssrv+ _grpc. _tcp. thanos- prometheus - < cluster_name> . < domain_name> : 10901
- - - query. auto- downsampling
第 3 步：
现在处理 thanos-store 与配置要从第一阶段发送到的数据的 S3 存储桶（ObjectStore）之间的通信。因此，正如在第一步中所做的那样，我们需要配置一个名称，该名称在注入环境 thanos-store-statefulSet.yaml 的一部分中请求到 Thanos 存储 pod： env:
- name: OBJSTORE_CONFIG
valueFrom:
secretKeyRef:
key: thanos. yaml
name: thanos- objectstorage
然后可以重用第一阶段的相同源文件并为 thanos-storethanos-storage-config.yaml 创建一个秘密： kubectl - n thanos create secret generic thanos- objectstorage - - from- file= thanos. yaml= thanos- storage- config. yaml
kubectl apply - f manifests - n thanos
现在，应该关闭循环，Thanos 通过 thanos-query 部署从其他集群接收实时数据，并通过 thanos-store-statefulSet 保留来自 S3 存储桶（ObjectStore）的数据：
Thanos 让我们改变了对 Prometheus 高度可用、耐用和经济高效的看法，在许多 Kubernetes 集群上实施 Thanos 和 Prometheus 需要付出很多努力，但如果关心确保高可用的 Prometheus，这是值得的。
