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

2020-08-23 本文已影响0人 SongRijie

上一篇提到了为什么选用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进行修改，后面再讲。

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

猜你喜欢

热点阅读