Prometheus Operator 的安装

 Prometheus Operator 的安装

接下来咱们用自定义的方式来对 Kubernetes 集群进行监控，可是仍是有一些缺陷，好比 Prometheus、AlertManager 这些组件服务自己的高可用，固然咱们也彻底能够用自定义的方式来实现这些需求，咱们也知道 Promethues 在代码上就已经对 Kubernetes 有了原生的支持，能够经过服务发现的形式来自动监控集群，所以咱们可使用另一种更加高级的方式来部署 Prometheus：Operator 框架。

Operator

Operator是由CoreOS公司开发的，用来扩展 Kubernetes API，特定的应用程序控制器，它用来建立、配置和管理复杂的有状态应用，如数据库、缓存和监控系统。Operator基于 Kubernetes 的资源和控制器概念之上构建，但同时又包含了应用程序特定的一些专业知识，好比建立一个数据库的Operator，则必须对建立的数据库的各类运维方式很是了解，建立Operator的关键是CRD（自定义资源）的设计。

CRD是对 Kubernetes API 的扩展，Kubernetes 中的每一个资源都是一个 API 对象的集合，例如咱们在YAML文件里定义的那些spec都是对 Kubernetes 中的资源对象的定义，全部的自定义资源能够跟 Kubernetes 中内建的资源同样使用 kubectl 操做。

Operator是将运维人员对软件操做的知识给代码化，同时利用 Kubernetes 强大的抽象来管理大规模的软件应用。目前CoreOS官方提供了几种Operator的实现，其中就包括咱们今天的主角：Prometheus Operator，Operator的核心实现就是基于 Kubernetes 的如下两个概念：

• 资源：对象的状态定义
• 控制器：观测、分析和行动，以调节资源的分布

固然咱们若是有对应的需求也彻底能够本身去实现一个Operator，接下来咱们就来给你们详细介绍下Prometheus-Operator的使用方法。

介绍

首先咱们先来了解下Prometheus-Operator的架构图：

promtheus opeator

上图是Prometheus-Operator官方提供的架构图，其中Operator是最核心的部分，做为一个控制器，他会去建立Prometheus、ServiceMonitor、AlertManager以及PrometheusRule4个CRD资源对象，而后会一直监控并维持这4个资源对象的状态。

其中建立的prometheus这种资源对象就是做为Prometheus Server存在，而ServiceMonitor就是exporter的各类抽象，exporter前面咱们已经学习了，是用来提供专门提供metrics数据接口的工具，Prometheus就是经过ServiceMonitor提供的metrics数据接口去 pull 数据的，固然alertmanager这种资源对象就是对应的AlertManager的抽象，而PrometheusRule是用来被Prometheus实例使用的报警规则文件。

这样咱们要在集群中监控什么数据，就变成了直接去操做 Kubernetes 集群的资源对象了，是否是方便不少了。上图中的 Service 和 ServiceMonitor 都是 Kubernetes 的资源，一个 ServiceMonitor 能够经过 labelSelector 的方式去匹配一类 Service，Prometheus 也能够经过 labelSelector 去匹配多个ServiceMonitor。

安装

咱们这里直接经过 Prometheus-Operator 的源码来进行安装，固然也能够用 Helm 来进行一键安装，咱们采用源码安装能够去了解更多的实现细节。首页将源码 Clone 下来：

$ git clone https://github.com/coreos/kube-prometheus.git $ cd manifests $ ls 00namespace-namespace.yaml node-exporter-clusterRole.yaml 0prometheus-operator-0alertmanagerCustomResourceDefinition.yaml node-exporter-daemonset.yaml ...... 

最新的版本官方将资源https://github.com/coreos/prometheus-operator/tree/master/contrib/kube-prometheus迁移到了独立的 git 仓库中：https://github.com/coreos/kube-prometheus.git

进入到 manifests 目录下面，这个目录下面包含咱们全部的资源清单文件，咱们须要对其中的文件 prometheus-serviceMonitorKubelet.yaml 进行简单的修改，由于默认状况下，这个 ServiceMonitor 是关联的 kubelet 的10250端口去采集的节点数据，而咱们前面说过为了安全，这个 metrics 数据已经迁移到10255这个只读端口上面去了，咱们只须要将文件中的https-metrics更改为http-metrics便可，这个在 Prometheus-Operator 对节点端点同步的代码中有相关定义，感兴趣的能够点此查看完整代码：

