"本文主要讲解在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集群模式下三种日志收集模式,结合实际使用场景采用不同的日志收集方案满足具体需求。
推荐阅读:
Kubernetes中如何使用ClusterDNS进行服务发现?
从Ice到Kubernetes容器技术,微服务架构经历了什么?
原创不易,随手关注或者”在看“,诚挚感谢!