引言

為什么前面用的好好的 Kube-prometheus-stack 好好的，不用了，要使用 Prometheus-Operator 呢？

首先，先介紹下我們的基本環(huán)境，我現(xiàn)在使用的集群是我們公司的 Test 環(huán)境的集群，托管在阿里云里面的 ACK Serverless 集群，對(duì)于業(yè)界開(kāi)箱即用的一些監(jiān)控生態(tài)工具，是很難做到全方面監(jiān)控的。所以，我這邊想要去做一套針對(duì) ACK Serverless 集群的監(jiān)控方案，但是這個(gè)肯定需要一些時(shí)間來(lái)好好研究的。

其次，我們前面講解到了我們的自動(dòng)化報(bào)告生成，生成的報(bào)告，里面的數(shù)據(jù)不是我們想要的。我是用 Kube-Prometheus-stack 的 Chart 包部署的，有的數(shù)據(jù)不全，因?yàn)檫@個(gè)包當(dāng)時(shí)是我們團(tuán)隊(duì)的另外一個(gè)人負(fù)責(zé)的，而且目前這個(gè)監(jiān)控方案后面還會(huì)涉及到生產(chǎn)環(huán)境。所以，我這邊打算把之前部署的刪除了，準(zhǔn)備使用 Prometheus-Operator，重新設(shè)計(jì)一套監(jiān)控方案，重新深入貫穿下 Prometheus 的生態(tài)。

為什么呢？我們來(lái)先詳細(xì)認(rèn)識(shí)下 ACK Serverless 集群

ACK Serverless

? ACK Serverless 集群 是一種 "無(wú)服務(wù)器" 的 Kubernetes 集群，即用戶無(wú)需管理底層的節(jié)點(diǎn)資源（如 EC2 或 ECS 實(shí)例），系統(tǒng)會(huì)根據(jù)用戶的實(shí)際負(fù)載動(dòng)態(tài)調(diào)度容器到后端資源。

? 用戶只需專(zhuān)注于工作負(fù)載的部署和業(yè)務(wù)邏輯，而不需要手動(dòng)管理集群中的節(jié)點(diǎn)。

架構(gòu)核心：

? 它基于 阿里云 Elastic Container Instance (ECI)，用以提供容器運(yùn)行的計(jì)算資源。

? 每個(gè) Pod 都會(huì)被調(diào)度到 ECI 中運(yùn)行，而不是固定的節(jié)點(diǎn)。

主要特點(diǎn)

無(wú)需節(jié)點(diǎn)管理

? ACK Serverless 集群不需要管理 Kubernetes 節(jié)點(diǎn)（如虛擬機(jī)或物理機(jī)）。

? 用戶不需要擔(dān)心節(jié)點(diǎn)的擴(kuò)容、縮容、健康檢查等復(fù)雜運(yùn)維工作。

按需擴(kuò)展

? Pod 在工作負(fù)載增加時(shí)動(dòng)態(tài)啟動(dòng)，直接使用 阿里云 ECI 作為后端資源。

? 當(dāng)負(fù)載減少時(shí)，Pod 會(huì)被回收，避免資源浪費(fèi)。

秒級(jí)彈性

? Pod 啟動(dòng)基于 ECI，啟動(dòng)速度極快（通常幾秒鐘）。

? 非常適合運(yùn)行短期或突發(fā)性的工作負(fù)載。

原生 Kubernetes 支持

? 兼容 Kubernetes 生態(tài)系統(tǒng)和原生 API。

? 支持 Helm、Kubectl 等 Kubernetes 工具。

高性價(jià)比

? 資源按實(shí)際使用計(jì)費(fèi)，不使用時(shí)不產(chǎn)生費(fèi)用。

? 無(wú)需為空閑節(jié)點(diǎn)支付費(fèi)用。

資源隔離

? 每個(gè) Pod 是獨(dú)立運(yùn)行的，與其他用戶隔離。

? 支持阿里云 VPC 網(wǎng)絡(luò)，安全可靠。

核心組件與工作原理

核心組件

ACK Serverless Control Plane：

? 負(fù)責(zé)管理 Kubernetes API 和調(diào)度邏輯。

? 無(wú)需用戶手動(dòng)操作，阿里云托管。

Elastic Container Instance (ECI)：

? 提供 Pod 的計(jì)算和存儲(chǔ)資源。

? 動(dòng)態(tài)為每個(gè) Pod 分配資源，按需計(jì)費(fèi)。

Serverless Pod：

? 工作負(fù)載直接以 Pod 的形式運(yùn)行在 ECI 上。

? 支持容器鏡像、存儲(chǔ)卷掛載、網(wǎng)絡(luò)配置等功能。

工作原理

1. 用戶創(chuàng)建 Serverless Pod 或通過(guò) Deployment 等資源部署工作負(fù)載。

2. ACK Serverless 的調(diào)度器會(huì)將 Pod 動(dòng)態(tài)分配到 ECI 資源中運(yùn)行。

3. 如果沒(méi)有足夠的資源，系統(tǒng)會(huì)自動(dòng)擴(kuò)展 ECI 實(shí)例。

