Kubernetes集羣部署史上最詳細（二）Prometheus監控Kubernetes集羣

時間 2019-12-04

標籤 kubernetes 集羣部署史上詳細 prometheus 監控欄目負載均衡简体版

原文原文鏈接

使用Prometheus監控Kubernetes集羣

監控方面Grafana採用YUM安裝經過服務形式運行，部署在Master上，而Prometheus則經過POD運行，Grafana經過使用Prometheus的service地址來獲取數據源。node

Prometheus的配置清單在kubernetes二進制程序包中就有，下載地址，git

解壓後有一個cluster目錄，該目錄裏面的addons裏面有所須要的插件，好比dns、dashboard以及prometheus等。github

我用的就是它自帶的這個prometheus清單文件，可是它裏面有些問題好比prometheus這個組件須要PV可是原始的包裏面沒有這個PV你須要手動創建，我這裏已經寫好了yaml文件不過使用的是hostpath，主要是爲了測試方便若是是生產環境中不建議這樣使用至少也要用個NFS這種存儲，另外它原始的清單文件中使用的prometheus等鏡像版本較低雖然也可使用可是我修改了這些版本使用的最新的版本，最新版本中有些啓動參數變化了因此也修改了響應的內容。因此你直接使用我修改的這個就能夠，從下面的連接下載，另外這裏還包括了grafana的2個dashboard，這兩個也作了修改，由於從官網下載的模板對於有些指標識別不了（由於版本問題或者其餘問題致使指標名稱對不上），因此須要修改。後端

文件說明

上圖是原始內容，我包裏的yaml文件只比它多一個。上面分紅4個部分，api

下面這4個是部署prometheus服務端用的
prometheus-configmap.yaml # 我在原有的配置中增長了global區域
prometheus-rabc.yaml
prometheus-service.yaml
prometheus-statefulset.yamlapp

下面這2個是部署node_exporter用的
node-exporter-ds.yaml
node-exporter-service.yamltcp

下面3個是部署kube-state-metrics用的，這個組件是對監控內容的補充，雖然你部署了metric-server、kubelet也提供了cadvisor接口以及上面
部署的node_exporter，可是還有一些指標須要監控好比調度了多少副本如今有幾個可用、不一樣狀態的POD有多少、POD重啓了多少次、運行了多少job等
這個組件也是從API SERVER上去獲取數據可是這些數據是原始數據而不像kubectl那樣可能會爲了便於理解而對某些數據作修改
kube-state-metrics-deployment.yaml
kube-state-metrics-rabc.yaml
kube-state-metrics-service.yaml測試

下面4個是alertmanager報警組件的部署
alertmanager-service.yaml
alertmanager-pvc.yaml
alertmanager-deployment.yaml
alertmanager-configmap.yamllua

kube-state-metrics與metric-server的對比

metric-server（或heapster）是一個集羣組件按期經過kubelet來獲取集羣節點的cpu、內存使用率這種監控指標，並且它只保留最新數據且存儲在內存中，不負責發送給第三方，你能夠經過其餘方式把他們發送給存儲後端，如influxdb或雲廠商，他當前的核心做用是：爲HPA等組件提供決策指標支持。spa

kube-state-metrics關注於獲取k8s各類資源對象的最新狀態，如deployment或者daemonset，它在內存中保留kubernetes集羣狀態的快照而且在隨後的時間裏基於這個快照生成新的指標，並且它也不負責發數據發給第三方。將kube-state-metrics做爲單獨的項目，還能夠從Prometheus等監控系統訪問這些指標。

之因此沒有把kube-state-metrics歸入到metric-server的能力中，是由於他們的關注點本質上是不同的。metric-server僅僅是獲取、格式化現有數據，寫入特定的存儲，實質上是一個監控系統。而kube-state-metrics是將k8s的運行情況在內存中作了個快照，而且獲取新的指標，但他沒有能力導出這些指標換個角度講，kube-state-metrics自己是metric-server的一種數據來源，雖然如今沒有這麼作。另外，像Prometheus這種監控系統，並不會去用metric-server中的數據，他都是本身作指標收集、集成的（Prometheus包含了metric-server的能力），但Prometheus能夠監控metric-server自己組件的監控狀態並適時報警，這裏的監控就能夠經過kube-state-metrics來實現，如metric-serverpod的運行狀態。

