7 min read

通过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,然后做方法二,最后做方法一。