共计 2542 个字符，预计需要花费 7 分钟才能阅读完成。
kubernetes 日志收集计划有几种计划，都实用于什么场景？本文对 k8s 罕用日志采集计划做了具体介绍。
对于容器日志
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。然而上述配置的日志收集也是通过 Docker Daemon 收集，收集日志的速度仍然是瓶颈。
log-driver 日志收集速度
syslog 14.9 MB/s
json-file 37.9 MB/s
能不能找到不通过 Docker Daemon 收集日志间接将日志内容重定向到文件并主动 rotate 的工具呢？答案是必定的采纳基底镜像。
S6-log 将 CMD 的规范输入重定向到 /…/default/current，而不是发送到 Docker Daemon，这样就防止了 Docker Daemon 收集日志的性能瓶颈。本文就是采纳基底镜像构建利用镜像造成对立日志收集计划。
对于 k8s 日志
k8s 日志收集计划分成三个级别：
- 利用 (Pod) 级别
- 节点级别
- 集群级别
利用 (Pod) 级别
Pod 级别的日志 , 默认是输入到规范输入和标记输出，实际上跟 docker 容器的统一。应用
kubectl logs pod-name -n namespace 查看。
节点级别
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 会看不到日志内容。
- 利用容器中间接将日志推到存储后端，这种形式就比较简单了，间接在利用外面将日志内容发送到日志收集服务后端。
日志架构
通过上文对 k8s 日志收集计划的介绍，要想设计一个对立的日志收集零碎，能够采纳节点代理形式收集每个节点上容器的日志，日志的整体架构如图所示。
解释如下：
- 所有利用容器都是基于 s6 基底镜像的，容器利用日志都会重定向到宿主机的某个目录文件下比方 /data/logs/namespace/appname/podname/log/xxxx.log
- log-agent 外部 蕴含 filebeat，logrotate 等工具，其中 filebeat 是作为日志文件收集的 agent
- 通过 filebeat 将收集的日志发送到 kafka
- kafka 日志发送的 es 日志存储 /kibana 检索层
- logstash 作为两头工具次要用来在 es 中创立 index 和生产 kafka 的音讯
整个流程很好了解，然而须要解决的是
- 用户部署的新利用，如何动静更新 filebeat 配置，
- 如何保障每个日志文件都被失常的 rotate，
- 如果须要更多的性能则须要二次开发 filebeat，使 filebeat 反对更多的自定义配置。
付诸实践
解决上述问题，就须要开发一个 log-agent 利用以 daemonset 模式运行在 k8s 集群的每个节点上，利用外部蕴含 filebeat，logrotate，和须要开发的性能组件。
第一个问题，如何动静更新 filebeat 配置，能够利用 http://github.com/fsnotify/fs… 工具包监听日志目录变动 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
}
总结
本文只是对 k8s 日志收集提供了一个简略的思路，对于日志收集能够依据公司的需要，就地取材。
起源：晓得又忘了 地址：https://zhuanlan.zhihu.com/p/…
