Kubernetes 里面對容器日志的處理方式，都叫作 cluster-level-logging，即：這個日志處理系統(tǒng)，與容器、Pod 以及 Node 的生命周期都是完全無關(guān)的。這種設(shè)計當(dāng)然是為了保證，無論是容器掛了、Pod 被刪除，甚至節(jié)點宕機的時候，應(yīng)用的日志依然可以被正常獲取到。
而對于一個容器來說，當(dāng)應(yīng)用把日志輸出到 stdout 和 stderr 之后，容器項目在默認(rèn)情況下就會把這些日志輸出到宿主機上的一個 JSON 文件里。這樣，你通過 kubectl logs 命令就可以看到這些容器的日志了。
第一種，在 Node 上部署 logging agent，將日志文件轉(zhuǎn)發(fā)到后端存儲里保存起來。這個方案的架構(gòu)圖如下所示
核心就在于 logging agent ，它一般都會以 DaemonSet 的方式運行在節(jié)點上，然后將宿主機上的容器日志目錄掛載進去，最后由 logging-agent 把日志轉(zhuǎn)發(fā)出去。
在 Node 上部署 logging agent 最大的優(yōu)點，在于一個節(jié)點只需要部署一個 agent，并且不會對應(yīng)用和 Pod 有任何侵入性。所以，這個方案，在社區(qū)里是最常用的一種。
Kubernetes 容器日志方案的第二種，就是對這種特殊情況的一個處理，即：當(dāng)容器的日志只能輸出到某些文件里的時候，我們可以通過一個 sidecar 容器把這些日志文件重新輸出到 sidecar 的 stdout 和 stderr 上，這樣就能夠繼續(xù)使用第一種方案了。
?由于 sidecar 跟主容器之間是共享 Volume 的，所以這里的 sidecar 方案的額外性能損耗并不高，也就是多占用一點 CPU 和內(nèi)存罷了。
宿主機上實際上會存在兩份相同的日志文件：一份是應(yīng)用自己寫入的；另一份則是 sidecar 的 stdout 和 stderr 對應(yīng)的 JSON 文件。這對磁盤是很大的浪費。所以說，除非萬不得已或者應(yīng)用容器完全不可能被修改，否則還是建議你直接使用方案一，或者直接使用下面的第三種方案。
第三種方案，就是通過一個 sidecar 容器，直接把應(yīng)用的日志文件發(fā)送到遠程存儲里面去。也就是相當(dāng)于把方案一里的 logging agent，放在了應(yīng)用 Pod 里。這種方案的架構(gòu)如下所示：
?在這種方案里，你的應(yīng)用還可以直接把日志輸出到固定的文件里而不是 stdout，你的 logging-agent 還可以使用 fluentd，后端存儲還可以是 ElasticSearch。只不過， fluentd 的輸入源，變成了應(yīng)用的日志文件。一般來說，我們會把 fluentd 的輸入源配置保存在一個 ConfigMap 里。
這種方案雖然部署簡單，并且對宿主機非常友好，但是這個 sidecar 容器很可能會消耗較多的資源，甚至拖垮應(yīng)用容器。并且，由于日志還是沒有輸出到 stdout 上，所以你通過 kubectl logs 是看不到任何日志輸出的。文章來源：http://www.zghlxwxcb.cn/news/detail-608292.html
此文章為7月Day26學(xué)習(xí)筆記，內(nèi)容來源于極客時間《深入淺出Kubernetes》，推薦該課程。文章來源地址http://www.zghlxwxcb.cn/news/detail-608292.html
到了這里，關(guān)于K8S：容器日志收集與管理的文章就介紹完了。如果您還想了解更多內(nèi)容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！
