Prometheus Operator & Kube-Prometheus & Helm chart 部署区别

  • Prometheus Operator 是 Kubernetes 原生的工具,它通过将 Prometheus 资源定义为 Kubernetes 对象(CRD)来简化 Prometheus 集群的管理。它自动化了在 Kubernetes 中配置和扩展 Prometheus 实例时涉及的常见任务,并提供了在 Kubernetes 环境中部署、配置和管理 Prometheus 的简单方式。
  1. 通过 kubectl 或 Kubernetes API 创建 Prometheus Operator Custom Resource Definition (CRD)。
  2. 使用 kubectl 或 YAML 文件创建 Prometheus 实例的定义。
  3. Prometheus Operator 观察配置更改并创建、更新或删除 Prometheus 实例。
  • kube-prometheus 提供基于Prometheus & Prometheus Operator完整的集群监控配置示例,包括多实例Prometheus & Alertmanager部署与配置及node exporter的metrics采集,以及scrape Prometheus target各种不同的metrics endpoints,并提供Alerting rules一些示例,触发告警集群潜在的问题。
  1. 使用 YAML 文件或 Helm chart 安装 Kube-Prometheus。
  2. Kube-Prometheus 部署 Prometheus、Alertmanager、Grafana 和 Pushgateway 等组件。
  3. 使用 Prometheus Operator 观察和管理 Prometheus 和相关组件。
  1. 安装 Helm 并添加 Prometheus Helm chart 存储库。
  2. 使用 Helm 安装 Prometheus chart,包括 Prometheus、Alertmanager 和 Pushgateway 等组件。

总结:三者部署 Prometheus 的区别

  • Prometheus Operator 可以更加自动化的管理 Prometheus 集群;
  • Kube-Prometheus 则提供了更加全面的监控解决方案,包括 Prometheus、Grafana 和 Alertmanager 等组件;
  • Helm chart 则通过一个命令即可快速部署 Prometheus 及其相关组件,但无法方便地进行各个组件的管理。

 Kube-Prometheus:目前是k8s集群监控的主流项目,主要使用Prometheus做集群监控,使用Prometheus Operator做监控的运维管理,也就是以上二者的结合。

Prometheus-Operator CRD资源

CRD 全称是 Custom Resource Definition

什么是 CRD?

以 Deployment 为实例,Deployment 没有直接创建 Pod,而是管理 RS,而 RS 管理 Pod,这就是控制器模式。控制器模式允许基于已有的资源定义更高阶的控制器,用来实现更复杂的能力。


特点:

  • CRD 本身是 Kubernetes 的一种资源,允许用户自定义新的资源类型;
  • CRD 允许用户基于已有的 Kubernetes 资源,例如 Deployment、Configmap 等,拓展集群能力;
  • CRD 可以自定义一套成体系的规范,自造概念;

CRD 本身是一种 Kubernetes 内置的资源类型,即自定义资源的定义,用于描述用户定义的资源是什么样子。

Prometheus-Operator CRD

Prometheus Operator的本职就是一组用户自定义的CRD资源以及Controller的实现,Prometheus Operator负责监听这些自定义资源的变化,并且根据这些资源的定义自动化的完成如Prometheus Server自身以及配置的自动化管理工作。主要包括以下几个功能:

  • Kubernetes 自定义资源:使用 Kubernetes CRD 来部署和管理 Prometheus、Alertmanager 和相关组件。
  • 简化的部署配置:直接通过 Kubernetes 资源清单配置 Prometheus,比如版本、持久化、副本、保留策略等等配置。
  • Prometheus 监控目标配置:基于熟知的 Kubernetes 标签查询自动生成监控目标配置,无需学习 Prometheus 特地的配置。


下面架构图中,各组件以不同的方式运行在 Kubernetes 集群中(之前都是用配置文件来配置,现在都是通过资源对象):

Prometheus Operator部署/管理Prometheus Server_sed

CRD 名称

作用

Operator

