Prometheus和Thanos的前生今世

没有人会为你的贫穷负责，却有人为你的富有而喝彩！所以不要活在别人的嘴巴里，做好自己！有路，就大胆的去走；有梦，就大胆地飞翔；前行的路，不怕万人阻挡，只怕自己投降！

总结thanos之前先来回顾一下prometheus

prometheus 回顾

云原生监控的事实标准Promethues

监控系统的历史悠久，是一个颇为成熟的领域，而Prometheus作为新生代的开源监控系统，慢慢成为了云原生体系的监控事实标准，也证明了其设计得到业界认可。Prometheus启发于Google公司的borgmon监控系统，由google前员工在2012年作为社区开源项目创建和开发，并于2015年正式发布。2016年，Prometheus正式加入Cloud Native Computing Foundation，成为仅次于Kubernetes的第二把交椅的项目。

架构

组件概述

• Prometheus server

  核心组件，负责从外部主动抓取指标到内存时序数据库，并定时将内存中的指标同步到磁盘。

• Alertmanager

  转发来自Prometheus server发送的告警信息至外部的告警接收者。

• Pushgateway

  被监控对象可主动推送指标至Pushgateway，Pushgateway的指标是被Prometheus server抓取。

• Promethues web UI

  Prometheus server的界面，输入表达式可查询相关的指标数据。

工作流程

Prometheus的工作流程核心是，以主动拉取pull的方式搜集被监控对象的metrics数据（监控指标数据），并将这些metrics数据存储到一个内存TSDB（时间序列数据库）中，并定期将内存中的指标同步到本地硬盘。有了这个核心工作流程，其余组件只是为了配合这个工作流程。被监控对象也可向Pushgateway组件推送指标，Prometheus最终也会从Pushgateway组件拉取指标到TSDB。Altermanager组件像是一个路由器，将Prometheus的告警进行转发至外部的接收者。

优点

Prometheus具有以下引人注意的优点：

• 强大的多维度数据模型
• 灵活而强大的查询语句（PromQL）：在同一个查询语句，可以对多个metrics进行乘法、加法、连接、取分数位等操作。
• 易于管理：Prometheus server是一个单独的二进制文件，可直接在本地工作，不依赖于分布式存储。
• 高效：平均每个采样点仅占3 bytes，且一个Prometheus server可以处理数百万的 metrics。
• 使用pull模式采集时间序列数据，这样不仅有利于本机测试而且可以避免有问题的服务器推送坏的metrics。
• 可以采用push gateway的方式把时间序列数据推送至Prometheus server端。
• 可以通过服务发现或者静态配置去获取监控目标。
• 有多种可视化图形界面。
• 非常多的应用都实现了Prometheus的metrics接口以暴露自身各项数据指标让 Prometheus去采集，很多没有适配的应用也会有第三方 exporter 帮它去适配 Prometheus。

局限性

无集群部署

Prometheus 本身只支持单机部署，没有自带支持集群部署，对于集群化和水平扩展，官方和社区都没有银弹，需要合理选择Federate、Cortex、Thanos等开源方案或自研方案。

存储容量

它的存储空间也受限于单机磁盘容量，磁盘容量决定了单个Prometheus所能存储的数据量，数据量大小又取决于被采集服务的指标数量、服务数量、采集速率以及数据过期时间。在数据量大的情况下，我们可能就需要做很多取舍，比如丢弃不重要的指标、降低采集速率、设置较短的数据过期时间。

非精确监控系统

在设计上的权衡：放弃了一部分数据准确性，但放弃一点准确性得到的是更高的可靠性，监控系统一般情况下可用性大于一致性，容忍部分副本数据丢失，保证查询请求成功。Prometheus不一定保证数据准确，这里的非精确来自两个方面：
1）rate、histogram_quantile等数学函数。
2）来查询范围过长要做降采样，势必会造成数据精度丢失。

资源消耗

在一个节点数量为6的kuberntes集群（指标主要来自kubelet服务、node-exporter服务、kube-apiserver、kube-controller等核心服务），单个Prometheus实例消耗0.1-0.4个cpu，2.5G-3G内存。

Prometheus高可用方案

业界Prometheus高可用方案概述

• 基本HA：即两套 Prometheus 采集完全一样的数据，外边挂负载均衡；
• HA + 远程存储：除了基础的多副本 Prometheus，还通过 Remote Write 写入到远程存储，解决存储持久化问题；
• 联邦集群：即Federation，按照功能进行分区，不同的 Shard 采集不同的数据，由 Global 节点来统一存放，解决监控数据规模的问题。

