Prometheus是最初由SoundCloud在2012年开发的开源监视和警报工具包。此后，该平台吸引了一个充满活力的开发人员和用户社区。 Prometheus现在已紧密集成到云原生生态系统中，并且对容器和Kubernetes具有本地支持。
在之前的教程中，您学习了如何配置和部署Prometheus来监视Kubernetes应用程序。但是，配置Prometheus并非易事，因为您需要具有特定领域的知识，包括Prometheus配置格式和Kubernetes自动发现设置。显然，获得这些知识需要时间和精力。
但是，正如本教程中所示，您可以使用CoreOS开发的Prometheus Operator大大简化Prometheus实例的部署和管理。我们将讨论Prometheus Operator如何使您的监视管道受益，然后逐步引导您建立一个有效的Prometheus Operator，以从您的应用程序中收集Prometheus格式的指标。让我们开始吧！
什么是运营商？
简而言之，CoreOS早在2016年就引入了软件操作员的概念。操作员是任何特定于应用程序或特定于域的控制器，它扩展了Kubernetes API以代表Kubernetes简化复杂状态应用程序的部署，配置和管理。用户。
在幕后，操作员抽象了基本的Kubernetes API和控制器，并自动执行了特定应用程序（例如Prometheus）的常见任务。由于有了这种抽象，即使用户几乎不了解其特定于域的配置和语言，也可以轻松地配置复杂的应用程序。此外，操作员还可用于许多其他任务，包括安全协调应用程序升级，服务发现，TLS证书配置，灾难恢复，备份管理等。
普罗米修斯算子
基于以上定义，可以将Prometheus Operator定义为Kubernetes之上的一个软件，该软件可以简化Prometheus实例的管理，包括其配置和服务发现。它使用户可以轻松启动Prometheus的多个实例，配置Prometheus版本，以及管理保留策略，持久性和副本。
此外，Prometheus Operator可以基于Kubernetes标签查询自动生成监视目标设置。用户只需在Prometheus Operator的清单中参考他们想要监视的服务和Pod，Operator就会为Kubernetes自动发现插入适当的Prometheus配置。
为了实现此功能，Prometheus Operator引入了其他资源和抽象，这些资源和抽象被设计为自定义资源定义（CRD）。这些包括：

描述Prometheus部署所需状态的Prometheus资源。
服务监视器，用于描述和管理Prometheus取消的监视目标。 Prometheus资源使用serviceMonitorSelector字段连接到ServiceMonitors。这样，Prometheus可以看到必须删除哪些目标（应用程序）。
警报管理器资源，用于定义，配置和管理Prometheus警报管理器。
在本文中，我们仅探讨Prometheus资源和服务监视器-配置Prometheus Operator监视Kubernetes集群所需的最低要求。
要完成下面使用的示例，您需要满足以下先决条件：
正在运行的Kubernetes集群有关使用Supergiant部署Kubernetes集群的更多信息，请参见Supergiant文档。或者，您可以使用Minikube在本地系统上安装单节点Kubernetes集群。
安装并配置为与集群通信的kubectl命令行工具。在这里查看如何安装kubectl。
设置此环境后，我们将监视一个简单的Web应用程序，该应用程序将导出Prometheus格式的指标。让我们开始吧！
步骤1：创建Prometheus运算符
Prometheus操作员必须访问Kubernetes API，节点和集群组件，因此我们应该为其授予一些权限。我们可以通过定义RBAC策略的ClusterRole资源来执行此操作。 ClusterRole包含代表一组权限的规则。这些权限是累加的，因此我们应该列出所有权限。我们将使用ClusterRole资源，该资源可以授予权限来操纵整个集群的资源，而不是角色空间范围内的Role。

上面的清单向Prometheus Operator授予了以下群集范围的权限：
读取对pod，节点和名称空间的访问权限。
对服务及其端点的读/写访问。
完全访问机密，ConfigMap，StatefuleSet，Prometheus相关资源（警报管理器，服务监视器等）和其他第三方资源等。
接下来，我们需要为Prometheus运营商提供身份。 这可以通过服务帐户来完成。

现在，由于有了ClusterRole和ServiceAccount，我们需要将ClusterRole中定义的权限列表绑定到Prometheus运算符。 ClusterRoleBinding允许将用户，组或服务帐户的列表与特定角色相关联。 我们将把ClusterRole绑定到Prometheus运营商的服务帐户。

请注意，roleRef.name应该与第一步中创建的ClusterRole的名称匹配，而subject.name应该与第二步中创建的服务帐户的名称匹配。
我们将批量创建这些资源，因此将上述清单放入一个文件（例如authorize.yml）中，并以–分隔符分隔每个清单。 然后运行：

好！ 现在，我们拥有Prometheus操作员管理Prometheus实例和监视应用程序所需的所有权限。 让我们为Prometheus Operator创建一个副本部署：

此清单执行一些重要的操作：
为要运行的prometheus-operator容器定义几个参数。 特别是，我们加载configmap-reload映像，以便能够动态更新Prometheus ConfigMap，并在kubelet-service标志中指定kube-system / kubelet。
将Prometheus Operator定义为用户ID为65534的非root用户。
将部署与在上述步骤中创建的服务帐户相关联。
现在，让我们将此规范保存在prometheus-deployment.yml中并创建部署：

验证是否启动：

