日志记录架构

应用程序日志可以帮助您了解应用程序内部发生了什么。日志对于调试问题和监控集群活动特别有用。大多数现代应用程序都具有某种日志记录机制。同样，容器引擎也设计为支持日志记录。容器化应用程序最简单、最广泛采用的日志记录方法是写入标准输出和标准错误流。

但是，容器引擎或运行时提供的本机功能通常不足以构成完整的日志记录解决方案。

例如，如果容器崩溃、Pod 被驱逐或节点死亡，您可能希望访问应用程序的日志。

在集群中，日志应该具有独立于节点、Pod 或容器的单独存储和生命周期。这个概念称为集群级日志记录。

集群级日志记录体系结构需要单独的后端来存储、分析和查询日志。Kubernetes 没有为日志数据提供本机存储解决方案。相反，有许多与 Kubernetes 集成的日志记录解决方案。以下部分描述了如何在节点上处理和存储日志。

Pod 和容器日志

Kubernetes 从运行的 Pod 中的每个容器捕获日志。

此示例使用一个 Pod 的清单，其中包含一个将文本写入标准输出流的容器，每秒写入一次。

debug/counter-pod.yaml

apiVersion: v1
kind: Pod
metadata:
  name: counter
spec:
  containers:
  - name: count
    image: busybox:1.28
    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: Fri Apr  1 11:42:23 UTC 2022
1: Fri Apr  1 11:42:24 UTC 2022
2: Fri Apr  1 11:42:25 UTC 2022

您可以使用 kubectl logs --previous 来检索来自容器先前实例的日志。如果您的 Pod 包含多个容器，请指定要访问的容器的日志，方法是将容器名称附加到命令，并在其后加上 -c 标志，例如

kubectl logs counter -c count

有关更多详细信息，请参阅 kubectl logs 文档。

节点如何处理容器日志

容器运行时处理并重定向容器化应用程序的 stdout 和 stderr 流生成的任何输出。不同的容器运行时以不同的方式实现此操作；但是，与 kubelet 的集成已标准化为 CRI 日志记录格式。

默认情况下，如果容器重新启动，kubelet 会保留一个已终止的容器及其日志。如果 Pod 从节点中驱逐，所有相应的容器也会被驱逐，包括它们的日志。

kubelet 通过 Kubernetes API 的一项特殊功能使日志可供客户端使用。访问此功能的常用方法是运行 kubectl logs。

日志轮换

kubelet 负责轮换容器日志和管理日志目录结构。kubelet 将此信息发送到容器运行时（使用 CRI），运行时将容器日志写入指定的位置。

您可以使用 kubelet 配置设置 中的两个 kubelet kubelet 配置文件 来配置两个 kubelet 配置设置，containerLogMaxSize（默认值为 10Mi）和 containerLogMaxFiles（默认值为 5）。这些设置可让您分别配置每个日志文件的最大大小和每个容器允许的最大文件数量。

为了在日志量很大的工作负载生成的集群中执行有效的日志轮换，kubelet 还提供了一种机制来调整日志轮换的方式，例如可以执行多少个并发日志轮换以及监控日志并根据需要进行轮换的间隔。您可以使用 kubelet 配置设置 中的两个 kubelet kubelet 配置文件 来配置两个 kubelet 配置设置，containerLogMaxWorkers 和 containerLogMonitorInterval。

当您运行基本日志记录示例中的 kubectl logs 时，节点上的 kubelet 会处理请求并直接从日志文件读取。kubelet 返回日志文件的内容。

系统组件日志

系统组件有两种类型：通常在容器中运行的组件，以及直接参与运行容器的组件。例如

• kubelet 和容器运行时不在容器中运行。kubelet 运行您的容器（分组在一起形成 pod）
• Kubernetes 调度程序、控制器管理器和 API 服务器在 Pod 中运行（通常是 静态 Pod）。etcd 组件在控制平面中运行，并且最常作为静态 Pod 运行。如果您的集群使用 kube-proxy，您通常会将其作为 DaemonSet 运行。

日志位置

kubelet 和容器运行时写入日志的方式取决于节点使用的操作系统

• Linux
• Windows

