您正在查看 Kubernetes 版本的文档： v1.18

Kubernetes v1.18 版本的文档已不再维护。您现在看到的版本来自于一份静态的快照。如需查阅最新文档，请点击最新版本。

日志架构

应用和系统日志可以让你了解集群内部的运行状况。日志对调试问题和监控集群活动非常有用。大部分现代化应用都有某种日志记录机制；同样地，大多数容器引擎也被设计成支持某种日志记录机制。针对容器化应用，最简单且受欢迎的日志记录方式就是写入标准输出和标准错误流。

但是，由容器引擎或运行时提供的原生功能通常不足以满足完整的日志记录方案。例如，如果发生容器崩溃、Pod 被逐出或节点宕机等情况，你仍然想访问到应用日志。因此，日志应该具有独立的存储和生命周期，与节点、Pod 或容器的生命周期相独立。这个概念叫 集群级的日志 。集群级日志方案需要一个独立的后台来存储、分析和查询日志。 Kubernetes 没有为日志数据提供原生存储方案，但是你可以集成许多现有的日志解决方案到 Kubernetes 集群中。

集群级日志架构假定在集群内部或者外部有一个日志后台。如果你对集群级日志不感兴趣，你仍会发现关于如何在节点上存储和处理日志的描述对你是有用的。

Kubernetes 中的基本日志记录

本节，你会看到一个kubernetes 中生成基本日志的例子，该例子中数据被写入到标准输出。这里通过一个特定的 Pod 规约演示创建一个容器，并令该容器每秒钟向标准输出写入数据。

debug/counter-pod.yaml Copy debug/counter-pod.yaml to clipboard

apiVersion: v1
kind: Pod
metadata:
  name: counter
spec:
  containers:
  - name: count
    image: busybox
    args: [/bin/sh, -c,
            'i=0; while true; do echo "$i: $(date)"; i=$((i+1)); sleep 1; done']

用下面的命令运行 Pod：

kubectl apply -f https://k8s.io/examples/debug/counter-pod.yaml

输出结果为：

pod/counter created

使用 kubectl logs 命令获取日志:

kubectl logs counter

输出结果为：

0: Mon Jan  1 00:00:00 UTC 2001
1: Mon Jan  1 00:00:01 UTC 2001
2: Mon Jan  1 00:00:02 UTC 2001
...

一旦发生容器崩溃，你可以使用命令 kubectl logs 和参数 --previous 检索之前的容器日志。如果 pod 中有多个容器，你应该向该命令附加一个容器名以访问对应容器的日志。详见 kubectl logs 文档。

节点级日志记录

节点级别的日志记录

容器化应用写入 stdout 和 stderr 的任何数据，都会被容器引擎捕获并被重定向到某个位置。例如，Docker 容器引擎将这两个输出流重定向到某个日志驱动，该日志驱动在 Kubernetes 中配置为以 JSON 格式写入文件。

说明： Docker JSON 日志驱动将日志的每一行当作一条独立的消息。该日志驱动不直接支持多行消息。你需要在日志代理级别或更高级别处理多行消息。

默认情况下，如果容器重启，kubelet 会保留被终止的容器日志。如果 Pod 在工作节点被驱逐，该 Pod 中所有的容器也会被驱逐，包括容器日志。

节点级日志记录中，需要重点考虑实现日志的轮转，以此来保证日志不会消耗节点上所有的可用空间。 Kubernetes 当前并不负责轮转日志，而是通过部署工具建立一个解决问题的方案。例如，在 Kubernetes 集群中，用 kube-up.sh 部署一个每小时运行的工具 logrotate。你也可以设置容器 runtime 来自动地轮转应用日志，比如使用 Docker 的 log-opt 选项。在 kube-up.sh 脚本中，使用后一种方式来处理 GCP 上的 COS 镜像，而使用前一种方式来处理其他环境。这两种方式，默认日志超过 10MB 大小时都会触发日志轮转。

例如，你可以找到关于 kube-up.sh 为 GCP 环境的 COS 镜像设置日志的详细信息，相应的脚本在这里

当运行 kubectl logs 时，节点上的 kubelet 处理该请求并直接读取日志文件，同时在响应中返回日志文件内容。

说明： 当前，如果有其他系统机制执行日志轮转，那么 kubectl logs 仅可查询到最新的日志内容。比如，一个 10MB 大小的文件，通过logrotate 执行轮转后生成两个文件，一个 10MB 大小，一个为空，所以 kubectl logs 将返回空。

系统组件日志

系统组件有两种类型：在容器中运行的和不在容器中运行的。例如：

在容器中运行的 kube-scheduler 和 kube-proxy。
不在容器中运行的 kubelet 和容器运行时（例如 Docker）。

