架构： k8s(1.10.12) + prometheus-operator(v0.20.0)的方式对pod进行监控
使用过prometheus-operator的同学都知道，prometheus-operator是通过自定义资源serviceMonitor ,serviceMonitor通过serivce标签找到对应的pod ，然后将所需监控的pod信息存入到prometheus配置文件当中，关系如下图所示
然而问题来了，突然有一天创建了serviceMonitor 以后，prometheus的配置文件并没有改变，并且在prometheus 的 target页面找不到对应新增的 service
因为k8s集群有一定规模，仅创建的serviceMonitor数量大概有500多个，楼主就想到会不会是所需监控的pod数量太多从而导致prometheus-operator无法进行更新，于是扩大了prometheus-operator的内存并重启，发现于事无补
随即查看prometheus-operator的日志，提示secret数据太长
楼主开始查阅相关资料，在Stack Overflow 发现有人提到在k8s中secret和confingmap的大小限制只有1m内存，结合上边prometheus-operator的日志，基本可以证实这一点了
这样看来，就是因为所需监控的pod太多了，operator生成的配置文件太大，超过了k8s secret的限制从而导致无法生成新的配置同步到prometheus
查看prometheus-operator的yaml文件
从上图可以看到，刚好是prometheus-config-reloader这个组建引用了secret,进入prometheus-config-reloader容器内部查看挂载点的文件
既然知道了原因，并且找到了secret的引用，楼主尝试将secret修改为pvc方式，测试Prometheus是否能启动
第一步：创建一个pvc，将生成的secret文件拷贝到pvc的宿主机挂载点，并且赋予777权限
第二步：更改名为 prometheus-k8s 的 statefulsets
查看prometheus已经全部启动完成
