关于kubernetes:简述Kubernetes容器日志收集原理

概述

对于容器日志

Docker 的日志分为两类，一类是 Docker 引擎日志；另一类是容器日志。引擎日志个别都交给了系统日志，不同的操作系统会放在不同的地位。本文次要介绍容器日志，容器日志能够了解是运行在容器外部的利用输入的日志，默认状况下，docker logs 显示以后运行的容器的日志信息，内容蕴含 STOUT（规范输入）和 STDERR（规范谬误输入）。日志都会以 json-file 的格局存储于 /var/lib/docker/containers/< 容器 id>/< 容器 id>-json.log，不过这种形式并不适宜放到生产环境中。

• 默认形式下容器日志并不会限度日志文件的大小，容器会始终写日志，导致磁盘爆满，影响零碎利用。（docker log-driver 反对 log 文件的 rotate）
• Docker Daemon 收集容器的规范输入，当日志量过大时会导致 Docker Daemon 成为日志收集的瓶颈，日志的收集速度受限。
• 日志文件量过大时，利用 docker logs - f 查看时会间接将 Docker Daemon 阻塞住，造成 docker ps 等命令也不响应。

Docker 提供了 logging drivers 配置，用户能够依据本人的需要去配置不同的 log-driver，可参考官网 Configure logging drivers[1]。然而上述配置的日志收集也是通过 Docker Daemon 收集，收集日志的速度仍然是瓶颈。

log-driver 日志收集速度

syslog 14.9 MB/s


json-file 37.9 MB/s

能不能找到不通过 Docker Daemon 收集日志间接将日志内容重定向到文件并主动 rotate 的工具呢？答案是必定的采纳 S6[2] 基底镜像。

S6-log 将 CMD 的规范输入重定向到 /…/default/current，而不是发送到 Docker Daemon，这样就防止了 Docker Daemon 收集日志的性能瓶颈。本文就是采纳 S6 基底镜像构建利用镜像造成对立日志收集计划。

对于 Kubernetes 日志

Kubernetes 日志收集计划分成三个级别：

利用（Pod）级别

Pod 级别的日志，默认是输入到规范输入和标记输出，实际上跟 Docker 容器的统一。应用 kubectl logs pod-name -n namespace 查看，具体参考：https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#logs。

节点级别

Node 级别的日志 , 通过配置容器的 log-driver 来进行治理，这种须要配合 logrotare 来进行，日志超过最大限度，主动进行 rotate 操作。

集群级别

集群级别的日志收集，有三种。

节点代理形式，在 Node 级别进行日志收集。个别应用 DaemonSet 部署在每个 Node 中。这种形式长处是消耗资源少，因为只需部署在节点，且对利用无侵入。毛病是只适宜容器内利用日志必须都是规范输入。

应用 sidecar container 作为容器日志代理，也就是在 Pod 中追随利用容器起一个日志解决容器，有两种模式：

一种是间接将利用容器的日志收集并输入到规范输入（叫做 Streaming sidecar container），但须要留神的是，这时候，宿主机上实际上会存在两份雷同的日志文件：一份是利用本人写入的；另一份则是 sidecar 的 stdout 和 stderr 对应的 JSON 文件。这对磁盘是很大的节约，所以说，除非万不得已或者利用容器齐全不可能被批改。

另一种是每一个 Pod 中都起一个日志收集 agent（比方 Logstash 或 Fluebtd）也就是相当于把计划一里的 logging agent 放在了 Pod 里。然而这种计划资源耗费（CPU，内存）较大，并且日志不会输入到规范输入，kubectl logs 会看不到日志内容。

利用容器中间接将日志推到存储后端，这种形式就比较简单了，间接在利用外面将日志内容发送到日志收集服务后端。

日志架构

通过上文对 Kubernetes 日志收集计划的介绍，要想设计一个对立的日志收集零碎，能够采纳节点代理形式收集每个节点上容器的日志，日志的整体架构如图所示：

解释如下：

1. 所有利用容器都是基于 S6 基底镜像的，容器利用日志都会重定向到宿主机的某个目录文件下比方 /data/logs/namespace/appname/podname/log/xxxx.log
2. log-agent 外部蕴含 Filebeat，Logrotate 等工具，其中 Filebeat 是作为日志文件收集的 agent
3. 通过 Filebeat 将收集的日志发送到 Kafka
4. Kafka 在讲日志发送的 ES 日志存储 /kibana 检索层
5. Logstash 作为两头工具次要用来在 ES 中创立 index 和生产 Kafka 的音讯

整个流程很好了解，然而须要解决的是：

1. 用户部署的新利用，如何动静更新 Filebeat 配置
2. 如何保障每个日志文件都被失常的 rotate
3. 如果须要更多的性能则须要二次开发 Filebeat，使 Filebeat 反对更多的自定义配置

付诸实践

解决上述问题，就须要开发一个 log-agent 利用以 DaemonSet 模式运行在 Kubernetes 集群的每个节点上，利用外部蕴含 Filebeat，Logrotate 和须要开发的性能组件。

第一个问题，如何动静更新 Filebeat 配置，能够利用 http://github.com/fsnotify/fsnotify 工具包监听日志目录变动 create、delete 事件，利用模板渲染的办法更新 Filebeat 配置文件。

第二个问题，利用 http://github.com/robfig/cron 工具包创立 CronJob，定期 rotate 日志文件，留神利用日志文件所属用户，如果不是 root 用户所属，能够在配置中设置切换用户。

/var/log/xxxx/xxxxx.log {
  su www-data www-data
  missingok
  notifempty
  size 1G
  copytruncate
} 

第三个问题，对于二次开发 filebeat，能够参考博文：https://www.jianshu.com/p/fe3ac68f4a7a

总结

本文只是对 Kubernetes 日志收集提供了一个简略的思路，对于日志收集能够依据公司的需要，就地取材。

写在最初

欢送大家关注我的公众号【 惊涛骇浪如码 】，海量 Java 相干文章，学习材料都会在外面更新，整顿的材料也会放在外面。

感觉写的还不错的就点个赞，加个关注呗！点关注，不迷路，继续更新！！！