云原生可观测性【免费下载链接】prometheus-operatorPrometheus Operator creates/configures/manages Prometheus clusters atop Kubernetes项目地址https://gitcode.com/gh_mirrors/pr/prometheus-operator点击查看免费下载本文是 Prometheus Operator 的Platform Guide平台指南基于官方文档 Documentation/platform/platform-guide.md 展开。文章将带领你完成从零部署一套可用的监控栈先为 Prometheus 配置 RBAC 权限并创建首个Prometheus自定义资源再部署高可用的Alertmanager集群最后通过alerting.alertmanagers字段把二者打通让告警真正流动起来。读完本文你将掌握 Prometheus Operator 平台侧部署与集成告警的核心实操能力并理解其底层 CRD 与控制器的工作原理。1. 前置知识Prometheus Operator 与自定义资源Prometheus Operator 是一个 Kubernetes Operator以自定义资源Custom Resources的方式提供 Prometheus 及其相关监控组件的原生部署与管理能力其核心目标包括自动化管理监控目标、通过 Label Selector 抽象 Prometheus 重打标签Relabeling配置、以及简化版本、持久化、保留策略、副本数等基础部署配置。Operator 提供的核心 CRD 包括Prometheus、Alertmanager、ThanosRuler、ServiceMonitor、PodMonitor、Probe、PrometheusRule、AlertmanagerConfig、PrometheusAgent与ScrapeConfig。其中本指南聚焦于其中两个实例型资源Prometheus与Alertmanager。相关资源总览可参考 Documentation/getting-started/introduction.md。如果你还没有接触过 Prometheus Operator建议先阅读 Documentation/getting-started/introduction.md 再继续本指南。2. 部署 Prometheus 实例Prometheus 服务器自身需要通过 Kubernetes API 发现抓取目标Target与 Alertmanager 实例因此在创建Prometheus资源之前必须为 Prometheus 使用的 ServiceAccount 预先配置好 RBAC 授权规则。2.1 创建 ServiceAccount首先为 Prometheus 创建一个ServiceAccountapiVersion: v1 kind: ServiceAccount metadata: name: prometheus该清单与 example/rbac/prometheus/prometheus-service-account.yaml 完全一致。2.2 创建 ClusterRole接下来创建一个ClusterRole授予 Prometheus 在集群内发现并抓取目标所需的必要权限apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: prometheus rules: - apiGroups: [] resources: - nodes - nodes/metrics - services - endpoints - pods verbs: [get, list, watch] - apiGroups: [] resources: - configmaps verbs: [get] - apiGroups: - discovery.k8s.io resources: - endpointslices verbs: [get, list, watch] - apiGroups: - networking.k8s.io resources: - ingresses verbs: [get, list, watch] - nonResourceURLs: [/metrics] verbs: [get]该清单与 example/rbac/prometheus/prometheus-cluster-role.yaml 完全一致各规则的用途可归纳如下nodes、nodes/metrics、services、endpoints、pods的get/list/watch用于 Kubernetes 服务发现Service Discovery这是 Prometheus 发现抓取目标的基础endpointslices支持基于 EndpointSlice 的服务发现ingresses用于从 Ingress 对象中发现抓取目标configmaps的getPrometheus 的 sidecarconfig-reloader需要读取 ConfigMap 中的规则文件rule files非资源 URL/metrics的get允许 Prometheus 抓取 Kubernetes apiserver 自身的/metrics指标。注意因为 Prometheus 只读取而不会修改 Kubernetes API 中的对象所以只需要get、list、watch动作即可。更详细的权限说明参见 Documentation/platform/rbac.md。2.3 创建 ClusterRoleBinding再创建一个ClusterRoleBinding把上面的ClusterRole绑定到 Prometheus 的ServiceAccount上apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: prometheus roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: prometheus subjects: - kind: ServiceAccount name: prometheus namespace: default该清单与 example/rbac/prometheus/prometheus-cluster-role-binding.yaml 完全一致。由于该ClusterRole通常会被多个Prometheus对象复用因此这里使用ClusterRoleBinding而非RoleBinding。注意创建ClusterRole并绑定到 Prometheus Pod 使用的ServiceAccount需要集群管理员权限。Prometheus Pod 使用的ServiceAccount是通过Prometheus对象的spec.serviceAccountName字段指定的。2.4 应用清单并部署 Prometheus 实例将上述三个清单依次应用kubectl apply -f example/rbac/prometheus/prometheus-service-account.yaml kubectl apply -f example/rbac/prometheus/prometheus-cluster-role.yaml kubectl apply -f example/rbac/prometheus/prometheus-cluster-role-binding.yamlRBAC 资源就绪后即可创建最基本的 Prometheus 实例apiVersion: monitoring.coreos.com/v1 kind: Prometheus metadata: name: prometheus spec: serviceAccountName: prometheus这是 example/user-guides/getting-started/prometheus.yaml 的完整内容——一个最小化的Prometheus资源只声明了serviceAccountName字段。Operator 会据此自动生成对应的StatefulSet、Service名为prometheus-operated、Secret包含生成的 Prometheus 配置文件等附属资源。2.5 验证实例运行状态执行以下命令观察Prometheus资源的状态变化kubectl get -n default prometheus prometheus -w-w参数会持续监听资源变化当实例创建成功、Pod 进入 Ready 状态后即可在Status中看到更新信息。更细粒度的验证可以查看对应 StatefulSet 与 Podkubectl get statefulset -l operated-prometheustrue kubectl get pods -l prometheusprometheusPrometheus 生成的 Pod 会带有prometheus: prometheus-name标签例如名为prometheus的实例其 Pod 标签为prometheus: prometheus。在稍后创建Service时这个标签正是 selector 的依据。3. 部署 Alertmanager 集群部署 Alertmanager 同样简单一个最基础的Alertmanager资源即可创建出多副本的高可用集群apiVersion: monitoring.coreos.com/v1 kind: Alertmanager metadata: name: example spec: replicas: 3该清单与 example/user-guides/alerting/alertmanager-example.yaml 完全一致spec.replicas: 3声明了 3 个副本。Operator 会将其物化为一个带 3 副本的StatefulSet并自动为这些副本配置mesh 集群通信端口 9094使 Alertmanager 之间可以互相同步告警状态。等待所有 Alertmanager Pod 就绪kubectl get pods -l alertmanagerexample -w从源码角度看pkg/alertmanager/statefulset.go 中定义了 Alertmanager 的关键端口常量Web 端口为9093alertmanagerWebPortMesh 集群通信端口为9094alertmanagerMeshPort并会在生成 StatefulSet 时同时暴露mesh-tcp与mesh-udp两个端口用于集群内部通信。这就是3 副本 Alertmanager 自动组成集群的底层实现依据。4. 理解 Prometheus 与 Alertmanager 的关系光有 Alertmanager 集群本身并没有实际价值——Alertmanager 的职责是接收来自 Prometheus 的告警并在此基础上提供去重Deduplicate对 Prometheus 发来的重复告警进行合并静默Silence在指定时间窗口内抑制特定告警路由与分组通知Routing Grouping将告警按规则分组并通过 PagerDuty、OpsGenie、邮件、聊天工具等各类集成渠道发送通知。因此要让 Alertmanager 发挥作用必须把它与 Prometheus 集成起来让 Prometheus 知道把告警发给谁。5. 将 Alertmanager 集成到 Prometheus集成过程分为两步先把 Alertmanager 服务暴露出来再在Prometheus资源中声明alerting.alertmanagers配置。5.1 暴露 Alertmanager 服务要访问 Alertmanager 的 Web 界面需要把服务暴露到集群外部。为了简单起见这里使用NodePort类型的ServiceapiVersion: v1 kind: Service metadata: name: alertmanager-example spec: type: NodePort ports: - name: web nodePort: 30903 port: 9093 protocol: TCP targetPort: web selector: alertmanager: example该清单与 example/user-guides/alerting/alertmanager-example-service.yaml 完全一致关键点在于selector: alertmanager: example必须与Alertmanager资源名对应——Operator 生成的 Alertmanager Pod 带有alertmanager: alertmanager-name标签这里的example正是前面Alertmanager对象的名字targetPort: web引用的是容器端口的名称即 Alertmanager 的 9093 Web 端口nodePort: 30903固定了节点上的外部端口。Service 创建成功后Alertmanager 的 Web 服务器即可通过节点的 IP 地址与端口30903访问http://node-ip:30903/。注意这种直接暴露 Alertmanager Web 服务器的方式在生产环境中可能并不合适。更多暴露方案ClusterIP Kubernetes API 代理、Ingress 等请参考 Documentation/platform/exposing-prometheus-and-alertmanager.md。5.2 在 Prometheus 中配置 Alertmanager此时 Alertmanager 集群已完全可用且具备高可用能力但还没有任何告警会发给它。接下来创建一个会向该 Alertmanager 集群发送告警的 Prometheus 实例apiVersion: monitoring.coreos.com/v1 kind: Prometheus metadata: name: example spec: serviceAccountName: prometheus replicas: 2 alerting: alertmanagers: - namespace: default name: alertmanager-example port: web这是 example/user-guides/alerting/prometheus-example.yaml 的核心告警配置片段。Prometheus资源会通过alerting.alertmanagers列表发现前面创建的Service背后的所有Alertmanager 实例——注意name、namespace、port三个字段必须与 AlertmanagerService的定义完全匹配name: alertmanager-example对应 Service 的名称namespace: default对应 Service 所在的命名空间port: web对应 Service 端口名称web9093。从 API 定义看pkg/apis/monitoring/v1/prometheus_types.go 中PrometheusSpec的Alertmanagers []AlertmanagerEndpoints字段即承载此配置其注释明确说明这是Prometheus 应向哪些 alertmanager endpoints 发送告警的选择器列表。5.3 验证集成结果打开 Prometheus 的 Web 界面进入Status Runtime Build Information页面检查 Prometheus 是否已发现 3 个 Alertmanager 实例对应 3 副本的StatefulSet。如果一切正常就说明 Prometheus 已把 Alertmanager 集群作为告警接收端纳管后续通过PrometheusRule定义的告警规则一旦触发就会按 Alertmanager 的路由与通知配置分发出去。6. 更深一层Operator 的告警发现机制从实现层面看alerting.alertmanagers之所以能自动发现多个实例是因为 Operator 在生成 Prometheus 配置时会根据该字段解析出一个可用的 Alertmanager 服务端点列表并将其写入 Prometheus 的alertmanager_config。当Service后面有多个 Pod 时例如这里 3 副本的 AlertmanagerPrometheus 会把告警负载均衡地发送给集群中的各个成员从而实现告警投递的高可用。AlertmanagerEndpoints类型还支持更多高级字段如scheme、pathPrefix、apiVersion、bearerTokenFile、tlsConfig等可用于自定义告警投递的协议、路径与认证方式具体字段定义同样位于 pkg/apis/monitoring/v1/prometheus_types.go 附近需要更精细控制时可查阅 API 参考 Documentation/api-reference/api.md。7. 补充Prometheus 与 Alertmanager 的多种暴露方式本文使用了最简单的NodePort方式暴露服务。在真实生产环境中还可以根据场景选择以下方式详见 Documentation/platform/exposing-prometheus-and-alertmanager.mdKubernetes API 代理创建ClusterIP类型的 Service借助kubectl proxy通过http://127.0.0.1:8001/api/v1/proxy/namespaces/namespace/services/service-name:port/访问。此时需要在Prometheus/Alertmanager资源中配置spec.externalUrl指向完整的外部访问 URLIngress为内部ClusterIPService 创建 Ingress 规则将/prometheus、/alertmanager等路径路由到对应的监控服务同样需要配合spec.externalUrl使用。若 Ingress 暴露在公网务必启用外部认证或 IP 白名单等访问控制。无论采用哪种方式spec.externalUrl都必须与实际的访问地址保持一致否则 Prometheus / Alertmanager Web 界面中的链接与回调地址会出现错乱。8. 小结至此你已完成 Prometheus Operator 平台侧的完整入门链路通过ServiceAccountClusterRoleClusterRoleBinding为 Prometheus 配置了服务发现所需的 RBAC 权限创建了最小化的Prometheus资源并验证其运行状态部署了 3 副本的Alertmanager高可用集群通过NodePortService 暴露 Alertmanager并在Prometheus资源的spec.alerting.alertmanagers中完成告警链路集成最终在 Prometheus Web 界面确认实例发现成功。下一步你可以结合 Documentation/getting-started/introduction.md 中提到的ServiceMonitor、PodMonitor、PrometheusRule等资源为应用配置抓取目标与告警规则或参考 Documentation/user-guides/basic-auth.md 等用户指南完善认证与安全配置将这套监控栈真正落地到生产环境。赞分享云原生可观测性【免费下载链接】prometheus-operatorPrometheus Operator creates/configures/manages Prometheus clusters atop Kubernetes项目地址https://gitcode.com/gh_mirrors/pr/prometheus-operator点击查看免费下载相关推荐Prometheus Operator 入门指南在 Kubernetes 上轻松部署 Prometheus 监控系统Prometheus Operator 入门指南在 Kubernetes 上轻松部署 Prometheus 监控系统 前言 在现代云原生环境中监控是确保系统云原生可观测性Prometheus-Operator实战部署指南Prometheus Operator实战部署指南 本文详细介绍了在生产环境中部署和配置Prometheus Operator的完整流程。内容涵盖环境准备与Ku云原生可观测性使用 Helm 在 Kubernetes 上为 Prometheus 部署 Thanos Sidecar 实战指南使用 Helm 在 Kubernetes 上为 Prometheus 部署 Thanos Sidecar 实战指南 本指南围绕仓库中 tutorials/kub可观测性云原生时序数据库运维上一篇告别磁盘空间焦虑Git History缓存清理全指南下一篇FanControl 风扇控制软件入门指南三步画好转速曲线让风扇安静下来创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Prometheus Operator 平台部署指南：在 Kubernetes 上部署 Prometheus 与 Alertmanager 实例
云原生可观测性【免费下载链接】prometheus-operatorPrometheus Operator creates/configures/manages Prometheus clusters atop Kubernetes项目地址https://gitcode.com/gh_mirrors/pr/prometheus-operator点击查看免费下载本文是 Prometheus Operator 的Platform Guide平台指南基于官方文档 Documentation/platform/platform-guide.md 展开。文章将带领你完成从零部署一套可用的监控栈先为 Prometheus 配置 RBAC 权限并创建首个Prometheus自定义资源再部署高可用的Alertmanager集群最后通过alerting.alertmanagers字段把二者打通让告警真正流动起来。读完本文你将掌握 Prometheus Operator 平台侧部署与集成告警的核心实操能力并理解其底层 CRD 与控制器的工作原理。1. 前置知识Prometheus Operator 与自定义资源Prometheus Operator 是一个 Kubernetes Operator以自定义资源Custom Resources的方式提供 Prometheus 及其相关监控组件的原生部署与管理能力其核心目标包括自动化管理监控目标、通过 Label Selector 抽象 Prometheus 重打标签Relabeling配置、以及简化版本、持久化、保留策略、副本数等基础部署配置。Operator 提供的核心 CRD 包括Prometheus、Alertmanager、ThanosRuler、ServiceMonitor、PodMonitor、Probe、PrometheusRule、AlertmanagerConfig、PrometheusAgent与ScrapeConfig。其中本指南聚焦于其中两个实例型资源Prometheus与Alertmanager。相关资源总览可参考 Documentation/getting-started/introduction.md。如果你还没有接触过 Prometheus Operator建议先阅读 Documentation/getting-started/introduction.md 再继续本指南。2. 部署 Prometheus 实例Prometheus 服务器自身需要通过 Kubernetes API 发现抓取目标Target与 Alertmanager 实例因此在创建Prometheus资源之前必须为 Prometheus 使用的 ServiceAccount 预先配置好 RBAC 授权规则。2.1 创建 ServiceAccount首先为 Prometheus 创建一个ServiceAccountapiVersion: v1 kind: ServiceAccount metadata: name: prometheus该清单与 example/rbac/prometheus/prometheus-service-account.yaml 完全一致。2.2 创建 ClusterRole接下来创建一个ClusterRole授予 Prometheus 在集群内发现并抓取目标所需的必要权限apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: prometheus rules: - apiGroups: [] resources: - nodes - nodes/metrics - services - endpoints - pods verbs: [get, list, watch] - apiGroups: [] resources: - configmaps verbs: [get] - apiGroups: - discovery.k8s.io resources: - endpointslices verbs: [get, list, watch] - apiGroups: - networking.k8s.io resources: - ingresses verbs: [get, list, watch] - nonResourceURLs: [/metrics] verbs: [get]该清单与 example/rbac/prometheus/prometheus-cluster-role.yaml 完全一致各规则的用途可归纳如下nodes、nodes/metrics、services、endpoints、pods的get/list/watch用于 Kubernetes 服务发现Service Discovery这是 Prometheus 发现抓取目标的基础endpointslices支持基于 EndpointSlice 的服务发现ingresses用于从 Ingress 对象中发现抓取目标configmaps的getPrometheus 的 sidecarconfig-reloader需要读取 ConfigMap 中的规则文件rule files非资源 URL/metrics的get允许 Prometheus 抓取 Kubernetes apiserver 自身的/metrics指标。注意因为 Prometheus 只读取而不会修改 Kubernetes API 中的对象所以只需要get、list、watch动作即可。更详细的权限说明参见 Documentation/platform/rbac.md。2.3 创建 ClusterRoleBinding再创建一个ClusterRoleBinding把上面的ClusterRole绑定到 Prometheus 的ServiceAccount上apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: prometheus roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: prometheus subjects: - kind: ServiceAccount name: prometheus namespace: default该清单与 example/rbac/prometheus/prometheus-cluster-role-binding.yaml 完全一致。由于该ClusterRole通常会被多个Prometheus对象复用因此这里使用ClusterRoleBinding而非RoleBinding。注意创建ClusterRole并绑定到 Prometheus Pod 使用的ServiceAccount需要集群管理员权限。Prometheus Pod 使用的ServiceAccount是通过Prometheus对象的spec.serviceAccountName字段指定的。2.4 应用清单并部署 Prometheus 实例将上述三个清单依次应用kubectl apply -f example/rbac/prometheus/prometheus-service-account.yaml kubectl apply -f example/rbac/prometheus/prometheus-cluster-role.yaml kubectl apply -f example/rbac/prometheus/prometheus-cluster-role-binding.yamlRBAC 资源就绪后即可创建最基本的 Prometheus 实例apiVersion: monitoring.coreos.com/v1 kind: Prometheus metadata: name: prometheus spec: serviceAccountName: prometheus这是 example/user-guides/getting-started/prometheus.yaml 的完整内容——一个最小化的Prometheus资源只声明了serviceAccountName字段。Operator 会据此自动生成对应的StatefulSet、Service名为prometheus-operated、Secret包含生成的 Prometheus 配置文件等附属资源。2.5 验证实例运行状态执行以下命令观察Prometheus资源的状态变化kubectl get -n default prometheus prometheus -w-w参数会持续监听资源变化当实例创建成功、Pod 进入 Ready 状态后即可在Status中看到更新信息。更细粒度的验证可以查看对应 StatefulSet 与 Podkubectl get statefulset -l operated-prometheustrue kubectl get pods -l prometheusprometheusPrometheus 生成的 Pod 会带有prometheus: prometheus-name标签例如名为prometheus的实例其 Pod 标签为prometheus: prometheus。在稍后创建Service时这个标签正是 selector 的依据。3. 部署 Alertmanager 集群部署 Alertmanager 同样简单一个最基础的Alertmanager资源即可创建出多副本的高可用集群apiVersion: monitoring.coreos.com/v1 kind: Alertmanager metadata: name: example spec: replicas: 3该清单与 example/user-guides/alerting/alertmanager-example.yaml 完全一致spec.replicas: 3声明了 3 个副本。Operator 会将其物化为一个带 3 副本的StatefulSet并自动为这些副本配置mesh 集群通信端口 9094使 Alertmanager 之间可以互相同步告警状态。等待所有 Alertmanager Pod 就绪kubectl get pods -l alertmanagerexample -w从源码角度看pkg/alertmanager/statefulset.go 中定义了 Alertmanager 的关键端口常量Web 端口为9093alertmanagerWebPortMesh 集群通信端口为9094alertmanagerMeshPort并会在生成 StatefulSet 时同时暴露mesh-tcp与mesh-udp两个端口用于集群内部通信。这就是3 副本 Alertmanager 自动组成集群的底层实现依据。4. 理解 Prometheus 与 Alertmanager 的关系光有 Alertmanager 集群本身并没有实际价值——Alertmanager 的职责是接收来自 Prometheus 的告警并在此基础上提供去重Deduplicate对 Prometheus 发来的重复告警进行合并静默Silence在指定时间窗口内抑制特定告警路由与分组通知Routing Grouping将告警按规则分组并通过 PagerDuty、OpsGenie、邮件、聊天工具等各类集成渠道发送通知。因此要让 Alertmanager 发挥作用必须把它与 Prometheus 集成起来让 Prometheus 知道把告警发给谁。5. 将 Alertmanager 集成到 Prometheus集成过程分为两步先把 Alertmanager 服务暴露出来再在Prometheus资源中声明alerting.alertmanagers配置。5.1 暴露 Alertmanager 服务要访问 Alertmanager 的 Web 界面需要把服务暴露到集群外部。为了简单起见这里使用NodePort类型的ServiceapiVersion: v1 kind: Service metadata: name: alertmanager-example spec: type: NodePort ports: - name: web nodePort: 30903 port: 9093 protocol: TCP targetPort: web selector: alertmanager: example该清单与 example/user-guides/alerting/alertmanager-example-service.yaml 完全一致关键点在于selector: alertmanager: example必须与Alertmanager资源名对应——Operator 生成的 Alertmanager Pod 带有alertmanager: alertmanager-name标签这里的example正是前面Alertmanager对象的名字targetPort: web引用的是容器端口的名称即 Alertmanager 的 9093 Web 端口nodePort: 30903固定了节点上的外部端口。Service 创建成功后Alertmanager 的 Web 服务器即可通过节点的 IP 地址与端口30903访问http://node-ip:30903/。注意这种直接暴露 Alertmanager Web 服务器的方式在生产环境中可能并不合适。更多暴露方案ClusterIP Kubernetes API 代理、Ingress 等请参考 Documentation/platform/exposing-prometheus-and-alertmanager.md。5.2 在 Prometheus 中配置 Alertmanager此时 Alertmanager 集群已完全可用且具备高可用能力但还没有任何告警会发给它。接下来创建一个会向该 Alertmanager 集群发送告警的 Prometheus 实例apiVersion: monitoring.coreos.com/v1 kind: Prometheus metadata: name: example spec: serviceAccountName: prometheus replicas: 2 alerting: alertmanagers: - namespace: default name: alertmanager-example port: web这是 example/user-guides/alerting/prometheus-example.yaml 的核心告警配置片段。Prometheus资源会通过alerting.alertmanagers列表发现前面创建的Service背后的所有Alertmanager 实例——注意name、namespace、port三个字段必须与 AlertmanagerService的定义完全匹配name: alertmanager-example对应 Service 的名称namespace: default对应 Service 所在的命名空间port: web对应 Service 端口名称web9093。从 API 定义看pkg/apis/monitoring/v1/prometheus_types.go 中PrometheusSpec的Alertmanagers []AlertmanagerEndpoints字段即承载此配置其注释明确说明这是Prometheus 应向哪些 alertmanager endpoints 发送告警的选择器列表。5.3 验证集成结果打开 Prometheus 的 Web 界面进入Status Runtime Build Information页面检查 Prometheus 是否已发现 3 个 Alertmanager 实例对应 3 副本的StatefulSet。如果一切正常就说明 Prometheus 已把 Alertmanager 集群作为告警接收端纳管后续通过PrometheusRule定义的告警规则一旦触发就会按 Alertmanager 的路由与通知配置分发出去。6. 更深一层Operator 的告警发现机制从实现层面看alerting.alertmanagers之所以能自动发现多个实例是因为 Operator 在生成 Prometheus 配置时会根据该字段解析出一个可用的 Alertmanager 服务端点列表并将其写入 Prometheus 的alertmanager_config。当Service后面有多个 Pod 时例如这里 3 副本的 AlertmanagerPrometheus 会把告警负载均衡地发送给集群中的各个成员从而实现告警投递的高可用。AlertmanagerEndpoints类型还支持更多高级字段如scheme、pathPrefix、apiVersion、bearerTokenFile、tlsConfig等可用于自定义告警投递的协议、路径与认证方式具体字段定义同样位于 pkg/apis/monitoring/v1/prometheus_types.go 附近需要更精细控制时可查阅 API 参考 Documentation/api-reference/api.md。7. 补充Prometheus 与 Alertmanager 的多种暴露方式本文使用了最简单的NodePort方式暴露服务。在真实生产环境中还可以根据场景选择以下方式详见 Documentation/platform/exposing-prometheus-and-alertmanager.mdKubernetes API 代理创建ClusterIP类型的 Service借助kubectl proxy通过http://127.0.0.1:8001/api/v1/proxy/namespaces/namespace/services/service-name:port/访问。此时需要在Prometheus/Alertmanager资源中配置spec.externalUrl指向完整的外部访问 URLIngress为内部ClusterIPService 创建 Ingress 规则将/prometheus、/alertmanager等路径路由到对应的监控服务同样需要配合spec.externalUrl使用。若 Ingress 暴露在公网务必启用外部认证或 IP 白名单等访问控制。无论采用哪种方式spec.externalUrl都必须与实际的访问地址保持一致否则 Prometheus / Alertmanager Web 界面中的链接与回调地址会出现错乱。8. 小结至此你已完成 Prometheus Operator 平台侧的完整入门链路通过ServiceAccountClusterRoleClusterRoleBinding为 Prometheus 配置了服务发现所需的 RBAC 权限创建了最小化的Prometheus资源并验证其运行状态部署了 3 副本的Alertmanager高可用集群通过NodePortService 暴露 Alertmanager并在Prometheus资源的spec.alerting.alertmanagers中完成告警链路集成最终在 Prometheus Web 界面确认实例发现成功。下一步你可以结合 Documentation/getting-started/introduction.md 中提到的ServiceMonitor、PodMonitor、PrometheusRule等资源为应用配置抓取目标与告警规则或参考 Documentation/user-guides/basic-auth.md 等用户指南完善认证与安全配置将这套监控栈真正落地到生产环境。赞分享云原生可观测性【免费下载链接】prometheus-operatorPrometheus Operator creates/configures/manages Prometheus clusters atop Kubernetes项目地址https://gitcode.com/gh_mirrors/pr/prometheus-operator点击查看免费下载相关推荐Prometheus Operator 入门指南在 Kubernetes 上轻松部署 Prometheus 监控系统Prometheus Operator 入门指南在 Kubernetes 上轻松部署 Prometheus 监控系统 前言 在现代云原生环境中监控是确保系统云原生可观测性Prometheus-Operator实战部署指南Prometheus Operator实战部署指南 本文详细介绍了在生产环境中部署和配置Prometheus Operator的完整流程。内容涵盖环境准备与Ku云原生可观测性使用 Helm 在 Kubernetes 上为 Prometheus 部署 Thanos Sidecar 实战指南使用 Helm 在 Kubernetes 上为 Prometheus 部署 Thanos Sidecar 实战指南 本指南围绕仓库中 tutorials/kub可观测性云原生时序数据库运维上一篇告别磁盘空间焦虑Git History缓存清理全指南下一篇FanControl 风扇控制软件入门指南三步画好转速曲线让风扇安静下来创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考