一、监控应用

1.1、自带 metrics

对于自带 metrics 的应用，直接开启它的 metrics，然后配置 Prometheus 的配置文件即可。

比如 traefik，它自带 metrics，我们只需要开启它：

[metrics]
  [metrics.prometheus]
    entryPoint = "traefik"
    buckets = [0.1, 0.3, 1.2, 5.0]

我们需要在 traefik.toml 的配置文件中添加上上面的配置信息，然后更新 ConfigMap 和 Pod 资源对象即可，Traefik Pod 运行后，我们可以看到我们的服务 IP：

$ kubectl get svc -n kube-system
NAME                      TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)                       AGE
......
traefik-ingress-service   NodePort    10.101.33.56     <none>        80:31692/TCP,8080:32115/TCP   63d

然后我们可以使用 curl 检查是否开启了 Prometheus 指标数据接口，或者通过 NodePort 访问也可以：

$ curl 10.101.33.56:8080/metrics
## HELP go_gc_duration_seconds A summary of the GC invocation durations.
## TYPE go_gc_duration_seconds summary
go_gc_duration_seconds{quantile="0"} 0.000121036
go_gc_duration_seconds{quantile="0.25"} 0.000210328
go_gc_duration_seconds{quantile="0.5"} 0.000279974
go_gc_duration_seconds{quantile="0.75"} 0.000420738
go_gc_duration_seconds{quantile="1"} 0.001191494
go_gc_duration_seconds_sum 0.004353914
go_gc_duration_seconds_count 12
## HELP go_goroutines Number of goroutines that currently exist.
## TYPE go_goroutines gauge
go_goroutines 63
......

从这里可以看到 Traefik 的监控数据接口已经开启成功了，然后我们就可以将这个/metrics 接口配置到 prometheus.yml 中去了，直接加到默认的 prometheus 这个 job 下面：(prome-cm.yaml)

apiVersion: v1
kind: ConfigMap
metadata:
  name: prometheus-config
  namespace: kube-ops
data:
  prometheus.yml: |
    global:
      scrape_interval: 30s
      scrape_timeout: 30s
    scrape_configs:
    - job_name: 'prometheus'
      static_configs:
        - targets: ['localhost:9090']
    - job_name: 'traefik'
      static_configs:
        - targets: ['traefik-ingress-service.kube-system.svc.cluster.local:8080']

当然，我们这里只是一个很简单的配置，scrape_configs 下面可以支持很多参数，例如：

• basic_auth 和 bearer_token：比如我们提供的/metrics接口需要 basic 认证的时候，通过传统的用户名/密码或者在请求的 header 中添加对应的 token 都可以支持
• kubernetes_sd_configs 或 consul_sd_configs：可以用来自动发现一些应用的监控数据

由于我们这里 Traefik 对应的 servicename 是traefik-ingress-service，并且在 kube-system 这个 namespace 下面，所以我们这里的targets的路径配置则需要使用FQDN的形式：traefik-ingress-service.kube-system.svc.cluster.local，当然如果你的 Traefik 和 Prometheus 都部署在同一个命名空间的话，则直接填 servicename:serviceport即可。然后我们重新更新这个 ConfigMap 资源对象：

$ kubectl delete -f prome-cm.yaml
configmap "prometheus-config" deleted
$ kubectl create -f prome-cm.yaml
configmap "prometheus-config" created

现在 Prometheus 的配置文件内容已经更改了，隔一会儿被挂载到 Pod 中的 prometheus.yml 文件也会更新，由于我们之前的 Prometheus 启动参数中添加了--web.enable-lifecycle参数，所以现在我们只需要执行一个 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                   3d
$ curl -X POST "http://10.102.74.90:9090/-/reload"

由于 ConfigMap 通过 Volume 的形式挂载到 Pod 中去的热更新需要一定的间隔时间才会生效，所以需要稍微等一小会儿。

reload 这个 url 是一个 POST 请求，所以这里我们通过 service 的 CLUSTER-IP:PORT 就可以访问到这个重载的接口，这个时候我们再去看 Prometheus 的 Dashboard 中查看采集的目标数据：

可以看到我们刚刚添加的traefik这个任务已经出现了，然后同样的我们可以切换到 Graph 下面去，我们可以找到一些 Traefik 的指标数据，至于这些指标数据代表什么意义，一般情况下，我们可以去查看对应的/metrics接口，里面一般情况下都会有对应的注释。

1.2、用 exporter 监控应用

对于更多非自带 metrics 的应用，我们就需要用 exporter 来监控了。

