云原生下日志采集的 3 种方式

与传统 KVM 部署应用不同的是，Kubernetes 集群应用 Pod 在 Node（Node 一般为物理机或者虚拟机）上的启动位置是不固定的，每次发版都可能调度到另外一台 Node 上，因此应用 Pod 随时会“漂移”，这时需要思考如何在当前场景下满足研发人员对日志查看的需求。通过调研发现，业内日志落地的成熟方案大体分为以下 3 种。

1、挂载 Node 本地文件

Pod 通过 HostPash 方式挂载 Node 目录，将日志文件落到物理机或者虚拟机，每台 Node 运行一个 Filebeat 服务来收集日志。

• 优点：Pod 运行不依赖外部存储组件，可靠性较高。挂载 Node 目录，写磁盘速度最快，每台 Node 上只运行一个 Filebeat 服务，内存和 CPU 利用率比较高。

• 缺点：有一定的开发成本，需要记录每个 Pod 在 Node 上的漂移记录，规划目录结构，单台 Node 上的 Filebeat 服务要管理所有应用的采集配置文件，通常需要通过程序来精细化管理 Filebeat 配置文件。

2、挂载共享存储

Pod 挂载共享存储，程序日志直接打印到共享存储中。

• 优点：不需要特意采集日志，日志直接写入共享存储，便于日志的统一处理。

• 缺点：网络 I/O 瓶颈，共享存储出问题时会导致所有 Pod 异常。通常，共享存储会有网络延迟，如果在应用的处理逻辑中同步打印日志，可能会导致用户请求的响应时间变长。

3、Sidecar 模式

每个 Pod 中运行一个 Sidecar 容器，里面包含了 Filebeat 客户端，可以将程序日志收集并发送给 Kafka 队列。

• 优点：日志采集程序和配置隔离，方便管理。

• 缺点：CPU 成本比较高，有多少个 Pod 就有多少个 Sidecar，占用资源较多。