這篇文章將為大家詳細(xì)講解有關(guān)如何進(jìn)行K8s日志采集最佳實(shí)踐，文章內(nèi)容質(zhì)量較高，因此小編分享給大家做個(gè)參考，希望大家閱讀完這篇文章后對(duì)相關(guān)知識(shí)有一定的了解。

烏爾禾網(wǎng)站制作公司哪家好，找創(chuàng)新互聯(lián)！從網(wǎng)頁(yè)設(shè)計(jì)、網(wǎng)站建設(shè)、微信開發(fā)、APP開發(fā)、成都響應(yīng)式網(wǎng)站建設(shè)公司等網(wǎng)站項(xiàng)目制作，到程序開發(fā)，運(yùn)營(yíng)維護(hù)。創(chuàng)新互聯(lián)自2013年起到現(xiàn)在10年的時(shí)間，我們擁有了豐富的建站經(jīng)驗(yàn)和運(yùn)維經(jīng)驗(yàn)，來(lái)保證我們的工作的順利進(jìn)行。專注于網(wǎng)站建設(shè)就選創(chuàng)新互聯(lián)。

Kubernetes 日志采集難點(diǎn)

在 Kubernetes 中，日志采集相比傳統(tǒng)虛擬機(jī)、物理機(jī)方式要復(fù)雜很多，最根本的原因是 Kubernetes 把底層異常屏蔽，提供更加細(xì)粒度的資源調(diào)度，向上提供穩(wěn)定、動(dòng)態(tài)的環(huán)境。因此日志采集面對(duì)的是更加豐富、動(dòng)態(tài)的環(huán)境，需要考慮的點(diǎn)也更加的多。

例如：

• 對(duì)于運(yùn)行時(shí)間很短的 Job 類應(yīng)用，從啟動(dòng)到停止只有幾秒的時(shí)間，如何保證日志采集的實(shí)時(shí)性能夠跟上而且數(shù)據(jù)不丟？

• K8s 一般推薦使用大規(guī)格節(jié)點(diǎn)，每個(gè)節(jié)點(diǎn)可以運(yùn)行 10-100+ 的容器，如何在資源消耗盡可能低的情況下采集 100+ 的容器？

• 在 K8s 中，應(yīng)用都以 yaml 的方式部署，而日志采集還是以手工的配置文件形式為主，如何能夠讓日志采集以 K8s 的方式進(jìn)行部署？

	Kubernetes	傳統(tǒng)方式
日志種類	文件、stdout、宿主機(jī)文件、journal	文件、journal
日志源	業(yè)務(wù)容器、系統(tǒng)組件、宿主機(jī)	業(yè)務(wù)、宿主機(jī)
采集方式	Agent（Sidecar、DaemonSet）、直寫（DockerEngine、業(yè)務(wù)）	Agent、直寫
單機(jī)應(yīng)用數(shù)	10-100	1-10
應(yīng)用動(dòng)態(tài)性	高	低
節(jié)點(diǎn)動(dòng)態(tài)性	高	低
采集部署方式	手動(dòng)、Yaml	手動(dòng)、自定義

采集方式：主動(dòng) or 被動(dòng)

日志的采集方式分為被動(dòng)采集和主動(dòng)推送兩種，在 K8s 中，被動(dòng)采集一般分為 Sidecar 和 DaemonSet 兩種方式，主動(dòng)推送有 DockerEngine 推送和業(yè)務(wù)直寫兩種方式。

• DockerEngine 本身具有 LogDriver 功能，可通過(guò)配置不同的 LogDriver 將容器的 stdout 通過(guò) DockerEngine 寫入到遠(yuǎn)端存儲(chǔ)，以此達(dá)到日志采集的目的。這種方式的可定制化、靈活性、資源隔離性都很低，一般不建議在生產(chǎn)環(huán)境中使用；

