从零开始：ACK Serverless 集群的监控方案设计指南-51CTO.COM

引言

为什么前面用的好好的 Kube-prometheus-stack 好好的，不用了，要使用 Prometheus-Operator 呢？

首先，先介绍下我们的基本环境，我现在使用的集群是我们公司的 Test 环境的集群，托管在阿里云里面的 ACK Serverless 集群，对于业界开箱即用的一些监控生态工具，是很难做到全方面监控的。所以，我这边想要去做一套针对 ACK Serverless 集群的监控方案，但是这个肯定需要一些时间来好好研究的。

其次，我们前面讲解到了我们的自动化报告生成，生成的报告，里面的数据不是我们想要的。我是用 Kube-Prometheus-stack 的 Chart 包部署的，有的数据不全，因为这个包当时是我们团队的另外一个人负责的，而且目前这个监控方案后面还会涉及到生产环境。所以，我这边打算把之前部署的删除了，准备使用 Prometheus-Operator，重新设计一套监控方案，重新深入贯穿下 Prometheus 的生态。

为什么呢？我们来先详细认识下 ACK Serverless 集群

ACK Serverless

• ACK Serverless 集群是一种 "无服务器" 的 Kubernetes 集群，即用户无需管理底层的节点资源（如 EC2 或 ECS 实例），系统会根据用户的实际负载动态调度容器到后端资源。

• 用户只需专注于工作负载的部署和业务逻辑，而不需要手动管理集群中的节点。

架构核心：

• 它基于阿里云 Elastic Container Instance (ECI)，用以提供容器运行的计算资源。

• 每个 Pod 都会被调度到 ECI 中运行，而不是固定的节点。

主要特点

无需节点管理

• ACK Serverless 集群不需要管理 Kubernetes 节点（如虚拟机或物理机）。

• 用户不需要担心节点的扩容、缩容、健康检查等复杂运维工作。

按需扩展

• Pod 在工作负载增加时动态启动，直接使用阿里云 ECI 作为后端资源。

• 当负载减少时，Pod 会被回收，避免资源浪费。

秒级弹性

• Pod 启动基于 ECI，启动速度极快（通常几秒钟）。

• 非常适合运行短期或突发性的工作负载。

原生 Kubernetes 支持

• 兼容 Kubernetes 生态系统和原生 API。

• 支持 Helm、Kubectl 等 Kubernetes 工具。

高性价比

• 资源按实际使用计费，不使用时不产生费用。

• 无需为空闲节点支付费用。

资源隔离

• 每个 Pod 是独立运行的，与其他用户隔离。

• 支持阿里云 VPC 网络，安全可靠。

核心组件与工作原理

核心组件

ACK Serverless Control Plane：

• 负责管理 Kubernetes API 和调度逻辑。

• 无需用户手动操作，阿里云托管。

Elastic Container Instance (ECI)：

• 提供 Pod 的计算和存储资源。

• 动态为每个 Pod 分配资源，按需计费。

Serverless Pod：

• 工作负载直接以 Pod 的形式运行在 ECI 上。

• 支持容器镜像、存储卷挂载、网络配置等功能。

工作原理

1. 用户创建 Serverless Pod 或通过 Deployment 等资源部署工作负载。

2. ACK Serverless 的调度器会将 Pod 动态分配到 ECI 资源中运行。

3. 如果没有足够的资源，系统会自动扩展 ECI 实例。

4. 任务完成后，Pod 会被释放，资源将被回收。

我们这里还需要学习下 ECI (Elastic Container Instance)

Elastic Container Instance (ECI)

ECI 是阿里云提供的一种按需运行容器的服务，无需管理底层计算资源。ECI 直接运行容器任务，不依赖虚拟机或物理机，用户只需要关注容器镜像、运行配置以及资源需求。

简单来说，ECI 是一种 Serverless 容器运行平台，它提供了类似虚拟机的运行环境，但用户不需要关心服务器的管理和运维。

ECI 的核心特点

无服务器

• 无需配置或管理底层的节点（ECS 实例）。

