使用prometheus+grafana监控k8s集群

最新推荐文章于 2024-09-16 13:46:32 发布

dayi_123

最新推荐文章于 2024-09-16 13:46:32 发布

阅读量1.4w

点赞数 7

分类专栏： docker&k8s 文章标签： prometheus k8s grafana kubernetes operator

本文链接：https://blog.csdn.net/dayi_123/article/details/111412012

版权

docker&k8s 专栏收录该内容

23 篇文章 1 订阅

订阅专栏

Prometheus官网地址：https://prometheus.io/

GitHub地址：https://github.com/prometheus/prometheus

一、prometheus的安装

Prometheus是最初由SoundCloud开发的监控和警报工具，于2016年加入了 Cloud Native Computing Foundation，这是继Kubernetes之后的第CNC的二个托管项目。

1、prometheus的特征

（1）具有由metric名称和键/值对标识的时间序列数据的多维数据模型

（2）有⼀个灵活的查询语⾔

（3）不依赖分布式存储，只和本地磁盘有关

（4）通过HTTP的服务拉取时间序列数据

（5）⽀持推送的⽅式来添加时间序列数据

（6）⽀持通过服务发现或静态配置发现⽬标

（7）多种图形和仪表板⽀持

2、prometheus的组件

Prometheus生态系统包含许多组件，部分组件是可选组件，主要的组件如下：

（1）Prometheus Server：⽤于抓取指标、存储时间序列数据

（2）exporter：暴露指标让任务来抓

（3）pushgateway：push的⽅式将指标数据推送到该⽹关

（4）alertmanager：处理报警的报警组件

（5）adhoc：⽤于数据查询的组件

3、prometheus的安装

Prometheus的二进制安装非常简单，只需要在prometheus的官方网站下载对应版本的二进制包，可通过prometheus的程序制定配置文件即可启动。此处我的prometheus运行在k8s集群中，所以我通过deployment控制器去运行prometheus运行。

（1）创建prometheus配置文件

默认的prometheus的配置为如下：

~]# cat prometheus-2.21.0.linux-386/prometheus.yml | grep -Ev "^#|^[[:space:]]{1,}#|^$"
global:
  scrape_interval:     15s # Set the scrape interval to every 15 seconds. Default is every 1 minute.
  evaluation_interval: 15s # Evaluate rules every 15 seconds. The default is every 1 minute.
alerting:
  alertmanagers:
  - static_configs:
    - targets:
rule_files:
scrape_configs:
  - job_name: 'prometheus'
    static_configs:
    - targets: ['localhost:9090']

Prometheus的主要几个配置参数说明如下：

1）scrape_interval：表示 prometheus 抓取指标数据的频率，默认是15s

2）evaluation_interval：⽤来控制评估规则的频率，prometheus使⽤规则产⽣新的时间序列数据或者产⽣警报

3）rule_files 模块制定了规则所在的位置，prometheus可以根据这个配置加载规则，⽤于⽣成新的时间序列数据或者报警信息

4）scrape_configs：⽤于控制prometheus监控哪些资源。由于 prometheus通过HTTP的⽅式来暴露的它本身的监控数据，prometheus也能够监控本身的健康情况。在默认的配置⾥有⼀个单独的job叫做prometheus,它采集prometheus 服务本身的时间序列数据。这个job包含了⼀个单独的、静态配置的⽬标：监听localhost上的9090端⼝。prometheus 默认会通过⽬标的/metrics路径采集metrics。

为了方便在k8s中prometheus使用配置文件，我们需要将配置文件通过ConfigMap的形式进行管理

# 定义所有的资源之前先创建一个名称空间
~]# kubectl create namespace prometheus
# 定义prometheus的configmap资源
]# cat prometheus-cm.yaml 
apiVersion: v1
kind: ConfigMap
metadata:
  name: prometheus-config
  namespace: prometheus
data:
  prometheus.yml: |
    global:
      scrape_interval: 15s
      evaluation_interval: 15s
    scrape_configs:
    - job_name: 'prometheus'
      static_configs:
      - targets: ['localhost:9090']
# 创建资源
]# kubectl apply -f prometheus-cm.yaml 
configmap/prometheus-config created

（2）为prometheus中的数据库创建存储资源

为了防止prometheus所在的pod故障导致数据丢失，我们需要为prometheus的TSDB创建一个pvc。这里使用之前创建的基于nfs的存储类实现动态的pv供给。

# 定义pvc资源
]# cat prometheus-pvc.yaml 
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: prometheus
  namespace: prometheus
  annotations:
    volume.beta.kubernetes.io/storage-class: "managed-nfs-storage"
spec:
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      storage: 5Gi
# 创建资源
]# kubectl apply -f prometheus-pvc.yaml 
persistentvolumeclaim/prometheus created

（3）通过rbac为prometheus授权

由于prometheus需要访问Kubernetes集群中的相关信息，所以我们需要为prometheusc创建一个ServiceAccount，并授予相关的权限。

# 定义sa资源
]# cat prometheus-sa.yaml 
apiVersion: v1
kind: ServiceAccount
metadata:
  name: prometheus
  namespace: prometheus
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata: 
  name: prometheus
  namespace: prometheus
rules:
- apiGroups:
  - ""
  resources:
  - nodes
  - services
  - endpoints
  - pods
  - nodes/proxy
  verbs:
  - get
  - list
  - watch
- apiGroups:
  - ""
  resources:
  - configmaps
  - nodes/metrics
  verbs:
  - get
- nonResourceURLs:
  - /metrics
  verbs:
  - get
---
kind: ClusterRoleBinding 
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: prometheus
  namespace: prometheus
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: prometheus
subjects:
- kind: ServiceAccount
  name: prometheus
  namespace: Prometheus
# 创建sa资源
]# kubectl apply -f prometheus-sa.yaml 
serviceaccount/prometheus created
clusterrole.rbac.authorization.k8s.io/prometheus created
clusterrolebinding.rbac.authorization.k8s.io/prometheus created

（4）为prometheus创建deployment控制器

相关的配置文件及依赖的存储资源定义好之后就可以为prometheus创建deployment控制器。

# 定义deployment控制器资源
]# cat prometheus-deployment.yaml 
apiVersion: apps/v1
kind: Deployment
metadata:
  name: prometheus
  namespace: prometheus
  labels:
    app: prometheus
spec:
  selector:
    matchLabels:
      app: prometheus
  template:
    metadata:
      labels:
        app: prometheus
    spec:
      serviceAccountName: prometheus
      containers:
      - image: prom/prometheus:v2.21.0
        name: prometheus
        command:
        - "/bin/prometheus"
        args:
        - "--config.file=/etc/prometheus/prometheus.yml"
        - "--storage.tsdb.path=/prometheus"
        - "--storage.tsdb.retention=24h"
        #控制对adminHTTPAPI的访问，其中包括删除时间序列等功能
        - "--web.enable-admin-api" 
        #⽀持热更新，直接执⾏localhost:9090/-/reload⽴即⽣效	
        - "--web.enable-lifecycle"
        ports:
        - containerPort: 9090
          protocol: TCP
          name: http
        volumeMounts:
        - mountPath: "/prometheus"
          subPath: prometheus
          name: data
        - mountPath: "/etc/prometheus"
          name: config-volume
        resources:
          requests:
            cpu: 200m
            memory: 512Mi
          limits:
            cpu: 200m
            memory: 512Mi
      # 由于prometheusdocker中是以nobody身份运行，所以要定义该项
      securityContext:
        runAsUser: 0  
      volumes: 
      - name: data
        persistentVolumeClaim:
          claimName: prometheus
      - configMap:
          name: prometheus-config
        name: config-volume
# 创建并查看运行状态
]# kubectl apply -f prometheus-deployment.yaml 
deployment.apps/prometheus created
]# kubectl get pods -n prometheus
NAME                         READY   STATUS    RESTARTS   AGE
prometheus-97bf69799-64n7w   1/1     Running   0          9s

（5）定义service资源通过集群外部访问

Prometheus的pod控制器创建成功后，为了便于在k8s集群外部访问prometheus，我们需要为k8s集群创建nodeport类型的service资源。

# 定义service资源
]# cat prometheus-svc.yaml 
apiVersion: v1
kind: Service
metadata:
  name: prometheus
  namespace: prometheus
  labels:
    app: prometheus
spec:
  selector:
    app: prometheus
  type: NodePort
  ports:
  - name: web
    port: 9090
targetPort: 9090
# 创建并查看service资源
]# kubectl apply -f prometheus-svc.yaml 
service/prometheus created
]# kubectl get svc -n prometheus
NAME         TYPE       CLUSTER-IP     EXTERNAL-IP   PORT(S)          AGE
prometheus   NodePort   10.111.61.27   <none>        9090:31736/TCP   16s

