当 Google Kubernetes Engine (GKE) 中的 Pod 发生故障或服务无法按预期运行时,了解导致问题的事件序列至关重要。检查当前状态并不总是足以找到根本原因,因此历史日志数据非常宝贵。
您可以在本页中了解如何使用 Cloud Logging 通过查询和分析 GKE 日志来调查过去的故障(例如,Pod 启动失败的原因或谁删除了关键的 Deployment)。
对于需要对集群范围的问题进行根本原因分析、审核更改并了解系统行为趋势的平台管理员和操作者,此信息非常重要。对于应用开发者来说,这也是调试特定于应用的错误、跟踪请求路径以及了解其代码在 GKE 环境中的行为随时间变化情况的必要工具。如需详细了解我们在 Google Cloud 内容中提及的常见角色和示例任务,请参阅常见的 GKE 用户角色和任务。
了解用于问题排查的关键日志类型
为帮助您进行问题排查,Cloud Logging 会自动从 GKE 集群、容器化应用和其他Google Cloud 服务中收集并汇总多种关键日志类型:
节点和运行时日志(
kubelet
、containerd
):来自底层节点服务的日志。由于kubelet
管理节点上所有 Pod 的生命周期,因此其日志对于排查容器启动、内存不足 (OOM) 事件、探测失败和卷装载错误等问题至关重要。这些日志对于诊断节点级问题(例如状态为NotReady
的节点)也非常重要。由于 containerd 管理容器的生命周期(包括拉取映像),因此其日志对于排查 kubelet 启动容器之前发生的问题至关重要。containerd 日志可帮助您诊断 GKE 中的节点级问题,因为它们记录了容器运行时的具体活动和潜在错误。
应用日志(
stdout
、stderr
):容器化进程的标准输出和错误流。这些日志对于调试应用特有的问题(例如崩溃、错误或意外行为)至关重要。审核日志:这些日志可回答“哪些用户何时在何处对您的集群执行过哪些操作?”这一问题。它们会跟踪对 Kubernetes API 服务器执行的管理操作和 API 调用,这有助于诊断因配置更改或未经授权的访问而导致的问题。
常见问题排查场景
发现问题后,您可以查询这些日志,了解发生了什么情况。为了帮助您入门,下面列出了如何通过查看日志来辅助解决以下问题:
- 如果节点的状态为
NotReady
,请查看其节点日志。kubelet
和containerd
日志通常会揭示该问题的根本原因,例如网络问题或资源限制。 - 如果新节点无法完成预配并加入集群,请查看节点的串行端口日志。这些日志会在节点的日志记录代理完全处于活动状态之前捕获前期启动和 kubelet 启动活动。
- 如果某个 Pod 之前未能启动,请查看该 Pod 的应用日志,以检查是否存在崩溃情况。如果日志为空或无法调度 Pod,请检查审核日志中是否有相关事件,或检查目标节点上的节点日志,以获取有关资源压力或映像拉取错误的线索。
- 如果某个关键部署被删除,但无人知道原因,请查询管理员活动审核日志。这些日志可帮助您确定是哪个用户或服务账号发出了这一删除操作的 API 调用,您可以通过该明确的初始信息开始着手调查。
如何访问日志
您可以使用 Google Cloud 控制台中的 Logs Explorer 查询、查看和分析 GKE 日志。Logs Explorer 提供了强大的过滤选项,可帮助您筛选、隔离并查明问题。
如需访问和使用 Logs Explorer,请完成以下步骤:
在 Google Cloud 控制台中,前往 Logs Explorer 页面。
在查询窗格中,输入查询。使用 Logging 查询语言编写有针对性的查询。为了帮助您入门,下面列出了一些常见的过滤条件:
过滤条件类型 说明 示例值 resource.type
Kubernetes 资源类型。 k8s_cluster
、k8s_node
、k8s_pod
、k8s_container
log_id
资源的日志流。 stdout
、stderr
resource.labels.RESOURCE_TYPE.name
用于筛选具有特定名称的资源的过滤条件。
将RESOURCE_TYPE
替换为您要查询的资源的名称。例如namespace
或pod
。example-namespace-name
、example-pod-name
severity
日志严重级别。 DEFAULT
、INFO
、WARNING
、ERROR
、CRITICAL
jsonPayload.message=~
用于在日志消息中查询文本的正则表达式搜索。 scale.down.error.failed.to.delete.node.min.size.reached
例如,为了排查特定 Pod 的问题,您可能需要隔离其错误日志。如需仅查看该 Pod 中严重级别为
ERROR
的日志,请使用以下查询:resource.type="k8s_container" resource.labels.pod_name="POD_NAME" resource.labels.namespace_name="NAMESPACE_NAME" severity=ERROR
替换以下内容:
POD_NAME
:出现问题的 Pod 的名称。NAMESPACE_NAME
:Pod 所在的命名空间。如果您不确定是哪个命名空间,可查看kubectl get pods
命令输出中的Namespace
列。
如需查看更多示例,请参阅 Google Cloud Observability 文档中的与 Kubernetes 相关的查询。
点击运行查询。
如需查看完整的日志消息(包括 JSON 载荷、元数据和时间戳),请点击相应日志条目。
如需详细了解 GKE 日志,请参阅 GKE 日志简介。
后续步骤
阅读使用 Cloud Monitoring 执行主动监控(本系列中的下一页)。
如需了解这些概念的实际应用,请参阅问题排查示例场景。
如需有关解决特定问题的建议,请查看 GKE 的问题排查指南。
如果您在文档中找不到问题的解决方案,请参阅获取支持以获取进一步的帮助,包括以下主题的建议:
- 请与 Cloud Customer Care 联系,以提交支持请求。
- 通过在 StackOverflow 上提问并使用
google-kubernetes-engine
标记搜索类似问题,从社区获得支持。您还可以加入#kubernetes-engine
Slack 频道,以获得更多社区支持。 - 使用公开问题跟踪器提交 bug 或功能请求。