Prometheus Operator 的安裝

 Prometheus Operator 的安裝

接下來咱們用自定義的方式來對 Kubernetes 集羣進行監控，可是仍是有一些缺陷，好比 Prometheus、AlertManager 這些組件服務自己的高可用，固然咱們也徹底能夠用自定義的方式來實現這些需求，咱們也知道 Promethues 在代碼上就已經對 Kubernetes 有了原生的支持，能夠經過服務發現的形式來自動監控集羣，所以咱們可使用另一種更加高級的方式來部署 Prometheus：Operator 框架。

Operator

Operator是由CoreOS公司開發的，用來擴展 Kubernetes API，特定的應用程序控制器，它用來建立、配置和管理複雜的有狀態應用，如數據庫、緩存和監控系統。Operator基於 Kubernetes 的資源和控制器概念之上構建，但同時又包含了應用程序特定的一些專業知識，好比建立一個數據庫的Operator，則必須對建立的數據庫的各類運維方式很是瞭解，建立Operator的關鍵是CRD（自定義資源）的設計。

CRD是對 Kubernetes API 的擴展，Kubernetes 中的每一個資源都是一個 API 對象的集合，例如咱們在YAML文件裏定義的那些spec都是對 Kubernetes 中的資源對象的定義，全部的自定義資源能夠跟 Kubernetes 中內建的資源同樣使用 kubectl 操做。

Operator是將運維人員對軟件操做的知識給代碼化，同時利用 Kubernetes 強大的抽象來管理大規模的軟件應用。目前CoreOS官方提供了幾種Operator的實現，其中就包括咱們今天的主角：Prometheus Operator，Operator的核心實現就是基於 Kubernetes 的如下兩個概念：

• 資源：對象的狀態定義
• 控制器：觀測、分析和行動，以調節資源的分佈

固然咱們若是有對應的需求也徹底能夠本身去實現一個Operator，接下來咱們就來給你們詳細介紹下Prometheus-Operator的使用方法。

介紹

首先咱們先來了解下Prometheus-Operator的架構圖：

promtheus opeator

上圖是Prometheus-Operator官方提供的架構圖，其中Operator是最核心的部分，做爲一個控制器，他會去建立Prometheus、ServiceMonitor、AlertManager以及PrometheusRule4個CRD資源對象，而後會一直監控並維持這4個資源對象的狀態。

其中建立的prometheus這種資源對象就是做爲Prometheus Server存在，而ServiceMonitor就是exporter的各類抽象，exporter前面咱們已經學習了，是用來提供專門提供metrics數據接口的工具，Prometheus就是經過ServiceMonitor提供的metrics數據接口去 pull 數據的，固然alertmanager這種資源對象就是對應的AlertManager的抽象，而PrometheusRule是用來被Prometheus實例使用的報警規則文件。

這樣咱們要在集羣中監控什麼數據，就變成了直接去操做 Kubernetes 集羣的資源對象了，是否是方便不少了。上圖中的 Service 和 ServiceMonitor 都是 Kubernetes 的資源，一個 ServiceMonitor 能夠經過 labelSelector 的方式去匹配一類 Service，Prometheus 也能夠經過 labelSelector 去匹配多個ServiceMonitor。

安裝

咱們這裏直接經過 Prometheus-Operator 的源碼來進行安裝，固然也能夠用 Helm 來進行一鍵安裝，咱們採用源碼安裝能夠去了解更多的實現細節。首頁將源碼 Clone 下來：

$ git clone https://github.com/coreos/kube-prometheus.git $ cd manifests $ ls 00namespace-namespace.yaml node-exporter-clusterRole.yaml 0prometheus-operator-0alertmanagerCustomResourceDefinition.yaml node-exporter-daemonset.yaml ...... 

最新的版本官方將資源https://github.com/coreos/prometheus-operator/tree/master/contrib/kube-prometheus遷移到了獨立的 git 倉庫中：https://github.com/coreos/kube-prometheus.git

進入到 manifests 目錄下面，這個目錄下面包含咱們全部的資源清單文件，咱們須要對其中的文件 prometheus-serviceMonitorKubelet.yaml 進行簡單的修改，由於默認狀況下，這個 ServiceMonitor 是關聯的 kubelet 的10250端口去採集的節點數據，而咱們前面說過爲了安全，這個 metrics 數據已經遷移到10255這個只讀端口上面去了，咱們只須要將文件中的https-metrics更改爲http-metrics便可，這個在 Prometheus-Operator 對節點端點同步的代碼中有相關定義，感興趣的能夠點此查看完整代碼：

