现状

当我们的应用部署在k8s的环境中以后，日志的处理也会成为一个需要研究的课题。相比于传统的环境，日志会伴随着容器的重启而消失，解决方案目前有ELK(EFK)和持久卷。
先说一下持久卷的方案。在实现上一般通过hostpath和pv的形式。首先我们的应用在k8s环境是多副本的，所以如果不想所有的副本日志都打印在一个里面的话，就要求每个副本的日志文件的名字不一样。再者，日志的查看方式大致是首先定位到我们容器所在的主机，然后登陆上去相应的日志路径下去查看日志。
其实我觉得EL/FK的方案应该是比较好的方案，因为这方式在查看上是极其方便的，并且还支持搜索。最近我也搜集了一下网上k8s环境下上使用EL/FK的方案，大致都是如下：

上面的这个架构可以将日志都收集到ES并通过kibana展现给用户，但是这种方式将k8s集群的日志，业务日志，中间件的日志混杂在一个索引中，一方面不同的用户查询的时候需要写不同的查询语句，另一方面不能按照不同的场景做不同日志切割。

日志的分类

按照场景进行区分：

• k8s集群的日志
• 业务日志
• 系统日志主要是中间件的日志、数据库的日志

按照存在形式区分：

• 文件形式
• 控制台直接输出（也就是我们通过docker log或者kubectl log看到的日志）

我的方案

我的方案同样依赖于EF/LK,只不过需制定一些规范以及开发一些周边的工具，让EF/LK能更好的服务于各个角色，同时让我们能更充分的使用EF/LK提供给我们的功能。

对于部署在k8s中的程序，我们应该使用namespace、label、annotation来表示他的用途或者场景。这算是使用规范中的一部分，比如：
命名空间表示环境：

• Dev-xxx:开发环境
• Test-xxx: 测试环境
  label字段center表示应用所属的中心，比如
• center: number表示号码中心
• center: file 表示文件中心
  label字段module表示应用所属的模块，比如
• module:cron 表示定时任务模块等
  fluent就按照上面的规范把不同的日志转为了不同的topic，从而转为不同的ES的索引，这样我们不同的角色人员只需查阅自己感兴趣的索引就可以了，并且我们可以对不同的索引指定不同的模板，从而形成不同的切割策略。

fluent之所以分为不同的角色，是为了让不同角色的fluent负责功能，进而我们在扩容的时候为特定角色的fluent进行扩容。

不同形式的日志

• 对于直接终端打印的日志，fluent的过滤插件就可以将日志在k8s的worker节点上将数据抽取出来
• 对于我们打印成文件的日志。一种方案是我们在每个deployment中放一个filebeat或者fluent来抽取日志，这种方案将fluent和应用浑浊在一起了，不能单独对fluent进行扩容。正在考虑通过CRD将fluent独立出来，后边再把方案补充过来。

自己开发工具

我们可以开发一套工具用于日常维护，功能大概分为以下：
配置：

• fluent的扩容，配置下发，删除
• Kafa的topic创建，broker的扩容
• ES模板的创建
  监控：
• kafka消息的消费状况
• fluent的工作状况
  等等

---

以上是我的大致想法，欢迎大家留言讨论，谢谢大家