【prometheus】kubernetes集群性能监控

手动安装方案——阿里云解决方案（部署失败）：

https://www.jianshu.com/p/1c7ddf18e8b2

手动安装方案—— （部署成功，但是只有CPU内存等的监控信息，没有GPU的监控信息）：

https://github.com/camilb/prometheus-kubernetes/tree/master

helm安装方案——GPU-Monitoring-tools解决方案（部署成功）：

参考：http://fly-luck.github.io/2018/12/10/gpu-monitoring-tools%20Prometheus/

对应github：https://github.com/NVIDIA/gpu-monitoring-tools/tree/helm-charts

监控方案

  1. gpu-monitoring-tools（以下简称gmt）的metrics采集包含多套方案：

    1. NVML Go Bindings（C API）。
    2. DCGM exporter（Prometheus metrics on DCGM）。
  2. gmt的监控框架提供了多套方案：
    1. 直接利用DCGM exporter的Prometheus DaemonSet，只有采集和监控。
    2. Prometheus Operator + Kube-Prometheus（经Nvidia修改），包含完整的采集、监控、告警、图形化等组件。

我们采用第二套监控框架方案，且这套方案的功能对于没有GPU的CPU机器仍然有效。
经验证，这套方案可以同时监控宿主机硬件（CPU、GPU、内存、磁盘等）、Kubernetes核心组件（apiserver、controller-manager、scheduler等）以及运行在Kubernetes上的业务服务的运行状态。

什么是Operator

  1. 对于无状态的应用，原生Kubernetes的资源（如Deployment）能很好地支持自动扩缩容、自动重启以及升级。
  2. 对于有状态的应用，如数据库、缓存、监控系统等，需要根据特定的应用进行不同的运维操作。
  3. Operator针对特定的应用将运维操作封装进软件，并将Kubernetes API通过第三方资源进行扩展，允许用户创建、配置、管理应用，通常包含一系列Kubernetes CRD的集合。
  4. 与Kubernetes的Controller和Resource对应关系类似，Operator根据用户提交给Controller的请求，将实际的实例数和实例状态维持在与用户期望相同的效果，但封装了许多细节的操作。

前置准备

镜像

将下列镜像导入到集群的所有节点上：

1234567891011121314151617181920
 
# 如果使用原始的kubernetes搭建Prometheus，使用这两个镜像创建资源，但仅能获取metrics，没有对接监控告警# docker pull nvidia/dcgm-exporter:1.4.6# docker pull quay.io/prometheus/node-exporter:v0.16.0

# operator基础镜像docker pull quay.io/coreos/prometheus-operator:v0.17.0docker pull quay.io/coreos/hyperkube:v1.7.6_coreos.0 

# exportersdocker pull nvidia/dcgm-exporter:1.4.3docker pull quay.io/prometheus/node-exporter:v0.15.2

# prometheus组件docker pull quay.io/coreos/configmap-reload:v0.0.1docker pull quay.io/coreos/prometheus-config-reloader:v0.0.3docker pull gcr.io/google_containers/addon-resizer:1.7docker pull gcr.io/google_containers/kube-state-metrics:v1.2.0docker pull quay.io/coreos/grafana-watcher:v0.0.8docker pull grafana/grafana:5.0.0docker pull quay.io/prometheus/prometheus:v2.2.1
helm模板

下载并解压下列helm模板：

1234
 
wget https://nvidia.github.io/gpu-monitoring-tools/helm-charts/kube-prometheus-0.0.43.tgztar zxvf kube-prometheus-0.0.43.tgzwget https://nvidia.github.io/gpu-monitoring-tools/helm-charts/prometheus-operator-0.0.15.tgztar zxvf prometheus-operator-0.0.15.tgz

安装步骤

1. 配置
节点标签

对于需要监控的GPU node打上标签。

1
 
kubectl label no <nodename> hardware-type=NVIDIAGPU
外源etcd

对于外源的etcd，即etcd不以容器的方式随Kubernetes集群初始化而启动，而是在事前启动的外部etcd集群，需要指定etcd的集群地址。
假设外源etcd的IP为etcd0，etcd1，etcd2，外部访问端口为2379，使用HTTP直接访问。

1
 
vim kube-prometheus/charts/exporter-kube-etcd/values.yaml
 
1234567
 
#etcdPort:  4001etcdPort: 2379

#endpoints: [] endpoints: [etcd0,etcd1,etcd2]scheme: http...

