中，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种。

推荐阅读：
相关文章