至此，prometheus监控已经在k8s集群中安装完毕，可以通过node节点ip加映射至node节点的端口号去访问设置prometheus监控。

二、prometheus的使用

Prometheus的监控数据指标是通过⼀个公开的（HTTP(S)）数据接⼝获取到的，不需要单独安装监控的agent，只需要暴露⼀个metrics接⼝，Prometheus就会定期去拉取数据；对于⼀些普通的HTTP服务，我们完全可以直接给这个服务添加⼀个/metrics接⼝暴露给 Prometheus；⽽且获取到的指标数据格式是⾮常易懂的，不需要太⾼的学习成本。现在很多服务从⼀开始就内置了⼀个/metrics 接⼝，⽐如Kubernetes的各个组件；有⼀些服务即使没有原⽣集成该接⼝，也完全可以使⽤⼀些exporter来获取到指标数据⽐如mysqld_exporter、node_exporter,类似于传统监控服务中的agent。

1、kubernetes集群节点的监控

（1）集群节点需要监控的内容

1）kubernetes集群node几点的监控，包括cpu,内存，负载、磁盘等

2）内部系统组件的状态：⽐如kube-scheduler、kube-controller-manager、kubedns/coredns等组件的详细运⾏状态

3）编排级的资源：⽐如Deployment的状态、资源请求、调度和API 延迟等数据指标

（2）kubernetes集群的监控方案

1）Heapster：Heapster是⼀个集群范围的监控和数据聚合⼯具，以 Pod 的形式运⾏在集群中，目前Heapster已经被metrics-server所代替。

2）cAdvisor：cAdvisor是 Google 开源的容器资源监控和性能分析⼯具，它是专⻔为容器⽽⽣，本身也⽀持 Docker 容器，在 Kubernetes 中，我们不需要单独去安装，cAdvisor 作为 kubelet 内置的⼀部分程序可以直接使⽤。

3）Kube-state-metrics：kube-state-metrics通过监听API Server⽣成有关资源对象的状态指标，⽐如Deployment、Node、Pod，需要注意的是kube-state-metrics只是简单提供⼀个metrics数据，并不会存储这些指标数据，所以我们可以使⽤Prometheus 来抓取这些数据然后存储。

4）metrics-server：metrics-server也是⼀个集群范围内的资源数据聚合⼯具，是Heapster的替代品，同样metrics-server也只是显示数据，并不提供数据存储服务。

在上述监控方案中，kube-state-metrics主要关注的是业务相关的⼀些元数据，⽐如Deployment、Pod、副本状态等，而metrics-server主要关注的是资源度量API的实现，⽐如CPU、⽂件描述符、内存、请求延时等指标

（3）使用Prometheus监控集群节点

使用Prometheus监控node节点，可以通过node_exporter服务来获取监控数据， node_exporter就是抓取⽤于采集服务器节点的各种运⾏指标，⽬前 node_exporter⽀持⼏乎所有常⻅的监控点。

node_exporter服务监控各节点可通过DaemonSet 控制器来部署，这样可以保证每个节点都可以运行一个该服务，即使节点扩容，也可保证在新节点上运行该服务。

# node_exporter服务的DaemonSet控制器资源清单
]# cat prome-node-exporter.yaml 
apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: node-exporter
  namespace: prometheus
  labels:
    name: node-exporter
spec:
  selector:
    matchLabels:
      name: node-exporter
  template:
    metadata:
      labels:
        name: node-exporter
    spec:
      # 使用宿主机pid、ipc、network命名空间
      hostPID: true
      hostIPC: true
      hostNetwork: true
      containers:
      - name: node-exporter
        image: prom/node-exporter:v1.0.1
        ports:
        - containerPort: 9100
        resources:
          requests:
            cpu: 0.15
        securityContext:
          privileged: true
        args:
        - --path.procfs
        - /host/proc
        - --path.sysfs
        - /host/sys
        - --collector.filesystem.ignored-mount-points
        - '"^/(sys|proc|dev|host|etc)($|/)"'
        volumeMounts:
        - name: dev
          mountPath: /host/dev
        - name: proc
          mountPath: /host/proc
        - name: sys
          mountPath: /host/sys
        - name: rootfs
          mountPath: /rootfs
      tolerations:
      - key: "node-role.kubernetes.io/master"
        operator: "Exists"
        effect: "NoSchedule"
      volumes:
        - name: proc
          hostPath:
            path: /proc
        - name: dev
          hostPath:
            path: /dev
        - name: sys
          hostPath:
            path: /sys
        - name: rootfs
          hostPath:
            path: /
# 创建并查看资源你运行情况
]# kubectl apply -f prome-node-exporter.yaml
]# kubectl get pods -n prometheus
NAME                         READY   STATUS    RESTARTS   AGE
node-exporter-dxbfn          1/1     Running   0          4m54s
node-exporter-fncvm          1/1     Running   0          4m54s
node-exporter-s6jbf          1/1     Running   0          4m51s

通过DaemonSet控制器管理的node-exporter服务是共享了宿主机的网络名称空间，所以该pod运行起来后，各node节点会监听9100端口，所以我们可通过9100端口去获取监控数据。

# 查看各节点node-export监听端口
]# netstat -lntp | grep node_exporter
tcp6       0      0 :::9100                 :::*                    LISTEN      41458/node_exporter 
# 查看监控数据
]# curl localhost:9100/metrics | more
# TYPE go_gc_duration_seconds summary
go_gc_duration_seconds{quantile="0"} 0
go_gc_duration_seconds{quantile="0.25"} 0
go_gc_duration_seconds{quantile="0.5"} 0
go_gc_duration_seconds{quantile="0.75"} 0
go_gc_duration_seconds{quantile="1"} 0
go_gc_duration_seconds_sum 0
go_gc_duration_seconds_count 0
# HELP go_goroutines Number of goroutines that currently exist.
# TYPE go_goroutines gauge
go_goroutines 6

（4）配置服务发现

各节点的node-exporter服务运行起来后，我们需要配置prometheus去发现这些服务，并获取数据；配置prometheus发现服务是通过修改ConfigMap配置实现的，我们需要将监控的服务加入配置，并重新创建该配置文件使之生效。

# node服务发现配置如下
]# cat prometheus-cm.yaml 
……
    - job_name: 'kubernetes-nodes'
      kubernetes_sd_configs:
      - role: node
# 重新加载配置
]# kubectl apply -f prometheus-cm.yaml 
configmap/prometheus-config configured
# 使配置生效
]# curl -XPOST "http://192.168.16.132:31736/-/reload"

上面的操作完成后，登录prometheus发现prometheus已经发现了三个节点，但是获取不到数据，这是因为prometheus去发现Node服务的时候，访问的端⼝默认是10250，但是此处我们指定了hostNetwork=true，所以在每个节点上就会绑定⼀个端⼝9100获取数据，我们需要将10250替换成9100。

此处可使用Prometheus的relabel_configs中的replace进行替换。relabel可以在Prometheus采集数据之前，通过Target实例的 Metadata信息，动态重新写⼊Label的值。

# 匹配__address__Label标签，替换端⼝
]# cat prometheus-cm.yaml 
……
    - job_name: 'kubernetes-nodes'
      kubernetes_sd_configs:
      - role: node
      relabel_configs:
      - source_labels: [__address__]
        regex: '(.*):10250'
        replacement: '${1}:9100'
        target_label: __address__
        action: replace
# 重新加载配置
]# kubectl apply -f prometheus-cm.yaml 
configmap/prometheus-config configured
# 重新加载使配置生效
]# curl -XPOST "http://192.168.16.132:31736/-/reload"

上面操作完成之后，再去查看prometheus就可以正常获取数据。

- job_name: 'kubernetes-nodes'
      kubernetes_sd_configs:
      - role: node
      relabel_configs:
      - source_labels: [__address__]
        regex: '(.*):10250'
        replacement: '${1}:9100'
        target_label: __address__
        action: replace
      # 将	Kubernetes的Label标签添加为Prometheus的指标标签：
      - action: labelmap
        regex: __meta_kubernetes_node_label_(.+*)
# 使配置生效并重新加载
]# kubectl apply -f prometheus-cm.yaml 
configmap/prometheus-config configured
]# curl -XPOST "http://192.168.16.132:31736/-/reload"

我们监控的node的节点在prometheus中只显示一个标签，这对于后续的查询等操作不提便利，如果需要显示个node节点的所有标签，可通过labelmap 这个属性将Kubernetes节点的Label标签添加为 Prometheus的指标标签：

- job_name: 'kubernetes-nodes'
      kubernetes_sd_configs:
      - role: node
      relabel_configs:
      - source_labels: [__address__]
        regex: '(.*):10250'
        replacement: '${1}:9100'
        target_label: __address__
        action: replace
      # 将	Kubernetes的Label标签添加为Prometheus的指标标签：
      - action: labelmap
        regex: __meta_kubernetes_node_label_(.+*)
