K8S+DevOps架构师实战课 | k8s日志收集架构

视频来源：B站《Docker&k8s教程天花板，绝对是B站讲的最好的，这一套学会k8s搞定Docker 全部核心知识都在这里》

一边学习一边整理老师的课程内容及试验笔记，并与大家分享，侵权即删，谢谢支持！

附上汇总贴：K8S+DevOps架构师实战课 | 汇总_热爱编程的通信人的博客-CSDN博客

总体分为三种方式：

使用在每个节点上运行的节点级日志记录代理。
在应用程序的 pod 中，包含专门记录日志的 sidecar 容器。
将日志直接从应用程序中推送到日志记录后端。

使用节点级日志代理

容器日志驱动：

https://docs.docker.com/config/containers/logging/configure/

查看当前的docker主机的驱动：

$ docker info --format '{
   
   {.LoggingDriver}}'

json-file格式，docker会默认将标准和错误输出保存为宿主机的文件，路径为：

/var/lib/docker/containers/<container-id>/<container-id>-json.log

并且可以设置日志轮转：

{
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "10m",
    "max-file": "3",
    "labels": "production_status",
    "env": "os,customer"
  }
}

优势：

部署方便，使用DaemonSet类型控制器来部署agent即可
对业务应用的影响最小，没有侵入性

劣势:

只能收集标准和错误输出，对于容器内的文件日志，暂时收集不到

使用 sidecar 容器和日志代理

方式一：sidecar 容器将应用程序日志传送到自己的标准输出。

思路：在pod中启动一个sidecar容器，把容器内的日志文件吐到标准输出，由宿主机中的日志收集agent进行采集。

$ cat count-pod.yaml
apiVersion: v1
kind: Pod
metadata:
  name: counter
spec:
  containers:
  - name: count
    image: busybox
    args:
    - /bin/sh
    - -c
    - >
      i=0;
      while true;
      do
        echo "$i: $(date)" >> /var/log/1.log;
        echo "$(date) INFO $i" >> /var/log/2.log;
        i=$((i+1));
        sleep 1;
      done
    volumeMounts:
    - name: varlog
      mountPath: /var/log
  - name: count-log-1
    image: busybox
    args: [/bin/sh, -c, 'tail -n+1 -f /var/log/1.log']
    volumeMounts:
    - name: varlog
      mountPath: /var/log
  - name: count-log-2
    image: busybox
    args: [/bin/sh, -c, 'tail -n+1 -f /var/log/2.log']
    volumeMounts:
    - name: varlog
      mountPath: /var/log
  volumes:
  - name: varlog
    emptyDir: {}
    
$ kubectl apply -f counter-pod.yaml
$ kubectl logs -f counter -c count-log-1

优势：可以实现容器内部日志收集对业务应用的侵入性不大
劣势：每个业务pod都需要做一次改造增加了一次日志的写入，对磁盘使用率有一定影响
方式二：sidecar 容器运行一个日志代理，配置该日志代理以便从应用容器收集日志。

思路：直接在业务Pod中使用sidecar的方式启动一个日志收集的组件（比如fluentd），这样日志收集可以将容器内的日志当成本地文件来进行收取。

优势：不用往宿主机存储日志，本地日志完全可以收集

劣势：每个业务应用额外启动一个日志agent，带来额外的资源损耗

从应用中直接暴露日志目录

企业日志方案选型

目前来讲，最建议的是采用节点级的日志代理。

方案一：自研方案，实现一个自研的日志收集agent，大致思路：

针对容器的标准输出及错误输出，使用常规的方式，监听宿主机中的容器输出路径即可
针对容器内部的日志文件在容器内配置统一的环境变量，比如LOG_COLLECT_FILES，指定好容器内待收集的日志目录及文件agent启动的时候挂载docker.sock文件及磁盘的根路径监听docker的容器新建、删除事件，通过docker的api，查出容器的存储、环境变量、k8s属性等信息配置了LOG_COLLECT_FILES环境变量的容器，根据env中的日志路径找到主机中对应的文件路径，然后生成收集的配置文件agent与开源日志收集工具（Fluentd或者filebeat等）配合，agent负责下发配置到收集工具中并对进程做reload

fluentd-pilot

方案二：日志使用开源的Agent进行收集（EFK方案），适用范围广，可以满足绝大多数日志收集、展示的需求。