一、监控应用

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 中查看采集的目标数据： 5.3、配置监控 - 图1
可以看到我们刚刚添加的traefik这个任务已经出现了，然后同样的我们可以切换到 Graph 下面去，我们可以找到一些 Traefik 的指标数据，至于这些指标数据代表什么意义，一般情况下，我们可以去查看对应的/metrics接口，里面一般情况下都会有对应的注释。

1.2、用exporter监控应用

对于更多非自带metrics的应用，我们就需要用exporter来监控了。
常见的exporter地址为：https://prometheus.io/docs/instrumenting/exporters/
我们这里以监听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是Google开源的容器资源监控和性能分析工具，它是专门为容器而生，本身也支持 Docker 容器，在 Kubernetes 中，我们不需要单独去安装，cAdvisor 作为 kubelet 内置的一部分程序可以直接使用。
Kube-state-metrics：kube-state-metrics通过监听 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 的实现，比如 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 提供的relabelconfigs中的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//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就是我们需要的。
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”。