中，push業務中日誌文件需要寫入物理機磁碟長期保存。但是每個pod默認寫入的路徑相同。會存在並發寫文件造成非預期問題。（注意：emptyDir 方式不能解決我們的需求，我們的需求是日誌長期保存。即便pod終止，也不會刪除。同時能夠區分一個pod對應一個日誌文件）。

Flexvolume是否能完成我的需求？

可以用statefulset+storageclass實現

（1）另外也可以繞一下：

1. 使用一個能持久化存儲的公用目錄，比方說hostpath:/data/logs

2. 將這個目錄掛載到所有pod的/data/logs路徑

3. 在pod的/data/logs創建一個不可能重名的文件夾，比如/data/logs/pod-name

4. 將log目錄軟鏈接到pod裡面的/data/logs/pod-name目錄

（2）建議將日誌持久化放到elasticsearch裡面去，集中化管理，還能結合告警、搜索、統計等，解決方案也挺多

1. 將srv與日誌採集agent綁定在一個pod裡面採集srv日誌

2. 將srv的log用emptyDir暴露在宿主機上，自動發現日誌文件

3. srv直接將log打到kafka等消息隊列裡面中轉

4. srv打syslog然後採集

Flexvolume看介紹似乎讓用戶能夠支持一些kubernetes不支持的卷類型

我是這麼做得。

在集群外部有機器開 NFS，pod 中使用volume 掛載，pod 中的日誌文件可以寫到外部的 NFS 中。當然要包括 HOSTNAME。

可以實現你的需求，但，從目錄結構上講 ，有一節不必要的 HOSTNAME，雖然不影響 grep。

如圖

太多，一屏顯示不全

既然是永久保存，為什麼不用pv卷？pv卷不是完全符合你的要求嗎？

可以換一個思路，log寫到stdout 然後在外部統一收集處理

推薦將日誌輸出到STDOUT，這樣使用Docker log 很容易進行日誌分析

後面推薦使用Flunted將Kubernetes中的日誌全部導出到ElasterSearch來持久化存儲

具體的配置是這個 Kubernetes Logging with Fluentd

Flexvolume 是Kubernetes的存儲驅動，跟日誌關係不大

對於容器日誌，業界的普遍做法是統一採集，集中存儲。直接保存在容器所在宿主機的本地磁碟會有諸多問題，使用起來也不太方便。比如，日誌查詢分析需要登錄到相應的宿主機，耗時耗力（隨著容器或 pod 數量的增加，這種問題會愈發突出）。

對於你的場景，推薦以 DaemonSet 或 Sidecar 模式部署日誌採集 agent，然後對日誌數據進行統一存儲。

下面推薦幾篇相關的技術文章：

  • 面向容器日誌的技術實踐 - 介紹了容器日誌採集、分析、可視化的常用方法和基本原理。
  • 全面提升，阿里雲Docker/Kubernetes(K8S) 日誌解決方案與選型對比 - 全面比較了 k8s 容器日誌的常用採集方案。
  • Kubernetes日誌採集Sidecar模式介紹 - 介紹了阿里雲日誌服務目前提供的 k8s 容器日誌採集方案，包括 DaemonSet方式、Sidecar方式。

建議另外部署一個日誌服務（如ELK），系統中其它業務服務的日誌，都集中到日誌服務中，這樣容易收集、處理、檢索，乃至進行數據分析等。

日誌集中的方式也有多種：

1）業務代碼中配置並輸出日誌到目標日誌伺服器；

2）業務代碼輸出日誌到 stdout，並由k8s或相應的日誌收集agent收到到目標日誌伺服器；

3）業務代碼不變仍然輸出到文件（但不要輸出到公共PV，且設置日誌循環），再由agent收集到目標日誌伺服器。

推薦使用前兩種，不建議第3種。

推薦閱讀：
相关文章