特此说明：本篇时基于prometheus-operator官网提供的kube-prometheus原生包进行部署的，由于我的k8s集群为1.18.0版本，考虑到对原生的兼容性，发现官方从release-0.5已经开始支持k8s1.18了，但是在实际使用中我使用的最新版本安装包并没有报错。
参考链接：https://zhuanlan.zhihu.com/p/100406234
1. 简介
随着云原生概念盛行，对于容器、服务、节点以及集群的监控变得越来越重要。Prometheus 作为 Kubernetes 监控的事实标准，有着强大的功能和良好的生态。但是它不支持分布式，不支持数据导入、导出，不支持通过 API 修改监控目标和报警规则，所以在使用它时，通常需要写脚本和代码来简化操作。Prometheus Operator 为监控 Kubernetes service、deployment 和 Prometheus 实例的管理提供了简单的定义，简化在 Kubernetes 上部署、管理和运行 Prometheus 和 Alertmanager 集群。
Prometheus Operator (后面都简称 Operater) 提供如下功能：
- 创建/销毁：在 Kubernetes namespace 中更加容易地启动一个 Prometheues实例，一个特定应用程序或者团队可以更容易使用 Operator。
- 便捷配置：通过 Kubernetes 资源配置 Prometheus 的基本信息，比如版本、存储、副本集等。
- 通过标签标记目标服务： 基于常见的 Kubernetes label 查询自动生成监控目标配置；不需要学习 Prometheus 特定的配置语言。
2. 架构
上面架构图中，各组件以不同的方式运行在 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 运行时一直与定义保持一致。
3. Prometheus Operater 定义了如下的四类自定义资源：
- Prometheus
- ServiceMonitor
- Alertmanager
- PrometheusRule
3.1 Prometheus
- Prometheus 自定义资源（CRD）声明了在 Kubernetes 集群中运行的 Prometheus
的期望设置。包含了副本数量，持久化存储，以及 Prometheus 实例发送警告到的 Alertmanagers等配置选项。 - 每一个 Prometheus 资源，Operator 都会在相同 namespace 下部署成一个正确配置的
StatefulSet，Prometheus 的 Pod 都会挂载一个名为 的
Secret，里面包含了 Prometheus 的配置。Operator 根据包含的 ServiceMonitor
生成配置，并且更新含有配置的 Secret。无论是对 ServiceMonitors 或者 Prometheus
的修改，都会持续不断的被按照前面的步骤更新。
3.2 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 必须为空。
3.3 Alertmanager
- Alertmanager 自定义资源(CRD)声明在 Kubernetes 集群中运行的 Alertmanager
的期望设置。它也提供了配置副本集和持久化存储的选项。 - 每一个 Alertmanager 资源，Operator 都会在相同 namespace 下部署成一个正确配置的
StatefulSet。Alertmanager pods 配置挂载一个名为 的 Secret，
使用 alertmanager.yaml key 对作为配置文件。
3.4 PrometheusRule
- PrometheusRule CRD 声明一个或多个 Prometheus 实例需要的 Prometheus rule。
- Alerts 和 recording rules 可以保存并应用为 yaml 文件，可以被动态加载而不需要重启。
4. 部署kube-prometheus
4.1 下载并解压
github地址：https://github.com/prometheus-operator/kube-prometheus
cd /root/pkg && mkdir k8s_prometheus
wget https://github.com/prometheus-operator/kube-prometheus/archive/refs/heads/main.zip
unzip main.zip -d k8s_prometheus
cd k8s_prometheus/kube-prometheus-main
cd manifests
4.2 部署
cd /root/pkg/k8s_prometheus/kube-prometheus-main
kubectl create -f manifests/setup #等执行完后通过kubectl get servicemonitors --all-namespaces查看都创建完成后在执行下一步
kubectl get servicemonitors --all-namespaces #创建完成后在执行下一步
kubectl create -f manifests/
4.3 监控访问
访问prometheus web端
访问alertmanager web端
访问grafana web端
添加数据源
导入模板
5. 遗留的问题
5.1 告警规则优化和告警媒介收发
5.2 Prometheus的持久化
