Kubernetes 集群監(jiān)控 kube-prometheus 部署

簡介

Prometheus 介紹

Kubernetes Operator 介紹

Prometheus Operator 介紹

簡介

Prometheus 介紹

Kubernetes Operator 介紹

Prometheus Operator 介紹

架構

Prometheus Operator

Prometheus

安裝

拉取 Prometheus Operator

進行文件分類

修改 Service 端口設置

修改 Prometheus Service

修改 Grafana Service

修改數(shù)據(jù)持久化存儲

創(chuàng)建 StorageClass

修改 Prometheus 持久化

修改 Grafana 持久化配置

安裝Prometheus Operator

安裝 Operator

安裝其它組件

查看 Prometheus & Grafana

查看 Prometheus

查看 Grafana

小結(jié)

簡介

Prometheus 介紹

Prometheus 是一套開源的監(jiān)控 & 報警 & 時間序列數(shù)據(jù)庫的組合,起始是由 SoundCloud 公司開發(fā)的。成立于 2012 年，之后許多公司和組織接受和采用 prometheus,他們便將它獨立成開源項目，并且有公司來運作.該項目有非常活躍的社區(qū)和開發(fā)人員，目前是獨立的開源項目，任何公司都可以使用它，2016 年，Prometheus 加入了云計算基金會，成為 kubernetes 之后的第二個托管項目.google SRE 的書內(nèi)也曾提到跟他們 BorgMon 監(jiān)控系統(tǒng)相似的實現(xiàn)是 Prometheus。現(xiàn)在最常見的 Kubernetes 容器管理系統(tǒng)中，通常會搭配 Prometheus 進行監(jiān)控。

注意：

Prometheus-operator 已經(jīng)改名為 Kube-promethues

Kubernetes Operator 介紹

在 Kubernetes 的支持下，管理和伸縮 Web 應用、移動應用后端以及 API 服務都變得比較簡單了。其原因是這些應用一般都是無狀態(tài)的，所以 Deployment 這樣的基礎 Kubernetes API 對象就可以在無需附加操作的情況下，對應用進行伸縮和故障恢復了。

而對于數(shù)據(jù)庫、緩存或者監(jiān)控系統(tǒng)等有狀態(tài)應用的管理，就是個挑戰(zhàn)了。這些系統(tǒng)需要應用領域的知識，來正確的進行伸縮和升級，當數(shù)據(jù)丟失或不可用的時候，要進行有效的重新配置。我們希望這些應用相關的運維技能可以編碼到軟件之中，從而借助 Kubernetes 的能力，正確的運行和管理復雜應用。

Operator 這種軟件，使用 TPR (第三方資源，現(xiàn)在已經(jīng)升級為 CRD) 機制對 Kubernetes API 進行擴展，將特定應用的知識融入其中，讓用戶可以創(chuàng)建、配置和管理應用。和 Kubernetes 的內(nèi)置資源一樣，Operator 操作的不是一個單實例應用，而是集群范圍內(nèi)的多實例。

Prometheus Operator 介紹

Kubernetes 的 Prometheus Operator 為 Kubernetes 服務和 Prometheus 實例的部署和管理提供了簡單的監(jiān)控定義。

安裝完畢后，Prometheus Operator 提供了以下功能：

創(chuàng)建/毀壞： 在 Kubernetes namespace 中更容易啟動一個 Prometheus 實例，一個特定的應用程序或團隊更容易使用Operator。

簡單配置： 配置 Prometheus 的基礎東西，比如在 Kubernetes 的本地資源 versions, persistence, retention policies, 和 replicas。

Target Services 通過標簽： 基于常見的 Kubernetes label 查詢，自動生成監(jiān)控 target 配置；不需要學習 Prometheus 特定的配置語言。

架構

Prometheus Operator

Operator： Operator 資源會根據(jù)自定義資源（Custom Resource Definition / CRDs）來部署和管理 Prometheus Server，同時監(jiān)控這些自定義資源事件的變化來做相應的處理，是整個系統(tǒng)的控制中心。

Prometheus： Prometheus 資源是聲明性地描述 Prometheus 部署的期望狀態(tài)。

Prometheus Server： Operator 根據(jù)自定義資源 Prometheus 類型中定義的內(nèi)容而部署的 Prometheus Server 集群，這些自定義資源可以看作是用來管理 Prometheus Server 集群的 StatefulSets 資源。

