Kubernetes 日誌記錄：介紹與挑戰

無論您的團隊有多少在傳統應用程式環境中管理日誌的經驗，在 Kubernetes 中管理日誌時仍可能會面臨陡峭的學習曲線。

因為 Kubernetes 是一個獨特的平台。與傳統應用程式環境相比，它不僅有更多可移動的部件 (還有擴充功能及日誌)，而且在尋找和分析日誌以提供可操作的可觀察性方面，複雜程度甚至遠遠超過其他類型分散式系統和運算環境。

您可以掌握 Kubernetes 日誌，但您需要改進您的日誌管理方式。您必須重新考慮收集和分析日誌的方式，以及日誌在您的整體可觀察性策略中所扮演的角色。

為了引導讀者了解這種作法，本文將介紹 Kubernetes 日誌的基礎知識。本文將解釋為什麼 Kubernetes 日誌收集如此有挑戰性，以及為什麼很難了解 Kubernetes 環境產生的所有不同類型的日誌。我們還將解釋如何透過簡化 Kubernetes 日誌管理來避免陷入 Kubernetes 日誌的泥淖，同時又不影響 Kubernetes 日誌為其支援的複雜雲端原生環境提供的可見性。

Kubernetes 日誌記錄的基礎
儘管 Kubernetes 日誌乍看之下與其他類型的日誌沒有什麼不同，但它們在某些關鍵方面運作方式不同。

日誌類型
首先，Kubernetes 中有兩種完全不同類型的日誌。部署應用程式的容器和 Pod 產生的是一種類型。這些日誌可幫助您了解各個應用程式的效能和可靠性。Kubernetes 本身會產生另一種類型，提供的是整個叢集健康狀況的可見性。

每個類別中又有多種類型的日誌。一個應用程式可能會有多個日誌，因為應用程式中的每個微服務執行個體都會產生一個。叢集等級的日誌也有為不同的類別：主節點、工作節點、Kubernetes API 伺服器和 Kubernetes 的各種其他元件都會產生日誌。

日誌位置
Kubernetes 中有這麼多種類型的日誌，分佈在不同位置不足為奇。IT 工程師會知道其中一些，例如儲存在 Kubernetes 叢集中各伺服器上 /var/log 底下的節點日誌。其他還有如儲存在容器中的日誌，如果您不習慣管理這種類型的資料，那收集起來可能會很棘手。

事件和指標
儘管本文重點是介紹 Kubernetes 日誌，但需要注意的是，日誌只是 Kubernetes 中幾個可見性來源之一。Kubernetes 還提供了一個指標 API，可用於收集叢集健康狀況和資源消耗的資料。它也會記錄某些類型的事件，例如 Pod 終止。單從 Kubernetes 日誌無法完全看到這些資訊，但您應該收集和分析這些資料以及日誌資料，以便獲得對 Kubernetes 的端對端可見性。

Kubernetes 日誌的問題
Kubernetes 本身的日誌架構並不是特別複雜。但是，由於很難實際收集和分析應用程式和叢集中的各種日誌，因此在 Kubernetes 中處理日誌變得相當具有挑戰性。

日誌沒有集中化
一個基本難題是 Kubernetes 日誌分散在各種不同的位置。您無法靠著追蹤單一日誌檔案或執行單一命令來從叢集中收集所有日誌資料。
相反的，如果您想手動收集日誌，需要在多個位置之間切換，包括所有單一節點、每個 Pod 等等。使用如 journalctl 指令可以在一定程度上簡化這個過程，但事情仍然不簡單。

缺乏內建的日誌管理
導致日誌收集複雜性增加原因之一，是 Kubernetes 本身沒有提供管理日誌的架構。它只是產生日誌並將其留給 IT 團隊來想辦法管理它們。

一旦日誌大小超過 10 MB，它就會從容器中刪除日誌資料，但這並沒有多大的幫助。這意味著如果您想將它用於分析之用，就必須在 Kubernetes 覆寫之前將這些資料彙整到其他地方。

形形色色和不斷發展的日誌格式
Kubernetes 叢集和應用程式產生的日誌有多種格式。在當今的大多數叢集仍沒有標準的日誌結構或方法。