使用 Thanos或者Victoriametrics，来解决全局查询、多副本数据 Join 问题。

就算使用官方建议的多副本+联邦，仍然会遇到一些问题，比如官方建议数据做Shard，然后通过Federation来实现高可用，但是边缘节点和Global节点依然是单点，需要自行决定是否每一层都要使用双节点重复采集进行保活。本质原因是，Prometheus的本地存储没有数据同步能力，要在保证可用性的前提下，再保持数据一致性是比较困难的，基础的HA Proxy满足不了以下要求，比如：集群的后端有A和B两个实例，A和B之间没有数据同步。A 宕机一段时间，丢失了一部分指标数据，如果负载均衡正常轮询，请求打到 A 上时，数据就会异常。

增强高可用的Prometheus数据一致性的思路

解决方案是可以从存储、查询两个角度上保证数据的一致。

存储角度

如果使用 Remote Write 远程存储， A和B后面可以都加一个Adapter，Adapter做选主逻辑，只有一份数据能推送到 TSDB，这样可以保证一个异常，另一个也能推送成功，数据不丢，同时远程存储只有一份，是共享数据。

查询角度

存储角度的解决方案实现很复杂且有一定风险，因此现在的大多数方案在查询层面做文章，比如Thanos或者Victoriametrics，仍然是两份数据，但是查询时做数据去重和Join。只是Thanos是通过Sidecar把数据放在对象存储，Victoriametrics是把数据Remote Write 到自己的Server实例，但查询层Thanos-Query和Victor的Promxy的逻辑基本一致。

扩展Prometheus的解决方案

cortext

概述

Cortex（https://cortexmetrics.io）为Prometheus提供了水平可扩展，高可用性，多租户的长期存储。目前在cncf 沙箱孵化。

Cortex为Prometheus提供了水平可扩展，高可用性，多租户的长期存储。Cortex是一个CNCF沙箱项目，用于多个生产系统，包括Weave Cloud和Grafana Cloud。Corte主要用作Prometheus的远程写入的存储，它提供与Prometheus兼容的查询API。

特点

• 水平可扩展：Cortex可以跨集群中的多台机器运行，超过了单台机器的吞吐量和存储量。这使您能够将指标从多个Prometheus服务器发送到单个Cortex群集，并在单个位置跨所有数据运行“全局聚合”查询；
• 高度可用：在集群中运行时，Cortex可以在机器之间复制数据。这样，您就可以在机器故障中幸存下来，而不会在图表中留下空白。
• 多租户：Cortex可以将数据和查询与单个群集中的多个不同独立Prometheus源隔离，从而使不受信任的各方共享同一群集；
• 长期存储：Cortex支持Amazon DynamoDB，Google Bigtable，Cassandra，S3和GCS来长期存储度量标准数据。这样一来，您可以持久地存储数据，其时间长于任何一台计算机的生命周期，并将此数据用于长期容量规划。

VictoriaMetrics

概述

VictoriaMetrics是一种快速，经济高效且可扩展的时间序列数据库。

它在二进制发行版，Docker映像和源代码中可用。

VictoriaMetrics也提供付费企业支持。

Thanos

概述

诞生于2018年9月，Thanos是一系列组件，基于Prometheus之上的可以组成具有无限存储容量的高可用性指标系统。Thanos是CNCF沙箱项目。Thanos利用Prometheus 2.0存储格式在任何对象存储中经济高效地存储历史指标数据，同时保留快速查询延迟。另外，它提供了所有Prometheus安装的全局查询视图，并且可以即时合并Prometheus HA对中的数据。

架构

特点

• 提供全局查询视图；
• 支持主流对象存储，以提供可靠的历史数据存储；
• 支持降准采样，以提供更大时间范围的指标。

查询

面对大量的存储数据，Thanos有两种横向扩展方式，一种是基于时间的分区(TIME-BASED)，一种是基于标签的分区(LABEL-BASED)。

基于时间的分区(TIME-BASED)

默认情况下，Thanos的存储网关(Store Gateway)查看对象存储(OSS)中的所有数据，并根据查询的时间范围返回这些数据。所有StoreAPI源都会公布可用的最短和最长时间。我们可以使用这些参数来缩小这个分区的范围，此参数可以是相对时间，也可以是具体日期。如

