摘要：功能提供的指標，按照階段分為三種類別實驗性質的中階段的或者的字段。穩定版本的中不向后兼容的主要版本的更新被廢棄的已經不在維護的。通過比較來保證的順序并不保證包含所有資源本文為容器監控實踐系列文章，完整內容見

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

我調度了多少個replicas？現在可用的有幾個？

多少個Pod是running/stopped/terminated狀態？

Pod重啟了多少次？

我有多少job在運行中

而這些則是kube-state-metrics提供的內容，它基于client-go開發，輪詢Kubernetes API，并將Kubernetes的結構化信息轉換為metrics。

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

1.實驗性質的：k8s api中alpha階段的或者spec的字段。

2.穩定版本的：k8s中不向后兼容的主要版本的更新

3.被廢棄的：已經不在維護的。

指標類別包括：

CronJob Metrics

DaemonSet Metrics

Deployment Metrics

Job Metrics

LimitRange Metrics

Node Metrics

PersistentVolume Metrics

PersistentVolumeClaim Metrics

Pod Metrics

Pod Disruption Budget Metrics

ReplicaSet Metrics

ReplicationController Metrics

ResourceQuota Metrics

Service Metrics

StatefulSet Metrics

Namespace Metrics

Horizontal Pod Autoscaler Metrics

Endpoint Metrics

Secret Metrics

ConfigMap Metrics

以pod為例：

kube_pod_info

kube_pod_owner

kube_pod_status_phase

kube_pod_status_ready

kube_pod_status_scheduled

kube_pod_container_status_waiting

kube_pod_container_status_terminated_reason

...

部署清單：

 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后的常用場景有：

存在執行失敗的Job: kube_job_status_failed{job="kubernetes-service-endpoints",k8s_app="kube-state-metrics"}==1

集群節點狀態錯誤: kube_node_status_condition{condition="Ready",status!="true"}==1

集群中存在啟動失敗的Pod：kube_pod_status_phase{phase=~"Failed|Unknown"}==1

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

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

metric-server（或heapster）是從api-server中獲取cpu、內存使用率這種監控指標，并把他們發送給存儲后端，如influxdb或云廠商，他當前的核心作用是：為HPA等組件提供決策指標支持。

kube-state-metrics關注于獲取k8s各種資源的最新狀態，如deployment或者daemonset，之所以沒有把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的運行狀態。

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{metav1.NamespaceAll}
    DefaultCollectors = CollectorSet{
        "daemonsets":               struct{}{},
        "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{
            Name: "kube_job_info",
            Type: metrics.MetricTypeGauge,
            Help: "Information about job.",
            GenerateFunc: wrapJobFunc(func(j *v1batch.Job) metrics.Family {
                return metrics.Family{&metrics.Metric{
                    Name:  "kube_job_info",
                    Value: 1,
                }}
            }),
        },

func (b *Builder) buildCronJobCollector() *Collector {
   // 過濾傳入的白名單
    filteredMetricFamilies := filterMetricFamilies(b.whiteBlackList, cronJobMetricFamilies)
    composedMetricGenFuncs := composeMetricGenFuncs(filteredMetricFamilies)
  // 將參數寫到header中
    familyHeaders := extractMetricFamilyHeaders(filteredMetricFamilies)
  // NewMetricsStore實現了client-go的cache.Store接口，實現本地緩存。
    store := metricsstore.NewMetricsStore(
        familyHeaders,
        composedMetricGenFuncs,
    )
  // 按namespace構建Reflector，監聽變化
    reflectorPerNamespace(b.ctx, b.kubeClient, &batchv1beta1.CronJob{}, store, b.namespaces, createCronJobListWatch)

    return NewCollector(store)
}

性能優化：

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

/metrics接口響應慢(10-20s)

內存消耗太大，導致超出limit被殺掉

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

`var cache = map[uuid][]byte{}
`

問題二的的方案是：對于時間序列的字符串，是存在很多重復字符的（如namespace等前綴篩選），可以用指針或者結構化這些重復字符。

1.因為kube-state-metrics是監聽資源的add、delete、update事件，那么在kube-state-metrics部署之前已經運行的資源，豈不是拿不到數據？kube-state-metric利用client-go可以初始化所有已經存在的資源對象，確保沒有任何遺漏

2.kube-state-metrics當前不會輸出metadata信息(如help和description）

3.緩存實現是基于golang的map，解決并發讀問題當期是用了一個簡單的互斥鎖，應該可以解決問題，后續會考慮golang的sync.Map安全map。

4.kube-state-metrics通過比較resource version來保證event的順序

5.kube-state-metrics并不保證包含所有資源

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