原文：https://github.com/coreos/prometheus-operator/blob/master/Documentation/design.md

设计（Design）

本文描述了 Prometheus Operator 引入的自定义资源定义之间的设计和交互。

Prometheus Operator 将介绍的自定义资源有：

• ServiceMonitor
• Alertmanager

Prometheus

Prometheus 自定义的资源定义（CRD）声明式地定义了在 Kubernetes 集群中运行的所需的 Prometheus 设置。它提供了配置复制，持久化存储和部署 Prometheus 实例向其发送告警的 Alertmanagers 的选项。

对于每个 Prometheus 资源，Operator 都在相同的命名空间中部署正确配置的 StatefulSet。Prometheus Pods 配置为安装一个名为 的 secrets，其中包含 Prometheus 的配置。

CRD 根据标签选择指定部署的 Prometheus 实例应包含哪些 ServiceMonitor。Operator 根据包含的 ServiceMonitor 生成配置，并在包含配置的 Secret 中更新它。对于 ServiceMonitors 或 Prometheus 资源本身的所有更改，它都会这样做。

如果未提供 ServiceMonitor 选择，则 Operator 将 secret 的管理留给用户，从而允许提供自定义配置，此时，仍能从 Operator 管理的 Prometheus 设置的能力中收益。

ServiceMonitor

ServiceMonitor 自定义的资源定义（CRD）允许声明式定义应如何监视一组动态服务。使用标签选择来定义选择哪些服务，以期望的配置进行监控。这允许组织引入关于直白哦如何公开的约定，然后按照这些约定自动发现新服务，而无须重新配置系统。

对于 Prometheus 来监视 Kubernetes 内的任何应用程序，Endpoints 对象都需要存在。Endpoint 对象基本上是 IP 地址列表。通常，一个 Endpoints 对象由一个 Service 对象填充。Service 对象通过标签选择器发现 Pods 并将其添加到 Endpoints 对象中。

服务可能会公开一个或多个服务端口，这些服务端口由多个 Endpoints 列表支持，这些 Endpoints 在常见情况下指向 Pod。这也反映在各自的 Endpoints 对象中。

由 Prometheus Operator 引入的 ServiceMonitor 对象依次发现这些 Endpoints 对象并配置 Prometheus 来监视这些 Pod。

ServiceMonitorSpec 的 Endpoints 部分用于配置这些 Endpoint 的哪些端口将针对度量指标以及哪些参数进行捉取。对于高级用例，可能需要监控支持的 Pod 端口，这些端口并非直接属于服务 Endpoints 的一部分。因此，在 Endpoints 部分指定 Endpoint 时，严格使用 Endpoint。

• 注意：endpoint（小写）是 ServiceMonitor CRD 中的字段，而 Endpoints（大写）是 Kubernetes 对象类型。

虽然 ServiceMonitor 必须与 Prometheus 资源位于同一个命名空间中，但发现的目标可能来自任何命名空间。这对于允许跨命名空间监视的用例很重要，例如进行 metadata 监测。使用 ServiceMonitorSpec 的 namespaceSelector，可以限制 endpoint 对象被允许从中发现的命名空间。要发现所有命名空间中的目标，namespaceSelector 必须为空：

spec:
  namespaceSelector:
    any: true

Alertmanager

Alertmanager 自定义的资源定义（CRD）声明式地定义了要在 Kubernetes 集群中运行地所需 Alertmanager 设置。它提供了配置复制和持久化存储的选项。

对于每个 Alertmanager 资源，Operator 都在相同的命名空间中部署正确配置的 StatefulSet。Alertmanager pod 配置为包含一个名为 的 secret，该密钥在 alertmanager.yaml 中保存使用的配置文件。

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