Prometheus Operator 安裝及監控k8s

摘選:https://i4t.com/4214.html

之前的文章介紹過傳統方式安裝Prometheus來監控集群，但是這種方式有一定的缺陷雖然完全可以用自定義方式來實現，但是不夠靈活，不具有通用性。在自定義監控時還需要不斷的更新Prometheus的配置。如果是kubernetes集群完全可以使用一種更原始的方式來實現kubernetes集群監控，即採用Prometheus Operator

Operator是由CoreOS公司開發的用來擴展Kubernetes API的特定應用程序控制器，用來創建、配置和管理複雜的有狀態應用，例如Mysql、緩存和監控系統。目前CoreOS官方提供了幾種Operator的代碼實現，其中就包括Prometheus Operator

下圖為Prometheus Operator 架構圖

Operator作為一個核心的控制器，它會創建Prometheus、ServiceMonitor、alertmanager以及我們的prometheus-rule這四個資源對象，operator會一直監控並維持這四個資源對象的狀態，其中創建Prometheus資源對象就是作為Prometheus Server進行監控，而ServiceMonitor就是我們用的exporter的各種抽象（exporter前面文章已經介紹了，就是提供我們各種服務的metrics的工具）Prometheus就是通過ServiceMonitor提供的metrics數據接口把我們數據pull過來的。現在我們監控prometheus不需要每個服務單獨創建修改規則。通過直接管理Operator來進行集群的監控。這裡還要說一下，一個ServiceMonitor可以通過我們的label標籤去匹配集群內部的service，而我們的prometheus也可以通過label匹配多個ServiceMonitor

prometheus-operator.png-147.6kB

其中，Operator是核心部分，作為一個控制器而存在，Operator會創建Prometheus、ServiceMonitor、AlertManager及PrometheusRule這4個CRD資源對象，然後一直監控並維持這4個CRD資源對象的狀態

• Prometheus 資源對象是作為Prometheus Service存在的
• ServiceMonitor 資源對象是專門提供metrics數據接口的exporter的抽象，Prometheus就是通過ServiceMonitor提供的metrics數據接口去 pull 數據的
• AlerManager 資源對象是對應alertmanager組件
• PrometheusRule 資源對象是被Prometheus實例使用的告警規則文件

CRD簡介
全稱CustomResourceDefinition，在Kubernetes中一切都可視為資源，在Kubernetes1.7之後增加對CRD自定義資源二次開發能力開擴展Kubernetes API，當我們創建一個新的CRD時，Kubernetes API服務器將為你制定的每個版本創建一個新的RESTful資源路徑，我們可以根據該API路徑來創建一些我們自己定義的類型資源。CRD可以是命名空間，也可以是集群範圍。由CRD的作用域scpoe字段中所制定的，與現有的內置對象一樣，刪除名稱空間將刪除該名稱中的所有自定義對象


簡單的來說CRD是對Kubernetes API的擴展，Kubernetes中的每個資源都是一個API對象的集合，例如yaml文件中定義spec那樣，都是對Kubernetes中資源對象的定義，所有的自定義資源可以跟Kubernetes中內建的資源一樣使用Kubectl 

這樣，在集群中監控數據，就變成Kubernetes直接去監控資源對象，Service和ServiceMonitor都是Kubernetes的資源對象，一個ServiceMonitor可以通過labelSelector匹配一類Service，Prometheus也可以通過labelSelector匹配多個ServiceMonitor，並且Prometheus和AlertManager都是自動感知監控告警配置的變化，不需要認為進行reload操作。

安裝

前天我們也說了Operator是原生支持Prometheus的，可以通過服務發現來監控集群，並且是通用安裝。也就是operator提供的yaml文件，基本上在Prometheus是可以直接使用的，需要改動的地方可能就只有幾處

有點需要說明一下，前面我們手動安裝了prometheus，在這裡都需要刪除，有一些服務會影響我們這裡的資源對象創建，例如node-exporter

image_1dfbqvbe7cf1u461d3e9ghcni9.png-152.1kB

#首先我們下載operator
#我這裡提供的yaml文件和下面的鏡像版本是對應的，如果使用官網的請自行下載鏡像
wget -P /root/ http://down.i4t.com/abcdocker-prometheus-operator.yaml.zip
unzip abcdocker-prometheus-operator.yaml.zip
cd /root/kube-prometheus-master/manifests