# 使配置生效并重新加载
]# kubectl apply -f prometheus-cm.yaml 
configmap/prometheus-config configured
]# curl -XPOST "http://192.168.16.132:31736/-/reload"

__meta_kubernetes_node_label 只是 kubernetes_sd_configs其中一个标签，更多的标签可参考官方文档（https://prometheus.io/docs/prometheus/latest/configuration/configuration/#%3Ckubernetes_sd_config%3E）

（5）常用服务的监控

很多服务内置了⼀个/metrics接⼝，针对这类服务的监控我们可以通过接口获取相关的监控指标数据。有些服务没有该接口，我们需要利⽤exporter服务来为Prometheus提供指标数据。Prometheus官⽅为许多应⽤就提供了exporter应⽤，也有许多第三⽅的实现具体可参考prometheus官方文档（https://prometheus.io/docs/instrumenting/exporters/）。

# nginx的基于exporter监控的deployment的资源配置文件
]# cat redis-exporter.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: redis
spec:
  selector:
    matchLabels:
      app: redis-exporter
  template:
    metadata:
      annotations:
        prometheus.io/scrape: "true"
        prometheus.io/port: "9121"
      labels:
        app: redis-exporter
    spec:
      containers:
      - name: redis
        image: redis:4
        resources:
          requests:
            cpu: 100m
            memory: 100Mi
        ports:
        - containerPort: 6379
      - name: redis-exporter
        image: oliver006/redis_exporter:latest
        resources:
          requests:
            cpu: 100m
            memory: 100Mi
        ports:
        - containerPort: 9121
---
kind: Service
apiVersion: v1
metadata:
  name: redis
spec:
  selector:
    app: redis-exporter
  ports:
  - name: redis
    port: 6379
    targetPort: 6379
  - name: prom
    port: 9121
    targetPort: 9121

上面的资源创建完成后就可以通过9121端口去采集/metric数据。然后在prometheus配置文件中追加redis的配置并重新加载下配置就可在prometheus中获取redis的监控指标。

# Prometheus的configmap中追加redis配置
]# cat prometheus-cm.yaml
. . . . . .
    - job_name: "redis"
      static_configs:
      - targets: ['redis.default.svc:9121']
# 重新加载配置
]# kubectl apply -f prometheus-cm.yaml 
configmap/prometheus-config unchanged
# 使配置生效
]# curl -XPOST "http://192.168.16.132:31736/-/reload"

2、监控kubernetes常用资源对象

（1）容器的监控

对于容器的监控，则使用cAdvisor，而cAdvisor则已经内置在了 kubelet 组件之

中，所以不需要单独去安装， cAdvisor 的数据路径为 /api/v1/nodes/<node>/proxy/metrics。

对于容器的监控我们同样使用node 的服务发现模式，因为每⼀个节点下⾯都有 kubelet，⾃然都有cAdvisor采集到的数据指标。而使用cAdvisor监控kubernetes集群资源时需要使用https 的协议，https协议需要用到ca.cart 和 token 这两个⽂件，这两个文件在所有的pod启动时，kubernetes已经注入到了该pod中。

监控容器的configmap配置文件如下：

]# cat prometheus-cm.yaml
. . . . . . 
    - job_name: 'kubernetes-cadvisor'
      kubernetes_sd_configs:
      - role: node
      scheme: https
      tls_config:
        ca_file: /var/run/secrets/kubernetes.io/serviceaccount/ca.crt
      bearer_token_file: /var/run/secrets/kubernetes.io/serviceaccount/token
      relabel_configs:
      - action: labelmap
        regex: __meta_kubernetes_node_label_(.+)
      - target_label: __address__
        replacement: kubernetes.default.svc:443
      - source_labels: [__meta_kubernetes_node_name]
        regex: (.+)
        target_label: __metrics_path__
        replacement: /api/v1/nodes/${1}/proxy/metrics/cadvisor
# 重新加载配置
]# kubectl apply -f prometheus-cm.yaml 
configmap/prometheus-config unchanged
# 使配置生效
]# curl -XPOST "http://192.168.16.132:31736/-/reload"

（2）监控kubelet

由于cAdvisor集成在了kubelet组件内，所以kubelet的监控也可通过cAdvisor来实现，kubelet的数据路径为：/api/v1/nodes/[节点名称]/proxy/metrics。监控configmap的configmap配置文件通监控容器的配置基本是一致的。

# 监控kubelet的configmap配置文件
]# cat prometheus-cm.yaml
. . . . . . 
    - job_name: 'kubernetes-cadvisor'
      kubernetes_sd_configs:
      - role: node
      scheme: https
      tls_config:
        ca_file: /var/run/secrets/kubernetes.io/serviceaccount/ca.crt
      bearer_token_file: /var/run/secrets/kubernetes.io/serviceaccount/token
      relabel_configs:
      - action: labelmap
        regex: __meta_kubernetes_node_label_(.+)
      - target_label: __address__
        replacement: kubernetes.default.svc:443
      - source_labels: [__meta_kubernetes_node_name]
        regex: (.+)
        target_label: __metrics_path__
        replacement: /api/v1/nodes/${1}/proxy/metrics/cadvisor
# 重新加载配置
]# kubectl apply -f prometheus-cm.yaml 
configmap/prometheus-config unchanged
# 使配置生效
]# curl -XPOST "http://192.168.16.132:31736/-/reload"

(3)监控apiserver

apiserver作为Kubernetes最核⼼的组件，是非常有必要对其进行监控的，对于apiserver的监控可以直接通过kubernetes 的Service来获取

# 查看默认的svc
]# kubectl get svc
NAME           TYPE      CLUSTER-IP   EXTERNAL-IP   PORT(S)      AGE
kubernetes     ClusterIP   10.96.0.1      <none>  443/TCP       132d
mysqlendpoints ClusterIP   10.102.60.55   <none>  3306/TCP      124d

要⾃动发现Service类型的服务，我们就需要⽤到role为Endpoints的kubernetes_sd_configs，我们可以在 ConfigMap对象中添加上⼀个Endpoints 类型的服务的监控任务。然后将我们自己需要的服务过滤出来。

Apiserver的svc默认为namespace为default的，服务名为 kubernetes的元数据。所以可以通过可以根据对应的__meta_kubernetes_namespace和__meta_kubernetes_service_name这两个元数据来过滤保留相关的svc。而此处则通过keep而非replace这个动作把符合我们要求的给保留下。

# 监控apiservice的configmap配置
]# cat prometheus-cm.yaml
    - job_name: 'apiservers'
      kubernetes_sd_configs:
      - role: endpoints
      scheme: https
      tls_config:
        ca_file: /var/run/secrets/kubernetes.io/serviceaccount/ca.crt
      bearer_token_file: /var/run/secrets/kubernetes.io/serviceaccount/token
      relabel_configs:
      - source_labels: [__meta_kubernetes_namespace, __meta_kubernetes_service_name, __meta_kubernetes_endpoint_port_name]
        action: keep
        regex: default;kubernetes;https
# 重新加载配置
]# kubectl apply -f prometheus-cm.yaml 
configmap/prometheus-config unchanged
# 使配置生效
]# curl -XPOST "http://192.168.16.132:31736/-/reload"

（4）service的监控

K8s中的apiserver是⼀种特殊的svc,如果需要监控其他的svc，需要在role为Endpoints的kubernetes_sd_configs中根据需求帅选出符合条件的svc进行监控。

# 监控符合条件的svc
- job_name: kubernetes-service-endpoints
      kubernetes_sd_configs:
      - role: endpoints
      relabel_configs:
      - action: keep
        regex: true
        source_labels:
        - __meta_kubernetes_service_annotation_prometheus_io_scrape
      - action: replace
        regex: (https?)
        source_labels:
        - __meta_kubernetes_service_annotation_prometheus_io_scheme
        target_label: __scheme__
      - action: replace
        regex: (.+)
        source_labels:
        - __meta_kubernetes_service_annotation_prometheus_io_path
        target_label: __metrics_path__
      - action: replace
        regex: ([^:]+)(?::\d+)?;(\d+)
        replacement: $1:$2
        source_labels:
        - __address__
        - __meta_kubernetes_service_annotation_prometheus_io_port
        target_label: __address__
      - action: labelmap
        regex: __meta_kubernetes_service_label_(.+)
      - action: replace
        source_labels:
        - __meta_kubernetes_namespace
        target_label: kubernetes_namespace
      - action: replace
        source_labels:
        - __meta_kubernetes_service_name
        target_label: kubernetes_name

在上面的配置中第一项“__meta_kubernetes_service_annotation_prometheus_io_scrap”的帅选条件为Service的annotation区域需要有prometheus.io/scrape=true 的声明。

