1.日志方案的关注点

日志来源和存放位置
日志采集和上报
日志存储
日志分析
日志查询

2.kubernetes中日志的来源和存放位置

宿主机系统日志
其位置一般为/var/log/message
组件的日志
类似于Etcd,kubernetes相关，docker等，如果全部容器化安装，则归为容器类日志， k8s中组件可以指定日志目录（--log-dir），同时也可以直接将日志以标准输出形式输出（--logtostderr），或者同时输出（--alsologtostderr ）
POD只中的标准输出和文件日志
标准输的的日志根据日志的驱动不同所处位置有所差异，以json-file为例，其位置docker/containers/[CTN-ID]/[CTN-ID]-json.log
文件日志由用户指定
集群中的事件
审计日志中一般包含了事件，但是事件一般还是通过k8s的API监听获取
集群中的审计日志
kube-apiserver中通过--audit-log-path指定

3.kubernetes中日志如何采集和日志上报

采集组件

目前主流的采集方案主要有ELK和EFK,而ELF中由于Logstash基于JVM性能不好，现在更多的是将Logstash中的采集功能（Logstash主要承担采集、过滤）交由FIiebeat承担，逐步形成ELK+FIlebeat的方案，FIlebeat及时GO实现，体积小依赖少资消耗小。EFK中的F就是Fluentd ，主要也是承担采集任务。

采集方案

1.对于宿主机，组件的日志和审计日志，一般存放于固定的目录（可以使本地或者远程），可以指定采集器的source即可；

2.对于事件，可通过agent监听，将时间内通融以标准输出或者文件方式存储，在配置采集器source；

3.对于pod包含两部分，json文件(标准输出)和业务系统自身产生的日志文件（应用日志），标准输出的位置相对有规律，对于应用日志采集时需要用户指定其位置，采集的方式有多中也各有利弊。

所有日志集中挂载，然后统一采集。需要分布式存储支持，为每个应用划分存储空间，最好为存储单独添加网卡。采集相对集中，压力大（可以正对不同内容设置单独采集器），有局限性。

image.png
DaemonSet方式将采集器分散到各个主机。这种方式可以采用目录挂载的方式将应用日志挂载到宿主机上，载将对应目录挂载到采集容器中，一个写（业务容器），一个读（采集容器）。资源消耗少，无侵入性。需要挂载目录规划。应用程序日志需要写到标准输出和标准错误输出，
不支持多行日志。

image.png
Sidecar方式将采集器分散到每个Pod中。灵活性强，耦合度低，但每个POD都有一个采集器，资源消大。同时业务容器产生的日志文件本省存储一份，又写入到json中多磁盘也是一种消耗，当然这也可以通过手段处理，只是增加了复杂度。

image.png
业务日志由业务开发这自己负责收集存储
这种方式使用的场景一般是业务系统后面有自己的支撑系统，比如存储和日志中心，这样业务系统在代码内部或者是有自己的伴生容器（sidecar）已经将日志存放到远程或者自己的日志中心，那平台就无需考虑。当然标准输出最好还是要管理的。

image.png
混合模式
相比之下很多人比较青睐于daemonset模式，其实个人觉得为了增加灵活性可以考虑混合使用，大部分的差异在于对业务容器自身产生文件日志的处理，这部分日志通常情况下是要用户指定日志的位置（除非自己处理），可以通过用户是否指定业务日志目录来区别是否处理。