Subsets: []v1.EndpointSubset{ { Ports: []v1.EndpointPort{ { Name: "https-metrics", Port: 10250, }, { Name: "http-metrics", Port: 10255, }, { Name: "cadvisor", Port: 4194, }, }, }, }, 

修改完成後，直接在該文件夾下面執行建立資源命令便可：

$ kubectl apply -f . 

部署完成後，會建立一個名爲monitoring的 namespace，因此資源對象對將部署在改命名空間下面，此外 Operator 會自動建立4個 CRD 資源對象：

$ kubectl get crd |grep coreos alertmanagers.monitoring.coreos.com 5d prometheuses.monitoring.coreos.com 5d prometheusrules.monitoring.coreos.com 5d servicemonitors.monitoring.coreos.com 5d 

能夠在 monitoring 命名空間下面查看全部的 Pod，其中 alertmanager 和 prometheus 是用 StatefulSet 控制器管理的，其中還有一個比較核心的 prometheus-operator 的 Pod，用來控制其餘資源對象和監聽對象變化的：

$ kubectl get pods -n monitoring
NAME                                  READY     STATUS    RESTARTS   AGE
alertmanager-main-0                   2/2       Running   0          21h
alertmanager-main-1                   2/2       Running   0          21h
alertmanager-main-2                   2/2       Running   0          21h
grafana-df9bfd765-f4dvw               1/1       Running   0          22h
kube-state-metrics-77c9658489-ntj66   4/4       Running   0          20h
node-exporter-4sr7f                   2/2       Running   0          21h
node-exporter-9mh2r                   2/2       Running   0          21h
node-exporter-m2gkp                   2/2       Running   0          21h
prometheus-adapter-dc548cc6-r6lhb     1/1       Running   0          22h
prometheus-k8s-0                      3/3       Running   1          21h
prometheus-k8s-1                      3/3       Running   1          21h
prometheus-operator-bdf79ff67-9dc48   1/1       Running   0          21h

查看建立的 Service:

kubectl get svc -n monitoring
NAME                    TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S) AGE alertmanager-main ClusterIP 10.110.204.224 <none> 9093/TCP 23h alertmanager-operated ClusterIP None <none> 9093/TCP,6783/TCP 23h grafana ClusterIP 10.98.191.31 <none> 3000/TCP 23h kube-state-metrics ClusterIP None <none> 8443/TCP,9443/TCP 23h node-exporter ClusterIP None <none> 9100/TCP 23h prometheus-adapter ClusterIP 10.107.201.172 <none> 443/TCP 23h prometheus-k8s ClusterIP 10.107.105.53 <none> 9090/TCP 23h prometheus-operated ClusterIP None <none> 9090/TCP 23h prometheus-operator ClusterIP None <none> 8080/TCP 23h 

能夠看到上面針對 grafana 和 prometheus 都建立了一個類型爲 ClusterIP 的 Service，固然若是咱們想要在外網訪問這兩個服務的話能夠經過建立對應的 Ingress 對象或者使用 NodePort 類型的 Service，咱們這裏爲了簡單，直接使用 NodePort 類型的服務便可，編輯 grafana 和 prometheus-k8s 這兩個 Service，將服務類型更改成 NodePort:

$ kubectl edit svc grafana -n monitoring
$ kubectl edit svc prometheus-k8s -n monitoring
$ kubectl get svc -n monitoring
NAME                    TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S) AGE grafana NodePort 10.98.191.31 <none> 3000:32333/TCP 23h prometheus-k8s NodePort 10.107.105.53 <none> 9090:30166/TCP 23h ...... 

更改完成後，咱們就能夠經過去訪問上面的兩個服務了，好比查看 prometheus 的 targets 頁面：

promtheus operator targets

配置

咱們能夠看到大部分的配置都是正常的，只有兩三個沒有管理到對應的監控目標，好比 kube-controller-manager 和 kube-scheduler 這兩個系統組件，這就和 ServiceMonitor 的定義有關係了，咱們先來查看下 kube-scheduler 組件對應的 ServiceMonitor 資源的定義：(prometheus-serviceMonitorKubeScheduler.yaml)

