Prometheus Operator 部署

Prometheus Operator 部署

安装

为了使用 Prometheus-Operator，这里我们直接使用 ​​kube-prometheus​​​ 这个项目来进行安装（提供了很多的内置规则，可以直接拿来使用），该项目和 Prometheus-Operator 的区别就类似于 Linux 内核和 CentOS/Ubuntu 这些发行版的关系，真正起作用的是 Operator 去实现的，而 kube-prometheus 只是利用 Operator 编写了一系列常用的监控资源清单。不过需要注意 Kubernetes 版本和 ​​kube-prometheus​​ 的兼容：

我们可以直接使用 ​​kube-prometheus​​​ 的 ​​Helm Charts​​ 来进行快速安装，也可以直接手动安装。

​​clone 项目代码，我们这里直接使用默认的 ​​main​​ 分支即可：

☸ ➜ git clone ➜ cd kube-prometheus

首先创建需要的命名空间和 CRDs，等待它们可用后再创建其余资源：（之所以能够识别prometheus对象是因为先要创建crd，下面就是创建的crd，有了crd我们才能去定义

kind: prometheus，这样k8s才能够识别）

☸ ➜ kubectl apply -f createdcustomresourcedefinition.apiextensions.k8s.io/alertmanagers.monitoring.coreos.com createdcustomresourcedefinition.apiextensions.k8s.io/podmonitors.monitoring.coreos.com createdcustomresourcedefinition.apiextensions.k8s.io/probes.monitoring.coreos.com createdcustomresourcedefinition.apiextensions.k8s.io/prometheusrules.monitoring.coreos.com createdcustomresourcedefinition.apiextensions.k8s.io/servicemonitors.monitoring.coreos.com createdcustomresourcedefinition.apiextensions.k8s.io/thanosrulers.monitoring.coreos.com creatednamespace/monitoring createdThe 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 ➜ kubectl get crd |grep coreosalertmanagerconfigs.monitoring.coreos.com 2022-05-19T06:44:00Zalertmanagers.monitoring.coreos.com 2022-05-19T06:44:01Zpodmonitors.monitoring.coreos.com 2022-05-19T06:44:01Zprobes.monitoring.coreos.com 2022-05-19T06:44:01Zprometheuses.monitoring.coreos.com 2022-05-19T06:45:04Zprometheusrules.monitoring.coreos.com 2022-05-19T06:44:01Zservicemonitors.monitoring.coreos.com 2022-05-19T06:44:01Zthanosrulers.monitoring.coreos.com 2022-05-19T06:44:02Z

☸ ➜ kubectl apply -f k8s.gcr.io/prometheus-adapter/prometheus-adapter:v0.9.1​​​ 替换为​​cnych/prometheus-adapter:v0.9.1​​​​kubeStateMetrics-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 monitoringNAME READY STATUS RESTARTS AGEalertmanager-main-0 2/2 Running 0 46malertmanager-main-1 2/2 Running 0 46malertmanager-main-2 2/2 Running 0 46mblackbox-exporter-5cb5d7479d-mznws 3/3 Running 0 49mgrafana-d595885ff-cf49m 1/1 Running 0 49mkube-state-metrics-685d769786-tkv7l 3/3 Running 0 22mnode-exporter-4d6mq 2/2 Running 0 49mnode-exporter-8cr4v 2/2 Running 0 49mnode-exporter-krr2h 2/2 Running 0 49mprometheus-adapter-6fd94587c9-6tsgb 0/1 Running 0 3sprometheus-adapter-6fd94587c9-8zm2l 1/1 Running 4 (13m ago) 13mprometheus-k8s-0 2/2 Running 0 46mprometheus-k8s-1 2/2 Running 0 46mprometheus-operator-7684989c7-qt2sp 2/2 Running 0 49m☸ ➜ kubectl get svc -n monitoringNAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGEalertmanager-main ClusterIP 10.102.174.254 9093/TCP,8080/TCP 49malertmanager-operated ClusterIP None 9093/TCP,9094/TCP,9094/UDP 47mblackbox-exporter ClusterIP 10.107.250.182 9115/TCP,19115/TCP 49mgrafana ClusterIP 10.105.33.193 3000/TCP 49mkube-state-metrics ClusterIP None 8443/TCP,9443/TCP 49mnode-exporter ClusterIP None 9100/TCP 49mprometheus-adapter ClusterIP 10.105.131.64 443/TCP 49mprometheus-k8s ClusterIP 10.109.250.233 9090/TCP,8080/TCP 49mprometheus-operated ClusterIP None 9090/TCP 47mprometheus-operator ClusterIP 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 monitoringNAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGEalertmanager-main NodePort 10.102.174.254 9093:32660/TCP,8080:31615/TCP 49mgrafana NodePort 10.105.33.193 3000:31837/TCP 49mprometheus-k8s NodePort 10.109.250.233 9090:31664/TCP,8080:31756/TCP 49m......

也可以通过修改资源清单文件来指定service类型为nodeport。

如果要修改Prometheus的副本数可以修改里面replicas字段，控制器watch到了变化对比当前的状态调整副本的个数。

更改完成后，我们就可以通过上面的 NodePort 去访问对应的服务了，比如查看 prometheus 的服务发现页面：

可以看到已经监控上了很多指标数据了，上面我们可以看到 Prometheus 是两个副本，我们这里通过 Service 去访问，按正常来说请求是会去轮询访问后端的两个 Prometheus 实例的，但实际上我们这里访问的时候始终是路由到后端的一个实例上去，因为这里的 Service 在创建的时候添加了 ​​sessionAffinity: ClientIP​​​ 这样的属性，会根据 ​​ClientIP​​ 来做 session 亲和性，所以我们不用担心请求会到不同的副本上去：

