kubernetes pod 的日志究竟来自哪里（在容器级别）？

Question

我希望将运行的命令中的一些日志重定向kubectl exec到该 pod 的日志，以便可以使用kubectl logs <pod-name>（或实际上，/var/log/containers/<pod-name>.log）读取它们。我可以在运行命令时看到我需要的日志作为输出，并且它们存储在正在运行的容器内的单独日志目录中。

将输出（即>> logfile.log）重定向到我认为是镜像内容的文件kubectl logs <pod-name>不会更新该容器的日志，也不会重定向到标准输出。

调用时kubectl logs <pod-name>，我的理解是 kubelet 从它的内部/var/log/containers/目录中获取它们。但是什么决定了哪些日志存储在那里？它与日志存储在任何其他 docker 容器中的过程相同吗？

有没有办法检查/跟踪日志记录过程，或确定这些日志的来源？

Answer 1

Pod 中容器的日志STDOUT和日志STDERR被捕获并存储在 /var/log/containers 中的文件中。这kubectl log是运行时显示的内容。

为了理解为什么在运行时没有显示 kubectl exec 运行的命令的输出kubectl log，让我们通过一个例子来看看它是如何工作的：

首先启动一个运行 ubuntu 并且永远休眠的 pod：

$> kubectl run test --image=ubuntu --restart=Never -- sleep infinity

执行进去

$> kubectl exec -it test bash

从容器内部看，正在捕获的是 PID 1的STDOUT和STDERR。当您kubectl exec对容器执行 a 时，会创建一个与 PID 1 一起存在的新进程：

root@test:/# ps -auxf
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root         7  0.0  0.0  18504  3400 pts/0    Ss   20:04   0:00 bash
root        19  0.0  0.0  34396  2908 pts/0    R+   20:07   0:00  \_ ps -auxf
root         1  0.0  0.0   4528   836 ?        Ss   20:03   0:00 sleep infinity

重定向到STDOUT不起作用，因为它/dev/stdout是访问它的进程的符号链接（/proc/self/fd/1而不是/proc/1/fd/1）。

root@test:/# ls -lrt /dev/stdout
lrwxrwxrwx 1 root root 15 Nov  5 20:03 /dev/stdout -> /proc/self/fd/1

为了查看与日志一起运行kubectl exec的命令的日志，需要将日志重定向到由 kubelet（STDOUT和STDERRpid 1）捕获的流。这可以通过将输出重定向到/proc/1/fd/1.

root@test:/# echo "Hello" > /proc/1/fd/1

退出交互式 shell 并使用检查日志kubectl logs现在应该显示输出

$> kubectl logs test
Hello