通过Prometheus-Operator认识Kubernetes-Operator

Prometheus通过一个叫做'@Modifier'的特性，用来查询某个具体时间点的指标数据。这个功能从2.25.0版本被添加，并默认处于禁用状态。

正因为要利用这个特性，所以需要对现有的Prometheus进行升级。这个低版本的Prometheus并不是用Docker或者以二进制这些自己之前熟悉的方式部署运行，而是使用了一种叫做Prometheus-Operator的方式。

Prometheus-Operator对我来说是非常陌生的一个工具，然而现实是我需要自己对Prometheus进行升级。

Just Google it!

网络搜索永远是第一途径，当我去搜索"prometheus upgrade using operator"类似的关键字后，结果几乎都是关于“用Prometheus-Operator部署Prometheus”，“什么是Prometheus-Operator”之类的内容。这些答案并非是我所想要的。

想要快速地从搜索直接得到答案的路行不通之后，我慢慢的意识到我需要了解，需要认识，需要学习摆在我面前的东西。

知识戈壁

当我试图去直接了解Prometheus Operator时，每一篇文章，每一段文字都会把自己引入另一篇文章，另一短文字。这些内容好像都在谈论同一个主题但又好像在谈很多主题。从视频内容到官方介绍再到博客文章，铺天盖地的新名词接踵而至。自己反复在这些地方穿梭之后发现自己并没有对Operator产生一个系统性的认识，而是得到了越来越多的知识碎片，这些碎片散落在我的知识戈壁中。我需要一条线索把这些碎片拼起来。

线索

这篇文章提供了一个使用Operator部署Prometheus的完整过程。其中首先部署了set文件夹下的CRD，然后部署了kube-prometheus。到此为止。我相信我的线索已经找到，碎片也可以拼了起来，并且对Operator有了一个全面的认识。下面就是我将碎片拼起来后的内容。

从Kubernetes Resource开始：

RESTful API有一个重要概念叫做resources。Kubernetes的大脑是控制平面（Control Plane）而API server作为大脑的核心，并且遵循RESTful API的风格，因resources这个概念在Kubernetes中同样重要。

那么什么是Kubernetes resource？这里是官方的解释：

在Kubernetes中resource被称作resource type 。为了让Kubernetes可扩展，resource type按照API Group进行组织，每个API Group都通过版本经行管理。

通过执行kubectl api-resources来查看Kubernetes中内置的resource。

会发现在Kubernetes中操作的pod，deployment，service，namespace，甚至node，statufulset，ingress实际上都是某种resource。同时也解释了在yaml文件中apiversion，kind这些字段的含义。

如何通过HTTP请求而不是kubectl来调用这些resource，请查看Ivan Velichko的文章。

来看看Prometheus Operator

kube-prometheus中包含Prometheus-operator和一整套Prometheus监控的组件。下载他的release版本，以v0.11.0为例，解压后打开/kube-prometheus-0.11.0/manifests/prometheus-prometheus.yaml，它负责描述真正在Kubernetes集群中运行的Prometheus。

这份yaml文件的kind字段，并非像以前所熟知的service，deployment，pod，而是Prometheus。按照上面的内容，这里的Prometheus应该是Kubernetes中的一种resource。

如果你看过线索一节提到的文章，就会发现使用kube-prometheus时，首先部署的是/kube-prometheus-0.11.0/manifests/setup下的yaml文件。这些文件被称作CRD。

CustomResourceDefinitions，CRD

如果仔细观察执行kubectl api-resources后的结果，会发现有一种resource叫做CustomResourceDefinitions，或者叫crd

crd允许我们定义自己的resource然后“注册”到Kubernetes的API server上。setup文件夹下的内容就是crd。

以/kube-prometheus-0.11.0/manifests/setup/0prometheusCustomResourceDefinition.yaml为例，这个crd就描述了一个Prometheus应该具备什么样的“特征”或“属性”。

这些“特征”和“属性”，就是我们在使用这个custom resource时可以在yaml选择的key。

回到本文最开始的需求，除了找到使用Prometheus-operator部署的Prometheus的升级方式之外，我最终的目的是要使用Prometheus的@Modifier特性。但是这个特性默认是被关闭的，需要手动启用。

如果以二进制的方式部署的Prometheus，我们可以停止这个Prometheus，并且在下次启动时，从命令行直接加入--enable-feature=promql-at-modifier这个参数。然而使用kube-prometheus这种方式部署的情况，就需要使用对应的crd和对应的prometheus.yaml。在0prometheusCustomResourceDefinition.yaml中启动默认关闭的特性的选项叫做enableFeatures

接下来要做的就是在prometheus-prometheus.yaml文件中添加内容

然后用kubectl apply -f prometheus-prometheus.yaml应用这个新的yaml文件。Prometheus的@modifier特性就启用了。

最开始的问题

如何对使用operator部署的应用进行升级？

在了解关于Kubernetes Operator的概念的过程中其实也一直想要通过搜索引擎找到直接的答案。但是事与愿违。

不过根据CoreOS在创建Kubernetes Operator时的理念上找到了一些思路，还没有去验证。

从第6点上，可以推断出直接修改prometheus-prometheus.yaml文件中的镜像版本号就可以做到升级Prometheus。这是改动最小的一种方式。

另外实际描述prometheus resource的是crd文件，因此第二种方式可以考虑升级crd，然后再修改prometheus-prometheus.yaml文件中的镜像版本号。并且operator并未做升级。

第三种想法就是对operator一同升级。所以做以下总结：

注意这些方法并未做验证。

• 方法一：直接prometheus-prometheus.yaml文件中的镜像版本号。
• 方法二：更新Prometheus的CRD，然后做方法一。
• 方法三：更新Prometheus Operator，然后做方法二，最后做方法一。