#官方下載 (使用官方下載的出現鏡像版本不相同請自己找鏡像版本)
wget -P /root/ https://github.com/coreos/kube-prometheus/archive/master.zip
unzip master.zip
cd /root/kube-prometheus-master/manifests

prometheus-serviceMonitorKubelet.yaml (這個文件是用來收集我們service的metrics數據的)

這裡不進行修改

cat prometheus-serviceMonitorKubelet.yaml

apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
 labels:
 k8s-app: kubelet
 name: kubelet
 namespace: monitoring
spec:
 endpoints:
 - bearerTokenFile: /var/run/secrets/kubernetes.io/serviceaccount/token
 honorLabels: true
 interval: 30s
 port: https-metrics
 scheme: https
 tlsConfig:
 insecureSkipVerify: true
 - bearerTokenFile: /var/run/secrets/kubernetes.io/serviceaccount/token
 honorLabels: true 

 interval: 30s
 metricRelabelings:
 - action: drop
 regex: container_(network_tcp_usage_total|network_udp_usage_total|tasks_state|cpu_load_average_10s)
 sourceLabels:
 - __name__
 path: /metrics/cadvisor
 port: https-metrics
 scheme: https
 tlsConfig:
 insecureSkipVerify: true
 jobLabel: k8s-app
 namespaceSelector: #匹配命名空間，這個代表的意思就是會去匹配kube-system命名空間下，具有k8s-app=kubelet的標籤，會將匹配的標籤納入我們prometheus監控中
 matchNames:
 - kube-system
 selector: #這三行是用來匹配我們的service
 matchLabels:
 k8s-app: kubelet

由於國內網絡問題，有一些鏡像無法直接下載。我這裡提供了所有的鏡像，只要導入進去即可

#我這裡已經做了免密，直接拷貝鏡像地址在所有的服務器上reload一下即可

wget -c http://down.i4t.com/abcdocker-prometheus-opertor.tar
#這裡等待會慢些，一會就可以下載好了(遇到報錯等等，如果不成功可以將url複製在瀏覽器在rz上去,總比Google拉不了鏡像強)
for i in k8s-master1 k8s-master2 k8s-node1 k8s-node2;do
 echo "----- $i -----"
 scp abcdocker-prometheus-opertor.tar root@$i:/opt/
 ssh root@$i "docker load -i /opt/abcdocker-prometheus-opertor.tar"
done 


#這樣集群所有節點都有鏡像，不存在鏡像拉取不到的錯誤（這裡的yaml文件最好使用我的版本，否則後面yaml文件更新了，鏡像還需要從新獲取）這裡有一個k8s.gcr.io/addon-resizer因為在Google上面被牆攔住了，所以大家還是乖乖的用我的鏡像吧

這裡修改完畢後，我們就可以直接創建配置文件

#需要在manifests目錄下進行創建，我會將整個yaml打包，直接進入即可
[root@yzsjhl82-138 ~]# cd kube-prometheus-master/manifests/
[root@k8s-master1 manifests]# kubectl apply -f .
...
role.rbac.authorization.k8s.io/prometheus-k8s created
role.rbac.authorization.k8s.io/prometheus-k8s created
service/prometheus-k8s created
serviceaccount/prometheus-k8s created
unable to recognize "0prometheus-operator-serviceMonitor.yaml": no matches for kind "ServiceMonitor" in version "monitoring.coreos.com/v1"
unable to recognize "alertmanager-alertmanager.yaml": no matches for kind "Alertmanager" in version "monitoring.coreos.com/v1"
unable to recognize "alertmanager-serviceMonitor.yaml": no matches for kind "ServiceMonitor" in version "monitoring.coreos.com/v1"
unable to recognize "grafana-serviceMonitor.yaml": no matches for kind "ServiceMonitor" in version "monitoring.coreos.com/v1"
unable to recognize "kube-state-metrics-serviceMonitor.yaml": no matches for kind "ServiceMonitor" in version "monitoring.coreos.com/v1"
unable to recognize "node-exporter-serviceMonitor.yaml": no matches for kind "ServiceMonitor" in version "monitoring.coreos.com/v1"
unable to recognize "prometheus-prometheus.yaml": no matches for kind "Prometheus" in version "monitoring.coreos.com/v1"
unable to recognize "prometheus-rules.yaml": no matches for kind "PrometheusRule" in version "monitoring.coreos.com/v1"
unable to recognize "prometheus-serviceMonitor.yaml": no matches for kind "ServiceMonitor" in version "monitoring.coreos.com/v1"
unable to recognize "prometheus-serviceMonitorApiserver.yaml": no matches for kind "ServiceMonitor" in version "monitoring.coreos.com/v1"
unable to recognize "prometheus-serviceMonitorCoreDNS.yaml": no matches for kind "ServiceMonitor" in version "monitoring.coreos.com/v1"
unable to recognize "prometheus-serviceMonitorKubeControllerManager.yaml": no matches for kind "ServiceMonitor" in version "monitoring.coreos.com/v1"
unable to recognize "prometheus-serviceMonitorKubeScheduler.yaml": no matches for kind "ServiceMonitor" in version "monitoring.coreos.com/v1"
unable to recognize "prometheus-serviceMonitorKubelet.yaml": no matches for kind "ServiceMonitor" in version "monitoring.coreos.com/v1"

