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。