• A: max-time=-6w
• B: min-time=-8w and max-time=-2w
• C: min-time=-3w

基于标签的分区(LABEL-BASED)

基于标签的分区类似于基于时间的分区，所有StoreAPI源都会公布可用的LABEL序列的相关标签，，这些标签来自Prometheus的external标签，并基于Thanos组件显式设置标签。

重复数据消除(DEDUPLICATION)

在Thanos架构中我们可以使用多个相同的Prometheus实例来实现高可用(HA)，以防止Prometheus单点故障。Thanos提供了查询结果的重复数据消除功能，从而可以实现Prometheus查询无缝对接。为了实现这一点，我们只需要在sidecar组件上设置一个或多个副本标签，其余的由query组件完成。如：

Prometheus + sidecar “A”: cluster=1,env=2,replica=A
Prometheus + sidecar “B”: cluster=1,env=2,replica=B
Prometheus + sidecar “A” in different cluster: cluster=2,env=2,replica=A

查询示例: up{job="prometheus",env="2"}. 重复数据消除功能开户后:

up{job="prometheus",env="2",cluster="1"} 1
up{job="prometheus",env="2",cluster="2"} 1

没有开启重复数据消除功能:

up{job="prometheus",env="2",cluster="1",replica="A"} 1
up{job="prometheus",env="2",cluster="1",replica="B"} 1
up{job="prometheus",env="2",cluster="2",replica="A"} 1

降采样

在Thanos中进行降采样(DOWNSAMPLING)的目的不是为了节省磁盘空间。它的主要好处是使长周期范围的数据查询（如数月或数年）变得更快。事实上降采样并不会节省任何空间，它为每个原始块添加多了两个新块，它们略小于或接近原始块的大小。这意味着，降采样稍微增加了存储空间使用量，但在查询长周期范围时，它提供了巨大的性能和带宽占用优势。

三个粒度的块(chunks)：

• raw — Prometheus的原始metrics块；
• 5m — 原始metrics块的5分钟压缩块
• 1h —原始metrics块的1小时压缩块

使用压缩块查询的优势对比：

在没有降采样块的情况下查询长周期范围意味着必须下载和处理与范围长度成比例的数据量。在1y示例中，我们将看到，降采样后就不需要下载20亿个样本（2GB，Prometheus默认15秒一个采样数据），而只需要获取和处理800万个样本（9MB），就足以呈现一个年度图表，这将带来很大的性能改进，并减少了很多带宽使用。

核心组件

Thanos sidecar

Sidecar作为一个单独的进程和已有的Prometheus实例运行在一个server上，互不影响。Sidecar可以视为一个Proxy组件，所有对Prometheus的访问都通过Sidecar来代理进行。通过Sidecar还可以将采集到的数据直接备份到云端对象存储服务器。

同时可支持多种对象存储(OSS)，如Aliyun、腾讯云、S3、Google云存储、Azure存储等，可无缝集成在Prometheus operator中进行部署。

Thanos store gateway

Store gateway实现了一套和Sidecar完全一致的API提供给Querier用于查询Sidecar备份到云端对象存储的数据。因为Sidecar在完成数据备份后，Prometheus会清理掉本地数据保证本地空间可用。所以当监控人员需要调取历史数据时只能去对象存储空间获取，而Store就提供了这样一个接口。Store Gateway内部还做了一些加速数据获取的优化逻辑，一是缓存了 TSDB 索引，二是优化了对象存储的远程调用请求 (用尽可能少的请求量拿到所有需要的数据)。

• Store

  • 从对象存储(OSS)中检索块(chunks)，以便查询长周期的监控指标
  • 支持基于时间(time-based)的分区查询
  • 支持基于标签(label-based)的分区查询

• Bucket

  • 监视对象存储Bucket中存储的监控数据

Thanos query

Querier从Sidecar和Store gateway获取指标数据，同时Querier实现了一套Prometheus官方的HTTP API从而保证对外提供与Prometheus一致的数据源接口，Grafana可以通过同一个查询接口请求不同集群的数据，Querier负责找到对应的集群并通过Sidecar获取数据，也能从Store gateway获取指标数据。Querier本身也是无状态的、可水平可扩展的，因而可以实现高可部署。Querier可以实现对高可部署的Prometheus的数据进行合并从而保证多次查询结果的一致性，从而解决全局视图和Prometheus高可用的问题。

