prometheus-常用資源對象

監控 Kubernetes 常用資源對象

Prometheus 來自動發現 Kubernetes 集群的節點，用到了 Prometheus 針對 Kubernetes 的服務發現機制kubernetes_sd_configs的使用，這節課我們來和大家一起了解下怎樣在 Prometheus 中來自動監控 Kubernetes 中的一些常用資源對象。

前面我們和大家介紹過了在 Prometheus 中用靜態的方式來監控 Kubernetes 集群中的普通應用，但是如果針對集群中眾多的資源對象都采用靜態的方式來進行配置的話顯然是不現實的，所以同樣我們需要使用到 Prometheus 提供的其他類型的服務發現機制。

容器監控

說到容器監控我們自然會想到cAdvisor，我們前面也說過cAdvisor已經內置在了 kubelet 組件之中，所以我們不需要單獨去安裝，cAdvisor的數據路徑為/api/v1/nodes/<node>/proxy/metrics，同樣我們這里使用 node 的服務發現模式，因為每一個節點下面都有 kubelet，自然都有cAdvisor采集到的數據指標，配置如下：

- job_name: 'kubernetes-cadvisor' kubernetes_sd_configs: - role: node scheme: https tls_config: ca_file: /var/run/secrets/kubernetes.io/serviceaccount/ca.crt bearer_token_file: /var/run/secrets/kubernetes.io/serviceaccount/token relabel_configs: - action: labelmap regex: __meta_kubernetes_node_label_(.+) - target_label: __address__ replacement: kubernetes.default.svc:443 - source_labels: [__meta_kubernetes_node_name] regex: (.+) target_label: __metrics_path__ replacement: /api/v1/nodes/${1}/proxy/metrics/cadvisor 

上面的配置和我們之前配置 node-exporter 的時候幾乎是一樣的，區別是我們這里使用了 https 的協議，另外需要注意的是配置了 ca.cart 和 token 這兩個文件，這兩個文件是 Pod 啟動后自動注入進來的，通過這兩個文件我們可以在 Pod 中訪問 apiserver，比如我們這里的__address__不在是 nodeip 了，而是 kubernetes 在集群中的服務地址，然后加上__metrics_path__的訪問路徑：/api/v1/nodes/${1}/proxy/metrics/cadvisor，現在同樣更新下配置，然后查看 Targets 路徑：

然后我們可以切換到 Graph 路徑下面查詢容器相關數據，比如我們這里來查詢集群中所有 Pod 的 CPU 使用情況，這里用的數據指標是 container_cpu_usage_seconds_total，然后去除一些無效的數據，查詢1分鍾內的數據，由於查詢到的數據都是容器相關的，最好要安裝 Pod 來進行聚合，對應的promQL語句如下：

sum by (pod_name)(rate(container_cpu_usage_seconds_total{image!="", pod_name!=""}[1m] ))

prometheus cadvisor graph

我們可以看到上面的結果就是集群中的所有 Pod 在1分鍾之內的 CPU 使用情況的曲線圖，當然還有很多數據可以獲取到，我們后面在需要的時候再和大家介紹。

apiserver 監控

apiserver 作為 Kubernetes 最核心的組件，當然他的監控也是非常有必要的，對於 apiserver 的監控我們可以直接通過 kubernetes 的 Service 來獲取：

$ kubectl get svc
NAME            TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S) AGE kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 175d 

上面這個 Service 就是我們集群的 apiserver 在集群內部的 Service 地址，要自動發現 Service 類型的服務，我們就需要用到 role 為 Endpoints 的 kubernetes_sd_configs，我們可以在 ConfigMap 對象中添加上一個 Endpoints 類型的服務的監控任務：

- job_name: 'kubernetes-apiservers' kubernetes_sd_configs: - role: endpoints 

上面這個任務是定義的一個類型為endpoints的kubernetes_sd_configs，添加到 Prometheus 的 ConfigMap 的配置文件中，然后更新配置：

