Prometheus Operator 介绍与配置解析


随着云原生概念盛行,对于容器、服务、节点以及集群的监控变得越来越重要。Prometheus作为Kubernetes监控的事实标准,有着强大的功能和良好的生态。但是它不支持分布式,不支持数据导入、导出,不支持通过API修改监控目标和报警规则,所以在使用它时,通常需要写脚本和代码来简化操作。

Prometheus Operator为监控Kubernetes Service、Deployment和Prometheus实例的管理提供了简单的定义,简化在Kubernetes上部署、管理和运行Prometheus和Alertmanager集群。

功能

Prometheus Operator(后面都简称Operater)提供如下功能:
  • 创建/销毁:在Kubernetes namespace中更加容易地启动一个Prometheues实例,一个特定应用程序或者团队可以更容易使用Operator。
  • 便捷配置:通过Kubernetes资源配置Prometheus的基本信息,比如版本、存储、副本集等。


通过标签标记目标服务:基于常见的Kubernetes label查询自动生成监控目标配置;不需要学习Prometheus特定的配置语言。如果你想和更多Prometheus技术专家交流,可以加我微信liyingjiese,备注『加群』。群里每周都有全球各大公司的最佳实践以及行业最新动态

先决条件

对于版本高于0.18.0的Prometheus Operator要求Kubernetes集群版本高于 1.8.0。如果你才开始使用Prometheus Operator,推荐你使用最新版。

如果你使用的旧版本的Kubernetes和Prometheus Operator还在运行,推荐先升级Kubernetes,再升级Prometheus Operator。

安装与卸载

快速安装

使用 Helm 安装Prometheus Operator。使用Helm安装后会在Kubernetes集群中创建、配置和管理Prometheus集群,chart中包含多种组件:
  • prometheus-operator
  • Prometheus
  • alertmanager
  • node-exporter
  • kube-state-metrics
  • Grafana

  • 收集Kubernetes内部组件指标的监控服务
    • kube-apiserver
    • kube-scheduler
    • kube-controller-manager
    • etcd
    • kube-dns/coredns
    • kube-proxy


安装一个版本名为my-release的chart:
helm install --name my-release stable/prometheus-operator

这会在集群中安装一个默认配置的prometheus-operator。这份配置文件列出了安装过程中可以配置的选项。

默认会安装Prometheus Operator,Alertmanager,Grafana。并且会抓取集群的基本信息。

Runner类型

卸载my-release部署:
helm delete my-release

这个命令会删除与这个chart相关的所有Kubernetes组件。

这个chart创建的CRDs不会被默认删除,需要手动删除:
kubectl delete crd prometheuses.monitoring.coreos.com
kubectl delete crd prometheusrules.monitoring.coreos.com
kubectl delete crd servicemonitors.monitoring.coreos.com
kubectl delete crd podmonitors.monitoring.coreos.com
kubectl delete crd alertmanagers.monitoring.coreos.com

架构

Prometheus Operator架构图如下:
1.jpg

上面架构图中,各组件以不同的方式运行在Kubernetes集群中:
  • Operator:根据自定义资源(Custom Resource Definition / CRDs)来部署和管理Prometheus Server,同时监控这些自定义资源事件的变化来做相应的处理,是整个系统的控制中心。
  • Prometheus:声明Prometheus deployment 期望的状态,Operator确保这个deployment运行时一直与定义保持一致。
  • Prometheus Server:Operator根据自定义资源Prometheus类型中定义的内容而部署的Prometheus Server集群,这些自定义资源可以看作是用来管理Prometheus Server集群的StatefulSets资源。
  • ServiceMonitor:声明指定监控的服务,描述了一组被Prometheus监控的目标列表。该资源通过Labels来选取对应的Service Endpoint,让Prometheus Server通过选取的Service来获取Metrics信息。
  • Service:简单的说就是Prometheus监控的对象。
  • Alertmanager:定义AlertManager deployment期望的状态,Operator确保这个deployment运行时一直与定义保持一致。


自定义资源

Prometheus Operater定义了如下的四类自定义资源:
  • Prometheus
  • ServiceMonitor
  • Alertmanager
  • PrometheusRule


Prometheus

Prometheus自定义资源(CRD)声明了在Kubernetes集群中运行的Prometheus的期望设置。包含了副本数量,持久化存储,以及Prometheus实例发送警告到的Alertmanagers等配置选项。

每一个Prometheus资源,Operator都会在相同namespace下部署成一个正确配置的StatefulSet,Prometheus的Pod都会挂载一个名为<prometheus-name>的Secret,里面包含了Prometheus的配置。Operator根据包含的ServiceMonitor生成配置,并且更新含有配置的Secret。无论是对ServiceMonitors或者Prometheus的修改,都会持续不断的被按照前面的步骤更新。

一个样例配置如下:
kind: Prometheus
metadata: # 略
spec:
alerting:
alertmanagers:
- name: prometheus-prometheus-oper-alertmanager # 定义该 Prometheus 对接的 Alertmanager 集群的名字, 在default这个namespace中
  namespace: default
  pathPrefix: /
  port: web
baseImage: quay.io/prometheus/prometheus
replicas: 2 # 定义该 Proemtheus “集群”有两个副本,说是集群,其实Prometheus自身不带集群功能,这里只是起两个完全一样的Prometheus来避免单点故障
ruleSelector: # 定义这个Prometheus需要使用带有prometheus=k8s且role=alert-rules标签的PrometheusRule
matchLabels:
  prometheus: k8s
  role: alert-rules