4. 任務(wù)完成后，Pod 會(huì)被釋放，資源將被回收。

我們這里還需要學(xué)習(xí)下 ECI (Elastic Container Instance)

Elastic Container Instance (ECI)

ECI 是阿里云提供的一種按需運(yùn)行容器的服務(wù)，無(wú)需管理底層計(jì)算資源。ECI 直接運(yùn)行容器任務(wù)，不依賴虛擬機(jī)或物理機(jī)，用戶只需要關(guān)注容器鏡像、運(yùn)行配置以及資源需求。

簡(jiǎn)單來(lái)說(shuō)，ECI 是一種 Serverless 容器運(yùn)行平臺(tái)，它提供了類(lèi)似虛擬機(jī)的運(yùn)行環(huán)境，但用戶不需要關(guān)心服務(wù)器的管理和運(yùn)維。

ECI 的核心特點(diǎn)

無(wú)服務(wù)器

? 無(wú)需配置或管理底層的節(jié)點(diǎn)（ECS 實(shí)例）。

? 容器實(shí)例直接運(yùn)行在阿里云托管的基礎(chǔ)設(shè)施上。

按需啟動(dòng)

? 容器實(shí)例在用戶請(qǐng)求時(shí)按需啟動(dòng)，支持秒級(jí)啟動(dòng)。

? 無(wú)需提前分配資源，避免閑置成本。

彈性擴(kuò)展

? 容器實(shí)例會(huì)根據(jù)負(fù)載動(dòng)態(tài)擴(kuò)展（水平擴(kuò)展或縮容）。

? 適合突發(fā)性和高彈性負(fù)載需求。

支持原生容器生態(tài)

? 完全兼容 OCI（Open Container Initiative）容器鏡像。

? 可以通過(guò) Docker CLI 或 Kubernetes API 部署和管理容器。

與阿里云服務(wù)的深度集成

? 支持 VPC（專(zhuān)有網(wǎng)絡(luò)）、NAS（網(wǎng)絡(luò)存儲(chǔ)）、OSS（對(duì)象存儲(chǔ)）等阿里云服務(wù)。

? 可以結(jié)合云監(jiān)控、日志服務(wù)進(jìn)行容器狀態(tài)和性能監(jiān)控。

ECI 和 ACK Serverless 的關(guān)系

ACK Serverless 是基于 ECI 構(gòu)建的

? ACK Serverless 集群 使用 ECI 作為其底層計(jì)算資源。Serverless Pod 會(huì)被調(diào)度到 ECI 上運(yùn)行，而不需要管理任何節(jié)點(diǎn)。

? 區(qū)別在于：

a.ECI 是單獨(dú)運(yùn)行的容器實(shí)例，更類(lèi)似于“裸容器”。

b.ACK Serverless 提供了 Kubernetes 的調(diào)度和管理能力，用戶可以通過(guò) Kubernetes 的 Deployment、Service 等資源來(lái)管理工作負(fù)載。

使用方式的不同

? 直接使用 ECI：

a.適用于需要直接運(yùn)行容器任務(wù)的場(chǎng)景，如事件驅(qū)動(dòng)的任務(wù)、短期批量任務(wù)。

b.可以通過(guò) ECI 的 API、CLI 或阿里云控制臺(tái)啟動(dòng)容器。

? 通過(guò) ACK Serverless 使用 ECI：

? 適合需要完整 Kubernetes 管理能力的場(chǎng)景。

? 用戶可以部署復(fù)雜的 Kubernetes 工作負(fù)載（如 Deployment、StatefulSet）。

? ACK Serverless 集群自動(dòng)將工作負(fù)載映射到 ECI 上運(yùn)行。

彈性與擴(kuò)展對(duì)比

ECI 和傳統(tǒng) ECS 的對(duì)比

我們?cè)倭私庀抡嬲僮鞯膶?duì)象：

Virtual Kubelet

圖片

Virtual Kubelet 是一個(gè)開(kāi)源項(xiàng)目，允許 Kubernetes 將其節(jié)點(diǎn)擴(kuò)展到其他服務(wù)（如服務(wù)器無(wú)關(guān)的容器實(shí)例、邊緣設(shè)備等）。 由于這些節(jié)點(diǎn)并非實(shí)際的物理或虛擬機(jī)，傳統(tǒng)的監(jiān)控方法（如通過(guò) Node Exporter 或直接訪問(wèn) Kubelet 的 /metrics 接口）可能不適用。

它并不是一個(gè)真正的物理節(jié)點(diǎn)或虛擬機(jī)，而是一個(gè)代理，通常用于將 Kubernetes 節(jié)點(diǎn)擴(kuò)展到其他服務(wù) （如阿里云 ECI、Azure ACI、AWS Fargate）。

虛擬節(jié)點(diǎn)并沒(méi)有底層的操作系統(tǒng)環(huán)境，也無(wú)法暴露 /proc 或 /sys 文件系統(tǒng)。

介紹

