Prometheus-operator 介紹和配置解析

隨着雲原生概念盛行，對於容器、服務、節點以及集羣的監控變得愈來愈重要。Prometheus 做爲 Kubernetes 監控的事實標準，有着強大的功能和良好的生態。可是它不支持分佈式，不支持數據導入、導出，不支持經過 API 修改監控目標和報警規則，因此在使用它時，一般須要寫腳本和代碼來簡化操做。Prometheus Operator 爲監控 Kubernetes service、deployment 和 Prometheus 實例的管理提供了簡單的定義，簡化在 Kubernetes 上部署、管理和運行 Prometheus 和 Alertmanager 集羣。

功能

Prometheus Operator (後面都簡稱 Operater) 提供以下功能：

• 建立/銷燬：在 Kubernetes namespace 中更加容易地啓動一個 Prometheues 實例，一個特定應用程序或者團隊能夠更容易使用 Operator。

• 便捷配置：經過 Kubernetes 資源配置 Prometheus 的基本信息，好比版本、存儲、副本集等。

• 經過標籤標記目標服務： 基於常見的 Kubernetes label 查詢自動生成監控目標配置；不須要學習 Prometheus 特定的配置語言。

先決條件

對於版本高於 0.18.0 的 Prometheus Operator 要求 Kubernetes 集羣版本高於 1.8.0。若是你纔開始使用 Prometheus Operator，推薦你使用最新版。

若是你使用的舊版本的 Kubernetes 和 Prometheus Operator 還在運行，推薦先升級 Kubernetes，再升級 Prometheus Operator。

安裝與卸載

快速安裝

使用 helm 安裝 Prometheus Operator。使用 helm 安裝後，會在 Kubernetes 集羣中建立、配置和管理 Prometheus 集羣，chart 中包含多種組件：

• prometheus-operator
• prometheus
• alertmanager
• node-exporter
• kube-state-metrics
• grafana
• 收集 Kubernetes 內部組件指標的監控服務
  • kube-apiserver
  • kube-scheduler
  • kube-controller-manager
  • etcd
  • kube-dns/coredns
  • kube-proxy

安裝一個版本名爲 my-release 的 chart：

helm install --name my-release stable/prometheus-operator
複製代碼

這會在集羣中安裝一個默認配置的 prometheus-operator。這份配置文件列出了安裝過程當中能夠配置的選項。

默認會安裝 Prometheus Operator, Alertmanager, Grafana。而且會抓取集羣的基本信息。

卸載

卸載 my-release 部署：

helm delete my-release
複製代碼

這個命令會刪除與這個 chart 相關的全部 Kubernetes 組件。

這個 chart 建立的 CRDs 不會被默認刪除，須要手動刪除：

kubectl delete crd prometheuses.monitoring.coreos.com
kubectl delete crd prometheusrules.monitoring.coreos.com
kubectl delete crd servicemonitors.monitoring.coreos.com
kubectl delete crd podmonitors.monitoring.coreos.com
kubectl delete crd alertmanagers.monitoring.coreos.com
複製代碼

架構

Prometheus Operator 架構圖以下：

上面架構圖中，各組件以不一樣的方式運行在 Kubernetes 集羣中：

• Operator： 根據自定義資源（Custom Resource Definition / CRDs）來部署和管理 Prometheus Server，同時監控這些自定義資源事件的變化來作相應的處理，是整個系統的控制中心。
• Prometheus：聲明 Prometheus deployment 指望的狀態，Operator 確保這個 deployment 運行時一直與定義保持一致。
• Prometheus Server： Operator 根據自定義資源 Prometheus 類型中定義的內容而部署的 Prometheus Server 集羣，這些自定義資源能夠看做是用來管理 Prometheus Server 集羣的 StatefulSets 資源。
• ServiceMonitor：聲明指定監控的服務，描述了一組被 Prometheus 監控的目標列表。該資源經過 Labels 來選取對應的 Service Endpoint，讓 Prometheus Server 經過選取的 Service 來獲取 Metrics 信息。
• Service：簡單的說就是 Prometheus 監控的對象。
• Alertmanager：定義 AlertManager deployment 指望的狀態，Operator 確保這個 deployment 運行時一直與定義保持一致。

自定義資源

Prometheus Operater 定義了以下的四類自定義資源：

• Prometheus
• ServiceMonitor
• Alertmanager
• PrometheusRule

Prometheus

