Prometheus 持久化安装

我们prometheus采用nfs挂载方式来存储数据，同时使用configMap管理配置文件。并且我们将所有的prometheus存储在kube-system

#建议将所有的prometheus yaml文件存在一块
mkdir /opt/prometheus -p && cd /opt/prometheus

#生成配置文件

cat >> prometheus.configmap.yaml <<EOF
apiVersion: v1
kind: ConfigMap
metadata:
  name: prometheus-config
  namespace: kube-system
data:
  prometheus.yml: |
    global:
      scrape_interval: 15s
      scrape_timeout: 15s
    scrape_configs:
    - job_name: 'prometheus'
      static_configs:
      - targets: ['localhost:9090']
EOF

# 配置文件解释（这里的configmap实际上就是prometheus的配置）
上面包含了3个模块global、rule_files和scrape_configs

其中global模块控制Prometheus Server的全局配置
scrape_interval:表示prometheus抓取指标数据的频率，默认是15s，我们可以覆盖这个值
evaluation_interval:用来控制评估规则的频率，prometheus使用规则产生新的时间序列数据或者产生警报

rule_files模块制定了规则所在的位置，prometheus可以根据这个配置加载规则，用于生产新的时间序列数据或者报警信息，当前我们没有配置任何规则，后期会添加

scrape_configs用于控制prometheus监控哪些资源。由于prometheus通过http的方式来暴露它本身的监控数据，prometheus也能够监控本身的健康情况。在默认的配置有一个单独的job，叫做prometheus，它采集prometheus服务本身的时间序列数据。这个job包含了一个单独的、静态配置的目标；监听localhost上的9090端口。
prometheus默认会通过目标的/metrics路径采集metrics。所以，默认的job通过URL：http://localhost:9090/metrics采集metrics。收集到时间序列包含prometheus服务本身的状态和性能。如果我们还有其他的资源需要监控，可以直接配置在该模块下即可

然后创建该资源对象：

[root@k8s-01 prometheus]# kubectl apply -f prometheus.configmap.yaml
configmap/prometheus-config created

[root@k8s-01 prometheus]#  kubectl get configmaps -n kube-system |grep prometheus
prometheus-config                    1      163m

配置文件创建完成，如果以后我们有新的资源需要被监控，我们只需要将ConfigMap对象更新即可，现在我们开始创建prometheus的Pod资源

[root@k8s-01 prometheus]# cat > prometheus.deploy.yaml <<EOF
apiVersion: apps/v1
kind: Deployment
metadata:
  name: prometheus
  namespace: kube-system
  labels:
    app: prometheus
spec:
  selector:
    matchLabels:
      app: prometheus
  template:
    metadata:
      labels:
        app: prometheus
    spec:
      serviceAccountName: prometheus
      containers:
      - image: prom/prometheus:v2.4.3
        name: prometheus
        command:
        - "/bin/prometheus"
        args:
        - "--config.file=/etc/prometheus/prometheus.yml"
        - "--storage.tsdb.path=/prometheus"
        - "--storage.tsdb.retention=30d"
        - "--web.enable-admin-api"  # 控制对admin HTTP API的访问，其中包括删除时间序列等功能
        - "--web.enable-lifecycle"  # 支持热更新，直接执行localhost:9090/-/reload立即生效
        ports:
        - containerPort: 9090
          protocol: TCP
          name: http
        volumeMounts:
        - mountPath: "/prometheus"
          subPath: prometheus
          name: data
        - mountPath: "/etc/prometheus"
          name: config-volume
        resources:
          requests:
            cpu: 100m
            memory: 512Mi
          limits:
            cpu: 100m
            memory: 512Mi
      securityContext:
        runAsUser: 0
      volumes:
      - name: data
        persistentVolumeClaim:
          claimName: prometheus
      - configMap:
          name: prometheus-config
        name: config-volume



---
apiVersion: v1
kind: Service
metadata:
  namespace: kube-system
  name: prometheus
  labels:
    app: prometheus
