本文轉自Rancher Labs
Kubernetes可以幫助管理部署在Pod中的上百個容器的生命週期。它是高度分散式的並且各個部分是動態的。一個已經實現的Kubernetes環境通常涉及帶有叢集和節點的幾個系統，這些系統託管著幾百個容器，而這些容器不斷地基於工作負載啟動、毀滅。
當在Kubernetes中處理大量的容器化應用和工作負載時，主動進行監控和除錯錯誤十分重要。在容器、節點或叢集級別，這些錯誤都能在容器中看到。Kubernetes的日誌機制是一個十分重要的元件，可以用來管理和監控服務以及基礎設施。在Kubernetes中，日誌可以讓你跟蹤錯誤甚至可以調整託管應用程式的容器的效能。
配置stdout（標準輸出）和stderr（標準錯誤）資料流
圖片來源：kubernetes.io
第一步是理解日誌是如何生成的。通過Kubernetes，日誌會被髮送到兩個資料流——stdout和stderr。這些資料流將寫入JSON檔案，並且此過程由Kubernetes內部處理。你可以配置將哪個日誌傳送到哪個資料流中。而一個最佳實踐的建議是將所有應用程式日誌都傳送到stdout並且所有錯誤日誌都傳送到stderr。
決定是否使用Sidecar模型
Kubernetes建議使用sidecar容器來收集日誌。在這一方法中，每個應用程式容器將有一個鄰近的“streaming容器”，該容器將會將所有日誌流傳輸到stdout和stderr。Sidecar模型可以幫助避免在節點級別公開日誌，並且它可以讓你控制容器級別的日誌。
然而，這一模型的問題是它能夠適用於小容量的日誌記錄，如果面對大規模的日誌記錄，可能會造成大量資源被佔用。因此，你需要為每個正在執行的應用程式容器單獨執行一個日誌容器。在Kubernetes文件中，將sidecar模型形容為“幾乎沒有很大的開銷”。需要由你決定是否嘗試這一模型並在選擇它之前檢視它所消耗的資源型別。
替代方法是使用日誌代理，該代理在節點級別收集日誌。這樣可以減少開銷，並確保安全地處理日誌。Fluentd已成為大規模聚合Kubernetes日誌的最佳選擇。它充當Kubernetes與你要使用Kubernetes日誌的任意數量的端點之間的橋樑。你也可以選擇像Rancher這樣的Kubernetes管理平臺，在應用商店已經整合了Fluentd，無需從頭開始安裝配置。
確定Fluentd可以更好地彙總和路由日誌資料後，下一步就是確定如何儲存和分析日誌資料。
選擇日誌分析工具：EFK或專用日誌記錄
傳統上，對於以本地伺服器為中心的系統，應用程式日誌儲存在系統中的日誌檔案中。這些檔案可以在定義的位置看到，也可以移動到中央伺服器。但是對於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。
使用RBAC控制對日誌的訪問
在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環境的安全性和高效能。