Kubernetes和prometheus以及alert manager使用总结

0，前言

在很早的时候写了一篇博客，主要介绍了dockers和kubernetes的简单使用，这里主要说一下高级的用法。

1,背景：

使用prometheus+alertmanager做告警需求，在告警规则curd后，需要将其应用。

2,方案：

使用当curd后，添加触发，通知应用程序解析规则，并应用到configmap，通过configmap可以挂载到prometheus的pod中，这时可以使用reload，热更新prometheus和alertmanager，使用这些规则。

1，可行性分析

1，configmap可以支持挂在到pod内，并且删除configmap的时候，并不会将挂载到pod内的文件删除，因此可以在规则变化后，删除configmap，并创建一个新的，这时会将新的文件挂载到pod内。

2，在pod内支持使用kubernetes client，这里可以直接使用kubernetes提供的官方client，在容器内操作容器外的集群。

3，使用kubernetes client操作集群的时候，需要提供node上kubernetes集群的配置文件，在这里root/.kube/config，这个可以使用dockerfile的功能做，也就是dokcerfile先执行一个脚本，将家目录下的config文件，复制到当前目录下，然后再使用copy或者add命令，添加到镜像中。（为什么这样做呢？是因为add或者copy命令的的src文件必须要在当前文件夹下，然后dsc是镜像中的位置）

3.1要注意的点是，config文件中的server host这一项，如果是再master上执行，需要首先通过etcdctl member list获取到可以使用的ip，然后替换掉127.0.0.1，这一步操作可以在业务中操作，也可以使用bash脚本做。

2，实施过程中遇到的问题

1，使用kubernetes client操作configmap的时候，提示找不到api version对应的configmap，这里可以手动添加一下，至于为什么在pod内执行会出问题，我也不是很清楚，client.add(“api/v1”, Configmap.class);

2，alertmanger默认的时区是UTC, 所以会比GMT+8慢八个小时，所以在使用alertmanager的silence功能时，时间的转换需要先使用GMT+8操作，然后再转换为UTC时间，再调用api。

3，关于prometheus的存储，如果有条件，可是使用nfs，如果仅仅做测试，可以直接使用hostpath的方式，如果是生产环境，建议使用自定义一个storageclass，然后使用pv和pvc，这样是可以动态申请存储大小的。

4，关于Prometheus的数据。需要注意的点是，如果自己的项目中没有用到的一些指标，就不要采集可以使用relabel_configs或者metric_relabel_configs，使用action为drop就可以不采集了，区别是relabel_config直接不采集，metric_relabel_configs是采集而不存储，同时对于一些不想要的标签，可以使用labeldrop这样的action进行丢弃。从而减少要存储的数据量。

5，对于存储数据的时间，默认是20d，20天，这里可以根据自己的业务场景需求更改，如果这里需要保存很久，建议使用外部第三方存储，不然数据太大node可能会炸。

3，具体的实施细节

1，如果想要知道具体实施的细节，可以参考《Prometheus技术秘笈》和《Prometheus监控实战》以及《Kubernetes in Action》

2，其实这些东西都是来自于kubernetes in action，这本书，所以其实如果大家想深入的学习高级用法，建议可以直接阅读此书。

3，如果大家有什么问题，也可以交流讨论。就在帖子下边回复就可以。