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