详解k8s原生的集群监控方案(Heapster+InfluxDB+Grafana) - kubernetes

一、浅析监控方案

heapster是一个监控计算、存储、网络等集群资源的工具，以k8s内置的cAdvisor做为数据源收集集群信息，并汇总出有价值的性能数据(Metrics)：cpu、内存、network、filesystem等，而后将这些数据输出到外部存储(backend)，如InfluxDB，最后再经过相应的UI界面进行可视化展现，如grafana。另外heapster的数据源和外部存储都是可插拔的，因此能够很灵活的组建出不少监控方案，如：Heapster+ElasticSearch+Kibana等等。 Heapster的总体架构图： javascript

二、部署

本篇咱们将实践 Heapster + InfluxDB + Grafana 的监控方案。使用官方提供的yml文件有一些小问题，请参考如下改动和说明：java

2.一、建立InfluxDB资源对象

apiVersion: apps/v1
kind: Deployment
metadata:
  name: monitoring-influxdb
  namespace: kube-system
spec:
  replicas: 1
  selector:
    matchLabels:
      task: monitoring
      k8s-app: influxdb
  template:
    metadata:
      labels:
        task: monitoring
        k8s-app: influxdb
    spec:
      containers:
      - name: influxdb
        image: k8s.gcr.io/heapster-influxdb-amd64:v1.3.3
        volumeMounts:
        - mountPath: /data
          name: influxdb-storage
      volumes:
      - name: influxdb-storage
        emptyDir: {}
---
apiVersion: v1
kind: Service
metadata:
  labels:
    task: monitoring
    kubernetes.io/cluster-service: 'true'
    kubernetes.io/name: monitoring-influxdb
  name: monitoring-influxdb
  namespace: kube-system
spec:
  type: NodePort
  ports:
  - nodePort: 31001
    port: 8086
    targetPort: 8086
  selector:
    k8s-app: influxdb

注意：这里咱们使用NotePort暴露monitoring-influxdb服务在主机的31001端口上，那么InfluxDB服务端的地址：http://[host-ip]:31001 ，记下这个地址，以便建立heapster和为grafana配置数据源时，能够直接使用。，node

2.一、建立Grafana资源对象

apiVersion: apps/v1
kind: Deployment
metadata:
  name: monitoring-grafana
  namespace: kube-system
spec:
  replicas: 1
  selector:
    matchLabels:
      task: monitoring
      k8s-app: grafana
  template:
    metadata:
      labels:
        task: monitoring
        k8s-app: grafana
    spec:
      containers:
      - name: grafana
        image: k8s.gcr.io/heapster-grafana-amd64:v4.4.3
        ports:
        - containerPort: 3000
          protocol: TCP
        volumeMounts:
        - mountPath: /etc/ssl/certs
          name: ca-certificates
          readOnly: true
        - mountPath: /var
          name: grafana-storage
        env:
        - name: INFLUXDB_HOST
          value: monitoring-influxdb
        - name: GF_SERVER_HTTP_PORT
          value: "3000"
          # The following env variables are required to make Grafana accessible via
          # the kubernetes api-server proxy. On production clusters, we recommend
          # removing these env variables, setup auth for grafana, and expose the grafana
          # service using a LoadBalancer or a public IP.
        - name: GF_AUTH_BASIC_ENABLED
          value: "false"
        - name: GF_AUTH_ANONYMOUS_ENABLED
          value: "true"
        - name: GF_AUTH_ANONYMOUS_ORG_ROLE
          value: Admin
        - name: GF_SERVER_ROOT_URL
          # If you're only using the API Server proxy, set this value instead:
          # value: /api/v1/namespaces/kube-system/services/monitoring-grafana/proxy
          value: /
      volumes:
      - name: ca-certificates
        hostPath:
          path: /etc/ssl/certs
      - name: grafana-storage
        emptyDir: {}
---
apiVersion: v1
kind: Service
metadata:
  labels:
    # For use as a Cluster add-on (https://github.com/kubernetes/kubernetes/tree/master/cluster/addons)
    # If you are NOT using this as an addon, you should comment out this line.
    kubernetes.io/cluster-service: 'true'
    kubernetes.io/name: monitoring-grafana
  name: monitoring-grafana
  namespace: kube-system
spec:
  # In a production setup, we recommend accessing Grafana through an external Loadbalancer
  # or through a public IP.
  # type: LoadBalancer
  # You could also use NodePort to expose the service at a randomly-generated port
  type: NodePort
  ports:
  - nodePort: 30108
    port: 80
    targetPort: 3000
  selector:
    k8s-app: grafana