• 業(yè)務(wù)直寫是在應(yīng)用中集成日志采集的 SDK，通過(guò) SDK 直接將日志發(fā)送到服務(wù)端。這種方式省去了落盤采集的邏輯，也不需要額外部署 Agent，對(duì)于系統(tǒng)的資源消耗最低，但由于業(yè)務(wù)和日志 SDK 強(qiáng)綁定，整體靈活性很低，一般只有日志量極大的場(chǎng)景中使用；

• DaemonSet 方式在每個(gè) node 節(jié)點(diǎn)上只運(yùn)行一個(gè)日志 agent，采集這個(gè)節(jié)點(diǎn)上所有的日志。DaemonSet 相對(duì)資源占用要小很多，但擴(kuò)展性、租戶隔離性受限，比較適用于功能單一或業(yè)務(wù)不是很多的集群；

• Sidecar 方式為每個(gè) POD 單獨(dú)部署日志 agent，這個(gè) agent 只負(fù)責(zé)一個(gè)業(yè)務(wù)應(yīng)用的日志采集。Sidecar 相對(duì)資源占用較多，但靈活性以及多租戶隔離性較強(qiáng)，建議大型的 K8s 集群或作為 PaaS 平臺(tái)為多個(gè)業(yè)務(wù)方服務(wù)的集群使用該方式。

總結(jié)下來(lái)：

• DockerEngine 直寫一般不推薦；

• 業(yè)務(wù)直寫推薦在日志量極大的場(chǎng)景中使用；

• DaemonSet 一般在中小型集群中使用；

• Sidecar 推薦在超大型的集群中使用。

詳細(xì)的各種采集方式對(duì)比如下：

	DockerEngine	業(yè)務(wù)直寫	DaemonSet方式	Sidecar方式
采集日志類型	標(biāo)準(zhǔn)輸出	業(yè)務(wù)日志	標(biāo)準(zhǔn)輸出+部分文件	文件
部署運(yùn)維	低，原生支持	低，只需維護(hù)好配置文件即可	一般，需維護(hù)DaemonSet	較高，每個(gè)需要采集日志的POD都需要部署sidecar容器
日志分類存儲(chǔ)	無(wú)法實(shí)現(xiàn)	業(yè)務(wù)獨(dú)立配置	一般，可通過(guò)容器/路徑等映射	每個(gè)POD可單獨(dú)配置，靈活性高
多租戶隔離	弱	弱，日志直寫會(huì)和業(yè)務(wù)邏輯競(jìng)爭(zhēng)資源	一般，只能通過(guò)配置間隔離	強(qiáng)，通過(guò)容器進(jìn)行隔離，可單獨(dú)分配資源
支持集群規(guī)模	本地存儲(chǔ)無(wú)限制，若使用syslog、fluentd會(huì)有單點(diǎn)限制	無(wú)限制	取決于配置數(shù)	無(wú)限制
資源占用	低，docker
engine提供	整體最低，省去采集開銷	較低，每個(gè)節(jié)點(diǎn)運(yùn)行一個(gè)容器	較高，每個(gè)POD運(yùn)行一個(gè)容器
查詢便捷性	低，只能grep原始日志	高，可根據(jù)業(yè)務(wù)特點(diǎn)進(jìn)行定制	較高，可進(jìn)行自定義的查詢、統(tǒng)計(jì)	高，可根據(jù)業(yè)務(wù)特點(diǎn)進(jìn)行定制
可定制性	低	高，可自由擴(kuò)展	低	高，每個(gè)POD單獨(dú)配置
耦合度	高，與DockerEngine強(qiáng)綁定，修改需要重啟DockerEngine	高，采集模塊修改/升級(jí)需要重新發(fā)布業(yè)務(wù)	低，Agent可獨(dú)立升級(jí)	一般，默認(rèn)采集Agent升級(jí)對(duì)應(yīng)Sidecar業(yè)務(wù)也會(huì)重啟（有一些擴(kuò)展包可以支持Sidecar熱升級(jí)）
適用場(chǎng)景	測(cè)試、POC等非生產(chǎn)場(chǎng)景	對(duì)性能要求極高的場(chǎng)景	日志分類明確、功能較單一的集群	大型、混合型、PAAS型集群