Thanos Query查询位于下游的Thanos Sidecar的指标数据，而Thanos Sidecar的指标数据来自与其绑定的Prometheus实例。

Thanos ruler

对监控数据进行评估和告警，还可以计算出新的监控数据，将这些新指标数据提供给 Thanos Query 查询，上传指标数据到对象存储，以供长期存储。

Thanos compactor

通常在查看较大时间范围的监控数据时，很多时候并不需要那么详细的数据，更多时候是为了得到数据趋势。compactor读取对象存储的数据，对其进行压缩以及降采样后再上传到对象存储，在查询大时间范围数据时就只读取压缩和降采样后的数据，极大地减少了查询的数据量，从而加速查询。

注意：Compact 组件并不会减少对象存储的使用空间，而是会增加，因为增加更长采样间隔的指标数据。如此一来，当查询大时间范围的数据时，就自动拉取更长时间间隔采样的数据以减少查询数据的总量，从而加快查询速度（大时间范围的数据不需要很精细的指标，需要的是趋势），当放大往细节查看时 (选择其中一小段时间)，又自动选择拉取更短采样间隔的数据，从而也能显示出小时间范围的监控细节。

Thanos 部署

##

thanos主要使用到sidecar和query，如果需要数据备份至云存储，store组件也得启动。

Thanos Sidecar

Thanos Sidecar以边车形式和Prometheus处于同一个Pod中，由于Prometheus散落在多个集群中，因此Thanos Sidecar位于多个集群中。prometheus和thanos sidecar是通过prometheus-operator来进行部署。thanos sidecar也通过nodePort方式的暴露（由于一个集群有2个thanos sidecar，因此分为设置nodePort为10901和10902）。thanos sidecar暴露的原因是作为位于其他集群的thanos query组件的后端存储。

apiVersion: monitoring.coreos.com/v1
kind: Prometheus
metadata:
  labels:
    prometheus: k8s
  name: k8s
  namespace: monitoring
spec:
  alerting:
    alertmanagers:
    - name: alertmanager-main
      namespace: monitoring
      port: web
  image: quay.mirrors.ustc.edu.cn/prometheus/prometheus:v2.15.2
  nodeSelector:
    kubernetes.io/os: linux
  podMonitorNamespaceSelector: {}
  podMonitorSelector: {}
  replicas: 2
  resources:
    requests:
      memory: 400Mi
  ruleSelector:
    matchLabels:
      prometheus: k8s
      role: alert-rules
  securityContext:
    fsGroup: 2000
    runAsNonRoot: true
    runAsUser: 1000
  serviceAccountName: prometheus-k8s
  serviceMonitorNamespaceSelector: {}
  serviceMonitorSelector: {}
  version: v2.15.2
  tolerations:
  - effect: NoSchedule
    key: node-role.kubernetes.io/master
  thanos:
    baseImage: quay.mirrors.ustc.edu.cn/thanos/thanos
    version: v0.11.0
    objectStorageConfig:
      key: objectstorage.yaml
     name: thanos-objectstorage
  externalLabels:
    cluster: test

apiVersion: v1
kind: Service
metadata:
  labels:
    app: thanos-sidecar
    statefulset.kubernetes.io/pod-name: prometheus-k8s-0
  name: thanos-sidecar-0-external
  namespace: monitoring
spec:
  externalTrafficPolicy: Cluster
  ports:
  - name: grpc
    nodePort: 10901
    port: 10901
    protocol: TCP
    targetPort: grpc
  selector:
    prometheus: k8s
    statefulset.kubernetes.io/pod-name: prometheus-k8s-0
  sessionAffinity: None
  type: NodePort
----
apiVersion: v1
kind: Service
metadata:
  labels:
    app: thanos-sidecar
    statefulset.kubernetes.io/pod-name: prometheus-k8s-1
  name: thanos-sidecar-1-external
  namespace: monitoring
spec:
  externalTrafficPolicy: Cluster
  ports:
  - name: grpc
    nodePort: 10902
    port: 10901
    protocol: TCP
    targetPort: grpc
  selector:
    prometheus: k8s
    statefulset.kubernetes.io/pod-name: prometheus-k8s-1
  sessionAffinity: None
  type: NodePort

Thanos query

Thanos Query是无状态服务，以Deployment形式、双副本部署在一个独立集群中。通过配置文件的方式指定位于其他集群中的thanos sidecar。

说明：

