基于pod内部文件的Kubernetes日志记录

Question

我有一个Kubernetes集群，它有一些应用程序pod，在每个pod中生成多个日志文件。我想在集中的日志解决方案中记录这些文件，比如elasticsearch。日志既不是pod的stdout/stderr的一部分，也不是作为主机卷装载的。所以基本上我需要一些解决方案，从我的pod中读取一个文件并将其发送给elasticsearch或其他一些日志解决方案。

此外，我还需要一个解决方案，用于相同的用例，但用于独立Docker容器不在Kubernetes上运行的情况。

Answer 1

我会考虑持续体积安装到您的吊舱。使用fluentd这样的侧车容器，您可以将这些日志文件转发到elasticsearch。对于docker引擎，两个docker进程可以共享相同的卷。

Answer 2

它们也不是作为主机卷安装的

这是您的问题：您需要公开一个作为主机卷的路径，以便现有的集中式日志slurping工具可以看到它们。我所知道的唯一一个星号是注意权限，如果您的进程以root用户身份运行，这不会是一个问题，但如果不是root用户，则会是一个问题——您需要卷装载一个主机目录，该目录具有使容器进程能够打开文件的权限。

但是，我已经有足够长的时间知道在处理容器软件时总是存在“是的，但是”，所以你可以考虑另外两种选择。

如果您正在使用一个现有的日志聚合工具，该工具希望所有日志输出都显示在容器的stdout和stderr上，那么您将希望利用容器中的根进程的能力，将日志写入任何文件，以将日志发送到容器的stdout和stderr的“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容器来做这件事，因为它们的日志记录情况只写入文件，不能容忍像上面那样指向文件描述符。

您需要修改命令：块来启动应用程序，然后为容器内日志生成tail，或者使用某种部署后技巧来execin并启动tail：

tail -f /the/inside/file.log > /proc/1/fd/1

如果应用程序将文件从下面旋转出来，选择使用“尾巴-F”，并使用“尾巴-F”...