容器監控實踐 kube state metrics

已經有了cadvisor、heapster、metric-server，幾乎容器執行的所有指標都能拿到，但是下面這種情況卻無能為力：

而這些則是kube-state-metrics提供的內容，它基於client-go開發，輪詢kubernetes api，並將kubernetes的結構化資訊轉換為metrics。

kube-state-metrics提供的指標，按照階段分為三種類別：

指標類別包括：

以pod為例：

部署清單：

kube-state-metrics/ ├── kube-state-metrics-cluster-role-binding.yaml ├── kube-state-metrics-cluster-role.yaml ├── kube-state-metrics-deployment.yaml ├── kube-state-metrics-role-binding.yaml ├── kube-state-metrics-role.yaml ├── kube-state-metrics-service-account.yaml ├── kube-state-metrics-service.yaml

主要映象有：

image: quay.io/coreos/kube-state-metrics:v1.5.0

image: k8s.gcr.io/addon-resizer:1.8.3（參考metric-server文章，用於擴縮容）

對於pod的資源限制，一般情況下：

`200mib memory

0.1 cores`

超過100節點的集群：

`2mib memory per node

0.001 cores per node`

kube-state-metrics做過一次效能優化，具體內容參考下文

部署成功後，prometheus的target會出現如下標誌

因為kube-state-metrics-service.yaml中有prometheus.io/scrape: 'true'標識，因此會將metric暴露給prometheus，而prometheus會在kubernetes-service-endpoints這個job下自動發現kube-state-metrics，並開始拉取metrics，無需其他配置。

使用kube-state-metrics後的常用場景有：

集群節點狀態錯誤: kube_node_status_condition==1

集群中存在啟動失敗的pod：kube_pod_status_phase==1

最近30分鐘內有pod容器重啟: changes(kube_pod_container_status_restarts[30m])>0

配合報警可以更好地監控集群的執行

kube-state-metrics本質上是不斷輪詢api-server，**結構也很簡單

主要**目錄

. ├── collectors │ ├── builder.go │ ├── collectors.go │ ├── configmap.go │ ...... │ ├── testutils.go │ ├── testutils_test.go │ └── utils.go ├── constant │ └── resource_unit.go ├── metrics │ ├── metrics.go │ └── metrics_test.go ├── metrics_store │ ├── metrics_store.go │ └── metrics_store_test.go ├── options │ ├── collector.go │ ├── options.go │ ├── options_test.go │ ├── types.go │ └── types_test.go ├── version │ └── version.go └── whiteblacklist ├── whiteblacklist.go └── whiteblacklist_test.go

所有型別：

var (
defaultnamespaces = namespacelist
defaultcollectors = collectorset{},
"deployments": struct{}{},
"limitranges": struct{}{},
"nodes": struct{}{},
"pods": struct{}{},
"poddisruptionbudgets": struct{}{},
"replicasets": struct{}{},
"replicationcontrollers": struct{}{},
"resourcequotas": struct{}{},
"services": struct{}{},
"jobs": struct{}{},
"cronjobs": struct{}{},
"statefulsets": struct{}{},
"persistentvolumes": struct{}{},
"persistentvolumeclaims": struct{}{},
"namespaces": struct{}{},
"horizontalpodautoscalers": struct{}{},
"endpoints": struct{}{},
"secrets": struct{}{},
"configmaps": struct{}{},})

構建對應的收集器

family即乙個型別的資源集合，如job下的kube_job_info、kube_job_created，都是乙個familygenerator例項

metrics.familygenerator}
}),},

func (b *builder) buildcronjobcollector() *collector , store, b.namespaces, createcronjoblistwatch)
return newcollector(store)
}

效能優化：

kube-state-metrics在之前的版本中暴露出兩個問題：

問題一的方案就是基於client-go的cache tool實現本地快取，具體結構為：

`var cache = map[uuid]byte{}

`問題二的的方案是：對於時間序列的字串，是存在很多重複字元的（如namespace等字首篩選），可以用指標或者結構化這些重複字元。

本文為容器監控實踐系列文章，完整內容見：container-monitor-book

容器監控實踐 kube state metrics

容器監控實踐 Heapster

容器監控實踐 kube state metrics

容器監控實踐 Prometheus概述

容器監控實踐 kube state metrics

容器監控實踐 Heapster

容器監控實踐 kube state metrics

容器監控實踐 Prometheus概述

相關推薦