據Sysdig發佈的容器報告,容器以及如Kubernetes等編排工具的使用增加了51%以上,你們開始將工做負載在集羣中進行託管並管理。鑑於集羣中短暫的狀態,對於端到端的集羣有一個十分重要的需求,即可以詳細監控節點、容器以及pod。node
IT工程師須要管理應用程序、集羣(節點和數據),而且須要減小手動配置service、目標和數據存儲的工做量,同時在應用程序每次關閉和返回時進行監控。這就須要一個無縫部署以及管理高可用監控系統(如Prometheus),其中能夠與Operator一塊兒處理抓取目標的動態配置、服務發現以及用於告警集羣中各類目標的配置規則。同時,使用Operator模式編寫代碼以減小人工干預。git
本文,咱們將關注Prometheus Operator是如何工做的,service monitor在Prometheus Operator中是如何發現目標和獲取指標的。web
可以使用原生Kubernetes配置選項無縫安裝Prometheus Operator編程
可以在Kubernetes命名空間中建立和摧毀一個Prometheus實例,某個特定的應用程序或者團隊可以輕鬆地使用Operatorapi
可以預配置配置文件,包括Kubernetes資源的版本、持久性、保留策略和replica安全
可以使用標籤發現目標service,並根據熟悉的Kubernetes標籤查詢自動生成監控目標配置。app
例如:當pod /service銷燬並返回時,Prometheus Operator能夠自動建立新的配置文件,無需人工干預。工具
Custom Resource Definition(CRD):建立一個新的自定義資源,包括可指定的名稱和模式,無需任何編程。Kubernetes API提供和處理自定義資源的存儲。性能
自定義資源:擴展Kubernetes API或容許將自定義API引入kubernetes集羣的對象。編碼
自定義控制器:以新的方式處理內置的Kubernetes對象,如Deployment、Service等,或管理自定義資源,如同管理本機Kubernetes組件
Operator模式(適用於CRD和自定義控制器):Operator基於Kubernetes資源和控制器增長了容許Operator執行常見應用程序任務的配置。
Operator在後臺執行如下操做以管理自定義資源:
一、CRD建立:CRD定義規範和元數據,基於該規範和元數據應建立自定義資源。當建立CRD的請求時,使用Kubernetes內部模式類型(OpenAPI v3模式)驗證元數據,而後建立自定義資源定義(CRD)對象
二、自定義資源建立根據元數據和CRD規範驗證對象,並相應地建立自定義對象建立。
三、Operator(自定義控制器)開始監控event及其狀態變動,並基於CRD管理自定義資源。它能夠提供event在自定義資源上執行CRUD操做,所以每當更改自定義資源的狀態時,都能被觸發相應的event。
Prometheus Operator使用Service Monitor CRD執行自動發現和自動配置獲取的目標。
ServiceMonitoring包括如下組件:
Service:其實是service/deployment,它在定義的端點、端口暴露指標,並使用對應的標籤進行標識。每當service或pod發生故障時,該service以相同的標籤返回,所以使得它可被service monitor發現。
Service Monitor:可基於匹配的標籤發現service的自定義資源。Servicemonitor處於部署了Prometheus CRD的命名空間中,但經過使用NamespaceSelector,它依舊可以發現部署在其餘命名空間中的service。
Prometheus CRD:基於標籤與service monitor相匹配而且可以生成Prometheus的配置。
Prometheus Operator:它可調用config-reloader組件以自動更新yaml配置,其中包含抓取目標的詳細信息。
接下來咱們來看一個簡單的使用案例,以此理解Prometheus Operator時如何監控service的。
Gerrit是一個代碼review工具,主要用於DevOps CI流水線,在代碼入庫前對每一個提交進行審閱。本文假設Gerrit已經在Kubernetes集羣中運行,所以再也不贅述Gerrit在Kubernetes做爲服務運行的步驟。
若是你尚未Prometheus Operator,可使用helm chart來安裝或直接使用Rancher,在Rancher2.2及以上的版本中,Rancher會在新添加的集羣中部署一個Prometheus Operator。如下組件將會被默認下載安裝:
prometheus-operator
prometheus
alertmanager
node-exporter
kube-state-metrics
grafana
service monitors to scrape internal kubernetes components
kube-apiserver kube-scheduler kube-controller-manager etcd kube-dns/coredns
如下步驟將展現Prometheus Operator如何自動發現運行在Kubernetes集羣上的Gerrit服務以及如何從Gerrit中抓取指標。
可使用Prometheus jar插件暴露Gerrit指標,但須要提早將該插件安裝在Gerrit實例上運行。
Prometheus jar插件下載地址:
https://gerrit-ci.gerritforge.com/ ,將jar放在Gerrit插件目錄中:/var/gerrit/review_site/plugins/,並重啓gerrit服務。
在管理員的web界面校驗Prometheus插件:Gerrit -> Plugins -> Prometheus plugin。
建立一個帳號和組並給予查看指標的訪問權限
以管理員權限登陸到Gerrit的web界面,訪問:Projects>List>All-Projects。點擊【Access】標籤,再點擊【edit】按鈕。
在block global capabilities中,點擊【Add Permission】而且在下拉列表中選擇【View Metrics】。
在Gerrit中爲用戶生成一個token。
選擇咱們此前建立的組「Prometheus Metrics「,點擊【Add】按鈕。
滑至頁面底部並點擊【Save Changes】按鈕。
在Gerrit中生成token以後,你可使用用戶id和token來生成Base64編碼格式的用戶id和token,用於將憑證存儲在Kubernetes中。
使用secret的詳細信息建立一個yaml並在Kubernetes中建立secret。
kubectl apply -f gerrit-secret.yaml
使用兩個標籤標記Gerrit服務,例如:app: gerrit and release: prometheus-operator
kubectl label svc gerrit app=gerrit release=prometheus-operator
在servicemonitoring添加端點的詳細信息以發現Gerrit服務指標以及具備匹配標籤的的selector,以下所示:
Selector下的標籤是用於標識服務的標籤:
Selector: matchLabels: app: gerrit release: prometheus-operator
元數據部分下的標籤是指用於經過Prometheus CRD識別服務監視器的標籤。
Metadata: labels: app: gerrit release: prometheus-operator
Namespaceselector:在Gerrit服務所運行的Kubernetes集羣中提供命名空間。Service能夠在任何命名空間中運行,但service monitor只能在Prometheus Operator運行的命名空間建立,這樣Prometheus CRD就能夠識別service monitor對象。
使用如下命令驗證Prometheus對象中Service Monitor selector的部分:
kubectl get prometheus Match and apply the label as given in step 4b for the Prometheus object. serviceMonitorSelector: matchLabels: release: prometheus-operator
注意:若是Prometheus-operator使用helm部署,標籤release=Prometheus-operator已經應用到Prometheus對象上。咱們依舊須要在service monitor中匹配這個標籤,由於Prometheus CRD須要肯定合適的service monitor。
以上servicemonitor建立步驟可使用prometheus-operator helm自定義values.yaml來完成。
標籤更新以後,Prometheus自定義對象將會自動調用config-reloader來讀取終端並更新Prometheus配置文件。這是Prometheus Operator的一個好處,無需手動介入建立Prometheus配置文件和更新抓取的配置。
一、 打開Prometheus url:http://prometheusip:nodeport
kubectl get svc prometheus以獲取nodeport詳細信息並用節點的詳細信息來替代IP。
二、 訪問菜單:Status -> Configuration,來查看使用抓取配置自動加載的Prometheus配置。在scrape_configs部分,能夠查看Gerrit service monitor的詳細信息,以下所示:
三、 訪問菜單 -> Status -> Targets or Service Discovery。若是service monitor已經成功抓取Gerrit的指標,目標應該顯示爲健康[1/1up]。
Gerrit暴露了各類指標,如JVM運行時間、線程內存、heap size、error等。這些均可以在Grafana儀表板中配置以監控Gerrit的性能和運行情況(以下所示)。
Gerrit指標在scrape url下暴露:
http://gerrit-svcip:nodeport/a/plugins/metrics-reporter-prometheus/metrics
kubectl get svc prometheus
-獲取service 節點端口。
將gerrit-svcip、nodeport替換爲gerrit服務的gerrit IP / nodeport的詳細信息,暴露的指標將以下所示。
指標的值能夠在Prometheus -> Graph 中的表達字段進行評估,如:caches_disk_cached_git_tags
在Grafana中配置指標以監控Gerrit的健康情況,選擇數據源爲Prometheus並在dashboard中配置widget。一些已經配置的關鍵指標有JVM_threads、Uptime、Http_Plugin errors、內存使用狀況、事件等。
Prometheus Operator有助於Prometheus的無縫部署和管理、抓取目標的動態配置、服務發現、可擴展性、以及內置的SRE專業知識,這能夠加速集羣監控。
2018年年底,Rancher Labs宣佈增強對Prometheus的支持,這將爲跨多個Kubernetes集羣和多個隔離租戶環境提供更高的可見性。在Rancher2.2及以上的版本中,每當添加一個新的Kubernetes集羣到Rancher中,Rancher都將在集羣中部署一個Prometheus operator,而後在集羣中建立一個Prometheus部署。此外,還支持如下兩個功能:
集羣範圍內的Prometheus部署將被用於存儲集羣指標(如CPU節點和內存消耗),並存儲從單個用戶部署的應用程序中收集的項目級指標。
項目級的Grafana與Prometheus的通訊將經過安全代理完成,該代理可爲Prometheus實現多租戶。安全代理工具PromQL語句可確保僅能經過用戶項目的命名空間進行查詢。
Rancher對Prometheus的加強支持,可確保爲全部Kubernetes集羣、全部項目和全部用戶進行高效的部署和有效的監測。安全代理確保不在多租戶之間重複共享數據,而且對多租戶進行隔離。除此以外,Rancher還收集使用Prometheus處理的數據公開端點的任意自定義指標。全部指標都可用於Rancher內部的告警和決策,經過通知用戶的Slack及PagerDuty進行簡單操做,經過啓動工做負載的橫向擴展最終增長負載進行復雜操做。Rancher如今還擁有徹底安全隔離和RBAC的集羣級和項目級的指標和儀表盤。