ServiceMonitor： ServiceMonitor 也是一個自定義資源，它描述了一組被 Prometheus 監(jiān)控的 targets 列表。該資源通過 Labels 來選取對應的 Service Endpoint，讓 Prometheus Server 通過選取的 Service 來獲取 Metrics 信息。

Service： Service 資源主要用來對應 Kubernetes 集群中的 Metrics Server Pod，來提供給 ServiceMonitor 選取讓 Prometheus Server 來獲取信息。簡單的說就是 Prometheus 監(jiān)控的對象，例如 Node Exporter Service、Mysql Exporter Service 等等。

Alertmanager： Alertmanager 也是一個自定義資源類型，由 Operator 根據(jù)資源描述內(nèi)容來部署 Alertmanager 集群。

Prometheus

作為一個監(jiān)控系統(tǒng)，Prometheus 項目的作用和工作方式，其實可以用如下所示的一張官方示意圖來解釋：

可以看到，Prometheus 項目工作的核心，是使用 Pull （抓取）的方式去搜集被監(jiān)控對象的 Metrics 數(shù)據(jù)（監(jiān)控指標數(shù)據(jù)），然后，再把這些數(shù)據(jù)保存在一個 TSDB （時間序列數(shù)據(jù)庫，比如 OpenTSDB、InfluxDB 等）當中，以便后續(xù)可以按照時間進行檢索。有了這套核心監(jiān)控機制， Prometheus 剩下的組件就是用來配合這套機制的運行。比如 Pushgateway，可以允許被監(jiān)控對象以 Push 的方式向 Prometheus 推送 Metrics 數(shù)據(jù)。而 Alertmanager，則可以根據(jù) Metrics 信息靈活地設置報警。當然， Prometheus 最受用戶歡迎的功能，還是通過 Grafana 對外暴露出的、可以靈活配置的監(jiān)控數(shù)據(jù)可視化界面。

安裝

系統(tǒng)參數(shù)：

Kube-promethues 版本： 0.6.0

Kubernetes 版本： 1.18.5

項目 Github 地址： https://github.com/coreos/kube-prometheus

拉取 Prometheus Operator

先從 Github 上將源碼拉取下來，利用源碼項目已經(jīng)寫好的 kubernetes 的 yaml 文件進行一系列集成鏡像的安裝，如 grafana、prometheus 等等。

從 GitHub 拉取 Prometheus Operator 源碼：

wget https://github.com/coreos/kube-prometheus/archive/v0.6.0.tar.gz

解壓：

tar -zxvf v0.6.0.tar.gz

進行文件分類

由于它的文件都存放在項目源碼的 manifests 文件夾下，所以需要進入其中進行啟動這些 kubernetes 應用 yaml 文件。又由于這些文件堆放在一起，不利于分類啟動，所以這里將它們分類。

進入源碼的 manifests 文件夾：

cd kube-prometheus-0.6.0/manifests/

創(chuàng)建文件夾并且將 yaml 文件分類：

# 創(chuàng)建文件夾 mkdir -p node-exporter alertmanager grafana kube-state-metrics prometheus serviceMonitor adapter # 移動 yaml 文件，進行分類到各個文件夾下 mv *-serviceMonitor* serviceMonitor/ mv grafana-* grafana/ mv kube-state-metrics-* kube-state-metrics/ mv alertmanager-* alertmanager/ mv node-exporter-* node-exporter/ mv prometheus-adapter* adapter/ mv prometheus-* prometheus/

基本目錄結(jié)構如下：

