从kube-prometheus定制k8s监控(二) 部署kube-prometheus

上一篇提到了为什么选用Prometheus Operator作k8s监控，相比于单部署Prometheus的区别。 而对于监控来说，仅仅有工具是远远不够的。 还需要高可用部署，定义收集的数据，监控指标，图标呈现等等， 这就要提到kube-prometheus。

kube-prometheus 是个很“贴心”的项目，它本来是Prometheus Operator的一部分，后来分离出来独立发布。 除了定义部署，还整合了一些外部项目，包括指标的创建，监控规则的定义，监控图表创建等等，把对k8s集群通用的监控标准化，达到“开箱即用”的效果。

这个项目用jsonnet维护。 jsonnet是一个模板语言，用来生成json文件，可以方便维护配置。因为k8s的配置习惯用yaml保存， 生成的json又用了一个golang工具gojsontoyaml转了一下格式。

项目生成的yaml保存在manifest/目录下，这些文件也被提交到了repo。 对于没有定制要求的使用者，可以直接用manifest/中的配置。 这里需要注意兼容性， 项目里维护了几个分支，对应k8s的不同版本，要根据实际情况选择。 比如我们运行1.16，选择release-0.4。

manifest/有个子目录，manifest/setup/保存的是namespace和CRD，需要先创建，生效之后再创建manifest/中的内容。 把repo 克隆下来，执行下面命令：

cd kube-prometheus
kubectl create -f manifests/setup
until kubectl get servicemonitors --all-namespaces ; do date; sleep 1; echo ""; done
kubectl create -f manifests/

它会做如下工作：

• 一个新的表空间monitoring
• Prometheus Operator和相关的CRD
• 两节点的Prometheus服务
• 三节点的Alert Manager服务
• 每个节点上部署node-exporter
• 提供k8s相关指标的服务
• 单节点grafana和通用的dashboard
• 一些通用的监控告警规则
• 上述服务间的整合及传输加密

运行成功后，monitoring下应该有下面资源：

# kubectl get pod -nmonitoring
NAME                                   READY   STATUS    RESTARTS   AGE
alertmanager-main-0                    2/2     Running   0          85d
alertmanager-main-1                    2/2     Running   0          85d
alertmanager-main-2                    2/2     Running   0          85d
grafana-8499b48c69-wlrq2               1/1     Running   0          10d
kube-state-metrics-6f856648b9-gt9hq    3/3     Running   0          109d
node-exporter-2vhqr                    2/2     Running   0          109d
node-exporter-66hq7                    2/2     Running   0          109d
node-exporter-9xzzw                    2/2     Running   0          109d
node-exporter-bqjqs                    2/2     Running   0          109d
node-exporter-br4bd                    2/2     Running   0          109d
node-exporter-mc24r                    2/2     Running   0          109d
node-exporter-vm7h2                    2/2     Running   0          109d
prometheus-adapter-54d6dfd87b-k6dqg    1/1     Running   0          109d
prometheus-k8s-0                       3/3     Running   0          85d
prometheus-k8s-1                       3/3     Running   0          85d
prometheus-operator-76878f58ff-lpd56   1/1     Running   0          109d

# kubectl get svc -nmonitoring
NAME                    TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)                      AGE
alertmanager-main       ClusterIP   182.25.245.53    <none>        9093/TCP                     109d
alertmanager-operated   ClusterIP   None             <none>        9093/TCP,9094/TCP,9094/UDP   109d
grafana                 ClusterIP   182.24.76.224    <none>        3000/TCP                     109d
kube-state-metrics      ClusterIP   None             <none>        8443/TCP,9443/TCP            109d
node-exporter           ClusterIP   None             <none>        9100/TCP                     109d
prometheus-adapter      ClusterIP   182.17.98.210    <none>        443/TCP                      109d
prometheus-k8s          ClusterIP   182.21.148.119   <none>        9090/TCP                     109d
prometheus-operated     ClusterIP   None             <none>        9090/TCP                     109d
prometheus-operator     ClusterIP   None             <none>        8080/TCP                     109d

Prometheus，Alert Manager和grafana的web访问分别对应几个service：

• prometheus-k8s.monitoring.svc:9090
• alertmanager-main.monitoring.svc:9093
• grafana.monitoring.svc:3000

具体的访问方法要根据集群的实际情况配置。 用默认admin/admin登录grafana，能看到一组dashboard。

grafana-dashboard-list.png

compute-cluster.png

访问alert manager的UI，查看告警：

alertManager.png

默认情况下，Prometheus会自动创建一个Watchdog的告警，每4小时发送一次。 目的是为了告知接受告警的客户端，告警发送系统正常运转。如果不需要就用Silence条件匹配将其关闭。

默认的配置可能遇到几个问题：

• 所有用到的image都从源地址获取。 如果集群用内部仓库，不能访问外网，拉取会失败。即使能对外访问，dockerhub和gcr都不容易。
• Prometheus的数据并没有持久化。
• Alert Manager和grafana都是默认配置，告警无法发送出来。

除此以外，如果还想把集群中运行的所有服务都整合到统一的监控体系中，就需要对kube-prometheus进行定制化，后面再讲。

有疑问加站长微信联系（非本文作者）