apiVersion: v1kind: Servicemetadata: labels: app.kubernetes.io/component: prometheus app.kubernetes.io/instance: k8s app.kubernetes.io/name: prometheus app.kubernetes.io/part-of: kube-prometheus app.kubernetes.io/version: 2.35.0 name: prometheus-k8s namespace: monitoringspec: ports: - name: web port: 9090 targetPort: web - name: reloader-web port: 8080 targetPort: reloader-web type: NodePort selector: app.kubernetes.io/component: prometheus app.kubernetes.io/instance: k8s app.kubernetes.io/name: prometheus app.kubernetes.io/part-of: kube-prometheus sessionAffinity: ClientIP

为什么会担心请求会到不同的副本上去呢？正常多副本应该是看成高可用的常用方案，理论上来说不同副本本地的数据是一致的，但是需要注意的是 Prometheus 的主动 Pull 拉取监控指标的方式，由于抓取时间不能完全一致，即使一致也不一定就能保证网络没什么问题，所以最终不同副本下存储的数据很大可能是不一样的，所以这里我们配置了 session 亲和性，可以保证我们在访问数据的时候始终是一致的。

配置

我们可以看到上面的监控指标大部分的配置都是正常的，只有两三个没有管理到对应的监控目标，比如 ​​kube-controller-manager​​​ 和 ​​kube-scheduler​​ 这两个系统组件。

这其实就和 ​​ServiceMonitor​​​ 的定义有关系了，我们先来查看下 kube-scheduler 组件对应的 ServiceMonitor 资源的定义，​​manifests/kubernetesControlPlane-serviceMonitorKubeScheduler.yaml​​：

# kubernetesControlPlane-serviceMonitorKubeScheduler.yamlapiVersion: monitoring.coreos.com/v1kind: ServiceMonitormetadata: labels: app.kubernetes.io/name: kube-scheduler app.kubernetes.io/part-of: kube-prometheus name: kube-scheduler namespace: monitoringspec: endpoints: - bearerTokenFile: /var/run/secrets/kubernetes.io/serviceaccount/token interval: 30s # 每30s获取一次信息 port: # 对应 service 的端口名 scheme: # 注意是使用 协议 tlsConfig: insecureSkipVerify: true # 跳过安全校验 jobLabel: app.kubernetes.io/name # 用于从中检索任务名称的标签 namespaceSelector: # 表示去匹配某一命名空间中的 Service，如果想从所有的namespace中匹配用any:true matchNames: - kube-system selector: # 匹配的 Service 的 labels，如果使用 mathLabels，则下面的所有标签都匹配时才会匹配该 service，如果使用 matchExpressions，则至少匹配一个标签的 service 都会被选择 matchLabels: app.kubernetes.io/name: kube-scheduler

☸ ➜ kubectl get svc -n kube-system -l app.kubernetes.io/name=kube-schedulerNo resources found in kube-system namespace.

所以我们需要去创建一个对应的 Service 对象，才能与 ​​ServiceMonitor​​ 进行关联：

apiVersion: v1kind: Servicemetadata: namespace: kube-system name: kube-scheduler labels: # 必须和上面的 ServiceMonitor 下面的 matchLabels 保持一致 app.kubernetes.io/name: kube-schedulerspec: selector: component: kube-scheduler ports: - name: port: 10259 targetPort: 10259 # 需要注意现在版本默认的安全端口是10259

其中最重要的是上面 labels 和 selector 部分，labels 区域的配置必须和我们上面的 ServiceMonitor 对象中的 selector 保持一致，selector 下面配置的是 ​​component=kube-scheduler​​，为什么会是这个 label 标签呢，我们可以去 describe 下 kube-scheduler 这个 Pod：

☸ ➜ kubectl describe pod kube-scheduler-master1 -n kube-systemName: kube-scheduler-master1Namespace: kube-systemPriority: 2000001000Priority Class Name: system-node-criticalNode: master1/192.168.0.106Start Time: Tue, 17 May 2022 15:15:43 +0800Labels: component=kube-scheduler tier=control-plane......

我们可以看到这个 Pod 具有 ​​component=kube-scheduler​​​ 和 ​​tier=control-plane​​ 这两个标签，而前面这个标签具有更唯一的特性，所以使用前面这个标签较好，这样上面创建的 Service 就可以和我们的 Pod 进行关联了，直接应用即可：

☸ ➜ kubectl apply -f ➜ kubectl get svc -n kube-system -l app.kubernetes.io/name=kube-schedulerNAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGEkube-scheduler ClusterIP 10.103.236.75 10259/TCP 5m9s

创建完成后，隔一小会儿后去 Prometheus 页面上查看 targets 下面 kube-scheduler 已经有采集的目标了，但是报了 ​​connect: connection refused​​ 这样的错误：

这是因为 kube-scheduler 启动的时候默认绑定的是 ​​127.0.0.1​​ 地址，所以要通过 IP 地址去访问就被拒绝了，我们可以查看 master 节点上的静态 Pod 资源清单来确认这一点：

# /etc/kubernetes/manifests/kube-scheduler.yamlapiVersion: v1kind: Podmetadata: creationTimestamp: null labels: component: kube-scheduler tier: control-plane name: kube-scheduler namespace: kube-systemspec: 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-serviceMonitorKubeControllerManagerapiVersion: v1kind: Servicemetadata: namespace: kube-system name: kube-controller-manager labels: app.kubernetes.io/name: kube-controller-managerspec: selector: component: kube-controller-manager ports: - name: port: 10257 targetPort: 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 ➜ kubectl delete -f Operator开箱机就可以使用，不需要我们配置太多的地方。

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。