spec:
  type: NodePort
  selector:
    app: prometheus
  ports:
  - name: http
    port: 9090

EOF

我们在启动程序的时候，除了指定prometheus.yaml(configmap)以外，还通过storage.tsdb.path指定了TSDB数据的存储路径、通过storage.tsdb.rentention设置了保留多长时间的数据，还有下面的web.enable-admin-api参数可以用来开启对admin api的访问权限，参数web.enable-lifecyle用来开启支持热更新，有了这个参数之后，prometheus.yaml(configmap)文件只要更新了，通过执行localhost:9090/-/reload就会立即生效

我们添加了一行securityContext，，其中runAsUser设置为0，这是因为prometheus运行过程中使用的用户是nobody，如果不配置可能会出现权限问题

NFS搭建步骤

for i in k8s-01 k8s-02 k8s-03;do ssh root@$i "yum install nfs-utils rpcbind -y";done
接着我们在任意一台机器上搭建nfs，其他的服务器主要是挂载

我这里使用192.168.0.200

NFS服务器操作如下
mkdir -p /home/kvm
systemctl start rpcbind
systemctl enable rpcbind
systemctl enable nfs
echo "/home/kvm  *(rw,no_root_squash,sync)" >>/etc/exports



其他k8s节点直接启动rpcbind并且挂载目录就可以
systemctl start rpcbind
systemctl enable rpcbind
mkdir /data/k8s -p
mount -t nfs 10.4.82.138:/home/kvm /data/k8s

prometheus.yaml文件对应的ConfigMap对象通过volume的形式挂载进Pod，这样ConfigMap更新后，对应的pod也会热更新，然后我们在执行上面的reload请求，prometheus配置就生效了。除此之外，对了将时间数据进行持久化，我们将数据目录和一个pvc对象进行了绑定，所以我们需要提前创建pvc对象

[root@k8s-01 prometheus]# cat >prometheus-volume.yaml <<EOF
apiVersion: v1
kind: PersistentVolume
metadata:
  name: prometheus
spec:
  capacity:
    storage: 10Gi
  accessModes:
  - ReadWriteOnce
  persistentVolumeReclaimPolicy: Recycle
  nfs:
    server: 192.168.0.200
    path: /home/kvm/k8s-vloume

---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: prometheus
  namespace: kube-system
spec:
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 10Gi

EOF

#nfs 
server nfs服务器ip
path  挂载点，提前挂在好，确保可以写入

这里通过一个简单的NFS作为存储后端创建一个pv & pvc

[root@k8s-01 prometheus]# kubectl create -f prometheus-volume.yaml
persistentvolume/prometheus created
persistentvolumeclaim/prometheus created

我们这里还需要创建rbac认证，因为prometheus需要访问k8s集群内部的资源

cat >>prometheus-rbac.yaml <<EOF
apiVersion: v1
kind: ServiceAccount
metadata:
  name: prometheus
  namespace: kube-system
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: prometheus
rules:
- apiGroups:
  - ""
  resources:
  - nodes
  - services
  - endpoints
  - pods
  - nodes/proxy
  verbs:
  - get
  - list
  - watch
- apiGroups:
  - ""
  resources:
  - configmaps
  - nodes/metrics
  verbs:
  - get
- nonResourceURLs:
  - /metrics
  verbs:
  - get
---
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRoleBinding
metadata:
  name: prometheus
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: prometheus
subjects:
- kind: ServiceAccount
  name: prometheus
  namespace: kube-system
EOF

由于我们要获取的资源，在每一个namespace下面都有可能存在，所以我们这里使用的是ClusterRole的资源对象，nonResourceURLs是用来对非资源型metrics进行操作的权限声明

创建rbac文件
[root@k8s-01 prometheus]# kubectl create -f prometheus-rbac.yaml
serviceaccount/prometheus created
clusterrole.rbac.authorization.k8s.io/prometheus created
clusterrolebinding.rbac.authorization.k8s.io/prometheus created