$ tree manifests/ ├── adapter │ ├── prometheus-adapter-apiService.yaml │ ├── prometheus-adapter-clusterRoleAggregatedMetricsReader.yaml │ ├── prometheus-adapter-clusterRoleBindingDelegator.yaml │ ├── prometheus-adapter-clusterRoleBinding.yaml │ ├── prometheus-adapter-clusterRoleServerResources.yaml │ ├── prometheus-adapter-clusterRole.yaml │ ├── prometheus-adapter-configMap.yaml │ ├── prometheus-adapter-deployment.yaml │ ├── prometheus-adapter-roleBindingAuthReader.yaml │ ├── prometheus-adapter-serviceAccount.yaml │ └── prometheus-adapter-service.yaml ├── alertmanager │ ├── alertmanager-alertmanager.yaml │ ├── alertmanager-secret.yaml │ ├── alertmanager-serviceAccount.yaml │ └── alertmanager-service.yaml ├── grafana │ ├── grafana-dashboardDatasources.yaml │ ├── grafana-dashboardDefinitions.yaml │ ├── grafana-dashboardSources.yaml │ ├── grafana-deployment.yaml │ ├── grafana-pvc.yaml │ ├── grafana-serviceAccount.yaml │ └── grafana-service.yaml ├── kube-state-metrics │ ├── kube-state-metrics-clusterRoleBinding.yaml │ ├── kube-state-metrics-clusterRole.yaml │ ├── kube-state-metrics-deployment.yaml │ ├── kube-state-metrics-serviceAccount.yaml │ └── kube-state-metrics-service.yaml ├── node-exporter │ ├── node-exporter-clusterRoleBinding.yaml │ ├── node-exporter-clusterRole.yaml │ ├── node-exporter-daemonset.yaml │ ├── node-exporter-serviceAccount.yaml │ └── node-exporter-service.yaml ├── prometheus │ ├── prometheus-clusterRoleBinding.yaml │ ├── prometheus-clusterRole.yaml │ ├── prometheus-prometheus.yaml │ ├── prometheus-roleBindingConfig.yaml │ ├── prometheus-roleBindingSpecificNamespaces.yaml │ ├── prometheus-roleConfig.yaml │ ├── prometheus-roleSpecificNamespaces.yaml │ ├── prometheus-rules.yaml │ ├── prometheus-serviceAccount.yaml │ └── prometheus-service.yaml ├── serviceMonitor │ ├── alertmanager-serviceMonitor.yaml │ ├── grafana-serviceMonitor.yaml │ ├── kube-state-metrics-serviceMonitor.yaml │ ├── node-exporter-serviceMonitor.yaml │ ├── prometheus-adapter-serviceMonitor.yaml │ ├── prometheus-operator-serviceMonitor.yaml │ ├── prometheus-serviceMonitorApiserver.yaml │ ├── prometheus-serviceMonitorCoreDNS.yaml │ ├── prometheus-serviceMonitorKubeControllerManager.yaml │ ├── prometheus-serviceMonitorKubelet.yaml │ ├── prometheus-serviceMonitorKubeScheduler.yaml │ └── prometheus-serviceMonitor.yaml └── setup ├── 0namespace-namespace.yaml ├── prometheus-operator-0alertmanagerCustomResourceDefinition.yaml ├── prometheus-operator-0podmonitorCustomResourceDefinition.yaml ├── prometheus-operator-0prometheusCustomResourceDefinition.yaml ├── prometheus-operator-0prometheusruleCustomResourceDefinition.yaml ├── prometheus-operator-0servicemonitorCustomResourceDefinition.yaml ├── prometheus-operator-0thanosrulerCustomResourceDefinition.yaml ├── prometheus-operator-clusterRoleBinding.yaml ├── prometheus-operator-clusterRole.yaml ├── prometheus-operator-deployment.yaml ├── prometheus-operator-serviceAccount.yaml └── prometheus-operator-service.yaml

修改 Service 端口設置

修改 prometheus-service.yaml 文件

vim prometheus/prometheus-service.yaml

修改prometheus Service端口類型為 NodePort，設置 NodePort 端口為 32101：

apiVersion: v1 kind: Service metadata: labels: prometheus: k8s name: prometheus-k8s namespace: monitoring spec: type: NodePort ports: - name: web port: 9090 targetPort: web nodePort: 32101 selector: app: prometheus prometheus: k8s sessionAffinity: ClientIP

修改 grafana-service.yaml 文件：

vim grafana/grafana-service.yaml

修改 garafana service 端口類型為 NodePort，設置 NodePort 端口為 32102：

apiVersion: v1 kind: Service metadata: labels: app: grafana name: grafana namespace: monitoring spec: type: NodePort ports: - name: http port: 3000 targetPort: http nodePort: 32102 selector: app: grafana

修改數(shù)據(jù)持久化存儲

prometheus 實際上是通過 emptyDir 進行掛載的，我們知道 emptyDir 掛載的數(shù)據(jù)的生命周期和 Pod 生命周期一致的，如果 Pod 掛掉了，那么數(shù)據(jù)也就丟失了，這也就是為什么我們重建 Pod 后之前的數(shù)據(jù)就沒有了的原因，所以這里修改它的持久化配置。