Kubernetes 開發人員已經開始透過 JSON 格式來標準化叢集層級日誌，以解決這個問題。但是，這項新功能僅在 Kubernetes 1.19 及以上版本中可用。它也僅適用於叢集日誌；來自應用程式的日誌可能仍採用多種格式。

結論是，儘管 Kubernetes 開發人員已經盡力使日誌更加一致，但缺乏通用的結構和格式仍然是一個問題。而且隨著 Kubernetes 日誌標準不斷發展，團隊制定的日誌管理策略可能越來越複雜。因為很難知道在上一版 Kubernetes 使用的日誌方法是否會在未來版本中同樣有效。

缺乏長期的日誌儲存
預設情況下，Kubernetes 不為應用程式日誌提供長期儲存。相反的，Pod 和容器會將日誌寫入內部環境，當 Pod 或容器關閉後，這些日誌就會永久消失。

這意味著應用程式日誌資料必須彙整到外部的長期儲存位置，以便可時時用於分析。有幾種方法可以做到這一點，例如使用被稱為 sidecar 的容器來收集日誌，或者將日誌直接串流傳輸到外部位置，而不是將它們寫入容器內的本地儲存空間。但是這些方法都會增加 Kubernetes 架構和管理工作流程的複雜性。

更好的 Kubernetes 日誌作法
簡而言之，Kubernetes 日誌很棘手——至少在您嘗試以手動管理日誌時是這樣。

這就是為什麼聰明的團隊會採取不同的方法。與其嘗試從 Pod 和叢集中收集每個日誌 (這是一項很難大規模執行的工作)，您可以部署一個會自動收集日誌的工具，無論日誌以哪種格式編寫或是儲存在 Kubernetes 環境中的哪些位置。

利用日誌分析解決方案將日誌資料與其他 Kubernetes 可見性來源 (例如指標和追蹤) 配對，以提供叢集狀態和應用程式的完全情境化資料則同樣重要。

當您自動化 Kubernetes 日誌收集和分析時，可以避免陷入 Kubernetes 日誌過度複雜的困境。您可以專注於從這些日誌中獲得可操作的可見性，而不是費力地找出每個日誌的儲存位置，以及如何在它們消失之前加以收集。

您可以使用 Splunk Log Observer 解決這個問題。Splunk Log Observer 會自動從 Kubernetes 環境的所有元件中收集所有類型的日誌，還能免除手動彙整日誌的需要。透過與 Splunk Infrastructure Monitoring Kubernetes Navigator 整合，Splunk Log Observer 能分析 Kubernetes 日誌資料以及 Kubernetes 可見性的其他重要來源，確保您可以獲得完整的可觀察性。

不要讓 Kubernetes 日誌管理的問題妨礙您獲得 Kubernetes 叢集的真正可觀察性。讓 Splunk 幫您完成繁瑣的日誌收集和關聯工作，如此一來您可以專注於分析日誌，並利用獲得的洞察力來推動 Kubernetes 的效能最佳化。

Log Observer 是 Splunk Observability Cloud 的組成元件可為網站可靠性工程師 (SRE)、開發營運工程師和開發人員提供了 Splunk 日誌記錄的強大功能，透過適用於 IT 監控、故障排除和調查的無縫且簡化的工作流程，在幾分鐘內就能發現問題並加以排除。觀看 Splunk Observability Cloud 示範，了解如何從單一使用者介面直接檢視所有指標、追翁和日誌資料，進行以故障排除為導向的日誌操作。

此貼文僅為個人意見，不代表 Splunk 的立場、策略或意見。本文改寫自 Bill Emmett 撰寫的一篇文章。
https://www.splunk.com/en_us/blog/learn/kubernetes-logging.html


作者
Stephen Watts
Stephen Watts 在 Splunk 負責不斷成長的行銷工作。Stephen 擁有美國奧本大學的哲學學位，並是加州大學丹佛分校的準資訊管理碩士。他為各種出版品撰稿，包括 CIO.com、Search Engine Journal、ITSM.Tools、IT Chronicles、DZone 和 CompTIA。