系统日志
系统组件日志记录集群中发生的事件,这对调试非常有用。您可以配置日志详细程度以查看更多或更少的详细信息。日志可以是粗粒度的,例如显示组件内部的错误,也可以是细粒度的,例如显示事件的逐步跟踪(例如 HTTP 访问日志、Pod 状态更改、控制器操作或调度程序决策)。
警告
与此处描述的命令行标志相反,日志输出本身不属于 Kubernetes API 稳定性保证:单个日志条目及其格式可能会在不同版本之间发生变化!Klog
klog 是 Kubernetes 日志记录库。 klog 为 Kubernetes 系统组件生成日志消息。
Kubernetes 正在简化其组件中的日志记录。以下 klog 命令行标志 已弃用,从 Kubernetes v1.23 开始,在 Kubernetes v1.26 中删除
--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,写入 stdout | 2>&1 | kube-log-runner (默认行为) |
将两者重定向到日志文件 | 1>>/tmp/log 2>&1 | kube-log-runner -log-file=/tmp/log |
复制到日志文件和 stdout | 2>&1 | tee -a /tmp/log | kube-log-runner -log-file=/tmp/log -also-stdout |
仅将 stdout 重定向到日志文件 | >/tmp/log | kube-log-runner -log-file=/tmp/log -redirect-stderr=false |
Klog 输出
传统 klog 本机格式的示例
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]
消息字符串可能包含换行符
I1025 00:15:15.525108 1 example.go:79] This is a message
which has a line break.
结构化日志记录
Kubernetes v1.23 [beta]
警告
迁移到结构化日志消息是一个持续的过程。并非所有日志消息都在此版本中结构化。解析日志文件时,您还必须处理非结构化日志消息。
日志格式和值序列化可能会发生变化。
结构化日志记录在日志消息中引入了统一的结构,允许以编程方式提取信息。您可以更轻松、更低成本地存储和处理结构化日志。生成日志消息的代码确定它是否使用传统的非结构化 klog 输出或结构化日志记录。
结构化日志消息的默认格式为文本,格式与传统 klog 向后兼容
<klog header> "<message>" <key1>="<value1>" <key2>="<value2>" ...
示例
I1025 00:15:15.525108 1 controller_utils.go:116] "Pod status updated" pod="kube-system/kubedns" status="ready"
字符串用引号括起来。其他值使用 %+v
格式化,这可能会导致日志消息继续下一行 取决于数据。
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,
second line.}
上下文日志记录
Kubernetes v1.30 [beta]
上下文日志记录建立在结构化日志记录之上。它主要与开发人员如何使用日志记录调用有关:基于该概念的代码更加灵活,并支持 上下文日志记录 KEP 中所述的更多用例。
如果开发人员在其组件中使用 WithValues
或 WithName
等附加函数,则日志条目包含由其调用者传递给函数的附加信息。
对于 Kubernetes 1.31,这是在 ContextualLogging
功能开关 后面进行的,默认情况下处于启用状态。这方面的基础设施是在 1.24 中添加的,无需修改组件。 component-base/logs/example
命令演示了如何使用新的日志记录调用以及支持上下文日志记录的组件的行为方式。
$ cd $GOPATH/src/k8s.io/kubernetes/staging/src/k8s.io/component-base/logs/example/cmd/
$ go run . --help
...
--feature-gates mapStringBool A set of key=value pairs that describe feature gates for alpha/experimental features. Options are:
AllAlpha=true|false (ALPHA - default=false)
AllBeta=true|false (BETA - default=false)
ContextualLogging=true|false (BETA - default=true)
$ go run . --feature-gates ContextualLogging=true
...
I0222 15:13:31.645988 197901 example.go:54] "runtime" logger="example.myname" foo="bar" duration="1m0s"
I0222 15:13:31.646007 197901 example.go:55] "another runtime" logger="example" foo="bar" duration="1h0m0s" duration="1m0s"
logger
键和 foo="bar"
是由记录 runtime
消息和 duration="1m0s"
值的函数的调用者添加的,无需修改该函数。
禁用上下文日志记录后,WithValues
和 WithName
不会执行任何操作,并且日志调用会通过全局 klog 记录器。因此,此附加信息不再出现在日志输出中
$ go run . --feature-gates ContextualLogging=false
...
I0222 15:14:40.497333 198174 example.go:54] "runtime" duration="1m0s"
I0222 15:14:40.497346 198174 example.go:55] "another runtime" duration="1h0m0s" duration="1m0s"
JSON 日志格式
Kubernetes v1.19 [alpha]
警告
JSON 输出不支持许多标准 klog 标志。有关不支持的 klog 标志的列表,请参阅 命令行工具参考。
不能保证所有日志都以 JSON 格式写入(例如,在进程启动期间)。如果您打算解析日志,请确保您也可以处理不是 JSON 的日志行。
字段名称和 JSON 序列化可能会发生变化。
--logging-format=json
标志将日志的格式从 klog 本机格式更改为 JSON 格式。JSON 日志格式的示例(美化打印)
{
"ts": 1580306777.04728,
"v": 4,
"msg": "Pod status updated",
"pod":{
"name": "nginx-1",
"namespace": "default"
},
"status": "ready"
}
具有特殊含义的键
ts
- 时间戳作为 Unix 时间(必需,浮点型)v
- 详细程度(仅适用于 info,不适用于错误消息,int)err
- 错误字符串(可选,字符串)msg
- 消息(必需,字符串)
当前支持 JSON 格式的组件列表
日志详细程度级别
-v
标志控制日志详细程度。增加值会增加记录的事件数量。减小值会减少记录的事件数量。提高详细程度设置会记录越来越不严重的事件。详细程度设置为 0 仅记录严重事件。
日志位置
系统组件有两种类型:在容器中运行的组件和不在容器中运行的组件。例如
- Kubernetes 调度程序和 kube-proxy 在容器中运行。
- Kubelet 和 容器运行时 不在容器中运行。
在具有 systemd 的机器上,Kubelet 和容器运行时写入 journald。否则,它们会将日志写入 /var/log
目录中的 .log
文件。容器内的系统组件始终将日志写入 /var/log
目录中的 .log
文件,绕过默认日志记录机制。与容器日志类似,您应该在 /var/log
目录中轮换系统组件日志。在通过 kube-up.sh
脚本创建的 Kubernetes 集群中,日志轮换由 logrotate
工具配置。logrotate
工具每天轮换日志,或者一旦日志大小超过 100MB。
日志查询
Kubernetes v1.30 [beta]
为了帮助调试节点上的问题,Kubernetes v1.27 引入了一项功能,允许查看在节点上运行的服务的日志。要使用此功能,请确保为该节点启用了 NodeLogQuery
功能开关,并且 kubelet 配置选项 enableSystemLogHandler
和 enableSystemLogQuery
均设置为 true。在 Linux 上,假设可以通过 journald 获取服务日志。在 Windows 上,假设可以通过应用程序日志提供程序获取服务日志。在这两个操作系统上,也可以通过读取 /var/log/
中的文件来获取日志。
假设您有权与节点对象交互,您可以在所有节点或仅一部分节点上尝试使用此功能。以下是如何从节点检索 kubelet 服务日志的示例
# Fetch kubelet logs from a node named node-1.example
kubectl get --raw "/api/v1/nodes/node-1.example/proxy/logs/?query=kubelet"
您还可以获取文件,前提是这些文件位于 kubelet 允许日志获取的目录中。例如,您可以从 Linux 节点上的 /var/log
获取日志
kubectl get --raw "/api/v1/nodes/<insert-node-name-here>/proxy/logs/?query=/<insert-log-file-name-here>"
Kubelet 使用启发式方法来检索日志。这在您不知道给定系统服务是否将日志写入操作系统的本机记录器(如 journald)还是写入 /var/log/
中的日志文件时很有用。启发式方法首先检查本机记录器,如果不可用,则尝试从 /var/log/<servicename>
或 /var/log/<servicename>.log
或 /var/log/<servicename>/<servicename>.log
检索第一个日志。
可使用的选项完整列表如下
选项 | 描述 |
---|---|
boot | boot 显示来自特定系统启动的消息 |
pattern | pattern 通过提供的与 PERL 兼容的正则表达式过滤日志条目 |
query | query 指定要从中返回日志的服务或文件(必需) |
sinceTime | 一个 RFC3339 时间戳,从中显示日志(包含) |
untilTime | 一个 RFC3339 时间戳,到此显示日志(包含) |
tailLines | 指定要检索的日志末尾多少行;默认值为获取整个日志 |
更复杂查询的示例
# Fetch kubelet logs from a node named node-1.example that have the word "error"
kubectl get --raw "/api/v1/nodes/node-1.example/proxy/logs/?query=kubelet&pattern=error"
下一步
- 阅读有关 Kubernetes 日志记录体系结构 的内容
- 阅读有关 结构化日志记录 的内容
- 阅读有关 上下文日志记录 的内容
- 阅读有关 klog 标志的弃用 的内容
- 阅读有关 日志记录严重程度的约定 的内容
- 阅读有关 日志查询 的内容