grafana&prometheus生产级容器化监控-4:使用kube-prometheus监控k8s集群

  • 2019 年 12 月 26 日
  • 筆記

目录

(1).关于prometheus-operator

(2).部署kube-prometheus

1.下载最新版本

2.容器化部署

(3).kube-prometheus主要组件概述

(4).生产级改造

1.总述

2.维护kube-prometheus副本

3.NodeSelector改造

4.grafana改造

5.持久化改造

6.钉钉报警

6.1.创建钉钉报警机器人

6.2.配置钉钉报警

7.Ingress代理

8.工程规划

(5).总结

(6).相关文章

(1).关于prometheus-operator和kube-prometheus

在最新版本中,kubernetes的prometheus-operator部署内容已经从prometheus-operator的github工程中拆分出独立工程kube-prometheus。

kube-prometheus即是通过operator方式部署的kubernetes集群监控,所以我们直接容器化部署kube-prometheus即可。

(2).部署kube-prometheus

1.下载最新版本

老版本的prometheus-operator自带kube-prometheus,位于contrib/kube-prometheus/manifests,但是0.34版本中kube-prometheus已经独立成单独项目:

进入kube-prometheus的release页面:

https://github.com/coreos/kube-prometheus/releases

下载kube-prometheus最新版本:v0.3.0(本文时间)

wget https://github.com/coreos/kube-prometheus/archive/v0.3.0.tar.gz

2.容器化部署

进入kube-prometheus根目录,我们执行kustomization.yaml中所有的配置文件即可,kustomization.yaml文件中包含了所有相关的容器化配置文件:

apiVersion: kustomize.config.k8s.io/v1beta1  kind: Kustomization  resources:  - ./manifests/alertmanager-alertmanager.yaml  - ./manifests/alertmanager-secret.yaml  - ./manifests/alertmanager-service.yaml  - ./manifests/alertmanager-serviceAccount.yaml  - ./manifests/alertmanager-serviceMonitor.yaml  - ./manifests/grafana-dashboardDatasources.yaml  - ./manifests/grafana-dashboardDefinitions.yaml  - ./manifests/grafana-dashboardSources.yaml  - ./manifests/grafana-deployment.yaml  - ./manifests/grafana-service.yaml  - ./manifests/grafana-serviceAccount.yaml  - ./manifests/grafana-serviceMonitor.yaml  - ./manifests/kube-state-metrics-clusterRole.yaml  - ./manifests/kube-state-metrics-clusterRoleBinding.yaml  - ./manifests/kube-state-metrics-deployment.yaml  - ./manifests/kube-state-metrics-role.yaml  - ./manifests/kube-state-metrics-roleBinding.yaml  - ./manifests/kube-state-metrics-service.yaml  - ./manifests/kube-state-metrics-serviceAccount.yaml  - ./manifests/kube-state-metrics-serviceMonitor.yaml  - ./manifests/node-exporter-clusterRole.yaml  - ./manifests/node-exporter-clusterRoleBinding.yaml  - ./manifests/node-exporter-daemonset.yaml  - ./manifests/node-exporter-service.yaml  - ./manifests/node-exporter-serviceAccount.yaml  - ./manifests/node-exporter-serviceMonitor.yaml  - ./manifests/prometheus-adapter-apiService.yaml  - ./manifests/prometheus-adapter-clusterRole.yaml  - ./manifests/prometheus-adapter-clusterRoleAggregatedMetricsReader.yaml  - ./manifests/prometheus-adapter-clusterRoleBinding.yaml  - ./manifests/prometheus-adapter-clusterRoleBindingDelegator.yaml  - ./manifests/prometheus-adapter-clusterRoleServerResources.yaml  - ./manifests/prometheus-adapter-configMap.yaml  - ./manifests/prometheus-adapter-deployment.yaml  - ./manifests/prometheus-adapter-roleBindingAuthReader.yaml  - ./manifests/prometheus-adapter-service.yaml  - ./manifests/prometheus-adapter-serviceAccount.yaml  - ./manifests/prometheus-clusterRole.yaml  - ./manifests/prometheus-clusterRoleBinding.yaml  - ./manifests/prometheus-operator-serviceMonitor.yaml  - ./manifests/prometheus-prometheus.yaml  - ./manifests/prometheus-roleBindingConfig.yaml  - ./manifests/prometheus-roleBindingSpecificNamespaces.yaml  - ./manifests/prometheus-roleConfig.yaml  - ./manifests/prometheus-roleSpecificNamespaces.yaml  - ./manifests/prometheus-rules.yaml  - ./manifests/prometheus-service.yaml  - ./manifests/prometheus-serviceAccount.yaml  - ./manifests/prometheus-serviceMonitor.yaml  - ./manifests/prometheus-serviceMonitorApiserver.yaml  - ./manifests/prometheus-serviceMonitorCoreDNS.yaml  - ./manifests/prometheus-serviceMonitorKubeControllerManager.yaml  - ./manifests/prometheus-serviceMonitorKubeScheduler.yaml  - ./manifests/prometheus-serviceMonitorKubelet.yaml  - ./manifests/setup/0namespace-namespace.yaml  - ./manifests/setup/prometheus-operator-0alertmanagerCustomResourceDefinition.yaml  - ./manifests/setup/prometheus-operator-0podmonitorCustomResourceDefinition.yaml  - ./manifests/setup/prometheus-operator-0prometheusCustomResourceDefinition.yaml  - ./manifests/setup/prometheus-operator-0prometheusruleCustomResourceDefinition.yaml  - ./manifests/setup/prometheus-operator-0servicemonitorCustomResourceDefinition.yaml  - ./manifests/setup/prometheus-operator-clusterRole.yaml  - ./manifests/setup/prometheus-operator-clusterRoleBinding.yaml  - ./manifests/setup/prometheus-operator-deployment.yaml  - ./manifests/setup/prometheus-operator-service.yaml  - ./manifests/setup/prometheus-operator-serviceAccount.yaml

