云計(jì)算虛擬化實(shí)戰(zhàn)：Kubernetes日志的6個(gè)最佳實(shí)踐

Kubernetes可以幫助管理部署在Pod中的上百個(gè)容器的生命周期。它是高度分布式的并且各個(gè)部分是動(dòng)態(tài)的。一個(gè)已經(jīng)實(shí)現(xiàn)的Kubernetes環(huán)境通常涉及帶有集群和節(jié)點(diǎn)的幾個(gè)系統(tǒng)，這些系統(tǒng)托管著幾百個(gè)容器，而這些容器不斷地基于工作負(fù)載啟動(dòng)、毀滅。

當(dāng)在Kubernetes中處理大量的容器化應(yīng)用和工作負(fù)載時(shí)，主動(dòng)進(jìn)行監(jiān)控和調(diào)試錯(cuò)誤十分重要。在容器、節(jié)點(diǎn)或集群級(jí)別，這些錯(cuò)誤都能在容器中看到。Kubernetes的日志機(jī)制是一個(gè)十分重要的組件，可以用來(lái)管理和監(jiān)控服務(wù)以及基礎(chǔ)設(shè)施。在Kubernetes中，日志可以讓你跟蹤錯(cuò)誤甚至可以調(diào)整托管應(yīng)用程序的容器的性能。

配置stdout(標(biāo)準(zhǔn)輸出)和stderr(標(biāo)準(zhǔn)錯(cuò)誤)數(shù)據(jù)流

1591766458577

圖片來(lái)源：kubernetes.io

第一步是理解日志是如何生成的。通過(guò)Kubernetes，日志會(huì)被發(fā)送到兩個(gè)數(shù)據(jù)流—;—;stdout和stderr。這些數(shù)據(jù)流將寫入JSON文件，并且此過(guò)程由Kubernetes內(nèi)部處理。你可以配置將哪個(gè)日志發(fā)送到哪個(gè)數(shù)據(jù)流中。而一個(gè)最佳實(shí)踐的建議是將所有應(yīng)用程序日志都發(fā)送到stdout并且所有錯(cuò)誤日志都發(fā)送到stderr。

決定是否使用Sidecar模型

Kubernetes建議使用sidecar容器來(lái)收集日志。在這一方法中，每個(gè)應(yīng)用程序容器將有一個(gè)鄰近的“streaming容器”，該容器將會(huì)將所有日志流傳輸?shù)絪tdout和stderr。Sidecar模型可以幫助避免在節(jié)點(diǎn)級(jí)別公開(kāi)日志，并且它可以讓你控制容器級(jí)別的日志。

然而，這一模型的問(wèn)題是它能夠適用于小容量的日志記錄，如果面對(duì)大規(guī)模的日志記錄，可能會(huì)造成大量資源被占用。因此，你需要為每個(gè)正在運(yùn)行的應(yīng)用程序容器單獨(dú)運(yùn)行一個(gè)日志容器。在Kubernetes文檔中，將sidecar模型形容為“幾乎沒(méi)有很大的開(kāi)銷”。需要由你決定是否嘗試這一模型并在選擇它之前查看它所消耗的資源類型。

替代方法是使用日志代理，該代理在節(jié)點(diǎn)級(jí)別收集日志。這樣可以減少開(kāi)銷，并確保安全地處理日志。Fluentd已成為大規(guī)模聚合Kubernetes日志的最佳選擇。它充當(dāng)Kubernetes與你要使用Kubernetes日志的任意數(shù)量的端點(diǎn)之間的橋梁。你也可以選擇像Rancher這樣的Kubernetes管理平臺(tái)，在應(yīng)用商店已經(jīng)集成了Fluentd，無(wú)需從頭開(kāi)始安裝配置。

確定Fluentd可以更好地匯總和路由日志數(shù)據(jù)后，下一步就是確定如何存儲(chǔ)和分析日志數(shù)據(jù)。

選擇日志分析工具：EFK或?qū)Ｓ萌罩居涗?/p>

傳統(tǒng)上，對(duì)于以本地服務(wù)器為中心的系統(tǒng)，應(yīng)用程序日志存儲(chǔ)在系統(tǒng)中的日志文件中。這些文件可以在定義的位置看到，也可以移動(dòng)到中央服務(wù)器。但是對(duì)于Kubernetes，所有日志都發(fā)送到磁盤上/var/log的JSON文件中。這種類型的日志聚合并不安全，因?yàn)楣?jié)點(diǎn)中的Pod可以是臨時(shí)的也可以是短暫的。刪除Pod時(shí)，日志文件將丟失。如果你需要嘗試對(duì)部分日志數(shù)據(jù)丟失進(jìn)行故障排除時(shí)，這可能很難。

