Kubernetes 日誌傳輸中的四大挑戰

收集日誌，並將數據發送到日誌伺服器，這一動作看起來簡單，但其實並不是一件容易的事。比如：容器日誌收集，就存在諸多挑戰。

日誌傳輸，通常包含兩大類：一個是主動方式;一個是被動方式。

主動方式，是指整個進程主動向遠程syslog伺服器發送日誌消息。通常，數據編碼的格式是rfc5424。

被動方式，是指部署每個進程的日誌路徑或文件模式。 LogAgent會定期掃描，並將捕獲的日誌消息發送到日誌伺服器。

但是在容器日誌收集中，上述方法並不適用。首先，日誌收集過程更快。其次，流程部署更加分散式。

具體而言，容器日誌收集面臨著四大挑戰：

一、未能收集所有關鍵日誌

當出現問題時，pods 可能會被刪除或重新創建。因此，與pod/container相關聯的日誌文件將被快速刪除/創建。

藉助LogAgent(如Fluentd或Logstash)，我們可以定期掃描文件夾，或利用內置模式定義自動檢測日誌，並且默認掃描間隔為60秒(見下圖)。掃描間隔太慢，將無法及時捕捉pod。假如：我們把間隔設得短一些，比如1秒，性能提升要高得多，但是會出現日誌丟失現象。

此前，在VM環境下，就不用擔心會出現類似問題。當進程以某種方式重新啟動時，日誌文件可能會被改變，但不會被刪除。最多只是感覺到日誌收集速度變慢，但不會丟失關鍵日誌。

如何解決這一問題?我們可以通過Kubernetes雲控制器功能來監控pod。每當啟動pod創建事件時，立即通知LogAgent。honeycomb- kubernetts -agent是一個有機統一體。

值得一提的是，不是所有日誌都被重定向到stdout/stderr。如果pod內的進程將日誌寫入本地文件，而不是stdout/stderr，LogAgent將無法獲得日誌，系統只監視與pod關聯的日誌文件，如下所示。該日誌文件將只捕獲容器的stdout/stderr。

這種日誌記錄行為是Kubernetes環境下的模式。儘管，雲原生移動確實需要時間，但並不是每個應用都是最前沿應用，對於DB服務尤其如此。

與VM環境相比，容器日誌收集更靈活，Pod可以經常在不同的工作節點上移動。但是，誰都不希望每當K8s集群有一個pod更改時，就要重新載入或重新啟動LogAgent，這絕對是一個新的挑戰。

二、Namespaces的多租戶問題

Kubernetes工作負載通常運行在vm共享工作站中。由Namespaces來區分來自不同項目的工作負載分。不同的項目可能對日誌記錄有不同的偏好。日誌到哪裡，由什麼工具管理，都需要提供一種簡單的配置方式，而不需要安裝其他應用。

在筆者看來，Kubernetes CRD (CustomResourceDefinition自定義資源定義)非常好用。你需要學習的只是標準的kubectl命令。RBAC可以藉此應用定製資源。所以，Kubernetes CRD安全並且簡單，更容易執行。在PKS中，我們將這個特性稱為sink資源。

三、如何在不同的Namespaces下支持SLA

為了讓操作更簡單，人們通常只部署一個LogAgent作為Kubernetes daemonset。這代表每個Kubernetes工作節點有一個pod。如果這個pod需要重新載入或重新調度，它將影響這個工作節點中的所有pod。

從K8s v1.12開始，每個節點可以運行100個pod。你需要確保LogAgent足夠快，可以從所有pod中收集日誌。像任何共享環境一樣，你可能會遇到錯綜複雜的關聯問題。一個pod的錯誤行為會損傷同一工作節點中的所有其他pod。

可能每個人都會想到，讓有問題的Namespaces禁用禁用日誌記錄，這樣我們可以很容易避免發出日誌，不會影響日誌收集。但是，緩慢的磁碟處理可能會對日誌傳輸造成明顯的延遲。

四、如何處理來自不同層面的日誌記錄

如下圖所示，我們有pod日誌、K8s日誌和平台日誌。即使對於「pod日誌」，我們也有來自標準工作負載或K8s附加組件的日誌。

而不同類型的日誌具有不同的特徵。他們可能會有不同優先順序別事項。不僅是層對層，而且是同一層的不同SLA。

在K8s解決方案中，我們如何解決這一問題?如何協助項目經理/開發人員迅速找出問題的根源?如何減少安裝與部署環節?PKS可能是最佳選擇!

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！