Prometheus 自定義資源（CRD）聲明瞭在 Kubernetes 集羣中運行的 Prometheus 的指望設置。包含了副本數量，持久化存儲，以及 Prometheus 實例發送警告到的 Alertmanagers等配置選項。

每個 Prometheus 資源，Operator 都會在相同 namespace 下部署成一個正確配置的 StatefulSet，Prometheus 的 Pod 都會掛載一個名爲 <prometheus-name> 的 Secret，裏面包含了 Prometheus 的配置。Operator 根據包含的 ServiceMonitor 生成配置，而且更新含有配置的 Secret。不管是對 ServiceMonitors 或者 Prometheus 的修改，都會持續不斷的被按照前面的步驟更新。

一個樣例配置以下：

kind: Prometheus
metadata: # 略
spec:
 alerting:
 alertmanagers:
 - name: prometheus-prometheus-oper-alertmanager # 定義該 Prometheus 對接的 Alertmanager 集羣的名字, 在 default 這個 namespace 中
 namespace: default
 pathPrefix: /
 port: web
 baseImage: quay.io/prometheus/prometheus
 replicas: 2 # 定義該 Proemtheus 「集羣」有兩個副本，說是集羣，其實 Prometheus 自身不帶集羣功能，這裏只是起兩個徹底同樣的 Prometheus 來避免單點故障
 ruleSelector: # 定義這個 Prometheus 須要使用帶有 prometheus=k8s 且 role=alert-rules 標籤的 PrometheusRule
 matchLabels:
 prometheus: k8s
 role: alert-rules
 serviceMonitorNamespaceSelector: {} # 定義這些 Prometheus 在哪些 namespace 裏尋找 ServiceMonitor
 serviceMonitorSelector: # 定義這個 Prometheus 須要使用帶有 k8s-app=node-exporter 標籤的 ServiceMonitor，不聲明則會所有選中
 matchLabels:
 k8s-app: node-exporter
 version: v2.10.0
複製代碼

Prometheus 配置

ServiceMonitor

ServiceMonitor 自定義資源(CRD)可以聲明如何監控一組動態服務的定義。它使用標籤選擇定義一組須要被監控的服務。這樣就容許組織引入如何暴露 metrics 的規定，只要符合這些規定新服務就會被發現列入監控，而不須要從新配置系統。

要想使用 Prometheus Operator 監控 Kubernetes 集羣中的應用，Endpoints 對象必須存在。Endpoints 對象本質是一個 IP 地址列表。一般，Endpoints 對象由 Service 構建。Service 對象經過對象選擇器發現 Pod 並將它們添加到 Endpoints 對象中。

一個 Service 能夠公開一個或多個服務端口，一般狀況下，這些端口由指向一個 Pod 的多個 Endpoints 支持。這也反映在各自的 Endpoints 對象中。

Prometheus Operator 引入 ServiceMonitor 對象，它發現 Endpoints 對象並配置 Prometheus 去監控這些 Pods。

ServiceMonitorSpec 的 endpoints 部分用於配置須要收集 metrics 的 Endpoints 的端口和其餘參數。在一些用例中會直接監控不在服務 endpoints 中的 pods 的端口。所以，在 endpoints 部分指定 endpoint 時，請嚴格使用，不要混淆。

注意：endpoints（小寫）是 ServiceMonitor CRD 中的一個字段，而 Endpoints（大寫）是 Kubernetes 資源類型。

ServiceMonitor 和發現的目標可能來自任何 namespace。這對於跨 namespace 的監控十分重要，好比 meta-monitoring。使用 PrometheusSpec 下 ServiceMonitorNamespaceSelector, 經過各自 Prometheus server 限制 ServiceMonitors 做用 namespece。使用 ServiceMonitorSpec 下的 namespaceSelector 能夠如今容許發現 Endpoints 對象的命名空間。要發現全部命名空間下的目標，namespaceSelector 必須爲空。

spec:
 namespaceSelector:
 any: true
複製代碼

一個樣例配置以下：

kind: ServiceMonitor
metadata:
 labels:
 k8s-app: node-exporter # 這個 ServiceMonitor 對象帶有 k8s-app=node-exporter 標籤，所以會被 Prometheus 選中
 name: node-exporter
 namespace: default