apiVersion: monitoring.coreos.com/v1 kind: ServiceMonitor metadata: labels: k8s-app: kube-scheduler name: kube-scheduler namespace: monitoring spec: endpoints: - interval: 30s # 每30s獲取一次信息 port: http-metrics # 對應service的端口名 jobLabel: k8s-app namespaceSelector: # 表示去匹配某一命名空間中的service，若是想從全部的namespace中匹配用any: true matchNames: - kube-system selector: # 匹配的 Service 的labels，若是使用mathLabels，則下面的全部標籤都匹配時纔會匹配該service，若是使用matchExpressions，則至少匹配一個標籤的service都會被選擇 matchLabels: k8s-app: kube-scheduler 

上面是一個典型的 ServiceMonitor 資源文件的聲明方式，上面咱們經過selector.matchLabels在 kube-system 這個命名空間下面匹配具備k8s-app=kube-scheduler這樣的 Service，可是咱們系統中根本就沒有對應的 Service，因此咱們須要手動建立一個 Service：（prometheus-kubeSchedulerService.yaml）

apiVersion: v1 kind: Service metadata: namespace: kube-system name: kube-scheduler labels: k8s-app: kube-scheduler spec: selector: component: kube-scheduler ports: - name: http-metrics port: 10251 targetPort: 10251 protocol: TCP 

10251是kube-scheduler組件 metrics 數據所在的端口，10252是kube-controller-manager組件的監控數據所在端口。

其中最重要的是上面 labels 和 selector 部分，labels 區域的配置必須和咱們上面的 ServiceMonitor 對象中的 selector 保持一致，selector下面配置的是component=kube-scheduler，爲何會是這個 label 標籤呢，咱們能夠去 describe 下 kube-scheduelr 這個 Pod：

$ kubectl describe pod kube-scheduler-master -n kube-system
Name:         kube-scheduler-master
Namespace:    kube-system
Node:         master/10.151.30.57
Start Time:   Sun, 05 Aug 2018 18:13:32 +0800
Labels:       component=kube-scheduler tier=control-plane ...... 

咱們能夠看到這個 Pod 具備component=kube-scheduler和tier=control-plane這兩個標籤，而前面這個標籤具備更惟一的特性，因此使用前面這個標籤較好，這樣上面建立的 Service 就能夠和咱們的 Pod 進行關聯了，直接建立便可：

$ kubectl create -f prometheus-kubeSchedulerService.yaml
$ kubectl get svc -n kube-system -l k8s-app=kube-scheduler NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE kube-scheduler ClusterIP 10.102.119.231 <none> 10251/TCP 18m 

建立完成後，隔一小會兒後去 prometheus 查看 targets 下面 kube-scheduler 的狀態：

promethus kube-scheduler error

咱們能夠看到如今已經發現了 target，可是抓取數據結果出錯了，這個錯誤是由於咱們集羣是使用 kubeadm 搭建的，其中 kube-scheduler 默認是綁定在127.0.0.1上面的，而上面咱們這個地方是想經過節點的 IP 去訪問，因此訪問被拒絕了，咱們只要把 kube-scheduler 綁定的地址更改爲0.0.0.0便可知足要求，因爲 kube-scheduler 是以靜態 Pod 的形式運行在集羣中的，因此咱們只須要更改靜態 Pod 目錄下面對應的 YAML 文件便可：

$ ls /etc/kubernetes/manifests/ etcd.yaml kube-apiserver.yaml kube-controller-manager.yaml kube-scheduler.yaml 

將 kube-scheduler.yaml 文件中-command的--address地址更改爲0.0.0.0：

containers: - command: - kube-scheduler - --leader-elect=true - --kubeconfig=/etc/kubernetes/scheduler.conf - --address=0.0.0.0 

修改完成後咱們將該文件從當前文件夾中移除，隔一下子再移回該目錄，就能夠自動更新了，而後再去看 prometheus 中 kube-scheduler 這個 target 是否已經正常了：

promethues-operator-kube-scheduler

你們能夠按照上面的方法嘗試去修復下 kube-controller-manager 組件的監控。

上面的監控數據配置完成後，如今咱們能夠去查看下 grafana 下面的 dashboard，一樣使用上面的 NodePort 訪問便可，第一次登陸使用 admin:admin 登陸便可，進入首頁後，能夠發現已經和咱們的 Prometheus 數據源關聯上了，正常來講能夠看到一些監控圖表了：

promethues-operator-grafana