虽然Heapster已经预先配置好了Grafana的Datasource和Dashboard，可是为了方便访问，这里咱们使用NotePort暴露monitoring-grafana服务在主机的30108上，那么Grafana服务端的地址：http://registry.wuling.com:30108 ，经过浏览器访问，为Grafana修改数据源，以下： 标红的地方，为上一步记录下的InfluxDB服务端的地址。git

2.二、建立Heapster资源对象

apiVersion: v1
kind: ServiceAccount
metadata:
  name: heapster
  namespace: kube-system
---
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: heapster
  namespace: kube-system
spec:
  replicas: 1
  selector:
    matchLabels:
      task: monitoring
      k8s-app: heapster
  template:
    metadata:
      labels:
        task: monitoring
        k8s-app: heapster
    spec:
      serviceAccountName: heapster
      containers:
      - name: heapster
        image: k8s.gcr.io/heapster-amd64:v1.4.2
        imagePullPolicy: IfNotPresent
        command:
        - /heapster
        - --source=kubernetes:https://kubernetes.default 
        - --sink=influxdb:http://150.109.39.33:31001  # 这里填写刚刚记录下的InfluxDB服务端的地址。
---
apiVersion: v1
kind: Service
metadata:
  labels:
    task: monitoring
    # For use as a Cluster add-on (https://github.com/kubernetes/kubernetes/tree/master/cluster/addons)
    # If you are NOT using this as an addon, you should comment out this line.
    kubernetes.io/cluster-service: 'true'
    kubernetes.io/name: Heapster
  name: heapster
  namespace: kube-system
spec:
  ports:
  - port: 80
    targetPort: 8082
  selector:
    k8s-app: heapster

--source 为heapster指定获取集群信息的数据源。参考：https://github.com/kubernetes/heapster/blob/master/docs/source-configuration.md --sink 为heaster指定后端存储，这里咱们使用InfluxDB，其余的，请参考：https://github.com/kubernetes/heapster/blob/master/docs/sink-owners.md 这里heapster留下了一个的坑，请继续往下看，当我部署完heapster，查看Heapster容器组的标准输出：不少人都觉得是https或者k8s配置的问题，因而去就慌忙的去配置InSecure http方式，致使坑愈来愈深，透明度愈来愈低，更是无从下手，我也是这样弄了好久，都较上劲了，此处省略一万字。。。，当这些路子都走遍了，再次品读下面的原文：才发现是权限的问题，heaster默认使用一个令牌(Token)与ApiServer进行认证，经过查看heapster.yml发现 serviceAccountName: heapster ，如今明白了吧，就是heaster没有权限，那么如何受权呢-----给heaster绑定一个有权限的角色就好了，以下：github

apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRoleBinding
metadata:
  name: heapster
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cluster-admin
subjects:
- kind: ServiceAccount
  name: heapster
  namespace: kube-system

当建立heapster资源的时候，直接把这段代码加上，就好了。数据库

三、从不一样维度查看应用程序性能指标

在k8s集群中，应用程序的性能指标，须要从不一样的维度(containers, pods, services, and whole clusters)进行统计。以便于使用户深刻了解他们的应用程序是如何执行的以及可能出现的应用程序瓶颈。后端

3.一、经过dashboard查看集群概况

整个监控方案部署成功后，从上图能够看到，在不一样粒度/维度下，dashboard上能够呈现对象的具体CPU和内存使用率。api

3.二、经过Grafana查看集群详情(cpu、memory、filesystem、network)

经过Grafana能够查看某个Node或Pod的全部资源使用率，包括集群节点、不一样NameSpace下的单个Pod等，一部分截图以下所示：从上面能够看到，Heapster无缝衔接Grafana，提供了完美的数据展现，很直观、友好。咱们也能够学习 Grafana 来自定制出更美观和知足特定业务需求的Dashboard。浏览器

四、总结

本篇咱们详解了k8s原生的监控方案，它主要监控的是pod和node，对于kubernetes其余组件(API Server、Scheduler、Controller Manager等)的监控显得力不从心，而prometheus(一套开源的监控&报警&时间序列数据库的组合)功能更全面，后面有时间会进行实战。监控是一个很是大的话题，监控的目的是为预警，预警的目的是为了指导系统自愈。只有把监控=》预警 =》自愈三个环节都完成了，实现自动对应用程序性能和故障管理，才算得上是一个真正意义的应用程序性能管理系统(APM)，因此这个系列会一直朝着这个目标努力下去，请你们继续关注。若是有什么好的想法，欢迎评论区交流。网络

延伸阅读

https://github.com/kubernetes/heapster

若是你以为本篇文章对您有帮助的话，感谢您的【推荐】。 若是你对 kubernets 感兴趣的话能够关注我，我会按期的在博客分享个人学习心得。