系统日志

系统组件的日志记录集群中发生的事件，这对于调试非常有用。 你可以配置日志的精细度，以展示更多或更少的细节。 日志可以是粗粒度的，如只显示组件内的错误， 也可以是细粒度的，如显示事件的每一个跟踪步骤（比如 HTTP 访问日志、pod 状态更新、控制器动作或调度器决策）。

Klog

klog 是 Kubernetes 的日志库。 klog 为 Kubernetes 系统组件生成日志消息。

有关 klog 配置的更多信息，请参见命令行工具参考。

Kubernetes 正在进行简化其组件日志的努力。下面的 klog 命令行参数从 Kubernetes 1.23 开始已被废弃， 会在未来版本中移除：

  • --add-dir-header
  • --alsologtostderr
  • --log-backtrace-at
  • --log-dir
  • --log-file
  • --log-file-max-size
  • --logtostderr
  • --one-output
  • --skip-headers
  • --skip-log-headers
  • --stderrthreshold

输出总会被写到标准错误输出（stderr）之上，无论输出格式如何。 对输出的重定向将由调用 Kubernetes 组件的软件来处理。 这一软件可以是 POSIX Shell 或者类似 systemd 这样的工具。

在某些场合下，例如对于无发行主体的（distroless）容器或者 Windows 系统服务， 这些替代方案都是不存在的。那么你可以使用 kube-log-runner 可执行文件来作为 Kubernetes 的封装层，完成对输出的重定向。 在很多 Kubernetes 基础镜像中，都包含一个预先构建的可执行程序。 这个程序原来称作 /go-runner，而在服务器和节点的发行版本库中，称作 kube-log-runner。

下表展示的是 kube-log-runner 调用与 Shell 重定向之间的对应关系：

用法POSIX Shell（例如 Bash）kube-log-runner <options> <cmd>
合并 stderr 与 stdout，写出到 stdout2>&1kube-log-runner（默认行为 ）
将 stderr 与 stdout 重定向到日志文件1>>/tmp/log 2>&1kube-log-runner -log-file=/tmp/log
输出到 stdout 并复制到日志文件中2>&1 | tee -a /tmp/logkube-log-runner -log-file=/tmp/log -also-stdout
仅将 stdout 重定向到日志>/tmp/logkube-log-runner -log-file=/tmp/log -redirect-stderr=false

klog 输出

传统的 klog 原生格式示例：

  1. I1025 00:15:15.525108       1 httplog.go:79] GET /api/v1/namespaces/kube-system/pods/metrics-server-v0.3.1-57c75779f-9p8wg: (1.512ms) 200 [pod_nanny/v0.0.0 (linux/amd64) kubernetes/$Format 10.56.1.19:51756]

消息字符串可能包含换行符：

  1. I1025 00:15:15.525108       1 example.go:79] This is a message
  2. which has a line break.

结构化日志

特性状态： Kubernetes v1.23 [beta]

警告：

迁移到结构化日志消息是一个正在进行的过程。在此版本中，并非所有日志消息都是结构化的。 解析日志文件时，你也必须要处理非结构化日志消息。

日志格式和值的序列化可能会发生变化。

结构化日志记录旨在日志消息中引入统一结构，以便以编程方式提取信息。 你可以方便地用更小的开销来处理结构化日志。 生成日志消息的代码决定其使用传统的非结构化的 klog 还是结构化的日志。

默认的结构化日志消息是以文本形式呈现的，其格式与传统的 klog 保持向后兼容：

  1. <klog header> "<message>" <key1>="<value1>" <key2>="<value2>" ...

示例：

  1. I1025 00:15:15.525108       1 controller_utils.go:116] "Pod status updated" pod="kube-system/kubedns" status="ready"

字符串在输出时会被添加引号。其他数值类型都使用 %+v 来格式化，因此可能导致日志消息会延续到下一行， 具体取决于数据本身。

  1. I1025 00:15:15.525108       1 example.go:116] "Example" data="This is text with a line break\nand \"quotation marks\"." someInt=1 someFloat=0.1 someStruct={StringField: First line,
  2. second line.}

上下文日志

特性状态： Kubernetes v1.24 [alpha]