POD的Annotations是什麼

Annotations將任何非標識metadata附加到對象，標籤可用於選擇對象並查找知足某些條件的對象集合。相比之下，Annotations不用於標識和選擇對象，雖然它也是鍵值形式。Annotations不會被Kubernetes直接使用，其主要目的是方便用戶閱讀查找。

Prometheus配置文件說明

# Kubernetes的API SERVER會暴露API服務，Promethues集成了對Kubernetes的自動發現，它有5種模式：Node、Service
# 、Pod、Endpoints、ingress，下面是Prometheus官方給出的對Kubernetes服務發現的實例。這裏你會看到大量的relabel_configs，
# 其實你就是把全部的relabel_configs去掉同樣能夠對kubernetes作服務發現。relabel_configs僅僅是對採集過來的指標作二次處理，好比
# 要什麼不要什麼以及替換什麼等等。而以__meta_開頭的這些元數據標籤都是實例中包含的，而relabel則是動態的修改、覆蓋、添加刪除這些標籤
# 或者這些標籤對應的值。並且以__開頭的標籤一般是系統內部使用的，所以這些標籤不會被寫入樣本數據中，若是咱們要收集這些東西那麼則要進行
# relabel操做。固然reabel操做也不只限於操做__開頭的標籤。
#
# action的行爲：
# replace：默認行爲，不配置action的話就採用這種行爲，它會根據regex來去匹配source_labels標籤上的值，並將並將匹配到的值寫入target_label中
# labelmap：它會根據regex去匹配標籤名稱，並將匹配到的內容做爲新標籤的名稱，其值做爲新標籤的值
# keep：僅收集匹配到regex的源標籤，而會丟棄沒有匹配到的全部標籤，用於選擇
# drop：丟棄匹配到regex的源標籤，而會收集沒有匹配到的全部標籤，用於排除
# labeldrop：使用regex匹配標籤，符合regex規則的標籤將從target實例中移除，其實也就是不收集不保存
# labelkeep：使用regex匹配標籤，僅收集符合regex規則的標籤，不符合的不收集
#
global:
scrape_interval: 10s
evaluation_interval: 30s
scrape_configs:
# 用於發現API SERVER
- job_name: 'kubernetes-apiservers'

kubernetes_sd_configs:
# 發現endpoints，它是從列出的服務端點發現目標，這個endpoints來自於Kubernetes中的service，每個service都有對應的endpoints，這裏是一個列表
# 能夠是一個IP:PORT也能夠是多個，這些IP:PORT就是service經過標籤選擇器選擇的POD的IP和端口。因此endpoints角色就是用來發現server對應的pod的IP的
# kubernetes會有一個默認的service，經過找到這個service的endpoints就找到了api server的IP:PORT，那endpoints有不少，我怎麼知道哪一個是api server呢
# 這個就靠source_labels指定的標籤名稱了。
- role: endpoints
# 經過什麼形式來鏈接，默認是https
scheme: https
# 下面這個ca_file和token_file的路徑都是默認的，你可能默認設置能用麼？其實能夠，由於每個運行起來的POD kubernetes都會爲其
# 建立一個serviceaccout的Secret而且掛載到下面的目錄上，裏面就有ca.crt和token這兩個文件，你能夠本身啓動一個POD，而後經過
# kubectl describe pods 來查看，必定會在Volumes下面有一個default-token-XXX的東西，而且Mounts裏面有下面的目錄。
tls_config:
ca_file: /var/run/secrets/kubernetes.io/serviceaccount/ca.crt
bearer_token_file: /var/run/secrets/kubernetes.io/serviceaccount/token