同时，需在grafana插入图表数据，注意：

  1. 在465行处添加一个”,”。
  2. 465行前为"title": "Crashlooping Control Plane Pods"的面板。
  3. 在465行处添加以下内容，注意保持缩进。
    1
    		 
    vim kube-prometheus/charts/grafana/dashboards/kubernetes-cluster-status-dashboard.json
    		 
12345678910111213141516171819202122232425262728293031323334353637383940414243444546474849505152535455565758596061626364656667686970717273747576777879808182
 
{  "cacheTimeout": null,  "colorBackground": false,  "colorValue": false,  "colors": [      "rgba(245, 54, 54, 0.9)",      "rgba(237, 129, 40, 0.89)",      "rgba(50, 172, 45, 0.97)"  ],  "datasource": "prometheus",  "editable": true,  "format": "percent",  "gauge": {      "maxValue": 100,      "minValue": 0,      "show": true,      "thresholdLabels": false,      "thresholdMarkers": true  },  "gridPos": {      "h": 5,      "w": 6,      "x": 0,      "y": 11  },  "id": 14,  "interval": null,  "links": [],  "mappingType": 1,  "mappingTypes": [      {        "name": "value to text",        "value": 1      },      {        "name": "range to text",        "value": 2      }  ],  "maxDataPoints": 100,  "nullPointMode": "connected",  "nullText": null,  "postfix": "",  "postfixFontSize": "50%",  "prefix": "",  "prefixFontSize": "50%",  "rangeMaps": [      {        "from": "null",        "text": "N/A",        "to": "null"      }  ],  "sparkline": {      "fillColor": "rgba(31, 118, 189, 0.18)",      "full": false,      "lineColor": "rgb(31, 120, 193)",      "show": false  },  "tableColumn": "",  "targets": [      {        "expr": "(sum(up{job=\"kube-etcd\"} == 1) / count(up{job=\"kube-etcd\"})) * 100",        "format": "time_series",        "intervalFactor": 2,        "refId": "A",        "step": 600      }  ],  "thresholds": "50, 80",  "title": "External etcd Servers UP",  "type": "singlestat",  "valueFontSize": "80%",  "valueMaps": [      {        "op": "=",        "text": "N/A",        "value": "null"      }  ],  "valueName": "current"}
暴露端口

暴露prometheus、alertmanager、grafana的访问端口，以备排障。这些端口需要能从开发VPC直接访问。

1
 
vim kube-prometheus/values.yaml
 
123456789101112
 
alertmanager:  ...  service:    ...    nodePort: 30779    type: NodePortprometheus:  ...  service:    ...    nodePort: 30778    type: NodePort
 
1
 
vim kube-prometheus/charts/grafana/values.yaml
 
123
 
service:  nodePort: 30780  type: NodePort
告警接收器

配置告警接收器，通常我们选择在同一个集群内的ControlCenter Service来接收，并将告警信息转换格式后转发给IMS。

1
 
vim kube-prometheus/values.yaml
 
1234567891011121314151617181920
 
alertmanager:  config:    route:      receiver: ‘webhook_test‘      routes:      - match:          alertname: DeadMansSwitch        receiver: ‘webhook_test‘      - match:          severity: critical        receiver: ‘webhook_test‘      - match:          severity: warning        receiver: ‘webhook_test‘    receivers:    - name: ‘webhook_test‘      webhook_configs:      - send_resolved: true        # short for controlcenter.default.svc or controlcenter.default.svc.cluster.local        url: "http://controlcenter.default:7777/api/alerts"
告警规则

平台监控包括Node硬件（CPU、内存、磁盘、网络、GPU）、K8s组件（Kube-Controller-Manager、Kube-Scheduler、Kubelet、API Server）、K8s应用（Deployment、StatefulSet、Pod）等。
由于篇幅较长，因此将监控告警规则放在附录。

2. 启动
12
 
cd prometheus-operatorhelm install . --name prometheus-operator --namespace monitoring
 
12
 
cd kube-prometheushelm install . --name kube-prometheus --namespace monitoring
3. 清理
1
 
helm delete --purge kube-prometheus
 
1
 
helm delete --purge prometheus-operator

常见问题

无法暴露Kubelet metrics

在1.13.0版本的kubernetes未出现此问题。

  1. 对于1.13.0之前的版本，需将获取kubelet metrics的方式由https改为http，否则Prometheus的kubelet targets将down掉。[github issue 926]

    1
    		 
    vim kube-prometheus/charts/exporter-kubelets/templates/servicemonitor.yaml
    		 
12345678910111213
 