步骤2：部署App Shipping Prometheus格式指标
此时，Prometheus Operator没有要监视的应用程序。 因此，在定义ServiceMonitors和Prometheus CRD之前，我们需要部署一些应用程序提供Prometheus格式的指标。 为此，我们使用了Go客户端库中的示例应用程序，该应用程序导出了某些服务的虚假RPC延迟。 为了将应用程序部署在Kubernetes集群中，我们使用Docker将其容器化并推送到Docker Hub存储库中。 让我们在Prometriceus默认监视的/ metrics端点上部署此示例应用服务指标。 以下是我们使用的部署清单：

请注意，containerPort为8081，这是应用程序代码中定义的端口。
将此清单保存在rpc-app-deployment.yml中并创建Deployment：

验证：

为了让Prometheus Operator访问此部署，我们需要公开服务。 然后，ServiceMonitor可以使用标签选择器发现此服务。 我们需要创建一个通过Pod的applabel及其rpc-app值来选择Pod的服务。 让我们看一下此服务清单：

另外，请注意，我们为此服务指定了一个目标端口，该端口引用该服务的后端容器上的端口。 如果未指定targetPort值，Kubernetes会自动将containerPort的值分配给targetPort，但是我们明确地包含了该字段以突出其重要性。
让我们将此规范保存到上面的某个文件（例如rpc-app-service.yml）中，然后创建服务：

现在，您可以验证服务是否成功发现了部署的终结点并配置了正确的端口：

步骤3：创建一个ServiceMonitor
Prometheus Operator使用ServiceMonitors根据标签选择器自动检测目标容器，并将它们与Prometheus实例相关联。 让我们看一下以下清单：

上面定义的ServiceMonitor将使用spec.selector.matchLabels字段选择标记为app：rpc-app的Pod。 请注意，此字段应与app：rpc-app匹配，以便ServiceMonitor查找部署的相应端点。
另外，我们为ServiceMonitor定义了env：production标签。 Prometheus操作员将使用该标签查找ServiceMonitor。 最后，由于我们使用名称为“ web”的端口部署了rpc-app-container，因此我们可以在ServiceMonitor中轻松引用它，而无需指定端口号。 这使我们可以在以后更改端口号，而不会影响其他资源的完整性。
让我们创建ServiceMonitor：

步骤4：创建Prometheus资源
下一步是创建Prometheus资源。 它的清单定义了将ServiceMonitor与操作员相关联的serviceMonitorSelector。 该字段的值应与上面的ServiceMonitor清单中指定的标签env：production匹配。 使用ServiceMonitor标签可以轻松动态地重新配置Prometheus。

另外，请注意，您应该参考上面步骤1中创建的服务帐户。 否则，将不允许Prometheus操作员访问群集资源和API。 这个小细节在GitHub上的问题＃1272中得到了解决。
另外，如果在群集中启用了RBAC授权，则必须同时为Prometheus和Prometheus Operator创建RBAC规则。 请参阅官方CoreOS文档中的“为Prometheus Pods启用RBAC规则”一章，以找到所需的RBAC资源定义。
现在，让我们将此清单保存在prometheus-resource.yml中，并创建Prometheus资源：

最后，我们需要创建一个NodePort类型的Prometheus服务，以将Prometheus暴露给外部世界。 这样，我们可以访问Prometheus Web界面。

将此规范保存在prometheus-service.yml中并创建服务：

现在，您可以从浏览器访问Prometheus仪表板。 如果使用Minikube运行集群，则可以使用以下命令找到Prometheus IP和端口：

然后，您可以在浏览器中输入该地址来访问Prometheus仪表板。
如果您使用/ targets端点，则会看到当前Prometheus目标的列表。 每个部署副本都被视为一个单独的目标，因此您会在信息中心中看到两个目标。 您还可以找到目标的标签和上次获取的时间。

Prometheus操作员使用kubernetes_sd_configs自动创建一个有效的Prometheus配置，以自动发现Kubernetes服务端点。 这是一个非常酷的功能，因为它使您无需学习特定于Prometheus的配置语言。 您可以在状态->配置选项卡下看到自动生成的Prometheus配置：

最后，我们可以可视化示例应用程序生成的RPC时间序列。 为此，请转到图表标签，您可以在其中选择要显示的指标。

在上面的示例中，我们可视化了rpc_durations_histogram_seconds指标。如您所见，我们使用“堆叠”选项进行时间序列可视化，但是您当然可以选择简单的线条。您还可以使用其他RPC指标和本机Prometheus指标。 Web界面还支持Prometheus查询语言PromQL，以选择和汇总所需的指标。 PromQL具有丰富的功能语义，可让您使用时间序列，实例和范围向量，标量和字符串。要了解有关PromQL的更多信息，请查看官方文档。
结论
如您所知，Kubernetes的Prometheus Operator提供了有用的抽象，用于配置和管理Prometheus监视管道。使用操作员意味着您不再需要手动配置Kubernetes自动发现设置，这需要学习很多东西。您需要定义的只是ServiceMonitor，其中包含要从中刮除指标的Pod列表，以及Prometheus资源，该资源可以自动配置并将ServiceMonitors链接到正在运行的Prometheus实例。除了这些功能，Prometheus Operator还支持Prometheus警报管理器的快速配置。所有这些功能大大简化了Prometheus监控管道的管理，同时保留了灵活性和必要的控制权。