（5）kube-state-metrics

kube-state-metrics主要是用来监控Kubernetes 集群上的Pod、DaemonSet、Deployment、Job、CronJob 等各种资源对象的状态。kube-state-metrics 的gitlab地址为：https://github.com/kubernetes/kube-state-metrics

对于kube-state-metrics的安装我们只需将gitlab上该项目拉取下来，再通过kubec aply创建即可。

git clone https://github.com/kubernetes/kube-state-metrics.git
]# cd kube-state-metrics-master/examples/standard/
# 在server的metadata下添加annotations
annotations:
  prometheus.io/scraped: "true"
# 创建kube-state-metrics
]# kubectl apply -f ./service.yaml

kube-state-metrics创建完成后需要在prometheus的配置文件中追加配置，抓取带有prometheus.io/scraped: "true"注解的endpoint。

]# cat prometheus-cm.yaml
. . . . . . 
    - job_name: "kube-state-metrics"
      kubernetes_sd_configs:
      - role: endpoints
      relabel_configs:
      - source_labels: [__meta_kubernetes_service_annotation_prometheus_io_scraped]
        action: keep
        regex: true
      - action: labelmap
        regex: __meta_kubernetes_service_label_(.+)
      - source_labels: [__meta_kubernetes_namespace]
        action: replace
        target_label: kubernetes_namespace
      - source_labels: [__meta_kubernetes_service_name]
        action: replace
        target_label: service_name
# 重新加载配置
]# kubectl apply -f prometheus-cm.yaml 
configmap/prometheus-config unchanged
# 使配置生效
]# curl -XPOST http://192.168.16.132:31736/-/reload

上面操作完成后就可以在promeheus的”targets”中看到kube-state-metrics相关数据呢，kube-state-metrics对应的svc有两个端口，在prometheus中显示了两个target。

三、grafana的使用

grafana 是⼀个可视化⾯板，有着⾮常漂亮的图表和布局展示，功能⻬全的度量仪表盘和图形编辑器，⽀持 Graphite、zabbix、InfluxDB、Prometheus、OpenTSDB、Elasticsearch 等作为数据源，⽐Prometheus⾃带的图表展示功能更强大更炫；并且有丰富的插件。

1、grafana的安装

Grafana的各种安装方法见官方文档（https://grafana.com/docs/grafana/latest/）。grafana在docker中运行直接执行命令” docker run -d --name=grafana -p 3000:3000 grafana/grafana”即可。此处的安装我们同prometheus一样，将grafana通过deployment控制器运行k8s中，再通过svc访问。需要注意的是>=5.1的版本运行的userID是472。

# 创建一个基于nfs storage class的pvc
]# cat grafana-pvc.yaml 
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: grafana
  namespace: prometheus
  annotations:
    volume.beta.kubernetes.io/storage-class: "managed-nfs-storage"
spec:
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      storage: 2Gi
]# kubectl apply -f grafana-pvc.yaml
# 创建基于deployment控制器的pod
]# cat grafana-deployment.yaml 
apiVersion: apps/v1
kind: Deployment
metadata:
  name: grafana
  namespace: prometheus
  labels:
    app: grafana
spec:
  revisionHistoryLimit: 10
  selector:
    matchLabels:
      app: grafana
  template:
    metadata:
      labels:
        app: grafana
    spec:
      containers:
      - name: grafana
        image: grafana/grafana:7.3.2
        imagePullPolicy: IfNotPresent
        ports:
        - containerPort: 3000
          name: Grafana
        # 通过环境变量的方式传递用户名密码
        env:
        - name: GF_SECURITY_ADMIN_USER
          value: admin
        - name: GF_SECURITY_ADMIN_PASSWORD
          value: dayi123
        readinessProbe:
          failureThreshold: 10
          httpGet: 
            path: /api/health
            port: 3000
            scheme: HTTP
          initialDelaySeconds: 60
          periodSeconds: 10
          successThreshold: 1
          timeoutSeconds: 30
        livenessProbe:
          failureThreshold: 3
          httpGet:
            path: /api/health
            port: 3000
            scheme: HTTP
          periodSeconds: 10
          successThreshold: 1
          timeoutSeconds: 1
        resources:
          limits:
            cpu: 200m
            memory: 256Mi
          requests:
            cpu: 200m
            memory: 256Mi
        volumeMounts:
        - mountPath: /var/lib/grafana
          subPath: grafana
          name: storage
      # 定义grafana的用户
      securityContext:
        fsGroup: 472
        runAsUser: 472
      volumes:
      - name: storage
        persistentVolumeClaim:
          claimName: grafana
# 创建
]# kubectl apply -f grafana-deployment.yaml
# 创建NodePort类型的svc将grafana暴露出去便于访问
]# cat grafana-svc.yaml 
apiVersion: v1
kind: Service
metadata:
  name: grafana
  namespace: prometheus
  labels:
    app: grafana
spec:
  type: NodePort
  ports:
    - port: 3000
  selector:
    app: Grafana
# 查看创建的svc资源
]# kubectl get svc -n prometheus
NAME       TYPE     CLUSTER-IP   EXTERNAL-IP   PORT(S)            AGE
grafana   NodePort 10.108.43.11   <none>     3000:30380/TCP      5m6s
prometheus NodePort  10.111.61.27  <none>   9090:31736/TCP       55d

上面所有的资源创建完成后我们就可以通过网页去访问grafana。用户名密码为在grafana的deployment中定义用户名密码。

2、使用grafana

Grafana安装完成后就可以使用grafana，首先我们需要配置数据源，登录grafana后，点击“DATA SOURCE”进行数据源的设置。进入后选择“Prometheus”根据自己实际情况进行prometheus的一些相关设置。设置完成后保存即可。数据源设置如下：

数据源设置完成后就可以添加dashboard，dashboard也可以导入通过导入的方式增加，操作如下：

导入以id号为162的dashboard为例，可以将编号ID为162的dashboard下载到本地，然后这⾥重新上传即可，也可以在⽂本框中直接输⼊162编号回⻋导⼊这个 dashboard。

在导入时一定要选择数据源。

Dashboard导入后，dashboard中可能会没有数据，一方面可能是由于prometheus和grafana时间不一致导致的，需要修改时间，另一方面是由于该图表的查询语句无法查询到数据，需要修改查询语句。修改方法为：点击该图像标题，点击下拉框中的“Edit”进行编辑，对查询语句根据实际情况进行调整。

Dashboard id号为162的第一个图像的原查询语法为：

(sum(node_memory_MemTotal) - sum(node_memory_MemFree +node_memory_Buffers +node_memory_Cached) ) / sum(node_memory_MemTotal) * 100

由于prometheus中没有“node_memory_MemTotal”等相关的指标数据，所以根据自己的prometheus中指标将“node_memory_MemTotal”等修改为““node_memory_MemTotal”_bytes”即可查询到数据。

(sum(node_memory_MemTotal_bytes) - sum(node_memory_MemFree_bytes+node_memory_Buffers_bytes+node_memory_Cached_bytes) ) / sum(node_memory_MemTotal_bytes) * 100

第二个图标中的原查询语句为：

sum(sum by (io_kubernetes_container_name)( rate(container_cpu_usage_seconds_total{image!=""}[1m] ) )) / count(node_cpu{mode="system"}) * 100

由于prometheus中存储出的数据中实际标签为“container”,并不存在标签“io_kubernetes_container_name”，所以需要修改为“container”,另一方面node_cpu这样的指标，实际为“node_cpu_seconds_total”，所以修改后的查询语法为：

sum(sum by (container)( rate(container_cpu_usage_seconds_total{image!=""}[1m] ) )) / count(node_cpu_seconds_total{mode="system"}) * 100

第三个图标和第一个图标差不多一样，也是不存在“node_filesystem_size”等这样的数据指标，需要进行修改。

# 原语句为
(sum(node_filesystem_size{device="rootfs"}) - sum(node_filesystem_free{device="rootfs"}) ) / sum(node_filesystem_size{device="rootfs"}) * 100
# 修改后语句为
(sum(node_filesystem_size_bytes{device="rootfs"}) - sum(node_filesystem_free_bytes{device="rootfs"}) ) / sum(node_filesystem_size_bytes{device="rootfs"}) * 100

第四个图表为pod的cpu使用率的图表，然而在prometheus中不存在名称为”io_kubernetes_container_name”该标签，需要将该标签替换为“pod”即可。其他的图表则依据prometheus中数据的实际情况进行调整。图表的查询语句修改完成后部分dashboard的如下：

除了上面的id号为162的dashboard模板为，还有常用的模板还有741（Deployment metrics）、747（Kubernetes Pod Metric）。

3、grafana中安装k8s插件

