Kubernetes Kube-state-metrics

有很多种方法可以监控Kubernetes本身，其中包括开源Kubernetes生态系统中的工具，如Heapster和Kube-state-metrics，以及其他商业化和基于SaaS的工具。我们将重点关注如何使用Kube-state-metrics来进行监控。[1] https://github.com/kubernetes-retired/heapster。[2] https://github.

富士康质检员张全蛋

5061人浏览 · 2021-02-07 10:31:27

富士康质检员张全蛋 · 2021-02-07 10:31:27 发布

之前我们配置了自动发现 Endpoints 的监控，但是这些监控数据都是应用内部的监控，需要应用本身提供一个 /metrics 接口，或者对应的 exporter 来暴露对应的指标数据，但是在 Kubernetes 集群上 Pod、DaemonSet、Deployment、Job、CronJob 等各种资源对象的状态也需要监控，这也反映了使用这些资源部署的应用的状态。比如：

我调度了多少个副本？现在可用的有几个？
多少个 Pod 是 running/stopped/terminated 状态？
Pod 重启了多少次？
我有多少 job 在运行中等等

通过查看前面从集群中拉取的指标(这些指标主要来自 apiserver 和 kubelet 中集成的 cAdvisor)，并没有具体的各种资源对象的状态指标。对于 Prometheus 来说，当然是需要引入新的 exporter 来暴露这些指标，Kubernetes 提供了一个kube-state-metrics 就是我们需要的。kube-state-metrics 关注于获取 Kubernetes 各种资源的最新状态，如 deployment 或者 daemonset。

要安装 kube-state-metrics 非常简单，直接将代码 Clone 到集群中(能用 kubectl 工具操作就行)，不过需要注意兼容的版本：

☸ ➜ git clone https://github.com/kubernetes/kube-state-metrics.git
☸ ➜ cd kube-state-metrics/examples/standard

默认的镜像为 gcr 的，这里我们可以将 deployment.yaml 下面的镜像替换成 cnych/kube-state-metrics:v2.3.0，此外我们上面为 Prometheus 配置了 Endpoints 的自动发现，所以我们可以给 kube-state-metrics 的 Service 配置上对应的 annotations 来自动被发现，然后直接创建即可：

☸ ➜ cat service.yaml
apiVersion: v1
kind: Service
metadata:
  labels:
    app.kubernetes.io/component: exporter
    app.kubernetes.io/name: kube-state-metrics
    app.kubernetes.io/version: 2.3.0
  name: kube-state-metrics
  namespace: kube-system
  annotations:
    prometheus.io/scrape: "true"
    prometheus.io/port: "8080" # 8081是kube-state-metrics应用本身指标的端口
......
☸ ➜ kubectl apply -f https://p8s.io/docs/k8s/manifests/prometheus/kube-state-metrics

部署完成后正常就可以被 Prometheus 采集到指标了：

当然如果你也想监控 kube-state-metrics 本身的相关指标，则需要单独配置使用 8081 端口作为指标的端口了。

使用 kube-state-metrics 的一些典型场景：

存在执行失败的 Job: kube_job_status_failed
集群节点状态错误: 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_total[30m])>0

kube-state-metrics与metrics-server对比

我们服务在运行过程中，我们想了解服务运行状态，pod有没有重启，伸缩有没有成功，pod的状态是怎么样的等，这时就需要kube-state-metrics，它主要关注deployment,、node 、 pod等内部对象的状态。而metrics-server 主要用于监测node，pod等的CPU，内存，网络等系统指标。

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的运行状态。

概述

已经有了cadvisor、heapster、metric-server，几乎容器运行的所有指标都能拿到，但是下面这种情况却无能为力：

我调度了多少个replicas？现在可用的有几个？
多少个Pod是running/stopped/terminated状态？
Pod重启了多少次？
我有多少job在运行中

而这些则是kube-state-metrics提供的内容，它基于client-go开发，轮询Kubernetes API，并将Kubernetes的结构化信息转换为metrics。

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提供的指标，按照阶段分为三种类别：

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
...

数据抓取

我们可以通过endpoints服务发现方式去发现kube-state-metrics暴露的数据抓取地址

 - job_name: 'kubernetes-service-endpoints'
      scrape_timeout: 30s      
      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
      - source_labels: [__meta_kubernetes_pod_container_port_number]
        action: replace
        target_label: container_port

# 在service中配置被prometheus抓取
metadata:
  annotations:
    prometheus.io/scrape: 'true'

我们可以通过endpoints服务发现方式去发现kube-state-metrics暴露的数据抓取地址

[root@k8s-master ~]# kubectl get pod -n ops -o wide
NAME                                  READY   STATUS    RESTARTS   AGE     IP            NODE         NOMINATED NODE   READINESS GATES
kube-state-metrics-6867944674-cl8x8   2/2     Running   0          3m30s   10.244.0.15   k8s-master   <none>           <none>


[root@k8s-master ~]# curl 10.244.0.15:8080/metrics | head -n 10
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0# HELP kube_certificatesigningrequest_labels Kubernetes labels converted to Prometheus labels.
# TYPE kube_certificatesigningrequest_labels gauge
# HELP kube_certificatesigningrequest_created Unix creation timestamp
# TYPE kube_certificatesigningrequest_created gauge
# HELP kube_certificatesigningrequest_condition The number of each certificatesigningrequest condition
# TYPE kube_certificatesigningrequest_condition gauge
# HELP kube_certificatesigningrequest_cert_length Length of the issued cert
# TYPE kube_certificatesigningrequest_cert_length gauge
# HELP kube_configmap_info Information about configmap.

因为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

配合报警可以更好地监控集群的运行

Kube-state-metrics

我们将在Kubernetes集群上使用部署和服务来安装Kube-state-metrics。部署使用Docker镜像Kube-state-metrics，并在集群的一个节点上运行。服务在端口8080上暴露指标，由于它是一项服务，因此我们可以创建的Prometheus服务作业。当作业运行时，Prometheus将自动发现

新的服务端点并开始抓取 Kube-state-metrics 。一旦添加了服务，我们将在 http://prometheus.quicknuke.com:9090/targets 列表内的 kubernetes-service-

endpoints 作业中看到一个新目标（如图 12-2 所示）。