引言

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

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

其次，我們前面講解到了我們的自動化報(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)控方案后面還會涉及到生產(chǎn)環(huán)境。所以，我這邊打算把之前部署的刪除了，準(zhǔn)備使用 Prometheus-Operator，重新設(shè)計(jì)一套監(jiān)控方案，重新深入貫穿下 Prometheus 的生態(tài)。

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

ACK Serverless

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

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

架構(gòu)核心：

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

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

主要特點(diǎn)

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

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

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

按需擴(kuò)展

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

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

秒級彈性

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

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

原生 Kubernetes 支持

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

? 支持 Helm、Kubectl 等 Kubernetes 工具。

高性價(jià)比

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

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

資源隔離

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

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

核心組件與工作原理

核心組件

ACK Serverless Control Plane：

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

? 無需用戶手動操作，阿里云托管。

Elastic Container Instance (ECI)：

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

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

Serverless Pod：

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

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

工作原理

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

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

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

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

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

Elastic Container Instance (ECI)

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

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

ECI 的核心特點(diǎn)

無服務(wù)器

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

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

按需啟動

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

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

彈性擴(kuò)展

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

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

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

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

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

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

? 支持 VPC（專有網(wǎng)絡(luò)）、NAS（網(wǎng)絡(luò)存儲）、OSS（對象存儲）等阿里云服務(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 會被調(diào)度到 ECI 上運(yùn)行，而不需要管理任何節(jié)點(diǎn)。

? 區(qū)別在于：

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

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

使用方式的不同

? 直接使用 ECI：

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

b.可以通過 ECI 的 API、CLI 或阿里云控制臺啟動容器。

? 通過 ACK Serverless 使用 ECI：

? 適合需要完整 Kubernetes 管理能力的場景。

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

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

彈性與擴(kuò)展對比

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

我們再了解下真正要操作的對象：

Virtual Kubelet

圖片

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

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

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

介紹

Prometheus 是一種開源的監(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 控制器，用于簡化 Prometheus 的部署和管理。您可以通過在 Kubernetes 中部署 Prometheus Operator 來自動設(shè)置和管理 Prometheus 實(shí)例。

? 配置 Prometheus 實(shí)例： Prometheus Operator 將通過 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ù)定義儀表板或自定義儀表板來查看和分析度量數(shù)據(jù)。

? 監(jiān)控應(yīng)用程序和系統(tǒng)： Prometheus 通過 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)控工具

以下這些工具可以用于在 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è)輕量級指標(biāo)收集器，用于提供節(jié)點(diǎn)和 Pod 等資源的實(shí)時(shí)性能指標(biāo)，可以用于水平自動擴(kuò)展等。

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

? kube-prometheus 或 kube-prometheus-stack： 這是一個(gè)基于 Prometheus 的 Kubernetes 集群監(jiān)控解決方案。它包含了一系列組件，用于部署和管理 Prometheus、Alertmanager、Grafana 等，以實(shí)現(xiàn)對 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)。請注意，隨著時(shí)間的推移，Kubernetes 社區(qū)的工具和技術(shù)也可能會有變化和演進(jìn)，因此在使用這些工具時(shí)，建議查閱相關(guān)文檔以獲得最新信息和最佳實(shí)踐。

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

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

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

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

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

2）Prometheus Operator 和 Kube-orometheus 或 Kube-prometheus-stack 對比

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

Prometheus Operator：

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

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

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

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

? 靈活性： Prometheus Operator 允許根據(jù)不同的需求和配置選擇性地部署多個(gè) Prometheus 實(shí)例，每個(gè)實(shí)例可以針對特定的監(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ī)則和儀表盤。

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

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

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

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

Prometheus Operator 的工作原理

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

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

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

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

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

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

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

而除了這些原生的 Resource 資源以外，Kubernetes 還允許用戶添加自己的自定義資源 (Custom Resource)。并且通過實(shí)現(xiàn)自定義 Controller 來實(shí)現(xiàn)對 Kubernetes 的擴(kuò)展。 當(dāng)然我們?nèi)绻袑?yīng)的需求也完全可以自己去實(shí)現(xiàn)一個(gè) Operator，接下來我們就來給大家詳細(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 通過配置 Servicemonitor 匹配到由 Service 對象自動填充的 Endpoints，并配置 Prometheus 監(jiān)控這些 Endpoints 后端的 Pods，ServiceMonitor.Spec 的 Endpoints 部分就是用于配置 Endpoints 的哪些端口將被 Scrape 指標(biāo)。

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

Prometheus告警對接流程

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

圖片

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

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

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

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

Prometheus Operator 架構(gòu)

圖片

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

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

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

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

? Prometheus

? Alertmanager

? ServiceMonitor

? PodMonitor

? Probe

? ThanosRuler

? PrometheusRule

? AlertmanagerConfig

? PrometheusAgent

? ScrapeConfig

Prometheus

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

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

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

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

Alertmanager

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

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

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

ThanosRuler

該 CRD 定義了一個(gè) Thanos Ruler 組件的配置，以方便在 Kubernetes 集群中運(yùn)行。通過 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)控一組動態(tài)的服務(wù)，使用標(biāo)簽選擇來定義哪些 Service 被選擇進(jìn)行監(jiān)控。這可以讓團(tuán)隊(duì)制定一個(gè)如何暴露監(jiān)控指標(biāo)的規(guī)范，然后按照這些規(guī)范自動發(fā)現(xiàn)新的服務(wù)，而無需重新配置。

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

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

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

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

spec:
  namespaceSelector:
    any: true
PodMonitor

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

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

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

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

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

spec:
  namespaceSelector:
    any: true

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

Probe

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

PrometheusRule

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

AlertmanagerConfig

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

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

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

PrometheusSgents

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

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

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

適用場景

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

ScrapeConfig

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

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

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

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

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

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

為了解決這些問題，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 用于外部資源或高度定制化的抓取需求。

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

結(jié)語

這邊我們算是把整個(gè) Prometheus 必要的概念和原理熟悉后，我們接下來就該實(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