常见的 exporter 地址为：https://prometheus.io/docs/instrumenting/exporters/ (opens new window)

我们这里以监听 redis 为例，常用形式为以 sidecar 的形式与主程序部署在同一个 Pod 中。

redis-demo.yaml

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: redis
  namespace: kube-ops
spec:
  template:
    metadata:
      annotations:
        prometheus.io/scrape: "true"
        prometheus.io/port: "9121"
      labels:
        app: redis
    spec:
      containers:
        - name: redis
          image: redis:4
          resources:
            requests:
              cpu: 100m
              memory: 100Mi
          ports:
            - containerPort: 6379
        - name: redis-exporter
          image: oliver006/redis_exporter:latest
          resources:
            requests:
              cpu: 100m
              memory: 100Mi
          ports:
            - containerPort: 9121
---
kind: Service
apiVersion: v1
metadata:
  name: redis
  namespace: kube-ops
spec:
  selector:
    app: redis
  ports:
    - name: redis
      port: 6379
      targetPort: 6379
    - name: prom
      port: 9121
      targetPort: 9121

创建配置清单，然后查看是否有 metrics

## kubectl get svc -n kube-ops -o wide
NAME             TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)             AGE    SELECTOR
prometheus-svc   NodePort    10.68.254.74    <none>        9090:23050/TCP      136m   app=prometheus
redis            ClusterIP   10.68.119.210   <none>        6379/TCP,9121/TCP   64s    app=redis
[root@ecs-5704-0003 redis-exporter]## curl 10.68.119.210:9121/metrics
## HELP go_gc_duration_seconds A summary of the GC invocation durations.
## TYPE go_gc_duration_seconds summary
go_gc_duration_seconds{quantile="0"} 0
go_gc_duration_seconds{quantile="0.25"} 0
go_gc_duration_seconds{quantile="0.5"} 0
......

然后我们更新 prometheus 的 configmap 配置清单：

apiVersion: v1
kind: ConfigMap
metadata:
  name: prometheus-config
  namespace: kube-ops
data:
  prometheus.yaml: |
    global:
      scrape_interval: 15s
      scrape_timeout: 15s
    scrape_configs:
    - job_name: 'prometheus'
      static_configs:
      - targets: ['localhost:9090']
    - job_name: 'redis'
      static_configs:
      - targets: ['redis.kube-ops.svc.cluster.local:9121']

更新配置文件，重新加载：

## kubectl delete -f prom-configmap.yaml
configmap "prometheus-config" deleted
## kubectl create -f prom-configmap.yaml
configmap/prometheus-config created
## curl -X POST "http://10.68.254.74:9090/-/reload"

二、监控集群

2.1、监控的要点

• Kubernetes 节点的监控：比如节点的 cpu、load、disk、memory 等指标
• 内部系统组件的状态：比如 kube-scheduler、kube-controller-manager、kubedns/coredns 等组件的详细运行状态
• 编排级的 metrics：比如 Deployment 的状态、资源请求、调度和 API 延迟等数据指标

2.2、监控的方案

Kubernetes 集群的监控方案目前主要有以下几种方案：

• Heapster：Heapster 是一个集群范围的监控和数据聚合工具，以 Pod 的形式运行在集群中。

除了 Kubelet/cAdvisor 之外，我们还可以向 Heapster 添加其他指标源数据，比如 kube-state-metrics，我们会在下面和大家讲解的

需要注意的是 Heapster 已经被废弃了，后续版本中会使用 metrics-server 代替。

• cAdvisor：cAdvisor (opens new window)是Google开源的容器资源监控和性能分析工具，它是专门为容器而生，本身也支持 Docker 容器，在 Kubernetes 中，我们不需要单独去安装，cAdvisor 作为 kubelet 内置的一部分程序可以直接使用。
• Kube-state-metrics：kube-state-metrics (opens new window)通过监听 API Server 生成有关资源对象的状态指标，比如 Deployment、Node、Pod，需要注意的是 kube-state-metrics 只是简单提供一个 metrics 数据，并不会存储这些指标数据，所以我们可以使用 Prometheus 来抓取这些数据然后存储。
• metrics-server：metrics-server 也是一个集群范围内的资源数据聚合工具，是 Heapster 的替代品，同样的，metrics-server 也只是显示数据，并不提供数据存储服务。

不过 kube-state-metrics 和 metrics-server 之间还是有很大不同的，二者的主要区别如下：

• kube-state-metrics 主要关注的是业务相关的一些元数据，比如 Deployment、Pod、副本状态等
• metrics-server 主要关注的是资源度量 API (opens new window) 的实现，比如 CPU、文件描述符、内存、请求延时等指标。