根据自定义资源(Custom Resource Definition / CRDs)来部署和管理 Prometheus Server,同时监控这些自定义资源事件的变化来做相应的处理,是整个系统的控制中心。

Prometheus

最核心的一个CRD,

控制prometheus server的statefulset状态。该CRD用于部署、管理prometheus stateful实例,以及配置该prometheus实例与ServiceMonitor(通过serviceMonitorNamespaceSelector标签)、Altermanager(通过alertmanagers标签)、PromtheusRule(通过ruleSelector标签)之间的关联。 一个Prometheus crd 资源创建后,promtheus-operator会自动创建一个prometheus stateful实例。

Prometheus Server

Operator 根据自定义资源 Prometheus 类型中定义的内容而部署的 Prometheus Server 集群,这些自定义资源可以看作是用来管理 Prometheus Server 集群的 StatefulSets 资源。

ServiceMonitor

纯配置,Operator告诉prometheus

server , 要监控的 targets是基于k8s service动态发现。 Operator基于servicemonitor的配置生成promtheus的标准配置文件promtheus.yml。注意的是,ServiceMonitor中的endpoint被转换为prometheus.yml中的 kubernetes_sd_configs标签,即服务发现仍然是通过prometheus的原生能力完成的,ServiceMonitor或prometheus-operator并不具备服务发现能力,仅仅是配置转换与应用能力。

Service

简单的说就是 Prometheus 监控的对象。提供给ServiceMonitor选取,让Prometheus Server来获取信息。

Alertmanager

用于部署和管理promtheus的Altermanager实例.一个Altermanager资源定义会对应于一个stateful实例,prometheus-opertaor会根据Alertmanager中指定replicas、image、RBAC等信息将promtheus的altermanager

pod部署,prometheus实例会自动与该Alertmanager相关联,共同完成监控->告警的链路。

PrometheusRule

用于生成promtheus的告警规则文件.纯配置项。promtheus-operator会将该资源转换为prometheus的rule文件,挂在于prometheus实例的文件系统中。

部署 Kube-Prometheus

概述

kube-prometheus 是一整套监控解决方案,它使用 Prometheus 采集集群指标,Grafana 做展示,包含如下组件:

  • The Prometheus Operator
  • Highly available Prometheus
  • Highly available Alertmanager
  • Prometheus node-exporter
  • Prometheus Adapter for Kubernetes Metrics APIs (k8s-prometheus-adapter)
  • kube-state-metrics
  • Grafana

注意:kube-promethues与kubernetes的版本对应关系如下:

 prometheus-operator/kube-prometheus: Use Prometheus to monitor Kubernetes and applications running on Kubernetes (github.com)

Prometheus Operator部署/管理Prometheus Server_自定义_02

下载 Kube-Prometheus 代码

方法一:

git clone https://github.com/prometheus-operator/kube-prometheus.git

cd kube-prometheus

git branch -r   # 查看当前分支有哪些

git checkout release-0.9    # 切换到自己 Kubernetes 兼容的版本
  • 1.
  • 2.
  • 3.
  • 4.
  • 5.
  • 6.
  • 7.

方法二:

git clone -b release-0.9 https://github.com/prometheus-operator/kube-prometheus.git
  • 1.


注:在release-0.11版本之后新增了NetworkPolicy

默认是允许自己访问,如果了解NetworkPolicy可以修改一下默认的规则,可以用查看 ls *networkPolicy*

如果不修改,则会影响到修改NodePort类型也无法访问;

如果不会Networkpolicy可以直接删除就行;

修改 Kube-Prometheus 镜像源

国外镜像源某些镜像无法拉取,我们这里修改prometheus-operator,prometheus,alertmanager,kube-state-metrics,node-exporter,prometheus-adapter的镜像源为国内镜像源。这里使用的是中科大的镜像源。

# 进入修改的目录

cd ./kube-prometheus/manifests/

# 镜像替换

sed -i 's/quay.io/quay.mirrors.ustc.edu.cn/g' setup/prometheus-operator-deployment.yaml

