直擊痛點，詳解 K8s 日誌採集最佳實踐

做者 | 元乙  阿里雲存儲服務技術專家

導讀：上一篇文章主要介紹 Kubernetes 日誌輸出的一些注意事項，日誌輸出最終的目的仍是作統一的採集和分析。在 Kubernetes 中，日誌採集和普通虛擬機的方式有很大不一樣，相對實現難度和部署代價也略大，但若使用恰當則比傳統方式自動化程度更高、運維代價更低。本文爲日誌系列文章的第 4 篇。

第一篇：《6 個 K8s 日誌系統建設中的典型問題，你遇到過幾個？》

第二篇：《一文看懂 K8s 日誌系統設計和實踐》

第三篇：《9 個技巧，解決 K8s 中的日誌輸出問題》

Kubernetes 日誌採集難點

在 Kubernetes 中，日誌採集相比傳統虛擬機、物理機方式要複雜不少，最根本的緣由是 Kubernetes 把底層異常屏蔽，提供更加細粒度的資源調度，向上提供穩定、動態的環境。所以日誌採集面對的是更加豐富、動態的環境，須要考慮的點也更加的多。

例如：

• 對於運行時間很短的 Job 類應用，從啓動到中止只有幾秒的時間，如何保證日誌採集的實時性可以跟上並且數據不丟？
• K8s 通常推薦使用大規格節點，每一個節點能夠運行 10-100+ 的容器，如何在資源消耗盡量低的狀況下采集 100+ 的容器？
• 在 K8s 中，應用都以 yaml 的方式部署，而日誌採集仍是以手工的配置文件形式爲主，如何可以讓日誌採集以 K8s 的方式進行部署？

	Kubernetes	傳統方式
日誌種類	文件、stdout、宿主機文件、journal	文件、journal
日誌源	業務容器、系統組件、宿主機	業務、宿主機
採集方式	Agent（Sidecar、DaemonSet）、直寫（DockerEngine、業務）	Agent、直寫
單機應用數	10-100	1-10
應用動態性	高	低
節點動態性	高	低
採集部署方式	手動、Yaml	手動、自定義

採集方式：主動 or 被動

日誌的採集方式分爲被動採集和主動推送兩種，在 K8s 中，被動採集通常分爲 Sidecar 和 DaemonSet 兩種方式，主動推送有 DockerEngine 推送和業務直寫兩種方式。

• DockerEngine 自己具備 LogDriver 功能，可經過配置不一樣的 LogDriver 將容器的 stdout 經過 DockerEngine 寫入到遠端存儲，以此達到日誌採集的目的。這種方式的可定製化、靈活性、資源隔離性都很低，通常不建議在生產環境中使用；
• 業務直寫是在應用中集成日誌採集的 SDK，經過 SDK 直接將日誌發送到服務端。這種方式省去了落盤採集的邏輯，也不須要額外部署 Agent，對於系統的資源消耗最低，但因爲業務和日誌 SDK 強綁定，總體靈活性很低，通常只有日誌量極大的場景中使用；
• DaemonSet 方式在每一個 node 節點上只運行一個日誌 agent，採集這個節點上全部的日誌。DaemonSet 相對資源佔用要小不少，但擴展性、租戶隔離性受限，比較適用於功能單一或業務不是不少的集羣；
• Sidecar 方式爲每一個 POD 單獨部署日誌 agent，這個 agent 只負責一個業務應用的日誌採集。Sidecar 相對資源佔用較多，但靈活性以及多租戶隔離性較強，建議大型的 K8s 集羣或做爲 PaaS 平臺爲多個業務方服務的集羣使用該方式。

總結下來：

• DockerEngine 直寫通常不推薦；
• 業務直寫推薦在日誌量極大的場景中使用；
• DaemonSet 通常在中小型集羣中使用；
• Sidecar 推薦在超大型的集羣中使用。

詳細的各類採集方式對好比下：

	DockerEngine	業務直寫	DaemonSet方式	Sidecar方式
採集日誌類型	標準輸出	業務日誌	標準輸出+部分文件	文件
部署運維	低，原生支持	低，只需維護好配置文件便可	通常，需維護DaemonSet	較高，每一個須要採集日誌的POD都須要部署sidecar容器
日誌分類存儲	沒法實現	業務獨立配置	通常，可經過容器/路徑等映射	每一個POD可單獨配置，靈活性高
多租戶隔離	弱	弱，日誌直寫會和業務邏輯競爭資源	通常，只能經過配置間隔離	強，經過容器進行隔離，可單獨分配資源
支持集羣規模	本地存儲無限制，若使用syslog、fluentd會有單點限制	無限制	取決於配置數	無限制
資源佔用	低，docker
engine提供	總體最低，省去採集開銷	較低，每一個節點運行一個容器	較高，每一個POD運行一個容器
查詢便捷性	低，只能grep原始日誌	高，可根據業務特色進行定製	較高，可進行自定義的查詢、統計	高，可根據業務特色進行定製
可定製性	低	高，可自由擴展	低	高，每一個POD單獨配置
耦合度	高，與DockerEngine強綁定，修改須要重啓DockerEngine	高，採集模塊修改/升級須要從新發布業務	低，Agent可獨立升級	通常，默認採集Agent升級對應Sidecar業務也會重啓（有一些擴展包能夠支持Sidecar熱升級）
適用場景	測試、POC等非生產場景	對性能要求極高的場景	日誌分類明確、功能較單一的集羣	大型、混合型、PAAS型集羣