Subsets: []v1.EndpointSubset{ { Ports: []v1.EndpointPort{ { Name: "https-metrics", Port: 10250, }, { Name: "http-metrics", Port: 10255, }, { Name: "cadvisor", Port: 4194, }, }, }, }, 

修改完成后，直接在该文件夹下面执行建立资源命令便可：

$ kubectl apply -f . 

部署完成后，会建立一个名为monitoring的 namespace，因此资源对象对将部署在改命名空间下面，此外 Operator 会自动建立4个 CRD 资源对象：

$ kubectl get crd |grep coreos alertmanagers.monitoring.coreos.com 5d prometheuses.monitoring.coreos.com 5d prometheusrules.monitoring.coreos.com 5d servicemonitors.monitoring.coreos.com 5d 

能够在 monitoring 命名空间下面查看全部的 Pod，其中 alertmanager 和 prometheus 是用 StatefulSet 控制器管理的，其中还有一个比较核心的 prometheus-operator 的 Pod，用来控制其余资源对象和监听对象变化的：

$ kubectl get pods -n monitoring
NAME                                  READY     STATUS    RESTARTS   AGE
alertmanager-main-0                   2/2       Running   0          21h
alertmanager-main-1                   2/2       Running   0          21h
alertmanager-main-2                   2/2       Running   0          21h
grafana-df9bfd765-f4dvw               1/1       Running   0          22h
kube-state-metrics-77c9658489-ntj66   4/4       Running   0          20h
node-exporter-4sr7f                   2/2       Running   0          21h
node-exporter-9mh2r                   2/2       Running   0          21h
node-exporter-m2gkp                   2/2       Running   0          21h
prometheus-adapter-dc548cc6-r6lhb     1/1       Running   0          22h
prometheus-k8s-0                      3/3       Running   1          21h
prometheus-k8s-1                      3/3       Running   1          21h
prometheus-operator-bdf79ff67-9dc48   1/1       Running   0          21h

查看建立的 Service:

kubectl get svc -n monitoring
NAME                    TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S) AGE alertmanager-main ClusterIP 10.110.204.224 <none> 9093/TCP 23h alertmanager-operated ClusterIP None <none> 9093/TCP,6783/TCP 23h grafana ClusterIP 10.98.191.31 <none> 3000/TCP 23h kube-state-metrics ClusterIP None <none> 8443/TCP,9443/TCP 23h node-exporter ClusterIP None <none> 9100/TCP 23h prometheus-adapter ClusterIP 10.107.201.172 <none> 443/TCP 23h prometheus-k8s ClusterIP 10.107.105.53 <none> 9090/TCP 23h prometheus-operated ClusterIP None <none> 9090/TCP 23h prometheus-operator ClusterIP None <none> 8080/TCP 23h 

能够看到上面针对 grafana 和 prometheus 都建立了一个类型为 ClusterIP 的 Service，固然若是咱们想要在外网访问这两个服务的话能够经过建立对应的 Ingress 对象或者使用 NodePort 类型的 Service，咱们这里为了简单，直接使用 NodePort 类型的服务便可，编辑 grafana 和 prometheus-k8s 这两个 Service，将服务类型更改成 NodePort:

$ kubectl edit svc grafana -n monitoring
$ kubectl edit svc prometheus-k8s -n monitoring
$ kubectl get svc -n monitoring
NAME                    TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S) AGE grafana NodePort 10.98.191.31 <none> 3000:32333/TCP 23h prometheus-k8s NodePort 10.107.105.53 <none> 9090:30166/TCP 23h ...... 

更改完成后，咱们就能够经过去访问上面的两个服务了，好比查看 prometheus 的 targets 页面：

promtheus operator targets

配置

咱们能够看到大部分的配置都是正常的，只有两三个没有管理到对应的监控目标，好比 kube-controller-manager 和 kube-scheduler 这两个系统组件，这就和 ServiceMonitor 的定义有关系了，咱们先来查看下 kube-scheduler 组件对应的 ServiceMonitor 资源的定义：(prometheus-serviceMonitorKubeScheduler.yaml)

