k8s叢集監控
目前,監控K8S叢集較為流行的方案如下:
方案一:Heapster + influxDB + Grafana
Heapster 是 Kubernetes 原生的叢集監控方案。Heapster 以 Pod 的形式執行,在其配置檔案內傳入kubernetes master的地址,Heapster就會自動發現叢集節點、從節點上的 Kubelet 獲取監控資料。Kubelet 則是從節點上的 cAdvisor 收集資料。Heapster將資料儲存到預先配置的 backend 並進行視覺化展示,Heapster 當前支援的 backend 有很多種,如 InfluxDB,而Grafana則是influxDB
注:cadvisor是google用來分析執行中的docker的容器的資源佔用以及host效能特性的工具,它會將資料的資料給kublet,kublet已整合cadvisor,無需安裝。
方案二:Prometheus+ grafana
Prometheus是一套開源的集時間序列資料儲存、dashboard、報警功能的組合元件,監控範圍覆蓋容器、主機、儲存、資料庫、各種中介軟體,同時還具備完善的時序資料儲存、告警處理等能力。它的服務過程是由Prometheus daemon 負責定時去目標上抓取 metrics(
兩個方案的對比:
1.監控資料採集
heapster的監控採集依賴cAdvisor,只能監控node和容器,監控的資料範圍有限,對k8s和容器中的服務卻無能為力;而對於
2.功能
prometheus提供了heapster沒有的報警功能。
具體地,以下為prometheus方案。
主要分為以下幾個部分:
————————
監控告警:Prometheus + Exporters + AlertManager + 企業微信
監控檢視:Prometheus + Exporters + Grafana
兩個者都有 Prometheus + Exporters,其中:
1、Prometheus:時序資料庫,用於儲存監控的指標(Metrics)資料,它定時從 Exporters 拉取資料。其具備定期清理功能,無需擔心資料增長問題。
2、Exporters:各種 Exporter,用於提供監控指標(Metrics),各個 exporter,以HTTP /metrics 暴露 API,供 Prometheus拉取資料。
3、AlertManager:對接 Prometheus,當 Prometheus 根據自己的報警規則,發現有規則觸發時,會將告警資訊傳遞給 AlertManager,由 AlertManager自己的一套流程下發告警,Prometheus只管發告警資料給AlertManager,無需關心以什麼形式下發給接受者。
4、Grafana:監控檢視展示,它支援直接從 Prometheus 查詢,進而在自己的頁面上進行展示。
5、企業微信:對接 AlertManager,AlertManager 將告警資訊,傳送給企業微信後端介面,然後接受使用者即可通過企業微信收到告警資訊。
主元件選型條件:
————————
Prometheus:時序資料庫
Prometheus優勢:
①:質量:符合CNCF基金會專案標準
②:開源及擴充套件性:開源,700+共享者,幾百個第三方支援。基於Golang編寫,可定製。
③:K8S支援:對接K8S友好,對於監控K8S和容器本身友好,對部署到K8S內部的自定義監控指標同樣友好。
④:告警:自帶告警功能
⑤:對接檢視展示:本身就有檢視,還支援對接更好的第三方視覺化。
⑥:部署:方便,靈活,它無需在宿主機上部署專門的agent代理。
————————
Grafana:資料檢視展示。
Grafana優勢:
①:開源,公司內部已部署有一套Grafana系統。
②:介面乾淨,漂亮。
③:靈活性很好。
④:支援很多源,包括Prometheus源。
————————
企業微信:告警接收。
————————
Prometheus Alert Manager:告警資訊傳送元件,它和 Prometheus配套使用。(可傳送給簡訊、企業微信等)
————————
Exporters列表:
①:kube-state-metrics:採集K8S資源物件以及K8S元件的健康狀態指標資料,主要是Kubernetes叢集上Pod, DaemonSet, Deployment, Job, CronJob等各種資源物件的狀態,比如pod重啟等。此元件需要DaemonSet模式啟動,或者每個機器都啟動一個。
②:blackbox-exporter:監控http、tcp、icmp網路效能。k8s本身的只能用於探測進而保活,但無法探測效能如何,blackbox-exporter為效能探測提供了一種可能。它可以探測一個應用的效能概覽,從dns解析->連結建立->tls握手->等待應用響應資料->資料傳輸等時間。
③:node-directory-size-metrics:主要用於讀取節點目錄,獲取磁碟使用metric資料。注意,它只檢測/mnt目錄下的目錄的磁碟使用,如果你有需檢測某個機器上某個目錄的變化,使用這個元件比較合適,前提是需要把那個目錄,掛載到 /mnt目錄下。同樣,需要 DaemonSet模式啟動。
④:cadvisor:收集容器的資訊,如CPU、記憶體、磁碟IO等等,這個元件是監控容器的核心。同樣,需要 DaemonSet模式啟動。
⑤:node-exporter:用於收集宿主機資訊,如:CPU、記憶體、宿主機檔案IO、ipvs資訊等。同樣,需要 DaemonSet模式啟動。
監控告警告警部分的指標列表:
————————
針對k8s,要接收告警資訊需要有:
1、k8s節點異常
2、k8s磁碟使用率告警
3、pod crash
4、pod未執行
5、pod記憶體使用超限
6、Pod的CPU使用超限
7、Pod OOM重啟
8、Daemonset 建立後卡住,也就是無法建立例項出來(rollout stuck)
9、Deployment 建立後卡住(rollout stuck)
10、Daemonset 建立後無法排程
11、Deployment 建立後無法排程
12、Node NodeNotReady
12、K8SManyNodesNotReady
13、k8s節點 OutOfDisk(磁碟耗盡)
14、K8s節點磁碟壓力
15、k8s節點記憶體壓力
16、k8s節點CPU壓力
17、k8s節點不可排程
18、pod 記憶體增長過快(比如短時間增長超過512M)
19、k8s節點的記憶體需求超過k8s節點本身記憶體的一個閾值(比如80%)
20、pod的磁碟IO過高
————————
針對宿主機部分:
1、磁碟使用率
2、宿主機是否掛掉
3、宿主機CPU佔用率
4、宿主機檔案IO高(螞蜂窩目前的磁碟IO,到600就幾乎不行了,閾值可以設定為450)
5、宿主機網路流量
6、宿主機記憶體使用率
————————
針對Prometheus本身
1、配置reload失敗
2、Prometheus丟棄通知數量過高
3、Promehtues通知佇列過高
————————
針對容器
- 磁碟佔用率
- Cup佔用率
- 記憶體使用率
- 磁碟IO高