spec:  endpoints:#  - port: https-metrics#    scheme: https  - port: http-metrics    scheme: http    ...#  - port: https-metrics#    scheme: https  - port: http-metrics    scheme: http    path: /metrics/cadvisor    ...
  1. 验证
    在Prometheus页面可以看到kubelet target。
无法暴露controller-manager及scheduler的metrics
方法一

针对Kubernetes v1.13.0。

  1. 将下述内容添加到kubeadm.conf，并在kubeadm初始化时kubeadm init –config kubeadm.conf。

    12345678910
    		 
    apiVersion: kubeadm.k8s.io/v1alpha3kind: ClusterConfigurationkubernetesVersion: 1.13.0networking:  podSubnet: 10.244.0.0/16controllerManagerExtraArgs:  address: 0.0.0.0schedulerExtraArgs:  address: 0.0.0.0...
  2. 为pod打上label。
    1234
    		 
    kubectl get po -n kube-systemkubectl -n kube-system label po kube-controller-manager-<nodename> k8s-app=kube-controller-managerkubectl -n kube-system label po kube-scheduler-<nodename> k8s-app=kube-schedulerkubectl get po -n kube-system --show-labels
  3. 验证
    在Prometheus页面可以看到kube-controller-manager及kube-scheduler两个target。
    在grafana页面可以看到controller-manager及scheduler的状态监控。
方法二

guide
针对1.13.0之前的Kubernetes。

  1. 修改kubeadm的核心配置。

    1
    		 
    kubeadm config view

将上述输出保存为newConfig.yaml，并添加以下两行：

1234
 
controllerManagerExtraArgs:  address: 0.0.0.0schedulerExtraArgs:  address: 0.0.0.0

应用新配置：

1
 
kubeadm config upload from-file --config newConfig.yaml
  1. 为pod打上label。

    1234
    		 
    kubectl get po -n kube-systemkubectl label po kube-controller-manager-<nodename> k8s-app=kube-controller-managerkubectl label po kube-scheduler-<nodename> k8s-app=kube-schedulerkubectl get po -n kube-system --show-labels
  2. 重建exporters。
    1
    		 
    kubectl -n kube-system get svc

可以看到以下两个没有CLUSTER-IP的Service：

12
 
kube-prometheus-exporter-kube-controller-managerkube-prometheus-exporter-kube-scheduler
 
12
 
kubectl -n kube-system get svc kube-prometheus-exporter-kube-controller-manager -o yamlkubectl -n kube-system get svc kube-prometheus-exporter-kube-scheduler -o yaml

将上述输出分别保存为newKubeControllerManagerSvc.yaml和newKubeSchedulerSvc.yaml，删除一些非必要信息（如uid、selfLink、resourceVersion、creationTimestamp等）后重建。

123
 
kubectl delete -n kube-system svc kube-prometheus-exporter-kube-controller-manager kube-prometheus-exporter-kube-schedulerkubectl apply -f newKubeControllerManagerSvc.yamlkubectl apply -f newKubeSchedulerSvc.yaml
  1. 确保Prometheus pod到kube-controller-manager和kube-scheduler的NodePort 10251/10252的访问是通畅的。
  2. 验证与方法一相同。
无法暴露coredns

在Kubernetes v1.13.0中，集群DNS组件默认为coredns，因此需修改kube-prometheus的配置，才能监控到DNS服务的状态。

方法一
  1. 修改配置中的selectorLabel值与coredns的pod标签对应。

    123
    		 
    kubectl -n kube-system get po --show-labels | grep coredns# 输出coredns    k8s-app=kube-dns
    		 
1
 
vim kube-prometheus/charts/exporter-coredns/values.yaml
 
12
 
#selectorLabel: corednsselectorLabel: kube-dns
  1. 重启kube-prometheus。

    12
    		 
    helm delete --purge kube-prometheushelm install --name kube-prometheus --namespace monitoring kube-prometheus
  2. 验证
    在Prometheus可以看到kube-dns target。
方法二
  1. 修改pod的标签与配置中的一致。

    1
    		 
    kubectl -n kube-system label po
  2. 验证与方法一相同。

部署成功后需要使用port-forward才能访问到grafana面板，可视化看到监控效果：

https://blog.csdn.net/aixiaoyang168/article/details/81661459

原文地址：https://www.cnblogs.com/zealousness/p/11116764.html

时间： 2024-10-03 00:52:05

【prometheus】kubernetes集群性能监控的相关文章

Kubernetes集群资源监控

