介绍应用容器化后的日志采集应该选择哪种方式？如何平衡？不同的服务质量QoS如何影响Node的稳定性？本文将对此进行简要回顾。主要内容有：日志采集的三种方式日志采集方式衡量Pod服务质量QoS1.日志采集的三种方式K8s日志采集方式主要有native方式、DaemonSet采集方式、Sidecar采集方式。在native模式下，日志被写入标准输出流和标准错误流，输出可以通过kubectllogs命令查看，如下图所示。通过日志轮转工具logrotate实现日志的拆分、压缩、删除和创建新的日志文件。DaemonSet采集方式在k8s的node节点上运行日志代理，日志代理采集日志到后端服务。SideCar采集方式是在POD中运行一个单独的日志采集代理容器，采集容器的日志。官方也解释说SideCar会带来更多的资源消耗，日志没有被kubelet接管，不能使用kubectllogs访问日志。总结：根据官方的采集方式，我应该选择DaemonSet还是SideCar？如何平衡？日志管理官方文档：https://kubernetes.io/zh-cn/docs/concepts/cluster-administration/logging/2.日志采集方式权衡资源消耗。在SideCar收集模式下，每个POD运行一个日志代理容器，DaemonSet代替Node运行一个日志代理。因此，DaemonSet会更充分地共享资源，SideCar模式会占用更多的资源。运维困难。如果业务POD中有多个辅助容器，比如security和links，加上日志采集容器，那么POD中的容器数量会增加。因此很多SideCar容器需要比DaemonSet更多的运维投入。在隔离方面，DaemonSet的日志代理可以为不同的应用配置采集路径配置，SideCar可以一对一定制。因此，一般来说，SideCar隔离性更好。集群大小不受SideCar的限制。DaemonSet模式实际支持的应用数量与场景有关，一般在几百到几千不等。因此，在集群规模上收集更多日志代理的能力是否跟得上是一个问题。对于升级问题，DaemonSet方式的日志采集和升级服务是无感知的，SideCar方式的升级可能会导致服务POD的重构，而这些POD仍然是服务感知的。所以DaemonSet模式对业务更加透明和不敏感。如果希望Sidecar收集方式对业务不敏感，可以使用OpenKruise提供的SidecarSet来管理sidecar容器。SidecarSet负责k8s集群sideCar容器的注入和升级，没有业务意义。总结：当日志采集代理能力能够满足需求时，DaemonSet模式在运维复杂度、资源节约、升级等方面是更好的选择。3.Pod服务质量QoSK8s使用服务质量QoS来确定Pod调度和驱逐策略。QoS分为三类，Guaranteed,Burstable,BestEffort。对于Guaranteed类的POD，必须指定POD中每个容器的内存和CPU，并且request和limit必须相等。对于BurstablePOD，POD中至少有一个容器的内存或CPU请求不满足Guaranteed要求，request和limit设置不同。对于BestEffort类的POD，容器没有设置内存和CPU的请求或限制。优先级保证>突发>尽力而为。K8s资源回收和驱逐策略。当Node上的内存或CPU耗尽时，为了保护Node，POD会被逐出，低优先级的POD会先被逐出。Burstable或BestEffort适用于filebeat、ilogtail等日志收集POD。总结：为了Node的稳定性，将日志采集类的POD设置为BestEffort类型的QoS比较安全。官方Pod服务质量文档：https://kubernetes.io/zh-cn/docs/tasks/configure-pod-container/quality-service-pod/