• 容器实例直接运行在阿里云托管的基础设施上。

按需启动

• 容器实例在用户请求时按需启动，支持秒级启动。

• 无需提前分配资源，避免闲置成本。

弹性扩展

• 容器实例会根据负载动态扩展（水平扩展或缩容）。

• 适合突发性和高弹性负载需求。

支持原生容器生态

• 完全兼容 OCI（Open Container Initiative）容器镜像。

• 可以通过 Docker CLI 或 Kubernetes API 部署和管理容器。

与阿里云服务的深度集成

• 支持 VPC（专有网络）、NAS（网络存储）、OSS（对象存储）等阿里云服务。

• 可以结合云监控、日志服务进行容器状态和性能监控。

ECI 和 ACK Serverless 的关系

ACK Serverless 是基于 ECI 构建的

• ACK Serverless 集群使用 ECI 作为其底层计算资源。Serverless Pod 会被调度到 ECI 上运行，而不需要管理任何节点。

• 区别在于：

a.ECI 是单独运行的容器实例，更类似于“裸容器”。

b.ACK Serverless 提供了 Kubernetes 的调度和管理能力，用户可以通过 Kubernetes 的 Deployment、Service 等资源来管理工作负载。

使用方式的不同

• 直接使用 ECI：

a.适用于需要直接运行容器任务的场景，如事件驱动的任务、短期批量任务。

b.可以通过 ECI 的 API、CLI 或阿里云控制台启动容器。

• 通过 ACK Serverless 使用 ECI：

• 适合需要完整 Kubernetes 管理能力的场景。

• 用户可以部署复杂的 Kubernetes 工作负载（如 Deployment、StatefulSet）。

• ACK Serverless 集群自动将工作负载映射到 ECI 上运行。

弹性与扩展对比

特性	ECI	ACK Serverless 集群
部署方式	直接运行容器实例	使用 Kubernetes 的 Pod 调度
弹性调度	按需创建容器	自动通过 Kubernetes 调度到 ECI
管理复杂性	低	较高（但 Kubernetes 提供更多能力)
计费	按容器实例计费	按 Serverless Pod 计费

ECI 和传统 ECS 的对比

特性	Elastic Container Instance (ECI)	Elastic Compute Service (ECS)
运维需求	无需管理节点	需要手动管理节点
启动时间	秒级	分钟级
计费模式	按秒级付费，资源消耗即付费	按小时或按月计费
弹性扩展	自动按需扩展，任务完成后自动释放	需要手动扩展和释放
适用场景	短期任务、事件驱动、弹性工作负载	长期稳定运行的服务

我们再了解下真正要操作的对象：

Virtual Kubelet

图片

Virtual Kubelet 是一个开源项目，允许 Kubernetes 将其节点扩展到其他服务（如服务器无关的容器实例、边缘设备等）。由于这些节点并非实际的物理或虚拟机，传统的监控方法（如通过 Node Exporter 或直接访问 Kubelet 的 /metrics 接口）可能不适用。

它并不是一个真正的物理节点或虚拟机，而是一个代理，通常用于将 Kubernetes 节点扩展到其他服务（如阿里云 ECI、Azure ACI、AWS Fargate）。

虚拟节点并没有底层的操作系统环境，也无法暴露 /proc 或 /sys 文件系统。

介绍

Prometheus 是一种开源的监控和警报工具，用于收集和记录应用程序和系统的度量数据。它特别适用于在 Kubernetes 集群中监控容器化应用程序。Kubernetes 集群中通常与 Prometheus 一起使用的组件是 Prometheus Operator 和 Grafana。

以下是在 Kubernetes 中使用 Prometheus 的主要步骤：

• 安装 Prometheus Operator： Prometheus Operator 是一种 Kubernetes 控制器，用于简化 Prometheus 的部署和管理。您可以通过在 Kubernetes 中部署 Prometheus Operator 来自动设置和管理 Prometheus 实例。

