Kubernetes日志傳輸過程中面臨的4個挑戰
譯文【51CTO.com快譯】如果您正在使用Kubernetes并需要進行日志記錄，您可能會面臨一些不同于虛擬機或裸機環境的問題和挑戰。
在過去的三個月里，我一直在研究PKS的可觀察特性。***，我把關注點放在了Kubernetes的日志系統上面。
收集日志，并將其發送到日志服務器。這看起來是簡單而普通的工作，不是嗎?或許有時候是這樣的吧。但是，與虛擬機或裸機環境相比，我注意到了使用容器時在日志記錄方面的一些新的挑戰。
以下是摘要。了解一下!看看您的Kubernetes項目上是否也有同樣的問題。
這篇文章的動機更多的是想要闡釋問題和技術難點。而不是關于如何解決它們。如果這里面的內容有什么不合適的地方，我會根據需要做出一些改變。
通常，日志的傳輸工作流有主動和被動之分。
主動方式：進程主動將日志消息發送到遠程的syslog服務器上。通常，數據編碼的格式是會是rfc5424。
被動方式：對于每個進程，指定其默認的日志路徑或文件模式。日志代理系統將會定期掃描它們，并將捕獲的日志消息發送到日志服務器上面。
你可能認為問題已經解決了!還沒有，我的朋友們。
在容器中運行服務與在虛擬機或裸機中有所不同。因為我們將要面臨的新趨勢是:
- 這個過程將更加短暫。
- 流程部署將更加分散。
而這對容器的日志記錄意味著什么?
挑戰I：無法收集所有的關鍵日志
當出現問題時，Pod(容器的集合)可能會被刪除或快速被重新創建。因此，與Pod/容器相關聯的日志文件將被快速刪除或重建。
然而，像Fluentd或log stash這樣的日志代理通常是通過定期掃描文件夾或日志模式來檢測新的日志文件的。默認的掃描間隔可能是60秒(見下圖)。很可能會因為掃描間隔太長而無法捕獲短壽命的容器日志。那我們把時間間隔設置得更短，比如1秒，這樣又如何呢?顯然這會帶來更高的性能開銷。
這在以前的虛擬機世界中不會是個問題。當進程以某種方式重新啟動時，日志文件可能會被輪換，而不是刪除。此時，用戶接收日志的速度可能只是會變慢。但不會缺少問題流程的關鍵日志。
我們如何解決這個問題呢?目前還沒有所謂的***實踐，我們也在探索。也許我們可以啟動一個訂閱pod事件的Kubernetes控制器。每當觸發pod創建事件時，立即通知日志代理。 honeycomb-kubernetes-agent就是一個有趣的實現了這個想法的GitHub項目。如果您有更好的解決方案，請留下評論。
然而，并不是所有日志都會被重定向到stdout/stderr之中。如果pod內的進程將日志寫入本地文件，而不是stdout/stderr當中，那么日志代理系統無法獲取這些日志。
為什么? 日志代理系統只會監視與pod相關的日志文件，如下所示。該日志文件將只捕獲容器的stdout/stderr。
- # ls -1 /var/lib/docker/containers/*/*-json.log
- ls -1 /var/lib/docker/containers/*/*-json.log
- /var/lib/docker/containers/0470.../0470...-json.log
- /var/lib/docker/containers/0645.../0645...-json.log
- /var/lib/docker/containers/12d2.../12d2...-json.log
- ...
- ...
是的，這種日志記錄行為的確是Kubernetes世界的一種反模式。然而，云原生運動的發展仍然需要時間，不是每個人都能夠緊跟潮流。對于數據庫服務來說尤其如此。
與虛擬機世界相比，Pod可能會經常在不同的工作節點中移動。您肯定不希望每當K8s集群有一個pod更改時，就需要重新加載或重新啟動日志代理。這是新的挑戰,對吧?
挑戰II：日志命名空間下的多租戶
Kubernetes的工作負載通常會在共享工作虛擬機中運行。來自不同項目的工作負載會以不同命名空間來進行劃分。
不同的項目可能對日志記錄有不同的偏好。日志轉到哪里，由什么工具管理，等等，都需要提供一種簡單的配置方式，并且沒有額外的安全隱患。
事實證明，在這方面，Kubernetes CRD (CustomResourceDefinition)是一個非常好的工具。
- 您需要學習的只是標準的kubectl命令。(參見kubectl備忘錄)。
- RBAC可以在這里用于資源的自定義。安全性也可以得到保證。
在PKS中，我們將這個特性稱為資源的sink。注意：這個想法已經提交給了Kubernetes社區。希望它能很快并入Kubernetes上游。
挑戰III：支持為不同命名空間使用不同的日志SLA
為了方便，人們通常只需要部署一個日志代理來作為Kubernetes daemonset。這意味著每個Kubernetes工作節點只有一個pod。如果因為某種原因需要重新加載或重新安排此pod，它將影響在此工作節點中的所有Pod。
從K8s v1.12開始，你可以在每個節點上運行100個pod。相應的,你需要確保你的日志代理足夠快，以便從所有pod中收集日志。
像任何共享的環境一樣，您可能會遇到一個嘈雜的鄰居問題。一個Pod的不當行為可能會損害同一工作節點中的所有其他pod。想要禁用一個有問題的命名空間的日志記錄?雖然你可以很容易的將整個日志系統關閉，卻無法繼續收集需要收集的日志了。
另外，慢速的磁盤可能會給日志傳輸帶來顯著的延遲。如果無法及時處理日志的背壓問題可能會導致日志代理的DDoS。
挑戰四：處理來自不同層級的日志記錄
如下圖所示，我們有pod日志、K8s日志和平臺日志。即使是對于“pod日志”，我們也有來自標準工作負載或K8s加載項的日志。
正如你可能猜測的，不同類型的日志具有不同的特性，以及不同的優先級。不僅是層與層之間，有時同一層的內部也有不同的SLA。
為了提供K8s解決方案，我們可以如何解決這個問題呢?你需要在協助項目經理和開發人員迅速找出問題根源的同時，盡量減少安全隱患。
什么是PKS?PKS是一個來自VMware和Pivotal的企業級Kubernetes解決方案。
原文地址: 4 Challenges In Kubernetes Log Transport ,作者：Denny Zhang
【51CTO譯稿，合作站點轉載請注明原文譯者和出處為51CTO.com】