2.3、监控实施

我们通过使用 node_exporter 来抓取节点的运行指标，并且通过部署 DaemoSet 来部署该服务，这样每个节点都会运行这个 Pod。

node-exporter.yaml

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: node-exporter
  namespace: kube-ops
  labels:
    name: node-exporter
spec:
  selector:
    matchLabels:
      name: node-exporter
  template:
    metadata:
      labels:
        name: node-exporter
    spec:
      hostPID: true
      hostIPC: true
      hostNetwork: true
      containers:
        - name: node-exporter
          image: prom/node-exporter:v0.16.0
          ports:
            - containerPort: 9100
          resources:
            requests:
              cpu: 0.15
          securityContext:
            privileged: true
          args:
            - --path.procfs
            - /host/proc
            - --path.sysfs
            - /host/sys
            - --collector.filesystem.ignored-mount-points
            - '"^/(sys|proc|dev|host|etc)($|/)"'
          volumeMounts:
            - name: dev
              mountPath: /host/dev
            - name: proc
              mountPath: /host/proc
            - name: sys
              mountPath: /host/sys
            - name: rootfs
              mountPath: /rootfs
      tolerations:
        - key: "node-role.kubernetes.io/master"
          operator: "Exists"
          effect: "NoSchedule"
      volumes:
        - name: proc
          hostPath:
            path: /proc
        - name: dev
          hostPath:
            path: /dev
        - name: sys
          hostPath:
            path: /sys
        - name: rootfs
          hostPath:
            path: /

由于我们要获取到的数据是主机的监控指标数据，而我们的 node-exporter 是运行在容器中的，所以我们在 Pod 中需要配置一些 Pod 的安全策略，这里我们就添加了 hostPID: true、hostIPC: true、hostNetwork: true3 个策略，用来使用主机的 PID namespace、IPC namespace 以及主机网络，这些 namespace 就是用于容器隔离的关键技术，要注意这里的 namespace 和集群中的 namespace 是两个完全不相同的概念。

另外我们还将主机的/dev、/proc、/sys 这些目录挂载到容器中，这些因为我们采集的很多节点数据都是通过这些文件夹下面的文件来获取到的，比如我们在使用 top 命令可以查看当前 cpu 使用情况，数据就来源于文件/proc/stat，使用 free 命令可以查看当前内存使用情况，其数据来源是来自/proc/meminfo 文件。

然后我们创建资源清单：

## kubectl apply -f node-exporter.yaml
daemonset.extensions/node-exporter created
## kubectl get pod -n kube-ops  -o wide
NAME                                 READY   STATUS    RESTARTS   AGE     IP            NODE          NOMINATED NODE   READINESS GATES
node-exporter-gvhd6                  1/1     Running   0          21s     172.16.0.52   172.16.0.52   <none>           <none>
node-exporter-l7wx9                  1/1     Running   0          21s     172.16.0.33   172.16.0.33   <none>           <none>

由于我们指定了 hostNerwork=True，所以会在每个节点上绑定 9100 端口，我们久可以直接通过如下命令来验证指标：

## curl 127.0.0.1:9100/metrics

2.4、服务发现

由于我们是以 DS 的方式运行，所以如果我们用一个 Service 并且以静态配置文件的方式配置 Prometheus，那么就只会展示一条数据，所以我们就要用到 Prometheus 的服务发现。

在 kubernetes 中，Prometheus 通过与 kubernetes API 集成，目前支持 5 中服务发现：

• Node
• Service
• Endpoints
• Pod
• Ingress

在这里我们是要获取所有节点的监控指标，所以就要用到 node 的服务发现模式，我们只需要在 Prometheus 的 configMap 中配置如下 Job 即可：

- job_name: "kubernetes-nodes"
  kubernetes_sd_configs:
    - role: node

通过指定 kubernetes_sd_configs 为 node，Prometheus 就会自动发现 kubernetes 中的所有 Node 节点并作为当前 Job 的监控实例，发现节点的/mrtrics 接口默认就是 kubelet 的 HTTP 端口。

然后我们更新 configmap 并 reload：

## kubectl apply -f prom-configmap.yaml
configmap/prometheus-config created
## curl -X POST "http://10.68.254.74:9090/-/reload"

我们可以看到上面的 kubernetes-nodes 这个 job 任务已经自动发现了我们 3 个 node 节点，但是在获取数据的时候失败了，出现了类似于下面的错误信息：

