Kubernetes日志傳輸過程中面臨的4個(gè)挑戰(zhàn)

譯文
作者：piaoyaosuifen翻譯 2018-10-15 09:39:29

云計(jì)算 這篇文章的動(dòng)機(jī)更多的是想要闡釋問題和技術(shù)難點(diǎn)。而不是關(guān)于如何解決它們。如果這里面的內(nèi)容有什么不合適的地方，我會(huì)根據(jù)需要做出一些改變。

成都創(chuàng)新互聯(lián)公司-專業(yè)網(wǎng)站定制、快速模板網(wǎng)站建設(shè)、高性價(jià)比思禮網(wǎng)站開發(fā)、企業(yè)建站全套包干低至880元,成熟完善的模板庫(kù),直接使用。一站式思禮網(wǎng)站制作公司更省心,省錢,快速模板網(wǎng)站建設(shè)找我們，業(yè)務(wù)覆蓋思禮地區(qū)。費(fèi)用合理售后完善，十多年實(shí)體公司更值得信賴。

【51CTO.com快譯】如果您正在使用Kubernetes并需要進(jìn)行日志記錄，您可能會(huì)面臨一些不同于虛擬機(jī)或裸機(jī)環(huán)境的問題和挑戰(zhàn)。

在過去的三個(gè)月里，我一直在研究PKS的可觀察特性。***，我把關(guān)注點(diǎn)放在了Kubernetes的日志系統(tǒng)上面。

收集日志，并將其發(fā)送到日志服務(wù)器。這看起來是簡(jiǎn)單而普通的工作，不是嗎?或許有時(shí)候是這樣的吧。但是，與虛擬機(jī)或裸機(jī)環(huán)境相比，我注意到了使用容器時(shí)在日志記錄方面的一些新的挑戰(zhàn)。

以下是摘要。了解一下!看看您的Kubernetes項(xiàng)目上是否也有同樣的問題。

這篇文章的動(dòng)機(jī)更多的是想要闡釋問題和技術(shù)難點(diǎn)。而不是關(guān)于如何解決它們。如果這里面的內(nèi)容有什么不合適的地方，我會(huì)根據(jù)需要做出一些改變。

通常，日志的傳輸工作流有主動(dòng)和被動(dòng)之分。

主動(dòng)方式：進(jìn)程主動(dòng)將日志消息發(fā)送到遠(yuǎn)程的syslog服務(wù)器上。通常，數(shù)據(jù)編碼的格式是會(huì)是rfc5424。

被動(dòng)方式：對(duì)于每個(gè)進(jìn)程，指定其默認(rèn)的日志路徑或文件模式。日志代理系統(tǒng)將會(huì)定期掃描它們，并將捕獲的日志消息發(fā)送到日志服務(wù)器上面。

你可能認(rèn)為問題已經(jīng)解決了!還沒有，我的朋友們。

在容器中運(yùn)行服務(wù)與在虛擬機(jī)或裸機(jī)中有所不同。因?yàn)槲覀儗⒁媾R的新趨勢(shì)是:

1. 這個(gè)過程將更加短暫。
2. 流程部署將更加分散。

而這對(duì)容器的日志記錄意味著什么?

挑戰(zhàn)I：無法收集所有的關(guān)鍵日志

當(dāng)出現(xiàn)問題時(shí)，Pod(容器的集合)可能會(huì)被刪除或快速被重新創(chuàng)建。因此，與Pod/容器相關(guān)聯(lián)的日志文件將被快速刪除或重建。

然而，像Fluentd或log stash這樣的日志代理通常是通過定期掃描文件夾或日志模式來檢測(cè)新的日志文件的。默認(rèn)的掃描間隔可能是60秒(見下圖)。很可能會(huì)因?yàn)閽呙栝g隔太長(zhǎng)而無法捕獲短壽命的容器日志。那我們把時(shí)間間隔設(shè)置得更短，比如1秒，這樣又如何呢?顯然這會(huì)帶來更高的性能開銷。

這在以前的虛擬機(jī)世界中不會(huì)是個(gè)問題。當(dāng)進(jìn)程以某種方式重新啟動(dòng)時(shí)，日志文件可能會(huì)被輪換，而不是刪除。此時(shí)，用戶接收日志的速度可能只是會(huì)變慢。但不會(huì)缺少問題流程的關(guān)鍵日志。

我們?nèi)绾谓鉀Q這個(gè)問題呢?目前還沒有所謂的***實(shí)踐，我們也在探索。也許我們可以啟動(dòng)一個(gè)訂閱pod事件的Kubernetes控制器。每當(dāng)觸發(fā)pod創(chuàng)建事件時(shí)，立即通知日志代理。 honeycomb-kubernetes-agent就是一個(gè)有趣的實(shí)現(xiàn)了這個(gè)想法的GitHub項(xiàng)目。如果您有更好的解決方案，請(qǐng)留下評(píng)論。