我们将ConfigMap volume rbac 创建完毕后，就可以创建prometheus.deploy.yaml了，运行prometheus服务

[root@k8s-01]# kubectl create -f prometheus.deploy.yaml
deployment.extensions/prometheus created

[root@k8s-01 prometheus]# kubectl get pod -n kube-system |grep prometheus
prometheus-847494df74-zbz9v      1/1     Running   0          148m


#这里1/1 状态为Running即可

现在我们prometheus服务状态是已经正常了，但是我们在浏览器是无法访问prometheus的 webui服务。那么我们还需要创建一个service

cat >>prometeheus-svc.yaml <<EOF
apiVersion: v1
kind: Service
metadata:
  namespace: kube-system
  name: prometheus
  labels:
    app: prometheus
spec:
  type: NodePort
  selector:
    app: prometheus
  ports:
  - name: http
    port: 9090

EOF

[root@k8s-01prometheus]# kubectl create -f prometeheus-svc.yaml
service/prometheus created

[root@k8s-01 prometheus]# kubectl get svc -n kube-system |grep prometheus
prometheus   NodePort    10.1.183.250   <none>        9090:30129/TCP           148m

这里定义的端口为3xxxx,我们直接在浏览器上任意节点输入ip+端口即可

我们可以查看一下当前监控规则

默认prometheus会监控自己

Status-->Targets

我们查看一下数据，是否收集到数据

Prometheus监控Kubernetes 集群节点及应用

对于Kubernetes的集群监控一般我们需要考虑一下几方面

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

监控方案

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

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

Kubelet/cAdvisor之外，我们还可以向Heapster添加其他指标源数据，比如kube-state-metrics

Heapster已经被废弃，使用metrics-server代替

cAvisor:cAdvisor是Google开源的容器资源监控和性能分析工具，它是专门为容器而生，本身也支持Docker容器，Kubernetes中，我们不需要单独去安装，cAdvisor作为kubelet内置的一部分程序可以直接使用
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之前还有很大不同的，二者主要区别如下

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

资源度量API

监控集群节点

首先需要我们监控集群的节点，要监控节点其实我们已经有很多非常成熟的方案了，比如Nagios、Zabbix，甚至可以我们自己收集数据，这里我们通过prometheus来采集节点的监控指标，可以通过node_exporter获取，node_exporter就是抓取用于采集服务器节点的各种运行指标，目前node_exporter几乎支持所有常见的监控点，比如cpu、distats、loadavg、meminfo、netstat等，详细的监控列表可以参考github repo

这里使用DeamonSet控制器来部署该服务，这样每一个节点都会运行一个Pod，如果我们从集群中删除或添加节点后，也会进行自动扩展

[root@k8s-01 prometheus]# cat >>prometheus-node-exporter.yaml<<EOF
apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: node-exporter
  namespace: kube-system
  labels:
    name: node-exporter
    k8s-app: node-exporter
spec:
  selector:
    matchLabels:
      name: node-exporter
  template:
    metadata:
      labels:
        name: node-exporter
        app: 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: /

EOF

创建node-exporter并检查pod

[root@k8s-01prometheus]# kubectl create -f prometheus-node-exporter.yaml
daemonset.extensions/node-exporter created


[root@k8s-01 prometheus]# kubectl get pod -n kube-system -o wide|grep node
node-exporter-bsdkl              1/1     Running   0          36m    192.168.122.217   k8s-02   <none>           <none>
node-exporter-f8wrt              1/1     Running   0          36m    192.168.122.2     k8s-01   <none>           <none>
node-exporter-gjhvz              1/1     Running   0          36m    192.168.122.165   k8s-03   <none>           <none>
 

#这里我们可以看到，我们有3个节点，在所有的节点上都启动了一个对应Pod进行获取数据

node-exporter.yaml文件说明

由于我们要获取的数据是主机的监控指标数据，而我们的node-exporter是运行在容器中的，所以我们在Pod中需要配置一些Pod的安全策略

hostPID:true
hostIPC:true
hostNetwork:true