# 下面的含義是源標籤__meta_kubernetes_namespace等若是其值爲default;kubernetes;https標籤順序和值要對應。換句話說就是
# 當__meta_kubernetes_namespace, __meta_kubernetes_service_name, __meta_kubernetes_endpoint_port_name三者對應的
# 值爲default、kubernetes、https則進行保留，並且該endpoints對應的地址爲api server的地址。
#
# __meta_kubernetes_namespace 端點對象的命名空間，在不一樣對象上這個標籤的含義不一樣，在角色是endpoints中這個是端點對象的名稱空間
# __meta_kubernetes_service_name 端點對象的服務名稱
# __meta_kubernetes_endpoint_port_name 端點的端口名稱
#
# kubernetes默認在default名稱空間有一個叫作kubernetes的service，因此這個service的有3個設置對應的就是下面三個標籤
# __meta_kubernetes_namespace 值爲default
# __meta_kubernetes_service_name 值爲kubernetes
# __meta_kubernetes_endpoint_port_name 值爲https
relabel_configs:
- source_labels: [__meta_kubernetes_namespace, __meta_kubernetes_service_name, __meta_kubernetes_endpoint_port_name]
action: keep
regex: default;kubernetes;https

# 配置針對kubelet的服務發現以及對標籤的處理，是獲取kubelet上/metrics接口數據來獲取node的資源使用狀況
- job_name: 'kubernetes-nodes-kubelet'
scheme: https
tls_config:
ca_file: /var/run/secrets/kubernetes.io/serviceaccount/ca.crt
# 跳過CA驗證
# insecure_skip_verify: true
bearer_token_file: /var/run/secrets/kubernetes.io/serviceaccount/token

kubernetes_sd_configs:
# 使用node角色，它使用默認的kubelet提供的http端口來發現集羣中每一個node節點。那具體地址是什麼呢？
# 地址類型有四種NodeInternalIP, NodeExternalIP, NodeLegacyHostIP 和 NodeHostName，默認爲這四個中第一個可用的地址。
# 那麼這裏爲何使用node角色呢？由於node角色就是用來發現kubelet的
# __meta_kubernetes_node_name：節點對象的名字
# __meta_kubernetes_node_label_<labelname>：表示節點對象上的每個標籤
# __meta_kubernetes_node_annotation_<annotationname>：表示節點對象上的每個annotation
# __meta_kubernetes_node_address_<address_type>：若是存在，那麼將是每個節點地址類型的第一個地址
# Node模式，Prometheus會自動發現Kubernetes中全部Node節點的信息並做爲監控的目標Target。
# 而這些Target的訪問地址實際上就是Kubelet的訪問地址，而且Kubelet實際上直接內置了對Promtheus的支持
- role: node

relabel_configs:
# 保留(.+)匹配到的內容，去掉__meta_kubernetes_node_label_，實際上就是把(.+)當作新標籤，而後老標籤的值給這個新標籤，
# 這裏沒有設置source_labels，則表示匹配全部標籤
- action: labelmap
# 匹配節點對象上的每個標籤
regex: __meta_kubernetes_node_label_(.+)

# 抓取cAdvisor數據，是獲取kubelet上/metrics/cadvisor接口數據來獲取容器的資源使用狀況
- job_name: 'kubernetes-nodes-cadvisor'
scheme: https
tls_config:
ca_file: /var/run/secrets/kubernetes.io/serviceaccount/ca.crt
bearer_token_file: /var/run/secrets/kubernetes.io/serviceaccount/token

kubernetes_sd_configs:
# 使用角色爲node
- role: node

relabel_configs:
- action: labelmap
regex: __meta_kubernetes_node_label_(.+)
# 把__metrics_path__的值替換爲/metrics/cadvisor，由於默認是/metrics
- target_label: __metrics_path__
replacement: /metrics/cadvisor