Prometheus 是一種開(kāi)源的監(jiān)控和警報(bào)工具，用于收集和記錄應(yīng)用程序和系統(tǒng)的度量數(shù)據(jù)。它特別適用于在 Kubernetes 集群中監(jiān)控容器化應(yīng)用程序。Kubernetes 集群中通常與 Prometheus 一起使用的組件是 Prometheus Operator 和 Grafana。

以下是在 Kubernetes 中使用 Prometheus 的主要步驟：

? 安裝 Prometheus Operator： Prometheus Operator 是一種 Kubernetes 控制器，用于簡(jiǎn)化 Prometheus 的部署和管理。您可以通過(guò)在 Kubernetes 中部署 Prometheus Operator 來(lái)自動(dòng)設(shè)置和管理 Prometheus 實(shí)例。

? 配置 Prometheus 實(shí)例： Prometheus Operator 將通過(guò) Kubernetes 的自定義資源定義（CRD）創(chuàng)建和管理 Prometheus 實(shí)例。您可以使用 PrometheusRule CRD 定義監(jiān)控規(guī)則，并使用 ServiceMonitor CRD 定義需要監(jiān)控的目標(biāo)（例如 Kubernetes 服務(wù)）。

? 配置和導(dǎo)入 Dashboard： Grafana 通常與 Prometheus 一起使用，用于可視化監(jiān)控指標(biāo)。您可以在 Grafana 中導(dǎo)入 Prometheus 的預(yù)定義儀表板或自定義儀表板來(lái)查看和分析度量數(shù)據(jù)。

? 監(jiān)控應(yīng)用程序和系統(tǒng)： Prometheus 通過(guò) HTTP 端點(diǎn)從目標(biāo)應(yīng)用程序和系統(tǒng)中拉取度量數(shù)據(jù)。您可以在應(yīng)用程序中暴露 Prometheus 格式的度量數(shù)據(jù)，并在 ServiceMonitor 中定義用于監(jiān)控的目標(biāo)。

? 警報(bào)配置： Prometheus 還支持配置警報(bào)規(guī)則，以便在達(dá)到特定閾值或條件時(shí)觸發(fā)警報(bào)。警報(bào)規(guī)則可以定義為 PrometheusRule CRD。

常見(jiàn)的幾款監(jiān)控工具

以下這些工具可以用于在 Kubernetes 集群中實(shí)現(xiàn)監(jiān)控和指標(biāo)收集，以便于監(jiān)視集群中的各種資源和應(yīng)用的性能。

? Heapster： Heapster 是一個(gè) Kubernetes 集群的資源監(jiān)控工具，用于收集和匯總資源使用情況數(shù)據(jù)，如 CPU、內(nèi)存、網(wǎng)絡(luò)等。

? Metrics Server： Metrics Server 是 Kubernetes 官方提供的一個(gè)輕量級(jí)指標(biāo)收集器，用于提供節(jié)點(diǎn)和 Pod 等資源的實(shí)時(shí)性能指標(biāo)，可以用于水平自動(dòng)擴(kuò)展等。

? Prometheus Operator： Prometheus Operator 是一個(gè) Kubernetes 控制器，用于管理和部署 Prometheus 和相關(guān)的監(jiān)控組件。它可以自動(dòng)創(chuàng)建和管理 Prometheus 實(shí)例、ServiceMonitor 和其他配置。

? kube-prometheus 或 kube-prometheus-stack： 這是一個(gè)基于 Prometheus 的 Kubernetes 集群監(jiān)控解決方案。它包含了一系列組件，用于部署和管理 Prometheus、Alertmanager、Grafana 等，以實(shí)現(xiàn)對(duì) Kubernetes 集群和應(yīng)用的全面監(jiān)控。

heapster-》metrics-server-》prometheus-operator -》kube-prometheus-》kube-prometheus-stack

相關(guān)地址：

prometheus-operator GitHub 地址[1]

kube-prometheus GitHub 地址[2]

kube-prometheus-stack GitHub 地址[3]

這些工具的組合可以幫助您搭建一個(gè)完整的監(jiān)控系統(tǒng)，用于監(jiān)視 Kubernetes 集群中的資源利用率、應(yīng)用的性能、服務(wù)的可用性等指標(biāo)。請(qǐng)注意，隨著時(shí)間的推移，Kubernetes 社區(qū)的工具和技術(shù)也可能會(huì)有變化和演進(jìn)，因此在使用這些工具時(shí)，建議查閱相關(guān)文檔以獲得最新信息和最佳實(shí)踐。

1）kube-prometheus 和 kube-prometheus-stack 區(qū)別

? "kube-prometheus" 和 "kube-prometheus-stack" 本質(zhì)上是同一個(gè)項(xiàng)目，只是在不同的時(shí)間和版本中使用了不同的名稱(chēng)。"kube-prometheus-stack" 是 "kube-prometheus" 項(xiàng)目的更新版本，它提供了更多的功能、改進(jìn)和修復(fù)。

