在開始這篇文章之前,首先要明確一點: Kubernetes 中對容器日志的處理方式,都叫做 cluster-level-logging ,也就是說,這個日志處理系統,與容器, Pod 以及 Node 的生命周期都是完全無關的.其實想想也能知道,這種設計就是為了保證,無論是容器宕了, Pod 被刪除甚至是節點宕機的時候,日志處理系統仍然可以被正常獲取到,從而可以分析原因所在.
而對於一個容器來說,當應用把日志輸出到 stdout 和 stderr 之后,容器項目在默認情況下,就會把這些日志輸出到宿主機上的一個 JSON 文件中,這樣,我就能夠通過 kubectl logs 命令,來查看到這些容器的日志.
但是你要明白一點,那就是 Kubernetes 本身,實際上是不會做容器日志收集工作的,所以為了能夠實現上述 cluster-level-logging ,就需要在部署集群的時候,就提前對具體的日志方案進行規划.所幸, Kubernetes 項目本身提供了三種相關方案.
接下來分別講一講.
| 第一種 |
在 Node 上部署 logging agent ,將日志文件轉發到后端存儲里保存起來.這個方案的架構圖如下所示:
從中我們能夠看到,這里的核心在於 logging agent ,它一般都會以 DaemonSet 的方式運行在節點上,然后將宿主機上的容器日志目錄掛載進去,最后由 logging-agent 把日志轉發出去.那么,這樣一來,我只需要在一個節點上部署一個 agent 即可,這樣也不會對應用和 Pod 有任何侵入性.
但是這種方案,要求應用輸出的日志,都必須是直接輸出到容器的 stdout 和 stderr 中.
這也就引出了第二種解決方案.
| 第二種 |
第二種情況,主要就是對上面所述缺點的一個處理,即:當容器的日志只能輸出到某些文件中時,可以通過一個 sidecar 容器將這些日志文件重新輸出到 sidecar 的 stdout 和 stderr 中.
這種解決方案的架構圖如下:
因為 sidecar 和主容器之間是共享 Volume 的,所以這里的 sidecar 方案的額外性能損耗並不高,只不過是多用了一點兒 CPU 和內存罷了.
但是要了解一點,這種方案下,宿主機上會存在兩份相同的日志文件:一份是應用自己寫入的,另外一份則是 sidecar 的 stdout 和 stderr 對應的 JSON 文件.這樣就會造成對磁盤的巨大浪費.
所以,如果不是萬不得已,也不是應用容器完全不可能被修改,還是建議使用方案一,或者使用下面介紹的方案三.
當然了,土豪隨意,畢竟開心才是重要的.
| 第三種 |
第三種方案,就是通過 sidecar 容器,直接將應用的日志文件發送到遠程存儲里面去.也就是,方案一中的 logging agent ,放在應用 Pod 中.繼續上一張架構圖:
在這種方案下,應用可以直接把日志輸出到固定的文件中,而不是 stdout , logging-agent 還可以使用 fluentd ,后端存儲還可以是 ElasticSearch .
這種方案,部署簡單,對宿主機也非常友好,但是這個 sidecar 容器,很有可能會消耗比較多的資源,甚至會拖垮應用容器,此外,由於日志沒有輸出到 stdout 上面,所以就算你通過命令 kubectl logs 來查看,也是看不到任何日志輸出到.
以上就是關於容器日志的收集與管理的三種方案的介紹了.
有一點需要注意的是,不管到最后選擇什么方案,到最后,一定要及時將這些日志文件,從宿主機上清理掉,或者給日志目錄文件專門掛載一些容量巨大的遠程盤.要不然,一旦磁盤分區被打滿,整個系統就可能會陷入崩潰狀態,這樣造成的損失就大多了.
以上內容來自我學習<深入剖析Kubernetes>專欄文章之后的一些見解,有偏頗之處,還望指出.
感謝您的閱讀~