【kubernetes/k8s概念】thanos原理架构

最新推荐文章于 2025-04-19 07:55:41 发布
最新推荐文章于 2025-04-19 07:55:41 发布
阅读量2.9k 收藏 1
点赞数 1
分类专栏： kubernetes 文章标签： kubernetes
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.youkuaiyun.com/zhonglinzhang/article/details/121334054
版权
Thanos是一个用于Prometheus的组件集合，旨在提供无限的指标存储、高可用性和全局查询视图。它利用Prometheus的2.0存储格式，将历史数据存储在云对象存储中，同时保持快速查询。Thanos的架构包括Sidecar、Store Gateway、Compactor、Receiver、Ruler、Query等组件，各自承担不同的职责，如数据上传、压缩、查询聚合等，实现了一个强大的监控解决方案。

摘要生成于 C知道 ，由 DeepSeek-R1 满血版支持， 前往体验 >

概述

    Thanos 是一组组件，可以组合成具有无限存储容量的高可用度量系统，可以无缝添加到现有 Prometheus 部署之上。

    Thanos 利用 Prometheus 2.0 存储格式高效地将历史指标数据存储在任何对象存储中，同时保持快速查询延迟。 此外还提供了所有 Prometheus 安装的全局查询视图，并且可以动态合并来自 Prometheus HA 对的数据。该项目的具体目标是：

  • 指标的全局查询视图。
  • 无限保留指标。
  • 组件的高可用性，包括 Prometheus。

架构

标题：Deployment with Sidecar
  •    Sidecar： 连接到Prometheus，为Thanos Query提供查询数据，将其上传到云对象存储
  •    Store Gateway：在云存储桶内提供指标，作为对象存储暴露的网关
  •    Compactor：对存储在云存储桶中的数据进行压缩、下采样和应用保留。
  •    Receiver：从Prometheus远程写入WAL端接收数据，将其公开和/或将其上传到云存储
  •    Ruler/Rule：针对 Thanos 中的数据评估记录和警报规则以进行展示和/或上传
  •    Querier/Query：实现 Prometheus 的 v1 API 来聚合来自底层组件的数据
  •    Query Frontend：实现 Prometheus 的 v1 API 将其代理到 Query，同时缓存响应并按查询天数进行可选拆分

参考：

  Thanos - Highly available Prometheus setup with long term storage capabilities

  https://github.com/thanos-io/thanos

  Learn Thanos using Interactive Browser-Based Labs | Katacoda

  Metric monitoring architecture at Improbable using Thanos - Improbable