? 最初，項(xiàng)目被稱(chēng)為 "kube-prometheus"，但隨著時(shí)間的推移，項(xiàng)目團(tuán)隊(duì)對(duì)項(xiàng)目進(jìn)行了大量的改進(jìn)和擴(kuò)展，并將其重命名為 "kube-prometheus-stack"，以更好地反映其提供的綜合性監(jiān)控解決方案。

? "kube-prometheus-stack"（或簡(jiǎn)稱(chēng) "kube-prometheus"）是一個(gè)在 Kubernetes 集群中部署和管理 Prometheus 監(jiān)控系統(tǒng)以及相關(guān)組件的綜合解決方案。它集成了 Prometheus、Grafana、Alertmanager 等一系列組件，還包括預(yù)配置的監(jiān)控規(guī)則和儀表盤(pán)，以及一鍵部署功能。用戶可以通過(guò)部署 "kube-prometheus-stack" 來(lái)快速啟動(dòng)一個(gè)全面的 Kubernetes 集群監(jiān)控系統(tǒng)，無(wú)需逐個(gè)配置各個(gè)組件。

? 總結(jié)起來(lái)，"kube-prometheus-stack" 是 "kube-prometheus" 項(xiàng)目的更新版本，提供更多的功能和改進(jìn)，是一個(gè)便捷的綜合性監(jiān)控解決方案，適合在 Kubernetes 環(huán)境中快速部署和使用。

2）Prometheus Operator 和 Kube-orometheus 或 Kube-prometheus-stack 對(duì)比

"Prometheus Operator" 和 "kube-prometheus"（或 "kube-prometheus-stack"）都是用于在 Kubernetes 集群中部署和管理 Prometheus 監(jiān)控系統(tǒng)的工具。它們有一些相似之處，但也存在一些區(qū)別。以下是它們的主要特點(diǎn)和區(qū)別的對(duì)比：

Prometheus Operator：

? 核心功能： Prometheus Operator 是一個(gè) Kubernetes 控制器，專(zhuān)門(mén)用于管理 Prometheus 和相關(guān)組件的配置和部署。它自動(dòng)創(chuàng)建和管理 Prometheus 實(shí)例、ServiceMonitor、Alertmanager、PrometheusRule 等 Kubernetes 資源。

? 聲明式配置： Prometheus Operator 通過(guò)自定義資源定義（Custom Resource Definitions，CRDs）來(lái)實(shí)現(xiàn)聲明式配置。您可以創(chuàng)建 Prometheus、ServiceMonitor 等資源對(duì)象來(lái)定義監(jiān)控配置，Operator 會(huì)根據(jù)這些定義自動(dòng)創(chuàng)建和維護(hù)相關(guān)的資源。

? 自動(dòng)發(fā)現(xiàn)： Prometheus Operator 支持自動(dòng)發(fā)現(xiàn) Kubernetes 中的 Service、Pod、Namespace 等資源，無(wú)需手動(dòng)配置每個(gè)監(jiān)控目標(biāo)。

? 生態(tài)系統(tǒng)整合： Prometheus Operator 集成了 Grafana 和 Alertmanager，并可以輕松與其他監(jiān)控工具集成。

? 靈活性： Prometheus Operator 允許根據(jù)不同的需求和配置選擇性地部署多個(gè) Prometheus 實(shí)例，每個(gè)實(shí)例可以針對(duì)特定的監(jiān)控任務(wù)進(jìn)行配置。

Kube-prometheus 或 Kube-prometheus-stack：

? 綜合解決方案： kube-prometheus（或 kube-prometheus-stack）是一個(gè)完整的監(jiān)控解決方案，集成了 Prometheus、Grafana、Alertmanager 等一系列組件，以及一些預(yù)配置的監(jiān)控規(guī)則和儀表盤(pán)。

? 快速啟動(dòng)： kube-prometheus 提供了一鍵式的部署方式，適合快速啟動(dòng)一個(gè)完整的監(jiān)控系統(tǒng)，無(wú)需逐個(gè)配置各個(gè)組件。

? 預(yù)配置規(guī)則和儀表盤(pán)： kube-prometheus 提供了一些默認(rèn)的監(jiān)控規(guī)則和 Grafana 儀表盤(pán)，可以快速啟用監(jiān)控功能。

? 集成和擴(kuò)展： 由于 kube-prometheus 集成了多個(gè)組件，您可以使用這個(gè)解決方案來(lái)快速部署一個(gè)全面的監(jiān)控系統(tǒng)，并且可以根據(jù)需要進(jìn)行定制和擴(kuò)展。

綜合來(lái)看，Prometheus Operator 專(zhuān)注于 Prometheus 和相關(guān)資源的管理和自動(dòng)化配置，而 kube-prometheus 或 kube-prometheus-stack 則是一個(gè)更加綜合的解決方案，適合快速啟動(dòng)一個(gè)完整的監(jiān)控系統(tǒng)，尤其對(duì)于剛開(kāi)始使用 Prometheus 的用戶來(lái)說(shuō)，可以減少配置的復(fù)雜性。您可以根據(jù)實(shí)際需求和情況選擇合適的工具。

