做开发的同学都知道日志的重要性，日志的种类一般有接口日志、错误日志、关键步骤日志、用户操作日志等。本文主要详细讲解使用kubernetes容器化部署的服务该如何记录和收集日志。
一、使用标准输出方式
将想要记录的日志内容输出到stdout或stderr即可（DockerEngine本身具有LogDriver 功能，可通过配置不同的LogDriver将容器的stdout通过DockerEngine写入到日志系统），由DockerEngine将日志写入到日志系统。
这种方式的优点是使用简单，但是缺点也十分明显。所有的输出都混在一个流中，无法像文件一样分类输出，一个应用中一般都有几种类型的日志，这些日志的格式、用途不一，混在同一个流中将很难做分类和分析。
虽然使用Stdout是Docker官方推荐的方式，但是仅限于简单的场景。这种方式可定制化、灵活性、资源隔离性都比较差，一般不建议在生产环境中使用。
二、服务直写方式
在服务代码中将日志直接发送到日志系统（集成所使用日志系统的SDK或者自己实现SDK）。
这种方式的优点是日志文件不需要临时存储到磁盘，也不需要部署额外的日志采集Agent，可根据业务特点进行定制，不受集群规模限制。
缺点是日志直写会占用一定的服务器资源，例如cpu、内存、特别是网络IO，会影响服务的整体性能。
三、DaemonSet方式
通过修改Deployment文件使服务容器和宿主机共享一个目录，服务将日志输出这个目录下面。使用DaemonSet方式在每个node节点上面运行一个日志采集agent（例如filebeat、fluentd、logstash等）采集这个节点上指定目录下的所有日志文件到日志系统。
这种方式的优点资源相对占用要小很多，也可以做到日志分类采集，日志采集几乎不影响服务的性能。缺点是扩展性受限。
四、Sidecar 方式
通过修改Deployment文件在一个pod里面运行两个容器，一个容器运行服务，另一个容器运行日志采集agent，并且让这两个容器共享同一个目录，服务将日志输出这个目录下面，日志采集agent采集这个目录下的所有的日志文件到日志系统。
这种方式的优点是日志采集容器和业务服务容器是独立的，系统资源不会相互影响 ，灵活性强，不受集群规模限制。
缺点是资源相对占用较多，因为针对每一个服务都要部署一个独立的agent容器，运维成本也相对较高。
小结
本文详细讲解了采集kubernetes容器化部署的服务日志的四种方法，每种方法都有优缺点和对应的使用场景，需要根据实际场景选择最合适的方式。
