1、如果以sidecar或者打包到业务Image中以 “Per Pod Per Agent” 的方式部署, 那么基础组件的Server端的压力可能也会成倍增长。
2、业务容器中存在一些其它agent进程时，我们在为Pod申请资源(cpu/mem request and limit)时，不仅要考虑业务应用本身的资源消耗，还要考虑这些基础组件的资源消耗。而且一旦某些Agent有Bug，比如内存泄漏，这将导致Pod牵连被重建，甚至Cgroup OOM在kill进程时，可能将业务进程kill了。
违背了Kubernetes&微服务的部署最佳实践：Per Process Per Contaienr
3、假设一个Node上运行10个Pod，那么就会有x10的基础组件数量在Node上。没有容器化之前，一个Node只要部署一个组件进程即可，容器化之后，集群中组件Agents数量要几十倍的增长,如果业务进行了微服务拆分，这个指数会更大，这些基础组件服务端是否能承受比以往高几十倍上百倍的通信请求，都是要解决的大问题。
4、如果你要全网升级某个基础组件Agent，你需要重新打所有业务镜像，然后全网业务要进行灰度升级。因为一个Agent的升级，导致你不得不重建业务Pod。
将基础组件Agents从业务Pod中剥离，通过Kubernetes的容灾，热升级，负载均衡等特性来管理这些基础组件Agent。
场景：大数据量的业务pod日志采集
daemonset模式缺陷：假设以daemonset模式部署filebeat来采集此node上的日志
1、filebeat单个agent可能出现采集不及时，但是有些pod还没被采集到时就被删除了，导致日志采集缺失
2、每个pod的日志量不一样，有的大有的小，但是filebeat并不会知道哪个pod的日志多，哪个少，只会对每个日志文件启动一个go协程去watch并采集，这样导致日志量大的pod出现日志延迟
使用sidecar解决：
每个pod中部署一个sidecar容器来采集此pod的日志，这样采集时不会被其它pod影响，并且可以根据每个pod中业务容器的日志量情况来绝对其sidecar日志采集容器需要的资源量