Kubernetes (K8s) 监控方案：Prometheus 实战指南
TechEnthusiast的博客
08-27 814
在当今云原生时代，Kubernetes (K8s) 已成为容器编排的标准解决方案。然而，随着 K8s 集群规模和复杂性的增加，有效的监控变得至关重要。本文将详细介绍如何使用 Prometheus 构建一个全面而强大的 K8s 监控系统，帮助您实时掌握集群状态，快速定位问题，并优化资源利用。在设计 K8s 监控方案时，我们需要遵循两个核心原则：这些原则为我们提供了一个框架，确保我们的监控覆盖了最关键的指标。我们的 K8s 监控方案将包括以下核心组件：这些组件共同工作，提供了一个全面的监控解决方案。使用 Nod
开源神器KRR：用数据驱动K8s资源优化
TechEnthusiast的博客
02-24 401
CNCF调研显示，企业平均有35%的云资源处于闲置状态。本文将揭秘开源神器KRR（Kubernetes Resource Recommender），通过数据驱动方式实现精准资源配置，实测可降低69%云成本。在Kubernetes集群中，
thanos:一个全能的框架
05-28
坦诺斯 一个全能的框架 没有什么是真实的，一切都被允许
Thanos 架构
小楼一夜听春雨，深巷明朝卖杏花
05-11 2355
Thanos Thanos是一个基于 Prometheus 实现的监控方案，其主要设计目的是解决原生 Prometheus 上的痛点，并且做进一步的提升，主要的特性有：全局查询，高可用，动态拓展，长期存储。下图是 Thanos 官方的架构图： Thanos 主要由如下几个特定功能的组件组成：(相当于微服务的模式，里面有比较多的组件) 边车组件（Sidecar）：连接 Prometheus，并把 Prometheus 暴露给查询网关（Querier/Query），以供实时查询，并且可以上传 Pro.
thanos rule组件和prometheus区别？
运维老生常谈
04-19 629
Prometheus的规则评估功能适合单实例的监控环境，专注于在本地存储和评估数据，适合较简单或中小规模的监控部署。组件扩展了规则评估功能，适用于分布式、高可用的监控场景，能够处理跨多个 Prometheus 实例的数据，提供更强大的规则评估和告警能力，特别适合大规模企业级监控系统。如果你已经在使用 Prometheus 并希望扩展到更大的规模或跨区域监控，使用 Thanos 的rule组件将是一个自然的进阶选择。
Thanos架构学习
运维求生之路
06-28 768
thanos架构学习
打造云原生大型分布式监控系统(二): Thanos 架构详解
weixin_47224377的博客
11-05 560
在上一篇文章，我们想尽 “千方百计” 才好不容易把 Prometheus 优化到适配大规模场景，部署和后期维护麻烦且复杂不说，还有很多不完美的地方，并且还无法满足一些更高级的诉求，比如查看时间久远的监控数据，对于一些时间久远不常用的 “冷数据”，最理想的方式就是存到廉价的对象存储中，等需要查询的时候能够自动加载出来。Thanos (没错，就是灭霸) 可以帮我们简化分布式 Prometheus 的部署与管理，并提供了一些的高级特性：全局视图，长期存储，高可用。下面我们来详细讲解一下。
k8s1.23 部署Prometheus-Operator集群监控
08-28 1835
kubernetes自定义资源：使用kubernetes CRD 来部署和管理Prometheus，Alertmanager和相关组件简化的部署配置：直接通过kubernetes资源清单配置Prometheus,比如版本，持久化，副本，保留策略等等配置Prometheus监控目标配置：基于熟知的kubernetes标签查询自动生成监控目标配置，无需学习prometheus特地的配置。
k8s部署 普罗米修斯（Prometheus）监控
D2961953033的博客
09-16 2869
Prometheus是一个开源的服务监控系统和时序数据库其提供了通用的数据模型和快捷数据采集、存储和查询接口它的核心组件Prometheus服务器定期从静态配置的监控目标或者基于服务发现自动配置的目标中进行拉 取数据新拉取到啊的 数据大于配置的内存缓存区时，数据就会持久化到存储设备当中。
信创：鲲鹏(arm64)+麒麟(kylin v10)离线部署k8s和kubesphere(含离线部署新方式)
qq_33174891的博客
07-10 2058
本文介绍了如何在麒麟 V10 aarch64架构服务器上制品和离线部署 KubeSphere 和 Kubernetes 集群。我们将使用 KubeSphere 开发的 KubeKey 工具实现自动化部署，在三台服务器上实现高可用模式最小化部署 Kubernetes 集群和 KubeSphere。KubeSphere 和 Kubernetes 在 ARM 架构 和 X86 架构的服务器上部署，最大的区别在于所有服务使用的容器镜像架构类型。
kube-thanos：用于部署Thanos的Kubernetes特定配置
02-03
kube-thanos：用于部署Thanos的Kubernetes特定配置
（一）Thanos：引入Thanos 架构
Kammingo的博客
02-22 1535
一、问题背景及解决方案 问题1、Prometheus 本身只支持单机部署，没有自带支持集群部署，也就不支持高可用以及水平扩容，在大规模场景下，最让人关心的问题是它的存储空间也受限于单机磁盘容量，磁盘容量决定了单个 Prometheus 所能存储的数据量，数据量大小又取决于被采集服务的指标数量、服务数量、采集速率以及数据过期时间。在数据量大的情况下，我们可能就需要做很多取舍，比如丢弃不重要的指标、降低采集速率、设置较短的数据过期时间(默认只保留15天的数据，看不到比较久远的监控数据)。 解决方案： ①集中数据
Thanos工作原理及组件简介
east4ming的博客
04-02 1130
Thanos 是一个「开源的，高可用的 Prometheus 系统，具有长期存储能力」。很多知名公司都在使用 Thanos，也是 CNCF 孵化项目的一部分。Thanos 的一个主要特点就是通过使用对象存储（比如 S3）可以允许 “无限” 存储空间。对象存储可以是每个云提供商提供的对象存储也可以是 ceph、rook 或 minio 这样的解决方案。
使用Prometheus和Thanos进行高可用K8S监控
weixin_44190790的博客
08-08 814
使用Prometheus和Thanos进行高可用K8S监控
k8s 1.28.2 集群部署 Thanos 对接 MinIO 实现 Prometheus 数据长期存储
以梦为马|越骑越傻
10-29 1284
Thanos 官网Thanos quay.io 镜像仓库Thanos 是一个强大的 Prometheus 扩展解决方案，能够解决 Prometheus 在大规模环境下的存储、扩展性和高可用性问题。它非常适合大规模集群监控需求，尤其是需要长期存储监控数据和全局查询。yaml 和 dashboard 的 json 文件可以从 gitee 自取：https://gitee.com/chen2ha/yaml_for_kubernetes/tree/master/thanos。
进阶之路：从零到一在k8s上部署高可用prometheus —— thanos receive、thanos query
ary的博客
08-03 2186
目录导航前言相关yaml文件thanos receive配置相关thanos-objectstorage.yamlthanos-receiver-hashring.yaml服务相关thanos-receiver-service.yamlthanos-receiver.yamlthanos query服务相关thanos-query-service.yamlthanos-query-service-web.yamlthanos-query.yaml部署验证 导航 进阶之路：从零到一在k8s上部署高可用prom
Prometheus+Thanos架构详解
BigSHI_0822的博客
11-11 4649
针对prometheus的长期持久化存储问题，采用用thanos解决方案
prometheus 服务发现 k8s
最新发布
06-06
<think>嗯，用户这次问的是在K8S中为Prometheus配置服务发现的问题。从用户提供的站内引用来看，ta应该已经对K8S的服务暴露机制（引用[1]）和Prometheus基础架构（引用[2]）有了解，还注意到ta特意提到了coredns的配置细节（引用[3]），说明可能遇到过DNS解析相关的问题。用户可能是个DevOps工程师，正在搭建监控系统。ta没有提Thanos，所以暂时不需要考虑联邦集群，重点是如何让Prometheus自动发现K8S里的各种服务。考虑到引用[3]里展示了coredns配置，用户可能特别关注服务发现时的DNS解析问题。需要特别注意三个技术关键点：一是Prometheus的K8S服务发现原理，二是RBAC权限的精细控制（用户没提但实际部署必遇的坑），三是配置热重载机制。引用[2]里提到"需要机制管理Prometheus配置"，这正是服务发现要解决的问题。上次回答快速排序时演示了代码块用法，这次也应该给完整的配置示例。用户给的引用[3]里有configmapyaml，可以借鉴这个格式来展示prometheus.yml片段。同时要预判用户可能遇到的问题，比如RBAC权限不足导致无法发现服务，或者serviceMonitor命名空间不匹配的情况。</think> 在 Kubernetes 中为 Prometheus 配置服务发现主要依赖其原生支持的 **Kubernetes 服务发现机制**，结合 Prometheus Operator 可进一步简化流程。以下是详细步骤： --- ### **核心配置方法** 1. **修改 Prometheus 配置文件 (`prometheus.yml`)** 添加 Kubernetes SD 配置，使 Prometheus 自动发现集群资源： ```yaml scrape_configs: - job_name: 'kubernetes-service-discovery' kubernetes_sd_configs: - role: node # 发现集群节点 - role: pod # 发现所有 Pod - role: service # 发现 Service - role: endpoint # 发现 Service 的 Endpoint relabel_configs: # 通过标签筛选目标 - source_labels: [__meta_kubernetes_namespace] action: keep regex: "monitoring|prod" # 仅监控指定命名空间 - source_labels: [__meta_kubernetes_service_name] action: keep regex: "nginx|app-server" # 仅监控指定服务 ``` - `kubernetes_sd_configs` 定义发现角色（Node/Pod/Service等） - `relabel_configs` 通过标签过滤目标（例如按命名空间或服务名） 2. **配置 RBAC 权限** Prometheus 需拥有读取集群资源的权限： ```yaml apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: prometheus-sd rules: - apiGroups: [""] resources: ["nodes", "pods", "services", "endpoints"] verbs: ["get", "list", "watch"] --- apiVersion: v1 kind: ServiceAccount metadata: name: prometheus namespace: monitoring --- apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: prometheus-sd roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: prometheus-sd subjects: - kind: ServiceAccount name: prometheus namespace: monitoring ``` --- ### **（推荐）使用 Prometheus Operator** 通过声明式 CRD 管理服务发现： 1. **定义 ServiceMonitor** ```yaml apiVersion: monitoring.coreos.com/v1 kind: ServiceMonitor metadata: name: app-monitor namespace: monitoring spec: selector: matchLabels: app: my-app # 选择需监控的 Service 标签 endpoints: - port: web # Service 中定义的端口名称 interval: 30s # 抓取间隔 ``` Operator 会自动将该配置注入 Prometheus。 2. **验证发现结果** 访问 Prometheus Web 界面（`Targets` 页面），确认已自动发现目标： - 状态为 **UP** 表示配置成功 - 异常时可检查 Prometheus 日志：`kubectl logs prometheus-pod-name` --- ### **常见问题解决** | **问题** | **排查点** | |-------------------------|----------------------------------------------------------------------------| | 目标未发现 | - RBAC 权限不足<br>- ServiceMonitor 命名空间与 Prometheus 不一致<br>- 标签匹配错误 | | 抓取超时 (Timeout) | - 网络策略阻断访问<br>- Pod 未暴露 metrics 端口<br>- 防火墙规则限制 | | 证书错误 (SSL) | - 配置 `tls_config` 或 `scheme: https`<br>- 补充 `ca_file` 证书 | > 注：若集群 DNS 异常（如引用[3]中的 `cali-cluster.tclocal` 配置），需确保 Prometheus 能解析服务域名 [^3]。 --- **相关优化方案** - **联邦集群**：跨集群聚合数据（引用[2]中提到的联邦机制）[^2] - **Thanos 集成**：实现长期存储和高可用（引用[2]） - **自动重载配置**：挂载 ConfigMap 并启动时添加 `--web.enable-lifecycle`，通过 API 热更新： ```bash curl -X POST http://prometheus-host:9090/-/reload ``` ---
评论 1
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值