Kubernetes日志采集原理全方位剖析
简介
作为容器编排领域的实施标准，Kubernetes（K8s）应用的场景也越来越广。日志作为可观测性建设中的重要一环，可以记录详细的访问请求以及错误信息，非常利于问题的定位。Kubernetes上的应用、Kubernetes组件本身、宿主机等都会产生各类日志数据，SLS全面支持这些数据的采集和分析。本文将主要介绍SLS对于Kubernetes日志采集的基本原理，便于大家在实践中能够更好的规划使用方式。
Kubernetes日志采集方式
在K8s中，日志采集一般分为Sidecar和DaemonSet两种方式。一般建议DaemonSet在中小型集群中使用；Sidecar推荐在超大型的集群中使用（为多个业务方提供服务，每个业务方有明确的自定义日志采集需求，采集配置数会超过500）。
- DaemonSet方式在每个node节点上只运行一个日志agent，采集这个节点上所有的日志。DaemonSet相对资源占用要小很多，但扩展性、租户隔离性受限，比较适用于功能单一或业务不是很多的集群。
- Sidecar方式为每个POD单独部署日志agent，这个agent只负责一个业务应用的日志采集。Sidecar相对资源占用较多，但灵活性以及多租户隔离性较强，建议大型的K8S集群或作为PAAS平台为多个业务方服务的集群使用该方式。
| DaemonSet方式 | Sidecar方式 | |
| 采集日志类型 | 标准输出+部分文件 | 文件 |
| 部署运维 | 一般，需维护DaemonSet | 较高，每个需要采集日志的POD都需要部署sidecar容器 |
| 日志分类存储 | 一般，可通过容器/路径等映射 | 每个POD可单独配置，灵活性高 |
| 多租户隔离 | 一般，只能通过配置间隔离 | 强，通过容器进行隔离，可单独分配资源 |
| 支持集群规模 | 取决于采集配置数（由于每个节点的Agent都需要加载所有配置并工作，所以集群的采集配置数有上限，一般不建议超过500个采集配置） | 无限制 |
| 资源占用 | 较低，每个节点运行一个容器 | 较高，每个POD运行一个容器 |
| 查询便捷性 | 较高，可进行自定义的查询、统计 | 高，可根据业务特点进行定制 |
| 可定制性 | 低 | 高，每个POD单独配置 |
| 耦合度 | 低，Agent可独立升级 | 一般，默认采集Agent升级对应Sidecar业务也会重启（有一些扩展包可以支持Sidecar热升级） |
| 适用场景 | 日志分类明确、功能较单一的集群 | 大型、混合型、PAAS型集群 |
TRANSLATE with