這里我們選擇 NFS 存儲的 StorageClass，直接使用前面創(chuàng)建的 StorageClass 即可。

修改 prometheus-prometheus.yaml文件:

vim prometheus/prometheus-prometheus.yaml

prometheus是一種 StatefulSet 有狀態(tài)集的部署模式，所以直接將 StorageClass 配置到里面，在下面的 yaml 中最下面添加持久化配置：

apiVersion: monitoring.coreos.com/v1 kind: Prometheus metadata: labels: prometheus: k8s name: k8s namespace: monitoring spec: alerting: alertmanagers: - name: alertmanager-main namespace: monitoring port: web image: quay.io/prometheus/prometheus:v2.20.0 nodeSelector: kubernetes.io/os: linux podMonitorNamespaceSelector: {} podMonitorSelector: {} replicas: 2 resources: requests: memory: 400Mi ruleSelector: matchLabels: prometheus: k8s role: alert-rules securityContext: fsGroup: 2000 runAsNonRoot: true runAsUser: 1000 serviceAccountName: prometheus-k8s serviceMonitorNamespaceSelector: {} serviceMonitorSelector: {} version: v2.20.0 storage: # 添加持久化配置，指定StorageClass volumeClaimTemplate: spec: storageClassName: nfs-storage-new # 指定 StorageClass resources: requests: storage: 10Gi

創(chuàng)建 grafana-pvc.yaml 文件

由于 Grafana 是部署模式為 Deployment，所以我們提前為其創(chuàng)建一個 grafana-pvc.yaml 文件，加入下面 PVC 配置。

kind: PersistentVolumeClaim apiVersion: v1 metadata: name: grafana namespace: monitoring #---指定namespace為monitoring spec: storageClassName: nfs-storage-new #---指定StorageClass accessModes: - ReadWriteOnce resources: requests: storage: 5Gi

修改 grafana-deployment.yaml 文件設置持久化配置，應用上面的 PVC：

vim grafana/grafana-deployment.yaml

將 volumes 里面的 “grafana-storage” 配置注掉，新增如下配置，掛載一個名為 grafana 的 PVC：

...... volumes: - name: grafana-storage # 新增持久化配置 persistentVolumeClaim: claimName: grafana # 設置為創(chuàng)建的PVC名稱 #- emptyDir: {} # 注釋掉舊的配置 # name: grafana-storage - name: grafana-datasources secret: secretName: grafana-datasources - configMap: name: grafana-dashboards name: grafana-dashboards ......

安裝Prometheus Operator

所有文件都在 manifests 目錄下執(zhí)行。

kubectl apply -f setup/

查看 Pod，等 pod 創(chuàng)建起來在進行下一步：

$ kubectl get pods -n monitoring NAME READY STATUS RESTARTS prometheus-operator-5d6f6f5d68-mb88p 1/1 Running 0

這會創(chuàng)建一個名為 monitoring 的命名空間，以及相關的 CRD 資源對象聲明和 Prometheus Operator 控制器。前面中我們介紹過 CRD 和 Operator 的使用，當我們聲明完 CRD 過后，就可以來自定義資源清單了，但是要讓我們聲明的自定義資源對象生效就需要安裝對應的 Operator 控制器，這里我們都已經(jīng)安裝了，所以接下來就可以來用 CRD 創(chuàng)建真正的自定義資源對象了。其實在 manifests 目錄下面的就是我們要去創(chuàng)建的 Prometheus、Alertmanager 以及各種監(jiān)控對象的資源清單。

沒有特殊的定制需求我們可以直接一鍵安裝：

kubectl apply -f adapter/ kubectl apply -f alertmanager/ kubectl apply -f node-exporter/ kubectl apply -f kube-state-metrics/ kubectl apply -f grafana/ kubectl apply -f prometheus/ kubectl apply -f serviceMonitor/

查看 Pod 狀態(tài)：

