为何仅单个Prometheus分片抓取KSM？求多分片配置方案

问题根源 #

Prometheus分片默认基于__address__标签做哈希分片（hashmod策略），而Kube-State-Metrics（KSM）通常是单实例部署，其__address__固定不变，会被哈希分配到某一个Prometheus分片上。这就导致其他分片完全抓取不到kube_pod_info指标——你的记录规则在单个分片上运行时，只能用该分片仅有的部分kube_pod_info数据和全量cadvisor指标做关联，最终生成的自然是不完整的节点数据。

多分片抓取KSM的可行方案 #

方案1：拆分KSM实例+分片定向抓取 #

• 部署多个KSM实例，通过--resource参数拆分各自负责的K8s资源类型（比如一个实例专门抓取Pod/Node数据，另一个抓取Service/Ingress），或者用标签选择器过滤要抓取的Pod范围。
• 给每个KSM实例注入唯一的分片标识标签（比如ksm_shard: "0"、ksm_shard: "1"），然后修改Prometheus的分片配置，让每个Prometheus分片只抓取对应标签的KSM实例。
• 优势：拆分后单KSM实例负载降低，资源利用更合理；劣势：需要维护多套KSM的部署和配置，复杂度略高。

方案2：修改分片策略，让所有Prometheus分片都抓取KSM #

• 针对KSM的抓取job单独配置，跳过默认的哈希分片逻辑，让所有Prometheus分片都抓取KSM实例，依赖Thanos的重复数据删除机制（默认启用）来处理重复指标。
• 示例配置：

scrape_configs:
  - job_name: 'kube-state-metrics'
    scrape_interval: 30s
    static_configs:
      - targets: ['kube-state-metrics.kube-system.svc:8080']
    # 关闭该job的分片逻辑，所有Prometheus实例都抓取
    thanos:
      shard:
        enabled: false
    # 或者通过relabel强制所有实例抓取该job
    relabel_configs:
      - action: replace
        source_labels: [__address__]
        target_label: __tmp_address__
      - action: hashmod
        source_labels: [__tmp_address__]
        modulus: 1
        target_label: __shard__

• 优势：无需改动KSM部署，配置简单；劣势：所有分片都会抓取KSM，会增加少量网络和存储负载，适合KSM指标量不大的场景。

方案3：用Thanos Ruler运行全局记录规则（临时方案转正） #

• 让Thanos Ruler从Thanos Query拉取全量的cadvisor和KSM指标，在全局层面运行记录规则——这样天然能拿到完整的数据集，关联后生成的指标自然是全量的。
• 这其实是跨分片关联规则的最优实践：分片Prometheus负责抓取和存储局部数据，全局规则交给Thanos Ruler统一计算，从根源避免单个分片数据不全的问题。

内容的提问来源于stack exchange，提问作者Haitham00n