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- prometheus]# kubectl apply -f prometheus.configmap.yaml
configmap/prometheus-config created

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

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

[root@k8s- 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:/-/reload立即生效
        ports:
        - containerPort:
          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:
      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:
 
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- k8s- k8s-;do ssh root@$i "yum install nfs-utils rpcbind -y";done
接着我们在任意一台机器上搭建nfs，其他的服务器主要是挂载
 
我这里使用192.168.0.
 
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- 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- 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-]# kubectl create -f prometheus.deploy.yaml
deployment.extensions/prometheus created
 
[root@k8s- prometheus]# kubectl get pod -n kube-system |grep prometheus

prometheus-847494df74-zbz9v      /     Running             148m
这里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: 
 
EOF

[root@k8s-01prometheus]# kubectl create -f prometeheus-svc.yaml
service/prometheus created
 
[root@k8s- prometheus]# kubectl get svc -n kube-system |grep prometheus

prometheus   NodePort    10.1.183.250   <none>        :/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- 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:
        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- prometheus]# kubectl get pod -n kube-system -o wide|grep node

node-exporter-bsdkl              /     Running             36m    192.168.122.217   k8s-   <none>           <none>

node-exporter-f8wrt              /     Running             36m    192.168.122.2     k8s-   <none>           <none>

node-exporter-gjhvz              /     Running             36m    192.168.122.165   k8s-   <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- prometheus]# kubectl logs -n kube-system node-exporter-
node-exporter-bsdkl  node-exporter-f8wrt  node-exporter-gjhvz
[root@k8s- 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- prometheus]# curl 127.0.0.1:/metrics|head
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
                                      --:--:-- --:--:-- --:--:--     # HELP go_gc_duration_seconds A summary of the GC invocation durations.
# TYPE go_gc_duration_seconds summary
go_gc_duration_seconds{quantile=""} 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=""} 0.000513074
go_gc_duration_seconds_sum 0.006654219
go_gc_duration_seconds_count
# HELP go_goroutines Number of goroutines that currently exist.
               2235k       --:--:-- --:--:-- --:--:-- 2339k
curl: () Failed writing body ( != )

只要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- prometheus]# kubectl apply -f prometheus.configmap.yaml
configmap/prometheus-config configured
[root@k8s- prometheus]#
[root@k8s- prometheus]#
[root@k8s- prometheus]# kubectl get svc -n kube-system |grep prometheus
prometheus   NodePort    10.1.183.250   <none>        :/TCP           169m
[root@k8s- prometheus]#
[root@k8s- 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- prometheus]# kubectl apply -f prometheus.configmap.yaml
configmap/prometheus-config configured
[root@k8s- prometheus]# curl -X POST http://10.1.183.250:9090/-/reload
[root@k8s- prometheus]# curl -X POST http://10.1.183.250:9090/-/reload
[root@k8s- 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- prometheus]# kubectl apply -f prometheus.configmap.yaml
configmap/prometheus-config configured
[root@k8s- prometheus]# curl -X POST http://10.1.183.250:9090/-/reload
[root@k8s- prometheus]# curl -X POST http://10.1.183.250:9090/-/reload

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

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

对于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- 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']
</span>- job_name: <span style="color: #800000;">'</span><span style="color: #800000;">kubernetes-node</span><span style="color: #800000;">'</span><span style="color: #000000;">
  kubernetes_sd_configs:
  </span>-<span style="color: #000000;"> role: node
  relabel_configs:
  </span>-<span style="color: #000000;"> source_labels: [__address__]
    regex: </span><span style="color: #800000;">'</span><span style="color: #800000;">(.*):10250</span><span style="color: #800000;">'</span><span style="color: #000000;">
    replacement: </span><span style="color: #800000;">'</span><span style="color: #800000;">${1}:9100</span><span style="color: #800000;">'</span><span style="color: #000000;">
    target_label: __address__
    action: replace
  </span>-<span style="color: #000000;"> action: labelmap
    regex: __meta_kubernetes_node_label_(.</span>+<span style="color: #000000;">)
