prometheus-operator

一、速補基礎

1、什么是metrics

缺省是在http(s)的url的/metrics輸出。 而metrics要么程序定義輸出(模塊或者自定義開發)，要么用官方的各種exporter(node-exporter，mysqld-exporter，memcached_exporter…)采集要監控的信息占用一個web端口然后輸出成metrics格式的信息，prometheus server去收集各個target的metrics存儲起來(tsdb)。 用戶可以在prometheus的http頁面上用promQL(prometheus的查詢語言)或者(grafana數據來源就是用)api去查詢一些信息，也可以利用pushgateway去統一采集然后prometheus從pushgateway采集(所以pushgateway類似於zabbix的proxy)，

k8s的資源指標分類：
資源指標：metrics-server內建API
自定義指標：prometheus來采集，需要組件k8s-prometheus-adapter

一、核心指標獲取

metrics-server：API server
--- kubectl api-versions 中默認不包含metrics.k8s.io/v1beta1；使用時需要添加kube-aggregator前綴
--- metrics部署文件：https://github.com/kubernetes-sigs/metrics-server
下載到本地並應用之后就可以使用kubectl api-versions查詢，查到metrics.k8s.io/v1beta1已經存在
應用之前需要修改metrics-server-deployment.yaml文件，添加如下：

Warming： metrics-server這個容器不能通過CoreDNS 10.96.0.10:53 解析各Node的主機名，metrics-server連節點時默認是連接節點的主機名，需要加個參數，讓它連接節點的IP：“–kubelet-preferred-address-types=InternalIP”
　　　　　　　　因為10250是https端口，連接它時需要提供證書，所以加上–kubelet-insecure-tls，表示不驗證客戶端證書，此前的版本中使用–source=這個參數來指定不驗證客戶端證書

 

 執行kubectl apply -f 

 

 使用kubectl top nodes查看

二、自定義指標  --- Prometheus

♦   node_exporter用來暴露node信息，還有其他的exporter

♦   PromQL查詢語句，不能直接被k8s直接解析，需要通過kube-state-metrics組件轉k8s-promethues-adapter轉為Custom Metrics API

三、prometheus-operator部署

聲明式API：
在Kubernetes中我們使用Deployment、DamenSet、StatefulSet來管理應用Workload，使用Service、Ingress來管理應用的訪問方式，使用ConfigMap和Secret來管理應用配置。我們在集群中對這些資源的創建，更新，刪除的動作都會被轉換為事件(Event)，Kubernetes的Controller Manager負責監聽這些事件並觸發相應的任務來滿足用戶的期望。這種方式我們成為聲明式，用戶只需要關心應用程序的最終狀態，其它的都通過Kubernetes來幫助我們完成，通過這種方式可以大大簡化應用的配置管理復雜度

因為svc的負載均衡，所以在K8S里監控metrics基本最小單位都是一個svc背后的pod為target，所以prometheus-operator創建了對應的CRD: kind: ServiceMonitor ，創建的ServiceMonitor里聲明需要監控選中的svc的label以及metrics的url路徑的和namespaces即可
工作架構如下圖所示。

 

 

 下載項目：

git clone https://github.com/coreos/prometheus-operator.git

拉取到文件后我們先創建prometheus-operator：

$ cd prometheus-operator
$ kubectl apply -f bundle.yaml
clusterrolebinding.rbac.authorization.k8s.io/prometheus-operator created
clusterrole.rbac.authorization.k8s.io/prometheus-operator created
deployment.apps/prometheus-operator created
serviceaccount/prometheus-operator created

確認pod運行，以及我們可以發現operator的pod在有RBAC下創建了一個APIService：

$ kubectl get pod
NAME                                   READY     STATUS    RESTARTS   AGE
prometheus-operator-6db8dbb7dd-djj6s   1/1       Running   0          1m
$ kubectl get APIService | grep monitor
v1.monitoring.coreos.com               2018-10-09T10:49:47Z

Prometheus Operator引入的自定義資源包括：

• Prometheus
• ServiceMonitor
• Alertmanager

這四個CRD作用如下

• Prometheus: 由 Operator 依據一個自定義資源kind: Prometheus類型中，所描述的內容而部署的 Prometheus Server 集群，可以將這個自定義資源看作是一種特別用來管理Prometheus Server的StatefulSets資源。
• ServiceMonitor: 一個Kubernetes自定義資源(和kind: Prometheus一樣是CRD)，該資源描述了Prometheus Server的Target列表，Operator 會監聽這個資源的變化來動態的更新Prometheus Server的Scrape targets並讓prometheus server去reload配置(prometheus有對應reload的http接口/-/reload)。而該資源主要通過Selector來依據 Labels 選取對應的Service的endpoints，並讓 Prometheus Server 通過 Service 進行拉取（拉）指標資料(也就是metrics信息)，metrics信息要在http的url輸出符合metrics格式的信息，ServiceMonitor也可以定義目標的metrics的url。
• Alertmanager：Prometheus Operator 不只是提供 Prometheus Server 管理與部署，也包含了 AlertManager，並且一樣通過一個 kind: Alertmanager 自定義資源來描述信息，再由 Operator 依據描述內容部署 Alertmanager 集群。
• PrometheusRule:對於Prometheus而言，在原生的管理方式上，我們需要手動創建Prometheus的告警文件，並且通過在Prometheus配置中聲明式的加載。而在Prometheus Operator模式中，告警規則也編程一個通過Kubernetes API 聲明式創建的一個資源.告警規則創建成功后，通過在Prometheus中使用想servicemonitor那樣用ruleSelector通過label匹配選擇需要關聯的PrometheusRule即可。