日志架构

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

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

例如，如果容器崩溃、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

容器日志流

作为一项 Alpha 功能，kubelet 可以将容器生成的两个标准流中的日志拆分出来：标准输出 和 标准错误。要使用此行为，您必须启用 PodLogsQuerySplitStreams 特性门控。启用该特性门控后，Kubernetes 1.32 允许通过 Pod API 直接访问这些日志流。您可以通过使用 stream 查询字符串指定流名称（Stdout 或 Stderr）来获取特定的流。您必须具有读取该 Pod 的 log 子资源的权限。

为了演示此功能，您可以创建一个 Pod，该 Pod 定期向标准输出和错误流写入文本。

debug/counter-pod-err.yaml

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

要运行此 Pod，请使用以下命令

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

要仅获取 stderr 日志流，您可以运行

kubectl get --raw "/api/v1/namespaces/default/pods/counter-err/log?stream=Stderr"

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

节点如何处理容器日志

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

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

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

日志轮换

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

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

为了在工作负载生成的日志量很大的集群中执行有效的日志轮换，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 中包含一个专用的日志记录边车容器。
• 从应用程序内部直接将日志推送到后端。

使用节点日志记录代理

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

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

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

容器写入 stdout 和 stderr，但没有统一的格式。节点级代理收集这些日志并转发以进行聚合。

使用带有日志记录代理的边车容器

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

• 边车容器将其应用程序日志流式传输到其自己的 stdout。
• 边车容器运行一个日志记录代理，该代理配置为从应用程序容器中提取日志。

流式边车容器

通过让你的边车容器写入它们自己的 stdout 和 stderr 流，你可以利用 kubelet 和已在每个节点上运行的日志记录代理。边车容器从文件、套接字或 journald 读取日志。每个边车容器都会将其日志打印到自己的 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 流。相反，你可以创建两个边车容器。每个边车容器可以 tail 共享卷中的特定日志文件，然后将日志重定向到其自己的 stdout 流。

以下是具有两个边车容器的 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 设置为目标，而不是实现流式边车容器方法。

边车容器还可以用于轮换应用程序本身无法轮换的日志文件。此方法的一个示例是定期运行 logrotate 的小型容器。但是，更直接的方法是直接使用 stdout 和 stderr，并将轮换和保留策略留给 kubelet。

带有日志记录代理的边车容器

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

以下是两个示例清单，你可以使用它们来实现带有日志记录代理的边车容器。第一个清单包含一个 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>    

第二个清单描述了一个运行 fluentd 的边车容器的 Pod。该 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 失败时记录的终止消息