在使用 systemd 机制的服务器上，kubelet 和容器 runtime 写入日志到 journald。如果没有 systemd，他们写入日志到 /var/log 目录的 .log 文件。容器中的系统组件通常将日志写到 /var/log 目录，绕过了默认的日志机制。他们使用 klog 日志库。你可以在日志开发文档找到这些组件的日志告警级别协议。

和容器日志类似，/var/log 目录中的系统组件日志也应该被轮转。通过脚本 kube-up.sh 启动的 Kubernetes 集群中，日志被工具 logrotate 执行每日轮转，或者日志大小超过 100MB 时触发轮转。

集群级日志架构

虽然Kubernetes没有为集群级日志记录提供原生的解决方案，但你可以考虑几种常见的方法。以下是一些选项：

使用在每个节点上运行的节点级日志记录代理。
在应用程序的 pod 中，包含专门记录日志的 sidecar 容器。
将日志直接从应用程序中推送到日志记录后端。

使用节点级日志代理

使用节点日志记录代理

你可以通过在每个节点上使用 节点级的日志记录代理 来实现群集级日志记录。日志记录代理是一种用于暴露日志或将日志推送到后端的专用工具。通常，日志记录代理程序是一个容器，它可以访问包含该节点上所有应用程序容器的日志文件的目录。

由于日志记录代理必须在每个节点上运行，它可以用 DaemonSet 副本，Pod 或本机进程来实现。然而，后两种方法被弃用并且非常不别推荐。

对于 Kubernetes 集群来说，使用节点级的日志代理是最常用和被推荐的方式，因为在每个节点上仅创建一个代理，并且不需要对节点上的应用做修改。但是，节点级的日志 仅适用于应用程序的标准输出和标准错误输出。

Kubernetes 并不指定日志代理，但是有两个可选的日志代理与 Kubernetes 发行版一起发布。 Stackdriver 日志适用于 Google Cloud Platform，和 Elasticsearch。你可以在专门的文档中找到更多的信息和说明。两者都使用 fluentd 与自定义配置作为节点上的代理。

使用 sidecar 容器和日志代理

你可以通过以下方式之一使用 sidecar 容器：

sidecar 容器将应用程序日志传送到自己的标准输出。
sidecar 容器运行一个日志代理，配置该日志代理以便从应用容器收集日志。

传输数据流的 sidecar 容器

数据流容器的 Sidecar 容器

利用 sidecar 容器向自己的 stdout 和 stderr 传输流的方式，你就可以利用每个节点上的 kubelet 和日志代理来处理日志。 sidecar 容器从文件、套接字或 journald 读取日志。每个 sidecar 容器打印其自己的 stdout 和 stderr 流。

这种方法允许你将日志流从应用程序的不同部分分离开，其中一些可能缺乏对写入 stdout 或 stderr 的支持。重定向日志背后的逻辑是最小的，因此它的开销几乎可以忽略不计。另外，因为 stdout、stderr 由 kubelet 处理，你可以使用内置的工具 kubectl logs。

考虑接下来的例子。pod 的容器向两个文件写不同格式的日志，下面是这个 pod 的配置文件:

admin/logging/two-files-counter-pod.yaml Copy admin/logging/two-files-counter-pod.yaml to clipboard

apiVersion: v1
kind: Pod
metadata:
  name: counter
spec:
  containers:
  - name: count
    image: busybox
    args:
    - /bin/sh
    - -c
    - >
      i=0;
      while true;
      do
        echo "$i: $(date)" >> /var/log/1.log;
        echo "$(date) INFO $i" >> /var/log/2.log;
        i=$((i+1));
        sleep 1;
      done
    volumeMounts:
    - name: varlog
      mountPath: /var/log
  volumes:
  - name: varlog
    emptyDir: {}

在同一个日志流中有两种不同格式的日志条目，这有点混乱，即使你试图重定向它们到容器的 stdout 流。取而代之的是，你可以引入两个 sidecar 容器。每一个 sidecar 容器可以从共享卷跟踪特定的日志文件，并重定向文件内容到各自的 stdout 流。

这是运行两个 sidecar 容器的 Pod 文件。

admin/logging/two-files-counter-pod-streaming-sidecar.yaml Copy admin/logging/two-files-counter-pod-streaming-sidecar.yaml to clipboard

apiVersion: v1
kind: Pod
metadata:
  name: counter
spec:
  containers:
  - name: count
    image: busybox
    args:
    - /bin/sh
    - -c
    - >
      i=0;
      while true;
      do
        echo "$i: $(date)" >> /var/log/1.log;
        echo "$(date) INFO $i" >> /var/log/2.log;
        i=$((i+1));
        sleep 1;
      done
    volumeMounts:
    - name: varlog
      mountPath: /var/log
  - name: count-log-1
    image: busybox
    args: [/bin/sh, -c, 'tail -n+1 -f /var/log/1.log']
    volumeMounts:
    - name: varlog
      mountPath: /var/log
  - name: count-log-2
    image: busybox
    args: [/bin/sh, -c, 'tail -n+1 -f /var/log/2.log']
    volumeMounts:
    - name: varlog
      mountPath: /var/log
  volumes:
  - name: varlog
    emptyDir: {}