• 配置 Prometheus 实例： Prometheus Operator 将通过 Kubernetes 的自定义资源定义（CRD）创建和管理 Prometheus 实例。您可以使用 PrometheusRule CRD 定义监控规则，并使用 ServiceMonitor CRD 定义需要监控的目标（例如 Kubernetes 服务）。

• 配置和导入 Dashboard： Grafana 通常与 Prometheus 一起使用，用于可视化监控指标。您可以在 Grafana 中导入 Prometheus 的预定义仪表板或自定义仪表板来查看和分析度量数据。

• 监控应用程序和系统： Prometheus 通过 HTTP 端点从目标应用程序和系统中拉取度量数据。您可以在应用程序中暴露 Prometheus 格式的度量数据，并在 ServiceMonitor 中定义用于监控的目标。

• 警报配置： Prometheus 还支持配置警报规则，以便在达到特定阈值或条件时触发警报。警报规则可以定义为 PrometheusRule CRD。

常见的几款监控工具

以下这些工具可以用于在 Kubernetes 集群中实现监控和指标收集，以便于监视集群中的各种资源和应用的性能。

• Heapster： Heapster 是一个 Kubernetes 集群的资源监控工具，用于收集和汇总资源使用情况数据，如 CPU、内存、网络等。

• Metrics Server： Metrics Server 是 Kubernetes 官方提供的一个轻量级指标收集器，用于提供节点和 Pod 等资源的实时性能指标，可以用于水平自动扩展等。

• Prometheus Operator： Prometheus Operator 是一个 Kubernetes 控制器，用于管理和部署 Prometheus 和相关的监控组件。它可以自动创建和管理 Prometheus 实例、ServiceMonitor 和其他配置。

• kube-prometheus 或 kube-prometheus-stack：这是一个基于 Prometheus 的 Kubernetes 集群监控解决方案。它包含了一系列组件，用于部署和管理 Prometheus、Alertmanager、Grafana 等，以实现对 Kubernetes 集群和应用的全面监控。

heapster-》metrics-server-》prometheus-operator -》kube-prometheus-》kube-prometheus-stack

1）kube-prometheus 和 kube-prometheus-stack 区别

• "kube-prometheus" 和 "kube-prometheus-stack" 本质上是同一个项目，只是在不同的时间和版本中使用了不同的名称。"kube-prometheus-stack" 是 "kube-prometheus" 项目的更新版本，它提供了更多的功能、改进和修复。

• 最初，项目被称为 "kube-prometheus"，但随着时间的推移，项目团队对项目进行了大量的改进和扩展，并将其重命名为 "kube-prometheus-stack"，以更好地反映其提供的综合性监控解决方案。

• "kube-prometheus-stack"（或简称 "kube-prometheus"）是一个在 Kubernetes 集群中部署和管理 Prometheus 监控系统以及相关组件的综合解决方案。它集成了 Prometheus、Grafana、Alertmanager 等一系列组件，还包括预配置的监控规则和仪表盘，以及一键部署功能。用户可以通过部署 "kube-prometheus-stack" 来快速启动一个全面的 Kubernetes 集群监控系统，无需逐个配置各个组件。

• 总结起来，"kube-prometheus-stack" 是 "kube-prometheus" 项目的更新版本，提供更多的功能和改进，是一个便捷的综合性监控解决方案，适合在 Kubernetes 环境中快速部署和使用。

2）Prometheus Operator 和 Kube-orometheus 或 Kube-prometheus-stack 对比

"Prometheus Operator" 和 "kube-prometheus"（或 "kube-prometheus-stack"）都是用于在 Kubernetes 集群中部署和管理 Prometheus 监控系统的工具。它们有一些相似之处，但也存在一些区别。以下是它们的主要特点和区别的对比：

Prometheus Operator：

• 核心功能： Prometheus Operator 是一个 Kubernetes 控制器，专门用于管理 Prometheus 和相关组件的配置和部署。它自动创建和管理 Prometheus 实例、ServiceMonitor、Alertmanager、PrometheusRule 等 Kubernetes 资源。