日志輸出：Stdout or 文件

和虛擬機(jī)/物理機(jī)不同，K8s 的容器提供標(biāo)準(zhǔn)輸出和文件兩種方式。在容器中，標(biāo)準(zhǔn)輸出將日志直接輸出到 stdout 或 stderr，而 DockerEngine 接管 stdout 和 stderr 文件描述符，將日志接收后按照 DockerEngine 配置的 LogDriver 規(guī)則進(jìn)行處理；日志打印到文件的方式和虛擬機(jī)/物理機(jī)基本類似，只是日志可以使用不同的存儲(chǔ)方式，例如默認(rèn)存儲(chǔ)、EmptyDir、HostVolume、NFS 等。

雖然使用 Stdout 打印日志是 Docker 官方推薦的方式，但大家需要注意：這個(gè)推薦是基于容器只作為簡(jiǎn)單應(yīng)用的場(chǎng)景，實(shí)際的業(yè)務(wù)場(chǎng)景中我們還是建議大家盡可能使用文件的方式，主要的原因有以下幾點(diǎn)：

• Stdout 性能問(wèn)題，從應(yīng)用輸出 stdout 到服務(wù)端，中間會(huì)經(jīng)過(guò)好幾個(gè)流程（例如普遍使用的 JSON LogDriver）：應(yīng)用 stdout -> DockerEngine -> LogDriver -> 序列化成 JSON -> 保存到文件 -> Agent 采集文件 -> 解析 JSON -> 上傳服務(wù)端。整個(gè)流程相比文件的額外開銷要多很多，在壓測(cè)時(shí)，每秒 10 萬(wàn)行日志輸出就會(huì)額外占用 DockerEngine 1 個(gè) CPU 核；

• Stdout 不支持分類，即所有的輸出都混在一個(gè)流中，無(wú)法像文件一樣分類輸出，通常一個(gè)應(yīng)用中有 AccessLog、ErrorLog、InterfaceLog（調(diào)用外部接口的日志）、TraceLog 等，而這些日志的格式、用途不一，如果混在同一個(gè)流中將很難采集和分析；

• Stdout 只支持容器的主程序輸出，如果是 daemon/fork 方式運(yùn)行的程序?qū)o(wú)法使用 stdout；

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

因此我們建議線上應(yīng)用使用文件的方式輸出日志，Stdout 只在功能單一的應(yīng)用或一些 K8s 系統(tǒng)/運(yùn)維組件中使用。

CICD集成：Logging Operator

Kubernetes 提供了標(biāo)準(zhǔn)化的業(yè)務(wù)部署方式，可以通過(guò) yaml（K8s API）來(lái)聲明路由規(guī)則、暴露服務(wù)、掛載存儲(chǔ)、運(yùn)行業(yè)務(wù)、定義縮擴(kuò)容規(guī)則等，所以 Kubernetes 很容易和 CICD 系統(tǒng)集成。而日志采集也是運(yùn)維監(jiān)控過(guò)程中的重要部分，業(yè)務(wù)上線后的所有日志都要進(jìn)行實(shí)時(shí)的收集。

原始的方式是在發(fā)布之后手動(dòng)去部署日志采集的邏輯，這種方式需要手工干預(yù)，違背 CICD 自動(dòng)化的宗旨；為了實(shí)現(xiàn)自動(dòng)化，有人開始基于日志采集的 API/SDK 包裝一個(gè)自動(dòng)部署的服務(wù)，在發(fā)布后通過(guò) CICD 的 webhook 觸發(fā)調(diào)用，但這種方式的開發(fā)代價(jià)很高。

在 Kubernetes 中，日志最標(biāo)準(zhǔn)的集成方式是以一個(gè)新資源注冊(cè)到 Kubernetes 系統(tǒng)中，以 Operator（CRD）的方式來(lái)進(jìn)行管理和維護(hù)。在這種方式下，CICD 系統(tǒng)不需要額外的開發(fā)，只需在部署到 Kubernetes 系統(tǒng)時(shí)附加上日志相關(guān)的配置即可實(shí)現(xiàn)。

