在前一篇文章Fluentd性能优化实践中，我们的fluentd日志收集系统已经改成了多进程的方式。但是由于日志的不断增加，普通的单机部署方式也不能满足我们的需求，所以我们就打算把fluentd部署到k8s上，以满足不断增加的日志需求。
为什么需要部署到k8s上？
如下图所示，在多进程架构中，我们所有的out进程都是部署在同一台机器上，当日志量不断增多的时候，out进程数量就要不断增加，当增加到一定程度的时候，就会把out进程所在的这台机器的所有资源都用完，这时候我们就需要升级该机器，因此该架构的问题就暴露出来了。
该架构的主要问题是：
- 升级的过程需要手动操作，升级过程比较繁琐
- 单台机器的性能不可能无限的增长
- 资源不能动态的调整，如果机器升级只是为了应付某个波峰的话，会造成性能浪费
怎么部署到k8s上？
由于我们每个fluentd进程的buffer都会使用file的方式，所以我们的fluentd进程是有状态的，因此我们在k8s上部署的时候采用statefulset的部署方式。新的日志收集架构图如下所示：
使用该架构后以上的单机问题就没有了，当日志量不断增加的时候，在k8s集群上面我们可以一直增加out进程的数量而不会受到单机性能的限制，甚至我们还可以让fluentd的out进程的数量根据实际的资源使用情况来自动的伸缩。
总结
这篇文章的内容比较简单，但是实实在在为我们解决了一个大问题，让我们在每次日志内容增多的时候都能从容应对。同时应用容器化是一件非常值得做的事情，build once run everywhere，可以避免很多不必要的问题，同时在替换一些基础依赖的时候也非常方便。