Prometheus Operator 的工作原理

Operator 是由 CoreOS 公司開(kāi)發(fā)的，用來(lái)擴(kuò)展 Kubernetes API，特定的應(yīng)用程序控制器，它用來(lái)創(chuàng)建、配置和管理復(fù)雜的有狀態(tài)應(yīng)用，如數(shù)據(jù)庫(kù)、緩存和監(jiān)控系統(tǒng)。Operator 基于 Kubernetes 的資源和控制器概念之上構(gòu)建，但同時(shí)又包含了應(yīng)用程序特定的一些專(zhuān)業(yè)知識(shí)，比如創(chuàng)建一個(gè)數(shù)據(jù)庫(kù)的Operator，則必須對(duì)創(chuàng)建的數(shù)據(jù)庫(kù)的各種運(yùn)維方式非常了解，創(chuàng)建 Operator 的關(guān)鍵是 CRD（自定義資源） 的設(shè)計(jì)。

CRD 是對(duì) Kubernetes API 的擴(kuò)展，Kubernetes 中的每個(gè)資源都是一個(gè) API 對(duì)象的集合，例如我們?cè)赮AML文件里定義的那些 spec 都是對(duì) Kubernetes 中的資源對(duì)象的定義，所有的自定義資源可以跟 Kubernetes 中內(nèi)建的資源一樣使用 kubectl 操作。

Operator 是將運(yùn)維人員對(duì)軟件操作的知識(shí)給代碼化，同時(shí)利用 Kubernetes 強(qiáng)大的抽象來(lái)管理大規(guī)模的軟件應(yīng)用。目前 CoreOS 官方提供了幾種 Operator 的實(shí)現(xiàn)，其中就包括我們今天的主角：Prometheus Operator，Operator 的核心實(shí)現(xiàn)就是基于 Kubernetes 的以下兩個(gè)概念：

? 資源： 對(duì)象的狀態(tài)定義

? 控制器： 觀測(cè)、分析和行動(dòng)，以調(diào)節(jié)資源的分布

從概念上來(lái)講 Operator 就是針對(duì)管理特定應(yīng)用程序的，在 Kubernetes 基本的 Resource 和 Controller 的概念上，以擴(kuò)展 Kubernetes API 的形式。幫助用戶創(chuàng)建，配置和管理復(fù)雜的有狀態(tài)應(yīng)用程序。從而實(shí)現(xiàn)特定應(yīng)用程序的常見(jiàn)操作以及運(yùn)維自動(dòng)化。

在 Kubernetes 中我們使用 Deployment、DamenSet，StatefulSet 來(lái)管理應(yīng)用 Workload，使用 Service，Ingress 來(lái)管理應(yīng)用的訪問(wèn)方式，使用 ConfigMap 和 Secret 來(lái)管理應(yīng)用配置。我們?cè)诩褐袑?duì)這些資源的創(chuàng)建，更新，刪除的動(dòng)作都會(huì)被轉(zhuǎn)換為事件 (Event)，Kubernetes 的 Controller Manager 負(fù)責(zé)監(jiān)聽(tīng)這些事件并觸發(fā)相應(yīng)的任務(wù)來(lái)滿足用戶的期望。這種方式我們成為聲明式，用戶只需要關(guān)心應(yīng)用程序的最終狀態(tài)，其它的都通過(guò) Kubernetes 來(lái)幫助我們完成，通過(guò)這種方式可以大大簡(jiǎn)化應(yīng)用的配置管理復(fù)雜度。

而除了這些原生的 Resource 資源以外，Kubernetes 還允許用戶添加自己的自定義資源 (Custom Resource)。并且通過(guò)實(shí)現(xiàn)自定義 Controller 來(lái)實(shí)現(xiàn)對(duì) Kubernetes 的擴(kuò)展。 當(dāng)然我們?nèi)绻袑?duì)應(yīng)的需求也完全可以自己去實(shí)現(xiàn)一個(gè) Operator，接下來(lái)我們就來(lái)給大家詳細(xì)介紹下 Prometheus-Operator 的使用方法。

下面三個(gè)yaml文件 很好的表述了，Prometheus 如何關(guān)聯(lián)選擇 Servicemonitor，Servicemonitor 如何關(guān)聯(lián)選擇目標(biāo) Service。

圖片

為了能讓 Prometheus 監(jiān)控 k8s 內(nèi)的應(yīng)用，Prometheus-Operator 通過(guò)配置 Servicemonitor 匹配到由 Service 對(duì)象自動(dòng)填充的 Endpoints，并配置 Prometheus 監(jiān)控這些 Endpoints 后端的 Pods，ServiceMonitor.Spec 的 Endpoints 部分就是用于配置 Endpoints 的哪些端口將被 Scrape 指標(biāo)。