除了上面通过一些dashboard模板监控k8s集群为，prometheus还提供呢一个插件grafana-kubernetes-app对kubernetes集群进行监控，该插件的官方文档地址为：（https://grafana.com/grafana/plugins/grafana-kubernetes-app/installation）。

（1）安装插件

该插件的安装需要进入到grafana对应的pod中安装，安装完成后需要重启grafana所对应的pod。

# 查看pod
]# kubectl get pods -n prometheus
NAME                         READY   STATUS    RESTARTS   AGE
grafana-5d6f5f45bc-wsps7     1/1     Running   1          7h47m
# 进入pod
]# kubectl exec -it grafana-5d6f5f45bc-wsps7 /bin/sh -n prometheus
# 安装插件
/usr/share/grafana $ grafana-cli plugins install grafana-kubernetes-app
installing grafana-kubernetes-app @ 1.0.1
from: https://grafana.com/api/plugins/grafana-kubernetes-app/versions/1.0.1/download
into: /var/lib/grafana/plugins

✔ Installed grafana-kubernetes-app successfully 

Restart grafana after installing plugins . <service grafana-server restart>
# 退出删除pod(删除后会重新创建，达到了重启的效果)
/usr/share/grafana $ exit
[root@master prometheus]# kubectl delete pods grafana-5d6f5f45bc-wsps7 -n prometheus
pod "grafana-5d6f5f45bc-wsps7" deleted
[root@master prometheus]# kubectl get pods -n prometheus
NAME                         READY   STATUS    RESTARTS   AGE
grafana-5d6f5f45bc-876jx     0/1     Running   0          66s

重启完grafana后，进入到插件页面发现会多了一个kubernetes插件，如下图所示：

（2）配置插件

安装完该插件，我们点击该插件进入插件，在“configuer”中点击“Connect to your Kubernetes Cluster and deploy metric exporters”进行该插件的配置。

配置kubernetes集群需要填写集群的名称。Kubernetes集群的地址（即apiservice地址）及认证方式，认证方式可选择tls证书认证（选择“TLS Client Auth”和“With CA Cert”）。证书文件可将” ~/.kube/config”文件中的内容通过base64解码后使用。

相关的认证信息填写完成后，如果之前没有创建“Node Exporter”和“kube State Metrics”则点击“deploy”进行创建，如果已经创建则点击“save”即可。点击“save”后会在左边的菜单栏出现“kubernetes”的图表。在dashboard中就可以看到相关的dashboard，在新版本的grafana中需要根据prometheus的实际数据对dashboard图标查询语句进行一些调整。

4、grafana监控告警

（1）、配置告警方式

设置grafana的邮件告警，需要在grafana的配置文件“/etc/grafana/grafan.ini”中设置smtp邮件服务器的地址。此处我们将grafana的配置文件通过configmap资源对象挂载到grafana的pod中。

# 创建grafana邮箱告警的configmap
]# cat grafana-cm.yaml 
apiVersion: v1
kind: ConfigMap
metadata:
  name: grafana-config
  namespace: prometheus
data:
  grafana.ini: |
    [server]
    root_url = http://192.168.16.132:30380/
    [smtp]
    enable = true
    host = smtp.163.com:25
    user = dayi_123@163.com
    password = dayi123
    skip_verify = true
    from_address = dayi_123@163.com
    [alerting]
    enabled = true
execute_alerts = true
# 创建
]# kubectl apply -f grafana-cm.yaml
# 将configmap挂载到grafana的pod中
# 修改grafana-deployment.yaml的配置文件,将configmap挂载到pod中
]# cat grafana-deployment.yaml
. . . . . . 
        volumeMounts:
        - mountPath: /var/lib/grafana
          subPath: grafana
          name: storage
        - mountPath: "/etc/grafana"
          name: config
      volumes:
      - name: storage
        persistentVolumeClaim:
          claimName: grafana
      - name: config
        configMap:
          name: grafana-config
# 更新pod
]# kubectl apply -f grafana-deployment.yaml

邮箱smtp设置后就可以设置告警发送到的邮箱等相关的信息。除了可以设置以邮件的方式告警外，还可以设置、钉钉、slack、 webhook等方式告警。设置钉钉告警需要在钉钉群里面添加机器人，类型为自定义机器人，添加完后将webhook 地址添设置钉钉告警的“Webhook URL”下即可。

（2）、设置告警

告警方式设置完成后，需要进行告警相关的设置，告警的设置我们需要先选择Graph相关图表，点击编辑，进⼊Graph编辑⻚⾯可以看到有⼀个Alert模块，点击该模块后点击“create Alert”即可进行告警的相关设置，具体设置根据自己的实际情况进行设置。

四、prometheus的告警功能

由于Grafana只⽀持Graph的图表的报警的报警功能，Grafana的报警功能⽐较弱，所以一般都是用prometheus的报警模块AlertManager进行报警。Alertmanager主要⽤于接收Prometheus发送的告警信息，它⽀持丰富的告警通知渠道，⽽且很容易做到告警信息进⾏去重，降噪，分组等。

1、AlertManager的安装

AlertManager的官⽅⽂档地址为https://prometheus.io/docs/alerting/configuration/；默认的安装方式为下载二进制文件，通过命令“./alertmanager --config.file=simple.yml”即可运行AlertManager。

由于prometheus运行在deployment控制器的pod中，所以将AlertManager的镜像也添加到prometheus所在的pod中。同时将AlerManager的配置文件以configmap的方式挂载到pod中。

# AlertManager的configmap文件
]# cat alertamager-cm.yaml 
apiVersion: v1
kind: ConfigMap
metadata:
  name: alertmanager-cm
  namespace: prometheus
data:
  config.yml: |
global:
  # 在没有报警的情况下声明为已解决的时间
      resolve_timeout: 5m
      # 报警发送的邮箱地址
      smtp_smarthost: 'smtp.126.com'
      smtp_from: 'dayi_123@126.com'
      smtp_auth_username: 'dayi_123@126.com'
      smtp_auth_password: 'xxxxxx'
      smtp_hello: '126.com'
      smtp_require_tls: false
    # 所有报警信息进⼊后的根路由，⽤来设置报警的分发策略
route: 
# 是接收到报警信息后的重新分组标签，
  group_by: ['alertname', 'cluster']
  # 报警分组被创建后，初始化通知时间
      group_wait: 30s
      # 当第⼀个报警发送后，发送新的报警信息的间隔时间。
      group_interval: 5s
      # 如果⼀个报警信息已经发送成功了，重新发送时间
      repeat_interval: 5m
      # 默认的receiver：如果⼀个报警没有被⼀个route匹配，则发送给默认的接收器
      receiver: default
      - receiver: emil
        group_wait: 10s
        match_re:
          team: node
    # 接收邮件的邮箱，可以设置多个
    receivers:
    - name: 'default'
      email_configs:
      - to: 'liuyi@ecmoho.com'
        send_resolved: 'true'
    - name: email
      email_configs:
      - to: 'liuyi@ecmoho.com'
        send_resolved: 'true'
# 创建
]# kubectl apply -f alertamager-cm.yaml 
configmap/alertmanager-cm created

AlertManager的configmap文件创建后，需要修改之前创建的prometheus的deployment的资源配置文件，在pod中新增AlertManager的镜像。即在prometheus的deployment中增加以下配置文件：

#在prometheus-deployment资源清单中配置文件中增加alertmanager镜像
]# cat prometheus-deployment.yaml
. . . . . . 
      - name: alertmanager
        image: prom/alertmanager:v0.21.0
        imagePullPolicy: IfNotPresent
        args:
        - "--config.file=/etc/alertmanager/config.yml"
        ports:
        - containerPort: 9093
          name: http
        volumeMounts:
        - mountPath: "/etc/alertmanager"
          name: alertcfg
        resources:
          requests:
            cpu: 100m
            memory: 256Mi
          limits:
            cpu: 100m
            memory: 256Mi
      - name: alertcfg
        configMap:
          name: alertmanager-cm
# 删除重新创建
]# kubectl delete -f prometheus-deployment.yaml
]# kubectl apply-f prometheus-deployment.yaml
# 同时也可在prometheus的svc中添加alertmanager配置
]# cat prometheus-svc.yaml
. . . . .
  - name: alert 
    port: 9093
    targetPort: 9093
# 重新加载
]# kubectl apply -f prometheus-svc.yaml

2、配置告警

AlertManager的容器启动起来后，我们还需要在Prometheus中配置AlertManager的地址，让Prometheus 能够访问到AlertManager。同时还需通过prometheus配置文件添加告警规则配置。

# 在prometheus中配置文件中配置alertmanager地址
]# cat prometheus-cm.yaml 
. . . . . .
    alerting:
      alertmanagers:
      - static_configs:
        - targets: ["localhost:9093"]
    rule_files:
      - /etc/prometheus/rules.yml