$ kubectl get pods -n monitoring NAME READY STATUS RESTARTS AGE alertmanager-main-0 2/2 Running 0 1h alertmanager-main-1 2/2 Running 0 1h alertmanager-main-2 2/2 Running 0 1h grafana-84db8f5cd8-7c6gt 1/1 Running 0 1h kube-state-metrics-69d4c7c69d-ldrwj 3/3 Running 0 1h node-exporter-btlb2 2/2 Running 0 1h node-exporter-k52kv 2/2 Running 0 1h node-exporter-m29nb 2/2 Running 0 1h node-exporter-ppdn4 2/2 Running 0 1h node-exporter-qnmrg 2/2 Running 0 1h node-exporter-w7hfx 2/2 Running 0 1h node-exporter-z2v7l 2/2 Running 0 1h prometheus-adapter-66b855f564-blqmb 1/1 Running 0 1h prometheus-k8s-0 3/3 Running 0 1h prometheus-k8s-1 3/3 Running 0 1h prometheus-operator-57859b8b59-rnxcj 2/2 Running 0 1h

查看 Prometheus & Grafana

查看 Prometheus

打開地址：http://node_ip:32101 查看 Prometheus 采集的目標，看其各個采集服務狀態(tài)有沒有錯誤。

可以看到已經(jīng)監(jiān)控上了很多指標數(shù)據(jù)了，上面我們可以看到 Prometheus 是兩個副本，我們這里通過 Service 去訪問，按正常來說請求是會去輪詢訪問后端的兩個 Prometheus 實例的，但實際上我們這里訪問的時候始終是路由到后端的一個實例上去，因為這里的 Service 在創(chuàng)建的時候添加了 SessionAffinity:ClientIP 這樣的屬性，會根據(jù) ClientIP 來做 Session 親和性，所以我們不用擔心請求會到不同的副本上去。

查看 Grafana

打開地址：http://node_ip:32102 查看 Grafana 圖表，看其 Kubernetes 集群是否能正常顯示。

默認用戶名：admin

默認密碼：admin

可以看到各種儀表盤：

小結(jié)

安裝 Prometheus 之后，我們就可以按照 Metrics 數(shù)據(jù)的來源，來對 Kubernetes 的監(jiān)控體系做一個簡要的概括：

第一種是宿主機（node）的監(jiān)控數(shù)據(jù)。這部分數(shù)據(jù)的提供，需要借助 Node Exporter 。一般來說，Node Exporter 會以 DaemonSet 的方式運行在宿主機上。其實，所謂的 Exporter，就是代替被監(jiān)控對象來對 Prometheus 暴露出可以被“抓取”的 Metrics 信息的一個輔助進程。而 Node Exporter 可以暴露給 Prometheus 采集的 Metrics 數(shù)據(jù)， 也不單單是節(jié)點的負載（Load）、CPU 、內(nèi)存、磁盤以及網(wǎng)絡這樣的常規(guī)信息，它的 Metrics 指標很豐富，具體你可以查看 Node Exporter 列表。

第二種是來自于 Kubernetes 的 API Server、kubelet 等組件的 /metrics API。除了常規(guī)的 CPU、內(nèi)存的信息外，這部分信息還主要包括了各個組件的核心監(jiān)控指標。比如，對于 API Server 來說，它就會在 /metrics API 里，暴露出各個 Controller 的工作隊列（Work Queue）的長度、請求的 QPS 和延遲數(shù)據(jù)等等。這些信息，是檢查 Kubernetes 本身工作情況的主要依據(jù)。

第三種是 Kubernetes 相關的監(jiān)控數(shù)據(jù)。這部分數(shù)據(jù)，一般叫作 Kubernetes 核心監(jiān)控數(shù)據(jù)（core metrics）。這其中包括了 Pod、Node、容器、Service 等主要 Kubernetes 核心概念的 Metrics。其中，容器相關的 Metrics 主要來自于 kubelet 內(nèi)置的 cAdvisor 服務。在 kubelet 啟動后，cAdvisor 服務也隨之啟動，而它能夠提供的信息，可以細化到每一個容器的 CPU 、文件系統(tǒng)、內(nèi)存、網(wǎng)絡等資源的使用情況。需要注意的是，這里提到的是 Kubernetes 核心監(jiān)控數(shù)據(jù)。

文章源碼：

https://github.com/zuozewei/blog-example/tree/master/Kubernetes/k8s-kube-promethues

參考資料：

[1]：《深入剖析Kubernetes》

Kubernetes

版權聲明：本文內(nèi)容由網(wǎng)絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發(fā)現(xiàn)本站中有涉嫌抄襲或描述失實的內(nèi)容，請聯(lián)系我們jiasou666@gmail.com 處理，核實后本網(wǎng)站將在24小時內(nèi)刪除侵權內(nèi)容。