• 开启部分响应特性，此时在部分后端 Store API 返回错误或超时的情况下也能查询到正确的监控数据(如果后端 Store API 做了高可用，挂掉一个副本，Query访问挂掉的副本超时，但由于还存在其他可用的副本，于是客户端能获取正确的查询结果；如果挂掉的某个后端本身就不存在客户端需要的数据，挂掉也不影响查询结果的正确性)；
• 开启查询时自动降采样的特性，以提供查询效率。

Thanos store gateway

store gateway以StatefulSet形式、双副本部署在一个独立集群中。为它创建Kubernetes headless service，用于 Thanos Query组件对Store Gateway进行服务发现。

Thanos ruler

Thanos ruler以StatefulSet形式、双副本部署在一个独立集群（和thanos query同一个集群）中。为它创建Kubernetes headless service，用于 Thanos Query组件对Thanos Ruler进行集群内的服务发现。另外我制作了一个小镜像用于让ruler组件重载配置文件，在规则文件被修改的时候。

apiVersion: v1
kind: Service
metadata:
  labels:
    app.kubernetes.io/name: thanos-rule
  name: thanos-rule
  namespace: monitoring
spec:
  clusterIP: None
  ports:
  - name: grpc
    port: 10901
    targetPort: grpc
  - name: http
    port: 10902
    targetPort: http
  selector:
    app.kubernetes.io/name: thanos-rule
---

apiVersion: apps/v1
kind: StatefulSet
metadata:
  labels:
    app.kubernetes.io/name: thanos-rule
  name: thanos-rule
  namespace: monitoring
