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

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

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

1591766458577

圖片來源：kubernetes.io

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

決定是否使用Sidecar模型

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

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

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

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

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

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

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

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

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

使用RBAC控制對日志的訪問

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

保持日志格式一致

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

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

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

結(jié) 論

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