顺次执行下述命令即可:

# Create the namespace and CRDs, and then wait for them to be availble before creating the remaining resources

kubectl create -f manifests/setup

再执行:kubectl create -f manifests

可以看到有很多pending状态,我们descirbe看一下原因:

kubectl describe -n monitoring pod prometheus-k8s-0

可以看到原因是没有找到符合条件的node节点,很有可能是nodeSelector指定的label和我单集群的node的label不一致。

查证:

prometheus-k8s-0的nodeSelector是:kubernetes.io/os: linux

查看node的label:

kubectl get nodes future --show-labels  NAME     STATUS   ROLES    AGE    VERSION   LABELS  future   Ready    master   107d   v1.13.3   beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,kubernetes.io/hostname=future,node-role.kubernetes.io/master=
[root@future kube-prometheus-0.3.0]# kubectl get nodes future --show-labels | grep -i linux  future   Ready    master   107d   v1.13.3   beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,kubernetes.io/hostname=future,node-role.kubernetes.io/master=

可以看到node没有名为”kubernetes.io/os”的label,我们需要打个label:

kubectl label nodes future kubernetes.io/os=linux

当然你也可以修改配置文件,这个在生产是要注意的。

再次查看pod,可以看到全部OK。

(3).kube-prometheus主要组件概述

组件名称

个数

是否原生

作用

1

alertmanager-main

3

Y

提供报警插件的支持,可以集成钉钉,微信等各种报警插件。

2

grafana

1

Y

提供可视化web界面。

3

kube-state-metrics

1

Y

kube-state-metrics is a simple service that listens to the Kubernetes API server and generates metrics about the state of the objects.kubernetes集群状态度量服务,它监听Kubernetes API服务器并生成关于对象状态的度量。Grafana/prometheus显示/存储的数据就是来源于这个组件。

4

prometheus-adapter

1

Y

由于本身prometheus属于第三方的 解决方案,原生的k8s系统并不能对Prometheus的自定义指标进行解析,就需要借助于k8s-prometheus-adapter将这些指标数据查询接口转换为标准的Kubernetes自定义指标。

5

prometheus-k8s

2

Y

prometheus,存放集群度量数据。

6

prometheus-operator

1

Y

Operator 是最核心的部分,作为一个控制器,他会去创建 Prometheus 、 ServiceMonitor 、 AlertManager 以及 PrometheusRule 4个 CRD 资源对象,然后会一直监控并维持这4个资源对象的状态。可以这样类比理解,相当于statefulset/deployment与POD的关系。

7

webhook-dingtalk

1

N

集成钉钉报警机器人。

从这里也可以看到,当集群规模逐步增大时,grafana/prometheus会逐步增多,命名的可读性就会变得非常重要。

(4).生产级改造

1.总述

官方/开源版本用于生产还是有些问题需要处理的。

问题

描述

严重程度

解决方式

本文是否解决

1

公司自行维护kube-prometheus副本

公司在自己的gitlab上要维护一个kube-prometheus,因为要做一些适配生产的改造。

P0

维护副本。

2

NodeSelector改造

一般生产环境会通过污点划分固定节点给monitor专用,label一般是monitoring,和默认值不同。

非常必要

需要修改官方配置文件,把nodeSelector的label改为monitoring。

3

grafana改造

dashboard用到了grafana-piechart-panel,但默认没有装这个插件。

必要

