做开发的同学都知道日志的重要性，日志的种类一般有接口日志、错误日志、关键步骤日志、用户操作日志等。本文首要详细讲解运用kubernetes容器化布置的服务该如何记载和收集日志。

一、运用标准输出方法

将想要记载的日志内容输出到stdout或stderr即可（DockerEngine本身具有LogDriver 功用，可经过配置不同的LogDriver将容器的stdout经过DockerEngine写入到日志体系），由DockerEngine将日志写入到日志体系。

这种方法的长处是运用简单，可是缺陷也十分明显。所有的输出都混在一个流中，无法像文件一样分类输出，一个应用中一般都有几种类型的日志，这些日志的格局、用处不一，混在同一个流中将很难做分类和分析。

虽然运用Stdout是Docker官方引荐的方法，可是仅限于简单的场景。这种方法可定制化、灵活性、资源隔离性都比较差，一般不主张在出产环境中运用。

二、服务直写方法

在服务代码中将日志直接发送到日志体系（集成所运用日志体系的SDK或者自己实现SDK）。

这种方法的长处是日志文件不需求暂时存储到磁盘，也不需求布置额定的日志收集Agent，可根据事务特点进行定制，不受集群规模限制。

缺陷是日志直写会占用一定的服务器资源，例如cpu、内存、特别是网络IO，会影响服务的整体功能。

经过修正Deployment文件使服务容器和宿主机同享一个目录，服务将日志输出这个目录下面。运用DaemonSet方法在每个node节点上面运转一个日志收集agent（例如filebeat、fluentd、logstash等）收集这个节点上指定目录下的所有日志文件到日志体系。

这种方法的长处资源相对占用要小许多，也可以做到日志分类收集，日志收集简直不影响服务的功能。缺陷是扩展性受限。

经过修正Deployment文件在一个pod里面运转两个容器，一个容器运转服务，另一个容器运转日志收集agent，而且让这两个容器同享同一个目录，服务将日志输出这个目录下面，日志收集agent收集这个目录下的所有的日志文件到日志体系。

这种方法的长处是日志收集容器和事务服务容器是独立的，体系资源不会相互影响，灵活性强，不受集群规模限制。

缺陷是资源相对占用较多，由于针对每一个服务都要布置一个独立的agent容器，运维成本也相对较高。

本文详细讲解了收集kubernetes容器化布置的服务日志的四种方法，每种方法都有优缺陷和对应的运用场景，需求根据实践场景挑选最合适的方法。