Prometheus Operator 部署
安装
为了使用 Prometheus-Operator，这里我们直接使用 kube-prometheus 这个项目来进行安装（提供了很多的内置规则，可以直接拿来使用），该项目和 Prometheus-Operator 的区别就类似于 Linux 内核和 CentOS/Ubuntu 这些发行版的关系，真正起作用的是 Operator 去实现的，而 kube-prometheus 只是利用 Operator 编写了一系列常用的监控资源清单。不过需要注意 Kubernetes 版本和 kube-prometheus 的兼容：
我们可以直接使用 kube-prometheus 的 Helm Charts 来进行快速安装，也可以直接手动安装。
https://github.com/prometheus-operator/kube-prometheus/blob/main/manifests/prometheus-prometheus.yaml 可以看到kind类型为prometheus了，不是之前的deploy，statefullset。
首先 clone 项目代码，我们这里直接使用默认的 main 分支即可：
☸ ➜ git clone https://github.com/prometheus-operator/kube-prometheus.git
☸ ➜ cd kube-prometheus
首先创建需要的命名空间和 CRDs，等待它们可用后再创建其余资源：（之所以能够识别prometheus对象是因为先要创建crd，下面就是创建的crd，有了crd我们才能去定义
kind: prometheus，这样k8s才能够识别）
☸ ➜ kubectl apply -f https://p8s.io/docs/operator/manifests/setup
customresourcedefinition.apiextensions.k8s.io/alertmanagerconfigs.monitoring.coreos.com created
customresourcedefinition.apiextensions.k8s.io/alertmanagers.monitoring.coreos.com created
customresourcedefinition.apiextensions.k8s.io/podmonitors.monitoring.coreos.com created
customresourcedefinition.apiextensions.k8s.io/probes.monitoring.coreos.com created
customresourcedefinition.apiextensions.k8s.io/prometheusrules.monitoring.coreos.com created
customresourcedefinition.apiextensions.k8s.io/servicemonitors.monitoring.coreos.com created
customresourcedefinition.apiextensions.k8s.io/thanosrulers.monitoring.coreos.com created
namespace/monitoring created
The CustomResourceDefinition "prometheuses.monitoring.coreos.com" is invalid: metadata.annotations: Too long: must have at most 262144 bytes
可以看到安装过程中会提示 Too long: must have at most 262144 bytes，只需要将 kubectl apply 改成 kubectl create 即可：
☸ ➜ kubectl create -f https://p8s.io/docs/operator/manifests/setup
☸ ➜ kubectl get crd |grep coreos
alertmanagerconfigs.monitoring.coreos.com 2022-05-19T06:44:00Z
alertmanagers.monitoring.coreos.com 2022-05-19T06:44:01Z
podmonitors.monitoring.coreos.com 2022-05-19T06:44:01Z
probes.monitoring.coreos.com 2022-05-19T06:44:01Z
prometheuses.monitoring.coreos.com 2022-05-19T06:45:04Z
prometheusrules.monitoring.coreos.com 2022-05-19T06:44:01Z
servicemonitors.monitoring.coreos.com 2022-05-19T06:44:01Z
thanosrulers.monitoring.coreos.com 2022-05-19T06:44:02Z
这会创建一个名为 monitoring 的命名空间，以及相关的 CRD 资源对象声明。前面我们讲解过 CRD 和 Operator 的使用，当我们声明完 CRD 过后，就可以来自定义资源清单了，但是要让我们声明的自定义资源对象生效就需要安装对应的 Operator 控制器，在 manifests 目录下面就包含了 Operator 的资源清单以及各种监控对象声明，比如 Prometheus、Alertmanager 等，直接应用即可：（定义完crd，还需要正真的控制器watch创建的crd对象，watch到之后才能够帮我们正真的去创建 ，所以还得去安装operator的控制器）
☸ ➜ kubectl apply -f https://p8s.io/docs/operator/manifests/
不过需要注意有一些资源的镜像来自于 k8s.gcr.io，如果不能正常拉取，则可以将镜像替换成可拉取的：
prometheusAdapter-deployment.yaml：将image: k8s.gcr.io/prometheus-adapter/prometheus-adapter:v0.9.1替换为cnych/prometheus-adapter:v0.9.1kubeStateMetrics-deployment.yaml：将image: k8s.gcr.io/kube-state-metrics/kube-state-metrics:v2.4.2替换为cnych/kube-state-metrics:v2.4.2
这会自动安装 prometheus-operator、node-exporter、kube-state-metrics、grafana、prometheus-adapter 以及 prometheus 和 alertmanager 等大量组件，如果没成功可以多次执行上面的安装命令。
☸ ➜ kubectl get pods -n monitoring
NAME READY STATUS RESTARTS AGE
alertmanager-main-0 2/2 Running 0 46m
alertmanager-main-1 2/2 Running 0 46m
alertmanager-main-2 2/2 Running 0 46m
blackbox-exporter-5cb5d7479d-mznws 3/3 Running 0 49m
grafana-d595885ff-cf49m 1/1 Running 0 49m
kube-state-metrics-685d769786-tkv7l 3/3 Running 0 22m
node-exporter-4d6mq 2/2 Running 0 49m
node-exporter-8cr4v 2/2 Running 0 49m
node-exporter-krr2h 2/2 Running 0 49m
prometheus-adapter-6fd94587c9-6tsgb 0/1 Running 0 3s
prometheus-adapter-6fd94587c9-8zm2l 1/1 Running 4 (13m ago) 13m
prometheus-k8s-0 2/2 Running 0 46m
prometheus-k8s-1 2/2 Running 0 46m
prometheus-operator-7684989c7-qt2sp 2/2 Running 0 49m
☸ ➜ kubectl get svc -n monitoring
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
alertmanager-main ClusterIP 10.102.174.254 <none> 9093/TCP,8080/TCP 49m
alertmanager-operated ClusterIP None <none> 9093/TCP,9094/TCP,9094/UDP 47m
blackbox-exporter ClusterIP 10.107.250.182 <none> 9115/TCP,19115/TCP 49m
grafana ClusterIP 10.105.33.193 <none> 3000/TCP 49m
kube-state-metrics ClusterIP None <none> 8443/TCP,9443/TCP 49m
node-exporter ClusterIP None <none> 9100/TCP 49m
prometheus-adapter ClusterIP 10.105.131.64 <none> 443/TCP 49m
prometheus-k8s ClusterIP 10.109.250.233 <none> 9090/TCP,8080/TCP 49m
prometheus-operated ClusterIP None <none> 9090/TCP 47m
prometheus-operator ClusterIP None <none> 8443/TCP 49m
可以看到上面针对 grafana、alertmanager 和 prometheus 都创建了一个类型为 ClusterIP 的 Service，当然如果我们想要在外网访问这两个服务的话可以通过创建对应的 Ingress 对象或者使用 NodePort 类型的 Service，我们这里为了简单，直接使用 NodePort 类型的服务即可，编辑 grafana、alertmanager-main 和 prometheus-k8s 这 3 个 Service，将服务类型更改为 NodePort:
# 将 type: ClusterIP 更改为 type: NodePort
☸ ➜ kubectl edit svc grafana -n monitoring
☸ ➜ kubectl edit svc alertmanager-main -n monitoring
☸ ➜ kubectl edit svc prometheus-k8s -n monitoring
☸ ➜ kubectl get svc -n monitoring
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
alertmanager-main NodePort 10.102.174.254 <none> 9093:32660/TCP,8080:31615/TCP 49m
grafana NodePort 10.105.33.193 <none> 3000:31837/TCP 49m
prometheus-k8s NodePort 10.109.250.233 <none> 9090:31664/TCP,8080:31756/TCP 49m
......
也可以通过修改资源清单文件来指定service类型为nodeport。
如果要修改Prometheus的副本数可以修改里面replicas字段，控制器watch到了变化对比当前的状态调整副本的个数。
更改完成后，我们就可以通过上面的 NodePort 去访问对应的服务了，比如查看 prometheus 的服务发现页面：
可以看到已经监控上了很多指标数据了，上面我们可以看到 Prometheus 是两个副本，我们这里通过 Service 去访问，按正常来说请求是会去轮询访问后端的两个 Prometheus 实例的，但实际上我们这里访问的时候始终是路由到后端的一个实例上去，因为这里的 Service 在创建的时候添加了 sessionAffinity: ClientIP 这样的属性，会根据 ClientIP 来做 session 亲和性，所以我们不用担心请求会到不同的副本上去：
apiVersion: v1
kind: Service
metadata:labels:app.kubernetes.io/component: prometheusapp.kubernetes.io/instance: k8sapp.kubernetes.io/name: prometheusapp.kubernetes.io/part-of: kube-prometheusapp.kubernetes.io/version: 2.35.0name: prometheus-k8snamespace: monitoring
spec:ports:- name: webport: 9090targetPort: web- name: reloader-webport: 8080targetPort: reloader-webtype: NodePortselector:app.kubernetes.io/component: prometheusapp.kubernetes.io/instance: k8sapp.kubernetes.io/name: prometheusapp.kubernetes.io/part-of: kube-prometheussessionAffinity: ClientIP
为什么会担心请求会到不同的副本上去呢？正常多副本应该是看成高可用的常用方案，理论上来说不同副本本地的数据是一致的，但是需要注意的是 Prometheus 的主动 Pull 拉取监控指标的方式，由于抓取时间不能完全一致，即使一致也不一定就能保证网络没什么问题，所以最终不同副本下存储的数据很大可能是不一样的，所以这里我们配置了 session 亲和性，可以保证我们在访问数据的时候始终是一致的。
配置
我们可以看到上面的监控指标大部分的配置都是正常的，只有两三个没有管理到对应的监控目标，比如 kube-controller-manager 和 kube-scheduler 这两个系统组件。
这其实就和 ServiceMonitor 的定义有关系了，我们先来查看下 kube-scheduler 组件对应的 ServiceMonitor 资源的定义，manifests/kubernetesControlPlane-serviceMonitorKubeScheduler.yaml：
# kubernetesControlPlane-serviceMonitorKubeScheduler.yaml
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:labels:app.kubernetes.io/name: kube-schedulerapp.kubernetes.io/part-of: kube-prometheusname: kube-schedulernamespace: monitoring
spec:endpoints:- bearerTokenFile: /var/run/secrets/kubernetes.io/serviceaccount/tokeninterval: 30s # 每30s获取一次信息port: https-metrics # 对应 service 的端口名scheme: https # 注意是使用 https 协议tlsConfig:insecureSkipVerify: true # 跳过安全校验jobLabel: app.kubernetes.io/name # 用于从中检索任务名称的标签namespaceSelector: # 表示去匹配某一命名空间中的 Service，如果想从所有的namespace中匹配用any:truematchNames:- kube-systemselector: # 匹配的 Service 的 labels，如果使用 mathLabels，则下面的所有标签都匹配时才会匹配该 service，如果使用 matchExpressions，则至少匹配一个标签的 service 都会被选择matchLabels:app.kubernetes.io/name: kube-scheduler
上面是一个典型的 ServiceMonitor 资源对象的声明方式，通过 selector.matchLabels 在 kube-system 这个命名空间下面匹配具有 app.kubernetes.io/name=kube-scheduler 这样的 Service，但是我们系统中根本就没有对应的 Service：
☸ ➜ kubectl get svc -n kube-system -l app.kubernetes.io/name=kube-scheduler
No resources found in kube-system namespace.
所以我们需要去创建一个对应的 Service 对象，才能与 ServiceMonitor 进行关联：
apiVersion: v1
kind: Service
metadata:namespace: kube-systemname: kube-schedulerlabels: # 必须和上面的 ServiceMonitor 下面的 matchLabels 保持一致app.kubernetes.io/name: kube-scheduler
spec:selector:component: kube-schedulerports:- name: https-metricsport: 10259targetPort: 10259 # 需要注意现在版本默认的安全端口是10259
其中最重要的是上面 labels 和 selector 部分，labels 区域的配置必须和我们上面的 ServiceMonitor 对象中的 selector 保持一致，selector 下面配置的是 component=kube-scheduler，为什么会是这个 label 标签呢，我们可以去 describe 下 kube-scheduler 这个 Pod：
☸ ➜ kubectl describe pod kube-scheduler-master1 -n kube-system
Name: kube-scheduler-master1
Namespace: kube-system
Priority: 2000001000
Priority Class Name: system-node-critical
Node: master1/192.168.0.106
Start Time: Tue, 17 May 2022 15:15:43 +0800
Labels: component=kube-schedulertier=control-plane
......
我们可以看到这个 Pod 具有 component=kube-scheduler 和 tier=control-plane 这两个标签，而前面这个标签具有更唯一的特性，所以使用前面这个标签较好，这样上面创建的 Service 就可以和我们的 Pod 进行关联了，直接应用即可：
☸ ➜ kubectl apply -f https://p8s.io/docs/operator/manifests/kubernetesControlPlane-serviceMonitorKubeScheduler.yaml
☸ ➜ kubectl get svc -n kube-system -l app.kubernetes.io/name=kube-scheduler
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kube-scheduler ClusterIP 10.103.236.75 <none> 10259/TCP 5m9s
创建完成后，隔一小会儿后去 Prometheus 页面上查看 targets 下面 kube-scheduler 已经有采集的目标了，但是报了 connect: connection refused 这样的错误：
这是因为 kube-scheduler 启动的时候默认绑定的是 127.0.0.1 地址，所以要通过 IP 地址去访问就被拒绝了，我们可以查看 master 节点上的静态 Pod 资源清单来确认这一点：
# /etc/kubernetes/manifests/kube-scheduler.yaml
apiVersion: v1
kind: Pod
metadata:creationTimestamp: nulllabels:component: kube-schedulertier: control-planename: kube-schedulernamespace: kube-system
spec:containers:- command:- kube-scheduler- --authentication-kubeconfig=/etc/kubernetes/scheduler.conf- --authorization-kubeconfig=/etc/kubernetes/scheduler.conf- --bind-address=127.0.0.1 # 绑定了127.0.0.1- --kubeconfig=/etc/kubernetes/scheduler.conf- --leader-elect=true- --port=0 # 如果为0，则不提供 HTTP 服务，--secure-port 默认值：10259，通过身份验证和授权为 HTTPS 服务的端口，如果为 0，则不提供 HTTPS。
......
我们可以直接将上面的 --bind-address=127.0.0.1 更改为 --bind-address=0.0.0.0 即可，更改后 kube-scheduler 会自动重启，重启完成后再去查看 Prometheus 上面的采集目标就正常了。
可以用同样的方式来修复下 kube-controller-manager 组件的监控，创建一个如下所示的 Service 对象，只是端口改成 10257：
# kubernetesControlPlane-serviceMonitorKubeControllerManager
apiVersion: v1
kind: Service
metadata:namespace: kube-systemname: kube-controller-managerlabels:app.kubernetes.io/name: kube-controller-manager
spec:selector:component: kube-controller-managerports:- name: https-metricsport: 10257targetPort: 10257 # controller-manager 的安全端口为10257
然后将 kube-controller-manager 静态 Pod 的资源清单文件中的参数 --bind-address=127.0.0.1 更改为 --bind-address=0.0.0.0。
上面的监控数据配置完成后，我们就可以去查看下 Grafana 下面的监控图表了，同样使用上面的 NodePort 访问即可，第一次登录使用 admin:admin 登录即可，进入首页后，我们可以发现其实 Grafana 已经有很多配置好的监控图表了。
我们可以随便选择一个 Dashboard 查看监控图表信息。
接下来我们再来学习如何完全自定义一个 ServiceMonitor 以及其他的相关配置。
如果要清理 Prometheus-Operator，可以直接删除对应的资源清单即可：
☸ ➜ kubectl delete -f https://p8s.io/docs/operator/manifests/
☸ ➜ kubectl delete -f https://p8s.io/docs/operator/manifests/setup/上面可以看到Prometheus Operator开箱机就可以使用，不需要我们配置太多的地方。
Prometheus Operator 部署相关推荐
- Kubernetes更优雅的监控工具Prometheus Operator
Kubernetes更优雅的监控工具Prometheus Operator [TOC] 1. Kubernetes Operator 介绍 在 Kubernetes 的支持下,管理和伸缩 Web 应用 ...
- k8s部署Kube Prometheus（Prometheus Operator）
摘要 本文通过Prometheus-operator框架一键化安装prometheus.alertmanage.granfana,并配置企业微信api以及告警推送,搭建 prometheus 的前提环 ...
- 在Kubernetes上使用Prometheus Operator监视应用程序
您可以使Prometheus配置了解您的应用程序在其中运行的Kubernetes环境.在先前的博客文章中 ,我已经描述了如何手动执行该操作. Prometheus Operator是Kubernete ...
- Hands-on Lab (15) - 使用Prometheus Operator监控应用
<OpenShift 4.x HOL教程汇总> 说明:本文已经在OpenShift 4.8环境中验证 文章目录 监控OpenShift集群 监控应用 部署被监控的应用 通过Operator ...
- Prometheus Operator + blackbox_exporter 监控Web页面
背景 目前生产环境使用Zabbix自带的web监控模块对所有子优鸟页面进行监控,由于目前Zabbix服务器为单节点,经常出现取不到web监控数据的情况.现将web监控迁移到Prometheus上. 但 ...
- Prometheus Operator 配置PrometheusRule告警规则
PrometheusRule 用于配置 Prometheus 的 Rule 规则文件,包括 recording rules 和 alerting,可以自动被 Prometheus 加载. 配置 Pro ...
- Prometheus Operator概述
在前面,我们单纯手工管理Prometheus还是复杂一些,因为它有很多东西需要我们去维护,特别是当有很多指标的时候需要我们去手工抓取和配置. 前面我们用自定义的方式来对 Kubernetes 集群进行 ...
- Spark on k8s Operator 部署安装
Spark on k8s Operator 部署安装 1. 背景 受限于公司内网环境,无法构建梯子及部分网络策略,不能使用网络资源直接部署,需要手动编译安装 2. 环境准备 centos 7 Kube ...
- Prometheus — 安装部署（主机安装）
目录 文章目录 目录 环境信息 部署 Prometheus Server 部署 Node Exporter 部署 AlertManager 部署 Grafana 添加 Node Exporter 界面 ...
最新文章
- SQL Server 与 ORACLE 的区别
- AJAX推送与拉取方式的比较
- utxo模型_什么是UTXO？简析账户/余额模型和UTXO模型
- 用户计算机MAC地址在哪看,怎么查看远程电脑mac地址
- .Net Core 2.1 通用主机(Core 在控制台应用程序中的应用)
- 大数据笔记-0907
- mysql数据库优化看的书_MySQL 数据库优化，看这篇就够了
- 隐马尔可夫(HMM)/感知机/条件随机场(CRF)----词性标注
- Honey Dance I believe
- java 命名参数动态替换_使用Kettle的命名参数动态执行作业
- 可视化排班管理_企业人事资源管理系统
- mysql 删除表时外键约束_MySQL删除表的时候忽略外键约束的简单实现
- 对比Excel学Python（二）数据可视化
- cvpr2019论文汇总（论文/代码/项目/论文阅读）
- html代码编辑器jason,JSON 编辑器实现代码
- 最全地理数据下载网址
- 2022最新7个开源Kubernetes(k8s)开发工具
- Omega network
- 测量学7_地形图的基本知识
- vdat文件怎么转成mp4文件