Get http://10.151.30.57:10250/metrics: net/http: HTTP/1.x transport connection broken: malformed HTTP response "\x15\x03\x01\x00\x02\x02"

这个是因为 prometheus 去发现 Node 模式的服务的时候，访问的端口默认是 10250，而现在该端口下面已经没有了/metrics 指标数据了，现在 kubelet 只读的数据接口统一通过 10255 端口进行暴露了，所以我们应该去替换掉这里的端口，但是我们是要替换成 10255 端口吗？不是的，因为我们是要去配置上面通过 node-exporter 抓取到的节点指标数据，而我们上面是不是指定了 hostNetwork=true，所以在每个节点上就会绑定一个端口 9100，所以我们应该将这里的 10250 替换成 9100。

这里我们就需要使用到 Prometheus 提供的 relabel_configs 中的 replace 能力了，relabel 可以在 Prometheus 采集数据之前，通过 Target 实例的 Metadata 信息，动态重新写入 Label 的值。除此之外，我们还能根据 Target 实例的 Metadata 信息选择是否采集或者忽略该 Target 实例。比如我们这里就可以去匹配address这个 Label 标签，然后替换掉其中的端口：

- job_name: "kubernetes-nodes"
  kubernetes_sd_configs:
    - role: node
  relabel_configs:
    - source_labels: [__address__]
      regex: "(.*):10250"
      replacement: "${1}:9100"
      taget_label: __address__
      action: replace

然后我们再重载 configmap 并 reload：

## kubectl apply -f prom-configmap.yaml
## curl -X POST "http://10.68.254.74:9090/-/reload"

如果我们希望将 Node 上面的 label 标签都获取到，我们就需要用到 labelmap 这个属性，下面我们修改 configmap:

- job_name: "kubernetes-nodes"
  kubernetes_sd_configs:
    - role: node
  relabel_configs:
    - source_labels: [__address__]
      regex: "(.*):10250"
      replacement: "${1}:9100"
      target_label: __address__
      action: replace
    - action: labelmap
      regex: __meta_kubernetes_node_label_(.+)

添加了一个 action 为 labelmap，正则表达式是_meta_kubernetes_node_label(.+)的配置，这里的意思就是表达式中匹配都的数据也添加到指标数据的 Label 标签中去。

对于 kubernetes_sd_configs 下面可用的标签如下： 可用元标签：

• __meta_kubernetes_node_name：节点对象的名称
• __meta_kubernetes_node_label：节点对象中的每个标签
• __meta_kubernetes_node_annotation：来自节点对象的每个注释
• __meta_kubernetes_node_address：每个节点地址类型的第一个地址（如果存在） *

然后我们重载 configmap 并 reload：

## kubectl apply -f prom-configmap.yaml
## curl -X POST "http://10.68.254.74:9090/-/reload"

2.5、监控 kubelet

由于 kubelet 也自带了一些监控指标数据，就上面我们提到的 10255 端口，所以我们这里也把 kubelet 的监控任务也一并配置上，我们修改 configmap 文件：

（1）、1.11 版本以前，用下面这个配置

- job_name: "kubernetes-kubelet"
      kubernetes_sd_configs:
      - role: node
      relabel_configs:
      - sources_labels: [__address__]
        regex: '(.*):10250'
        replacement: '${1}:10255'
        target_label: __address__
        action: replace
      - action: labelmap
        regex: __meta_kubernetes_node_label_(.+)

重载 configmap 并 reload:

## kubectl apply -f prom-configmap.yaml
## curl -X POST "http://10.68.254.74:9090/-/reload"

（2）、1.11 版本以后用一下配置（因为在 1.11+之后，kubelet 就移除了 10255 端口， metrics 接口又回到了 10250 端口中，所以这里不需要替换端口，但是需要使用 https 的协议。）：

- job_name: "kubernetes-kubelet"
  kubernetes_sd_configs:
    - role: node
  scheme: https
  tls_config:
    ca_file: /var/run/secrets/kubernetes.io/serviceaccount/ca.crt
    insecure_skip_verify: true
  bearer_token_file: /var/run/secrets/kubernetes.io/serviceaccount/token
  relabel_configs:
    - action: labelmap
      regex: __meta_kubernetes_node_label_(.+)

重载 configmap 并 reload:

## kubectl apply -f prom-configmap.yaml
## curl -X POST "http://10.68.254.74:9090/-/reload"

三、监控资源对象

3.1、容器监控

容器监控我们会用 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: "(.+)"
      replacement: /api/v1/nodes/${1}/proxy/metrics/cadvisor
      target_label: __metrics_path__