spec:
  replicas: 2
  selector:
    matchLabels:
      app.kubernetes.io/name: thanos-rule
  serviceName: thanos-rules
  podManagementPolicy: Parallel
  template:
    metadata:
      labels:
        app.kubernetes.io/name: thanos-rule
    spec:
      serviceAccount: thanos-rules
      containers:
      - name: reloader
        image: registry.cn-shenzhen.aliyuncs.com/gzlj/thanos-reloader:v0.1
        imagePullPolicy: Always
        resources:
          limits:
            cpu: 100m
            memory: 100Mi
      - args:
        - rule
        - --grpc-address=0.0.0.0:10901
        - --http-address=0.0.0.0:10902
        - --rule-file=/etc/thanos/rules/*rules.yaml
        - --objstore.config-file=/etc/thanos/objectstorage.yaml
        - --data-dir=/var/thanos/rule
        - --label=rule_replica="$(NAME)"
        - --alert.label-drop="rule_replica"
        - --query=dnssrv+_http._tcp.thanos-query.monitoring.svc.cluster.local
        - --alertmanagers.url=http://alertmanager-main.monitoring.svc.cluster.local:9093
        env:
        - name: NAME
          valueFrom:
            fieldRef:
              fieldPath: metadata.name
        image: quay.mirrors.ustc.edu.cn/thanos/thanos:v0.11.0
        livenessProbe:
          failureThreshold: 24
          httpGet:
            path: /-/healthy
            port: 10902
            scheme: HTTP
          periodSeconds: 5
        name: thanos-rule
        ports:
        - containerPort: 10901
          name: grpc
        - containerPort: 10902
          name: http
        readinessProbe:
          failureThreshold: 18
          httpGet:
            path: /-/ready
            port: 10902
            scheme: HTTP
          initialDelaySeconds: 10
          periodSeconds: 5
        terminationMessagePolicy: FallbackToLogsOnError
        volumeMounts:
        - mountPath: /var/thanos/rule
          name: data
          readOnly: false
        - name: thanos-objectstorage
          subPath: objectstorage.yaml
          mountPath: /etc/thanos/objectstorage.yaml
        - name: thanos-rules
          mountPath: /etc/thanos/rules
      volumes:
      - name: thanos-objectstorage
        secret:
          secretName: thanos-objectstorage
      - name: thanos-rules
        configMap:
          name: thanos-rules
      - name: data
        emptyDir: {}

Thanos Operator部署

Thanos operator CRDs

ObjectStore

该资源负责 bucket 管理。 Thanos 在 bucket 上压缩和采样，强烈建议您每个 bucket 只运行一个 compactor。

一般来说，超过一个部署不是并发安全的，必须针对 bucket 作为单例部署。

此外，还有一个很棒的 bucket 检查工具，称为bucket，它为存储在bucket中的块提供了一个简单的 Web 界面。

Thanos & StoreEndpoint

Thanos 是负责查询、存储和规则配置的主要自定义资源。它与代表不同 StoreAPI 端点的 StoreEndpoint 有特殊关系。这些可以是 Sidecar、Store、Rule 或任何其他 Store API 提供程序。 Thanos 资源按 StoreEndpoint 实例化。这意味着您可以为多个 Prometheus 实例或集群使用单个 Thanos 配置。

现在让我们看一些部署示例，以帮助我们更好地理解 CRD。

单集群

在这种情况下，我们将使用 Thanos 的长期存储功能。这意味着我们将安装一个带有 Thanos sidecar 和完整 Thanos 堆栈的 Prometheus 算子。让我们看一个极简主义设置的例子。

可以看到蓝色为无状态服务（stateless），橙色为有状态服务

//编辑prometheus-operator的value.ymal文件开启thanos sidecar（待补充）
 
//安装、删除prometheus-operator
helm template ./charts/prometheus-operator --name tpo --namespace monitor | kubectl apply --validate=false -f -
helm template ./charts/prometheus-operator --name tpo --namespace monitor | kubectl delete --ignore-not-found=true -f -
 
//下载Thanos Operator
helm repo add banzaicloud-stable https://kubernetes-charts.banzaicloud.com
helm fetch --untar --untardir ./charts banzaicloud-stable/thanos
 
//编辑value.ymal文件（待补充）
 
//手动安装Thanos
helm template ./charts/thanos --name t-thanos --namespace monitor | kubectl -n monitor apply --validate=false -f -
helm template ./charts/thanos --name t-thanos --namespace monitor | kubectl -n monitor delete --ignore-not-found=true -f -

objectstore

apiVersion: monitoring.banzaicloud.io/v1alpha1
kind: ObjectStore
metadata:
  name: objectstore-sample
spec:
  config:
    mountFrom:
      secretKeyRef:
        name: thanos
        key: object-store.yaml
  bucketWeb:
    label: cluster
  compactor: {}

storeendpoint

apiVersion: monitoring.banzaicloud.io/v1alpha1
kind: StoreEndpoint
metadata:
  name: storeendpoint-sample
spec:
  # Add fields here
  thanos: thanos-sample
  config:
    mountFrom:
      secretKeyRef:
        name: thanos
        key: object-store.yaml
  selector: {}

thanos

apiVersion: monitoring.banzaicloud.io/v1alpha1
kind: Thanos
metadata:
  name: thanos-sample
spec:
  query: {}
  rule: {}
  storeGateway: {}

多集群

根据上面的部署，我们只有一个集群部署，但是如果我们有多个集群并且需要一种查看它们的方法怎么办？我们可以采取几种不同的方法。现在，我们将探索最基本的。我们已经安装了多个安装了 Thanos 的集群。我们需要使用指向这些集群的端点配置 Thanos 自定义资源。

Thanos

Thanos with only query definition

apiVersion: monitoring.banzaicloud.io/v1alpha1
kind: Thanos
metadata:
  name: thanos-multi
spec:
  query: {}

StoreEndpoint

store-endpoints per cluster

apiVersion: monitoring.banzaicloud.io/v1alpha1
kind: StoreEndpoint
metadata:
  name: remote-cluster-n
spec:
  thanos: thanos-multi
  url: http://remote-cluster-n.com

观察者集群部署

此部署模型从集群中减去额外的工作负载，并将 Thanos 组件移动到专用的观察者集群。

Thanos

thanos with queryDiscovery definition

apiVersion: monitoring.banzaicloud.io/v1alpha1
kind: Thanos
metadata:
  name: query-master
spec:
  query: {}
  queryDiscovery: true

thanos definition for the remote clusters

apiVersion: monitoring.banzaicloud.io/v1alpha1
kind: Thanos
metadata:
  name: thanos-generic-n
spec:
  query: {}
  rule: {}
  storeGateway: {}

apiVersion: monitoring.banzaicloud.io/v1alpha1
kind: StoreEndpoint
metadata:
  name: remote-cluster-n
spec:
  thanos: thanos-generic-n
  url: http://remote-cluster-n.com
  config:
    mountFrom:
      secretKeyRef:
        name: thanos
        key: object-store-n.yaml

注意：此部署模型也适用于单集群多命名空间部署

参考：

扩展Prometheus的解决方案thanos

多集群监控组件Thanos

Deploy Prometheus Operator With Thanos

Introducing the Thanos Operator