上一篇提到了为什么选用Prometheus Operator作k8s的监控，以及相比于单部署Prometheus的区别。 而对于监控来说，仅仅有工具是不够的。 还需要高可用部署，定义收集的数据，监控指标，图标呈现等等， 这就要说到kube-prometheus。
kube-prometheus 把k8s集群的通用监控标准化，达到“开箱即用”的效果，是个很“贴心”的项目。它本来是Prometheus Operator的一部分，后来分离出来独立发布。
这个项目用jsonnet维护。 jsonnet是一个模板语言，用来生成json文件，大多用来维护配置。k8s的配置大家习惯用yaml保存， 所以生成的json又用了一个golang工具gojsontoyaml转了一下格式，保存在manifest/目录下。项目原生的配置文件也被提交到了repo，所以对于没有定制要求的使用者，直接用manifest/下的文件就够了。
这里需要注意兼容性， 项目里维护了几个分支，对应k8s的不同版本，要根据实际情况选择，这点参见README.md。 比如我们运行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这个namepace应该有下面资源：
# 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 172.25.245.53 <none> 9093/TCP 109d
alertmanager-operated ClusterIP None <none> 9093/TCP,9094/TCP,9094/UDP 109d
grafana ClusterIP 172.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 172.17.98.210 <none> 443/TCP 109d
prometheus-k8s ClusterIP 172.21.148.119 <none> 9090/TCP 109d
prometheus-operated ClusterIP None <none> 9090/TCP 109d
prometheus-operator ClusterIP None <none> 8080/TCP 109d
组件web的访问分别对应几个service：
-
Prometheus:prometheus-k8s.monitoring.svc:9090 -
Alert Manager:alertmanager-main.monitoring.svc:9093 -
Grafana: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进行修改，后面再讲。
网友评论