Kubernetes 日志采集方案

早在 Kubernetes 出現(xiàn)之前，我們就開始為容器環(huán)境開發(fā)日志采集方案，隨著 K8s 的逐漸穩(wěn)定，我們開始將很多業(yè)務(wù)遷移到 K8s 平臺(tái)上，因此也基于之前的基礎(chǔ)專門開發(fā)了一套 K8s 上的日志采集方案。主要具備的功能有：

• 支持各類數(shù)據(jù)的實(shí)時(shí)采集，包括容器文件、容器 Stdout、宿主機(jī)文件、Journal、Event 等；

• 支持多種采集部署方式，包括 DaemonSet、Sidecar、DockerEngine LogDriver 等；

• 支持對(duì)日志數(shù)據(jù)進(jìn)行富化，包括附加 Namespace、Pod、Container、Image、Node 等信息；

• 穩(wěn)定、高可靠，基于阿里自研的 Logtail 采集 Agent 實(shí)現(xiàn)，目前全網(wǎng)已有幾百萬(wàn)的部署實(shí)例；

• 基于 CRD 進(jìn)行擴(kuò)展，可使用 Kubernetes 部署發(fā)布的方式來(lái)部署日志采集規(guī)則，與 CICD 完美集成。

安裝日志采集組件

目前這套采集方案已經(jīng)對(duì)外開放，我們提供了一個(gè) Helm 安裝包，其中包括 Logtail 的 DaemonSet、AliyunlogConfig 的 CRD 聲明以及 CRD Controller，安裝之后就能直接使用 DaemonSet 采集以及 CRD 配置了。安裝方式如下：

1. 阿里云 Kubernetes 集群在開通的時(shí)候可以勾選安裝，這樣在集群創(chuàng)建的時(shí)候會(huì)自動(dòng)安裝上述組件。如果開通的時(shí)候沒(méi)有安裝，則可以 手動(dòng)安裝；

2. 如果是自建的 Kubernetes，無(wú)論是在阿里云上自建還是在其他云或者是線下，也可以使用這樣采集方案。

安裝好上述組件之后，Logtail 和對(duì)應(yīng)的 Controller 就會(huì)運(yùn)行在集群中，但默認(rèn)這些組件并不會(huì)采集任何日志，需要配置日志采集規(guī)則來(lái)采集指定 Pod 的各類日志。

采集規(guī)則配置：環(huán)境變量 or CRD

除了在日志服務(wù)控制臺(tái)上手動(dòng)配置之外，對(duì)于 Kubernetes 還額外支持兩種配置方式：環(huán)境變量和 CRD。

• 環(huán)境變量是自 swarm 時(shí)代一直使用的配置方式，只需要在想要采集的容器環(huán)境變量上聲明需要采集的數(shù)據(jù)地址即可，Logtail 會(huì)自動(dòng)將這些數(shù)據(jù)采集到服務(wù)端；

這種方式部署簡(jiǎn)單，學(xué)習(xí)成本低，很容易上手；但能夠支持的配置規(guī)則很少，很多高級(jí)配置（例如解析方式、過(guò)濾方式、黑白名單等）都不支持，而且這種聲明的方式不支持修改/刪除，每次修改其實(shí)都是創(chuàng)建 1 個(gè)新的采集配置，歷史的采集配置需要手動(dòng)清理，否則會(huì)造成資源浪費(fèi)。

• CRD 配置方式是非常符合 Kubernetes 官方推薦的標(biāo)準(zhǔn)擴(kuò)展方式，讓采集配置以 K8s 資源的方式進(jìn)行管理，通過(guò)向 Kubernetes 部署 AliyunLogConfig 這個(gè)特殊的 CRD 資源來(lái)聲明需要采集的數(shù)據(jù)。

例如下面的示例就是部署一個(gè)容器標(biāo)準(zhǔn)輸出的采集，其中定義需要 Stdout 和 Stderr 都采集，并且排除環(huán)境變量中包含 COLLEXT_STDOUT_FLAG：false 的容器。