spec:
 selector:
 matchLabels: # 定義須要監控的 Endpoints，帶有 app=node-exporter 且 k8s-app=node-exporter標籤的 Endpoints 會被選中
 app: node-exporter
 k8s-app: node-exporter
 endpoints:
 - bearerTokenFile: /var/run/secrets/kubernetes.io/serviceaccount/token
 interval: 30s # 定義這些 Endpoints 須要每 30 秒抓取一次
 targetPort: 9100 # 定義這些 Endpoints 的指標端口爲 9100
 scheme: https
 jobLabel: k8s-app
複製代碼

ServiceMonitor 配置

Alertmanager

Alertmanager 自定義資源(CRD)聲明在 Kubernetes 集羣中運行的 Alertmanager 的指望設置。它也提供了配置副本集和持久化存儲的選項。

每個 Alertmanager 資源，Operator 都會在相同 namespace 下部署成一個正確配置的 StatefulSet。Alertmanager pods 配置掛載一個名爲 <alertmanager-name> 的 Secret， 使用 alertmanager.yaml key 對做爲配置文件。

當有兩個或更多配置的副本時，Operator 能夠高可用性模式運行Alertmanager實例。

一個樣例配置以下：

kind: Alertmanager # 一個 Alertmanager 對象
metadata:
 name: prometheus-prometheus-oper-alertmanager
spec:
 baseImage: quay.io/prometheus/alertmanager
 replicas: 3      # 定義該 Alertmanager 集羣的節點數爲 3
 version: v0.17.0
複製代碼

Alertmanager 配置

PrometheusRule

PrometheusRule CRD 聲明一個或多個 Prometheus 實例須要的 Prometheus rule。

Alerts 和 recording rules 能夠保存並應用爲 yaml 文件，能夠被動態加載而不須要重啓。

一個樣例配置以下：

kind: PrometheusRule
metadata:
 labels: # 定義該 PrometheusRule 的 label, 顯然它會被 Prometheus 選中
 prometheus: k8s
 role: alert-rules
 name: prometheus-k8s-rules
spec:
 groups:
 - name: k8s.rules
 rules: # 定義了一組規則，其中只有一條報警規則，用來報警 kubelet 是否是掛了
 - alert: KubeletDown
 annotations:
 message: Kubelet has disappeared from Prometheus target discovery.
 expr: | absent(up{job="kubelet"} == 1)  for: 15m
 labels:
 severity: critical
複製代碼

PrometheusRule 配置

它們之間的關係以下圖：

Prometheus Operator 的優勢

Prometheus Operator 中全部的 API 對象都是 CRD 中定義好的 Schema，API Server會校驗。當開發者使用 ConfigMap 保存配置沒有任何校驗，配置文件寫錯時，自表現爲功能不可用，問題排查複雜。在 Prometheus Operator 中，全部在 Prometheus 對象、ServiceMonitor 對象、PrometheusRule 對象中的配置都是有 Schema 校驗的，校驗失敗 apply 直接出錯，這就大大下降了配置異常的風險。

Prometheus Operator 藉助 K8S 將 Prometheus 服務平臺化。有了 Prometheus 和 AlertManager 這樣的 API 對象，很是簡單、快速的能夠在 K8S 集羣中建立和管理 Prometheus 服務和 AlertManager 服務，以應對不一樣業務部門，不一樣領域的監控需求。

ServiceMonitor 和 PrometheusRule 解決了 Prometheus 配置難維護問題，開發者再也不須要去專門學習 Prometheus 的配置文件，再也不須要經過 CI 和 k8s ConfigMap 等手段把配置文件更新到 Pod 內再觸發 webhook 熱更新，只須要修改這兩個對象資源就能夠了。

prometheus-operator-blog

關於Choerodon豬齒魚

Choerodon豬齒魚是一個開源多雲技術平臺，是基於開源技術Kubernetes，Istio，knative，Gitlab，Spring Cloud來實現本地和雲端環境的集成，實現企業多雲/混合雲應用環境的一致性。平臺經過提供精益敏捷、持續交付、容器環境、微服務、DevOps等能力來幫助組織團隊來完成軟件的生命週期管理，從而更快、更頻繁地交付更穩定的軟件。

Choerodon豬齒魚已開通官方微信交流羣，歡迎你們添加Choerodon豬齒魚微信(ID:choerodon-c7n)入羣

你們也能夠經過如下社區途徑瞭解豬齒魚的最新動態、產品特性，以及參與社區貢獻：

• 官網：choerodon.io
• 論壇：forum.choerodon.io
• Github：github.com/choerodon
• 碼雲：gitee.com/choerodon