日誌輸出：Stdout or 文件

和虛擬機/物理機不一樣，K8s 的容器提供標準輸出和文件兩種方式。在容器中，標準輸出將日誌直接輸出到 stdout 或 stderr，而 DockerEngine 接管 stdout 和 stderr 文件描述符，將日誌接收後按照 DockerEngine 配置的 LogDriver 規則進行處理；日誌打印到文件的方式和虛擬機/物理機基本相似，只是日誌可使用不一樣的存儲方式，例如默認存儲、EmptyDir、HostVolume、NFS 等。

雖然使用 Stdout 打印日誌是 Docker 官方推薦的方式，但你們須要注意：這個推薦是基於容器只做爲簡單應用的場景，實際的業務場景中咱們仍是建議你們儘量使用文件的方式，主要的緣由有如下幾點：

• Stdout 性能問題，從應用輸出 stdout 到服務端，中間會通過好幾個流程（例如廣泛使用的 JSON LogDriver）：應用 stdout -> DockerEngine -> LogDriver -> 序列化成 JSON -> 保存到文件 -> Agent 採集文件 -> 解析 JSON -> 上傳服務端。整個流程相比文件的額外開銷要多不少，在壓測時，每秒 10 萬行日誌輸出就會額外佔用 DockerEngine 1 個 CPU 核；

• Stdout 不支持分類，即全部的輸出都混在一個流中，沒法像文件同樣分類輸出，一般一個應用中有 AccessLog、ErrorLog、InterfaceLog（調用外部接口的日誌）、TraceLog 等，而這些日誌的格式、用途不一，若是混在同一個流中將很難採集和分析；

• Stdout 只支持容器的主程序輸出，若是是 daemon/fork 方式運行的程序將沒法使用 stdout；

• 文件的 Dump 方式支持各類策略，例如同步/異步寫入、緩存大小、文件輪轉策略、壓縮策略、清除策略等，相對更加靈活。

所以咱們建議線上應用使用文件的方式輸出日誌，Stdout 只在功能單一的應用或一些 K8s 系統/運維組件中使用。

CICD集成：Logging Operator

Kubernetes 提供了標準化的業務部署方式，能夠經過 yaml（K8s API）來聲明路由規則、暴露服務、掛載存儲、運行業務、定義縮擴容規則等，因此 Kubernetes 很容易和 CICD 系統集成。而日誌採集也是運維監控過程當中的重要部分，業務上線後的全部日誌都要進行實時的收集。

原始的方式是在發佈以後手動去部署日誌採集的邏輯，這種方式須要手工干預，違背 CICD 自動化的宗旨；爲了實現自動化，有人開始基於日誌採集的 API/SDK 包裝一個自動部署的服務，在發佈後經過 CICD 的 webhook 觸發調用，但這種方式的開發代價很高。

在 Kubernetes 中，日誌最標準的集成方式是以一個新資源註冊到 Kubernetes 系統中，以 Operator（CRD）的方式來進行管理和維護。在這種方式下，CICD 系統不須要額外的開發，只需在部署到 Kubernetes 系統時附加上日誌相關的配置便可實現。

Kubernetes 日誌採集方案

早在 Kubernetes 出現以前，咱們就開始爲容器環境開發日誌採集方案，隨着 K8s 的逐漸穩定，咱們開始將不少業務遷移到 K8s 平臺上，所以也基於以前的基礎專門開發了一套 K8s 上的日誌採集方案。主要具有的功能有：

• 支持各種數據的實時採集，包括容器文件、容器 Stdout、宿主機文件、Journal、Event 等；
• 支持多種採集部署方式，包括 DaemonSet、Sidecar、DockerEngine LogDriver 等；
• 支持對日誌數據進行富化，包括附加 Namespace、Pod、Container、Image、Node 等信息；
• 穩定、高可靠，基於阿里自研的 Logtail 採集 Agent 實現，目前全網已有幾百萬的部署實例；
• 基於 CRD 進行擴展，可以使用 Kubernetes 部署發佈的方式來部署日誌採集規則，與 CICD 完美集成。

安裝日誌採集組件

目前這套採集方案已經對外開放，咱們提供了一個 Helm 安裝包，其中包括 Logtail 的 DaemonSet、AliyunlogConfig 的 CRD 聲明以及 CRD Controller，安裝以後就能直接使用 DaemonSet 採集以及 CRD 配置了。安裝方式以下：