sed -i 's/quay.io/quay.mirrors.ustc.edu.cn/g' prometheus-prometheus.yaml 

sed -i 's/quay.io/quay.mirrors.ustc.edu.cn/g' alertmanager-alertmanager.yaml

sed -i 's/quay.io/quay.mirrors.ustc.edu.cn/g' kube-state-metrics-deployment.yaml

sed -i 's/k8s.gcr.io/lank8s.cn/g' kube-state-metrics-deployment.yaml

sed -i 's/quay.io/quay.mirrors.ustc.edu.cn/g' node-exporter-daemonset.yaml

sed -i 's/quay.io/quay.mirrors.ustc.edu.cn/g' prometheus-adapter-deployment.yaml

sed -i 's/k8s.gcr.io/lank8s.cn/g' prometheus-adapter-deployment.yaml

# 确认一下是否还有国外镜像

grep "image: " * -r
  • 1.
  • 2.
  • 3.
  • 4.
  • 5.
  • 6.
  • 7.
  • 8.
  • 9.
  • 10.
  • 11.
  • 12.
  • 13.
  • 14.
  • 15.
  • 16.
  • 17.
  • 18.
  • 19.
  • 20.
  • 21.
  • 22.
  • 23.
  • 24.
  • 25.
安装operator & kube-Prometheus

创建namespace & CRD资源,如下:

setup 文件夹中包含所有自定义资源配置 CustomResourceDefinition(一般不用修改,也不要轻易修改)

# 下载prometheus-operator镜像需要花费几分钟,这里等待几分钟,直到prometheus-operator变成running状态

kubectl create -f manifests/setup
  • 1.
  • 2.
  • 3.

创建所有应用资源:

kubectl create -f manifests/


# 等待所有镜像变成Running状态

watch kubectl get po -n monitoring
  • 1.
  • 2.
  • 3.
  • 4.
  • 5.
  • 6.

需要关注的几个控制器文件:

prometheus-adapter-deployment.yaml:kubernetes自定义监控指标

blackbox-exporter-deployment.yaml:黑盒监控控制器

kube-state-metrics-deployment.yaml:监听API Server生成有关资源对象的状态指标

setup/prometheus-operator-deployment.yaml:prometheus-operator控制器文件

prometheus-prometheus.yaml:prometheus主控制器文件

alertmanager-alertmanager.yaml:alertmanager主控制器文件

grafana-deployment.yaml:grafana主控制器文件
  • 1.
  • 2.
  • 3.
  • 4.
  • 5.
  • 6.
  • 7.
  • 8.
  • 9.
  • 10.
  • 11.
  • 12.
  • 13.

删除所有资源:

# kubectl delete --ignore-not-found=true -f manifests/ -f manifests/setup
  • 1.
配置Ingress资源对象
cat > prometheus-all-ingress.yaml << 'EOF'
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  namespace: monitoring
  name: prometheus-ingress
spec:
  ingressClassName: nginx
  rules:
  - host: grafana-opera.kubernets.cn  # 访问 Grafana 域名
    http:
      paths:
        - pathType: Prefix
          backend:
            service:
              name: grafana
              port:
                number: 3000
          path: /
  - host: prometheus-opera.kubernets.cn  # 访问 Prometheus 域名
    http:
      paths:
        - pathType: Prefix
          backend:
            service:
              name: prometheus-k8s
              port:
                number: 9090
          path: /
  - host: alertmanager-opera.kubernets.cn  # 访问 alertmanager 域名
    http:
      paths:
        - pathType: Prefix
          backend:
            service:
              name: alertmanager-main
              port:
                number: 9093
          path: /
EOF