Servicemonitor 對(duì)象很巧妙，它解耦了“監(jiān)控的需求”和“需求的實(shí)現(xiàn)方”。 Servicemonitor 只需要用到 Label-selector 這種簡(jiǎn)單又通用的方式聲明一個(gè) “監(jiān)控需求”，也就是哪些 Endpoints 需要搜集，怎么收集就行了。讓用戶只關(guān)心需求，這是一個(gè)非常好的關(guān)注點(diǎn)分離。當(dāng)然 Servicemonitor 最后還是會(huì)被 Operator轉(zhuǎn)化為原始的復(fù) 雜的 Scrape config,但這個(gè)復(fù)雜度已經(jīng)完全被 Operator 屏蔽了。

Prometheus告警對(duì)接流程

下圖很好的展現(xiàn)了Prometheus在配置報(bào)警時(shí)需要操作哪些資源，及各資源起到的作用

圖片

? 首先通過(guò)配置 Servicemonitor/Podmonitor 來(lái)獲取應(yīng)用的監(jiān)控指標(biāo)；

? Prometheus.spec.alerting 字段會(huì)匹配 Alertmanager 中的配置，匹配到 Alertmanager 實(shí)例

? 然后通過(guò) Prometheusrule 對(duì)監(jiān)控到的指標(biāo)配置報(bào)警規(guī)則；

? 最后配置告警接收器，配置 Alertmanager config 來(lái)配置如何處理告警，包括如何接收、路由、抑制和發(fā)送警報(bào)等；

Prometheus Operator 架構(gòu)

圖片

上圖是 Prometheus-Operator 官方提供的架構(gòu)圖，其中 Operator 是最核心的部分，作為一個(gè)控制器，他會(huì)去創(chuàng)建 Prometheus、ServiceMonitor、AlertManager 以及 PrometheusRule 4個(gè)CRD 資源對(duì)象，然后會(huì)一直監(jiān)控并維持這4個(gè)資源對(duì)象的狀態(tài)。

其中創(chuàng)建的 Prometheus 這種資源對(duì)象就是作為 Prometheus Server 存在，而 ServiceMonitor 就是 Exporter 的各種抽象，Exporter 前面我們已經(jīng)學(xué)習(xí)了，是用來(lái)提供專(zhuān)門(mén)提供 Metrics 數(shù)據(jù)接口的工具，Prometheus 就是通過(guò) ServiceMonitor 提供的 Metrics 數(shù)據(jù)接口去 Pull 數(shù)據(jù)的，當(dāng)然 AlertManager 這種資源對(duì)象就是對(duì)應(yīng)的 AlertManager 的抽象，而 PrometheusRule 是用來(lái)被 Prometheus 實(shí)例使用的報(bào)警規(guī)則文件。

這樣我們要在集群中監(jiān)控什么數(shù)據(jù)，就變成了直接去操作 Kubernetes 集群的資源對(duì)象了，是不是方便很多了。上圖中的 Service 和 ServiceMonitor 都是 Kubernetes 的資源，一個(gè) ServiceMonitor 可以通過(guò) LabelSelector 的方式去匹配一類(lèi) Service，Prometheus 也可以通過(guò) LabelSelector 去匹配多個(gè) ServiceMonitor。

在最新版本的 Operator 中提供了一下幾個(gè) CRD 資源對(duì)象：

? Prometheus

? Alertmanager

? ServiceMonitor

? PodMonitor

? Probe

? ThanosRuler

? PrometheusRule

? AlertmanagerConfig

? PrometheusAgent

? ScrapeConfig

Prometheus

該 CRD 聲明定義了 Prometheus 期望在 Kubernetes 集群中運(yùn)行的配置，提供了配置選項(xiàng)來(lái)配置副本、持久化、報(bào)警實(shí)例等。

對(duì)于每個(gè) Prometheus CRD 資源，Operator 都會(huì)以 StatefulSet 形式在相同的命名空間下部署對(duì)應(yīng)配置的資源，Prometheus Pod 的配置是通過(guò)一個(gè)包含 Prometheus 配置的名為 Prometheus-name 的 Secret 對(duì)象聲明掛載的。

該 CRD 根據(jù)標(biāo)簽選擇來(lái)指定部署的 Prometheus 實(shí)例應(yīng)該覆蓋哪些 ServiceMonitors，然后 Operator 會(huì)根據(jù)包含的 ServiceMonitors 生成配置，并在包含配置的 Secret 中進(jìn)行更新。

如果未提供對(duì) ServiceMonitor 的選擇，則 Operator 會(huì)將 Secret 的管理留給用戶，這樣就可以提供自定義配置，同時(shí)還能享受 Operator 管理 Operator 的設(shè)置能力。

Alertmanager

該 CRD 定義了在 Kubernetes 集群中運(yùn)行的 Alertmanager 的配置，同樣提供了多種配置，包括持久化存儲(chǔ)。

對(duì)于每個(gè) Alertmanager 資源，Operator 都會(huì)在相同的命名空間中部署一個(gè)對(duì)應(yīng)配置的 StatefulSet，Alertmanager Pods 被配置為包含一個(gè)名為 Alertmanager-name 的 Secret，該 Secret 以 alertmanager.yaml 為 key 的方式保存使用的配置文件。