$ kubectl delete -f prome-cm.yaml
$ kubectl create -f prome-cm.yaml
$ # 隔一會兒執行reload操作 $ kubectl get svc -n kube-ops NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE prometheus NodePort 10.102.74.90 <none> 9090:30358/TCP 14d $ curl -X POST "http://10.102.74.90:9090/-/reload" 

更新完成后，我們再去查看 Prometheus 的 Dashboard 的 target 頁面：

我們可以看到 kubernetes-apiservers 下面出現了很多實例，這是因為這里我們使用的是 Endpoints 類型的服務發現，所以 Prometheus 把所有的 Endpoints 服務都抓取過來了，同樣的，上面我們需要的服務名為kubernetes這個 apiserver 的服務也在這個列表之中，那么我們應該怎樣來過濾出這個服務來呢？還記得上節課的relabel_configs嗎？沒錯，同樣我們需要使用這個配置，只是我們這里不是使用replace這個動作了，而是keep，就是只把符合我們要求的給保留下來，哪些才是符合我們要求的呢？我們可以把鼠標放置在任意一個 target 上，可以查看到Before relabeling里面所有的元數據，比如我們要過濾的服務是 default 這個 namespace 下面，服務名為 kubernetes 的元數據，所以這里我們就可以根據對應的__meta_kubernetes_namespace和__meta_kubernetes_service_name這兩個元數據來 relabel

prometheus before lable

另外由於 kubernetes 這個服務對應的端口是443，需要使用 https 協議，所以這里我們需要使用 https 的協議，對應的就需要將對應的 ca 證書配置上，如下：

- job_name: 'kubernetes-apiservers' kubernetes_sd_configs: - role: endpoints scheme: https tls_config: ca_file: /var/run/secrets/kubernetes.io/serviceaccount/ca.crt bearer_token_file: /var/run/secrets/kubernetes.io/serviceaccount/token relabel_configs: - source_labels: [__meta_kubernetes_namespace, __meta_kubernetes_service_name, __meta_kubernetes_endpoint_port_name] action: keep regex: default;kubernetes;https 

現在重新更新配置文件、重新加載 Prometheus，切換到 Prometheus 的 Targets 路徑下查看：

promethues apiserver

現在可以看到 kubernetes-apiserver 這個任務下面只有 apiserver 這一個實例了，證明我們的 relabel 是成功的，現在我們切換到 graph 路徑下面查看下采集到數據，比如查詢 apiserver 的總的請求數：

sum(rate(apiserver_request_count[1m])) 

這里我們使用到了 promql 里面的 rate 和 sum函數，表示的意思是 apiserver 在1分鍾內總的請求數。

apiserver request count

這樣我們就完成了對 Kubernetes APIServer 的監控。

另外如果我們要來監控其他系統組件，比如 kube-controller-manager、kube-scheduler 的話應該怎么做呢？由於 apiserver 服務 namespace 在 default 使用默認的 Service kubernetes，而其余組件服務在 kube-system 這個 namespace 下面，如果我們想要來監控這些組件的話，需要手動創建單獨的 Service，其中 kube-sheduler 的指標數據端口為 10251，kube-controller-manager 對應的端口為 10252，大家可以嘗試下自己來配置下這幾個系統組件。

Service 的監控

上面的 apiserver 實際上是一種特殊的 Service，現在我們同樣來配置一個任務用來專門發現普通類型的 Service：

- job_name: 'kubernetes-service-endpoints' kubernetes_sd_configs: - role: endpoints relabel_configs: - source_labels: [__meta_kubernetes_service_annotation_prometheus_io_scrape] action: keep regex: true - source_labels: [__meta_kubernetes_service_annotation_prometheus_io_scheme] action: replace target_label: __scheme__ regex: (https?) - source_labels: [__meta_kubernetes_service_annotation_prometheus_io_path] action: replace target_label: __metrics_path__ regex: (.+) - source_labels: [__address__, __meta_kubernetes_service_annotation_prometheus_io_port] action: replace target_label: __address__ regex: ([^:]+)(?::\d+)?;(\d+) replacement: $1:$2 - 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 

