日志架构

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

然而，容器引擎或运行时提供的原生功能通常不足以构成完整的日志解决方案。

例如，如果容器崩溃、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.34 允许通过 Pod API 直接访问这些日志流。你可以通过指定流名称（Stdout 或 Stderr）并使用 stream 查询字符串来获取特定流。你必须具有读取该 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 journal）。你可以使用 Kubernetes 的存储机制将持久存储映射到运行该组件的容器中。

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

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

集群级日志架构

虽然 Kubernetes 不提供集群级日志的原生解决方案，但你可以考虑以下几种常见方法。

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

使用节点日志代理

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

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

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

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

将 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 容器。第一个清单包含一个用于配置 fluentd 的 ConfigMap。

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 的 Sidecar 容器的 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 失败时记录的终止消息