#应用
kubectl apply -f prometheus-all-ingress.yaml
  • 1.
  • 2.
  • 3.
  • 4.
  • 5.
  • 6.
  • 7.
  • 8.
  • 9.
  • 10.
  • 11.
  • 12.
  • 13.
  • 14.
  • 15.
  • 16.
  • 17.
  • 18.
  • 19.
  • 20.
  • 21.
  • 22.
  • 23.
  • 24.
  • 25.
  • 26.
  • 27.
  • 28.
  • 29.
  • 30.
  • 31.
  • 32.
  • 33.
  • 34.
  • 35.
  • 36.
  • 37.
  • 38.
  • 39.
  • 40.
  • 41.
  • 42.
  • 43.
  • 44.

访问验证

prometheus

两个Prometheus实例的, Service 添加 sessionAffinity: ClientIP 属性,会根据 ClientIP 来做 session 亲和性,所以我们不用担心请求会到不同的副本上去。

curl prometheus-opera.kubernets.cn
  • 1.

Prometheus Operator部署/管理Prometheus Server_github_03

granfana
curl grafana-opera.kubernets.cn
  • 1.

Prometheus Operator部署/管理Prometheus Server_sed_04

alertmanager
curl alertmanager-opera.kubernets.cn
  • 1.

总结

  • Prometheus整体监控结构略微复杂,一个个部署并不简单,kube-prometheus大大提升了部署的方式;
  • 通过自定义资源CRD维护简单,不用再次维护大量的configmap配置文件,操作流程大大简化;
  • Kube-Prometheus 则提供了更加全面的监控解决方案,包括 Prometheus、Grafana 和 Alertmanager 等组件;
  • CoreOS主推Kube-Prometheus,目前是k8s集群监控的主流项目。

数据持久化

prometheus数据持久化

默认Prometheus和Grafana不做数据持久化,那么服务重启以后配置的Dashboard、账号密码、监控数据等信息将会丢失,所以做数据持久化也是很有必要的。

原始的数据是以 emptyDir 形式存放在pod里面,生命周期与pod相同,出现问题时,容器重启,监控相关的数据就全部消失了。

vim manifests/prometheus-prometheus.yaml    //加入如下内容
 
# 新增持久化存储,yaml 末尾添加
  retention: 3d     #加这个参数,表示prometheus数据保留的天数,默认会是1天
  storage:
    volumeClaimTemplate:
      spec:
        storageClassName: nfs-storage
        resources:
          requests:
            storage: 50Gi
            
            
#应用
kubectl apply -f manifests/prometheus-prometheus.yaml
  • 1.
  • 2.
  • 3.
  • 4.
  • 5.
  • 6.
  • 7.
  • 8.
  • 9.
  • 10.
  • 11.
  • 12.
  • 13.
  • 14.
  • 15.

Prometheus Operator部署/管理Prometheus Server_自定义_05

grafana数据持久化

先手动创建grafana的持久化PVC:

vim manifests/grafana-pvc.yaml				//加入如下内容

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: grafana-pvc
  namespace: monitoring
spec:
  accessModes:
  - ReadWriteMany
  resources:
    requests:
      storage: 5Gi
  storageClassName: nfs-storage
  
  
 #应用
 kubectl apply -f manifests/grafana-pvc.yaml
  • 1.
  • 2.
  • 3.
  • 4.
  • 5.
  • 6.
  • 7.
  • 8.
  • 9.
  • 10.
  • 11.
  • 12.
  • 13.
  • 14.
  • 15.
  • 16.
  • 17.
  • 18.
vim manifests/grafana-deployment.yaml   //修改该配置文件

      volumes:
#      - emptyDir: {}           # 注释此两行,新增下三行
#        name: grafana-storage
      - name: grafana-storage
        persistentVolumeClaim:
          claimName: grafana-pvc
      - name: grafana-datasources
        secret:
          secretName: grafana-datasources
  • 1.
  • 2.
  • 3.
  • 4.
  • 5.
  • 6.
  • 7.
  • 8.
  • 9.
  • 10.
  • 11.

Prometheus Operator部署/管理Prometheus Server_sed_06

