应用容器化后，建议日志是落盘后再采集还是直接通过网络发到外部呢？

容器日志收集有三种方案：

第一种，在 Node 上部署 logging agent，将日志文件转发到后端存储里保存起来， 这里的核心就在于 logging agent ，它一般都会以 DaemonSet 的方式运行在节点 上，然后将宿主机上的容器日志目录挂载进去，最后由 logging-agent 把日志转发出去。举个例子，我们可以通过 Fluentd 项目作为宿主机上的 logging-agent，然后把日志转发到远 端的 ElasticSearch 里保存起来供将来进行检索。
在 Node 上部署 logging agent 最大的优点，在于一个节点只需要部署一个 agent，并且不会对应用和 Pod 有任何侵入性。所以，这个方案，在社区里是最常用的一种。 但是也不难看到，这种方案的不足之处就在于，它要求应用输出的日志，都必须是直接输出到容 器的 stdout 和 stderr 里。

所以， Kubernetes 容器日志方案的第二种，就是对这种特殊情况的一个处理，即:当容器的日 志只能输出到某些文件里的时候，我们可以通过一个 sidecar 容器把这些日志文件重新输出到 sidecar 的 stdout 和 stderr 上，这样就能够继续使用第一种方案了。 在这种情况下，你用 kubectl logs 命令是看不到应用的任何日志的。而且最常用的方案一，也是没办法使用的。那么这个时候，我们就可以为这个 Pod 添加两个 sidecar 容器，分别将上述两个日志文件里的内容重新以 stdout 和 stderr 的方式输出出来。 这时候，你就可以通过 kubectl logs 命令查看这两个 sidecar 容器的日志，间接看到应用的日 志内容了。 由于 sidecar 跟主容器之间是共享 Volume 的，所以这里的 sidecar 方案的额外性能损耗并不 高，也就是多占用一点 CPU 和内存罢了。但需要注意的是，这时候，宿主机上实际上会存在两份相同的日志文件:一份是应用自己写入 的;另一份则是 sidecar 的 stdout 和 stderr 对应的 JSON 文件。这对磁盘是很大的浪费。所 以说，除非万不得已或者应用容器完全不可能被修改，否则我还是建议你直接使用方案一，或者 直接使用下面的第三种方案。

第三种方案，就是通过一个 sidecar 容器，直接把应用的日志文件发送到远程存储里面去。 也就是相当于把方案一里的 logging agent，放在了应用 Pod 里。 在这种方案里，你的应用还可以直接把日志输出到固定的文件里而不是 stdout，你的 logging- agent 还可以使用 fluentd，后端存储还可以是 ElasticSearch。只不过， fluentd 的输入源， 变成了应用的日志文件。一般来说，我们会把 fluentd 的输入源配置保存在一个 ConfigMap 里。 Fluentd 容器使用的输入源，就是通过引用这个 ConfigMap 来指定的。 需要注意的是，这种方案虽然部署简单，并且对宿主机非常友好，但是这个 sidecar 容器很可能 会消耗较多的资源，甚至拖垮应用容器。并且，由于日志还是没有输出到 stdout 上，所以你通 过 kubectl logs 是看不到任何日志输出的。

综合对比以上三种方案，我比较建议你将应用日志输出到 stdout 和 stderr，然后通过在宿主机上部署 logging-agent 的方式来集中处理日志。这种方案不仅管理简单，kubectl logs 也可以用，而且可靠性高，并且宿主机本身，很可能就 自带了 rsyslogd 等非常成熟的日志收集组件来供你使用。除此之外，还有一种方式就是在编写应用的时候，就直接指定好日志的存储后端，在这种方案下，Kubernetes 就完全不必操心容器日志的收集了，这对于本身已经有完善的日志 处理系统的公司来说，是一个非常好的选择。

最后需要指出的是，无论是哪种方案，你都必须要及时将这些日志文件从宿主机上清理掉，或者给日志目录专门挂载一些容量巨大的远程盘。否则，一旦主磁盘分区被打满，整个系统就可能会陷入奔溃状态，这是非常麻烦的。