"本文主要讲解在kubernetes集群环境下日志收集组件选型及方案"
1、需求来源
在大规模集群部署的场景下，容器实例会部署到多个节点上，节点以及节点上的应用产生的日志会随之分散在各个容器的主机上，传统的集群应用大多在本地持久化，这给整个应用系统的日志监控和故障排除带来了很大的挑战，而在Kubernetes大规模集群环境下，需要考虑把分散在各个节点上的日志统一采集，统一管理，统一展示。
2、日志来源
- 主机内核日志
主机内核产生的错误日志通常可以帮助开发者诊断因为主机或者OS异常而带来的服务异常，比如网络异常，文件系统异常等。
- 核心组件日志
docker的日志帮助用户查看pod内部容器的运行状态、APIServer的日志，Scheduler产生的日志能够帮助用户查看Kubernetes本身运行产生的日志。
- 应用自身日志
通常业务升级或者在某种场景下出现异常，可以通过日志进行排查。
3、日志收集方式
- 宿主机文件
Pod应用的数据存储在宿主机文件系统中，比如我们通过hostpath声明把业务日志存储在某个目录下，通常会在每个节点上以DaemonSet形式部署fluentd或者filebeat，将宿主机的文件系统挂载到fluentd或者filebeat Pod中内进行采集，当然我们也可以采集其它日志（操作系统产生日志，Kubernetes组件产生日志等）如下图所示：
- 容器内的文件
一种sidecar的日志收集模式，将日志收集容器和应用容器部署在同一个pod中，通过共享volume的形式实现对容器日志的收集，然后输出到节点上，这种收集一般针对日志准确性要求比较高的应用，通过这种方式我们可以定制当前容器内的文件名、pod的ip等。如下图所示：
- 容器内直接输出
Pod应用直接将数据存储在共享文件系统中（NFS、hdfs、ceph、GlusterFS等）。nfs日志存储使用介绍 这种情况下我们可以直接在当前文件系统中查看日志，或者在存储日志所在节点部署日志收集pod，把日志传输到日志系统。如下图所示：
4、日志收集存储实例
日志存储和查询方面比较建议使用ELK（logstash耗费资源较多，建议换成filebeat或者fluentd进行日志收集传递）成熟解决方案，因为ES原生支持多租户的使用场景，支持通过建立不同的索引方式来区分不同用户，不同业务类型的数据; fluentd在启动后会根据配置文件中的logstash_prefix，在ES中生成指定前缀的索引，在Kibana界面创建显示索引时，可以根据之前日志前缀设定匹配和监控产生日志数据，如下图所示：
针对大规模的持续增长的应用业务日志，在传统单机业务模式下会存储固定几天的数据，在万物互联的今天，我们不但需要快速实时的监控集群中的日志数据，更需要将这些数据进行持久化存储，方便我们基于这些数据进行数据挖掘、统计、分析建模或者根据用户的行为日志做预测工作，当然这些工作我们可以使用大数据分析解决方案（hadoop spark）对数据进行具体分析管理。
5、总结
本次主要介绍了Kubernetes集群模式下三种日志收集模式，结合实际使用场景采用不同的日志收集方案满足具体需求。