为了固定grafana的登录密码,也可以添加环境变量,添加方式参考如下

       readinessProbe:
          httpGet:
            path: /api/health
            port: http
        env:                                #添加环境变量
        - name: GF_SECURITY_ADMIN_USER      #添加环境变量
          value: admin                      #添加环境变量
        - name: GF_SECURITY_ADMIN_PASSWORD  #添加环境变量
          value: admin                      #添加环境变量
        resources:
          limits:
            cpu: 200m
            memory: 200Mi
  • 1.
  • 2.
  • 3.
  • 4.
  • 5.
  • 6.
  • 7.
  • 8.
  • 9.
  • 10.
  • 11.
  • 12.
  • 13.

优化配置

 grafana-kubernetes-app 插件

kubectl exec -it $(kubectl get pod -n monitoring -l app.kubernetes.io/name=grafana -o jsonpath='{.items[*].metadata.name}') -n monitoring -- sh


/usr/share/grafana $ grafana-cli plugins install grafana-piechart-panel

/usr/share/grafana $ grafana-cli plugins install camptocamp-prometheus-alertmanager-datasource

/usr/share/grafana $ grafana-cli plugins install grafana-kubernetes-app
  • 1.
  • 2.
  • 3.
  • 4.
  • 5.
  • 6.
  • 7.
  • 8.

grafana dashboard 时区默认为UTC,比北京时间慢了8小时,很不便于日常监控查看,这里可以修改

cd ./kube-prometheus/manifests

sed -i 's/UTC/UTC+8/g'  grafana-dashboardDefinitions.yaml

kubectl apply -f grafana-dashboardDefinitions.yaml 
  • 1.
  • 2.
  • 3.
  • 4.
  • 5.

Prometheus Operator部署/管理Prometheus Server_自定义_07

如何修改alert rule?

通过rule规则修改
## edit
kubectl edit cm  prometheus-k8s-rulefiles-0  -n monitoring 
  • 1.
  • 2.
修改配置文件方式
cd ./kube-prometheus/manifests

vim kubernetes-prometheusRule.yaml  //打开该文件 保留自己需要的然后应用即可

### 应用
kubectl apply kubernetes-prometheusRule.yaml
  • 1.
  • 2.
  • 3.
  • 4.
  • 5.
  • 6.

AlterManager报警配置

这里给出精简版本,详细可以参考 kube-prometheus/manifests/alertmanager-secret.yaml

cat << EOF > alertmanager-prometheusAlert.yaml
apiVersion: v1
kind: Secret
metadata:
  labels:
    app.kubernetes.io/component: alert-router
    app.kubernetes.io/instance: main
    app.kubernetes.io/name: alertmanager
    app.kubernetes.io/part-of: kube-prometheus
    app.kubernetes.io/version: 0.24.0
  name: alertmanager-main
  namespace: monitoring
stringData:
  alertmanager.yaml: |-
    global:
      resolve_timeout: 5m
    route:
      group_by: ['env','instance','type','group','job','alertname','cluster']
      group_wait: 10s
      group_interval: 2m
      repeat_interval: 10m
      receiver: 'webhook'
    receivers:
    - name: 'webhook'
      webhook_configs:
      - url: 'http://prometheus-alert-center.monitor.svc:8080/prometheusalert?type=wx&tpl=prometheus-wx&wxurqq.com/cgi-bin/webhook/send?key=71c0a6f0-43a0-4ecf-b8c9-52aff88f3b68&at=ZhangDaDan,ZHDYA'
        send_resolved: true
type: Opaque
EOF


#应用
kubectl apply -f alertmanager-prometheusAlert.yaml
  • 1.
  • 2.
  • 3.
  • 4.
  • 5.
  • 6.
  • 7.
  • 8.
  • 9.
  • 10.
  • 11.
  • 12.
  • 13.
  • 14.
  • 15.
  • 16.
  • 17.
  • 18.
  • 19.
  • 20.
  • 21.
  • 22.
  • 23.
  • 24.
  • 25.
  • 26.
  • 27.
  • 28.
  • 29.
  • 30.
  • 31.
  • 32.
  • 33.