</span>- job_name: <span style="color: #800000;">'</span><span style="color: #800000;">kubernetes-cadvisor</span><span style="color: #800000;">'</span><span style="color: #000000;">
  kubernetes_sd_configs:
  </span>-<span style="color: #000000;"> role: node
  scheme: https
  tls_config:
    ca_file: </span>/var/run/secrets/kubernetes.io/serviceaccount/<span style="color: #000000;">ca.crt
  bearer_token_file: </span>/var/run/secrets/kubernetes.io/serviceaccount/<span style="color: #000000;">token
  relabel_configs:
  </span>-<span style="color: #000000;"> action: labelmap
    regex: __meta_kubernetes_node_label_(.</span>+<span style="color: #000000;">)
  </span>-<span style="color: #000000;"> target_label: __address__
    replacement: kubernetes.default.svc:</span><span style="color: #800080;">443</span>
  -<span style="color: #000000;"> source_labels: [__meta_kubernetes_node_name]
    regex: (.</span>+<span style="color: #000000;">)
    target_label: __metrics_path__
    replacement: </span>/api/v1/nodes/${<span style="color: #800080;">1</span>}/proxy/metrics/cadvisor  </pre>

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

我们这里也可以自定义规则

容器监控

cAdvisor是一个容器资源监控工具，包括容器的内存，CPU，网络IO，资源IO等资源，同时提供了一个Web页面用于查看容器的实时运行状态。

cAvisor已经内置在了kubelet组件之中，所以我们不需要单独去安装，cAdvisor的数据路径为/api/v1/nodes//proxy/metrics

action 使用labelkeep或者labeldrop则可以对Target标签进行过滤，仅保留符合过滤条件的标签

    - 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:
      - source_labels: [__meta_kubernetes_node_name]
        regex: (.+)
        target_label: __metrics_path__
        replacement: /api/v1/nodes/${}/proxy/metrics/cadvisor

ls_config配置的证书地址是每个Pod连接apiserver所使用的地址，基本上写死了。并且我们在配置文件添加了一个labelmap标签。在最下面使用了一个正则替换了cAdvisor的一个metrics地址

证书是我们Pod启动的时候kubelet给pod注入的一个证书，所有的pod启动的时候都会有一个ca证书注入进来

如要想要访问apiserver的信息，还需要配置一个token_file

修改完成之后，我们需要configmap并且使用curl进行热更新(过程比较慢，需要等待会)

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

现在我们可以到Graph路径下面查询容器的相关数据

这里演示查询集群中所有Pod的CPU使用情况，查询指标container_cpu_usage_seconds_total并且查询1分钟之内的数据

这里演示一下使用函数rate和不使用函数的一个过滤功能

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

执行下方命令，过滤1分钟内的数据

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

还可以使用sum函数,pod在1分钟内的使用率，同时将pod名称打印出来

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

Api-Service 监控

apiserver作为Kubernetes最核心的组件，它的监控也是非常有必要的，对于apiserver的监控，我们可以直接通过kubernetes的service来获取

[root@k8s- prometheus]# kubectl get svc --all-namespaces
NAMESPACE              NAME                        TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)                  AGE
default                kubernetes                  ClusterIP   10.1.0.1       <none>        /TCP                  31d
ingress-nginx          ingress-nginx               ClusterIP   10.1.216.99    <none>        /TCP,/TCP           24h
kube-system            kube-dns                    ClusterIP   10.1.0.10      <none>        /UDP,/TCP,/TCP   30d
kube-system            kubelet                     ClusterIP   None           <none>        /TCP                25h
kube-system            prometheus                  NodePort    10.1.183.250   <none>        :/TCP           4h38m
kubernetes-dashboard   dashboard-metrics-scraper   ClusterIP   10.1.100.76    <none>        /TCP                 30d
kubernetes-dashboard   kubernetes-dashboard        NodePort    10.1.158.92    <none>        :/TCP            30d

上面的service是我们集群的apiserver内部的service的地址，要自动发现service类型的服务，需要使用role为Endpoints的kubernetes_sd_configs (自动发现)，我们只需要在configmap里面在添加Endpoints类型的服务发现

   - job_name: 'kubernetes-apiserver'
     kubernetes_sd_configs:
     - role: endpoints

刷新配置文件

