01 引言
为了在Kubernetes能够方便的管理和部署Prometheus，我们使用ConfigMap管理Prometheus配置文件。
如果每次对Prometheus配置文件进行升级时，我们需要手动移除已经运行的Pod实例，从而让Kubernetes可以使用最新的配置文件创建Prometheus，当应用实例的数量更多时，通过手动的方式部署和升级Prometheus过程繁琐并且效率低下。
问题：从本质上来讲Prometheus属于是典型的有状态应用，而其有包含了一些自身特有的运维管理和配置管理方式，而这些都无法通过Kubernetes原生提供的应用管理概念实现自动化。
解决方案：为了简化这类应用程序的管理复杂度，CoreOS率先引入了Operator的概念，并且首先推出了针对在Kubernetes下运行和管理Etcd的Etcd Operator，并随后推出了Prometheus Operator。
02 初识Prometheus Operator
2.1 什么是Prometheus Operator?
Operator：就是针对管理特定应用程序的，在Kubernetes基本的Resource和Controller的概念上，以扩展Kubernetes api的形式，帮助用户创建，配置和管理复杂的有状态应用程序，从而实现特定应用程序的常见操作以及运维自动化。
在Kubernetes中我们使用:
- Deployment、DamenSet，StatefulSet来管理应用Workload；
- 使用Service，Ingress来管理应用的访问方式；
- 使用ConfigMap和Secret来管理应用配置；
- 在集群中对这些资源的创建，更新，删除的动作都会被转换为事件(Event)，Kubernetes的Controller Manager负责监听这些事件并触发相应的任务来满足用户的期望。这种方式我们成为声明式，用户只需要关心应用程序的最终状态，其它的都通过Kubernetes来帮助我们完成，通过这种方式可以大大简化应用的配置管理复杂度。
实现核心点：除了这些原生的Resource资源以外，Kubernetes还允许用户添加自己的自定义资源(Custom Resource)，并且通过实现自定义Controller来实现对Kubernetes的扩展。
如下所示，是Prometheus Operator的架构示意图：
上图有两个概念：
- Prometheus：本质就是一组用户自定义的CRD资源以及Controller的实现。
- Prometheus Operator负责监听这些自定义资源的变化，并且根据这些资源的定义自动化的完成如Prometheus Server自身以及配置的自动化管理工作。
2.2 Prometheus Operator能做什么？
要了解Prometheus Operator能做什么，其实就是要了解Prometheus Operator为我们提供了哪些自定义的Kubernetes资源，列出了Prometheus Operator目前提供的️4类资源：
- Prometheus：声明式创建和管理Prometheus Server实例；
- ServiceMonitor：负责声明式的管理监控配置；
- PrometheusRule：负责声明式的管理告警配置；
- Alertmanager：声明式的创建和管理Alertmanager实例。
简言之，Prometheus Operator能够帮助用户自动化的创建以及管理Prometheus Server以及其相应的配置。
03 在Kubernetes集群中部署Prometheus Operator
3.1 下载
在Kubernetes中安装Prometheus Operator非常简单，用户可以从以下地址中过去Prometheus Operator的源码：
git clone https://github.com/coreos/prometheus-operator.git
3.2 配置
这里，我们为Promethues Operator创建一个单独的命名空间monitoring：
kubectl create namespace monitoring
由于需要对Prometheus Operator进行RBAC授权，而默认的bundle.yaml中使用了default命名空间，因此，在安装Prometheus Operator之前需要先替换一下bundle.yaml文件中所有namespace定义，由default修改为monitoring，通过运行以下命令安装Prometheus Operator的Deployment实例：
$ kubectl -n monitoring apply -f bundle.yaml clusterrolebinding.rbac.authorization.k8s.io/prometheus-operator created clusterrole.rbac.authorization.k8s.io/prometheus-operator created deployment.apps/prometheus-operator created serviceaccount/prometheus-operator created service/prometheus-operator created
Prometheus Operator通过Deployment的形式进行部署，目的是让Prometheus Operator能够监听和管理Kubernetes资源同时也创建了单独的ServiceAccount以及相关的授权动作。
查看Prometheus Operator部署状态，以确保已正常运行：
$ kubectl -n monitoring get pods NAME READY STATUS RESTARTS AGE prometheus-operator-6db8dbb7dd-2hz55 1/1 Running 0 19s
04 Prometheus Operator的使用
4.1 Operator管理Prometheus
4.1.1 创建Prometheus实例
当集群中已经安装Prometheus Operator之后，对于部署Prometheus Server实例就变成了声明一个Prometheus资源，如下所示，我们在Monitoring命名空间下创建一个Prometheus实例：
apiVersion: monitoring.coreos.com/v1 kind: Prometheus metadata: name: inst namespace: monitoring spec: resources: requests: memory: 400Mi
将以上内容保存到prometheus-inst.yaml文件，并通过kubectl进行创建：
$ kubectl create -f prometheus-inst.yaml prometheus.monitoring.coreos.com/inst-1 created
此时，查看monitoring命名空间下的statefulsets资源，可以看到Prometheus Operator自动通过Statefulset创建的Prometheus实例：
$ kubectl -n monitoring get statefulsets NAME DESIRED CURRENT AGE prometheus-inst 1 1 1m
查看Pod实例：
$ kubectl -n monitoring get pods NAME READY STATUS RESTARTS AGE prometheus-inst-0 3/3 Running 1 1m prometheus-operator-6db8dbb7dd-2hz55 1/1 Running 0 45m
通过port-forward访问Prometheus实例:
$ kubectl -n monitoring port-forward statefulsets/prometheus-inst 9090:9090
通过http://localhost:9090可以在本地直接打开Prometheus Operator创建的Prometheus实例，查看配置信息，可以看到目前Operator创建了只包含基本配置的Prometheus实例：
4.1.2 使用ServiceMonitor管理监控配置
修改监控配置项也是Prometheus下常用的运维操作之一，为了能够自动化的管理Prometheus的配置，Prometheus Operator使用了 自定义资源类型ServiceMonitor 来描述监控对象的信息。
这里我们首先在集群中部署一个示例应用，将以下内容保存到example-app.yaml，并使用kubectl命令行工具创建：
apiVersion: extensions/v1beta1 kind: Deployment metadata: name: example-app spec: replicas: 3 template: metadata: labels: app: example-app spec: containers: - name: example-app image: fabxc/instrumented_app ports: - name: web containerPort: 8080
示例应用会通过Deployment创建3个Pod实例:
$ kubectl get pods NAME READY STATUS RESTARTS AGE example-app-94c8bc8-l27vx 2/2 Running 0 1m example-app-94c8bc8-lcsrm 2/2 Running 0 1m example-app-94c8bc8-n6wp5 2/2 Running 0 1m
实例对象通过Service暴露应用访问信息
kind: Service apiVersion: v1 metadata: name: example-app labels: app: example-app spec: selector: app: example-app ports: - name: web port: 8080
在本地同样通过port-forward访问任意Pod实例:
$ kubectl port-forward deployments/example-app 8080:8080
访问本地的http://localhost:8080/metrics实例应用程序会返回以下样本数据：
# TYPE codelab_api_http_requests_in_progress gauge codelab_api_http_requests_in_progress 3 # HELP codelab_api_request_duration_seconds A histogram of the API HTTP request durations in seconds. # TYPE codelab_api_request_duration_seconds histogram codelab_api_request_duration_seconds_bucket{method="GET",path="/api/bar",status="200",le="0.0001"} 0
为了能够让Prometheus能够采集部署在Kubernetes下应用的监控数据，在原生的Prometheus配置方式中，我们在Prometheus配置文件中定义单独的Job，同时使用kubernetes_sd定义整个服务发现过程。
而在Prometheus Operator中，则可以直接声明一个ServiceMonitor对象，如下所示：
apiVersion: monitoring.coreos.com/v1 kind: ServiceMonitor metadata: name: example-app namespace: monitoring labels: team: frontend spec: namespaceSelector: matchNames: - default selector: matchLabels: app: example-app endpoints: - port: web
通过定义selector中的标签定义选择监控目标的Pod对象，同时在endpoints中指定port名称为web的端口。默认情况下ServiceMonitor和监控对象必须是在相同Namespace下的。
在本示例中由于Prometheus是部署在Monitoring命名空间下，因此为了能够关联default命名空间下的example对象，需要使用namespaceSelector定义让其可以跨命名空间关联ServiceMonitor资源。
保存以上内容到example-app-service-monitor.yaml文件中，并通过kubectl创建：
$ kubectl create -f example-app-service-monitor.yaml servicemonitor.monitoring.coreos.com/example-app created
如果希望ServiceMonitor可以关联任意命名空间下的标签，则通过以下方式定义：
spec: namespaceSelector: any: true
如果监控的Target对象启用了BasicAuth认证，那在定义ServiceMonitor对象时，可以使用endpoints配置中定义basicAuth如下所示：
apiVersion: monitoring.coreos.com/v1 kind: ServiceMonitor metadata: name: example-app namespace: monitoring labels: team: frontend spec: namespaceSelector: matchNames: - default selector: matchLabels: app: example-app endpoints: - basicAuth: password: name: basic-auth key: password username: name: basic-auth key: user port: web
其中basicAuth中关联了名为basic-auth的Secret对象，用户需要手动将认证信息保存到Secret中:
apiVersion: v1 kind: Secret metadata: name: basic-auth data: password: dG9vcg== # base64编码后的密码 user: YWRtaW4= # base64编码后的用户名 type: Opaque
4.1.3 关联Promethues与ServiceMonitor
为了能够让Prometheus关联到ServiceMonitor，需要在Pormtheus定义中使用serviceMonitorSelector，我们可以通过标签选择当前Prometheus需要监控的ServiceMonitor对象，修改prometheus-inst.yaml中Prometheus的定义如下所示：
apiVersion: monitoring.coreos.com/v1 kind: Prometheus metadata: name: inst namespace: monitoring spec: serviceMonitorSelector: matchLabels: team: frontend resources: requests: memory: 400Mi
将对Prometheus的变更应用到集群中：
$ kubectl -n monitoring apply -f prometheus-inst.yaml
此时，如果查看Prometheus配置信息，我们会惊喜的发现Prometheus中配置文件自动包含了一条名为monitoring/example-app/0的Job配置：
global: scrape_interval: 30s scrape_timeout: 10s evaluation_interval: 30s external_labels: prometheus: monitoring/inst prometheus_replica: prometheus-inst-0 alerting: alert_relabel_configs: - separator: ; regex: prometheus_replica replacement: $1 action: labeldrop rule_files: - /etc/prometheus/rules/prometheus-inst-rulefiles-0/*.yaml scrape_configs: - job_name: monitoring/example-app/0 scrape_interval: 30s scrape_timeout: 10s metrics_path: /metrics scheme: http kubernetes_sd_configs: - role: endpoints namespaces: names: - default relabel_configs: - source_labels: [__meta_kubernetes_service_label_app] separator: ; regex: example-app replacement: $1 action: keep - source_labels: [__meta_kubernetes_endpoint_port_name] separator: ; regex: web replacement: $1 action: keep - source_labels: [__meta_kubernetes_endpoint_address_target_kind, __meta_kubernetes_endpoint_address_target_name] separator: ; regex: Node;(.*) target_label: node replacement: ${1} action: replace - source_labels: [__meta_kubernetes_endpoint_address_target_kind, __meta_kubernetes_endpoint_address_target_name] separator: ; regex: Pod;(.*) target_label: pod replacement: ${1} action: replace - source_labels: [__meta_kubernetes_namespace] separator: ; regex: (.*) target_label: namespace replacement: $1 action: replace - source_labels: [__meta_kubernetes_service_name] separator: ; regex: (.*) target_label: service replacement: $1 action: replace - source_labels: [__meta_kubernetes_pod_name] separator: ; regex: (.*) target_label: pod replacement: $1 action: replace - source_labels: [__meta_kubernetes_service_name] separator: ; regex: (.*) target_label: job replacement: ${1} action: replace - separator: ; regex: (.*) target_label: endpoint replacement: web action: replace
不过，如果细心的读者可能会发现，虽然Job配置有了，但是Prometheus的Target中并没包含任何的监控对象。查看Prometheus的Pod实例日志，可以看到如下信息：
level=error ts=2018-12-15T12:52:48.452108433Z caller=main.go:240 component=k8s_client_runtime err="github.com/prometheus/prometheus/discovery/kubernetes/kubernetes.go:300: Failed to list *v1.Endpoints: endpoints is forbidden: User \"system:serviceaccount:monitoring:default\" cannot list endpoints in the namespace \"default\""
4.1.4 自定义ServiceAccount
由于默认创建的Prometheus实例使用的是monitoring命名空间下的default账号，该账号并没有权限能够获取default命名空间下的任何资源信息。
为了修复这个问题，我们需要在Monitoring命名空间下为创建一个名为Prometheus的ServiceAccount，并且为该账号赋予相应的集群访问权限。
apiVersion: v1 kind: ServiceAccount metadata: name: prometheus namespace: monitoring --- apiVersion: rbac.authorization.k8s.io/v1beta1 kind: ClusterRole metadata: name: prometheus rules: - apiGroups: [""] resources: - nodes - services - endpoints - pods verbs: ["get", "list", "watch"] - apiGroups: [""] resources: - configmaps verbs: ["get"] - nonResourceURLs: ["/metrics"] verbs: ["get"] --- apiVersion: rbac.authorization.k8s.io/v1beta1 kind: ClusterRoleBinding metadata: name: prometheus roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: prometheus subjects: - kind: ServiceAccount name: prometheus namespace: monitoring
将以上内容保存到prometheus-rbac.yaml文件中，并且通过kubectl创建相应资源：
$ kubectl -n monitoring create -f prometheus-rbac.yaml serviceaccount/prometheus created clusterrole.rbac.authorization.k8s.io/prometheus created clusterrolebinding.rbac.authorization.k8s.io/prometheus created
在完成ServiceAccount创建后，修改prometheus-inst.yaml，并添加ServiceAccount如下所示：
apiVersion: monitoring.coreos.com/v1 kind: Prometheus metadata: name: inst namespace: monitoring spec: serviceAccountName: prometheus serviceMonitorSelector: matchLabels: team: frontend resources: requests: memory: 400Mi
保存Prometheus变更到集群中：
$ kubectl -n monitoring apply -f prometheus-inst.yaml prometheus.monitoring.coreos.com/inst configured
等待Prometheus Operator完成相关配置变更后，此时查看Prometheus，我们就能看到当前Prometheus已经能够正常的采集实例应用的相关监控数据了。
4.2 Operator管理监控配置
4.2.1 使用Prometheus Rule定义告警规则
对于Prometheus而言，在原生的管理方式上，我们需要手动创建Prometheus的告警文件，并且通过在Prometheus配置中声明式的加载。
而在Prometheus Operator模式中，告警规则也编程一个通过Kubernetes API 声明式创建的一个资源，如下所示：
apiVersion: monitoring.coreos.com/v1 kind: PrometheusRule metadata: labels: prometheus: example role: alert-rules name: prometheus-example-rules spec: groups: - name: ./example.rules rules: - alert: ExampleAlert expr: vector(1)
将以上内容保存为example-rule.yaml文件，并且通过kubectl命令创建相应的资源：
$ kubectl -n monitoring create -f example-rule.yaml prometheusrule "prometheus-example-rules" created
告警规则创建成功后，通过在Prometheus中使用ruleSelector通过选择需要关联的PrometheusRule即可：
apiVersion: monitoring.coreos.com/v1 kind: Prometheus metadata: name: inst namespace: monitoring spec: serviceAccountName: prometheus serviceMonitorSelector: matchLabels: team: frontend ruleSelector: matchLabels: role: alert-rules prometheus: example resources: requests: memory: 400Mi
Prometheus重新加载配置后，从UI中我们可以查看到通过PrometheusRule自动创建的告警规则配置：
如果查看Alerts页面，我们会看到告警已经处于触发状态。
4.2.2 使用Operator管理Alertmanager实例
到目前为止，我们已经通过Prometheus Operator的自定义资源类型管理了Promtheus的实例，监控配置以及告警规则等资源；通过Prometheus Operator将原本手动管理的工作全部变成声明式的管理模式，大大简化了Kubernetes下的Prometheus运维管理的复杂度。
接下来，我们将继续使用Promtheus Operator定义和管理Alertmanager相关的内容。为了通过Prometheus Operator管理Alertmanager实例，用户可以通过自定义资源Alertmanager进行定义，如下所示，通过replicas可以控制Alertmanager的实例数：
apiVersion: monitoring.coreos.com/v1 kind: Alertmanager metadata: name: inst namespace: monitoring spec: replicas: 3
当replicas大于1时，Prometheus Operator会自动通过集群的方式创建Alertmanager。将以上内容保存为文件alertmanager-inst.yaml，并通过以下命令创建：
$ kubectl -n monitoring create -f alertmanager-inst.yaml alertmanager.monitoring.coreos.com/inst created
查看Pod的情况如下所示，我们会发现Alertmanager的Pod实例一直处于ContainerCreating的状态中:
$ kubectl -n monitoring get pods NAME READY STATUS RESTARTS AGE alertmanager-inst-0 0/2 ContainerCreating 0 32s
通过kubectl describe命令查看该Alertmanager的Pod实例状态，可以看到类似于以下内容的告警信息：
MountVolume.SetUp failed for volume "config-volume" : secrets "alertmanager-inst" not found
这是由于Prometheus Operator通过Statefulset的方式创建的Alertmanager实例，在默认情况下，会通过alertmanager-{ALERTMANAGER_NAME}的命名规则去查找Secret配置并以文件挂载的方式，将Secret的内容作为配置文件挂载到Alertmanager实例当中。
因此，这里还需要为Alertmanager创建相应的配置内容，如下所示，是Alertmanager的配置文件：
global: resolve_timeout: 5m route: group_by: ['job'] group_wait: 30s group_interval: 5m repeat_interval: 12h receiver: 'webhook' receivers: - name: 'webhook' webhook_configs: - url: 'http://alertmanagerwh:30500/'
将以上内容保存为文件alertmanager.yaml，并且通过以下命令创建名为alrtmanager-inst的Secret资源：
$ kubectl -n monitoring create secret generic alertmanager-inst --from-file=alertmanager.yaml secret/alertmanager-inst created
在Secret创建成功后，查看当前Alertmanager Pod实例状态。如下所示：
$ kubectl -n monitoring get pods NAME READY STATUS RESTARTS AGE alertmanager-inst-0 2/2 Running 0 5m alertmanager-inst-1 2/2 Running 0 52s alertmanager-inst-2 2/2 Running 0 37s
使用port-forward将Alertmanager映射到本地：
$ kubectl -n monitoring port-forward statefulsets/alertmanager-inst 9093:9093
访问http://localhost:9093/#/status，并查看当前集群状态：
接下来，我们只需要修改我们的Prometheus资源定义，通过alerting指定使用的Alertmanager资源即可：
apiVersion: monitoring.coreos.com/v1 kind: Prometheus metadata: name: inst namespace: monitoring spec: serviceAccountName: prometheus serviceMonitorSelector: matchLabels: team: frontend ruleSelector: matchLabels: role: alert-rules prometheus: example alerting: alertmanagers: - name: alertmanager-example namespace: monitoring port: web resources: requests: memory: 400Mi
等待Prometheus重新加载后，我们可以看到Prometheus Operator在配置文件中添加了以下配置：
alertmanagers: - kubernetes_sd_configs: - role: endpoints namespaces: names: - monitoring scheme: http path_prefix: / timeout: 10s relabel_configs: - source_labels: [__meta_kubernetes_service_name] separator: ; regex: alertmanager-example replacement: $1 action: keep - source_labels: [__meta_kubernetes_endpoint_port_name] separator: ; regex: web replacement: $1 action: keep
通过服务发现规则将Prometheus与Alertmanager进行了自动关联。
4.3 在Operator中使用自定义配置
在Prometheus Operator我们通过声明式的创建如Prometheus, ServiceMonitor这些自定义的资源类型来自动化部署和管理Prometheus的相关组件以及配置。
而在一些特殊的情况下，对于用户而言，可能还是希望能够手动管理Prometheus配置文件，而非通过Prometheus Operator自动完成。 为什么？
- 实际上Prometheus Operator对于Job的配置只适用于在Kubernetes中部署和管理的应用程序。如果你希望使用Prometheus监控一些其他的资源，例如AWS或者其他平台中的基础设施或者应用，这些并不在Prometheus Operator的能力范围之内。
为了能够在通过Prometheus Operator创建的Prometheus实例中使用自定义配置文件，我们只能创建一个不包含任何与配置文件内容相关的Prometheus实例：
apiVersion: monitoring.coreos.com/v1 kind: Prometheus metadata: name: inst-cc namespace: monitoring spec: serviceAccountName: prometheus resources: requests: memory: 400Mi
将以上内容保存到prometheus-inst-cc.yaml文件中，并且通过kubectl创建:
$ kubectl -n monitoring create -f prometheus-inst-cc.yaml prometheus.monitoring.coreos.com/inst-cc created
如果查看新建Prometheus的Pod实例YAML定义，我们可以看到Pod中会包含一个volume配置：
volumes: - name: config secret: defaultMode: 420 secretName: prometheus-inst-cc
Prometheus的配置文件实际上是保存在名为prometheus-<name-of-prometheus-object>的Secret中，当用户创建的Prometheus中关联ServiceMonitor这类会影响配置文件内容的定义时，Promethues Operator会自动管理。
而如果Prometheus定义中不包含任何与配置相关的定义，那么Secret的管理权限就落到了用户自己手中。通过修改prometheus-inst-cc的内容，从而可以让用户可以使用自定义的Prometheus配置文件，作为示例，我们创建一个prometheus.yaml文件并添加以下内容：
global: scrape_interval: 10s scrape_timeout: 10s evaluation_interval: 10s
生成文件内容的base64编码后的内容：
$ cat prometheus.yaml | base64 Z2xvYmFsOgogIHNjcmFwZV9pbnRlcnZhbDogMTBzCiAgc2NyYXBlX3RpbWVvdXQ6IDEwcwogIGV2YWx1YXRpb25faW50ZXJ2YWw6IDEwcw==
修改名为prometheus-inst-cc的Secret内容，如下所示：
$ kubectl -n monitoring edit secret prometheus-inst-cc # 省略其它内容 data: prometheus.yaml: "Z2xvYmFsOgogIHNjcmFwZV9pbnRlcnZhbDogMTBzCiAgc2NyYXBlX3RpbWVvdXQ6IDEwcwogIGV2YWx1YXRpb25faW50ZXJ2YWw6IDEwcw=="
通过port-forward在本地访问新建的Prometheus实例，观察配置文件变化即可：
kubectl -n monitoring port-forward statefulsets/prometheus-inst-cc 9091:9090
05 文末
本文主要讲解了在Kubernetes下如何使用Operator来有状态的运维和管理Prometheus以及Alertmanager等组件，希望能对大家有所启发，谢谢大家的阅读。