serviceMonitorNamespaceSelector: {} # 定义这些Prometheus在哪些namespace里寻找ServiceMonitor
serviceMonitorSelector: # 定义这个Prometheus需要使用带有k8s-app=node-exporter标签的ServiceMonitor,不声明则会全部选中
matchLabels:
  k8s-app: node-exporter
version: v2.10.0


Prometheus配置

ServiceMonitor

ServiceMonitor自定义资源(CRD)能够声明如何监控一组动态服务的定义。它使用标签选择定义一组需要被监控的服务。这样就允许组织引入如何暴露Metrics的规定,只要符合这些规定新服务就会被发现列入监控,而不需要重新配置系统。

要想使用Prometheus Operator监控Kubernetes集群中的应用,Endpoints对象必须存在。Endpoints对象本质是一个IP地址列表。通常,Endpoints对象由Service构建。Service对象通过对象选择器发现Pod并将它们添加到Endpoints对象中。

一个Service可以公开一个或多个服务端口,通常情况下,这些端口由指向一个Pod的多个Endpoints支持。这也反映在各自的Endpoints对象中。

Prometheus Operator引入ServiceMonitor对象,它发现Endpoints对象并配置Prometheus去监控这些Pods。

ServiceMonitorSpec的endpoints部分用于配置需要收集metrics的Endpoints的端口和其他参数。在一些用例中会直接监控不在服务endpoints中的pods的端口。因此,在endpoints部分指定endpoint时,请严格使用,不要混淆。


注意:endpoints(小写)是ServiceMonitorCRD中的一个字段,而Endpoints(大写)是Kubernetes 资源类型。
ServiceMonitor和发现的目标可能来自任何namespace。这对于跨namespace的监控十分重要,比如meta-monitoring。使用PrometheusSpec下ServiceMonitorNamespaceSelector,通过各自Prometheus server限制ServiceMonitors作用namespece。使用ServiceMonitorSpec下的namespaceSelector可以现在允许发现Endpoints对象的命名空间。要发现所有命名空间下的目标,namespaceSelector必须为空。
spec:
namespaceSelector:
any: true

一个样例配置如下:
kind: ServiceMonitor
metadata:
labels:
k8s-app: node-exporter # 这个ServiceMonitor对象带有k8s-app=node-exporter标签,因此会被Prometheus选中
name: node-exporter
namespace: default
spec:
selector:
matchLabels: # 定义需要监控的Endpoints,带有app=node-exporter且k8s-app=node-exporter标签的Endpoints会被选中
  app: node-exporter
  k8s-app: node-exporter
endpoints:
- bearerTokenFile: /var/run/secrets/kubernetes.io/serviceaccount/token
interval: 30s # 定义这些Endpoints需要每30秒抓取一次
targetPort: 9100 # 定义这些Endpoints的指标端口为9100
scheme: https
jobLabel: k8s-app


ServiceMonitor配置

Alertmanager

Alertmanager自定义资源(CRD)声明在Kubernetes集群中运行的Alertmanager的期望设置。它也提供了配置副本集和持久化存储的选项。

每一个Alertmanager资源,Operator都会在相同namespace下部署成一个正确配置的StatefulSet。Alertmanager pods配置挂载一个名为<alertmanager-name>的Secret, 使用alertmanager.yaml key对作为配置文件。

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

一个样例配置如下:
kind: Alertmanager #  一个Alertmanager对象
metadata:
name: prometheus-prometheus-oper-alertmanager
spec:
baseImage: quay.io/prometheus/alertmanager
replicas: 3      # 定义该Alertmanager集群的节点数为3
version: v0.17.0

Alertmanager配置

PrometheusRule

PrometheusRule CRD声明一个或多个Prometheus实例需要的Prometheus rule。

Alerts和recording rules可以保存并应用为yaml文件,可以被动态加载而不需要重启。

一个样例配置如下:
kind: PrometheusRule
metadata:
labels: # 定义该PrometheusRule的label, 显然它会被Prometheus选中
prometheus: k8s
role: alert-rules
name: prometheus-k8s-rules
spec:
groups:
- name: k8s.rules
rules: # 定义了一组规则,其中只有一条报警规则,用来报警kubelet是不是挂了
- alert: KubeletDown
  annotations:
    message: Kubelet has disappeared from Prometheus target discovery.
  expr: |
    absent(up{job="kubelet"} == 1)
  for: 15m
  labels:
    severity: critical


PrometheusRule配置

它们之间的关系如下图:
2.jpg

Prometheus Operator的优点

Prometheus Operator中所有的API对象都是CRD中定义好的Schema,API Server会校验。当开发者使用ConfigMap保存配置没有任何校验,配置文件写错时,自表现为功能不可用,问题排查复杂。在Prometheus Operator中,所有在Prometheus对象、ServiceMonitor对象、PrometheusRule对象中的配置都是有Schema校验的,校验失败apply直接出错,这就大大降低了配置异常的风险。

Prometheus Operator借助Kubernetes将Prometheus服务平台化。有了Prometheus和AlertManager这样的API对象,非常简单、快速的可以在Kubernetes集群中创建和管理Prometheus服务和AlertManager服务,以应对不同业务部门,不同领域的监控需求。

ServiceMonitor和PrometheusRule解决了Prometheus配置难维护问题,开发者不再需要去专门学习Prometheus的配置文件,不再需要通过CI和Kubernetes ConfigMap等手段把配置文件更新到Pod内再触发webhook热更新,只需要修改这两个对象资源就可以了。

原文链接:https://mp.weixin.qq.com/s/v34NOT2_pbzWYG6tuSuoZQ

0 个评论

要回复文章请先登录注册