本文簡單整理 Kubernetes 裏關於容器應用日誌的四種收集方式。
文章目錄
首先解釋下容器日誌原則：
- 日誌收集方案一般需要想辦法把日誌數據轉發到後端（Loging Backend）裏存儲然後處理。
- 因爲Kubernetes 裏面對容器日誌的處理過程應該與容器、Pod 以及 Node 的生命週期都是完全無關的。這種設計是爲了保證，無論是容器掛了、Pod 被刪除，甚至節點宕機的時候，應用的日誌依然可以被正常獲取到。
下面整理幾種日誌收集方案：
一、直接指定方案
（app容器 - 後端）
最直接的方式，在編寫應用的時候，就直接指定好日誌的存儲後端，如下所示：
在這種方案下，Kubernetes 就完全不必操心容器日誌的收集了。但這僅適用於本身已經有完善的日誌處理系統的公司。
二、NodeAgent 方案
（app容器 - [stdout/stderr] - NodeAgent - 後端）
這個方案，在社區裏是最常用的一種。
在 Node 上部署 logging agent（一般都會以 DaemonSet 的方式運行），將日誌文件轉發到後端存儲裏保存起來。
過程解釋：
- 應用 Pod 裏的容器 app-container 產生日誌輸出到 stdout 和 stderr
- 對於一個容器來說，當應用把日誌輸出到 stdout 和 stderr 之後，容器項目在默認情況下就會把這些日誌輸出到宿主機上的一個 JSON 文件裏。（這樣通過 kubectl logs 命令就可以看到這些容器的日誌了）
- logging agent 將日誌文件轉發到後端存儲裏
另外， logrotate，在日誌文件超過 10MB 的時候會自動對日誌文件進行 rotate 操作
優點與不足：
最大的優點在於一個節點只需要部署一個 agent，並且不會對應用和 Pod 有任何侵入性。
不足之處就在於，它要求應用輸出的日誌，都必須是直接輸出到容器的 stdout 和 stderr 裏。因爲 stdout 的數據會默認輸出到容器之外的宿主機，但如果日誌直接輸出到了容器內的某個文件裏，或者輸出到了遠程存儲裏，就不適用了。
三、Sidecar + NodeAgent 方案
（app容器 - Sidecar - [stdout/stderr] - NodeAgent - 後端）
這種方案針對容器應用產生的日誌不輸出到 stdout/stderr 上的特殊情況。但實際上存在兩份相同的日誌文件，浪費磁盤空間。
通過一個 sidecar 容器把日誌文件重新輸出到 sidecar 的 stdout 和 stderr 上，然後再利用 logging agent 將日誌文件轉發到後端。
過程解釋：
- 應用 Pod 裏的容器 app-container 產生日誌輸出到容器內的某個文件，因爲在容器內，外面是獲取不到的。
- 爲 Pod 添加一個 sidecar 容器，因爲 sidecar 跟主容器之間是共享 Volume 的，所以可以將容器內日誌文件內容重新以 stdout 和 stderr 的方式輸出出來。
- 對於輸出到 stdout 和 stderr 的內容，容器項目會默認地把這些日誌輸出到宿主機上的一個 JSON 文件裏。
- logging agent 將日誌文件轉發到後端存儲裏
分析：
此方案的額外性能損耗雖然並不高，也就是 sidecar 多佔用一點 CPU 和內存罷了。但需要注意的是，這時候宿主機上實際上會存在兩份相同的日誌文件：一份是應用自己寫入的；另一份則是 sidecar 的 stdout 和 stderr 對應的 JSON 文件。這對磁盤是很大的浪費。
所以，除非萬不得已或者應用容器完全不可能被修改，其他不推薦使用此方案
四、SidecarAgent 方案
（app容器 - SidecarAgent - 後端）
通過一個 sidecar 容器，直接把應用的日誌文件發送到後端遠程存儲裏面去。
這種方案也可以處理容器應用產生的日誌不輸出到 stdout/stderr 上的特殊情況，但這個 sidecar 容器會消耗較多的資源，甚至拖垮應用容器。
總結
綜合對比以上幾種方案，建議將應用日誌輸出到 stdout 和 stderr，然後通過在宿主機上部署 logging-agent 的方式來集中處理日誌。這種方案不僅管理簡單，kubectl logs 也可以用，而且可靠性高，並且宿主機本身，很可能就自帶了 rsyslogd 等非常成熟的日誌收集組件來供你使用。
圖片均來自於張磊老師極客時間課程《深入剖析 Kubernetes》，也是本文的主要參考資料