• 声明式配置： Prometheus Operator 通过自定义资源定义（Custom Resource Definitions，CRDs）来实现声明式配置。您可以创建 Prometheus、ServiceMonitor 等资源对象来定义监控配置，Operator 会根据这些定义自动创建和维护相关的资源。

• 自动发现： Prometheus Operator 支持自动发现 Kubernetes 中的 Service、Pod、Namespace 等资源，无需手动配置每个监控目标。

• 生态系统整合： Prometheus Operator 集成了 Grafana 和 Alertmanager，并可以轻松与其他监控工具集成。

• 灵活性： Prometheus Operator 允许根据不同的需求和配置选择性地部署多个 Prometheus 实例，每个实例可以针对特定的监控任务进行配置。

Kube-prometheus 或 Kube-prometheus-stack：

• 综合解决方案： kube-prometheus（或 kube-prometheus-stack）是一个完整的监控解决方案，集成了 Prometheus、Grafana、Alertmanager 等一系列组件，以及一些预配置的监控规则和仪表盘。

• 快速启动： kube-prometheus 提供了一键式的部署方式，适合快速启动一个完整的监控系统，无需逐个配置各个组件。

• 预配置规则和仪表盘： kube-prometheus 提供了一些默认的监控规则和 Grafana 仪表盘，可以快速启用监控功能。

• 集成和扩展：由于 kube-prometheus 集成了多个组件，您可以使用这个解决方案来快速部署一个全面的监控系统，并且可以根据需要进行定制和扩展。

综合来看，Prometheus Operator 专注于 Prometheus 和相关资源的管理和自动化配置，而 kube-prometheus 或 kube-prometheus-stack 则是一个更加综合的解决方案，适合快速启动一个完整的监控系统，尤其对于刚开始使用 Prometheus 的用户来说，可以减少配置的复杂性。您可以根据实际需求和情况选择合适的工具。

Prometheus Operator 的工作原理

Operator 是由 CoreOS 公司开发的，用来扩展 Kubernetes API，特定的应用程序控制器，它用来创建、配置和管理复杂的有状态应用，如数据库、缓存和监控系统。Operator 基于 Kubernetes 的资源和控制器概念之上构建，但同时又包含了应用程序特定的一些专业知识，比如创建一个数据库的Operator，则必须对创建的数据库的各种运维方式非常了解，创建 Operator 的关键是 CRD（自定义资源）的设计。

CRD 是对 Kubernetes API 的扩展，Kubernetes 中的每个资源都是一个 API 对象的集合，例如我们在YAML文件里定义的那些 spec 都是对 Kubernetes 中的资源对象的定义，所有的自定义资源可以跟 Kubernetes 中内建的资源一样使用 kubectl 操作。

Operator 是将运维人员对软件操作的知识给代码化，同时利用 Kubernetes 强大的抽象来管理大规模的软件应用。目前 CoreOS 官方提供了几种 Operator 的实现，其中就包括我们今天的主角：Prometheus Operator，Operator 的核心实现就是基于 Kubernetes 的以下两个概念：

• 资源：对象的状态定义

• 控制器：观测、分析和行动，以调节资源的分布

从概念上来讲 Operator 就是针对管理特定应用程序的，在 Kubernetes 基本的 Resource 和 Controller 的概念上，以扩展 Kubernetes API 的形式。帮助用户创建，配置和管理复杂的有状态应用程序。从而实现特定应用程序的常见操作以及运维自动化。

在 Kubernetes 中我们使用 Deployment、DamenSet，StatefulSet 来管理应用 Workload，使用 Service，Ingress 来管理应用的访问方式，使用 ConfigMap 和 Secret 来管理应用配置。我们在集群中对这些资源的创建，更新，删除的动作都会被转换为事件 (Event)，Kubernetes 的 Controller Manager 负责监听这些事件并触发相应的任务来满足用户的期望。这种方式我们成为声明式，用户只需要关心应用程序的最终状态，其它的都通过 Kubernetes 来帮助我们完成，通过这种方式可以大大简化应用的配置管理复杂度。