# 抓取服務端點，整個這個任務都是用來發現node-exporter和kube-state-metrics-service的，這裏用的是endpoints角色，這是經過這二者的service來發現
# 的後端endpoints。另外須要說明的是若是知足採集條件，那麼在service、POD中定義的labels也會被採集進去
- job_name: 'kubernetes-service-endpoints'

kubernetes_sd_configs:
- role: endpoints

relabel_configs:
# 從新打標僅抓取到的具備 "prometheus.io/scrape: true" 的annotation的端點，意思是說若是某個service具備prometheus.io/scrape = true annotation聲明則抓取
# annotation自己也是鍵值結構，因此這裏的源標籤設置爲鍵，而regex設置值，當值匹配到regex設定的內容時則執行keep動做也就是保留，其他則丟棄.
# node-exporter這個POD的service裏面就有一個叫作prometheus.io/scrape = true的annotations因此就找到了node-exporter這個POD
- source_labels: [__meta_kubernetes_service_annotation_prometheus_io_scrape]
action: keep
regex: true

# 應用中自定義暴露的指標，也許你暴露的API接口不是/metrics這個路徑，那麼你能夠在這個POD對應的service中作一個
# "prometheus.io/path = /mymetrics" 聲明，下面的意思就是把你聲明的這個路徑賦值給__metrics_path__
# 其實就是讓prometheus來獲取自定義應用暴露的metrices的具體路徑，不過這裏寫的要和service中作好約定
# 若是service中這樣寫 prometheus.io/app-metrics-path: '/metrics' 那麼你這裏就要
# __meta_kubernetes_service_annotation_prometheus_io_app_metrics_path這樣寫
- source_labels: [__meta_kubernetes_service_annotation_prometheus_io_path]
action: replace
target_label: __metrics_path__
regex: (.+)

# 暴露自定義的應用的端口，就是把地址和你在service中定義的 "prometheus.io/port = <port>" 聲明作一個拼接
# 而後賦值給__address__，這樣prometheus就能獲取自定義應用的端口，而後經過這個端口再結合__metrics_path__來獲取
# 指標，若是__metrics_path__值不是默認的/metrics那麼就要使用上面的標籤替換來獲取真正暴露的具體路徑
- source_labels: [__address__, __meta_kubernetes_service_annotation_prometheus_io_port]
action: replace
regex: ([^:]+)(?::\d+)?;(\d+)
replacement: $1:$2
target_label: __address__

# 從新設置scheme
# 匹配源標籤__meta_kubernetes_service_annotation_prometheus_io_scheme也就是prometheus.io/scheme annotation
# 若是源標籤的值匹配到regex則把值替換爲__scheme__對應的值
- source_labels: [__meta_kubernetes_service_annotation_prometheus_io_scheme]
action: replace
target_label: __scheme__
regex: (https?)

# 下面主要是爲了給樣本添加額外信息
- action: labelmap
regex: __meta_kubernetes_service_label_(.+)
- source_labels: [__meta_kubernetes_namespace]
action: replace
target_label: kubernetes_namespace
- source_labels: [__meta_kubernetes_service_name]
action: replace
target_label: kubernetes_name

# 下面是自動發現service，不過若是要想監控service則須要安裝blackbox-exporter
- job_name: 'kubernetes-services-http'

metrics_path: /probe
# 生成__param_module="http_2xx"的label，若是是TCP探測則使用 module: [tcp_connect]
params:
module: [http_2xx]

kubernetes_sd_configs:
- role: service

relabel_configs:
# 爲了讓service能夠被探測到，那須要在service的annotation中增長 prometheus.io/scrape: true 聲明
# 也就是隻保留prometheus.io/scrape: true的service
- action: keep
regex: true
source_labels:
- __meta_kubernetes_service_annotation_prometheus_io_scrape
# 用__address__這個label的值建立一個名爲__param_target的label爲blackbox-exporter,值爲內部service的訪問地址，做爲blackbox-exporter採集用
- source_labels: [__address__]
target_label: __param_target