#这三个配置主要用于主机的PID namespace、IPC namespace以及主机网络，这里需要注意的是namespace是用于容器隔离的关键技术，这里的namespace和集群中的namespace是两个完全不同的概念

另外我们还需要将主机/dev、/proc、/sys这些目录挂在到容器中，这些因为我们采集的很多节点数据都是通过这些文件来获取系统信息

比如我们在执行top命令可以查看当前cpu使用情况，数据就来源于/proc/stat，使用free命令可以查看当前内存使用情况，其数据来源是/proc/meminfo文件

另外如果是使用kubeadm搭建的，同时需要监控master节点的，则需要添加下方的相应容忍

      - key: "node-role.kubernetes.io/master"
        operator: "Exists"
        effect: "NoSchedule

node-exporter容器相关启动参数

        args:
        - --path.procfs     #配置挂载宿主机（node节点）的路径
        - /host/proc
        - --path.sysfs      #配置挂载宿主机（node节点）的路径
        - /host/sys
        - --collector.filesystem.ignored-mount-points
        - '"^/(sys|proc|dev|host|etc)($|/)"'

在我们的yaml文件中加入了hostNetwork:true会直接将我们的宿主机的9100端口映射出来，从而不需要创建service 在我们的宿主机上就会有一个9100的端口

容器的9100--->映射到宿主机9100

      hostNetwork: true
      containers:
      - name: node-exporter
        image: prom/node-exporter:v0.16.0
        ports:
        - containerPort: 9100

上面我们检查了Pod的运行状态都是正常的，接下来我们要查看一下Pod日志，以及node-exporter中的metrics

使用命令kubectl logs -n 命名空间 node-exporter中Pod名称检查Pod日志是否有额外报错

[root@k8s-01 prometheus]# kubectl logs -n kube-system node-exporter-
node-exporter-bsdkl  node-exporter-f8wrt  node-exporter-gjhvz  
[root@k8s-01 prometheus]# kubectl logs -n kube-system node-exporter-bsdkl 
time="2019-12-05T05:50:42Z" level=info msg="Starting node_exporter (version=0.16.0, branch=HEAD, revision=d42bd70f4363dced6b77d8fc311ea57b63387e4f)" source="node_exporter.go:82"
time="2019-12-05T05:50:42Z" level=info msg="Build context (go=go1.9.6, user=root@a67a9bc13a69, date=20180515-15:52:42)" source="node_exporter.go:83"
time="2019-12-05T05:50:42Z" level=info msg="Enabled collectors:" source="node_exporter.go:90"
time="2019-12-05T05:50:42Z" level=info msg=" - arp" source="node_exporter.go:97"
time="2019-12-05T05:50:42Z" level=info msg=" - bcache" source="node_exporter.go:97"
time="2019-12-05T05:50:42Z" level=info msg=" - bonding" source="node_exporter.go:97"
time="2019-12-05T05:50:42Z" level=info msg=" - conntrack" source="node_exporter.go:97"
time="2019-12-05T05:50:42Z" level=info msg=" - cpu" source="node_exporter.go:97"
time="2019-12-05T05:50:42Z" level=info msg=" - diskstats" source="node_exporter.go:97"
time="2019-12-05T05:50:42Z" level=info msg=" - edac" source="node_exporter.go:97"
time="2019-12-05T05:50:42Z" level=info msg=" - entropy" source="node_exporter.go:97"
time="2019-12-05T05:50:42Z" level=info msg=" - filefd" source="node_exporter.go:97"
time="2019-12-05T05:50:42Z" level=info msg=" - filesystem" source="node_exporter.go:97"
time="2019-12-05T05:50:42Z" level=info msg=" - hwmon" source="node_exporter.go:97"
time="2019-12-05T05:50:42Z" level=info msg=" - infiniband" source="node_exporter.go:97"
time="2019-12-05T05:50:42Z" level=info msg=" - ipvs" source="node_exporter.go:97"
time="2019-12-05T05:50:42Z" level=info msg=" - loadavg" source="node_exporter.go:97"
time="2019-12-05T05:50:42Z" level=info msg=" - mdadm" source="node_exporter.go:97"
time="2019-12-05T05:50:42Z" level=info msg=" - meminfo" source="node_exporter.go:97"
time="2019-12-05T05:50:42Z" level=info msg=" - netdev" source="node_exporter.go:97"
time="2019-12-05T05:50:42Z" level=info msg=" - netstat" source="node_exporter.go:97"
time="2019-12-05T05:50:42Z" level=info msg=" - nfs" source="node_exporter.go:97"
time="2019-12-05T05:50:42Z" level=info msg=" - nfsd" source="node_exporter.go:97"
time="2019-12-05T05:50:42Z" level=info msg=" - sockstat" source="node_exporter.go:97"
time="2019-12-05T05:50:42Z" level=info msg=" - stat" source="node_exporter.go:97"
time="2019-12-05T05:50:42Z" level=info msg=" - textfile" source="node_exporter.go:97"
time="2019-12-05T05:50:42Z" level=info msg=" - time" source="node_exporter.go:97"
time="2019-12-05T05:50:42Z" level=info msg=" - timex" source="node_exporter.go:97"
time="2019-12-05T05:50:42Z" level=info msg=" - uname" source="node_exporter.go:97"
time="2019-12-05T05:50:42Z" level=info msg=" - vmstat" source="node_exporter.go:97"
time="2019-12-05T05:50:42Z" level=info msg=" - wifi" source="node_exporter.go:97"
time="2019-12-05T05:50:42Z" level=info msg=" - xfs" source="node_exporter.go:97"
time="2019-12-05T05:50:42Z" level=info msg=" - zfs" source="node_exporter.go:97"
time="2019-12-05T05:50:42Z" level=info msg="Listening on :9100" source="node_exporter.go:111"