注意我們這里在relabel_configs區域做了大量的配置，特別是第一個保留__meta_kubernetes_service_annotation_prometheus_io_scrape為true的才保留下來，這就是說要想自動發現集群中的 Service，就需要我們在 Service 的annotation區域添加prometheus.io/scrape=true的聲明，現在我們先將上面的配置更新，查看下效果：

service endpoints

我們可以看到kubernetes-service-endpoints這一個任務下面只發現了一個服務，這是因為我們在relabel_configs中過濾了 annotation 有prometheus.io/scrape=true的 Service，而現在我們系統中只有這樣一個服務符合要求，所以只出現了一個實例。

現在我們在之前創建的 redis 這個 Service 中添加上prometheus.io/scrape=true這個 annotation：(prome-redis-exporter.yaml)

kind: Service apiVersion: v1 metadata: name: redis namespace: kube-ops annotations: prometheus.io/scrape: "true" prometheus.io/port: "9121" spec: selector: app: redis ports: - name: redis port: 6379 targetPort: 6379 - name: prom port: 9121 targetPort: 9121 

由於 redis 服務的 metrics 接口在9121這個 redis-exporter 服務上面，所以我們還需要添加一個prometheus.io/port=9121這樣的annotations，然后更新這個 Service：

$ kubectl apply -f prome-redis-exporter.yaml
deployment.extensions "redis" unchanged service "redis" changed 

更新完成后，去 Prometheus 查看 Targets 路徑，可以看到 redis 服務自動出現在了kubernetes-service-endpoints這個任務下面：

kubernetes service endpoints

這樣以后我們有了新的服務，服務本身提供了/metrics接口，我們就完全不需要用靜態的方式去配置了，到這里我們就可以將之前配置的 redis 的靜態配置去掉了。

大家可以嘗試去將之前配置的 traefik 服務用動態發現的方式重新配置到上面的 service-endpoints 中。

同樣的，大家可以自己去嘗試下去配置下自動發現 Pod、ingress 這些資源對象。

kube-state-metrics

上面我們配置了自動發現 Service（Pod也是一樣的）的監控，但是這些監控數據都是應用內部的監控，需要應用本身提供一個/metrics接口，或者對應的 exporter 來暴露對應的指標數據，但是在 Kubernetes 集群上 Pod、DaemonSet、Deployment、Job、CronJob 等各種資源對象的狀態也需要監控，這也反映了使用這些資源部署的應用的狀態。但通過查看前面從集群中拉取的指標(這些指標主要來自 apiserver 和 kubelet 中集成的 cAdvisor)，並沒有具體的各種資源對象的狀態指標。對於 Prometheus 來說，當然是需要引入新的 exporter 來暴露這些指標，Kubernetes 提供了一個kube-state-metrics就是我們需要的。

kube-state-metrics 已經給出了在 Kubernetes 部署的 manifest 定義文件，我們直接將代碼 Clone 到集群中(能用 kubectl 工具操作就行):

$ git clone https://github.com/kubernetes/kube-state-metrics.git $ cd kube-state-metrics/kubernetes $ kubectl create -f . clusterrolebinding.rbac.authorization.k8s.io "kube-state-metrics" created clusterrole.rbac.authorization.k8s.io "kube-state-metrics" created deployment.apps "kube-state-metrics" created rolebinding.rbac.authorization.k8s.io "kube-state-metrics" created role.rbac.authorization.k8s.io "kube-state-metrics-resizer" created serviceaccount "kube-state-metrics" created service "kube-state-metrics" created 

將 kube-state-metrics 部署到 Kubernetes 上之后，就會發現 Kubernetes 集群中的 Prometheus 會在kubernetes-service-endpoints 這個 job 下自動服務發現 kube-state-metrics，並開始拉取 metrics，這是因為部署 kube-state-metrics 的 manifest 定義文件 kube-state-metrics-service.yaml 對 Service 的定義包含prometheus.io/scrape: 'true'這樣的一個annotation，因此 kube-state-metrics 的 endpoint 可以被 Prometheus 自動服務發現。

關於 kube-state-metrics 暴露的所有監控指標可以參考 kube-state-metrics 的文檔kube-state-metrics Documentation。