1. 项目概述为什么“K8S 部署 Prometheus 高可用集群”不是锦上添花而是生产环境的生存底线你刚接手一个运行了三个月的 K8S 集群业务 Pod 状态看起来一切正常——直到凌晨两点订单支付成功率突然从 99.97% 掉到 82%告警没响日志里没有 ERRORSRE 团队花了 47 分钟才定位到是 etcd 节点磁盘 IO 持续 98% 导致 apiserver 响应延迟飙升。而你的 Prometheus 单点实例早在故障发生前 18 分钟就因内存 OOM 被 kubelet 杀掉重启后 WAL 数据丢失、TSDB 重建失败监控断档——你根本不知道那 18 分钟里发生了什么。这不是虚构场景是我去年在一家中型电商公司真实踩过的坑。“K8S 部署 Prometheus 高可用集群”这个标题里的每一个词都直指生产系统的核心命脉K8S是调度与编排底座Prometheus是可观测性的眼睛而高可用集群不是“多跑几个副本就叫 HA”它是当主节点宕机、网络分区、存储损坏、配置错误、版本升级失败时监控数据不丢、查询不中断、告警不沉默的硬性保障。网上大量所谓“Prometheus 高可用教程”本质只是把replicas: 2往 StatefulSet 里一塞再加个 Service 做 ClusterIP 负载结果呢两个实例各自独立抓取、各自存储、各自计算Alertmanager 规则重复触发Grafana 查询返回不一致结果甚至因 TSDB WAL 文件竞争导致数据损坏——这不叫高可用这叫“高不可靠”。真正能落地的高可用必须同时解决三个维度的可靠性数据层高可用指标采集不丢、写入不乱、存储不腐、恢复不漏服务层高可用查询响应连续、告警触发精准、API 调用稳定运维层高可用配置变更原子、版本升级平滑、故障切换秒级、扩缩容无感。本项目标题中的“最新无坑版”核心就落在“无坑”二字——它意味着我们绕开了社区文档里不会写的陷阱比如 Prometheus v2.40 默认启用的--enable-featurememory-snapshot-on-shutdown在容器环境下极易引发启动卡死比如prometheus-operator的PrometheusRuleCRD 在跨命名空间引用时的 RBAC 权限黑洞比如 Alertmanager 配置中group_by: [job]与group_wait: 30s组合在高并发告警流下导致的聚合失效。这些坑我都在 Ubuntu 24.04 containerd 1.7.13 Kubernetes v1.28.8 的真实环境中反复验证过所有配置均基于上游 Helm Chart v52.4.02024 Q2 最新稳定版深度定制不依赖任何第三方私有镜像或魔改组件。如果你正在为 Dev 环境搭建 CI/CD 流水线比如对接 GitLab CI/CD 自动部署到 k8s这套方案就是你监控底座的黄金标准——它不只是一套部署脚本更是你整个可观测性体系的 SLA 锚点。2. 整体架构设计与选型逻辑为什么不用 Operator为什么必须用 Thanos Ruler为什么拒绝单点 Alertmanager2.1 架构全景图三层解耦四重冗余真正的高可用绝非堆砌副本而是分层解耦、职责清晰、故障域隔离。本方案采用经典的“采集-存储-查询-告警”四层分离架构每层均实现跨 AZ可用区部署与自动故障转移采集层Scraping Layer部署 3 个独立的prometheus-server实例StatefulSet每个实例绑定专属ServiceMonitor和PodMonitor通过relabel_configs实现标签路由确保同一目标仅被一个实例抓取避免重复采集导致指标翻倍。关键点在于禁用--web.enable-admin-api关闭所有远程写入口所有写入仅走本地 TSDB。这是防止脑裂的第一道防线。存储层Storage Layer每个 Prometheus 实例挂载独立的PersistentVolume推荐使用local-path-provisioner NVMe SSD并启用--storage.tsdb.retention.time15d与--storage.tsdb.wal-compression。这里不做远程存储如 S3因为远程写会引入网络抖动、认证延迟、重试风暴三大风险。我们把存储可靠性压在本地磁盘与 RAID10 上——实测 NVMe SSD 的 99.99% IOPS 稳定性远高于任何对象存储网关。查询层Query Layer部署prometheus-thanos-query作为统一查询入口后端连接全部 3 个 Prometheus 实例通过 Headless Service DNS SRV 记录自动发现。Thanos Query 自动去重、降采样、跨时间窗口合并确保 Grafana 查询返回全局一致视图。注意Thanos Query 本身不存储数据它只是智能代理因此可水平扩展至 10 副本。告警层Alerting Layer部署 3 副本alertmanagerStatefulSet通过--cluster.peer参数组成 Raft 集群共享告警状态。所有 Prometheus 实例将告警推送至alertmanager-headless.default.svc.cluster.local:9093由 Alertmanager 集群内部完成去重、分组、静默、抑制与通知。关键配置--cluster.reconnect-interval10s缩短脑裂恢复时间、--web.external-urlhttps://alertmgr.prod.example.com强制外部 URL 生成正确通知链接。提示此架构完全规避了prometheus-operator的复杂性。Operator 虽然自动化程度高但其PrometheusCRD 的滚动更新策略在 v0.72.0 之前存在严重 Bug——当修改spec.storage.volumeSize时Operator 会先删除旧 StatefulSet 再创建新实例导致监控真空期长达 3-5 分钟。而本方案采用纯 Helm Kustomize 管理所有变更通过kubectl apply -k原子执行零停机。2.2 核心组件选型依据为什么是 Thanos 而非 Cortex 或 Mimir社区常争论 Thanos、Cortex、Mimir 三者的优劣但在 K8S 生产环境“最新无坑版”的选型逻辑非常务实组件优势本方案弃用原因实测数据Thanos与原生 Prometheus 完全兼容无需修改采集配置Sidecar 模式对现有 Prometheus 侵入极小Query 层天然支持多租户隔离——单集群 3 节点查询 P99 800ms10 万 seriesCortex天然多租户、水平扩展强需要独立部署 Distributor/Ingester/Querier/Store-gateway组件间 gRPC 通信链路长故障定位复杂Ingester 内存泄漏 Bug 在 v1.14.0 仍未彻底修复故障平均恢复时间 12 分钟MimirGrafana Labs 主导生态整合好对 etcd 依赖强K8S 环境需额外部署 etcd 集群mimirtool配置校验工具在 Ubuntu 24.04 下编译失败率 37%本地测试 5 次部署2 次因 etcd TLS 证书握手超时失败我们选择 Thanos 的核心理由是它把复杂性锁在 Query 层而让 Prometheus 保持纯粹。你不需要理解 Cortex 的 Ring 一致性哈希也不需要调试 Mimir 的 Blocks Storage GC 策略。只需在 Prometheus 启动参数里加一行--storage.tsdb.max-block-duration2h再部署一个 Sidecar剩下的交给 Thanos Query。这种“最小必要改动”原则正是生产环境稳定性的基石。2.3 高可用的关键细节WAL 文件如何避免竞态TSDB 如何保证崩溃恢复很多教程忽略了一个致命细节Prometheus 的 WALWrite-Ahead Log文件在多副本场景下极易引发数据损坏。当两个 Prometheus 实例同时写入同一块共享存储如 NFS时WAL 的segment文件会被并发 truncate导致部分写入丢失。本方案彻底杜绝共享存储但带来了新问题每个实例的 WAL 是独立的如何保证崩溃后数据不丢答案藏在--storage.tsdb.wal-compression与--storage.tsdb.retention.time的协同机制里WAL 文件默认每 128MB 生成一个新 segment可通过--storage.tsdb.wal-segment-size调整Prometheus 启动时会扫描所有 WAL segment按时间顺序重放replay其中的样本数据关键点WAL 重放是幂等的。即使某个 segment 被部分写入Prometheus 也能通过 CRC 校验跳过损坏块继续处理后续有效数据更重要的是--storage.tsdb.retention.time15d并非只清理旧 block它同时控制 WAL 的保留策略——当 TSDB 创建新 block 时会自动删除已成功持久化到 block 中的对应 WAL segment。实测数据模拟 Prometheus 进程被kill -9强制终止重启后 WAL 重放耗时 2.3 秒NVMe SSD恢复数据精度达 100%对比崩溃前 1 分钟内所有 counter 指标增量。而如果启用--enable-featurememory-snapshot-on-shutdownv2.40 默认进程会在退出前将内存中未刷盘的样本快照到磁盘但这在容器环境下极易因SIGTERM信号处理超时导致启动卡死——我们禁用该特性用更可靠的 WAL 机制兜底。3. 核心配置详解与实操步骤从 Ubuntu 24.04 环境初始化到 Grafana 仪表盘上线3.1 环境准备Ubuntu 24.04 的 kernel 与 containerd 适配要点在 Ubuntu 24.04Noble Numbat上部署 K8S最大的坑不是 Kubernetes 本身而是kernel 6.8 的 cgroup v2 默认行为与 containerd 1.7 的兼容性。如果你直接apt install containerd会得到 v1.7.13但它默认启用systemd_cgroup true而 Ubuntu 24.04 的 systemd 255 对 cgroup v2 的memory.high控制存在 race condition导致 Prometheus 容器内存限制失效。必须执行的三步初始化修正 containerd 配置# 编辑 /etc/containerd/config.toml sudo sed -i s/systemd_cgroup true/systemd_cgroup false/g /etc/containerd/config.toml # 重启 containerd sudo systemctl restart containerd禁用 swap 并配置内核参数# Ubuntu 24.04 默认启用 zram swap必须关闭 sudo swapoff -a sudo sed -i /swap/d /etc/fstab # 添加内核参数防止 OOM Killer 误杀 Prometheus echo vm.swappiness1 | sudo tee -a /etc/sysctl.conf echo kernel.pid_max4194304 | sudo tee -a /etc/sysctl.conf sudo sysctl -p验证 cgroup 版本与挂载点# 必须看到 unified cgroup hierarchy mount | grep cgroup # 输出应为cgroup2 on /sys/fs/cgroup type cgroup2 (rw,nosuid,nodev,noexec,relatime,seclabel) # 若看到 cgroup1请检查 /proc/cmdline 是否含 systemd.unified_cgroup_hierarchy1注意跳过这三步Prometheus 在高负载下会出现内存 RSS 持续增长直至被 OOM Killer 杀死且kubectl top pods显示的内存使用量与docker stats严重不符。这是 Ubuntu 24.04 独有的坑网上 90% 的教程都未提及。3.2 Prometheus Server 部署StatefulSet 的 7 个关键字段解析我们不使用 Helm Chart 的默认 values.yaml而是手写精简版 StatefulSetprometheus-server.yaml聚焦高可用核心字段apiVersion: apps/v1 kind: StatefulSet metadata: name: prometheus-server namespace: monitoring spec: serviceName: prometheus-server # 必须与 Headless Service 名称一致 replicas: 3 podManagementPolicy: Parallel # 关键允许并行启动避免串行等待导致启动慢 updateStrategy: type: RollingUpdate rollingUpdate: partition: 0 # 滚动更新时从序号 0 开始逐个更新确保至少 2 个实例在线 selector: matchLabels: app: prometheus-server template: metadata: labels: app: prometheus-server annotations: # 关键启用 Prometheus 原生健康检查避免 kubelet 误判 prometheus.io/scrape: true prometheus.io/port: 9090 spec: containers: - name: prometheus image: quay.io/prometheus/prometheus:v2.47.2 # 2024 Q3 最新稳定版 args: - --config.file/etc/prometheus/prometheus.yml - --storage.tsdb.path/prometheus - --storage.tsdb.retention.time15d - --web.enable-lifecycle # 允许热重载配置 - --web.enable-admin-api # 仅开发环境启用生产环境注释掉 - --storage.tsdb.wal-compression - --storage.tsdb.max-block-duration2h # Thanos Sidecar 必需 - --log.levelinfo ports: - containerPort: 9090 name: http volumeMounts: - name: config-volume mountPath: /etc/prometheus/ - name: prometheus-storage mountPath: /prometheus # 关键资源限制必须严格防止抢占其他 Pod 资源 resources: limits: memory: 8Gi cpu: 4000m requests: memory: 6Gi cpu: 2000m # 关键Liveness Probe 必须用 /-/readyz而非 /healthz livenessProbe: httpGet: path: /-/readyz port: 9090 initialDelaySeconds: 60 timeoutSeconds: 30 periodSeconds: 30 readinessProbe: httpGet: path: /-/healthy port: 9090 initialDelaySeconds: 30 timeoutSeconds: 10 periodSeconds: 10 volumes: - name: config-volume configMap: name: prometheus-config volumeClaimTemplates: # 每个 Pod 独立 PVC杜绝 WAL 竞态 - metadata: name: prometheus-storage spec: accessModes: [ReadWriteOnce] storageClassName: local-path # 使用 local-path-provisioner resources: requests: storage: 100Gi7 个字段的深层解读podManagementPolicy: Parallel默认OrderedReady会等待第一个 Pod Ready 后再启动第二个导致 3 副本启动耗时翻 3 倍。高可用要求快速拉起全部实例。rollingUpdate.partition: 0K8S 1.24 新增字段指定更新起始序号。设为 0 表示全部更新但结合replicas: 3与minAvailable: 2需在 PodDisruptionBudget 中配置实际更新时会确保至少 2 个在线。--storage.tsdb.max-block-duration2hThanos Sidecar 要求 Prometheus 以短周期生成 block否则无法及时上传。2h 是平衡上传频率与 block 大小的最佳值。livenessProbe.path: /-/readyzPrometheus 的/healthz已废弃/-/readyz才是官方推荐的就绪探针路径它检查 TSDB 加载、配置加载、Web 服务是否就绪。resources.limits.memory: 8Gi实测数据——当抓取目标 5000 个时Prometheus 内存峰值稳定在 6.2~7.8Gi。设为 8Gi 留出 20% 缓冲避免频繁 OOM。volumeClaimTemplates必须用volumeClaimTemplates而非volumes确保每个 Pod 拥有独立 PV物理隔离 WAL 存储。annotations.prometheus.io/scrape: true为 Prometheus 自身暴露的 metrics 开启自监控这是诊断 Prometheus 自身健康的第一手数据。3.3 Thanos Sidecar 与 Query 部署如何让 3 个 Prometheus “说同一种语言”Thanos 的核心价值在于 Query 层的智能聚合而 Sidecar 是连接 Prometheus 与 Query 的神经末梢。部署难点在于Sidecar 必须与 Prometheus 实例一一绑定且网络发现必须零配置。Step 1部署 Thanos Sidecar作为 Prometheus 的 InitContainer# 在 prometheus-server.yaml 的 containers 数组中追加 - name: thanos-sidecar image: quay.io/thanos/thanos:v0.34.1 # 与 Prometheus v2.47.2 兼容的最新版 args: - sidecar - --prometheus.urlhttp://localhost:9090 - --grpc-address0.0.0.0:10901 # Sidecar gRPC 端口供 Query 发现 - --http-address0.0.0.0:10902 # Sidecar HTTP 端口供调试 - --tsdb.path/prometheus ports: - containerPort: 10901 name: grpc - containerPort: 10902 name: http volumeMounts: - name: prometheus-storage mountPath: /prometheusStep 2部署 Thanos QueryHeadless Service StatefulSet# thanos-query-service.yaml apiVersion: v1 kind: Service metadata: name: thanos-query namespace: monitoring spec: clusterIP: None # Headless Service让客户端直连 Pod IP ports: - port: 9090 targetPort: http selector: app: thanos-query # thanos-query-statefulset.yaml apiVersion: apps/v1 kind: StatefulSet metadata: name: thanos-query namespace: monitoring spec: serviceName: thanos-query replicas: 3 selector: matchLabels: app: thanos-query template: metadata: labels: app: thanos-query spec: containers: - name: thanos-query image: quay.io/thanos/thanos:v0.34.1 args: - query - --http-address0.0.0.0:9090 - --grpc-address0.0.0.0:10901 - --log.levelinfo - --query.replica-labelprometheus_replica # 告诉 Query哪个 label 标识副本 # 关键动态发现所有 Prometheus Sidecar - --storednssrv_grpc._tcp.thanos-store.monitoring.svc.cluster.local ports: - containerPort: 9090 name: http - containerPort: 10901 name: grpcDNS SRV 记录的魔法dnssrv_grpc._tcp.thanos-store.monitoring.svc.cluster.local这一串看似复杂的字符串其实是 K8S CoreDNS 的高级功能。我们需提前创建一个 Headless Servicethanos-storeapiVersion: v1 kind: Service metadata: name: thanos-store namespace: monitoring spec: clusterIP: None ports: - name: grpc port: 10901 protocol: TCP selector: app: prometheus-server # 匹配所有 Prometheus PodCoreDNS 会自动为每个匹配的 Pod 生成 SRV 记录格式为_grpc._tcp.pod-0.thanos-store.monitoring.svc.cluster.local. 30 IN SRV 0 100 10901 pod-0.prometheus-server.monitoring.svc.cluster.local.Thanos Query 启动时通过 DNS 查询_grpc._tcp.thanos-store...即可获取全部 3 个 Sidecar 的 IP 和端口实现零配置自动发现。实操心得第一次部署时若kubectl get endpoints thanos-store返回空说明 CoreDNS 未生效。此时执行kubectl rollout restart deployment coredns -n kube-system强制刷新通常 10 秒内即可同步。这是 Thanos 部署中最常见的“查无此服务”问题根源在于 CoreDNS 缓存未及时更新。3.4 Alertmanager 高可用集群Raft 集群的 5 个心跳参数调优Alertmanager 的高可用不是简单起多个 Pod而是构建一个稳定的 Raft 共识集群。默认配置在跨 AZ 网络下极易脑裂必须精细调整心跳参数# alertmanager-statefulset.yaml apiVersion: apps/v1 kind: StatefulSet metadata: name: alertmanager namespace: monitoring spec: serviceName: alertmanager replicas: 3 template: spec: containers: - name: alertmanager image: quay.io/prometheus/alertmanager:v0.27.0 args: - --config.file/etc/alertmanager/config.yml - --storage.path/alertmanager - --cluster.listen-address0.0.0.0:9094 # Raft 监听地址 - --cluster.advertise-address$(POD_IP):9094 # 广播地址用 Downward API 注入 - --cluster.peeralertmanager-0.alertmanager.monitoring.svc.cluster.local:9094 - --cluster.peeralertmanager-1.alertmanager.monitoring.svc.cluster.local:9094 - --cluster.peeralertmanager-2.alertmanager.monitoring.svc.cluster.local:9094 - --web.external-urlhttps://alertmgr.prod.example.com - --log.levelinfo # 关键Raft 心跳参数调优针对跨 AZ 网络 - --cluster.reconnect-interval10s # 重连间隔缩短脑裂恢复时间 - --cluster.reconnect-timeout5s # 重连超时 - --cluster.election-timeout30s # 选举超时必须 heartbeat-timeout - --cluster.heartbeat-timeout10s # 心跳超时网络抖动容忍阈值 - --cluster.gossip-interval2s # Gossip 传播间隔加速状态同步 env: - name: POD_IP valueFrom: fieldRef: fieldPath: status.podIP ports: - containerPort: 9093 name: http - containerPort: 9094 name: cluster volumeMounts: - name: config-volume mountPath: /etc/alertmanager/ - name: alertmanager-storage mountPath: /alertmanager为什么这 5 个参数必须调优默认--cluster.heartbeat-timeout1s在跨 AZ 网络中ICMP ping 延迟常达 5~15ms1s 心跳超时会导致频繁误判节点失联触发无效选举。--cluster.election-timeout30s必须大于heartbeat-timeout的 3 倍否则可能在心跳包传输延迟时误触发选举。--cluster.gossip-interval2s默认 200ms 过于激进高并发告警流下易引发 gossip 消息风暴2s 是平衡传播速度与网络负载的黄金值。验证集群状态访问http://any-alertmanager-pod-ip:9093/metrics搜索alertmanager_cluster_peers_connected值应为 3搜索alertmanager_cluster_status值应为1表示健康。若出现0说明 Raft 集群未形成需检查--cluster.peer地址是否能互相 telnet 通。4. 实操全流程与关键环节验证从kubectl apply到 Grafana 仪表盘上线的 17 分钟4.1 部署命令流5 个 YAML 文件的精确执行顺序整个部署过程严格遵循依赖顺序任何一步出错都会导致后续失败。以下是经过 23 次生产环境验证的精确命令流假设所有 YAML 文件存于./k8s-prom-ha/目录# Step 1创建 monitoring 命名空间与 RBAC必须最先执行 kubectl apply -f ./k8s-prom-ha/00-namespace-rbac.yaml # Step 2部署 local-path-provisioner为 Prometheus 提供本地存储 kubectl apply -f https://raw.githubusercontent.com/rancher/local-path-provisioner/v0.0.24/deploy/local-path-storage.yaml # 等待 provisioner Pod Running kubectl wait --forconditionReady pod -l applocal-path-provisioner -n local-path-storage --timeout120s # Step 3部署 Prometheus ConfigMap 与 Secret配置与证书 kubectl apply -f ./k8s-prom-ha/01-configmap-secret.yaml # Step 4部署 Prometheus Server Thanos Sidecar核心监控采集 kubectl apply -f ./k8s-prom-ha/02-prometheus-server.yaml # 等待全部 3 个 Pod Running 且 Ready kubectl wait --forconditionReady pod -l appprometheus-server -n monitoring --timeout300s # Step 5部署 Thanos Query Alertmanager查询与告警 kubectl apply -f ./k8s-prom-ha/03-thanos-query.yaml kubectl apply -f ./k8s-prom-ha/04-alertmanager.yaml # 等待 Query 与 Alertmanager 全部 Ready kubectl wait --forconditionReady pod -l appthanos-query -n monitoring --timeout120s kubectl wait --forconditionReady pod -l appalertmanager -n monitoring --timeout120s总耗时基准在 3 节点 K8S 集群8C16G * 3上从kubectl apply -f 00-namespace-rbac.yaml到所有 Pod Ready实测平均耗时17 分钟 23 秒。其中最长环节是 Prometheus 初始化 TSDB约 8 分钟因其需加载全部 WAL 并构建内存索引。4.2 关键环节验证清单12 个必检点缺一不可部署完成后必须逐项验证以下 12 个关键点。任何一个失败都意味着高可用未生效序号验证项执行命令期望输出失败含义1Prometheus 实例是否全部 Runningkubectl get pods -n monitoring -l appprometheus-serverprometheus-server-0/1/2 2/2 Running副本数不足采集层单点2Thanos Sidecar 是否就绪kubectl get pods -n monitoring prometheus-server-0 -o wideREADY列显示2/2Sidecar 未启动无法被 Query 发现3Thanos Query 是否发现全部 Storekubectl logs -n monitoring thanos-query-0grep found new store输出 3 行含pod-0/pod-1/pod-24Alertmanager Raft 集群是否形成kubectl exec -n monitoring alertmanager-0 -- curl -s http://localhost:9093/statusgrep StatusStatus: running且Peers: 35Prometheus 自身指标是否可查curl -s http://localhost:9090/api/v1/query?queryprometheus_build_infojq .data.result[0].metric返回{branch:HEAD,buildUser:root...,version:2.47.2}6Thanos Query 是否返回全局数据curl -s http://localhost:9090/api/v1/query?querycount by(job)(up)jq .data.result[].value返回[1, 1, 1]3 个 job 各 1 个实例7Alertmanager 是否接收告警kubectl exec -n monitoring prometheus-server-0 -- curl -X POST -d {status:firing,alerts:[{labels:{alertname:TestAlert,job:prometheus},annotations:{}}]} http://alertmanager.monitoring.svc.cluster.local:9093/api/v1/alertsHTTP 200Alertmanager 网络不通或配置错误8Grafana 数据源是否连通在 Grafana UI 中Settings → Data Sources → Prometheus → Save TestData source is workingGrafana 无法访问 Thanos Query9Grafana 仪表盘是否显示数据导入 ID 18601Kubernetes Cluster MonitoringCPU/Memory/Network 图表有实时曲线数据链路中断或 PromQL 查询错误10模拟 Prometheus 崩溃恢复kubectl delete pod -n monitoring prometheus-server-1新 Pod 启动后 30 秒内kubectl get pods显示Running/2/2启动失败WAL 或配置有误11模拟网络分区手动断开 1 节点kubectl delete pod -n monitoring thanos-query-2剩余 2 个 Query 仍能响应查询Query 层无冗余单点故障12检查告警静默是否全局生效在 Alertmanager UI 中创建静默观察prometheus-server-0/1/2的告警是否全部消失全部消失Raft 状态未同步静默只在单节点生效注意第 10 步“模拟崩溃恢复”是检验高可用的终极测试。实测中Prometheus Pod 被删除后K8S 重新调度新 Pod从拉镜像、挂载 PVC、加载 WAL、启动 Web 服务全程平均耗时 42 秒。期间 Thanos Query 自动剔除离线实例查询请求无缝路由至剩余 2 个实例监控数据无中断。这才是真正的“高可用”。4.3 Grafana 集成与仪表盘配置如何让 3 个 Prometheus 的数据在一张图上说话Grafana 本身不感知 Prometheus 副本它只认数据源。要让 Grafana 展示全局视图必须配置 Thanos Query 为数据源并在查询中显式声明prometheus_replica标签Step 1添加 Thanos Query 数据源URL 填http://thanos-query.monitoring.svc.cluster.local:9090集群内访问如果 Grafana 在集群外需通过 Ingress 暴露 Thanos Query并启用 Basic Auth见下文安全加固Step 2编写 PromQL 查询关键不要写sum(rate(http_requests_total[5m]))这会让 Grafana 随机选择一个 Prometheus 实例查询结果不可靠。必须写sum by (job, instance) (rate(http_requests_total{job~kubernetes.*}[5m]))Thanos Query 会自动从 3 个实例中去重、合并返回全局聚合结果。Step 3配置仪表盘变量让运维更高效在 Grafana Dashboard 设置中添加变量prometheus_replica类型Query数据源Thanos Query查询label_values(prometheus_replica)