概述
從 v1.8 開始,資源使用情況的監控可以通過 Metrics API的形式獲取,具體的組件爲Metrics Server,用來替換之前的heapster,heapster從1.11開始逐漸被廢棄。
Metrics-Server是集羣核心監控數據的聚合器,從 Kubernetes1.8 開始,它作爲一個 Deployment對象默認部署在由kube-up.sh腳本創建的集羣中,如果是其他部署方式需要單獨安裝,或者諮詢對應的雲廠商。
Metrics API
介紹Metrics-Server之前,必須要提一下Metrics API的概念
Metrics API相比於之前的監控採集方式(hepaster)是一種新的思路,官方希望核心指標的監控應該是穩定的,版本可控的,且可以直接被用戶訪問(例如通過使用 kubectl top 命令),或由集羣中的控制器使用(如HPA),和其他的Kubernetes APIs一樣。
官方廢棄heapster項目,就是爲了將核心資源監控作爲一等公民對待,即像pod、service那樣直接通過api-server或者client直接訪問,不再是安裝一個hepater來匯聚且由heapster單獨管理。
假設每個pod和node我們收集10個指標,從k8s的1.6開始,支持5000節點,每個節點30個pod,假設採集粒度爲1分鐘一次,則:
10 x 5000 x 30 / 60 = 25000 平均每分鐘2萬多個採集指標
因爲k8s的api-server將所有的數據持久化到了etcd中,顯然k8s本身不能處理這種頻率的採集,而且這種監控數據變化快且都是臨時數據,因此需要有一個組件單獨處理他們,k8s版本只存放部分在內存中,於是metric-server的概念誕生了。
其實hepaster已經有暴露了api,但是用戶和Kubernetes的其他組件必須通過master proxy的方式才能訪問到,且heapster的接口不像api-server一樣,有完整的鑑權以及client集成。這個api現在還在alpha階段(18年8月),希望能到GA階段。類api-server風格的寫法:generic apiserver
有了Metrics Server組件,也採集到了該有的數據,也暴露了api,但因爲api要統一,如何將請求到api-server的/apis/metrics請求轉發給Metrics Server呢,解決方案就是:kube-aggregator,在k8s的1.7中已經完成,之前Metrics Server一直沒有面世,就是耽誤在了kube-aggregator這一步。
kube-aggregator(聚合api)主要提供:
- Provide an API for registering API servers.
- Summarize discovery information from all the servers.
- Proxy client requests to individual servers.
詳細設計文檔:參考鏈接
metric api的使用:
- Metrics API 只可以查詢當前的度量數據,並不保存歷史數據
- Metrics API URI 爲 /apis/metrics.k8s.io/,在 k8s.io/metrics 維護
- 必須部署 metrics-server 才能使用該 API,metrics-server 通過調用 Kubelet Summary API 獲取數據
如:
http://127.0.0.1:8001/apis/metrics.k8s.io/v1beta1/nodes
http://127.0.0.1:8001/apis/metrics.k8s.io/v1beta1/nodes/<node-name>
http://127.0.0.1:8001/apis/metrics.k8s.io/v1beta1/namespace/<namespace-name>/pods/<pod-name>
Metrics-Server介紹
Metrics server定時從Kubelet的Summary API(類似/ap1/v1/nodes/nodename/stats/summary)採集指標信息,這些聚合過的數據將存儲在內存中,且以metric-api的形式暴露出去。
Metrics server複用了api-server的庫來實現自己的功能,比如鑑權、版本等,爲了實現將數據存放在內存中嗎,去掉了默認的etcd存儲,引入了內存存儲(即實現Storage interface)。因爲存放在內存中,因此監控數據是沒有持久化的,可以通過第三方存儲來拓展,這個和heapster是一致的。
Metrics server出現後,新的Kubernetes 監控架構將變成上圖的樣子
- 核心流程(黑色部分):這是 Kubernetes正常工作所需要的核心度量,從 Kubelet、cAdvisor 等獲取度量數據,再由metrics-server提供給 Dashboard、HPA 控制器等使用。
- 監控流程(藍色部分):基於核心度量構建的監控流程,比如 Prometheus 可以從 metrics-server 獲取核心度量,從其他數據源(如 Node Exporter 等)獲取非核心度量,再基於它們構建監控告警系統。
官方地址:https://github.com/kubernetes-incubator/metrics-server
安裝使用
如上文提到的,metric-server是擴展的apiserver,依賴於kube-aggregator,因此需要在apiserver中開啓相關參數。
–requestheader-client-ca-file=/etc/kubernetes/certs/proxy-ca.crt
–proxy-client-cert-file=/etc/kubernetes/certs/proxy.crt
–proxy-client-key-file=/etc/kubernetes/certs/proxy.key
–requestheader-allowed-names=aggregator
–requestheader-extra-headers-prefix=X-Remote-Extra-
–requestheader-group-headers=X-Remote-Group
–requestheader-username-headers=X-Remote-User
安裝文件下載:1.8+版本,注意更換鏡像地址爲國內鏡像
或者手動拉取鏡像
docker pull registry.cn-beijing.aliyuncs.com/xingshulin/metrics-server-amd64:v0.3.3
docker tag mirrorgooglecontainers/metrics-server-amd64:v0.3.3 k8s.gcr.io/metrics-server-amd64:v0.3.3
將下載下來的metrics-server,修改metrics-server/deploy/1.8+/metrics-server-deployment.yaml文件
將imagePullPolicy修改爲 IfNotPresent,默認爲always
apply yaml這文件
kubectl create -f metrics-server/deploy/1.8+/
安裝完檢查deployment和pods部署完成
其他
kubernetes的新監控體系中,metrics-server屬於Core metrics(核心指標),提供API metrics.k8s.io,僅提供Node和Pod的CPU和內存使用情況。而其他Custom Metrics(自定義指標)由Prometheus等組件來完成,後續文章將對自定義指標進行解析。
相關文章:
kubernetes基於Metrics Server的HPA彈性伸縮pod
通過rancher快速部署Kubernetes集羣
在centos7部署k8s搭建kubernetes集羣