# 配置完成后重新创建并加载
]# kubectl delete -f prometheus-cm.yaml 
configmap "prometheus-config" deleted
]# kubectl apply -f prometheus-cm.yaml 
configmap/prometheus-config created
]# curl -XPOST "http://192.168.16.132:3173

Prometheus配置中告警规则是通过引入rule_files实现的，这⾥我们同样将rules.yml ⽂件⽤ConfigMap的形式挂载到/etc/prometheus⽬录下⾯即可。

# 配置告警规则
]# cat prometheus-cm.yaml 
apiVersion: v1
kind: ConfigMap
metadata:
  name: prometheus-config
  namespace: prometheus
data:
  prometheus.yml: |
. . . . . . 
  rules.yml: |
    groups:
    - name: test-rule
      rules:
      - alert: NodeMemoryUsage
        expr: (node_memory_MemTotal_bytes - (node_memory_MemFree_bytes + node_memory_Buffers_bytes + node_memory_Cached_bytes)) / node_memory_MemTotal_bytes * 100 > 80
        for: 2m
        labels: 
          team: node
        annotations:
          summary: "{{$labels.instance}}: High Memory usage detected"
          description: "{{$labels.instance}}: Memory usage is above 20% (current value is:{{ $value }}"
# 重新创建配置并加载
]# kubectl delete -f prometheus-cm.yaml 
configmap "prometheus-config" deleted
]# kubectl apply -f prometheus-cm.yaml 
configmap/prometheus-config created
]# curl -XPOST "http://192.168.16.132:31736/-/reload"

告警规则中各参数作用如下：

for：使 Prometheus 服务等待指定的时间, 然后执⾏查询表达式。

labels：允许指定额外的标签列表，把它们附加在告警上。

Annotations：指定了另⼀组标签，它们不被当做告警实例的身份标识，它们经常⽤于存储些额外的信息，⽤于报警信息的展示之类的。

除了上面的告警规则外，其余告警规则我们可根据自己需求自定义。如果相关的告警规则被触发我们可以在prometheus的alerts模块中（安装alertmanager后会出现）或alertmanager页面中查看。

3、配置钉钉告警

要使用钉钉告警，首先需要我们定义webhook来接收报警信息，然后在webhook⾥⾯去进⾏告警信息的处理。在github上有人已经做了该项目（https://github.com/timonwong/prometheus-webhook-dingtalk），同时该项目也被人做成docker镜像（https://hub.docker.com/r/timonwong/prometheus-webhook-dingtalk）；我们只需根据自己需求配置使用即可。

在k8s集群中我们也将该webhook运行在deployment控制的pod中。资源清单定义如下：

]# cat ddtalk-hook.yaml 
apiVersion: apps/v1
kind: Deployment
metadata:
  name: ddtalk-hook
  namespace: prometheus
spec:
  selector:
    matchLabels:
      app: ddtalk-hook
  template:
    metadata: 
      labels:
        app: ddtalk-hook
    spec:
      containers:
      - name: ddtalk-hook
        image: timonwong/prometheus-webhook-dingtalk:v1.4.0
        args:
        - --ding.profile=webhook1=https://oapi.dingtalk.com/robot/send?access_token=53630694d60843f17b99e40949afba58fb247995554120bf054037f6111ea59f
        ports:
        - containerPort: 8060
          name: http
        resources:
          requests: 
            cpu: 50m
            memory: 100Mi
          limits:
            cpu: 50m
            memory: 100Mi
---
apiVersion: v1
kind: Service
metadata:
  name: ddtalk-hook
  namespace: prometheus
spec:
  selector:
    app: ddtalk-hook
  ports:
  - name: hook
    port: 8060
    targetPort: http
]# kubectl apply -f ddtalk-hook.yaml

上面资源定义完成后我们需要在alermanager的配置文件中添加一个routes，用于将告警信息发送到接收钉钉告警的服务中。

]# cat alertamager-cm.yaml 
. . . . . .
      routes:
      . . . . . . 
      - receiver: webhook
        group_wait: 10s    
    receivers:
    - name: 'email'
      email_configs:
      - to: 'liuyi@ecmoho.com'
        send_resolved: true
. . . . . .

五、Prometheus Operator 的安装与使用

Operator是由CoreOS公司开发的，⽤来扩展 Kubernetes API，是特定的应⽤程序控制器，它⽤来创建、配置和管理复杂的有状态应⽤，如数据库、缓存和监控系统。Operator基于Kubernetes的资源和控制器概念之上构建，但同时⼜包含了应⽤程序特定的⼀些专业知识，⽐如创建⼀个数据库的Operator，则必须对创建的数据库的各种运维⽅式⾮常了解，创建Operator 的关键是CRD（⾃定义资源）的设计。CRD 是对 Kubernetes API 的扩展，Kubernetes中的每个资源都是⼀个API对象的集合。

Operator 是将运维⼈员对软件操作的知识给代码化，同时利⽤ Kubernetes 强⼤的抽象来管理⼤规模的软件应⽤。

1、Prometheus-Operator

官方文档地址：https://coreos.com/operators/prometheus/docs/latest/user-guides/getting-started.html

Github地址：https://github.com/prometheus-operator/prometheus-operator

Prometheus-operator程序地址：https://github.com/prometheus-operator/kube-prometheus

Prometheus-Operator中Operator是最核⼼的部分，作为⼀个控制器，他会去创建Prometheus、ServiceMonitor、AlertManager以及PrometheusRule 4个 CRD 资源对象，然后会⼀直监控并维持这4个资源对象的状态。prometheus这种资源对象就是作为 Prometheus Server存在，⽽ServiceMonitor就是exporter的各种抽象；exporter是⽤来专⻔提供metrics数据接⼝的⼯具，Prometheus就是通过ServiceMonitor提供的metrics数据接⼝去pull数据的，alertmanager这种资源对象就是对应的AlertManager的抽象，⽽ PrometheusRule是⽤来被Prometheus实例使⽤的报警规则⽂件。这样我们要在集群中监控什么数据，就变成了直接去操作Kubernetes集群的资源对象了。

2、Prometheus-Operator的安装

Prometheus-Operator的安装可以使用源码进⾏安装，也可以⽤Helm来进⾏⼀键安装。使用helm安装只需通过“helm install --name my-release stable/prometheus-operator”命令即可完成安装。使用源码安装的方法如下：

# 下载源码
]# git clone https://github.com/prometheus-operator/kube-prometheus
# 创建相关的名称空间及operator等相关资源
]# cd kube-prometheus/manifests/
]# kubectl apply -f setup/
# 创建prometheus等相关资源
]# kubectl apply -f ./
alertmanager.monitoring.coreos.com/main created
secret/alertmanager-main created
service/alertmanager-main created
serviceaccount/alertmanager-main created
. . . . . .

由于使用prometheus-operator定义的资源数据都是存储在临时挂载目录中，服务重启后数据会丢失，为了保持数据持久化，我们需要创建一个StorageClass （使用之前创建的基于nfs的storageclass）。然后在prometheus的CRD资源对象中添加如下配置：

  storage:
    volumeClaimTemplate:
      spec:
        storageClassName: managed-nfs-storage
        resources:
          requests:
            storage: 5Gi

修改后的promehteus的crd资源定义如下：

# 查看之前创建的storageclass
]# kubectl get storageclass
NAME                  PROVISIONER      RECLAIMPOLICY   VOLUMEBINDINGMODE   ALLOWVOLUMEEXPANSION   AGE
managed-nfs-storage   fuseim.pri/ifs   Delete          Immediate           false                  10
# 修改后的promehteus crd资源
]# cat prometheus-prometheus.yaml 
apiVersion: monitoring.coreos.com/v1
kind: Prometheus
metadata:
  labels:
    prometheus: k8s
  name: k8s
  namespace: monitoring
spec:
  alerting:
    alertmanagers:
    - name: alertmanager-main
      namespace: monitoring
      port: web
  storage:
    volumeClaimTemplate:
      spec:
        storageClassName: managed-nfs-storage
        resources:
          requests:
            storage: 5Gi
  image: quay.io/prometheus/prometheus:v2.22.1
  nodeSelector:
    kubernetes.io/os: linux
  podMonitorNamespaceSelector: {}
  podMonitorSelector: {}
  probeNamespaceSelector: {}
  probeSelector: {}
  replicas: 1
  resources:
    requests:
      memory: 400Mi
  ruleSelector:
    matchLabels:
      prometheus: k8s
      role: alert-rules
  securityContext:
    fsGroup: 2000
    runAsNonRoot: true
    runAsUser: 1000
  serviceAccountName: prometheus-k8s
  serviceMonitorNamespaceSelector: {}
  serviceMonitorSelector: {}
  version: v2.22.1
# 更新配置
]# kubectl apply -f  prometheus-prometheus.yaml