#接下来，我们在任意集群节点curl 9100/metrics

[root@k8s-01 prometheus]# curl 127.0.0.1:9100/metrics|head 
  % 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 go_gc_duration_seconds A summary of the GC invocation durations.
# TYPE go_gc_duration_seconds summary
go_gc_duration_seconds{quantile="0"} 0.000239179
go_gc_duration_seconds{quantile="0.25"} 0.000322674
go_gc_duration_seconds{quantile="0.5"} 0.000361148
go_gc_duration_seconds{quantile="0.75"} 0.000416324
go_gc_duration_seconds{quantile="1"} 0.000513074
go_gc_duration_seconds_sum 0.006654219
go_gc_duration_seconds_count 18
# HELP go_goroutines Number of goroutines that currently exist.
100 64669  100 64669    0     0  2235k      0 --:--:-- --:--:-- --:--:-- 2339k
curl: (23) Failed writing body (135 != 15652)

只要metrics可以获取到数据说明node-exporter没有问题

服务发现

我们这里三个节点都运行了node-exporter程序，如果我们通过一个Server来将数据收集在一起，用静态的方式配置到prometheus就会显示一条数据，我们得自己在指标中过滤每个节点的数据，配置比较麻烦。这里就采用服务发现

在Kubernetes下，Prometheus通过Kubernetes API基础，目前主要支持5种服务发现，分别是node、Server、Pod、Endpoints、Ingress

需要我们在Prometheus配置文件中，添加如下三行

    - job_name: 'kubernetes-node'
      kubernetes_sd_configs:
      - role: node

#通过制定Kubernetes_sd_config的模式为node，prometheus就会自动从Kubernetes中发现所有的node节点并作为当前job监控的目标实例，发现的节点/metrics接口是默认的kubelet的HTTP接口

接下来我们更新配置文件

[root@k8s-01 prometheus]# kubectl apply -f prometheus.configmap.yaml 
configmap/prometheus-config configured
[root@k8s-01 prometheus]# 
[root@k8s-01 prometheus]# 
[root@k8s-01 prometheus]# kubectl get svc -n kube-system |grep prometheus
prometheus   NodePort    10.1.183.250   <none>        9090:30129/TCP           169m
[root@k8s-01 prometheus]# 
[root@k8s-01 prometheus]# curl -X POST http://10.1.183.250:9090/-/reload
#热更新刷新配置（需要等待一小会）

接着访问我们的地址

http://192.168.122.217:30129/targets

这个端口要和service对上

现在我们可以看到已经获取到我们的Node节点的IP，但是由于metrics监听的端口是10250而并不是我们设置的9100，所以提示我们节点属于Down的状态

这里我们就需要使用Prometheus提供的relabel_configs中的replace能力了，relabel可以在Prometheus采集数据之前，通过Target实例的Metadata信息，动态重新写入Label的值。除此之外，我们还能根据Target实例的Metadata信息选择是否采集或者忽略该Target实例。这里使用__address__标签替换10250端口为9100

这里使用正则进行替换端口

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

接下来我们更新一下配置

curl的时候可以多更新几次，顺便等待一会

[root@k8s-01 prometheus]# kubectl apply -f prometheus.configmap.yaml 
configmap/prometheus-config configured
[root@k8s-01 prometheus]# curl -X POST http://10.1.183.250:9090/-/reload
[root@k8s-01 prometheus]# curl -X POST http://10.1.183.250:9090/-/reload
[root@k8s-01 prometheus]#

现在在状态就正常了

目前状态已经正常，但是还有一个问题就是我们的采集数据只显示了IP地址，对于我们监控分组分类不是很方便，这里可以通过labelmap这个属性来将Kubernetes的Label标签添加为Prometheus的指标标签

    - job_name: 'kubernetes-node'
      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标签中去。

[root@k8s-01 prometheus]# kubectl apply -f prometheus.configmap.yaml 
configmap/prometheus-config configured
[root@k8s-01 prometheus]# curl -X POST http://10.1.183.250:9090/-/reload
[root@k8s-01 prometheus]# curl -X POST http://10.1.183.250:9090/-/reload

实际上就是获取我们的标签

[root@k8s-01 ~]# kubectl get nodes --show-labels
NAME     STATUS   ROLES    AGE   VERSION   LABELS
k8s-01   Ready    master   30d   v1.16.0   beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,kubernetes.io/arch=amd64,kubernetes.io/hostname=k8s-01,kubernetes.io/os=linux,node-role.kubernetes.io/master=
k8s-02   Ready    <none>   30d   v1.16.0   beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,kubernetes.io/arch=amd64,kubernetes.io/hostname=k8s-02,kubernetes.io/os=linux
k8s-03   Ready    <none>   30d   v1.16.0   beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,kubernetes.io/arch=amd64,kubernetes.io/hostname=k8s-03,kubernetes.io/os=linux
[root@k8s-01 ~]#

对于Kubernetes_sd_configs下面可用的元标签如下

__meta_kubernetes_node_name: 节点对象的名称
_meta_kubernetes_node_label: 节点对象中的每个标签
_meta_kubernetes_node_annotation: 来自节点对象的每个注释

_meta_kubernetes_node_address: 每个节点地址类型的第一个地址(如果存在) 关于kubernetes_sd_configs更多信息可以查看官方文档: kubernetes_sd_config

#prometheus configmap 监控完整配置如下,可以直接拷贝
root@k8s-01 prometheus]# cat prometheus.configmap.yaml 
apiVersion: v1
kind: ConfigMap
metadata:
  name: prometheus-config
  namespace: kube-system
data:
  prometheus.yml: |
    global:
      scrape_interval: 15s
      scrape_timeout: 15s
    scrape_configs:
    - job_name: 'prometheus'
      static_configs:
      - targets: ['localhost:9090']
    
    - job_name: 'kubernetes-node'
      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_(.+)
      
    - 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: (.+)
        target_label: __metrics_path__
        replacement: /api/v1/nodes/${1}/proxy/metrics/cadvisor

我们还可以去Graph里面看一下数据