Kubernetes监控指标 集群监控? 节点资源利用率? 节点数? 运行Pods Pod监控? Kubernetes指标(pod) DESIRED:预期的状态CURRENT:当前的状态UP-TO-DATE:更新后的状态AVAILABLE:可以用的状态 ? 容器指标(cpu,mem)? 应用程序 Kubernetes监控方案 cAdvisor+InfluxDB+Grafana:cAdvisor(k8s自身的组件)采集的数据,Heapster会去收集数据存在InfluxDB中,Grafana对In

建立Heapster Influxdb Grafana集群性能监控平台

依赖于kubenets dns服务地址:https://note.youdao.com/web/#/file/WEB42cf75c02ae113136ff664f3f137cb67/note/WEB0eec19f3667471969b3354b7128fda9c/ 图形化展示度量指标的实现需要集成k8s的另外一个Addons组件: Heapster .Heapster原生支持K8s(v1.0.6及以后版本)和 CoreOS ,并且支持多种存储后端,比如: InfluxDB . ElasticSe

kubectl-trace 基于bpftrace 的kubernetes 集群性能分析工具

kubectl-trace 是一个kubectl 的插件,我们可以使用基于bpftrace 的编程能力,来分析系统的性能问题, 强大,灵活,后边安装试用下 参考架构 参考资料 https://github.com/iovisor/kubectl-trace 原文地址:https://www.cnblogs.com/rongfengliang/p/12044223.html

Kubernetes集群

Kubernetes已经成为当下最火热的一门技术,未来一定也会有更好的发展,围绕着云原生的周边产物也越来越多,使得上云更加便利更加有意义,本文主要讲解一些蔚来汽车从传统应用落地到Kubernetes集群的一些实践经验,提供给大家在落地之前的一些思考和注意点,并且让大家在实施的时候能够有一些借鉴,提供一些使用过程中的注意事项.项目背景 Docker诞生于2013年初,随着时间的推移Docker项目也逐渐火热起来,也形成了自己的生态,为了能够灵活调度容器,编排技术也变得非常重要,Swarm,Meso

Rancher2.x 一键式部署 Prometheus + Grafana 监控 Kubernetes 集群

目录 1.Prometheus & Grafana 介绍 2.环境.软件准备 3.Rancher 2.x 应用商店 4.一键式部署 Prometheus 5.验证 Prometheus + Grafana 1.Prometheus & Grafana 介绍 Prometheus 是一套开源的系统监控.报警.时间序列数据库的组合,Prometheus 基本原理是通过 Http 协议周期性抓取被监控组件的状态,而通过 Exporter Http 接口输出这些被监控的组件信息,而且已经有很多 E

Kubernetes集群监控方案

本文介绍在k8s集群中使用node-exporter.prometheus.grafana对集群进行监控.其实现原理有点类似ELK.EFK组合.node-exporter组件负责收集节点上的metrics监控数据,并将数据推送给prometheus, prometheus负责存储这些数据,grafana将这些数据通过网页以图形的形式展现给用户. 在开始之前有必要了解下Prometheus是什么?Prometheus (中文名:普罗米修斯)是由 SoundCloud 开发的开源监控报警系统和时序列

kubernetes集群全栈监控报警方案kube-prometheus

参考文档 http://www.servicemesher.com/blog/prometheus-operator-manual/ https://github.com/coreos/prometheus-operator https://github.com/coreos/kube-prometheus 背景环境 kubernetes集群1.13版本,纯二进制版本打造,参考k8s1.13集群部署 coreos/kube-prometheus从coreos/prometheus-operato

部署kubernetes集群

一.部署说明最近很多学生问我kubernetes的技术问题,回答了很多次,突然间想我是不是做一些帖子,可以让我的学生能看到,身边想学习的人也都能看到呢!于是我打算开始写这边文章,如果访问量大,学习的人多,我会每周更新一篇的速度去将kubernetes的技术一直更新下去.随着云计算的发展,容器技术不断的更新,发展.从docker到kubernetes,企业也在不断的升级自己的架构,代表公司就是我们熟悉的京东,从2015年开始不断的使用容器来承载自己的业务.2018年618,60%的业务都是由kub

kube-liveboard: kubernetes集群可视化工具

kube-liveboard 随着kubernetes 集群的增大,对于集群数据选取恰当的形式进行展示有助于直观反映集群的状态,方便发现集群的短板,了解集群的瓶颈.因此,笔者做了kube-liveboard这个项目用以实现以上目标,实现集群状态的可视化. 从apiserver中可以获取所有的资源信息,社区目前有kube-state-metrics项目对各项资源进行分别的统计,并形成metrics接口.笔者自己也开发了一个类似的项目,kube-cluster-state,用以统计比如每个node上