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

**導讀**：[上一篇文章](https://developer.aliyun.com/article/747821)主要介紹 Kubernetes 日誌輸出的一些注意事項，日誌輸出最終的目的還是做統一的採集和分析。在 Kubernetes 中，日誌採集和普通虛擬機器的方式有很大不同，相對實現難度和部署代價也略大，但若使用恰當則比傳統方式自動化程度更高、運維代價更低。本文為日誌系列文章的第 4 篇。

第一篇：[《6 個 K8s 日誌系統建設中的典型問題，你遇到過幾個？》](https://developer.aliyun.com/article/718735)

第二篇：[《一文看懂 K8s 日誌系統設計和實踐》](https://developer.aliyun.com/article/727594)

第三篇：[《9 個技巧，解決 K8s 中的日誌輸出問題》](https://developer.aliyun.com/article/747821)

# Kubernetes 日誌採集難點
在 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 平臺為多個業務方服務的叢集使用該方式。

![2.png](https://ucc.alicdn.com/pic/developer-ecology/3b29139381f047bba144969e04bd74c8.png)

總結下來：

- 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

![4..png](https://ucc.alicdn.com/pic/developer-ecology/61d5f24174ca440d8655f6dd623a5d60.png)

Kubernetes 提供了標準化的業務部署方式，可以透過 yaml（K8s API）來宣告路由規則、暴露服務、掛載儲存、執行業務、定義縮擴容規則等，所以 Kubernetes 很容易和 CICD 系統整合。而日誌採集也是運維監控過程中的重要部分，業務上線後的所有日誌都要進行實時的收集。

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

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

# Kubernetes 日誌採集方案

![5..png](https://ucc.alicdn.com/pic/developer-ecology/0c2fa77ee40f4b219ce804c165aaf91d.png)

早在 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 叢集在開通的時候可以勾選安裝，這樣在叢集建立的時候會自動安裝上述元件。如果開通的時候沒有安裝，則可以[手動安裝](https://help.aliyun.com/document_detail/87540.html)；
1. 如果是自建的 Kubernetes，無論是在阿里雲上自建還是在其他雲或者是線下，也可以使用這樣採集方案，具體安裝方式參考[自建 Kubernetes 安裝](https://help.aliyun.com/document_detail/66654.html)。

安裝好上述元件之後，Logtail 和對應的 Controller 就會執行在叢集中，但預設這些元件並不會採集任何日誌，需要配置日誌採集規則來採集指定 Pod 的各類日誌。

## 採集規則配置：環境變數 or CRD
除了在日誌服務控制檯上手動配置之外，對於 Kubernetes 還額外支援兩種配置方式：環境變數和 CRD。

- **環境變數**是自 swarm 時代一直使用的配置方式，只需要在想要採集的容器環境變數上宣告需要採集的資料地址即可，Logtail 會自動將這些資料採集到服務端；

這種方式部署簡單，學習成本低，很容易上手；但能夠支援的配置規則很少，很多高階配置（例如解析方式、過濾方式、黑白名單等）都不支援，而且這種宣告的方式不支援修改/刪除，每次修改其實都是建立 1 個新的採集配置，歷史的採集配置需要手動清理，否則會造成資源浪費。

![6..png](https://ucc.alicdn.com/pic/developer-ecology/c1cedd029d134dd2856dbb3c9555bf89.png)

- [**CRD 配置方式**](https://help.aliyun.com/document_detail/74878.html)是非常符合 Kubernetes 官方推薦的標準擴充套件方式，讓採集配置以 K8s 資源的方式進行管理，透過向 Kubernetes 部署 AliyunLogConfig 這個特殊的 CRD 資源來宣告需要採集的資料。

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

基於 CRD 的配置方式以 Kubernetes 標準擴充套件資源的方式進行管理，支援配置的增刪改查完整語義，而且支援各種高階配置，是我們極其推薦的採集配置方式。

![7..png](https://ucc.alicdn.com/pic/developer-ecology/4a6415e69a4343afad9d70baa6c50387.png)

## 採集規則推薦的配置方式

![8.png](https://ucc.alicdn.com/pic/developer-ecology/5dae595fb62b4f2fa72964eedda4171f.png)

實際應用場景中，一般都是使用 DaemonSet 或 DaemonSet 與 Sidecar 混用方式，DaemonSet 的優勢是資源利用率高，但有一個問題是 DaemonSet 的所有 Logtail 都共享全域性配置，而單一的 Logtail 有配置支撐的上限，因此無法支撐應用數比較多的叢集。

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

- 一個配置儘可能多的採集同類資料，減少配置數，降低 DaemonSet 壓力；
- 核心的應用採集要給予充分的資源，可以使用 Sidecar 方式；
- 配置方式儘可能使用 CRD 方式；
- Sidecar 由於每個 Logtail 是單獨的配置，所以沒有配置數的限制，這種比較適合於超大型的叢集使用。

# 實踐 1 - 中小型叢集

![9.png](https://ucc.alicdn.com/pic/developer-ecology/360d67a3ea3340fa9fcd18b8eb9f00e0.png)

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

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

# 實踐 2 - 大型叢集

![10.png](https://ucc.alicdn.com/pic/developer-ecology/6a493388586b42ee80dcb534c3a3a96c.png)

對於一些用作 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。

![2群直播海報.png](https://ucc.alicdn.com/pic/developer-ecology/ba2fd89d2e5243449b94f33672a77cc8.png)

> “[阿里巴巴雲原生](https://developer.aliyun.com/group/alisoftwaretech/)關注微服務、Serverless、容器、Service Mesh 等技術領域、聚焦雲原生流行技術趨勢、雲原生大規模的落地實踐，做最懂雲原生開發者的技術圈。”

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

相關文章