#由於配置文件有先後順序，所以這邊有一些文件沒有獲取到，這裡沒有關係。我們在從新apply刷新一下即可
[root@k8s-master1 manifests]# kubectl apply -f .
 

當我們部署成功之後，我們可以查看一下crd,yaml文件會自動幫我們創建crd文件。只有我們創建了crd文件，我們的serviceMonitor才會有用

[root@k8s-master1 manifests]# kubectl get crd
NAME CREATED AT
alertmanagers.monitoring.coreos.com 2019-07-09T17:38:48Z
podmonitors.monitoring.coreos.com 2019-07-09T17:38:48Z
prometheuses.monitoring.coreos.com 2019-07-09T17:38:48Z
prometheusrules.monitoring.coreos.com 2019-07-09T17:38:49Z
servicemonitors.monitoring.coreos.com 2019-07-09T17:38:49Z

其他的資源文件都會部署在一個命名空間下面，在monitoring裡面是operator Pod對應的列表

[root@k8s-master1 manifests]# kubectl get pod -n monitoring
NAME READY STATUS RESTARTS AGE
alertmanager-main-0 2/2 Running 0 49m
alertmanager-main-1 2/2 Running 0 48m
alertmanager-main-2 2/2 Running 0 48m
grafana-545d8c5576-8lgvg 1/1 Running 0 51m
kube-state-metrics-c86f5648c-4ffdb 4/4 Running 0 25s
node-exporter-7hthp 2/2 Running 0 51m
node-exporter-r7np2 2/2 Running 0 51m
node-exporter-ssbdr 2/2 Running 0 51m
node-exporter-wd7jm 2/2 Running 0 51m
prometheus-adapter-66fc7797fd-bd7gx 1/1 Running 0 51m
prometheus-k8s-0 3/3 Running 1 49m
prometheus-k8s-1 3/3 Running 1 49m
prometheus-operator-7cfc488cdd-wtm8w 1/1 Running 0 51m

其中prometheus和alertmanager採用的StatefulSet，其他的Pod則採用deployment創建

[root@k8s-master1 manifests]# kubectl get deployments.apps -n monitoring
NAME READY UP-TO-DATE AVAILABLE AGE
grafana 1/1 1 1 53m
kube-state-metrics 1/1 1 1 53m
prometheus-adapter 1/1 1 1 53m
prometheus-operator 1/1 1 1 53m
[root@k8s-master1 manifests]# kubectl get statefulsets.apps -n monitoring
NAME READY AGE 

alertmanager-main 3/3 52m
prometheus-k8s 2/2 52m

#其中prometheus-operator是我們的核心文件，它是監控我們prometheus和alertmanager的文件

現在創建完成後我們還無法直接訪問prometheus

[root@k8s-master1 manifests]# kubectl get svc -n monitoring |egrep "prometheus|grafana|alertmanage"
alertmanager-main ClusterIP 10.106.59.84 <none> 9093/TCP 59m
alertmanager-operated ClusterIP None <none> 9093/TCP,6783/TCP 57m
grafana ClusterIP 10.110.58.16 <none> 3000/TCP 59m
prometheus-adapter ClusterIP 10.105.34.241 <none> 443/TCP 59m
prometheus-k8s ClusterIP 10.102.246.32 <none> 9090/TCP 59m
prometheus-operated ClusterIP None <none> 9090/TCP 57m
prometheus-operator ClusterIP None <none> 8080/TCP 59m
/<none>/<none>/<none>/<none>/<none>/<none>/<none>

