希望长大对我而言，是可以做更多想做的事，而不是被迫做更多不想做的事...... 首页

k8s日志解决方案

丁D
学无止境
2019-11-14 09:53
37260已阅读

k8s 日志

摘要在微服务盛行的年代，传统的应用日志解决方案已经不在适用了，本文就将容器化的微服务日志解决方案这个课题进行详细的介绍。

### 一、传统日志解决方案
在以前我们的应用日志一般由log4j输入到不同的文件中，比如info.log warn.log  error.log。
然后当我们需要查看日志的时候，就需要登录服务器使用命令`tail -fn 500 error.log`进行查看。

### 二、微服务日志解决方案
近年来微服务越来越火爆，微服务虽然带来一些好处，但是也引入了日志收集的问题。一般来说，我们可能将服务部署在容器中，然后使用k8s进行编排。这样的话服务被部署到那个node我们是不知道的，我们也不可能登陆所有的服务器一一去查看日志。所以我们需要将日志收集并进行统一的存储和查看。k8s推荐使用EFK，对日志进行收集，存储，查看，现在我们就3种常见的日志解决方案进行讲解。
#### 在Node部署logstash（Fluentd）
在容器中输出到控制台的日志，都会被以*-sjson.log的命名方式保存到宿主机的/var/lib/docker/containers/目录下，这就为我们这个日志采集提供了基础。

k8s推荐使用Fluentd+Elasticsearch+Kibana。

我们可以在每个node上面部署一个Fluentd，然后将日志收集转发到远端的ElasticSearch里保存起来供将来进行检索

![](/upload/微信图片_20191114104453.png)

**好处**：
1）一个宿主机只需要部署一个日志收集器可以是Fluentd也可以是logstash
2）不会对应用和pod有任何入侵性。

**这个方案在社区里是最常用的一种**

**缺点**：
1）应用日志必须输出到控制台，不然收集不到
2）一个log agent收集多个pod的日志，不好进行分类存储
3）容器停了，日志就清空了（需要验证一下）

当然我们也可以使用在将文件写在容器的某个目录，然后将该目录挂载到node中，然后使用ELk等去收集
缺点是：：日志文件占用磁盘空间

#### 在pod新增日志收集容器sidecar，将应用日志重定向输出stdout和stderr
当我们的应用将日志输出到文件中的时候，我们只要登录容器中查看日志才能看到到的，使用kubect这种命令是看不到的，所以我们想办法将文件里面的日志，重定向到控制台输出。

我们可以在pod部署两个容器，一个是应用本身，一个是sidecar，应用将日志写入文件中，比如error.log，  sidecar则负责将文件的日志转到控制台输出。这样的话我们就可以继续用上一个方案，统一收集，存储。

![](/upload/微信图片_20191114104500.png)

缺点：
1）由于pod里面的容器是共用Volume，所以这个方案性能损耗并不高，就是多占了点cpu，内存
2）磁盘浪费，保存了两份日志文件，一：容器中应用输出的日志文件，二：重定向输出到控制台，宿主机保存的日志

**不到万不得已，一般不使用这个方案**