K8s部署独立Prometheus实例时scrape_configs配置加载失败问题

云原生阿岚

2026-8-29

根本原因

additionalScrapeConfigs字段用法错误。该字段仅接受纯scrape_configs数组格式的片段内容，不支持传入包含global等顶层配置的完整Prometheus配置文件。Prometheus Operator监听到Prometheus CR后，会自动拼接全局基础配置、内置采集规则，再将additionalScrapeConfigs的内容追加到最终配置的scrape_configs数组末尾，你传入带global段的内容会导致最终生成的YAML格式非法，配置加载sidecar无法正常输出完整的prometheus.env.yaml文件。
启动时序与错误降级逻辑匹配上了你看到的报错现象：Prometheus容器和配置reload sidecar是并行启动的，首次启动时sidecar还没完成配置生成、或者因为配置格式错误根本没生成目标文件，Prometheus进程先尝试读取配置就会报文件不存在触发重启；重启后sidecar降级生成了不包含错误附加配置的默认基础配置，Pod就能正常运行，但你自定义的scrape_configs自然不会出现在最终配置里。
Makefile的Secret更新逻辑有缺陷。kubectl create secret命令不具备幂等性，如果命名空间下已经存在同名Secret，该命令会直接报错跳过，不会更新Secret里存储的配置内容，哪怕你本地修正了配置文件，Pod挂载的还是旧的错误内容。
需额外排查Operator监听范围配置：如果之前修改过Rancher监控组件里Prometheus Operator的启动参数，限制了只监听cattle-monitoring-system命名空间的CR资源，Operator就不会处理indigo命名空间下的Prometheus实例，自然不会为其生成、更新配置。

解决方案

修正自定义采集配置文件prometheus-scrape-configs.yml，删除顶层的global配置段，仅保留scrape作业数组内容：

- job_name: blackbox # 采集blackbox exporter自身指标
  metrics_path: /metrics
  static_configs:
    - targets:
      - .....

- job_name: blackbox-http # 通过blackbox做HTTP探测
  metrics_path: /probe
  params:
    module: [http_2xx]
  static_configs:
    - targets:
      - .....
      labels:
        env: elise
    - targets:
      - .....
      labels:
        env: osb
    - targets:
      - .....
      labels:
        env: itp
  relabel_configs:
    - source_labels: [__address__]
      target_label: __param_target
    - source_labels: [__param_target]
      target_label: instance
    - target_label: __address__
      replacement: .....

全局参数不要放在附加配置里，直接在Prometheus CR的spec层级添加global字段声明即可，调整后的Prometheus CR段示例：

apiVersion: monitoring.coreos.com/v1
kind: Prometheus
metadata:
  name: indigo
  namespace: $NAMESPACE
spec:
  serviceAccountName: prometheus
  global:
    scrape_interval: 30s
    evaluation_interval: 30s
  additionalScrapeConfigs:
    name: prometheus-scrape-configs-secret
    key: prometheus-scrape-configs.yml
  resources:
    requests:
      memory: 400Mi

修正Makefile里的Secret创建逻辑，改成幂等更新的写法，保证每次部署都会同步最新的配置内容到Secret：

.PHONY: deploy-monitoring
deploy-monitoring:
    kubectl create secret generic prometheus-scrape-configs-secret \
    -n $(NAMESPACE) --from-file=prometheus-scrape-configs.yml --dry-run=client -o yaml | kubectl apply -f -

    envsubst < $(ENVIRONMENT)-deployment.yml | kubectl apply -f -

检查Prometheus Operator的监听范围，执行以下命令查看启动参数：

kubectl get deployment -n cattle-monitoring-system rancher-monitoring-operator -o yaml | grep -A5 args

如果输出里存在--namespaces=cattle-monitoring-system这类限制命名空间的参数，需要将indigo添加到监听列表，或者移除该参数让Operator监听全命名空间的CR资源。
4. 重新执行部署命令后，先通过kubectl get prometheus -n indigo -o yaml查看CR的status.conditions字段，确认没有配置解析相关的报错，再进入Pod检查/etc/prometheus/config_out/prometheus.env.yaml内容，即可看到自定义的scrape_configs段。

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