ca 和 token 这两个文件是在 pod 启动的时候自动注入的，有了这两个文件，我们就可以在 Pod 中访问 apiserver，比如我们这里的address不在是 nodeip 了，而是 kubernetes 在集群中的服务地址，然后加上metrics_path的访问路径：/api/v1/nodes/${1}/proxy/metrics/cadvisor，就可以获得到 cAdvisor 的指标了。

然后我们再重载 configmap 并 reload：

## kubectl apply -f prom-configmap.yaml
## curl -X POST "http://10.68.254.74:9090/-/reload"

然后我们可以看到数据如下：

可以使用 promQL 去掉一些多余的 Pod，如下：

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

然后成图如下：

其统计的是在 1 分钟内 CPU 的使用情况。

3.2、系统组件监控

3.2.1、apiserver 监控

apiserver 是 kubernetes 中最核心的主键，对其的监控是非常有必要的。对其的监控我们可以通过 kubernetes 的 service 来获取。其 configmap 中的配置文件如下：

- job_name: "kubernetes-apiserver"
  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

这里我们依然用到了 relabel_configs，但是我们这里的 action 并不是 replace，而是 keep，这是因为 endpoints 的服务有很多，许多都不是我们想要的，我们这里只需要将想要的元数据保留下来，我们这里只需要 default 命令空间下，服务名为 kubernetes 的元数据。

然后我们再重载 configmap 并 reload：

## kubectl apply -f prom-configmap.yaml
## curl -X POST "http://10.68.254.74:9090/-/reload"

然后我们就可以在 Grafa 下面查看图形，比如我们这里查看 apiserver 请求的总数：

sum(rate(apiserver_request_count[1m]))

3.2.2、scheduler 监控

思路：

1、配置 Service

2、配置 configmap，keep 想要的元数据

3.2.3、controller-manager 监控

3.3、Service 监控

上面的系统组件监控，其实也用到了 service，这里的 service 监控主要针对的是普通的 service。

配置 configmap 如下：

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

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

重新 apply 一下这个配置文件，然后就可以看到这个服务已经监控。

3.4、kube-state-metrics

上面我们配置了自动发现 Service（Pod 也是一样的）的监控，但是这些监控数据都是应用内部的监控，需要应用本身提供一个/metrics 接口，或者对应的 exporter 来暴露对应的指标数据，但是在 Kubernetes 集群上 Pod、DaemonSet、Deployment、Job、CronJob 等各种资源对象的状态也需要监控，这也反映了使用这些资源部署的应用的状态。但通过查看前面从集群中拉取的指标(这些指标主要来自 apiserver 和 kubelet 中集成的 cAdvisor)，并没有具体的各种资源对象的状态指标。对于 Prometheus 来说，当然是需要引入新的 exporter 来暴露这些指标，Kubernetes 提供了一个kube-state-metrics (opens new window)就是我们需要的。

kube-state-metrics 已经给出了在 Kubernetes 部署的 manifest 定义文件，我们直接将代码 Clone 到集群中(能用 kubectl 工具操作就行):

## git clone https://github.com/kubernetes/kube-state-metrics.git
## cd kube-state-metrics/examples/autosharding

更改 service：

apiVersion: v1
kind: Service
metadata:
  labels:
    app.kubernetes.io/name: kube-state-metrics
    app.kubernetes.io/version: v1.8.0
  name: kube-state-metrics
  namespace: kube-system
  annotations:
    prometheus.io/scrape: "true"
spec:
  clusterIP: None
  ports:
    - name: http-metrics
      port: 8080
      targetPort: http-metrics
    - name: telemetry
      port: 8081
      targetPort: telemetry
  selector:
    app.kubernetes.io/name: kube-state-metrics

然后启动配置清单：

## kubectl apply -f .
clusterrolebinding.rbac.authorization.k8s.io/kube-state-metrics created
clusterrole.rbac.authorization.k8s.io/kube-state-metrics created
rolebinding.rbac.authorization.k8s.io/kube-state-metrics created
role.rbac.authorization.k8s.io/kube-state-metrics created
serviceaccount/kube-state-metrics created
service/kube-state-metrics created
statefulset.apps/kube-state-metrics created

将 kube-state-metrics 部署到 Kubernetes 上之后，就会发现 Kubernetes 集群中的 Prometheus 会在 kubernetes-service-endpoints 这个 job 下自动服务发现 kube-state-metrics，因为我们在 service.yaml 文件中加了 prometheus.io/scrape: "true"。