首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >grafana&prometheus生产级容器化监控-4:使用kube-prometheus监控k8s集群

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

作者头像
千里行走
发布2019-12-26 12:02:03
2.9K0
发布2019-12-26 12:02:03
举报
文章被收录于专栏:千里行走千里行走

目录

(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

本文参与 腾讯云自媒体分享计划,分享自微信公众号。
原始发表:2019-12-19,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 千里行走 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体分享计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
相关产品与服务
容器服务
腾讯云容器服务(Tencent Kubernetes Engine, TKE)基于原生 kubernetes 提供以容器为核心的、高度可扩展的高性能容器管理服务,覆盖 Serverless、边缘计算、分布式云等多种业务部署场景,业内首创单个集群兼容多种计算节点的容器资源管理模式。同时产品作为云原生 Finops 领先布道者,主导开源项目Crane,全面助力客户实现资源优化、成本控制。
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档