在开始这篇文章之前,首先要明确一点: Kubernetes 中对容器日志的处理方式,都叫做 cluster-level-logging ,也就是说,这个日志处理系统,与容器, Pod 以及 Node 的生命周期都是完全无关的.其实想想也能知道,这种设计就是为了保证,无论是容器宕了, Pod 被删除甚至是节点宕机的时候,日志处理系统仍然可以被正常获取到,从而可以分析原因所在.
而对于一个容器来说,当应用把日志输出到 stdout 和 stderr 之后,容器项目在默认情况下,就会把这些日志输出到宿主机上的一个 JSON 文件中,这样,我就能够通过 kubectl logs 命令,来查看到这些容器的日志.
但是你要明白一点,那就是 Kubernetes 本身,实际上是不会做容器日志收集工作的,所以为了能够实现上述 cluster-level-logging ,就需要在部署集群的时候,就提前对具体的日志方案进行规划.所幸, Kubernetes 项目本身提供了三种相关方案.
接下来分别讲一讲.
| 第一种 |
在 Node 上部署 logging agent ,将日志文件转发到后端存储里保存起来.这个方案的架构图如下所示:
从中我们能够看到,这里的核心在于 logging agent ,它一般都会以 DaemonSet 的方式运行在节点上,然后将宿主机上的容器日志目录挂载进去,最后由 logging-agent 把日志转发出去.那么,这样一来,我只需要在一个节点上部署一个 agent 即可,这样也不会对应用和 Pod 有任何侵入性.
但是这种方案,要求应用输出的日志,都必须是直接输出到容器的 stdout 和 stderr 中.
这也就引出了第二种解决方案.
| 第二种 |
第二种情况,主要就是对上面所述缺点的一个处理,即:当容器的日志只能输出到某些文件中时,可以通过一个 sidecar 容器将这些日志文件重新输出到 sidecar 的 stdout 和 stderr 中.
这种解决方案的架构图如下:
因为 sidecar 和主容器之间是共享 Volume 的,所以这里的 sidecar 方案的额外性能损耗并不高,只不过是多用了一点儿 CPU 和内存罢了.
但是要了解一点,这种方案下,宿主机上会存在两份相同的日志文件:一份是应用自己写入的,另外一份则是 sidecar 的 stdout 和 stderr 对应的 JSON 文件.这样就会造成对磁盘的巨大浪费.
所以,如果不是万不得已,也不是应用容器完全不可能被修改,还是建议使用方案一,或者使用下面介绍的方案三.
当然了,土豪随意,毕竟开心才是重要的.
| 第三种 |
第三种方案,就是通过 sidecar 容器,直接将应用的日志文件发送到远程存储里面去.也就是,方案一中的 logging agent ,放在应用 Pod 中.继续上一张架构图:
在这种方案下,应用可以直接把日志输出到固定的文件中,而不是 stdout , logging-agent 还可以使用 fluentd ,后端存储还可以是 ElasticSearch .
这种方案,部署简单,对宿主机也非常友好,但是这个 sidecar 容器,很有可能会消耗比较多的资源,甚至会拖垮应用容器,此外,由于日志没有输出到 stdout 上面,所以就算你通过命令 kubectl logs 来查看,也是看不到任何日志输出到.
以上就是关于容器日志的收集与管理的三种方案的介绍了.
有一点需要注意的是,不管到最后选择什么方案,到最后,一定要及时将这些日志文件,从宿主机上清理掉,或者给日志目录文件专门挂载一些容量巨大的远程盘.要不然,一旦磁盘分区被打满,整个系统就可能会陷入崩溃状态,这样造成的损失就大多了.
以上内容来自我学习<深入剖析Kubernetes>专栏文章之后的一些见解,有偏颇之处,还望指出.
感谢您的阅读~