上下文日志建立在结构化日志之上。 它主要是关于开发人员如何使用日志记录调用：基于该概念的代码将更加灵活， 并且支持在结构化日志 KEP 中描述的额外用例。

如果开发人员在他们的组件中使用额外的函数，比如 WithValues 或 WithName， 那么日志条目将会包含额外的信息，这些信息会被调用者传递给函数。

目前这一特性是由 StructuredLogging 特性门控所控制的，默认关闭。 这个基础设施是在 1.24 中被添加的，并不需要修改组件。 该 component-base/logs/example 命令演示了如何使用新的日志记录调用以及组件如何支持上下文日志记录。

  1. $ cd $GOPATH/src/k8s.io/kubernetes/staging/src/k8s.io/component-base/logs/example/cmd/
  2. $ go run . --help
  3. ...
  4.       --feature-gates mapStringBool  A set of key=value pairs that describe feature gates for alpha/experimental features. Options are:
  5.                                      AllAlpha=true|false (ALPHA - default=false)
  6.                                      AllBeta=true|false (BETA - default=false)
  7.                                      ContextualLogging=true|false (ALPHA - default=false)
  8. $ go run . --feature-gates ContextualLogging=true
  9. ...
  10. I0404 18:00:02.916429  451895 logger.go:94] "example/myname: runtime" foo="bar" duration="1m0s"
  11. I0404 18:00:02.916447  451895 logger.go:95] "example: another runtime" foo="bar" duration="1m0s"

example 前缀和 foo="bar" 会被函数的调用者添加上， 不需修改该函数，它就会记录 runtime 消息和 duration="1m0s" 值。

禁用上下文日志后，WithValues 和 WithName 什么都不会做， 并且会通过调用全局的 klog 日志记录器记录日志。 因此，这些附加信息不再出现在日志输出中：

  1. $ go run . --feature-gates ContextualLogging=false
  2. ...
  3. I0404 18:03:31.171945  452150 logger.go:94] "runtime" duration="1m0s"
  4. I0404 18:03:31.171962  452150 logger.go:95] "another runtime" duration="1m0s"

JSON 日志格式

特性状态： Kubernetes v1.19 [alpha]

警告：

JSON 输出并不支持太多标准 klog 参数。对于不受支持的 klog 参数的列表， 请参见命令行工具参考。

并不是所有日志都保证写成 JSON 格式（例如，在进程启动期间）。 如果你打算解析日志，请确保可以处理非 JSON 格式的日志行。

字段名和 JSON 序列化可能会发生变化。

--logging-format=json 参数将日志格式从 klog 原生格式改为 JSON 格式。 JSON 日志格式示例（美化输出）：

  1. {
  2.    "ts": 1580306777.04728,
  3.    "v": 4,
  4.    "msg": "Pod status updated",
  5.    "pod":{
  6.       "name": "nginx-1",
  7.       "namespace": "default"
  8.    },
  9.    "status": "ready"
  10. }

具有特殊意义的 key：

  • ts - Unix 时间风格的时间戳（必选项，浮点值）
  • v - 精细度（仅用于 info 级别，不能用于错误信息，整数）
  • err - 错误字符串（可选项，字符串）
  • msg - 消息（必选项，字符串）

当前支持 JSON 格式的组件列表：

日志精细度级别

参数 -v 控制日志的精细度。增大该值会增大日志事件的数量。 减小该值可以减小日志事件的数量。增大精细度会记录更多的不太严重的事件。 精细度设置为 0 时只记录关键（critical）事件。

日志位置

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

  • Kubernetes 调度器和 kube-proxy 在容器中运行。
  • kubelet 和容器运行时不在容器中运行。

在使用 systemd 的系统中，kubelet 和容器运行时写入 journald。 在别的系统中，日志写入 /var/log 目录下的 .log 文件中。 容器中的系统组件总是绕过默认的日志记录机制，写入 /var/log 目录下的 .log 文件。 与容器日志类似，你应该轮转 /var/log 目录下系统组件日志。 在 kube-up.sh 脚本创建的 Kubernetes 集群中，日志轮转由 logrotate 工具配置。 logrotate 工具，每天或者当日志大于 100MB 时，轮转日志。

接下来