1. 阿里雲 Kubernetes 集羣在開通的時候能夠勾選安裝，這樣在集羣建立的時候會自動安裝上述組件。若是開通的時候沒有安裝，則能夠手動安裝；
2. 若是是自建的 Kubernetes，不管是在阿里雲上自建仍是在其餘雲或者是線下，也可使用這樣採集方案，具體安裝方式參考自建 Kubernetes 安裝。

安裝好上述組件以後，Logtail 和對應的 Controller 就會運行在集羣中，但默認這些組件並不會採集任何日誌，須要配置日誌採集規則來採集指定 Pod 的各種日誌。

採集規則配置：環境變量 or CRD

除了在日誌服務控制檯上手動配置以外，對於 Kubernetes 還額外支持兩種配置方式：環境變量和 CRD。

• 環境變量是自 swarm 時代一直使用的配置方式，只須要在想要採集的容器環境變量上聲明須要採集的數據地址便可，Logtail 會自動將這些數據採集到服務端；

這種方式部署簡單，學習成本低，很容易上手；但可以支持的配置規則不多，不少高級配置（例如解析方式、過濾方式、黑白名單等）都不支持，並且這種聲明的方式不支持修改/刪除，每次修改其實都是建立 1 個新的採集配置，歷史的採集配置須要手動清理，不然會形成資源浪費。

• CRD 配置方式是很是符合 Kubernetes 官方推薦的標準擴展方式，讓採集配置以 K8s 資源的方式進行管理，經過向 Kubernetes 部署 AliyunLogConfig 這個特殊的 CRD 資源來聲明須要採集的數據。

例以下面的示例就是部署一個容器標準輸出的採集，其中定義須要 Stdout 和 Stderr 都採集，而且排除環境變量中包含 COLLEXT_STDOUT_FLAG：false 的容器。

基於 CRD 的配置方式以 Kubernetes 標準擴展資源的方式進行管理，支持配置的增刪改查完整語義，並且支持各類高級配置，是咱們極其推薦的採集配置方式。

採集規則推薦的配置方式

實際應用場景中，通常都是使用 DaemonSet 或 DaemonSet 與 Sidecar 混用方式，DaemonSet 的優點是資源利用率高，但有一個問題是 DaemonSet 的全部 Logtail 都共享全局配置，而單一的 Logtail 有配置支撐的上限，所以沒法支撐應用數比較多的集羣。

上述是咱們給出的推薦配置方式，核心的思想是：

• 一個配置儘量多的採集同類數據，減小配置數，下降 DaemonSet 壓力；
• 核心的應用採集要給予充分的資源，可使用 Sidecar 方式；
• 配置方式儘量使用 CRD 方式；
• Sidecar 因爲每一個 Logtail 是單獨的配置，因此沒有配置數的限制，這種比較適合於超大型的集羣使用。

實踐 1 - 中小型集羣

絕大部分 Kubernetes 集羣都屬於中小型的，對於中小型沒有明確的定義，通常應用數在 500 之內，節點規模 1000 之內，沒有職能明確的 Kubernetes 平臺運維。這種場景應用數不會特別多，DaemonSet 能夠支撐全部的採集配置：

• 絕大部分業務應用的數據使用 DaemonSet 採集方式；
• 核心應用（對於採集可靠性要求比較高，例如訂單/交易系統）使用 Sidecar 方式單獨採集。

實踐 2 - 大型集羣

對於一些用做 PaaS 平臺的大型/超大型集羣，通常業務在 1000 以上，節點規模也在 1000 以上，有專門的 Kubernetes 平臺運維人員。這種場景下應用數沒有限制，DaemonSet 沒法支持，所以必須使用 Sidecar 方式，總體規劃以下：

• Kubernetes 平臺自己的系統組件日誌、內核日誌相對種類固定，這部分日誌使用 DaemonSet 採集，主要爲平臺的運維人員提供服務；
• 各個業務的日誌使用 Sidecar 方式採集，每一個業務能夠獨立設置 Sidecar 的採集目的地址，爲業務的 DevOps 人員提供足夠的靈活性。

有一個阿里團隊須要你！

雲原生應用平臺邀 Kubernetes/容器/ Serverless/應用交付技術領域專家（P7-P8）加盟。

• 技術要求：Go/Rust/Java/C++，Linux，分佈式系統；

• 工做年限：P7 三年起，P8 五年起，具體看實際能力；

• 工做地點：國內（北京 / 杭州 / 深圳）；海外（舊金山灣區 / 西雅圖）。

簡歷投遞：xining.zj AT alibaba-inc.com。

「阿里巴巴雲原生關注微服務、Serverless、容器、Service Mesh 等技術領域、聚焦雲原生流行技術趨勢、雲原生大規模的落地實踐，作最懂雲原生開發者的技術圈。」