# 用blackbox-exporter的service地址值」prometheus-blackbox-exporter:9115"替換原__address__的值
- target_label: __address__
replacement: blackbox-exporter.example.com:9115
- source_labels: [__param_target]
target_label: instance

# 下面主要是爲了給樣本添加額外信息
- action: labelmap
regex: __meta_kubernetes_service_label_(.+)
- source_labels: [__meta_kubernetes_namespace]
target_label: kubernetes_namespace
- source_labels: [__meta_kubernetes_service_name]
target_label: kubernetes_name

# 下面是對ingresses監控，不過若是要想監控ingresses則須要安裝blackbox-exporter
- job_name: 'kubernetes-ingresses'

metrics_path: /probe
# 生成__param_module="http_2xx"的label
params:
module: [http_2xx]

kubernetes_sd_configs:
- role: ingress

relabel_configs:
# Example relabel to probe only some ingresses that have "example.io/should_be_probed = true" annotation
# - source_labels: [__meta_kubernetes_ingress_annotation_example_io_should_be_probed]
# action: keep
# regex: true
- source_labels: [__meta_kubernetes_ingress_scheme,__address__,__meta_kubernetes_ingress_path]
regex: (.+);(.+);(.+)
replacement: ${1}://${2}${3}
target_label: __param_target
- target_label: __address__
replacement: blackbox-exporter.example.com:9115
- source_labels: [__param_target]
target_label: instance
# 下面主要是爲了給樣本添加額外信息
- action: labelmap
regex: __meta_kubernetes_ingress_label_(.+)
- source_labels: [__meta_kubernetes_namespace]
target_label: kubernetes_namespace
- source_labels: [__meta_kubernetes_ingress_name]
target_label: kubernetes_name

# 抓取POD進行監控
- job_name: 'kubernetes-pods'

kubernetes_sd_configs:
- role: pod
relabel_configs:
# POD的 annotation 中含有"prometheus.io/scrape: true" 的則保留，意思就是會被Prometheus抓取，不具備這個的POD則不會被抓取
- action: keep
regex: true
source_labels:
- __meta_kubernetes_pod_annotation_prometheus_io_scrape
# 獲取POD的 annotation 中定義的"prometheus.io/path: XXX"定義的值，這個值就是你的程序暴露符合prometheus規範的metrics的地址
# 若是你的metrics的地址不是 /metrics 的話，經過這個標籤說，那麼這裏就會把這個值賦值給 __metrics_path__這個變量，由於prometheus
# 是經過這個變量獲取路徑而後進行拼接出來一個完整的URL，並經過這個URL來獲取metrics值的，由於prometheus默認使用的就是 http(s)://X.X.X.X/metrics
# 這樣一個路徑來獲取的。
- action: replace
regex: (.+)
source_labels:
- __meta_kubernetes_pod_annotation_prometheus_io_path
target_label: __metrics_path__
# 這裏是端口信息，由於你的程序頗有可能在容器中並非以80端口運行的，那麼就須要作一個拼接http(s)://x.x.x.x:xx/metrics
# __address__在prometheus中表明的就是實例的IP地址，而POD中的annotation 中定義的"prometheus.io/port: XX"就是你程序
# 被訪問到的端口，最終在prometheus中將會被顯示爲 instance=X.X.X.X:XX這樣
- action: replace
regex: ([^:]+)(?::\d+)?;(\d+)
replacement: $1:$2
source_labels:
- __address__
- __meta_kubernetes_pod_annotation_prometheus_io_port
target_label: __address__

- action: labelmap
regex: __meta_kubernetes_pod_label_(.+)
- source_labels: [__meta_kubernetes_namespace]
action: replace
target_label: kubernetes_namespace
- source_labels: [__meta_kubernetes_pod_name]
action: replace
target_label: kubernetes_pod_name

prometheus是如何識別apiserver的呢？

這些亂七八糟的標籤可能讓你眼花繚亂，咱們舉一個簡單的例子看一下，prometheus是如何識別apiserver的，看下圖