需要修改官方配置文件。

4

持久化

prometheus-k8s重启,历史监控数据全部丢失。

P0

增加PV存储。保存metric, 以及prometheus自身的各种配置;注意生产要使用独立的云存储空间,防止共用互相影响。

5

钉钉报警

报警功能。

P0

接入dingding webhook

6

Ingress代理

默认不支持

P0

增加Ingress-proxy代理部署。

7

工程规划

如命名等。

非常必要

如:通过一个命名规范可以清楚的标明语义,通过名字可以准确的阅读出“Who, What, Why, When, Where”;节点功能划分(污点);其他等。

涉及部分

8

镜像本地化

不改很坑。相当于生产服务的稳定一定程度上依赖第三方公司的服务。不知道哪天炸。

P0

将相关的所有镜像上传到公司线上网段的镜像仓库,修改配置文件中的所有的镜像地址。

可能还有,想到再续(应该还是有的,一时想不到了)。

2.维护kube-prometheus副本

因为要适配生产,需要做一些改动,必须有一个地方存放且记录历史修改。

如笔者备份为:

https://github.com/hepyu/k8s-app-config/tree/master/product/standard/kube-prometheus-pro/kube-prometheus-pro-0.3.0/manifests

3.NodeSelector改造

文件

NodeSelector

修改前

修改后

alertmanager-alertmanager.yaml

kubernetes.io/os: linux

node.type: monitoring

grafana-deployment.yaml

beta.kubernetes.io/os: linux

node.type: monitoring

kube-state-metrics-deployment.yaml

kubernetes.io/os: linux

node.type: monitoring

node-exporter-daemonset.yaml

kubernetes.io/os: linux

node.type: monitoring

prometheus-adapter-deployment.yaml

kubernetes.io/os: linux

node.type: monitoring

prometheus-prometheus.yaml

kubernetes.io/os: linux

node.type: monitoring

给node增加label:

kubectl label nodes future node.type=monitoring

然后再重新执行上述文件,OK。

4.grafana改造

默认不支持饼图,需要装载饼图的插件。

修改文件:

manifests/grafana-deployment.yaml

增加饼图插件,下述黑色部分:

        resources:            limits:              cpu: 200m              memory: 200Mi            requests:              cpu: 100m              memory: 100Mi          env:          - name: GF_INSTALL_PLUGINS            value: "grafana-piechart-panel"

然后重新部署grafana即可。

5.持久化

修改prometheus-k8s,增加pv存储,本文由于是作者自己ECS,所以使用local PV,生产环境建议使用nas云存储。

初始化prometheus-k8s-pv,配置文件位于:

k8s-app-config/product/standard/kube-prometheus-pro/kube-prometheus-pro-0.3.0/manifests/custom_by_hepy

注意建立对应的本地目录,并chmod配置权限。

然后需要修改文件k8s-app-config/product/standard/kube-prometheus-pro/kube-prometheus-pro-0.3.0/manifests/prometheus-prometheus.yaml,增加下述加粗部分:

spec:    alerting:      alertmanagers:      - name: alertmanager-main        namespace: monitoring        port: web    #增加下述配置    storage:      volumeClaimTemplate:        spec:          storageClassName: prometheus-k8s          resources:            requests:              storage: 100Gi

然后重新执行prometheus-prometheus.yaml。

PVC验证:

root@future manifests]# kubectl get pvc -n monitoring | grep -i k8s  prometheus-k8s-db-prometheus-k8s-0         Bound     prometheus-k8s-1                           100Gi      RWO            prometheus-k8s                          6m30s  prometheus-k8s-db-prometheus-k8s-1         Bound     prometheus-k8s-0                           100Gi      RWO            prometheus-k8s

数据目录验证:

ll /datavip/k8s-data/prometheus-k8s-0/

total 4

drwxrwsrwx 3 root 2000 4096 Dec 18 18:21 prometheus-db

特别注意:

生产环境注意使用独立的云存储空间,防止共用互相影响。

6.钉钉报警

6.1.创建钉钉报警机器人

先建一个钉钉普通群,然后点击右上角的群设置:

点击智能群助手:

选择添加一个机器人:

机器人类型选择:自定义(通过Webhook接入自定义服务)

完成:

6.2.配置钉钉报警

kube-prometheus默认是将alertmanager的报警配置放在secret中(我很不习惯),我们也暂且遵循这个做法。

创建钉钉告警插件:dingtalk-webhook.yaml;

位于:

k8s-app-config/product/standard/kube-prometheus-pro/kube-prometheus-pro-0.3.0/manifests/custom_by_hepy

内容如下,主要是将钉钉报警地址配到K8S中:

