我有一个 Kubernetes 集群，它有一些应用程序 pod，这些 pod 在每个 pod 内生成多个日志文件。我想将这些文件记录在像 elasticsearch 这样的集中式日志记录解决方案中。日志既不是 pod 的 stdout/stderr 的一部分，也不是作为主机卷安装的。所以基本上我需要一些解决方案，从我的 pod 读取文件并将其发送到 elasticsearch 或其他一些日志记录解决方案。
此外，我需要一个针对相同用例的解决方案，但如果独立 Docker 容器未在 Kubernetes 上运行。
最佳答案
nor they are mounted as host volume
这是您的问题:您需要公开一个是主机卷的路径，以便您现有的集中式日志分析工具可以看到它们。我知道这样做时唯一的星号是要注意权限，如果您的进程以 root 身份运行，这将不是问题，但如果不是 root 则将成为问题 - 您需要批量安装主机具有允许容器进程打开文件的权限的目录。
但是，我已经有足够长的时间知道在处理容器化软件时总是有“是的，但是”，所以您可以考虑另外两种选择。
如果您正在使用一种现有的日志聚合工具，它希望所有日志输出都出现在容器的标准输出和标准错误中，那么您将希望利用容器内根进程的能力来写入任何文件以将日志发送到容器的标准输出和标准错误的“pid 1”，以我知道的至少两种方式之一:
直接记录到标准输出
一些日志框架会容忍被赋予一个“文件路径”，并且会愉快地打开它并开始写入它:
<log4j:configuration>
<appender name="DOCKER_STDOUT" class="org.apache.log4j.FileAppender">
<param name="File" value="/proc/1/fd/1"/>
顺便说一句:这只是一个例子，我现在不知道 log4j 是否容忍这样的事情
重定向到标准输出
与之前的策略类似，优点是不需要更改应用程序配置，并且 100% 的时间都在工作；但缺点是集群内部署要复杂得多。
我不得不用 kong:0.10 来做这个技巧容器，因为它们的日志记录情况只写入文件，并且不允许像上面那样指向文件描述符。
需要修改 command: block 来启动应用程序，然后为容器内日志生成一个 tail，或者使用某种后置exec 中的部署技巧并启动 tail:
tail -f /the/inside/file.log > /proc/1/fd/1
如果应用程序从 tail 下方旋转文件，则选择使用“tail -F”，如果需要，则使用 nohup tail -F ... &当部署后 exec shell 退出时保护进程不被终止
关于docker - 基于 pod 内文件的 Kubernetes 日志记录，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/49582078/