[root@k8s- prometheus]# kubectl get svc -n kube-system
NAME         TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)                  AGE
kube-dns     ClusterIP   10.1.0.10      <none>        /UDP,/TCP,/TCP   30d
kubelet      ClusterIP   None           <none>        /TCP                25h
prometheus   NodePort    10.1.183.250   <none>        :/TCP           4h43m
[root@k8s- prometheus]# kubectl apply -f prometheus.configmap.yaml
configmap/prometheus-config configured
[root@k8s- prometheus]# curl -X POST http://10.1.183.250:9090/-/reload
[root@k8s- prometheus]# curl -X POST http://10.1.183.250:9090/-/reload
[root@k8s- prometheus]#

更新完成后，我们可以看到kubernetes-apiserver下面出现了很多实例，这是因为我们这里使用的Endpoints类型的服务发现，所以prometheus把所有的Endpoints服务都抓取过来了，同样的我们要监控的kubernetes也在列表中。

这里我们使用keep动作，将符合配置的保留下来，例如我们过滤default命名空间下服务名称为kubernetes的元数据，这里可以根据__meta_kubernetes_namespace和__mate_kubertnetes_service_name2个元数据进行relabel

    - job_name: kubernetes-apiservers
      kubernetes_sd_configs:
      - role: endpoints
      relabel_configs:
      - action: keep
        regex: default;kubernetes;https
        source_labels:
        - __meta_kubernetes_namespace
        - __meta_kubernetes_service_name
        - __meta_kubernetes_endpoint_port_name
      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

#参数解释
action: keep  #保留哪些标签
regex: default;kubernetes;https  #匹配namespace下的default命名空间下的kubernetes service 最后https协议
可以通过`kubectl describe svc kubernetes`查看到

刷新配置

#这个过程比较慢，可能要等几分钟,可以多reload几次

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

接下来我们还是前往Greph上查看采集到的数据

sum(rate(apiserver_request_count[1m]))
这里使用的promql里面的rate和sun函数，意思是apiserver在1分钟内请求的数

如果我们要监控其他系统组件，比如kube-controller-manager、kube-scheduler的话就需要单独手动创建service，因为apiserver服务默认在default，而其他组件在kube-steam这个namespace下。其中kube-sheduler的指标数据端口为10251，kube-controller-manager对应端口为10252

Service 监控

apiserver实际上是一种特殊的Service，现在配置一个专门发现普通类型的Service

这里我们对service进行过滤，只有在service配置了prometheus.io/scrape: "true"过滤出来

    - 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: $:$
      - 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

继续重复步骤，刷新配置

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

Serivce自动发现参数说明（并不是所有创建的service都可以被prometheus发现）

#.参数解释
relabel_configs:
-source_labels:[__meta_kubernetes_service_annotation_prometheus_io_scrape]
action: keep
regex: true  保留标签
source_labels: [__meta_kubernetes_service_annotation_prometheus_io_cheme]
 
这行配置代表我们只去筛选有__meta_kubernetes_service_annotation_prometheus_io_scrape的service，只有添加了这个声明才可以自动发现其他service
.参数解释
 
- source_labels: [address, __meta_kubernetes_service_annotation_prometheus_io_port]

action: replace

target_label: address