當(dāng)有兩個(gè)或更多配置的副本時(shí)，Operator 會(huì)在高可用模式下運(yùn)行 Alertmanager 實(shí)例。

ThanosRuler

該 CRD 定義了一個(gè) Thanos Ruler 組件的配置，以方便在 Kubernetes 集群中運(yùn)行。通過(guò) Thanos Ruler，可以跨多個(gè) Prometheus 實(shí)例處理記錄和警報(bào)規(guī)則。

一個(gè) ThanosRuler 實(shí)例至少需要一個(gè) queryEndpoint，它指向 Thanos Queriers 或 Prometheus 實(shí)例的位置。queryEndpoints 用于配置 Thanos 運(yùn)行時(shí)的 --query 參數(shù)，更多信息也可以在 Thanos 文檔中找到。

ServiceMonitor

該 CRD 定義了如何監(jiān)控一組動(dòng)態(tài)的服務(wù)，使用標(biāo)簽選擇來(lái)定義哪些 Service 被選擇進(jìn)行監(jiān)控。這可以讓團(tuán)隊(duì)制定一個(gè)如何暴露監(jiān)控指標(biāo)的規(guī)范，然后按照這些規(guī)范自動(dòng)發(fā)現(xiàn)新的服務(wù)，而無(wú)需重新配置。

為了讓 Prometheus 監(jiān)控 Kubernetes 內(nèi)的任何應(yīng)用，需要存在一個(gè) Endpoints 對(duì)象，Endpoints 對(duì)象本質(zhì)上是 IP 地址的列表，通常 Endpoints 對(duì)象是由 Service 對(duì)象來(lái)自動(dòng)填充的，Service 對(duì)象通過(guò)標(biāo)簽選擇器匹配 Pod，并將其添加到 Endpoints 對(duì)象中。一個(gè) Service 可以暴露一個(gè)或多個(gè)端口，這些端口由多個(gè) Endpoints 列表支持，這些端點(diǎn)一般情況下都是指向一個(gè) Pod。

Prometheus Operator 引入的這個(gè) ServiceMonitor 對(duì)象就會(huì)發(fā)現(xiàn)這些 Endpoints 對(duì)象，并配置 Prometheus 監(jiān)控這些 Pod。ServiceMonitorSpec 的 endpoints 部分就是用于配置這些 Endpoints 的哪些端口將被 scrape 指標(biāo)的。

注意：endpoints（小寫(xiě)）是 ServiceMonitor CRD 中的字段，而 Endpoints（大寫(xiě)）是 Kubernetes 的一種對(duì)象。

ServiceMonitors 以及被發(fā)現(xiàn)的目標(biāo)都可以來(lái)自任何命名空間，這對(duì)于允許跨命名空間監(jiān)控的場(chǎng)景非常重要。使用 PrometheusSpec 的 ServiceMonitorNamespaceSelector，可以限制各自的 Prometheus 服務(wù)器選擇的 ServiceMonitors 的命名空間。使用 ServiceMonitorSpec 的 namespaceSelector，可以限制 Endpoints 對(duì)象被允許從哪些命名空間中發(fā)現(xiàn)，要在所有命名空間中發(fā)現(xiàn)目標(biāo)，namespaceSelector 必須為空：

spec:
  namespaceSelector:
    any: true
PodMonitor

該 CRD 用于定義如何監(jiān)控一組動(dòng)態(tài) pods，使用標(biāo)簽選擇來(lái)定義哪些 pods 被選擇進(jìn)行監(jiān)控。同樣團(tuán)隊(duì)中可以制定一些規(guī)范來(lái)暴露監(jiān)控的指標(biāo)。

Pod 是一個(gè)或多個(gè)容器的集合，可以在一些端口上暴露 Prometheus 指標(biāo)。

由 Prometheus Operator 引入的 PodMonitor 對(duì)象會(huì)發(fā)現(xiàn)這些 Pod，并為 Prometheus 服務(wù)器生成相關(guān)配置，以便監(jiān)控它們。

PodMonitorSpec 中的 PodMetricsEndpoints 部分，用于配置 Pod 的哪些端口將被 scrape 指標(biāo)，以及使用哪些參數(shù)。

PodMonitors 和發(fā)現(xiàn)的目標(biāo)可以來(lái)自任何命名空間，這同樣對(duì)于允許跨命名空間的監(jiān)控用例是很重要的。使用 PodMonitorSpec 的 namespaceSelector，可以限制 Pod 被允許發(fā)現(xiàn)的命名空間，要在所有命名空間中發(fā)現(xiàn)目標(biāo)，namespaceSelector 必須為空：

spec:
  namespaceSelector:
    any: true

PodMonitor 和 ServieMonitor 最大的區(qū)別就是不需要有對(duì)應(yīng)的 Service。

Probe

該 CRD 用于定義如何監(jiān)控一組 Ingress 和靜態(tài)目標(biāo)。除了 target 之外，Probe 對(duì)象還需要一個(gè) prober，它是監(jiān)控的目標(biāo)并為 Prometheus 提供指標(biāo)的服務(wù)。例如可以通過(guò)使用 blackbox-exporter 來(lái)提供這個(gè)服務(wù)。

