我們prometheus采用nfs掛載方式來存儲數據，同時使用configMap管理配置文件。並且我們將所有的prometheus存儲在kube-system

配置文件創建完成，如果以后我們有新的資源需要被監控，我們只需要將ConfigMap對象更新即可，現在我們開始創建prometheus的Pod資源

我們在啟動程序的時候，除了指定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，如果不配置可能會出現權限問題

prometheus.yaml文件對應的ConfigMap對象通過volume的形式掛載進Pod，這樣ConfigMap更新后，對應的pod也會熱更新，然后我們在執行上面的reload請求，prometheus配置就生效了。除此之外，對了將時間數據進行持久化，我們將數據目錄和一個pvc對象進行了綁定，所以我們需要提前創建pvc對象

我們這里還需要創建rbac認證，因為prometheus需要訪問k8s集群內部的資源

由於我們要獲取的資源，在每一個namespace下面都有可能存在，所以我們這里使用的是ClusterRole的資源對象，nonResourceURLs是用來對非資源型metrics進行操作的權限聲明

我們將ConfigMap volume rbac 創建完畢后，就可以創建prometheus.deploy.yaml了，運行prometheus服務

現在我們prometheus服務狀態是已經正常了，但是我們在瀏覽器是無法訪問prometheus的 webui服務。那么我們還需要創建一個service

這里定義的端口為3xxxx,我們直接在瀏覽器上任意節點輸入ip+端口即可

Prometheus監控Kubernetes 集群節點及應用

監控方案

Kubelet/cAdvisor之外，我們還可以向Heapster添加其他指標源數據，比如kube-state-metrics

不過kube-state-metrics和metrics-server之前還有很大不同的，二者主要區別如下

監控集群節點

首先需要我們監控集群的節點，要監控節點其實我們已經有很多非常成熟的方案了，比如Nagios、Zabbix，甚至可以我們自己收集數據，這里我們通過prometheus來采集節點的監控指標，可以通過node_exporter獲取，node_exporter就是抓取用於采集服務器節點的各種運行指標，目前node_exporter幾乎支持所有常見的監控點，比如cpu、distats、loadavg、meminfo、netstat等，詳細的監控列表可以參考github repo

這里使用DeamonSet控制器來部署該服務，這樣每一個節點都會運行一個Pod，如果我們從集群中刪除或添加節點后，也會進行自動擴展

由於我們要獲取的數據是主機的監控指標數據，而我們的node-exporter是運行在容器中的，所以我們在Pod中需要配置一些Pod的安全策略

另外我們還需要將主機/dev、/proc、/sys這些目錄掛在到容器中，這些因為我們采集的很多節點數據都是通過這些文件來獲取系統信息

另外如果是使用kubeadm搭建的，同時需要監控master節點的，則需要添加下方的相應容忍

在我們的yaml文件中加入了hostNetwork:true會直接將我們的宿主機的9100端口映射出來，從而不需要創建service 在我們的宿主機上就會有一個9100的端口

上面我們檢查了Pod的運行狀態都是正常的，接下來我們要查看一下Pod日志，以及node-exporter中的metrics

使用命令kubectl logs -n 命名空間 node-exporter中Pod名稱檢查Pod日志是否有額外報錯

服務發現

我們這里三個節點都運行了node-exporter程序，如果我們通過一個Server來將數據收集在一起，用靜態的方式配置到prometheus就會顯示一條數據，我們得自己在指標中過濾每個節點的數據，配置比較麻煩。這里就采用服務發現

在Kubernetes下，Prometheus通過Kubernetes API基礎，目前主要支持5種服務發現，分別是node、Server、Pod、Endpoints、Ingress

現在我們可以看到已經獲取到我們的Node節點的IP，但是由於metrics監聽的端口是10250而並不是我們設置的9100，所以提示我們節點屬於Down的狀態

這里我們就需要使用Prometheus提供的relabel_configs中的replace能力了，relabel可以在Prometheus采集數據之前，通過Target實例的Metadata信息，動態重新寫入Label的值。除此之外，我們還能根據Target實例的Metadata信息選擇是否采集或者忽略該Target實例。這里使用__address__標簽替換10250端口為9100

目前狀態已經正常，但是還有一個問題就是我們的采集數據只顯示了IP地址，對於我們監控分組分類不是很方便，這里可以通過labelmap這個屬性來將Kubernetes的Label標簽添加為Prometheus的指標標簽

添加了一個action為labelmap，正則表達式是__meta_kubernetes_node(.+)的配置，這里的意思就是表達式中匹配的數據也添加到指標數據的Label標簽中去。

容器監控

cAdvisor是一個容器資源監控工具，包括容器的內存，CPU，網絡IO，資源IO等資源，同時提供了一個Web頁面用於查看容器的實時運行狀態。

cAvisor已經內置在了kubelet組件之中，所以我們不需要單獨去安裝，cAdvisor的數據路徑為/api/v1/nodes//proxy/metrics

action 使用labelkeep或者labeldrop則可以對Target標簽進行過濾，僅保留符合過濾條件的標簽

ls_config配置的證書地址是每個Pod連接apiserver所使用的地址，基本上寫死了。並且我們在配置文件添加了一個labelmap標簽。在最下面使用了一個正則替換了cAdvisor的一個metrics地址

修改完成之后，我們需要configmap並且使用curl進行熱更新(過程比較慢，需要等待會)

還可以使用sum函數,pod在1分鍾內的使用率，同時將pod名稱打印出來

Api-Service 監控

apiserver作為Kubernetes最核心的組件，它的監控也是非常有必要的，對於apiserver的監控，我們可以直接通過kubernetes的service來獲取

上面的service是我們集群的apiserver內部的service的地址，要自動發現service類型的服務，需要使用role為Endpoints的kubernetes_sd_configs (自動發現)，我們只需要在configmap里面在添加Endpoints類型的服務發現

更新完成后，我們可以看到kubernetes-apiserver下面出現了很多實例，這是因為我們這里使用的Endpoints類型的服務發現，所以prometheus把所有的Endpoints服務都抓取過來了，同樣的我們要監控的kubernetes也在列表中。

這里我們使用keep動作，將符合配置的保留下來，例如我們過濾default命名空間下服務名稱為kubernetes的元數據，這里可以根據__meta_kubernetes_namespace和__mate_kubertnetes_service_name2個元數據進行relabel

如果我們要監控其他系統組件，比如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"過濾出來

Serivce自動發現參數說明（並不是所有創建的service都可以被prometheus發現）

我們可以看到這里的服務的core DNS,為什么那么多service只有coreDNS可以被收集到呢？

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獲取到數據的！

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分鍾

免責聲明！