regex: ([^:]+)(?::\d+)?												
											Kubernetes1.16下部署Prometheus+node-exporter+Grafana+AlertManager 监控系统的更多相关文章
	
								Prometheus + Node Exporter + Grafana 监控主机运行信息
		  上一篇文章中讲了如何利用Prometheus和Grafana监控SpringBoot应用的JVM信息,这次就来看看如何监控 服务器运行状态,先列出用到的工具: Prometheus node_ex ...
		
						【开源监控】Prometheus+Node Exporter+Grafana监控linux服务器
		Prometheus Prometheus介绍 Prometheus新一代开源监控解决方案.github地址 Prometheus主要功能 多维 数据模型(时序由 metric 名字和 k/v 的 l ...
		
						在Kubernetes下部署Prometheus
		使用ConfigMaps管理应用配置 当使用Deployment管理和部署应用程序时,用户可以方便了对应用进行扩容或者缩容,从而产生多个Pod实例.为了 能够统一管理这些Pod的配置信息,在Kuber ...
		
						Prometheus+Grafana企业监控系统
		Prometheus+Grafana企业监控系统 作者 刘畅 实验配置: 主机名称 Ip地址 controlnode 172.16.1.70/24 slavenode1 172.16.1.71/24  ...
		
						kubernetes1.11.1 部署prometheus
		部署前提:已经安装好了kubernetes的集群,版本是1.11.1,是用kubeadm部署的. 2台虚拟机:master:172.17.1.36      node1:172.17.1.40 pro ...
		
						Prometheus+Grafana搭建监控系统
		之前在业务中遇到服务器负载过高问题,由于没有监控,一直没发现,直到业务方反馈网站打开速度慢,才发现问题.这样显得开发很被动.所以是时候搭建一套监控系统了. 由于是业余时间自己捯饬,所以神马业务层面的监 ...
		
						docker-compose 快速部署Prometheus之服务端并监控ceph  cluster  使用钉钉webhook 报警
		现在环境是这样: ceph 4台: 192.168.100.21  ceph-node1 192.168.100.22  ceph-node2 192.168.100.23  ceph-node3 1 ...
		
						kubernetes1.15极速部署prometheus和grafana
		关于prometheus和grafana prometheus负责监控数据采集,grafana负责展示,下图来自官网: 环境信息 硬件:三台CentOS 7.7服务器 kubernetes:1.15  ...
		
						CentOS 7.3 下部署基于 Node.js的微信小程序商城
		本文档为微信小程序商城NideShop项目的安装部署教程,欢迎star NideShop商城api服务:https://github.com/tumobi/nideshop NideShop微信小程序 ...
		
		
	
 
随机推荐
	
									菜鸟系列Fabric源码学习—创建通道
			通道创建源码解析 1. 与通道创建相关配置及操作命令 主要是configtx.yaml.通过应用通道的profile生成创建通道的配置文件. TwoOrgsChannel: Consortium: S ...
			
						sql数据库的基础语句
			1, 创建数据库 create database database-name 2, 删除数据库 drop database dbname 3, 备份sql server 创建 备份数据的device  ...
			
						将mysql中一行中的几个字段 转换成一列并从其他数据库中查对应的邮件信息
			--将项目中的总监,经理,等的邮箱合并为一行 SELECT GROUP_CONCAT(t.USER_EMAIL SEPARATOR ' ') mail_address FROM portal.t_ac ...
			
						Kubernetes---Pod重启策略
			PodSpec中有一个restartPolicy 字段,可能的值为Always.OnFailure和Never.默认为Always.restartPolicy 适用于Pod 中的所有容器.restar ...
			
						MySQL 聚合函数（四）检测功能依赖
			源自MySQL 5.7 官方手册:12.20.4 Detection of Functional Dependence 本节提供了MySQL检测功能依赖的方式的几个示例.这些示例使用此表示法: {X} ...
			
						oracle练手（一）
			练手001 1.列出至少有一个员工的所有部门 select dname from dept where deptno in (select deptno from emp); select dname ...
			
						怎样获取响应头: Response Header
			1. 使用 xhr.getResponseHeader()可以获取指定响应头字段值. function getHeaderTime() { console.log(this.getResponseHe ...
			
						Myatis中的OGNL和bind标签的结合用法
			1.MyBatis常用的OGNL e1 or e2 e1 and e2 e1 == e2,e1 eq e2 e1 != e2,e1 neq e2 e1 lt e2:小于 e1 lte e2:小于等于, ...
			
						sql server 数据库中明明有值但是查询怎么都查不到值
			产生原因是因为编码问题 数据库是英文版  但是数据库中数据又是中文的 所以查询中文时需要加上N select * from customer where Username=N'张三'
			
						Angular 变更检测
			angular 的钩子函数有 content 和 view , Docheck 子控件中有属性变化的时候,父组件的 Docheck  content   view  这3个会依次执行,即使这个属性不在 ...

Kubernetes1.16下部署Prometheus+node-exporter+Grafana+AlertManager 监控系统

Prometheus 持久化安装

生成配置文件

配置文件解释（这里的configmap实际上就是prometheus的配置）

nfs

这里1/ 状态为Running即可

Prometheus监控Kubernetes 集群节点及应用

监控方案

监控集群节点

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

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

服务发现

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

容器监控

Api-Service 监控

这里使用的promql里面的rate和sun函数，意思是apiserver在1分钟内请求的数

Service 监控

.参数解释

Kubernetes1.16下部署Prometheus+node-exporter+Grafana+AlertManager 监控系统的更多相关文章

随机推荐

热门专题