而除了这些原生的 Resource 资源以外，Kubernetes 还允许用户添加自己的自定义资源 (Custom Resource)。并且通过实现自定义 Controller 来实现对 Kubernetes 的扩展。当然我们如果有对应的需求也完全可以自己去实现一个 Operator，接下来我们就来给大家详细介绍下 Prometheus-Operator 的使用方法。

下面三个yaml文件很好的表述了，Prometheus 如何关联选择 Servicemonitor，Servicemonitor 如何关联选择目标 Service。

图片

为了能让 Prometheus 监控 k8s 内的应用，Prometheus-Operator 通过配置 Servicemonitor 匹配到由 Service 对象自动填充的 Endpoints，并配置 Prometheus 监控这些 Endpoints 后端的 Pods，ServiceMonitor.Spec 的 Endpoints 部分就是用于配置 Endpoints 的哪些端口将被 Scrape 指标。

Servicemonitor 对象很巧妙，它解耦了“监控的需求”和“需求的实现方”。 Servicemonitor 只需要用到 Label-selector 这种简单又通用的方式声明一个 “监控需求”，也就是哪些 Endpoints 需要搜集，怎么收集就行了。让用户只关心需求，这是一个非常好的关注点分离。当然 Servicemonitor 最后还是会被 Operator转化为原始的复杂的 Scrape config,但这个复杂度已经完全被 Operator 屏蔽了。

Prometheus告警对接流程

下图很好的展现了Prometheus在配置报警时需要操作哪些资源，及各资源起到的作用

图片

• 首先通过配置 Servicemonitor/Podmonitor 来获取应用的监控指标；

• Prometheus.spec.alerting 字段会匹配 Alertmanager 中的配置，匹配到 Alertmanager 实例

• 然后通过 Prometheusrule 对监控到的指标配置报警规则；

• 最后配置告警接收器，配置 Alertmanager config 来配置如何处理告警，包括如何接收、路由、抑制和发送警报等；

Prometheus Operator 架构

图片

上图是 Prometheus-Operator 官方提供的架构图，其中 Operator 是最核心的部分，作为一个控制器，他会去创建 Prometheus、ServiceMonitor、AlertManager 以及 PrometheusRule 4个CRD 资源对象，然后会一直监控并维持这4个资源对象的状态。

其中创建的 Prometheus 这种资源对象就是作为 Prometheus Server 存在，而 ServiceMonitor 就是 Exporter 的各种抽象，Exporter 前面我们已经学习了，是用来提供专门提供 Metrics 数据接口的工具，Prometheus 就是通过 ServiceMonitor 提供的 Metrics 数据接口去 Pull 数据的，当然 AlertManager 这种资源对象就是对应的 AlertManager 的抽象，而 PrometheusRule 是用来被 Prometheus 实例使用的报警规则文件。

这样我们要在集群中监控什么数据，就变成了直接去操作 Kubernetes 集群的资源对象了，是不是方便很多了。上图中的 Service 和 ServiceMonitor 都是 Kubernetes 的资源，一个 ServiceMonitor 可以通过 LabelSelector 的方式去匹配一类 Service，Prometheus 也可以通过 LabelSelector 去匹配多个 ServiceMonitor。

在最新版本的 Operator 中提供了一下几个 CRD 资源对象：

• Prometheus

• Alertmanager

• ServiceMonitor

• PodMonitor

• Probe

• ThanosRuler

• PrometheusRule

• AlertmanagerConfig

• PrometheusAgent

• ScrapeConfig

Prometheus

该 CRD 声明定义了 Prometheus 期望在 Kubernetes 集群中运行的配置，提供了配置选项来配置副本、持久化、报警实例等。

对于每个 Prometheus CRD 资源，Operator 都会以 StatefulSet 形式在相同的命名空间下部署对应配置的资源，Prometheus Pod 的配置是通过一个包含 Prometheus 配置的名为 Prometheus-name 的 Secret 对象声明挂载的。

