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


1、淺析監控方案

heapster是一個監控計算、存儲、網絡等集群資源的工具,以k8s內置的cAdvisor作為數據源收集集群信息,並匯總出有價值的性能數據(Metrics):cpu、內存、network、filesystem等,然后將這些數據輸出到外部存儲(backend),如InfluxDB,最后再通過相應的UI界面進行可視化展示,如grafana。 另外heapster的數據源和外部存儲都是可插拔的,所以可以很靈活的組建出很多監控方案,如:Heapster+ElasticSearch+Kibana等等。
Heapster的整體架構圖:

2、部署

本篇我們將實踐 Heapster + InfluxDB + Grafana 的監控方案。使用官方提供的yml文件有一些小問題,請參考以下改動和說明:

2.1、創建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配置數據源時,可以直接使用。

2.1、創建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已經預先配置好了GrafanaDatasourceDashboard,但是為了方便訪問,這里我們使用NotePort暴露monitoring-grafana服務在主機的30108上,那么Grafana服務端的地址:http://registry.wuling.com:30108 ,通過瀏覽器訪問,為Grafana修改數據源,如下:

標紅的地方,為上一步記錄下的InfluxDB服務端的地址。

2.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綁定一個有權限的角色就行了,如下:

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資源的時候,直接把這段代碼加上,就行了。

3、從不同維度查看應用程序性能指標

在k8s集群中,應用程序的性能指標,需要從不同的維度(containers, pods, services, and whole clusters)進行統計。以便於使用戶深入了解他們的應用程序是如何執行的以及可能出現的應用程序瓶頸。

3.1、通過dashboard查看集群概況





整個監控方案部署成功后,從上圖可以看到,在不同粒度/維度下,dashboard上可以呈現對象的具體CPU和內存使用率。

3.2、通過Grafana查看集群詳情(cpu、memory、filesystem、network)

通過Grafana可以查看某個Node或Pod的所有資源使用率,包括集群節點、不同NameSpace下的單個Pod等,一部分截圖如下所示:






從上面可以看到,Heapster無縫銜接Grafana,提供了完美的數據展示,很直觀、友好。我們也可以學習 Grafana 來自定制出更美觀和滿足特定業務需求的Dashboard

4、總結

本篇我們詳解了k8s原生的監控方案,它主要監控的是podnode,對於kubernetes其他組件(API ServerSchedulerController Manager等)的監控顯得力不從心,而prometheus(一套開源的監控&報警&時間序列數據庫的組合)功能更全面,后面有時間會進行實戰。監控是一個非常大的話題,監控的目的是為預警,預警的目的是為了指導系統自愈。只有把 監控=》預警 =》自愈 三個環節都完成了,實現自動對應用程序性能和故障管理,才算得上是一個真正意義的應用程序性能管理系統(APM),所以這個系列會一直朝着這個目標努力下去,請大家繼續關注。如果有什么好的想法,歡迎評論區交流。

延伸閱讀

https://github.com/kubernetes/heapster

如果你覺得本篇文章對您有幫助的話,感謝您的【推薦】
如果你對 kubernets 感興趣的話可以關注我,我會定期的在博客分享我的學習心得


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM