?引言

應用容器化后的日志采集該選擇何種方式？該如何權衡？不同的服務質量QoS對Node的穩定性影響是怎么樣的，本文就捋一捋這個。主要內容有：

• 日志采集三種方式
• 日志采集方式權衡
• Pod服務質量QoS

一、日志采集三種方式

K8s日志采集方式主要有原生方式、DaemonSet采集方式、Sidecar采集方式。

原生方式，日志寫入標準輸出和標準錯誤流，可通過 kubectl logs 命令查看輸出，如下圖。

通過日志輪替工具logrotate實現日志分割、壓縮、刪除、以及創建新的日志文件。

DaemonSet采集方式，在k8s的node節點上運行日志代理，由日志代理將日志采集到后端服務。

SideCar采集方式，在一個POD中運行一個單獨的日志采集代理容器，用于采集容器的日志。

官方也說明了SideCar會帶來更多的資源損耗，日志沒有被kubelet接管，不能使用kubectl logs訪問日志。

小結：基于官方提供的采集方式，是應該選擇DaemonSet還是SideCar呢？如何權衡？

官方日志管理說明文檔：

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 的服務質量文檔：https://kubernetes.io/zh-cn/docs/tasks/configure-pod-container/quality-service-pod/