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

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的形式运行在集群中

kubernetes_monitoring_heapster.png-19.1kB

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

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

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

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

修改完成之后，我们需要configmap并且使用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

现在我们可以到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-01 prometheus]# kubectl get svc --all-namespaces 
NAMESPACE              NAME                        TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)                  AGE
default                kubernetes                  ClusterIP   10.1.0.1       <none>        443/TCP                  31d
ingress-nginx          ingress-nginx               ClusterIP   10.1.216.99    <none>        80/TCP,443/TCP           24h
kube-system            kube-dns                    ClusterIP   10.1.0.10      <none>        53/UDP,53/TCP,9153/TCP   30d
kube-system            kubelet                     ClusterIP   None           <none>        10250/TCP                25h
kube-system            prometheus                  NodePort    10.1.183.250   <none>        9090:30129/TCP           4h38m
kubernetes-dashboard   dashboard-metrics-scraper   ClusterIP   10.1.100.76    <none>        8000/TCP                 30d
kubernetes-dashboard   kubernetes-dashboard        NodePort    10.1.158.92    <none>        443:30001/TCP            30d

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

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

刷新配置文件

[root@k8s-01 prometheus]# kubectl get svc -n kube-system 
NAME         TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)                  AGE
kube-dns     ClusterIP   10.1.0.10      <none>        53/UDP,53/TCP,9153/TCP   30d
kubelet      ClusterIP   None           <none>        10250/TCP                25h
prometheus   NodePort    10.1.183.250   <none>        9090:30129/TCP           4h43m
[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]#

更新完成后，我们可以看到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-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]# curl -X POST http://10.1.183.250:9090/-/reload
[root@k8s-01 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: $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

继续重复步骤，刷新配置

[root@k8s-01 prometheus]# 
[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]#

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

#1.参数解释
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
2.参数解释
- source_labels: [address, __meta_kubernetes_service_annotation_prometheus_io_port]

action: replace

target_label: address

regex: ([^:]+)(?::\d+)?😭\d+)

replacement: $1😒2
指定一个抓取的端口，有的service可能有多个端口（比如之前的redis）。默认使用的是我们添加是使用kubernetes_service端口
3.参数解释
- source_labels: [__meta_kubernetes_service_annotation_prometheus_io_scheme]

action: replace

target_label: scheme

regex: (https?)
这里如果是https证书类型，我们还需要在添加证书和token

我们可以看到这里的服务的core DNS,为什么那么多service只有coreDNS可以被收集到呢？

上面也说了，我们有过滤条件，只有复合条件的才进行过滤

core DNS serviceYaml 文件包含true参数，所以会被匹配到

继续重复步骤，刷新配置

[root@k8s-01 prometheus]# 
[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]# curl -X POST http://10.1.183.250:9090/-/reload
[root@k8s-01 prometheus]#

当我们再次查看，发现状态完成

Grafana是一个跨平台的开源的度量分析和可视化工具，可以通过将采集的数据查询然后可视化的展示，并及时通知。

Grafana 安装并监控k8s集群

由于Prometheus自带的web Ui图标功能相对较弱，所以一般情况下我们会使用一个第三方的工具来展示这些数据

Grafana介绍

grafana 是一个可视化面包，有着非常漂亮的图片和布局展示，功能齐全的度量仪表盘和图形化编辑器，支持Graphite、Zabbix、InfluxDB、Prometheus、OpenTSDB、Elasticasearch等作为数据源，比Prometheus自带的图标展示功能强大很多，更加灵活，有丰富的插件

我们这里使用deployment持久化安装grafana

cat >>grafana_deployment.yaml <<EOF
apiVersion: apps/v1
kind: Deployment
metadata:
  name: grafana
  namespace: kube-system
  labels:
    app: grafana
    k8s-app: grafana