PrometheusRule

用于配置 Prometheus 的 Rule 規(guī)則文件，包括 recording rules 和 alerting，可以自動(dòng)被 Prometheus 加載。

AlertmanagerConfig

在以前的版本中要配置 Alertmanager 都是通過(guò) Configmap 來(lái)完成的，在 v0.43 版本后新增該 CRD，可以將 Alertmanager 的配置分割成不同的子對(duì)象進(jìn)行配置，允許將報(bào)警路由到自定義 Receiver 上，并配置抑制規(guī)則。

AlertmanagerConfig 可以在命名空間級(jí)別上定義，為 Alertmanager 提供一個(gè)聚合的配置。這里提供了一個(gè)如何使用它的例子。不過(guò)需要注意這個(gè) CRD 還不穩(wěn)定。

這樣我們要在集群中監(jiān)控什么數(shù)據(jù)，就變成了直接去操作 Kubernetes 集群的資源對(duì)象了，是這樣比之前手動(dòng)的方式就方便很多了。

PrometheusSgents

是一種新的 CRD，主要用于定義 Prometheus Agent 實(shí)例。

Prometheus Agent 是一種輕量化的 Prometheus 模式，適用于 遠(yuǎn)程寫(xiě)入 的場(chǎng)景。

它的主要作用是采集監(jiān)控?cái)?shù)據(jù)并將其轉(zhuǎn)發(fā)到遠(yuǎn)程存儲(chǔ)（例如 Thanos 或 Cortex），而不需要存儲(chǔ)數(shù)據(jù)或提供查詢功能。

適用場(chǎng)景

• ? 僅需要采集監(jiān)控?cái)?shù)據(jù)并將其轉(zhuǎn)發(fā)到遠(yuǎn)程存儲(chǔ)，不需要存儲(chǔ)和查詢功能。
• ? 適合邊緣監(jiān)控或分布式監(jiān)控場(chǎng)景，例如 IoT、邊緣計(jì)算。
• ? 資源受限的環(huán)境中更適合使用 Prometheus Agent。

ScrapeConfig

用于動(dòng)態(tài)配置 Prometheus Scrape Configuration（Prometheus 的抓取配置）。

它允許用戶通過(guò)聲明式方式為 Prometheus 添加或修改抓取配置 (scrape_configs)，而無(wú)需直接編輯 Prometheus 的全局配置文件（prometheus.yaml）。

主要目的是提供更靈活的抓取配置選項(xiàng)，尤其是用于復(fù)雜場(chǎng)景中自定義抓取目標(biāo)或特殊的認(rèn)證需求。

在默認(rèn)情況下，Prometheus Operator 是通過(guò) ServiceMonitor 或 PodMonitor 來(lái)定義抓取目標(biāo)的。

然而，這種方式有一定限制，無(wú)法滿足一些復(fù)雜場(chǎng)景，比如：

• ? 自定義抓取目標(biāo)（不通過(guò) Kubernetes 服務(wù)發(fā)現(xiàn)）。
• ? 針對(duì)特定的認(rèn)證方式配置（如 BasicAuth、BearerToken、OAuth）。
• ? 自定義 metrics_path 或抓取規(guī)則。

為了解決這些問(wèn)題，Prometheus Operator 引入了 ScrapeConfig CRD。

主要功能

自定義抓取目標(biāo)

• ? 可以定義任意非 Kubernetes 的抓取目標(biāo)，例如外部的 HTTP 服務(wù)、API 網(wǎng)關(guān)等。

靈活的認(rèn)證方式

• ? 支持 BasicAuth、TLS 認(rèn)證、Bearer Token、OAuth 等多種認(rèn)證方式。

特定的抓取設(shè)置

• ? 自定義 metrics_path、scheme（HTTP/HTTPS）、interval（抓取間隔）等參數(shù)。

與 ServiceMonitor 和 PodMonitor 的區(qū)別

• ? ServiceMonitor 和 PodMonitor 更適合 Kubernetes 內(nèi)部資源的監(jiān)控。
• ? ScrapeConfig 用于外部資源或高度定制化的抓取需求。

簡(jiǎn)言之，Prometheus Operator 能夠幫助用戶自動(dòng)化的創(chuàng)建以及管理 Prometheus Server 以及其相應(yīng)的配置。

結(jié)語(yǔ)

這邊我們算是把整個(gè) Prometheus 必要的概念和原理熟悉后，我們接下來(lái)就該實(shí)操了，下面的也是一個(gè)大工程，需要一些時(shí)間去把這個(gè)貫穿和實(shí)現(xiàn)。

引用鏈接

[1] prometheus-operator GitHub 地址: https://github.com/prometheus-operator/prometheus-operator[2] kube-prometheus GitHub 地址: https://github.com/prometheus-operator/kube-prometheus[3] kube-prometheus-stack GitHub 地址: https://github.com/prometheus-community/helm-charts/tree/main/charts/kube-prometheus-stack