溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
這篇文章將為大家詳細講解有關如何進行K8s日志采集最佳實踐，文章內容質量較高，因此小編分享給大家做個參考，希望大家閱讀完這篇文章后對相關知識有一定的了解。
在 Kubernetes 中，日志采集相比傳統虛擬機、物理機方式要復雜很多，最根本的原因是 Kubernetes 把底層異常屏蔽，提供更加細粒度的資源調度，向上提供穩定、動態的環境。因此日志采集面對的是更加豐富、動態的環境，需要考慮的點也更加的多。
例如：
對于運行時間很短的 Job 類應用，從啟動到停止只有幾秒的時間，如何保證日志采集的實時性能夠跟上而且數據不丟？
K8s 一般推薦使用大規格節點，每個節點可以運行 10-100+ 的容器，如何在資源消耗盡可能低的情況下采集 100+ 的容器？
在 K8s 中，應用都以 yaml 的方式部署，而日志采集還是以手工的配置文件形式為主，如何能夠讓日志采集以 K8s 的方式進行部署？
| Kubernetes | 傳統方式 | |
|---|---|---|
| 日志種類 | 文件、stdout、宿主機文件、journal | 文件、journal |
| 日志源 | 業務容器、系統組件、宿主機 | 業務、宿主機 |
| 采集方式 | Agent（Sidecar、DaemonSet）、直寫（DockerEngine、業務） | Agent、直寫 |
| 單機應用數 | 10-100 | 1-10 |
| 應用動態性 | 高 | 低 |
| 節點動態性 | 高 | 低 |
| 采集部署方式 | 手動、Yaml | 手動、自定義 |
日志的采集方式分為被動采集和主動推送兩種，在 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型集群 |
和虛擬機/物理機不同，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 系統/運維組件中使用。
Kubernetes 提供了標準化的業務部署方式，可以通過 yaml（K8s API）來聲明路由規則、暴露服務、掛載存儲、運行業務、定義縮擴容規則等，所以 Kubernetes 很容易和 CICD 系統集成。而日志采集也是運維監控過程中的重要部分，業務上線后的所有日志都要進行實時的收集。
原始的方式是在發布之后手動去部署日志采集的邏輯，這種方式需要手工干預，違背 CICD 自動化的宗旨；為了實現自動化，有人開始基于日志采集的 API/SDK 包裝一個自動部署的服務，在發布后通過 CICD 的 webhook 觸發調用，但這種方式的開發代價很高。
在 Kubernetes 中，日志最標準的集成方式是以一個新資源注冊到 Kubernetes 系統中，以 Operator（CRD）的方式來進行管理和維護。在這種方式下，CICD 系統不需要額外的開發，只需在部署到 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 配置了。安裝方式如下：
阿里云 Kubernetes 集群在開通的時候可以勾選安裝，這樣在集群創建的時候會自動安裝上述組件。如果開通的時候沒有安裝，則可以 手動安裝；
如果是自建的 Kubernetes，無論是在阿里云上自建還是在其他云或者是線下，也可以使用這樣采集方案。
安裝好上述組件之后，Logtail 和對應的 Controller 就會運行在集群中，但默認這些組件并不會采集任何日志，需要配置日志采集規則來采集指定 Pod 的各類日志。
除了在日志服務控制臺上手動配置之外，對于 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 是單獨的配置，所以沒有配置數的限制，這種比較適合于超大型的集群使用。
絕大部分 Kubernetes 集群都屬于中小型的，對于中小型沒有明確的定義，一般應用數在 500 以內，節點規模 1000 以內，沒有職能明確的 Kubernetes 平臺運維。這種場景應用數不會特別多，DaemonSet 可以支撐所有的采集配置：
絕大部分業務應用的數據使用 DaemonSet 采集方式；
核心應用（對于采集可靠性要求比較高，例如訂單/交易系統）使用 Sidecar 方式單獨采集。
對于一些用作 PaaS 平臺的大型/超大型集群，一般業務在 1000 以上，節點規模也在 1000 以上，有專門的 Kubernetes 平臺運維人員。這種場景下應用數沒有限制，DaemonSet 無法支持，因此必須使用 Sidecar 方式，整體規劃如下：
Kubernetes 平臺本身的系統組件日志、內核日志相對種類固定，這部分日志使用 DaemonSet 采集，主要為平臺的運維人員提供服務；
各個業務的日志使用 Sidecar 方式采集，每個業務可以獨立設置 Sidecar 的采集目的地址，為業務的 DevOps 人員提供足夠的靈活性
關于如何進行K8s日志采集最佳實踐就分享到這里了，希望以上內容可以對大家有一定的幫助，可以學到更多知識。如果覺得文章不錯，可以把它分享出去讓更多的人看到。
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