该 CRD 根据标签选择来指定部署的 Prometheus 实例应该覆盖哪些 ServiceMonitors，然后 Operator 会根据包含的 ServiceMonitors 生成配置，并在包含配置的 Secret 中进行更新。

如果未提供对 ServiceMonitor 的选择，则 Operator 会将 Secret 的管理留给用户，这样就可以提供自定义配置，同时还能享受 Operator 管理 Operator 的设置能力。

Alertmanager

该 CRD 定义了在 Kubernetes 集群中运行的 Alertmanager 的配置，同样提供了多种配置，包括持久化存储。

对于每个 Alertmanager 资源，Operator 都会在相同的命名空间中部署一个对应配置的 StatefulSet，Alertmanager Pods 被配置为包含一个名为 Alertmanager-name 的 Secret，该 Secret 以 alertmanager.yaml 为 key 的方式保存使用的配置文件。

当有两个或更多配置的副本时，Operator 会在高可用模式下运行 Alertmanager 实例。

ThanosRuler

该 CRD 定义了一个 Thanos Ruler 组件的配置，以方便在 Kubernetes 集群中运行。通过 Thanos Ruler，可以跨多个 Prometheus 实例处理记录和警报规则。

一个 ThanosRuler 实例至少需要一个 queryEndpoint，它指向 Thanos Queriers 或 Prometheus 实例的位置。queryEndpoints 用于配置 Thanos 运行时的 --query 参数，更多信息也可以在 Thanos 文档中找到。

ServiceMonitor

该 CRD 定义了如何监控一组动态的服务，使用标签选择来定义哪些 Service 被选择进行监控。这可以让团队制定一个如何暴露监控指标的规范，然后按照这些规范自动发现新的服务，而无需重新配置。

为了让 Prometheus 监控 Kubernetes 内的任何应用，需要存在一个 Endpoints 对象，Endpoints 对象本质上是 IP 地址的列表，通常 Endpoints 对象是由 Service 对象来自动填充的，Service 对象通过标签选择器匹配 Pod，并将其添加到 Endpoints 对象中。一个 Service 可以暴露一个或多个端口，这些端口由多个 Endpoints 列表支持，这些端点一般情况下都是指向一个 Pod。

Prometheus Operator 引入的这个 ServiceMonitor 对象就会发现这些 Endpoints 对象，并配置 Prometheus 监控这些 Pod。ServiceMonitorSpec 的 endpoints 部分就是用于配置这些 Endpoints 的哪些端口将被 scrape 指标的。

注意：endpoints（小写）是 ServiceMonitor CRD 中的字段，而 Endpoints（大写）是 Kubernetes 的一种对象。

ServiceMonitors 以及被发现的目标都可以来自任何命名空间，这对于允许跨命名空间监控的场景非常重要。使用 PrometheusSpec 的 ServiceMonitorNamespaceSelector，可以限制各自的 Prometheus 服务器选择的 ServiceMonitors 的命名空间。使用 ServiceMonitorSpec 的 namespaceSelector，可以限制 Endpoints 对象被允许从哪些命名空间中发现，要在所有命名空间中发现目标，namespaceSelector 必须为空：

spec:
  namespaceSelector:
    any: true
PodMonitor

该 CRD 用于定义如何监控一组动态 pods，使用标签选择来定义哪些 pods 被选择进行监控。同样团队中可以制定一些规范来暴露监控的指标。

Pod 是一个或多个容器的集合，可以在一些端口上暴露 Prometheus 指标。

由 Prometheus Operator 引入的 PodMonitor 对象会发现这些 Pod，并为 Prometheus 服务器生成相关配置，以便监控它们。

PodMonitorSpec 中的 PodMetricsEndpoints 部分，用于配置 Pod 的哪些端口将被 scrape 指标，以及使用哪些参数。

PodMonitors 和发现的目标可以来自任何命名空间，这同样对于允许跨命名空间的监控用例是很重要的。使用 PodMonitorSpec 的 namespaceSelector，可以限制 Pod 被允许发现的命名空间，要在所有命名空间中发现目标，namespaceSelector 必须为空：