---  apiVersion: extensions/v1beta1  kind: Deployment  metadata:    labels:      run: dingtalk    name: webhook-dingtalk    namespace: monitoring  spec:    replicas: 1    template:      metadata:        labels:          run: dingtalk      spec:        containers:        - name: dingtalk          image: timonwong/prometheus-webhook-dingtalk:v0.3.0          imagePullPolicy: IfNotPresent          # 设置钉钉群聊自定义机器人后,使用实际 access_token 替换下面 xxxxxx部分          args:              - --ding.profile=default-webhook-dingtalk=https://oapi.dingtalk.com/robot/send?access_token=98f5b3db00fe696046c21a6eded40a94886f5e1a022e84a5d53aed371f93fa5e          ports:          - containerPort: 8060            protocol: TCP    ---  apiVersion: v1  kind: Service  metadata:    labels:      run: dingtalk    name: webhook-dingtalk    namespace: monitoring  spec:    ports:    - port: 8060      protocol: TCP      targetPort: 8060    selector:      run: dingtalk    sessionAffinity: None

创建告警接收器alertmanager.yaml,位于相同目录,内容如下:

global:    resolve_timeout: 5m  route:    group_by: ['job']    group_wait: 30s    group_interval: 5m    repeat_interval: 12h    receiver: webhook  receivers:  - name: 'webhook'    webhook_configs:    - url: 'http://webhook-dingtalk.monitoring.svc.cluster.local:8060/dingtalk/default-webhook-dingtalk/send'  send_resolved: true

进入目录:

k8s-app-config/product/standard/kube-prometheus-pro/kube-prometheus-pro-0.3.0/manifests

执行命令,部署钉钉插件:

kubectl apply -f custom_by_hepy/dingtalk-webhook.yaml

执行命令,替换原有的alertmanager-secret:

kubectl delete secret alertmanager-main -n monitoring

kubectl create secret generic alertmanager-main –from-file=custom_by_hepy/alertmanager.yaml -n monitoring

至此,完成钉钉插件集成。

下图为钉钉报警样例:

7.Ingress代理

代理grafana,prometheus, alertmanager。

进入目录:

k8s-app-config/product/standard/kube-prometheus-pro/kube-prometheus-pro-0.3.0/manifests

执行命令部署ingress-grafana代理:

kubectl apply -f custom_by_hepy/grafana-ingress.yaml

kubectl apply -f custom_by_hepy/prometheus-k8s-ingress.yaml

本地配置host。

访问grafana:

http://monitor-kubernetes.inc-inc.com:30834/

我们随便选一个:Nodes

每个dashboard含义本文暂不做详述,后续另开。

访问prometheus:

http://prometheus-k8s.inc-inc.com:30834/graph

查看告警信息:

查看监控的对象,如果怀疑有那个资源没有被监控到,来这里查证:

8.工程规划

对于规模较大的kubernetes集群,需要在工程上进行拓扑规划,尤其是命名规范(通过pod名称能够准确阅读出“Who, What, Why, When, Where”,这就要求尽量使用statefulset)。

规划必要性在于,不同的业务线有不同的grafana/prometheus,没有规划非常容易乱。

本文不讨论;但会涉及其中的一个点:

即,将kubernetes监控的dashboard统一到业务的grafana里,可以让所有相关的技术人员看到集群的情况,这点很重要,所有开发是有必要从潜意识开始逐步适应云原生体系。

方法是将每个dashboard的json配置文件拷贝出来作为单独的文件,利用grafana的provisioning机制进行load。

本文提供一个摘录好的dashboard文件集(基于kube-prometheus-v0.3.0版本),位于:

https://github.com/hepyu/k8s-app-config/tree/master/product/standard/grafana-prometheus-pro/grafana/provisioning/dashboards/kubernetes

效果如下:

详情以及体验/实操请参见:

grafana&prometheus生产级容器化监控-1:生产级容器化

9.镜像本地化

这个是显然是必须处理的,必须将相关的docker镜像放到自己公司的镜像仓库。具体方式参见文章:

kubernetes-4:阿里云上创建容器镜像服务

(5).总结

本文提供一个可用于生产的kube-prometheus的容器化配置(v0.30.0版本),位于:

https://github.com/hepyu/k8s-app-config/tree/master/product/standard/kube-prometheus-pro/kube-prometheus-pro-0.3.0/manifests

(使用时注意将PV改为云存储)

包含了本文所涉及的生产级改造。

(6).相关文章

kubernetes-1:使用kubeadm搭建K8S单master节点集群

grafana&prometheus生产级容器化监控-1:生产级容器化

grafana&prometheus生产级容器化监控-2:监控rocketmq

grafana&prometheus生产级容器化监控-3:监控mysql