Kubernetes官方推薦使用兩個(gè)選項(xiàng)：將所有日志發(fā)送到Elasticsearch，或使用你選擇的第三方日志記錄工具。同樣，這里存在一個(gè)潛在的選擇。采用Elasticsearch路線意味著你需要購(gòu)買一個(gè)完整的堆棧，即EFK堆棧，包括Elasticsearch、Fluentd和Kibana。每個(gè)工具都有其自己的作用。如上所述，F(xiàn)luentd可以聚合和路由日志。Elasticsearch是分析原始日志數(shù)據(jù)并提供可讀輸出的強(qiáng)大平臺(tái)。Kibana是一種開(kāi)源數(shù)據(jù)可視化工具，可以從你的日志數(shù)據(jù)創(chuàng)建漂亮的定制dashboard。這是一個(gè)完全開(kāi)源的堆棧，是使用Kubernetes進(jìn)行日志記錄的強(qiáng)大解決方案。

盡管如此，有些事情仍然需要牢記。Elasticsearch除了由名為Elastic的組織構(gòu)建和維護(hù)，還有龐大的開(kāi)源社區(qū)開(kāi)發(fā)人員為其做貢獻(xiàn)。盡管經(jīng)過(guò)大量的實(shí)踐檢驗(yàn)，它可以快速、強(qiáng)大地處理大規(guī)模數(shù)據(jù)查詢，但在大規(guī)模操作時(shí)可能會(huì)出現(xiàn)一些問(wèn)題。如果采用的是自我管理(Self-managed)的Elasticsearch，那么需要有人了解如何構(gòu)建大規(guī)模平臺(tái)。

替代方案是使用基于云的日志分析工具來(lái)存儲(chǔ)和分析Kubernetes日志。諸如Sumo Logic和Splunk等工具都是很好的例子。其中一些工具利用Fluentd來(lái)將日志路由到他們平臺(tái)，而另一些可能有它們自己的自定義日志代理，該代理位于Kubernetes中的節(jié)點(diǎn)級(jí)別。這些工具的設(shè)置十分簡(jiǎn)單，并且使用這些工具可以花費(fèi)最少的時(shí)間從零搭建一個(gè)可以查看日志的dashboard。

使用RBAC控制對(duì)日志的訪問(wèn)

在Kubernetes中身份驗(yàn)證機(jī)制使用的是基于角色訪問(wèn)控制(RBAC)以驗(yàn)證一個(gè)用戶的訪問(wèn)和系統(tǒng)權(quán)限。根據(jù)用戶是否具有特權(quán)(authorization.k8s.io/decision )并向用戶授予原因(authorization.k8s.io/reason )，對(duì)在操作期間生成的審核日志進(jìn)行注釋。默認(rèn)情況下，審核日志未激活。建議激活它以跟蹤身份驗(yàn)證問(wèn)題，并可以使用kubectl進(jìn)行設(shè)置。

保持日志格式一致

Kubernetes日志由Kubernetes架構(gòu)中不同的部分生成。這些聚合的日志應(yīng)該格式一致，以便諸如Fluentd或FluentBit的日志聚合工具更易于處理它們。例如，當(dāng)配置stdout和stderr或使用Fluentd分配標(biāo)簽和元數(shù)據(jù)時(shí)，需要牢記這一點(diǎn)。這種結(jié)構(gòu)化日志提供給Elasticsearch之后，可以減少日志分析期間的延遲。

在日志收集守護(hù)進(jìn)程上設(shè)置資源限制

由于生成了大量日志，因此很難在集群級(jí)別上管理日志。DaemonSet在Kubernetes中的使用方式與Linux類似。它在后臺(tái)運(yùn)行以執(zhí)行特定任務(wù)。Fluentd和filebeat是Kubernetes支持的用于日志收集的兩個(gè)守護(hù)程序。我們必須為每個(gè)守護(hù)程序設(shè)置資源限制，以便根據(jù)可用的系統(tǒng)資源來(lái)優(yōu)化日志文件的收集。

結(jié) 論

Kubernetes包含多個(gè)層和組件，因此對(duì)其進(jìn)行良好地監(jiān)控和跟蹤能夠讓我們?cè)诿鎸?duì)故障時(shí)從容不迫。Kubernetes鼓勵(lì)使用無(wú)縫集成的外部“Kubernetes原生”工具進(jìn)行日志記錄，從而使管理員更輕松地獲取日志。文章中提到的實(shí)踐對(duì)于擁有一個(gè)健壯的日志記錄體系結(jié)構(gòu)很重要，該體系結(jié)構(gòu)在任何情況下都可以正常工作。它們以優(yōu)化的方式消耗計(jì)算資源，并保持Kubernetes環(huán)境的安全性和高性能。