使用 kube-prometheus 监控其它命名空间中的应用：RBAC 授权与 ServiceMonitor 配置实战

云原生可观测性指标监控监控大盘告警【免费下载链接】kube-prometheusUse Prometheus to monitor Kubernetes and applications running on Kubernetes项目地址https://gitcode.com/gh_mirrors/ku/kube-prometheus点击查看免费下载本文是 kube-prometheus 官方指南 monitoring-other-namespaces.md 的深化解读。默认部署下 Prometheus 只对default、kube-system以及监控栈自身所在命名空间拥有 RBAC 发现权限本文讲解如何通过 jsonnet 中的prometheus.namespaces变量为任意命名空间生成Role/RoleBinding并结合ServiceMonitor让 Prometheus 采集目标应用指标读完即可在自己的.jsonnet构建脚本中落地一套多命名空间监控方案。为什么需要额外授权默认 RBAC 只覆盖少数命名空间kube-prometheus 采用RBAC 最小授权原则。Prometheus 的 ServiceMonitor 服务发现依赖 prometheus-operator 通过 Kubernetes API 读取目标命名空间中的Service、Pod、EndpointSlice或Endpoints、Ingress等资源而读取这些资源必须要有对应命名空间内的 RBAC 权限。默认情况下这份权限只被授予三个命名空间defaultkube-system监控栈自身所在的命名空间由values.common.namespace决定默认是monitoring这一点可以从源码得到直接印证。在 prometheus.libsonnet 中prometheus组件的默认配置硬编码了这三个命名空间namespaces:: [default, kube-system, defaults.namespace],其中defaults.namespace即为构建时传入的栈部署命名空间。也就是说如果你在任意其他命名空间例如业务应用所在的foo中创建了ServiceMonitor但该命名空间不在授权列表内Prometheus 将无法发现并抓取其中的服务——即使 ServiceMonitor 本身已经创建成功。对应的 RBAC 资源定义位于 prometheus-roleSpecificNamespaces.yamlRole与 prometheus-roleBindingSpecificNamespaces.yamlRoleBinding由make generate构建后静态渲染生成。从渲染结果可以看到prometheus-k8s这一Role在default、kube-system、monitoring三个命名空间各有一份规则覆盖discovery.k8s.io下的endpointslices核心组下的services、podsextensions与networking.k8s.io下的ingressesverbs 均为get、list、watch而RoleBinding则将monitoring命名空间中的prometheus-k8sServiceAccount 绑定到这些Role上。核心变量prometheus.namespaces要监控更多命名空间只需要在 jsonnet 构建脚本里扩充prometheus.namespaces列表。该变量在 prometheus.libsonnet 中被消费构建器会为列表中的每一个命名空间分别生成一份RoleroleSpecificNamespaces和一份RoleBindingroleBindingSpecificNamespaces。其中Role的具体规则还受serviceDiscoveryRole配置影响当serviceDiscoveryRole EndpointSlice默认值时额外授予discovery.k8s.io/endpointslices的get、list、watch权限当serviceDiscoveryRole Endpoints时改为授予核心组的endpoints权限其他取值会直接触发 jsonnet 断言error Invalid serviceDiscoveryRole: ...。无论哪种模式services、pods以及extensions/networking.k8s.io下的ingresses的只读权限始终会被授予。对应RoleBinding的生成逻辑prometheus.libsonnet会为每个命名空间生成一个RoleBinding将prometheus-k8sServiceAccount 绑定到该命名空间内的prometheus-k8sRole上。操作步骤为命名空间foo生成 Role 与 RoleBinding在构建清单时把目标命名空间加入prometheus.namespaces数组即可。下面是与原指南一致、可在真实构建中直接使用的 jsonnet 示例local kp (import kube-prometheus/main.libsonnet) { values:: { common: { namespace: monitoring, }, prometheus:: { namespaces: [default, kube-system, monitoring, foo], }, }, }; { setup/0namespace-namespace: kp.kubePrometheus.namespace } { [setup/prometheus-operator- name]: kp.prometheusOperator[name] for name in std.filter((function(name) name ! serviceMonitor name ! prometheusRule), std.objectFields(kp.prometheusOperator)) } // serviceMonitor and prometheusRule are separated so that they can be created after the CRDs are ready { prometheus-operator-serviceMonitor: kp.prometheusOperator.serviceMonitor } { prometheus-operator-prometheusRule: kp.prometheusOperator.prometheusRule } { kube-prometheus-prometheusRule: kp.kubePrometheus.prometheusRule } { [alertmanager- name]: kp.alertmanager[name] for name in std.objectFields(kp.alertmanager) } { [blackbox-exporter- name]: kp.blackboxExporter[name] for name in std.objectFields(kp.blackboxExporter) } { [grafana- name]: kp.grafana[name] for name in std.objectFields(kp.grafana) } { [kube-state-metrics- name]: kp.kubeStateMetrics[name] for name in std.objectFields(kp.kubeStateMetrics) } { [kubernetes- name]: kp.kubernetesControlPlane[name] for name in std.objectFields(kp.kubernetesControlPlane) } { [node-exporter- name]: kp.nodeExporter[name] for name in std.objectFields(kp.nodeExporter) } { [prometheus- name]: kp.prometheus[name] for name in std.objectFields(kp.prometheus) } { [prometheus-adapter- name]: kp.prometheusAdapter[name] for name in std.objectFields(kp.prometheusAdapter) }几点实操要点务必保留默认的三个命名空间。namespaces是一个完整的替换列表而不是追加操作示例中显式写出了default、kube-system、monitoring再追加foo如果只写[foo]会丢掉基础命名空间的授权。若使用namespaces: [...]:表示追加合并则可以在不重写默认值的前提下增量添加这正是 additional-namespaces.jsonnet 中推荐的做法。构建方式不变将上述 jsonnet 交给jsonnet与jsonnet-bundler渲染成 YAML 后再按 docs/customizing.md 的流程生成manifests目录中的清单并kubectl apply。增量追加更稳妥官方示例 additional-namespaces.jsonnet仓库 examples/additional-namespaces.jsonnet 提供了一个更简洁的增量写法利用 jsonnet 的:字段合并语义在默认三个命名空间之上追加业务命名空间无需手工维护完整列表local 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) }该示例渲染后会为my-namespace与my-second-namespace各生成一份prometheus-k8sRole与RoleBinding与 prometheus-roleSpecificNamespaces.yaml、prometheus-roleBindingSpecificNamespaces.yaml 中已有条目的结构完全一致只是把metadata.namespace替换为目标命名空间。为每个额外命名空间定义 ServiceMonitor有了 RBAC 授权Prometheus 才具备在该命名空间内发现目标的能力但要让指标真正被抓取还必须在目标命名空间中创建ServiceMonitor资源。通常来说为命名空间内的应用创建ServiceMonitor是该命名空间使用者的职责如果希望与整套集群监控基础设施使用同一套 jsonnet 工具链进行生成可以按下面的方式在构建脚本中一并产出。仓库 examples/additional-namespaces-servicemonitor.jsonnet 展示了如何在 jsonnet 中内联定义 ServiceMonitor并随其他组件一起渲染输出local 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) }这个 ServiceMonitor 的关键字段含义如下字段作用示例取值metadata.namespace必须与目标应用所在命名空间一致ServiceMonitor 与目标Service同处一个命名空间my-namespacespec.jobLabel指定从目标 Service 的哪个标签取值作为 Prometheusjob标签appspec.endpoints[].port目标 Service 上承载指标接口的端口名需与 Service 中定义的端口名严格一致http-metricsspec.selector.matchLabels用于匹配目标 Service 的标签选择器决定哪些 Service 被纳入采集app.kubernetes.io/name: myapp重要提醒请确保你的 Service 资源带有正确的标签例如app: myapp或示例中的app.kubernetes.io/name: myapp。Prometheus 正是利用这些 Kubernetes 标签在命名空间内完成服务发现与目标匹配的——如果 Service 缺少与selector对应的标签ServiceMonitor 将永远匹配不到任何端点也就不会有任何抓取任务。ServiceMonitor属于 prometheus-operator 的 CRDmonitoring.coreos.com/v1其 CRD 定义由 manifests/setup/0servicemonitorCustomResourceDefinition.yaml 提供。Prometheus 一侧的serviceMonitorSelector与serviceMonitorNamespaceSelector均为空见 prometheus.libsonnet表示 Prometheus 会选中集群内且自身有权访问的命名空间内所有 ServiceMonitor这也是只需要靠 RBAC 列表来控制可见性的原因。变体一监控全部命名空间需谨慎如果业务上确实需要覆盖整个集群官方提供all-namespacesmixin见 examples/all-namespaces.jsonnet 与 monitoring-all-namespaces.mdlocal kp (import kube-prometheus/main.libsonnet) (import kube-prometheus/addons/all-namespaces.libsonnet) { values:: { common: { namespace: monitoring, }, prometheus: { namespaces: [], }, }, };其底层实现all-namespaces.libsonnet做了两件事在prometheus.clusterRole中追加集群级规则endpointslices、services、endpoints、pods、ingresses的get/list/watch将roleSpecificNamespaces与roleBindingSpecificNamespaces置为null同时把prometheus.namespaces清空避免再为具体命名空间生成重复的 Role/RoleBinding。安全警告这种配置在集群尤其是多租户集群中可能带来安全隐患——它让 Prometheus 对整个集群拥有可见性可能超出某些被安全策略锁定的命名空间的预期。请仅在完全受信的单租户集群中使用并评估合规要求。采用该方案后仍需按上文“为每个额外命名空间定义 ServiceMonitor”一节的方式为实际要监控的服务创建 ServiceMonitor。变体二直接手写 RBAC 清单不使用 jsonnet如果团队不使用 jsonnet 构建流程也可以参考 manifests/prometheus-roleSpecificNamespaces.yaml 中现有的Role模板为每个目标命名空间手工复制一份将metadata.namespace改为目标命名空间再在 manifests/prometheus-roleBindingSpecificNamespaces.yaml 中为每个命名空间添加对应的RoleBindingsubjects固定指向monitoring命名空间下的prometheus-k8sServiceAccountapiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: prometheus-k8s namespace: foo roleRef: apiGroup: rbac.authorization.k8s.io kind: Role name: prometheus-k8s subjects: - kind: ServiceAccount name: prometheus-k8s namespace: monitoring手工维护的缺点是无法随构建流程自动同步新增命名空间时需要人工补两份资源因此官方推荐优先使用 jsonnet 变量方案。验证与故障排查部署完成后可以通过以下方式验证授权是否生效、采集是否正常检查 RBAC 资源是否就位kubectl get role,rolebinding -n foo应能看到prometheus-k8s的Role与RoleBinding。观察 Prometheus 抓取状态进入 Prometheus UI 的Status → Targets页面或执行kubectl -n monitoring exec进入 Prometheus Pod 后查询/api/v1/targets确认my-namespace下出现对应抓取目标且状态为UP。核对 Service 标签若Targets页面始终为空优先检查目标Service的标签是否与ServiceMonitor.spec.selector.matchLabels匹配参见 example-app.yaml 中的 Service 与标签写法。确认 ServiceMonitor 被选中kubectl get servicemonitor -n my-namespace确认资源存在由于 Prometheus 的serviceMonitorSelector/serviceMonitorNamespaceSelector为空只要命名空间在授权列表内即可被自动纳入。相关资源速查指南原文docs/monitoring-other-namespaces.md增量追加命名空间示例examples/additional-namespaces.jsonnet连带 ServiceMonitor 的完整示例examples/additional-namespaces-servicemonitor.jsonnetRBAC 生成逻辑jsonnet/kube-prometheus/components/prometheus.libsonnet全命名空间方案docs/customizations/monitoring-all-namespaces.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云原生可观测性指标监控监控大盘告警kube-prometheus 监控附加命名空间通过 jsonnet 扩展 Prometheus 抓取范围与 ServiceMonitor 实战指南kube prometheus 监控附加命名空间通过 jsonnet 扩展 Prometheus 抓取范围与 ServiceMonitor 实战指南 导读 在云原生可观测性指标监控监控大盘告警kube-prometheus 全命名空间监控指南使用 all-namespaces mixin 监控集群所有命名空间kube prometheus 全命名空间监控指南使用 all namespaces mixin 监控集群所有命名空间 本指南基于 kube promethe云原生可观测性指标监控监控大盘告警上一篇DeepSeek-Reasonix 桌面客户端使用指南预发布版功能与安装教程下一篇XamarinMediaManager API详解掌握音视频播放的全部接口创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考