kube-prometheus 监控附加命名空间：通过 jsonnet 扩展 Prometheus 抓取范围与 ServiceMonitor 实战指南

云原生可观测性指标监控监控大盘告警【免费下载链接】kube-prometheusUse Prometheus to monitor Kubernetes and applications running on Kubernetes项目地址https://gitcode.com/gh_mirrors/ku/kube-prometheus点击查看免费下载导读在默认部署中kube-prometheus 的 Prometheus 服务仅具备在default、kube-system以及监控栈自身所在命名空间由$.values.namespace指定内发现与抓取目标的能力这是由 Prometheus 服务账号所绑定的命名空间级 RBAC 权限决定的。本文基于 docs/customizations/monitoring-additional-namespaces.md 的定制指南讲解如何通过 jsonnet 向$.values.prometheus.namespaces追加目标命名空间从而让 Prometheus 自动生成对应命名空间的 Role/RoleBinding 并完成服务发现随后介绍如何在同一 jsonnet spec 中定义 ServiceMonitor 资源将命名空间内的应用服务纳入抓取。读完本文你将掌握一套完整的、与 kube-prometheus 原生工具链一致的多命名空间监控扩展方案。为什么默认只能监控三个命名空间RBAC 是抓取的前提Prometheus 在 Kubernetes 上通过 ServiceMonitor / PodMonitor 等自定义资源发现目标时实际上依赖 Prometheus Operator 内部的 Kubernetes 服务发现kubernetes_sd机制——它需要调用 Kubernetes API 去枚举Service、Pod、EndpointSlice或Endpoints与Ingress。因此Prometheus 服务账号必须拥有对应命名空间内这些资源的get、list、watch权限否则即使存在 ServiceMonitor 也无法抓取到任何目标。这一点可以在源码中得到直接印证。在 jsonnet/kube-prometheus/components/prometheus.libsonnet#L13 中默认的命名空间列表被定义为namespaces:: [default, kube-system, defaults.namespace],defaults.namespace即用户通过$.values.namespace配置的监控栈部署命名空间默认为monitoring。紧接着同一文件中基于该列表生成了两类命名空间级 RBAC 对象roleSpecificNamespacesprometheus.libsonnet#L276-L319为列表中的每个命名空间各生成一个Role其规则覆盖endpointslices或endpoints取决于serviceDiscoveryRole配置、services、pods与ingresses的get/list/watch权限roleBindingSpecificNamespacesprometheus.libsonnet#L184-L206为每个命名空间生成对应的RoleBinding将 Prometheus 的 ServiceAccount位于监控栈命名空间与上述Role绑定。因此默认部署下你会在集群中看到三个Role/RoleBinding组合。以仓库自带的渲染产物 manifests/prometheus-roleSpecificNamespaces.yaml 和 manifests/prometheus-roleBindingSpecificNamespaces.yaml 为例其中分别为default、kube-system、monitoring三个命名空间各生成了一份Role与RoleBindingRole 规则中包含endpointslices、services、pods、ingresses的get/list/watch权限RoleBinding 的 subject 则是位于monitoring命名空间下的prometheus-k8sServiceAccount。注意Role与RoleBinding都是命名空间级资源必须成对出现在目标命名空间内。仅仅在目标命名空间放置 ServiceMonitor 而不授予 Prometheus 对应权限目标将永远处于 Down / 不可发现状态。第一步向$.values.prometheus.namespaces追加目标命名空间要将额外的命名空间纳入监控范围只需在 jsonnet spec 中通过合并操作符向prometheus.namespaces追加命名空间名称。完整的可运行示例见 examples/additional-namespaces.jsonnetlocal kp (import kube-prometheus/main.libsonnet) { values:: { common: { namespace: monitoring, }, prometheus: { namespaces: [my-namespace, my-second-namespace], }, }, }; { [00namespace- name]: kp.kubePrometheus[name] for name in std.objectFields(kp.kubePrometheus) } { [0prometheus-operator- name]: kp.prometheusOperator[name] for name in std.objectFields(kp.prometheusOperator) } { [node-exporter- name]: kp.nodeExporter[name] for name in std.objectFields(kp.nodeExporter) } { [kube-state-metrics- name]: kp.kubeStateMetrics[name] for name in std.objectFields(kp.kubeStateMetrics) } { [alertmanager- name]: kp.alertmanager[name] for name in std.objectFields(kp.alertmanager) } { [prometheus- name]: kp.prometheus[name] for name in std.objectFields(kp.prometheus) } { [grafana- name]: kp.grafana[name] for name in std.objectFields(kp.grafana) }需要理解的关键点是namespaces: [my-namespace, my-second-namespace]使用的是:合并操作符而不是::覆盖。:会在默认列表[default, kube-system, monitoring]的基础上追加新命名空间而::则会整体替换默认列表这正是 examples/all-namespaces.jsonnet 中配合全命名空间插件使用namespaces: []清空列表的原因。如果你确实需要替换默认列表应使用::。追加列表后jsonnet 渲染阶段会自动为my-namespace、my-second-namespace各生成一份Role与RoleBinding生成的逻辑与前述roleSpecificNamespaces/roleBindingSpecificNamespaces完全一致因此无需手工编写这些 RBAC 清单。若监控栈部署命名空间不是monitoring请同步修改common.namespace使整个 jsonnet 生成结果自洽。补充监控所有命名空间的替代方案如果你希望省去逐个维护命名空间列表的成本仓库提供了all-namespacesaddonjsonnet/kube-prometheus/addons/all-namespaces.libsonnet。它会直接向 Prometheus 的clusterRole追加endpointslices、services、endpoints、pods、ingresses的get/list/watch权限并将roleBindingSpecificNamespaces与roleSpecificNamespaces置为null——因为集群级 Role 已覆盖所有命名空间无需再生成命名空间级 RBAC。使用方式见 examples/all-namespaces.jsonnetlocal kp (import kube-prometheus/main.libsonnet) (import kube-prometheus/addons/all-namespaces.libsonnet) { values:: { common: { namespace: monitoring, }, prometheus: { namespaces: [], }, }, };该方案以提升权限为代价换取免维护适合对安全隔离要求不高的测试环境生产环境建议按需使用本文第一部分介绍的精确命名空间追加方式。第二步为每个附加命名空间定义 ServiceMonitor仅完成 RBAC 扩展还不足以让 Prometheus 开始抓取。还需要为目标命名空间内的服务定义 ServiceMonitor 资源——它是 Prometheus Operator 用于描述抓取哪些端点、以何种指标路径抓取的声明式配置。官方指南强调通常应由命名空间的属主应用团队自行维护各自命名空间内的 ServiceMonitor。但如果你希望与集群监控基础设施使用同一套 jsonnet 工具链生成可以在自己的 jsonnet spec 中直接声明 ServiceMonitor。完整示例见 examples/additional-namespaces-servicemonitor.jsonnetlocal kp (import kube-prometheus/main.libsonnet) { values:: { common: { namespace: monitoring, }, prometheus:: { namespaces: [my-namespace, my-second-namespace], }, }, exampleApplication: { serviceMonitorMyNamespace: { apiVersion: monitoring.coreos.com/v1, kind: ServiceMonitor, metadata: { name: my-servicemonitor, namespace: my-namespace, }, spec: { jobLabel: app, endpoints: [ { port: http-metrics, }, ], selector: { matchLabels: { app.kubernetes.io/name: myapp, }, }, }, }, }, }; { [00namespace- name]: kp.kubePrometheus[name] for name in std.objectFields(kp.kubePrometheus) } { [0prometheus-operator- name]: kp.prometheusOperator[name] for name in std.objectFields(kp.prometheusOperator) } { [node-exporter- name]: kp.nodeExporter[name] for name in std.objectFields(kp.nodeExporter) } { [kube-state-metrics- name]: kp.kubeStateMetrics[name] for name in std.objectFields(kp.kubeStateMetrics) } { [alertmanager- name]: kp.alertmanager[name] for name in std.objectFields(kp.alertmanager) } { [prometheus- name]: kp.prometheus[name] for name in std.objectFields(kp.prometheus) } { [grafana- name]: kp.grafana[name] for name in std.objectFields(kp.grafana) } { [example-application- name]: kp.exampleApplication[name] for name in std.objectFields(kp.exampleApplication) }该示例与第一步相比仅多了两点改动新增了一个名为exampleApplication的顶层对象用于承载用户自定义的 ServiceMonitor 等应用级资源文件末尾的生成列表中追加了{ [example-application- name]: kp.exampleApplication[name] for name in std.objectFields(kp.exampleApplication) }确保自定义对象也能被渲染成独立的 YAML 文件输出。ServiceMonitor 字段解读与实战参数说明对照示例中的 ServiceMonitor各字段的作用如下字段取值示例说明metadata.namemy-servicemonitorServiceMonitor 资源的名称用于在集群内唯一标识metadata.namespacemy-namespace必须与目标服务所在的命名空间一致且该命名空间必须在第一步的namespaces列表中spec.jobLabelapp指定使用目标 Service 的哪个标签值作为抓取任务的job标签示例中对应 Service 上的app: myapp标签spec.endpoints[].porthttp-metrics指定抓取目标 Service 的哪个端口按端口名匹配不是端口号spec.selector.matchLabelsapp.kubernetes.io/name: myapp通过标签选择器匹配目标 ServicePrometheus 将发现所有带该标签的 Service 的端点被监控 Service 必须带正确的标签示例的selector使用app.kubernetes.io/name: myapp匹配目标 Service而jobLabel: app又要求目标 Service 带有app标签作为 job 名。因此目标 Service 上必须同时存在app: myapp与app.kubernetes.io/name: myapp这两类标签否则 ServiceMonitor 无法选中它抓取也就不会发生。官方文档的原话是确保你的 Service 资源带有正确的标签例如app: myapp因为 Prometheus 依赖 Kubernetes 标签在命名空间内发现资源。作为参考仓库自带的示例应用 examples/example-app/example-app.yaml 中Service 的 selector 与 Deployment 的 Pod 标签都使用了app.kubernetes.io/name: example-app端口命名为webport: 8080、targetPort: web这与 ServiceMonitor 的endpoints[].port按端口名匹配的机制是严格对应的——配置 ServiceMonitor 前务必确认你的 Service 暴露了与endpoints[].port一致的具名端口。验证与故障排查要点应用上述 jsonnet 配置并渲染部署后可以从以下几个层面验证结果RBAC 是否生效确认目标命名空间内已生成prometheus-k8s的Role与RoleBindingkubectl get role,rolebinding -n my-namespace其规则应包含endpointslices/services/pods/ingresses的get/list/watch权限ServiceMonitor 是否被 Operator 接受kubectl get servicemonitor -n my-namespace并检查 Prometheus Operator 日志中是否存在因标签不匹配或 RBAC 缺失导致的报错目标是否出现在 Prometheus 中通过 Prometheus UI 的 Status → Targets 页面查看my-namespace下的目标及其健康状态或在 Prometheus 中执行up{namespacemy-namespace}查询确认。小结扩展 kube-prometheus 的监控范围是一个两步走的过程第一步通过$.values.prometheus.namespaces:追加目标命名空间让 jsonnet 自动生成命名空间级Role/RoleBinding解决 Prometheus 的服务发现权限问题第二步为每个目标命名空间内的服务定义ServiceMonitor并确保 Service 具备匹配的标签与具名端口解决抓什么、从哪个端点抓的问题。两者缺一不可且都以 jsonnet 为单一事实来源与 kube-prometheus 的声明式渲染工具链保持一致。需要更深入的背景知识时可结合 monitoring-other-namespaces.md、monitoring-all-namespaces.md 以及 customizing.md 进一步阅读。赞分享云原生可观测性指标监控监控大盘告警【免费下载链接】kube-prometheusUse Prometheus to monitor Kubernetes and applications running on Kubernetes项目地址https://gitcode.com/gh_mirrors/ku/kube-prometheus点击查看免费下载相关推荐kube-prometheus自定义ServiceMonitor监控特定命名空间应用kube prometheus自定义ServiceMonitor监控特定命名空间应用 1. 痛点与挑战Kubernetes多命名空间监控困境 在复杂的Kub云原生可观测性指标监控监控大盘告警Loop 窗口管理从入门到快捷键定制一次讲透Loop 窗口管理从入门到快捷键定制一次讲透 macOS 桌面上同时开着十几个窗口时最磨人的往往不是写代码而是拖窗口想摆成一半屏得拖到边缘再目测、来回云原生可观测性指标监控监控大盘告警kube-prometheus 全命名空间监控指南使用 all-namespaces mixin 监控集群所有命名空间kube prometheus 全命名空间监控指南使用 all namespaces mixin 监控集群所有命名空间 本指南基于 kube promethe云原生可观测性指标监控监控大盘告警上一篇解锁索尼相机隐藏功能Sony-PMCA-RE逆向工程工具完全指南下一篇告别千篇一律用system24打造专属Discord终端风格界面创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考