引言
应用容器化后的日志采集该选择何种方式？该如何权衡？不同的服务质量QoS对Node的稳定性影响是怎么样的，本文就捋一捋这个。主要内容有：
- 日志采集三种方式
- 日志采集方式权衡
- Pod服务质量QoS
一、日志采集三种方式
K8s日志采集方式主要有原生方式、DaemonSet采集方式、Sidecar采集方式。
原生方式，日志写入标准输出和标准错误流，可通过 kubectl logs 命令查看输出，如下图。
通过日志轮替工具logrotate实现日志分割、压缩、删除、以及创建新的日志文件。
DaemonSet采集方式，在k8s的node节点上运行日志代理，由日志代理将日志采集到后端服务。
SideCar采集方式，在一个POD中运行一个单独的日志采集代理容器，用于采集容器的日志。
官方也说明了SideCar会带来更多的资源损耗，日志没有被kubelet接管，不能使用kubectl logs访问日志。
小结：基于官方提供的采集方式，是应该选择DaemonSet还是SideCar呢？如何权衡？
官方日志管理说明文档：
代码语言：javascript复制https://kubernetes.io/zh-cn/docs/concepts/cluster-administration/logging/
二、日志采集方式权衡
资源占用 ，SideCar采集模式每个POD运行一个日志代理容器，DaemonSet则是Node运行一个日志代理。
因此，DaemonSet会更充分共享资源，SideCar模式会占用更多的资源。
运维难度，如果业务POD内已经拥有多种辅助容器比如安全、链路等，再增加日志采集容器，POD中容器数量将会增加。
因此，众多SideCar容器要比DaemonSet增加更多的运维投入。
隔离情况，DaemonSet的日志代理，可以配置不同应用的采集路径配置，SideCar一对一单向定制。
因此，总的来说SideCar隔离性更好些。
集群规模，SideCar没有限制，DaemonSet模式实际支持的应用数与场景有关系，大体范围在几百到千级别。
因此，集群规模更多日志代理采集的能力是否跟得上的问题。
升级问题，DaemonSet模式日志采集升级业务无感知，SideCar模式的升级可能导致业务POD的重建，POD的重建还是对业务有感知。
因此，DaemonSet模式对业务更为透明无感。
如果想SideCar采集模式业务无感，可以使用OpenKruise提供的SidecarSet管理sidecar容器。
SidecarSet负责注入和升级k8s集群的sideCar容器，对业务无感。
小结：在日志采集代理能力能满足需求的情况下，DaemonSet模式在运维复杂性、资源节省、升级方面更好的选择。
三、Pod服务质量QoS
K8s使用服务质量QoS来决定Pod的调度和驱逐策略。
QoS分为三类，Guaranteed、Burstable、BestEffort。
Guaranteed类的POD，该POD中的每个容器内存和CPU必须指定，而且request和limit必须相等。
Burstable类的POD，POD里至少一个容器的内存或者CPU请求不满足Guaranteed要求，request和limit设置的不相同。
BestEffort类的POD， 容器没有设置内存和CPU的request或limit。
优先级Guaranteed>Burstable>BestEffort。
K8s资源回收驱逐策略，当Node上的内存或者CPU耗尽时，为了保护Node会驱逐POD，优先级低的POD会优先被驱逐。
日志采集类filebeat、ilogtail等类型的POD适合使用Burstable或者BestEffort。
小结：为了Node的稳定性，日志采集类的POD设置为BestEffort类型的QoS更为安全。
官方Pod 的服务质量文档
代码语言：javascript复制https://kubernetes.io/zh-cn/docs/tasks/configure-pod-container/quality-service-pod/