然而，并不是所有日志都會(huì)被重定向到stdout/stderr之中。如果pod內(nèi)的進(jìn)程將日志寫入本地文件，而不是stdout/stderr當(dāng)中，那么日志代理系統(tǒng)無法獲取這些日志。

為什么? 日志代理系統(tǒng)只會(huì)監(jiān)視與pod相關(guān)的日志文件，如下所示。該日志文件將只捕獲容器的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世界的一種反模式。然而，云原生運(yùn)動(dòng)的發(fā)展仍然需要時(shí)間，不是每個(gè)人都能夠緊跟潮流。對(duì)于數(shù)據(jù)庫(kù)服務(wù)來說尤其如此。

與虛擬機(jī)世界相比，Pod可能會(huì)經(jīng)常在不同的工作節(jié)點(diǎn)中移動(dòng)。您肯定不希望每當(dāng)K8s集群有一個(gè)pod更改時(shí)，就需要重新加載或重新啟動(dòng)日志代理。這是新的挑戰(zhàn),對(duì)吧?

挑戰(zhàn)II：日志命名空間下的多租戶

Kubernetes的工作負(fù)載通常會(huì)在共享工作虛擬機(jī)中運(yùn)行。來自不同項(xiàng)目的工作負(fù)載會(huì)以不同命名空間來進(jìn)行劃分。

不同的項(xiàng)目可能對(duì)日志記錄有不同的偏好。日志轉(zhuǎn)到哪里，由什么工具管理，等等，都需要提供一種簡(jiǎn)單的配置方式，并且沒有額外的安全隱患。

事實(shí)證明，在這方面，Kubernetes CRD (CustomResourceDefinition)是一個(gè)非常好的工具。

1. 您需要學(xué)習(xí)的只是標(biāo)準(zhǔn)的kubectl命令。(參見kubectl備忘錄)。
2. RBAC可以在這里用于資源的自定義。安全性也可以得到保證。

在PKS中，我們將這個(gè)特性稱為資源的sink。注意：這個(gè)想法已經(jīng)提交給了Kubernetes社區(qū)。希望它能很快并入Kubernetes上游。

挑戰(zhàn)III：支持為不同命名空間使用不同的日志SLA

為了方便，人們通常只需要部署一個(gè)日志代理來作為Kubernetes daemonset。這意味著每個(gè)Kubernetes工作節(jié)點(diǎn)只有一個(gè)pod。如果因?yàn)槟撤N原因需要重新加載或重新安排此pod，它將影響在此工作節(jié)點(diǎn)中的所有Pod。

從K8s v1.12開始，你可以在每個(gè)節(jié)點(diǎn)上運(yùn)行100個(gè)pod。相應(yīng)的,你需要確保你的日志代理足夠快，以便從所有pod中收集日志。

像任何共享的環(huán)境一樣，您可能會(huì)遇到一個(gè)嘈雜的鄰居問題。一個(gè)Pod的不當(dāng)行為可能會(huì)損害同一工作節(jié)點(diǎn)中的所有其他pod。想要禁用一個(gè)有問題的命名空間的日志記錄?雖然你可以很容易的將整個(gè)日志系統(tǒng)關(guān)閉，卻無法繼續(xù)收集需要收集的日志了。

另外，慢速的磁盤可能會(huì)給日志傳輸帶來顯著的延遲。如果無法及時(shí)處理日志的背壓?jiǎn)栴}可能會(huì)導(dǎo)致日志代理的DDoS。

挑戰(zhàn)四：處理來自不同層級(jí)的日志記錄

如下圖所示，我們有pod日志、K8s日志和平臺(tái)日志。即使是對(duì)于“pod日志”，我們也有來自標(biāo)準(zhǔn)工作負(fù)載或K8s加載項(xiàng)的日志。

正如你可能猜測(cè)的，不同類型的日志具有不同的特性，以及不同的優(yōu)先級(jí)。不僅是層與層之間，有時(shí)同一層的內(nèi)部也有不同的SLA。

為了提供K8s解決方案，我們可以如何解決這個(gè)問題呢?你需要在協(xié)助項(xiàng)目經(jīng)理和開發(fā)人員迅速找出問題根源的同時(shí)，盡量減少安全隱患。

什么是PKS?PKS是一個(gè)來自VMware和Pivotal的企業(yè)級(jí)Kubernetes解決方案。

原文地址: 4 Challenges In Kubernetes Log Transport ,作者：Denny Zhang

【51CTO譯稿，合作站點(diǎn)轉(zhuǎn)載請(qǐng)注明原文譯者和出處為51CTO.com】

文章名稱：Kubernetes日志傳輸過程中面臨的4個(gè)挑戰(zhàn)
文章起源：http://m.5511xx.com/article/cciehpd.html