spec:
  namespaceSelector:
    any: true

PodMonitor 和 ServieMonitor 最大的区别就是不需要有对应的 Service。

Probe

该 CRD 用于定义如何监控一组 Ingress 和静态目标。除了 target 之外，Probe 对象还需要一个 prober，它是监控的目标并为 Prometheus 提供指标的服务。例如可以通过使用 blackbox-exporter 来提供这个服务。

PrometheusRule

用于配置 Prometheus 的 Rule 规则文件，包括 recording rules 和 alerting，可以自动被 Prometheus 加载。

AlertmanagerConfig

在以前的版本中要配置 Alertmanager 都是通过 Configmap 来完成的，在 v0.43 版本后新增该 CRD，可以将 Alertmanager 的配置分割成不同的子对象进行配置，允许将报警路由到自定义 Receiver 上，并配置抑制规则。

AlertmanagerConfig 可以在命名空间级别上定义，为 Alertmanager 提供一个聚合的配置。这里提供了一个如何使用它的例子。不过需要注意这个 CRD 还不稳定。

这样我们要在集群中监控什么数据，就变成了直接去操作 Kubernetes 集群的资源对象了，是这样比之前手动的方式就方便很多了。

PrometheusSgents

是一种新的 CRD，主要用于定义 Prometheus Agent 实例。

Prometheus Agent 是一种轻量化的 Prometheus 模式，适用于远程写入的场景。

它的主要作用是采集监控数据并将其转发到远程存储（例如 Thanos 或 Cortex），而不需要存储数据或提供查询功能。

适用场景

• 仅需要采集监控数据并将其转发到远程存储，不需要存储和查询功能。
• 适合边缘监控或分布式监控场景，例如 IoT、边缘计算。
• 资源受限的环境中更适合使用 Prometheus Agent。

ScrapeConfig

用于动态配置 Prometheus Scrape Configuration（Prometheus 的抓取配置）。

它允许用户通过声明式方式为 Prometheus 添加或修改抓取配置 (scrape_configs)，而无需直接编辑 Prometheus 的全局配置文件（prometheus.yaml）。

主要目的是提供更灵活的抓取配置选项，尤其是用于复杂场景中自定义抓取目标或特殊的认证需求。

在默认情况下，Prometheus Operator 是通过 ServiceMonitor 或 PodMonitor 来定义抓取目标的。

然而，这种方式有一定限制，无法满足一些复杂场景，比如：

• 自定义抓取目标（不通过 Kubernetes 服务发现）。
• 针对特定的认证方式配置（如 BasicAuth、BearerToken、OAuth）。
• 自定义 metrics_path 或抓取规则。

为了解决这些问题，Prometheus Operator 引入了 ScrapeConfig CRD。

主要功能

自定义抓取目标

• 可以定义任意非 Kubernetes 的抓取目标，例如外部的 HTTP 服务、API 网关等。

灵活的认证方式

• 支持 BasicAuth、TLS 认证、Bearer Token、OAuth 等多种认证方式。

特定的抓取设置

• 自定义 metrics_path、scheme（HTTP/HTTPS）、interval（抓取间隔）等参数。

与 ServiceMonitor 和 PodMonitor 的区别

• ServiceMonitor 和 PodMonitor 更适合 Kubernetes 内部资源的监控。
• ScrapeConfig 用于外部资源或高度定制化的抓取需求。

简言之，Prometheus Operator 能够帮助用户自动化的创建以及管理 Prometheus Server 以及其相应的配置。

结语

这边我们算是把整个 Prometheus 必要的概念和原理熟悉后，我们接下来就该实操了，下面的也是一个大工程，需要一些时间去把这个贯穿和实现。

引用链接

[1] prometheus-operator GitHub 地址: https://github.com/prometheus-operator/prometheus-operator[2] kube-prometheus GitHub 地址: https://github.com/prometheus-operator/kube-prometheus[3] kube-prometheus-stack GitHub 地址: https://github.com/prometheus-community/helm-charts/tree/main/charts/kube-prometheus-stack