上面的资源创建完成后，会生产相关的svc资源，为了能够正常访问promehteus及grafana我们需要将promehteus及grafana(新版默认为NodePort)的svc修改为NodePort类型。

# 生成的svc
]# kubectl get svc -n monitoring
NAME                 TYPE     CLUSTER-IP    EXTERNAL-IP   PORT(S)   AGE
alertmanager-main  ClusterIP   10.97.233.207    <none>     9093/TCP                     39m
alertmanager-operated   ClusterIP   None      <none>        9093/TCP,9094/TCP,9094/UDP   30m
grafana                 NodePort    10.100.21.231    <none>        3000:30611/TCP               39m
kube-state-metrics      ClusterIP   None             <none>        8443/TCP,9443/TCP            39m
node-exporter           ClusterIP   None             <none>        9100/TCP                     39m
prometheus-adapter      ClusterIP   10.103.4.15      <none>        443/TCP                      39m
prometheus-k8s          ClusterIP   10.105.172.229   <none>        9090/TCP                     39m
prometheus-operated     ClusterIP   None             <none>        9090/TCP                     30m
prometheus-operator     ClusterIP   None             <none>        8443/TCP                     93m
# 修改prometheus的端口类型为NodePort
]# kubectl edit svc prometheus-k8s -n monitoring

上面操作完成后，可登录prometheus查看，k8s集群中大部分资源都已经被监控，而grafana中也已经生成了相关的dashboard。

3、Prometheus-Operator的配置

上面的资源创建后，prometheus已经将k8s集群的大部分资源监控。没有被监控到的资源包括kube-controller-manager和kube-scheduler这两个系统组件。kube-scheduler 组件对应的 ServiceMonitor 资源的定义如下：

]# cat prometheus-serviceMonitorKubeScheduler.yaml 
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  labels:
    k8s-app: kube-scheduler
  name: kube-scheduler
  namespace: monitoring
spec:
  endpoints:
  - bearerTokenFile: /var/run/secrets/kubernetes.io/serviceaccount/token
    interval: 30s
    port: https-metrics
    scheme: https
    tlsConfig:
      insecureSkipVerify: true
  jobLabel: k8s-app
  # 匹配某⼀命名空间中的service，如果想从所有的namespace中匹配⽤any: true
  namespaceSelector:
    matchNames:
    - kube-system
  # 匹配的Service的labels, 如果使⽤mathLabels，则下⾯的所有标签都匹配时才会匹配该service，如果使⽤matchExpressions，则⾄少匹配⼀个标签的service 
  selector:
    matchLabels:
      k8s-app: kube-scheduler

通过监控kube-scheduler的ServiceMonitor资源发现，监控kube-scheduler是通过kube-system名称空间下的标签为k8s-app=kube-scheduler的svc采集监控数据的。而系统中没有该svc，所以监控不到kube-scheduler。需要我们去手动创建一个svc。

]# cat kube-schedule-svc.yaml 
apiVersion: v1
kind: Service
metadata:
  namespace: kube-system
  name: kube-scheduler
  labels:
    k8s-app: kube-scheduler
  annotations:
    prometheus.io/scrape: 'true'
spec:
  selector:
    component: kube-scheduler
  ports:
  - name: http-metrics
    port: 10251
    targetPort: 10251
    protocol: TCP
# 创建
]# kubectl apply -f kube-schedule-svc.yaml

当kube-scheduler的svc创建后，在k8s的监控中已经发现了kube-scheduler的target，但是抓取数据时出错了，这是因为kubeadm搭建的集群中kube-scheduler 默认是绑定在127.0.0.1上⾯的。kube-scheduler绑定的地址更改成 0.0.0.0即可满⾜要求。

# 修改监听地址
]# sed -i "s@host: 127.0.0.1@host: 0.0.0.0@g" /etc/kubernetes/manifests/kube-scheduler.yaml

修改完成后我们将该⽂件从当前⽂件夹中移除，隔⼀会⼉再移回该⽬录，就可以⾃动更新，然后再去看prometheus中kube-scheduler这个targe已经正常。

kube-controller-manager的监控也可按照此方法配置，kube-controller-manager监听的地址是10252，晒选该资源的label是”k8s-app: kube-controller-manager”。

4、自定义Prometheus-Operator监控项

在prometheus的集群中，处理监控集群的组件外,大多数时候我们需要根据业务需求自定义监控想，在promehteus-operator中自定义监控想需要通过以下步骤来完成：

（1）建立ServiceMonitor对象，用户Prometheus添加监控项

（2）为ServiceMonitor对象关联metrics数据接口的Service对象

（3）确保Service对象可以正确获取到metrics数据

Prometheus-operator中并没有etcd的监控，为etcd自动以监控项的操作如下：

# 首先为用到的etcd证书创建一个secret资源
]# kubectl -n monitoring create secret generic etcd-certs --from-file=/etc/kubernetes/pki/etcd/healthcheck-client.crt --from-file=/etc/kubernetes/pki/etcd/healthcheck-client.key --from-file=/etc/kubernetes/pki/etcd/ca.crt 
secret/etcd-certs created
# 查看
]# kubectl get secret etcd-certs -n monitoring
NAME         TYPE     DATA   AGE
etcd-certs   Opaque   3      10m
# 然后将用到的证书配置到prometheus中
]# kubectl edit prometheus k8s -n monitoring
. . . . . .
  ruleSelector:
    matchLabels:
      prometheus: k8s
      role: alert-rules
  secrets:
  - etcd-certs
. . . . . .
# 查看prometheus中的证书
]# kubectl exec -it prometheus-k8s-0 ls /etc/prometheus/secrets/etcd-certs/ -n monitoring
ca.crt                  healthcheck-client.crt  healthcheck-client.key

因为很多时候etcd是独立于集群之外的,所以我们在创建svc的同时需要创建一个Endpoints将etcd代理到k8s集群，然后将svc绑定到Endpoints。需要注意的是svc和Endpoints的metadata区域内容要保持一致。

]# cat etcd-svcendpoints.yaml 
apiVersion: v1
kind: Service
metadata:
  name: etcd-k8s
  namespace: kube-system
  labels:
    k8s-app: etcd
spec:
  type: ClusterIP
  clusterIP: None     
  ports:
  - name: port
    port: 2379          
    protocol: TCP
---
apiVersion: v1
kind: Endpoints
metadata:
  name: etcd-k8s
  namespace: kube-system
  labels:
    k8s-app: etcd
subsets:
- addresses:
  - ip: 192.168.16.131
  ports:
  - port: 2379
# 创建
]# kubectl apply -f etcd-svcendpoints.yaml

Svc资源创建完成后，就需要创建etcd的monitoring资源。由于证书中的serverName 和etcd中签发的可能不匹配，所以加上了在定义etcd的monitor资源时加上了insecureSkipVerify=true。

]# cat etcd-servicemonitor.yaml 
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: etcd-k8s
  namespace: monitoring
  labels:
    k8s-app: etcd-k8s
spec:
  jobLabel: k8s-app
  endpoints:
  - port: port
    interval: 30s
    scheme: https
    tlsConfig:
      caFile: /etc/prometheus/secrets/etcd-certs/ca.crt
      certFile: /etc/prometheus/secrets/etcd-certs/healthcheck-client.crt
      keyFile: /etc/prometheus/secrets/etcd-certs/healthcheck-client.key
      insecureSkipVerify: true
  selector:
    matchLabels:
      k8s-app: etcd
  namespaceSelector:
    matchNames:
    - kube-system
# 创建
]# kubectl apply -f etcd-servicemonitor.yaml

Etcd的监控完成后可以在grafana中导入编号为3070的dashboard,便可获取etcd的监控图表。

5、配置 PrometheusRule

安装完prometheus-operator后自带的监控项已经有了告警规则，我们自定义的监控项就需要我们自定义一些告警规则。手动搭建的prometheus中⾃定义告警需要在 Prometheus的配置⽂件中指定报警的rules⽂件或定义告警规则。Prometheus-operator中自定义告警规则需要创建⼀个具有prometheus=k8s和role=alert-rules标签的

PrometheusRule对象即可。例如添加的etcd的监控项创建告警规则：

]# cat etcd-rules.yaml 
apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
  abels:
    prometheus: k8s
    role: alert-rules
  name: etcd-rules
  namespace: monitoring
spec:
  groups:
  - name: etcd
    rule:
    - alert: EtcdClusterUnavailable
      annotations:
        summary: etcd cluster small
        description: etcd cluster unavailable
      expr: |
        count(up{job="etcd"} == 0) > (count(up{job="etcd"}) / 2 - 1)
      for: 3m
      labels:
        severity: critical
# 创建
]# kubectl apply -f etcd-rules.yaml 
prometheusrule.monitoring.coreos.com/etcd-rules created