对于在 Pod 中运行的 Kubernetes 集群组件，这些组件会写入 /var/log 目录中的文件，绕过默认的日志记录机制（这些组件不会写入 systemd 日志）。您可以使用 Kubernetes 的存储机制将持久性存储映射到运行该组件的容器中。

Kubelet 允许将 Pod 日志目录从默认的 /var/log/pods 更改为自定义路径。可以通过在 kubelet 的配置文件中配置 podLogsDir 参数来进行此调整。

有关 etcd 及其日志的详细信息，请查看 etcd 文档。同样，您可以使用 Kubernetes 的存储机制将持久性存储映射到运行该组件的容器中。

集群级日志记录体系结构

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

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

使用节点日志代理

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

由于日志代理必须在每个节点上运行，因此建议将代理作为 DaemonSet 运行。

节点级日志记录每个节点只创建一个代理，并且不需要对节点上运行的应用程序进行任何更改。

容器写入标准输出和标准错误，但没有统一的格式。节点级代理会收集这些日志，并将其转发以进行聚合。

使用日志代理的 sidecar 容器

您可以通过以下几种方式之一使用 sidecar 容器

• sidecar 容器将应用程序日志流式传输到其自身的 stdout。
• 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

apiVersion: v1
kind: Pod
metadata:
  name: counter
spec:
  containers:
  - name: count
    image: busybox:1.28
    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

apiVersion: v1
kind: Pod
metadata:
  name: counter
spec:
  containers:
  - name: count
    image: busybox:1.28
    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:1.28
    args: [/bin/sh, -c, 'tail -n+1 -F /var/log/1.log']
    volumeMounts:
    - name: varlog
      mountPath: /var/log
  - name: count-log-2
    image: busybox:1.28
    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: Fri Apr  1 11:42:26 UTC 2022
1: Fri Apr  1 11:42:27 UTC 2022
2: Fri Apr  1 11:42:28 UTC 2022
...

kubectl logs counter count-log-2

输出类似于

Fri Apr  1 11:42:29 UTC 2022 INFO 0
Fri Apr  1 11:42:30 UTC 2022 INFO 0
Fri Apr  1 11:42:31 UTC 2022 INFO 0
...

如果您在集群中安装了节点级代理，该代理将自动获取这些日志流，无需任何进一步的配置。如果您愿意，您可以配置代理以根据源容器解析日志行。

即使对于仅具有较低 CPU 和内存使用量的 Pod（CPU 数量级为几个毫核，内存数量级为几兆字节），将日志写入文件，然后将其流式传输到 stdout 也会使您在节点上需要的存储量增加一倍。如果您有一个写入单个文件的应用程序，建议将 /dev/stdout 设置为目标，而不是实施流式传输 sidecar 容器方法。

sidecar 容器还可用于轮换无法由应用程序本身轮换的日志文件。这种方法的一个例子是一个运行 logrotate 的小型容器，该容器定期运行。但是，直接使用 stdout 和 stderr 更简单，并将轮换和保留策略留给 kubelet。

带有日志代理的 sidecar 容器

如果节点级日志代理对于您的情况不够灵活，您可以创建一个带有独立日志代理的 sidecar 容器，该日志代理专门配置为与您的应用程序一起运行。

以下是有两个示例清单文件，您可以使用它们来实现带有日志代理的 sidecar 容器。第一个清单文件包含一个 ConfigMap，用于配置 fluentd。

admin/logging/fluentd-sidecar-config.yaml

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>    

第二个清单文件描述了一个 Pod，该 Pod 具有一个运行 fluentd 的 sidecar 容器。该 Pod 挂载了一个卷，fluentd 可以从中获取其配置数据。

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

apiVersion: v1
kind: Pod
metadata:
  name: counter
spec:
  containers:
  - name: count
    image: busybox:1.28
    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: registry.k8s.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

直接从应用程序公开日志

直接从每个应用程序公开或推送日志的集群日志记录超出了 Kubernetes 的范围。

下一步

• 阅读有关 Kubernetes 系统日志 的信息
• 了解有关 Kubernetes 系统组件跟踪 的信息
• 了解如何 自定义 Kubernetes 在 Pod 失败时记录的终止消息