K8s系列－K8S 日志采集最佳實操

感謝分享原文-http://bjbsair.com/2020-04-03/tech-info/29912.html

日志采集難點：

在 Kubernetes 中，日志采集相比傳統虛擬機、物理機方式要復雜很多，最根本的原因是 Kubernetes 把底層異常屏蔽，提供更加細粒度的資源調度，向上提供穩定、動態的環境。因此日志采集面對的是更加豐富、動態的環境，需要考慮的點也更加的多。

例如：

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

采集方式：主動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 推薦在超大型的集群中使用。

詳細的各種采集方式對比如下：

日志輸出：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 人員提供足夠的靈活性。