在很多的一段时间内, 业务一直都是使用单独的prometheus进行集群业务的监控,通过prometheus提供的服务发现能力, 在业务svc加入指定的annotations即可实现数据收集, 但还是会面临时常需要修改prometheus的配置文件(比如static scrape)，prometheus虽然也提供了配置热加载的能力, 久而久之也烦,如果能够实现配置的动态加载, 对运维人员无感操作, 是不是就方便地多, prometheus operator即可实现.
对于平台来说， 上面跑着若干产品线，prometheus operator能够将更多的自由度移位到业务侧, 比如抓取时间，超时时间等，同时也使得平台运维同事的工作量能够解脱出来.
最近kubernetes新上线了个服务,需要基于Kubernetes架构下压测一下该服务的性能, 之前用过ab, 但是ab还是相对简单了点, 网上调研了一番发现了jmeter这个由apache出品的压测工具,特别是报告非常清晰, 使用起来还挺简单.
虽然现业务架构上了kubernetes，因为历史遗留问题, 现在还存在着使用consul来做service discovery组件, 预计还得在生产中存在一段时间, 因此配上了Prometheus监控, 在部署过程中出现了一个Unsupported Media Type错
今天同事接到一个需求, 需求是这样的: 需要对接友商的系统(域名, 公网能够解析),但是友商系统有个白名单, 只有在白名单中的ip才能有权限访问, 这个ip应该是什么?
补充一下架构背景： 应用都是部署在kubernetes集群中的， kubernetes部署在阿里云ECS上. CNI使用的flannel
这么长时间跟kubernetes打交道, 还真没想过这个问题, 刚好可以测试一翻, 探探究竟
期间会涉及到CNI(container network interface)相关的话题,在这里不会做深入研究, 一笔带过.详细的学习记录在这里可以找到Kubernetes学习(flannel深入学习)
经过之前的对Istio的学习，大致明白了istio的机制,而要体会istio对流量的神奇魔法,自然离不开 virtualservice 与 destinationrule这两个对象了.
最近有个同事说他在测试kubernetes中跑spark，在运行spark-job时提示Invalid DER: object is not integer，但是如果在线上环境跑同样的任务就没问题, 束手无措，想让我帮看一下什么问题
Gateway在istio中是一个比较重要的对象, 一般用于管理南北流量，即集群外向集群内的访问及集群内需要访问集群外的这部分流量.
前面大致学习了下Istio的整体架构, 没有涉及它里面的细节, 这次主要说明一下istio是如何将请求进行转发的. 信息量确实比较大.