现在当你运行这个 Pod 时，你可以分别地访问每一个日志流，运行如下命令：

kubectl logs counter count-log-1

0: Mon Jan  1 00:00:00 UTC 2001
1: Mon Jan  1 00:00:01 UTC 2001
2: Mon Jan  1 00:00:02 UTC 2001
...

kubectl logs counter count-log-2

Mon Jan  1 00:00:00 UTC 2001 INFO 0
Mon Jan  1 00:00:01 UTC 2001 INFO 1
Mon Jan  1 00:00:02 UTC 2001 INFO 2
...

集群中安装的节点级代理会自动获取这些日志流，而无需进一步配置。如果你愿意，你可以配置代理程序来解析源容器的日志行。

注意，尽管 CPU 和内存使用率都很低（以多个 cpu millicores 指标排序或者按内存的兆字节排序），向文件写日志然后输出到 stdout 流仍然会成倍地增加磁盘使用率。如果你的应用向单一文件写日志，通常最好设置 /dev/stdout 作为目标路径，而不是使用流式的 sidecar 容器方式。

应用本身如果不具备轮转日志文件的功能，可以通过 sidecar 容器实现。该方式的一个例子是运行一个定期轮转日志的容器。然而，还是推荐直接使用 stdout 和 stderr，将日志的轮转和保留策略交给 kubelet。

具有日志代理功能的 sidecar 容器

日志记录代理功能的 sidecar 容器

如果节点级日志记录代理程序对于你的场景来说不够灵活，你可以创建一个带有单独日志记录代理程序的 sidecar 容器，将代理程序专门配置为与你的应用程序一起运行。

说明： 在 sidecar 容器中使用日志代理会导致严重的资源损耗。此外，你不能使用 kubectl logs 命令访问日志，因为日志并没有被 kubelet 管理。

例如，你可以使用 Stackdriver，它使用 fluentd 作为日志记录代理。以下是两个可用于实现此方法的配置文件。第一个文件包含配置 fluentd 的 ConfigMap。

admin/logging/fluentd-sidecar-config.yaml Copy admin/logging/fluentd-sidecar-config.yaml to clipboard

apiVersion: v1
kind: ConfigMap
metadata:
  name: fluentd-config
data:
  fluentd.conf: |
    <source>
      type tail
      format none
      path /var/log/1.log
      pos_file /var/log/1.log.pos
      tag count.format1
    </source>

    <source>
      type tail
      format none
      path /var/log/2.log
      pos_file /var/log/2.log.pos
      tag count.format2
    </source>

    <match **>
      type google_cloud
    </match>

说明： 配置 fluentd 超出了本文的范围。要进一步了解如何配置 fluentd，请参考 fluentd 官方文档.

第二个文件描述了运行 fluentd sidecar 容器的 Pod 。flutend 通过 Pod 的挂载卷获取它的配置数据。

admin/logging/two-files-counter-pod-agent-sidecar.yaml Copy admin/logging/two-files-counter-pod-agent-sidecar.yaml to clipboard

apiVersion: v1
kind: Pod
metadata:
  name: counter
spec:
  containers:
  - name: count
    image: busybox
    args:
    - /bin/sh
    - -c
    - >
      i=0;
      while true;
      do
        echo "$i: $(date)" >> /var/log/1.log;
        echo "$(date) INFO $i" >> /var/log/2.log;
        i=$((i+1));
        sleep 1;
      done
    volumeMounts:
    - name: varlog
      mountPath: /var/log
  - name: count-agent
    image: k8s.gcr.io/fluentd-gcp:1.30
    env:
    - name: FLUENTD_ARGS
      value: -c /etc/fluentd-config/fluentd.conf
    volumeMounts:
    - name: varlog
      mountPath: /var/log
    - name: config-volume
      mountPath: /etc/fluentd-config
  volumes:
  - name: varlog
    emptyDir: {}
  - name: config-volume
    configMap:
      name: fluentd-config

一段时间后，你可以在 Stackdriver 界面看到日志消息。

记住，这只是一个例子，事实上你可以用任何一个日志代理替换 fluentd ，并从应用容器中读取任何资源。

从应用中直接暴露日志目录

直接从应用程序暴露日志

通过暴露或推送每个应用的日志，你可以实现集群级日志记录；然而，这种日志记录机制的实现已超出 Kubernetes 的范围。