apiVersion: monitoring.coreos.com/v1 kind: ServiceMonitor metadata: labels: k8s-app: kube-scheduler name: kube-scheduler namespace: monitoring spec: endpoints: - interval: 30s # 每30s获取一次信息 port: http-metrics # 对应service的端口名 jobLabel: k8s-app namespaceSelector: # 表示去匹配某一命名空间中的service，若是想从全部的namespace中匹配用any: true matchNames: - kube-system selector: # 匹配的 Service 的labels，若是使用mathLabels，则下面的全部标签都匹配时才会匹配该service，若是使用matchExpressions，则至少匹配一个标签的service都会被选择 matchLabels: k8s-app: kube-scheduler 

上面是一个典型的 ServiceMonitor 资源文件的声明方式，上面咱们经过selector.matchLabels在 kube-system 这个命名空间下面匹配具备k8s-app=kube-scheduler这样的 Service，可是咱们系统中根本就没有对应的 Service，因此咱们须要手动建立一个 Service：（prometheus-kubeSchedulerService.yaml）

apiVersion: v1 kind: Service metadata: namespace: kube-system name: kube-scheduler labels: k8s-app: kube-scheduler spec: selector: component: kube-scheduler ports: - name: http-metrics port: 10251 targetPort: 10251 protocol: TCP 

10251是kube-scheduler组件 metrics 数据所在的端口，10252是kube-controller-manager组件的监控数据所在端口。

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

$ kubectl describe pod kube-scheduler-master -n kube-system
Name:         kube-scheduler-master
Namespace:    kube-system
Node:         master/10.151.30.57
Start Time:   Sun, 05 Aug 2018 18:13:32 +0800
Labels:       component=kube-scheduler tier=control-plane ...... 

咱们能够看到这个 Pod 具备component=kube-scheduler和tier=control-plane这两个标签，而前面这个标签具备更惟一的特性，因此使用前面这个标签较好，这样上面建立的 Service 就能够和咱们的 Pod 进行关联了，直接建立便可：

$ kubectl create -f prometheus-kubeSchedulerService.yaml
$ kubectl get svc -n kube-system -l k8s-app=kube-scheduler NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE kube-scheduler ClusterIP 10.102.119.231 <none> 10251/TCP 18m 

建立完成后，隔一小会儿后去 prometheus 查看 targets 下面 kube-scheduler 的状态：

promethus kube-scheduler error

咱们能够看到如今已经发现了 target，可是抓取数据结果出错了，这个错误是由于咱们集群是使用 kubeadm 搭建的，其中 kube-scheduler 默认是绑定在127.0.0.1上面的，而上面咱们这个地方是想经过节点的 IP 去访问，因此访问被拒绝了，咱们只要把 kube-scheduler 绑定的地址更改为0.0.0.0便可知足要求，因为 kube-scheduler 是以静态 Pod 的形式运行在集群中的，因此咱们只须要更改静态 Pod 目录下面对应的 YAML 文件便可：

$ ls /etc/kubernetes/manifests/ etcd.yaml kube-apiserver.yaml kube-controller-manager.yaml kube-scheduler.yaml 

将 kube-scheduler.yaml 文件中-command的--address地址更改为0.0.0.0：

containers: - command: - kube-scheduler - --leader-elect=true - --kubeconfig=/etc/kubernetes/scheduler.conf - --address=0.0.0.0 

修改完成后咱们将该文件从当前文件夹中移除，隔一下子再移回该目录，就能够自动更新了，而后再去看 prometheus 中 kube-scheduler 这个 target 是否已经正常了：

promethues-operator-kube-scheduler

你们能够按照上面的方法尝试去修复下 kube-controller-manager 组件的监控。

上面的监控数据配置完成后，如今咱们能够去查看下 grafana 下面的 dashboard，一样使用上面的 NodePort 访问便可，第一次登陆使用 admin:admin 登陆便可，进入首页后，能够发现已经和咱们的 Prometheus 数据源关联上了，正常来讲能够看到一些监控图表了：

promethues-operator-grafana