spec:
  selector:
    matchLabels:
      k8s-app: grafana
      app: grafana
  revisionHistoryLimit: 10
  template:
    metadata:
      labels:
        app: grafana
        k8s-app: grafana
    spec:
      containers:
      - name: grafana
        image: grafana/grafana:5.3.4
        imagePullPolicy: IfNotPresent
        ports:
        - containerPort: 3000
          name: grafana
        env:
        - name: GF_SECURITY_ADMIN_USER
          value: admin
        - name: GF_SECURITY_ADMIN_PASSWORD
          value: jiangwenhui
        readinessProbe:
          failureThreshold: 10
          httpGet:
            path: /api/health
            port: 3000
            scheme: HTTP
          initialDelaySeconds: 60
          periodSeconds: 10
          successThreshold: 1
          timeoutSeconds: 30
        livenessProbe:
          failureThreshold: 3
          httpGet:
            path: /api/health
            port: 3000
            scheme: HTTP
          periodSeconds: 10
          successThreshold: 1
          timeoutSeconds: 1
        resources:
          limits:
            cpu: 300m
            memory: 1024Mi
          requests:
            cpu: 300m
            memory: 1024Mi
        volumeMounts:
        - mountPath: /var/lib/grafana
          subPath: grafana
          name: storage
      securityContext:
        fsGroup: 472
        runAsUser: 472
      volumes:
      - name: storage
        persistentVolumeClaim:
          claimName: grafana
EOF

这里使用了grafana 5.3.4的镜像，添加了监控检查、资源声明，比较重要的变量是GF_SECURITY_ADMIN_USER和GF_SECURITY_ADMIN_PASSWORD为grafana的账号和密码。

由于grafana将dashboard、插件这些数据保留在/var/lib/grafana目录下，所以我们这里需要做持久化，同时要针对这个目录做挂载声明，由于5.3.4版本用户的userid和groupid都有所变化，所以这里添加了一个securityContext设置用户ID

image_1ddnv749l17k7ucdel1m4v17jjea.png-56.5kB

现在我们添加一个pv和pvc用于绑定grafana

cat >>grafana_volume.yaml <<EOF
apiVersion: v1
kind: PersistentVolume
metadata:
  name: grafana
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: grafana
  namespace: kube-system
spec:
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 10Gi
EOF

这里配置依旧使用NFS进行挂载使用

现在我们还需要创建一个service，使用NodePort

cat >>grafana_svc.yaml<<EOF
apiVersion: v1
kind: Service
metadata:
  name: grafana
  namespace: kube-system
  labels:
    app: grafana
spec:
  type: NodePort
  ports:
    - port: 3000
  selector:
    app: grafana
EOF

由于5.1(可以选择5.1之前的docker镜像，可以避免此类错误)版本后groupid更改，同时我们将/var/lib/grafana挂载到pvc后，目录拥有者可能不是grafana用户，所以我们还需要添加一个Job用于授权目录

cat > grafana_job.yaml <<EOF
apiVersion: batch/v1
kind: Job
metadata:
  name: grafana-chown
  namespace: kube-system
spec:
  template:
    spec:
      restartPolicy: Never
      containers:
      - name: grafana-chown
        command: ["chown", "-R", "472:472", "/var/lib/grafana"]
        image: busybox
        imagePullPolicy: IfNotPresent
        volumeMounts:
        - name: storage
          subPath: grafana
          mountPath: /var/lib/grafana
      volumes:
      - name: storage
        persistentVolumeClaim:
          claimName: grafana
EOF

这里使用一个busybox镜像将/var/lib/grafana目录修改为权限472

#需要先创建pv和pvc  (这里是需要安装顺序来创建)
[root@k8s-01 prometheus]# kubectl create -f grafana_volume.yaml
persistentvolume/grafana created
persistentvolumeclaim/grafana created
[root@k8s-01 prometheus]# kubectl create -f grafana_job.yaml
job.batch/grafana-chown created
[root@k8s-01 prometheus]# kubectl apply -f grafana_deployment.yaml
deployment.apps/grafana created
[root@k8s-01 prometheus]# kubectl create -f grafana_svc.yaml

创建完成后我们打开grafana的dashboard界面

[root@k8s-01 prometheus]# 
[root@k8s-01 prometheus]# kubectl get pod,svc -n kube-system |grep grafana
pod/grafana-59bd6c446d-4jjnf         1/1     Running     0          7m39s
pod/grafana-chown-w562v              0/1     Completed   0          14m
service/grafana      NodePort    10.1.63.182    <none>        3000:30636/TCP           13m
[root@k8s-01 prometheus]#