基于 CRD 的配置方式以 Kubernetes 標(biāo)準(zhǔn)擴(kuò)展資源的方式進(jìn)行管理，支持配置的增刪改查完整語(yǔ)義，而且支持各種高級(jí)配置，是我們極其推薦的采集配置方式。

采集規(guī)則推薦的配置方式

實(shí)際應(yīng)用場(chǎng)景中，一般都是使用 DaemonSet 或 DaemonSet 與 Sidecar 混用方式，DaemonSet 的優(yōu)勢(shì)是資源利用率高，但有一個(gè)問(wèn)題是 DaemonSet 的所有 Logtail 都共享全局配置，而單一的 Logtail 有配置支撐的上限，因此無(wú)法支撐應(yīng)用數(shù)比較多的集群。

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

• 一個(gè)配置盡可能多的采集同類數(shù)據(jù)，減少配置數(shù)，降低 DaemonSet 壓力；

• 核心的應(yīng)用采集要給予充分的資源，可以使用 Sidecar 方式；

• 配置方式盡可能使用 CRD 方式；

• Sidecar 由于每個(gè) Logtail 是單獨(dú)的配置，所以沒(méi)有配置數(shù)的限制，這種比較適合于超大型的集群使用。

實(shí)踐 1 - 中小型集群

絕大部分 Kubernetes 集群都屬于中小型的，對(duì)于中小型沒(méi)有明確的定義，一般應(yīng)用數(shù)在 500 以內(nèi)，節(jié)點(diǎn)規(guī)模 1000 以內(nèi)，沒(méi)有職能明確的 Kubernetes 平臺(tái)運(yùn)維。這種場(chǎng)景應(yīng)用數(shù)不會(huì)特別多，DaemonSet 可以支撐所有的采集配置：

• 絕大部分業(yè)務(wù)應(yīng)用的數(shù)據(jù)使用 DaemonSet 采集方式；

• 核心應(yīng)用（對(duì)于采集可靠性要求比較高，例如訂單/交易系統(tǒng)）使用 Sidecar 方式單獨(dú)采集。

實(shí)踐 2 - 大型集群

對(duì)于一些用作 PaaS 平臺(tái)的大型/超大型集群，一般業(yè)務(wù)在 1000 以上，節(jié)點(diǎn)規(guī)模也在 1000 以上，有專門的 Kubernetes 平臺(tái)運(yùn)維人員。這種場(chǎng)景下應(yīng)用數(shù)沒(méi)有限制，DaemonSet 無(wú)法支持，因此必須使用 Sidecar 方式，整體規(guī)劃如下：

• Kubernetes 平臺(tái)本身的系統(tǒng)組件日志、內(nèi)核日志相對(duì)種類固定，這部分日志使用 DaemonSet 采集，主要為平臺(tái)的運(yùn)維人員提供服務(wù)；

• 各個(gè)業(yè)務(wù)的日志使用 Sidecar 方式采集，每個(gè)業(yè)務(wù)可以獨(dú)立設(shè)置 Sidecar 的采集目的地址，為業(yè)務(wù)的 DevOps 人員提供足夠的靈活性

關(guān)于如何進(jìn)行K8s日志采集最佳實(shí)踐就分享到這里了，希望以上內(nèi)容可以對(duì)大家有一定的幫助，可以學(xué)到更多知識(shí)。如果覺(jué)得文章不錯(cuò)，可以把它分享出去讓更多的人看到。

當(dāng)前文章：如何進(jìn)行K8s日志采集最佳實(shí)踐-創(chuàng)新互聯(lián)
本文網(wǎng)址：http://sd-ha.com/article12/decodc.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供網(wǎng)站內(nèi)鏈、定制開發(fā)、做網(wǎng)站、網(wǎng)站收錄、營(yíng)銷型網(wǎng)站建設(shè)、網(wǎng)站設(shè)計(jì)公司

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng)，如需處理請(qǐng)聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來(lái)源： 創(chuàng)新互聯(lián)