pod中的promehteus的告警规则的位置为“/etc/prometheus/rules/prometheus-k8s-rulefiles-0/”。所以该资源创建后实际上会生成一个“<namespace>-<name>.yaml 的⽂件”。

]# kubectl exec -it prometheus-k8s-0 -n monitoring ls /etc/prometheus/rules/prometheus-k8s-rulefiles-0/ 
monitoring-etcd-rules.yaml            monitoring-prometheus-k8s-rules.yaml

6、配置告警

Prometheus-operator中alertmanager的告警配置是通过“kube-prometheus/manifests/alertmanager-secret.yaml”这个配置文件配置的，这个创建后主要配置信息如下：

]# kubectl get secret alertmanager-main -n monitoring -o yaml
apiVersion: v1
data:
  alertmanager.yaml: Imdsb2JhbCI6CiAgInJlc29sdmVfdGltZW91dCI6ICI1bSIKImluaGliaXRfcnVsZXMiOgotICJlcXVhbCI6CiAgLSAibmFtZXNwYWNlIgogIC0gImFsZXJ0bmFtZSIKICAic291cmNlX21hdGNoIjoKICAgICJzZXZlcml0eSI6ICJjcml0aWNhbCIKICAidGFyZ2V0X21hdGNoX3JlIjoKICAgICJzZXZlcml0eSI6ICJ3YXJuaW5nfGluZm8iCi0gImVxdWFsIjoKICAtICJuYW1lc3BhY2UiCiAgLSAiYWxlcnRuYW1lIgogICJzb3VyY2VfbWF0Y2giOgogICAgInNldmVyaXR5IjogIndhcm5pbmciCiAgInRhcmdldF9tYXRjaF9yZSI6CiAgICAic2V2ZXJpdHkiOiAiaW5mbyIKInJlY2VpdmVycyI6Ci0gIm5hbWUiOiAiRGVmYXVsdCIKLSAibmFtZSI6ICJXYXRjaGRvZyIKLSAibmFtZSI6ICJDcml0aWNhbCIKInJvdXRlIjoKICAiZ3JvdXBfYnkiOgogIC0gIm5hbWVzcGFjZSIKICAiZ3JvdXBfaW50ZXJ2YWwiOiAiNW0iCiAgImdyb3VwX3dhaXQiOiAiMzBzIgogICJyZWNlaXZlciI6ICJEZWZhdWx0IgogICJyZXBlYXRfaW50ZXJ2YWwiOiAiMTJoIgogICJyb3V0ZXMiOgogIC0gIm1hdGNoIjoKICAgICAgImFsZXJ0bmFtZSI6ICJXYXRjaGRvZyIKICAgICJyZWNlaXZlciI6ICJXYXRjaGRvZyIKICAtICJtYXRjaCI6CiAgICAgICJzZXZlcml0eSI6ICJjcml0aWNhbCIKICAgICJyZWNlaXZlciI6ICJDcml0aWNhbCI=
kind: Secret
metadata:
   name: alertmanager-main
   namespace: monitoring

该配置文件中的告警信息都是通过base64加密的，解密后即是告警相关的一些配置信息

]# echo "Imdsb2JhbCI6CiAgInJlc29sdmVfdGltZW91dCI6ICI1bSIKImluaGliaXRfcnVsZXMiOgotICJlcXVhbCI6CiAgLSAibmFtZXNwYWNlIgogIC0gImFsZXJ0bmFtZSIKICAic291cmNlX21hdGNoIjoKICAgICJzZXZlcml0eSI6ICJjcml0aWNhbCIKICAidGFyZ2V0X21hdGNoX3JlIjoKICAgICJzZXZlcml0eSI6ICJ3YXJuaW5nfGluZm8iCi0gImVxdWFsIjoKICAtICJuYW1lc3BhY2UiCiAgLSAiYWxlcnRuYW1lIgogICJzb3VyY2VfbWF0Y2giOgogICAgInNldmVyaXR5IjogIndhcm5pbmciCiAgInRhcmdldF9tYXRjaF9yZSI6CiAgICAic2V2ZXJpdHkiOiAiaW5mbyIKInJlY2VpdmVycyI6Ci0gIm5hbWUiOiAiRGVmYXVsdCIKLSAibmFtZSI6ICJXYXRjaGRvZyIKLSAibmFtZSI6ICJDcml0aWNhbCIKInJvdXRlIjoKICAiZ3JvdXBfYnkiOgogIC0gIm5hbWVzcGFjZSIKICAiZ3JvdXBfaW50ZXJ2YWwiOiAiNW0iCiAgImdyb3VwX3dhaXQiOiAiMzBzIgogICJyZWNlaXZlciI6ICJEZWZhdWx0IgogICJyZXBlYXRfaW50ZXJ2YWwiOiAiMTJoIgogICJyb3V0ZXMiOgogIC0gIm1hdGNoIjoKICAgICAgImFsZXJ0bmFtZSI6ICJXYXRjaGRvZyIKICAgICJyZWNlaXZlciI6ICJXYXRjaGRvZyIKICAtICJtYXRjaCI6CiAgICAgICJzZXZlcml0eSI6ICJjcml0aWNhbCIKICAgICJyZWNlaXZlciI6ICJDcml0aWNhbCI=" | base64 -d
"global":
  "resolve_timeout": "5m"
"inhibit_rules":
- "equal":
  - "namespace"
  - "alertname"
  "source_match":
    "severity": "critical"
  "target_match_re":
    "severity": "warning|info"
- "equal":
  - "namespace"
  - "alertname"
  "source_match":
    "severity": "warning"
  "target_match_re":
    "severity": "info"
"receivers":
- "name": "Default"
- "name": "Watchdog"
- "name": "Critical"
"route":
  "group_by":
  - "namespace"
  "group_interval": "5m"
  "group_wait": "30s"
  "receiver": "Default"
  "repeat_interval": "12h"
  "routes":
  - "match":
      "alertname": "Watchdog"
    "receiver": "Watchdog"
  - "match":
      "severity": "critical"
    "receiver": "Critical"

因此，我们需要配置告警地址等信息，只许将配置文件创建为secret对象即可。

# 邮件告警及钉钉告警配置信息如下
]# cat alert-conf/alertmanager.yaml 
global:
  resolve_timeout: 5m
  smtp_smarthost: 'smtp.126.com:25'
  smtp_from: 'dayi_123@126.com'
  smtp_auth_username: 'dayi_123@126.com'
  smtp_auth_password: 'xxxxxx'
  smtp_hello: '126.com'
  smtp_require_tls: false
route:
  group_by: ['alertname', 'cluster']
  group_wait: 30s
  group_interval: 5s
  repeat_interval: 5m
  receiver: default
  routes:
  - receiver: email
    group_wait: 10s
    match_re:
      team: node
  - receiver: webhook
    group_wait: 10s    
receivers:
- name:
  webhook: 'webhook'
  webhook_configs:
  - url: 'http://ddtalk-hook:8060'
    send_resolved: true
- name: 'default'
  email_configs:
  - to: 'liuyi@ecmoho.com'
    send_resolved: true
- name: 'email'
  email_configs:
  - to: 'liuyi@ecmoho.com'
    send_resolved: true
# 删除之前的secret，创建新的secret
]# kubectl delete secret alertmanager-main -n monitoring
secret "alertmanager-main" deleted
]# kubectl create secret generic alertmanager-main --from-file=alert-conf/alertmanager.yaml -n monitoring
secret/alertmanager-main created

定义了钉钉告警后，自然要定义告警接收程序，将前面prometheus的钉钉告警接收程序修改下名称空间放在当前名称空间即可。

# 接收处理钉钉告警资源配置如下
]# cat ddtalk-hook.yaml 
apiVersion: apps/v1
kind: Deployment
metadata:
  name: ddtalk-hook
  namespace: monitoring
spec:
  selector:
    matchLabels:
      app: ddtalk-hook
  template:
    metadata: 
      labels:
        app: ddtalk-hook
    spec:
      containers:
      - name: ddtalk-hook
        image: timonwong/prometheus-webhook-dingtalk:v1.4.0
        args:
        - --ding.profile=webhook1=https://oapi.dingtalk.com/robot/send?access_token=53630694d60843f17b99e40949afba58fb247995554120bf054037f6111ea59f
        ports:
        - containerPort: 8060
          name: http
        resources:
          requests: 
            cpu: 50m
            memory: 100Mi
          limits:
            cpu: 50m
            memory: 100Mi
---
apiVersion: v1
kind: Service
metadata:
  name: ddtalk-hook
  namespace: prometheus
spec:
  selector:
    app: ddtalk-hook
  ports:
  - name: hook
    port: 8060
    targetPort: http
# 创建
]# kubectl apply -f ddtalk-hook.yaml