然后我们在任意集群中的节点访问端口为30636

这里的集群密码就是上面我们创建deployment里面设置的变量，我这里用户设置为admin密码jiangwenhui

登陆到grafana就显示到了我们的引导界面

第一次创建grafana需要添加数据源

类型选择prometheus

这里的地址我们填写下面的url

http://prometheus.kube-system.svc.cluster.local:9090

这里的prometheus代表service名称

kube-system代表命名空间

数据源添加完毕后，接下来添加New dashboard

这里我们可以自定义模板，或者可以使用别人写好的模板（写好的模板后面是需要我们自己修改的）

grafana提供了很多模板，类似和docker镜像仓库一下。导入模板也极其简单。点击上方的Dashboard

这里面的模板都是公共的，可以免费使用

点进去任意一个模板后，我们可以看到ID，复制ID然后在返回grafana

我这里添加一个监控Kubernetes集群。显示整体群集CPU、内存、磁盘使用情况以及单个pod统计信息。

https://grafana.com/grafana/dashboards/8588

点击导入模板

在这里我们输入8588或者url，会自动跳转到配置页面

https://grafana.com/grafana/dashboards/8588

选择好数据源之后，我们在点击Import即可

这里就会将模板8588给我们导入进行

这里就会获取我们prometheus里面的数据了

现在的模板还没有进行保存，我们要点击保存一下

现在就保存下来了

目前我们导入模板之后是无法直接使用滴

这里无法显示是由于模板定义的标签，我们prometheus并没有这个数据元，所以说我们要对模板进行修改！

在修改之前我们先设置一下时区，grafana默认走的是浏览器时区，但是prometheus使用的是UTC时区

修改默认模板 (我这里使用的是8588模板，下面模板修改请根据我的操作步骤进行操作)

grafana模板修改

前面的步骤必须和我相同，否则这里可能会无法出现值

首先我们进行编辑 Cluster memory usage (集群内存使用率)

计算方式就是(整个集群的内存-(整个集群剩余的内存以及Buffer和Cached))/整

(sum(node_memory_MemTotal_bytes) - sum(node_memory_MemFree_bytes + node_memory_Buffers_bytes+node_memory_Cached_bytes)) / sum(node_memory_MemTotal_bytes) * 100

这里要说明一点，这里填写的是PromSQL，也就是说是可以在prometheus查询到的。如果查询不到grafana也是会获取不到数据的

这里在prometheus是可以获取到的

Cluster memory usage 配置如下 (集群内存使用率)

sum(sum by (container_name)( rate(container_cpu_usage_seconds_total{image!=""}[1m] ) )) / count(node_cpu_seconds_total{mode="system"}) * 100

Cluster filesystem usage 集群文件系统使用率

(sum(node_filesystem_size_bytes{device="tmpfs"}) - sum(node_filesystem_free_bytes{device="tmpfs"}) ) / sum(node_filesystem_size_bytes{device="tmpfs"}) * 100

这里我们就获取到数据了

接下来我们配置集群中Pod cpu使用率

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

下面显示的地方配置

{{ pod }}

集群pod 内存使用率

sort_desc(sum (container_memory_usage_bytes{image!=" ", pod_name!=" "}) by(pod))

下面显示的名称同样也是{{ pod }}

最后我们配置一下Pod 网络监控

1.入口流量
sort_desc(sum by (pod) (rate (container_network_receive_bytes_total{name!=""}[1m]) ))
2.出口流量

sort_desc(sum by (pod) (rate (container_network_transmit_bytes_total{name!=""}[1m]) ))
监控时间为1分钟

效果图如下 记得点击保存

所有的PromSQL都是可以在prometheus获取到数据的！

posted @ 2019-12-11 18:41 哥$ 阅读(859) 评论(0) 编辑收藏举报

会员力量，点亮园子希望

刷新页面返回顶部

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

Prometheus 持久化安装

生成配置文件

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

nfs

这里1/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 监控

2.参数解释

指定一个抓取的端口，有的service可能有多个端口（比如之前的redis）。默认使用的是我们添加是使用kubernetes_service端口

3.参数解释

这里如果是https证书类型，我们还需要在添加证书和token

Grafana 安装并监控k8s集群

监控时间为1分钟

公告