Kubernetes能夠幫助管理部署在Pod中的上百個容器的生命週期。它是高度分佈式的而且各個部分是動態的。一個已經實現的Kubernetes環境一般涉及帶有集羣和節點的幾個系統，這些系統託管着幾百個容器，而這些容器不斷地基於工做負載啓動、毀滅。
當在Kubernetes中處理大量的容器化應用和工做負載時，主動進行監控和調試錯誤十分重要。在容器、節點或集羣級別，這些錯誤都能在容器中看到。Kubernetes的日誌機制是一個十分重要的組件，能夠用來管理和監控服務以及基礎設施。在Kubernetes中，日誌可讓你跟蹤錯誤甚至能夠調整託管應用程序的容器的性能。
配置stdout（標準輸出）和stderr（標準錯誤）數據流
第一步是理解日誌是如何生成的。經過Kubernetes，日誌會被髮送到兩個數據流——stdout和stderr。這些數據流將寫入JSON文件，而且此過程由Kubernetes內部處理。你能夠配置將哪一個日誌發送到哪一個數據流中。而一個最佳實踐的建議是將全部應用程序日誌都發送到stdout而且全部錯誤日誌都發送到stderr。
Kubernetes建議使用sidecar容器來收集日誌。在這一方法中，每一個應用程序容器將有一個鄰近的「streaming容器」，該容器將會將全部日誌流傳輸到stdout和stderr。Sidecar模型能夠幫助避免在節點級別公開日誌，而且它可讓你控制容器級別的日誌。
然而，這一模型的問題是它可以適用於小容量的日誌記錄，若是面對大規模的日誌記錄，可能會形成大量資源被佔用。所以，你須要爲每一個正在運行的應用程序容器單獨運行一個日誌容器。在Kubernetes文檔中，將sidecar模型形容爲「幾乎沒有很大的開銷」。須要由你決定是否嘗試這一模型並在選擇它以前查看它所消耗的資源類型。
替代方法是使用日誌代理，該代理在節點級別收集日誌。這樣能夠減小開銷，並確保安全地處理日誌。Fluentd已成爲大規模聚合Kubernetes日誌的最佳選擇。它充當Kubernetes與你要使用Kubernetes日誌的任意數量的端點之間的橋樑。你也能夠選擇像Rancher這樣的Kubernetes管理平臺，在應用商店已經集成了Fluentd，無需從頭開始安裝配置。
肯定Fluentd能夠更好地彙總和路由日誌數據後，下一步就是肯定如何存儲和分析日誌數據。
傳統上，對於以本地服務器爲中心的系統，應用程序日誌存儲在系統中的日誌文件中。這些文件能夠在定義的位置看到，也能夠移動到中央服務器。可是對於Kubernetes，全部日誌都發送到磁盤上/var/log的JSON文件中。這種類型的日誌聚合並不安全，由於節點中的Pod能夠是臨時的也能夠是短暫的。刪除Pod時，日誌文件將丟失。若是你須要嘗試對部分日誌數據丟失進行故障排除時，這可能很難。
Kubernetes官方推薦使用兩個選項：將全部日誌發送到Elasticsearch，或使用你選擇的第三方日誌記錄工具。一樣，這裏存在一個潛在的選擇。採用Elasticsearch路線意味着你須要購買一個完整的堆棧，即EFK堆棧，包括Elasticsearch、Fluentd和Kibana。每一個工具都有其本身的做用。如上所述，Fluentd能夠聚合和路由日誌。Elasticsearch是分析原始日誌數據並提供可讀輸出的強大平臺。Kibana是一種開源數據可視化工具，能夠從你的日誌數據建立漂亮的定製dashboard。這是一個徹底開源的堆棧，是使用Kubernetes進行日誌記錄的強大解決方案。
儘管如此，有些事情仍然須要牢記。Elasticsearch除了由名爲Elastic的組織構建和維護，還有龐大的開源社區開發人員爲其作貢獻。儘管通過大量的實踐檢驗，它能夠快速、強大地處理大規模數據查詢，但在大規模操做時可能會出現一些問題。若是採用的是自我管理（Self-managed）的Elasticsearch，那麼須要有人瞭解如何構建大規模平臺。
替代方案是使用基於雲的日誌分析工具來存儲和分析Kubernetes日誌。諸如Sumo Logic和Splunk等工具都是很好的例子。其中一些工具利用Fluentd來將日誌路由到他們平臺，而另外一些可能有它們本身的自定義日誌代理，該代理位於Kubernetes中的節點級別。這些工具的設置十分簡單，而且使用這些工具能夠花費最少的時間從零搭建一個能夠查看日誌的dashboard。
在Kubernetes中身份驗證機制使用的是基於角色訪問控制（RBAC）以驗證一個用戶的訪問和系統權限。根據用戶是否具備特權（authorization.k8s.io/decision）並向用戶授予緣由（authorization.k8s.io/reason），對在操做期間生成的審覈日誌進行註釋。默認狀況下，審覈日誌未激活。建議激活它以跟蹤身份驗證問題，並可使用kubectl進行設置。
Kubernetes日誌由Kubernetes架構中不一樣的部分生成。這些聚合的日誌應該格式一致，以便諸如Fluentd或FluentBit的日誌聚合工具更易於處理它們。例如，當配置stdout和stderr或使用Fluentd分配標籤和元數據時，須要牢記這一點。這種結構化日誌提供給Elasticsearch以後，能夠減小日誌分析期間的延遲。
因爲生成了大量日誌，所以很難在集羣級別上管理日誌。DaemonSet在Kubernetes中的使用方式與Linux相似。它在後臺運行以執行特定任務。Fluentd和filebeat是Kubernetes支持的用於日誌收集的兩個守護程序。咱們必須爲每一個守護程序設置資源限制，以便根據可用的系統資源來優化日誌文件的收集。
Kubernetes包含多個層和組件，所以對其進行良好地監控和跟蹤可以讓咱們在面對故障時從容不迫。Kubernetes鼓勵使用無縫集成的外部「Kubernetes原生」工具進行日誌記錄，從而使管理員更輕鬆地獲取日誌。文章中提到的實踐對於擁有一個健壯的日誌記錄體系結構很重要，該體系結構在任何狀況下均可以正常工做。它們以優化的方式消耗計算資源，並保持Kubernetes環境的安全性和高性能。
本文分享自微信公衆號 - K8S中文社區（k8schina）。
若有侵權，請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。web
