Prometheus Operator 的安装

接下来我们用自定义的方式来对 Kubernetes 集群进行监控,但是还是有一些缺陷,比如 Prometheus、AlertManager 这些组件服务本身的高可用。

当然我们也完全可以用自定义的方式来实现这些需求,我们也知道 Promethues 在代码上就已经对 Kubernetes 有了原生的支持,可以通过服务发现的形式来自动监控集群,因此我们可以使用另外一种更加高级的方式来部署 Prometheus:Operator 框架。

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 的以下两个概念:

  • 资源:对象的状态定义
  • 控制器:观测、分析和行动,以调节资源的分布

为什么需要prometheus-operator

因为是prometheus主动去拉取的,所以在k8s里pod因为调度的原因导致pod的ip会发生变化,人工不可能去维持,自动发现有基于DNS的,但是新增还是有点麻烦

Prometheus-operator的本职就是一组用户自定义的CRD资源以及Controller的实现,Prometheus Operator这个controller有RBAC权限下去负责监听这些自定义资源的变化,并且根据这些资源的定义自动化的完成如Prometheus Server自身以及配置的自动化管理工作

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

而除了这些原生的Resource资源以外,Kubernetes还允许用户添加自己的自定义资源(Custom Resource)。并且通过实现自定义Controller来实现对Kubernetes的扩展,不需要用户去二开k8s也能达到给k8s添加功能和对象

因为svc的负载均衡,所以在K8S里监控metrics基本最小单位都是一个svc背后的pod为target,所以prometheus-operator创建了对应的CRD: kind: ServiceMonitor ,创建的ServiceMonitor里声明需要监控选中的svc的label以及metrics的url路径的和namespaces即可

Prometheus-Operator的架构图:

Prometheus Operator 的安装_第1张图片上图是Prometheus-Operator官方提供的架构图,其中Operator是最核心的部分,作为一个控制器,他会去创建Prometheus、ServiceMonitor、AlertManager以及PrometheusRule4个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。

安装

我们这里直接通过 Prometheus-Operator 的源码来进行安装,当然也可以用 Helm 来进行一键安装,我们采用源码安装可以去了解更多的实现细节。首页将源码 Clone 下来:

git clone https://github.com/coreos/kube-prometheus.git
cd manifests

进入到 manifests 目录下面,这个目录下面包含我们所有的资源清单文件,我们需要对其中的文件 prometheus-serviceMonitorKubelet.yaml 进行简单的修改
因为默认情况下,这个 ServiceMonitor 是关联的 kubelet 的10250端口去采集的节点数据,而我们前面说过为了安全,这个 metrics 数据已经迁移到10255这个只读端口上面去了
我们只需要将文件中的https-metrics更改成http-metrics即可

[root@k8s-master manifests]# cat  prometheus-serviceMonitorKubelet.yaml|grep "http-metrics" 
    port: http-metrics
    port: http-metrics
    port: http-metrics

修改完成后,直接在该文件夹下面依次执行创建资源命令即可:

[root@k8s-master setup]# pwd
/usr/local/src/kube-prometheus/manifests/setup
kubectl apply -f .

[root@k8s-master manifests]# pwd
/usr/local/src/kube-prometheus/manifests
kubectl apply -f .

部署完成后,会创建一个名为monitoring的 namespace,所以资源对象对将部署在改命名空间下面,此外 Operator 会自动创建4个 CRD 资源对象:

[root@k8s-master manifests]# kubectl get crd |grep coreos
alertmanagers.monitoring.coreos.com     2020-07-29T13:45:20Z
podmonitors.monitoring.coreos.com       2020-07-29T13:45:20Z
prometheuses.monitoring.coreos.com      2020-07-29T13:45:21Z
prometheusrules.monitoring.coreos.com   2020-07-29T13:45:21Z
servicemonitors.monitoring.coreos.com   2020-07-29T13:45:21Z
thanosrulers.monitoring.coreos.com      2020-07-29T13:45:21Z

可以在 monitoring 命名空间下面查看所有的 Pod
其中 alertmanager 和 prometheus 是用 StatefulSet 控制器管理的
其中还有一个比较核心的 prometheus-operator 的 Pod,用来控制其他资源对象和监听对象变化的:

[root@k8s-master manifests]# kubectl get pods -n monitoring
NAME                                   READY   STATUS    RESTARTS   AGE
alertmanager-main-0                    2/2     Running   0          33m
alertmanager-main-1                    2/2     Running   0          33m
alertmanager-main-2                    2/2     Running   0          33m
grafana-859c88dd49-cdmrj               1/1     Running   0          33m
kube-state-metrics-66c98bdcd5-tgv8z    3/3     Running   0          33m
node-exporter-7ft2b                    2/2     Running   0          33m
node-exporter-s8nqf                    2/2     Running   0          33m
node-exporter-scxhj                    2/2     Running   0          29m
prometheus-adapter-b8d458474-dqw7q     1/1     Running   0          33m
prometheus-k8s-0                       3/3     Running   1          33m
prometheus-k8s-1                       3/3     Running   1          33m
prometheus-operator-58795797cc-bnnp9   2/2     Running   0          33m

编辑 grafana 和 prometheus-k8s 这两个 Service,将服务类型更改为 NodePort:

kubectl edit svc grafana -n monitoring
kubectl edit svc prometheus-k8s -n monitoring

查看创建的 Service:
Prometheus Operator 的安装_第2张图片更改完成后,我们就可以通过去访问上面的两个服务了,比如查看 prometheus 的 targets 页面:
Prometheus Operator 的安装_第3张图片

你可能感兴趣的:(prometheus)