由於默認的yaml文件svc採用的是ClusterIP，我們無法進行訪問。這裡我們可以使用ingress進行代理，或者使用node-port臨時訪問。我這裡就修改一下svc，使用node-port進行訪問

#我這裡使用edit進行修改，或者修改yaml文件apply下即可

kubectl edit svc -n monitoring prometheus-k8s
#注意修改的svc是prometheus-k8s因為這個有clusterIP
kubectl edit svc -n monitoring grafana
kubectl edit svc -n monitoring alertmanager-main
#三個文件都需要修改，不要修改錯了。都是修改有clusterIP的
...
 type: NodePort #將這行修改為NodePort

prometheus-k8s、grafana和alertmanager-main都是隻修改type=clusterIP這行

image_1dfc0kddh1lbk1gc11r4k16q1rim.png-73.3kB

修改完畢後，我們在查看svc，就會發現這幾個都包含node端口了，接下來在任意集群節點訪問即可

#operator會自動幫我們刷新配置，我們需要修改的地方不是很多

[root@k8s-master1 manifests]# kubectl get svc -n monitoring |egrep "prometheus|grafana|alertmanage"
alertmanager-main NodePort 10.106.59.84 <none> 9093:30857/TCP 66m
alertmanager-operated ClusterIP None <none> 9093/TCP,6783/TCP 64m
grafana NodePort 10.110.58.16 <none> 3000:32479/TCP 66m
prometheus-adapter ClusterIP 10.105.34.241 <none> 443/TCP 66m
prometheus-k8s NodePort 10.102.246.32 <none> 9090:32556/TCP 66m
prometheus-operated ClusterIP None <none> 9090/TCP 64m
prometheus-operator ClusterIP None <none> 8080/TCP 66m
/<none>/<none>/<none>/<none>/<none>/<none>/<none> 

接下來我們查看prometheus的Ui界面

[root@abcdocker manifests]# kubectl get svc -n monitoring |grep prometheus-k8s
prometheus-k8s NodePort 10.110.6.193 <none> 9090:31723/TCP 8m10s
/<none>

我們訪問的集群任意IP:31723

123123.png-584.6kB

這裡kube-controller-manager和kube-scheduler並管理的目標，其他的都有。這裡的就是和我們yaml文件裡面定義的有關係

image_1dfvaqmqj1oel18kfu01p79e61o.png-47.6kB

配置文件解釋

[root@yzsjhl82-138 ~]# cd kube-prometheus-master/manifests/
[root@yzsjhl82-138 manifests]# vim prometheus-serviceMonitorKubeScheduler.yaml
apiVersion: monitoring.coreos.com/v1 #kubectl get crd裡面包含的，不進行修改
kind: ServiceMonitor
metadata:
 labels:
 k8s-app: kube-scheduler
 name: kube-scheduler #定義的名稱
 namespace: monitoring 
spec:
 endpoints:
 - interval: 30s
 port: http-metrics #這裡定義的就是在svc上的端口名稱
 jobLabel: k8s-app
 namespaceSelector: #表示匹配哪一個命名空間，配置any:true則回去所有命名空間中查詢
 matchNames:
 - kube-system
 selector: #這裡大概意思就是匹配kube-system命名空間下具有k8s-app=kube-scheduler標籤的svc
 matchLabels:
 k8s-app: kube-scheduler

這時候我們可以手動匹配一下，根據yaml文件的配置是匹配kube-system命名空間下標籤為k8s-app=kube-scheduler

#通過匹配可以看到，在kube-system沒有一個標籤為kube-scheduler
[root@abcdocker manifests]# kubectl get svc -n kube-system -l k8s-app=kube-scheduler
No resources found.
[root@abcdocker manifests]# kubectl get svc -n kube-system -l k8s-app=kubelet
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kubelet ClusterIP None <none> 10250/TCP 24h
/<none> 

要想要kube-scheduler關聯上，我們就需要手動創建一個svc

未完=========

閱讀更多 DevOps運維 的文章

關鍵字: 監控 方式 YAML