本页面将介绍 Google Kubernetes Engine (GKE) 的基本问题排查技巧。本页面适用于刚开始使用 Kubernetes 和 GKE 且想要学习有效的问题排查实践的用户。
本页面简要介绍了以下工具和技术,可用于监控、诊断和解决 GKE 问题:
- 在 Google Cloud 控制台中查看集群和工作负载的健康状况:获取简要概览,以便快速识别集群和应用中存在的潜在问题。
- 使用
kubectl
命令行工具调查集群状态:使用这些命令可查看节点和 Pod 等资源的实时状态。 - 使用 Cloud Logging 进行历史分析:查询历史日志数据并检查事件,以确定故障的根本原因。
- 使用 Cloud Monitoring 执行主动监控:跟踪一段时间内的性能指标,直观呈现趋势,并创建提醒以便在问题影响用户之前检测到并做出响应。
- 借助 Gemini Cloud Assist 加快诊断速度:分析复杂的错误消息,获取分步问题排查指南,并自动调查问题。
- 综合应用:问题排查示例场景:了解如何在分步演练中使用这些工具来诊断和解决常见的实际应用故障。
了解核心概念
如果您是 Kubernetes 和 GKE 新手,在开始问题排查之前,务必要了解核心概念,例如集群架构以及 Pod 和节点之间的关系。如需了解详情,请参阅开始了解 GKE。
此外,了解您负责维护 GKE 的哪些部分以及 Google Cloud 负责维护哪些部分也有助于您完成本快速入门。如需了解详情,请参阅 GKE 共担责任。
在 Google Cloud 控制台中查看集群和工作负载健康状况
Google Cloud 控制台是问题排查的良好起点,因为它可以快速显示集群和工作负载的健康状况。集群健康状况是指底层 GKE 基础架构(如节点和网络)的健康状况,而工作负载健康状况是指集群上运行的应用的状态和性能。
以下部分介绍了集群和工作负载页面。为了让您全面了解应用的运行状况, Google Cloud 管理中心 Google Cloud 还提供强大的日志记录和监控工具,让您能够调查过去失败的根本原因,并主动防止未来发生类似问题。如需详细了解这些工具,请参阅使用 Cloud Logging 进行历史分析和使用 Cloud Monitoring 执行主动监控部分。
查找集群问题
Kubernetes 集群页面可让您大致了解集群的健康状况。如需找出任何集群存在的问题,请从此页面开始。
首先,在 Google Cloud 控制台中,前往 Kubernetes 集群页面。
以下是一些示例,展示了如何使用此页面进行问题排查:
- 如需有关改进集群健康状况、升级策略和费用优化的建议,请点击查看建议。
- 如需识别运行状况不佳的集群,请查看状态列。任何没有绿色对勾标记的集群都需要注意。
- 如需查看潜在问题,请查看通知列。点击任意通知消息即可了解详情。
调查特定集群
发现集群存在问题后,您可以探索集群的详细信息页面,获取有助于排查集群问题并了解其配置的深入信息。
如需前往集群的详情页面,请执行以下操作:
转到 Kubernetes 集群页面
查看名称列,然后点击要调查的集群的名称。
以下是一些示例,说明了如何使用集群详情页面排查集群问题:
对于一般健康检查,请尝试以下选项:
如需查看集群级信息中心,请前往可观测性标签页。默认情况下,GKE 会在您创建集群时启用 Cloud Monitoring。启用 Cloud Monitoring 后,GKE 会自动设置此页面上的信息中心。以下视图可能最有助于问题排查:
- 概览:查看集群的健康状况、资源利用率和关键事件的简要摘要。此信息中心可帮助您快速评估集群的总体状态并找出潜在问题。
- 流量指标:查看基于节点的网络指标,深入了解 Kubernetes 工作负载之间的流量。
- 工作负载状态:查看 Deployment、Pod 和容器的状态。识别出现故障或健康状况不佳的实例,并检测资源限制。
控制平面:查看控制平面的健康状况和性能。 借助此信息中心,您可以监控
kube-apiserver
和etcd
等组件的关键指标,识别性能瓶颈,并检测组件故障。
如需查看最近的应用错误,请前往应用错误标签页。此标签页上的信息可帮助您确定错误优先级并解决错误,其中会显示错误发生次数、首次出现时间以及上次发生时间。
如需进一步调查错误,请点击错误消息以查看详细的错误报告,包括相关日志的链接。
如果您在最近升级或更改后排查问题,请查看集群详情标签页中的集群基础知识部分。确认版本字段中列出的版本是否符合您的预期。如需进一步调查,请点击升级部分中的显示升级历史记录。
如果您使用的是 Standard 集群,并且 Pod 陷入
Pending
状态,或者您怀疑节点过载,请检查节点标签页。由于 GKE 会为您管理节点,因此 Autopilot 集群没有节点标签页。- 在节点池部分中,检查自动扩缩是否配置正确,以及机器类型是否适合您的工作负载。
- 在节点部分中,查找状态不是
Ready
的任何节点。NotReady
状态表示节点本身存在问题,例如资源压力或 kubelet 问题(kubelet 是在每个节点上运行以管理容器的代理)。
查找工作负载问题
当您怀疑特定应用(例如部署失败的应用)存在问题时,请前往 Google Cloud 控制台中的工作负载页面。此页面集中显示了集群中运行的所有应用。
首先,在 Google Cloud 控制台中,前往工作负载页面。
以下是一些示例,展示了如何使用此页面进行问题排查:
- 如需识别运行状况不佳的工作负载,请查看状态列。任何没有绿色对勾标记的工作负载都需要注意。
- 如果应用无响应,请查看 Pod 列。例如,状态为 1/3 表示三个应用副本中只有一个在运行,这表明存在问题。
调查特定工作负载
从概览中确定存在问题的工作负载后,请探索工作负载详情页面,开始隔离根本原因。
如需前往工作负载的详情页面,请执行以下操作:
转到工作负载页面。
查看名称列,然后点击要调查的工作负载的名称。
以下是一些示例,说明了如何使用工作负载详情页面排查工作负载问题:
如需检查工作负载的配置,请使用工作负载的概览和详细信息标签页。您可以使用此信息来验证事件,例如是否部署了正确的容器映像标记,或检查工作负载的资源请求和限制。
如需查找特定崩溃 Pod 的名称,请前往受管理的 Pod 部分。您可能需要此信息来执行
kubectl
命令。此部分列出了由工作负载控制的所有 Pod,以及它们的状态。如需查看工作负载的近期更改历史记录,请前往修订历史记录标签页。如果您在新部署后发现性能问题,请参阅本部分内容,确定哪个修订版本处于有效状态。然后,您可以将当前修订版本的配置与之前的修订版本进行比较,以找出问题的根源。如果未显示此标签页,则表示相应工作负载要么是不使用修订版本的类型,要么尚未进行任何更新。如果部署似乎失败,请前往事件标签页。此页面通常是最有价值的信息来源,因为它会显示 Kubernetes 级事件。
如需查看应用的日志,请点击日志标签页。此页面可帮助您了解集群内部发生的情况。您可以在此处查找有助于诊断问题的错误消息和堆栈轨迹。
如需确切了解部署的内容,请查看 YAML 标签页。此页面显示工作负载在集群中的有效 YAML 清单。此信息有助于发现与受源代码控制的清单之间的任何差异。如果您正在查看单个 Pod 的 YAML 清单,此标签页还会显示 Pod 的状态,从而提供有关 Pod 级故障的深入分析。
使用 kubectl
命令行工具调查集群状态
虽然 Google Cloud 控制台可帮助您了解是否存在问题,但 kubectl
命令行工具对于发现原因至关重要。通过直接与 Kubernetes 控制平面通信,kubectl
命令行工具可让您收集所需详细信息,以便对 GKE 环境进行问题排查。
以下部分将介绍一些基本命令,这些命令是 GKE 问题排查的强大起点。
准备工作
在开始之前,请执行以下任务:
- 安装 kubectl。
配置
kubectl
命令行工具以与您的集群通信:gcloud container clusters get-credentials CLUSTER_NAME \ --location=LOCATION
替换以下内容:
CLUSTER_NAME
:您的集群的名称。LOCATION
:集群控制平面的 Compute Engine 位置。为区域级集群提供区域,或为可用区级集群提供可用区。
查看您的权限。如需查看您是否拥有运行
kubectl
命令所需的权限,请使用kubectl auth can-i
命令。例如,如需查看您是否有权运行kubectl get nodes
,请运行kubectl auth can-i get nodes
命令。如果您拥有所需权限,该命令会返回
yes
;否则,该命令会返回no
。如果您没有运行
kubectl
命令的权限,则可能会看到类似于以下内容的错误消息:Error from server (Forbidden): pods "POD_NAME" is forbidden: User "USERNAME@DOMAIN.com" cannot list resource "pods" in API group "" in the namespace "default"
如果您没有所需的权限,请让集群管理员为您分配必要的角色。
获取正在运行的内容的概览
kubectl get
命令可帮助您全面了解集群中发生的情况。使用以下命令可查看两个最重要的集群组件(节点和 Pod)的状态:
如需检查节点是否正常运行,请查看所有节点及其状态的详细信息:
kubectl get nodes
输出类似于以下内容:
NAME STATUS ROLES AGE VERSION gke-cs-cluster-default-pool-8b8a777f-224a Ready <none> 4d23h v1.32.3-gke.1785003 gke-cs-cluster-default-pool-8b8a777f-egb2 Ready <none> 4d22h v1.32.3-gke.1785003 gke-cs-cluster-default-pool-8b8a777f-p5bn Ready <none> 4d22h v1.32.3-gke.1785003
除
Ready
之外的任何状态都需要进一步调查。如需检查 Pod 是否运行正常,请查看所有 Pod 及其状态的详细信息:
kubectl get pods --all-namespaces
输出类似于以下内容:
NAMESPACE NAME READY STATUS RESTARTS AGE kube-system netd-6nbsq 3/3 Running 0 4d23h kube-system netd-g7tpl 3/3 Running 0 4d23h
除
Running
之外的任何状态都需要进一步调查。以下是您可能会看到的一些常见状态:Running
:正常运行状态。Pending
:Pod 正在等待被调度到节点上。CrashLoopBackOff
:Pod 中的容器反复崩溃,因为应用启动后因出错而退出,然后由 Kubernetes 重新启动。ImagePullBackOff
:Pod 无法拉取容器映像。
上述命令只是 kubectl
get
命令的两种使用方式示例。您还可以使用该命令详细了解多种类型的 Kubernetes 资源。如需查看您可以探索的资源的完整列表,请参阅 Kubernetes 文档中的 kubectl get。
详细了解特定资源
发现问题后,您需要了解更多详情。例如,状态不是 Running
的 Pod 可能存在问题。如需了解更多详情,请使用 kubectl describe
命令。
例如,如需描述特定 Pod,请运行以下命令:
kubectl describe pod POD_NAME -n NAMESPACE_NAME
替换以下内容:
POD_NAME
:出现问题的 Pod 的名称。NAMESPACE_NAME
:Pod 所在的命名空间。 如果您不确定命名空间是什么,请查看kubectl get pods
命令输出中的Namespace
列。
kubectl describe
命令的输出包含有关资源的详细信息。在排查 Pod 问题时,您可以重点查看以下几个部分:
Status
:Pod 的当前状态。Conditions
:Pod 的总体健康状况和就绪状态。Restart Count
:Pod 中的容器已重启的次数。如果数量过高,则可能需要引起注意。Events
:此 Pod 发生的重要事件的日志,例如被调度到节点、拉取其容器映像,以及是否发生任何错误。在Events
部分,您通常可以找到有关 Pod 失败原因的直接线索。
与 kubectl get
命令类似,您可以使用 kubectl describe
命令详细了解多种类型的资源。如需查看您可以探索的资源的完整列表,请参阅 Kubernetes 文档中的 kubectl describe。
使用 Cloud Logging 进行历史分析
虽然 kubectl
命令行工具对于检查 Kubernetes 对象的实时状态非常有用,但其视图通常仅限于当前时刻。若要了解问题的根本原因,您通常需要调查一段时间内发生的情况。如果您需要此类历史背景信息,请使用 Cloud Logging。
Cloud Logging 会汇总来自 GKE 集群、容器化应用和其他 Google Cloud 服务的日志。
了解用于问题排查的关键日志类型
Cloud Logging 会自动收集多种不同类型的 GKE 日志,这些日志可帮助您进行问题排查:
节点和运行时日志(
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 日志。日志浏览器提供了强大的过滤选项,可帮助您查明问题。
如需访问和使用日志浏览器,请完成以下步骤:
在 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 执行主动监控
问题发生后,查看日志是问题排查的关键步骤。不过,一个真正具有弹性的系统还需要采取主动方法来识别问题,以免问题导致服务中断。
如需主动发现未来可能出现的问题并随时间推移跟踪关键绩效指标,请使用 Cloud Monitoring。Cloud Monitoring 提供信息中心、指标和提醒功能。这些工具可帮助您发现不断上升的错误率、不断增加的延迟时间或资源限制,从而帮助您在用户受到影响之前采取行动。
查看实用指标
GKE 会自动将一组指标发送到 Cloud Monitoring。以下各部分列出了一些最重要的问题排查指标:
如需查看完整的 GKE 指标列表,请参阅 GKE 系统指标。
容器性能和健康状况指标
当您怀疑特定应用存在问题时,可以先查看这些指标。这些指标有助于您监控应用的健康状况,包括发现容器是否频繁重启、内存不足或受到 CPU 限制的节流。
指标 | 说明 | 问题排查的重要性 |
---|---|---|
kubernetes.io/container/cpu/limit_utilization |
实例当前使用的 CPU 占 CPU 限额的比例。该值可能大于 1,因为容器可能被允许超出其 CPU 限制。 | 标识 CPU 节流。值过高可能会导致性能下降。 |
kubernetes.io/container/memory/limit_utilization |
实例当前使用的内存占内存限额的比例。此值不能超过 1。 | 监控内存不足 (OOM) 错误的风险。 |
kubernetes.io/container/memory/used_bytes |
容器实际消耗的内存(以字节为单位)。 | 跟踪内存消耗情况,以识别潜在的内存泄漏或 OOM 错误风险。 |
kubernetes.io/container/memory/page_fault_count |
按类型(主要和次要)划分的页面错误数。 | 表示内存压力较大。严重缺页中断意味着即使未达到内存限制,系统也会从磁盘读取内存(交换)。 |
kubernetes.io/container/restart_count |
容器的重启次数。 | 通过重启次数高或不断增加来突出显示潜在问题,例如应用崩溃、配置错误或资源耗尽。 |
kubernetes.io/container/ephemeral_storage/used_bytes |
本地临时存储空间使用量(以字节为单位)。 | 监控临时磁盘使用情况,以防止因临时存储空间已满而导致 Pod 被逐出。 |
kubernetes.io/container/cpu/request_utilization |
实例当前使用的 CPU 占请求的 CPU 的比例。该值可能大于 1,因为用量可能超过请求量。 | 识别预配过度或预配不足的 CPU 请求,帮助您优化资源分配。 |
kubernetes.io/container/memory/request_utilization |
实例的当前用量占内存请求量的比例。该值可能大于 1,因为用量可能超过请求量。 | 识别过度配置或配置不足的内存请求,以改进调度并防止出现 OOM 错误。 |
节点性能和健康指标
当您需要诊断底层 GKE 基础架构的问题时,请检查这些指标。这些指标对于了解节点的整体健康状况和容量至关重要,有助于您调查节点是否处于不健康或高压状态,或者节点是否有足够的内存来调度新的 Pod。
指标 | 说明 | 问题排查的重要性 |
---|---|---|
kubernetes.io/node/cpu/allocatable_utilization |
实例当前使用的 CPU 占可分配 CPU 的比例。 | 指示 Pod 使用量总和是否使节点的可用 CPU 资源紧张。 |
kubernetes.io/node/memory/allocatable_utilization |
实例当前使用的内存占可分配内存的比例。该值不能超过 1,因为使用的内存不能超过可分配的内存(字节数)。 | 表明节点缺少内存来调度新 Pod 或供现有 Pod 运行,尤其是在值较高时。 |
kubernetes.io/node/status_condition (Beta 版) |
节点状态条件字段中的节点条件。 | 报告节点健康状况,例如 Ready 、MemoryPressure 或 DiskPressure 。 |
kubernetes.io/node/ephemeral_storage/used_bytes |
节点使用的本地临时存储空间(字节数)。 | 通过提供有关临时存储空间用量过高的警告,帮助防止 Pod 启动失败或被逐出。 |
kubernetes.io/node/ephemeral_storage/inodes_free |
本地临时存储空间上的可用索引节点 (inode) 数量。 | 监控可用 inode 的数量。即使有可用的磁盘空间,inode 用完也可能会导致操作停止。 |
kubernetes.io/node/interruption_count (Beta 版) |
中断是指在客户控制相应基础设施的情况下,系统对该基础设施的逐出操作。此指标是按类型和原因统计的当前中断次数。 | 说明了节点为何可能会因系统逐出而意外消失。 |
Pod 效果和健康指标
这些指标可帮助您排查与 Pod 同其环境(例如网络和存储空间)互动相关的问题。当您需要诊断启动缓慢的 Pod、调查潜在的网络连接问题或主动管理存储空间以防止因卷已满而导致写入失败时,可以使用这些指标。
指标 | 说明 | 问题排查的重要性 |
---|---|---|
kubernetes.io/pod/network/received_bytes_count |
Pod 通过网络接收的累计字节数。 | 识别可能表明应用或网络存在问题的异常网络活动(高或低)。 |
kubernetes.io/pod/network/policy_event_count (Beta 版) |
数据平面中检测到的网络政策事件数量的变化。 | 识别由网络政策引起的连接问题。 |
kubernetes.io/pod/volume/utilization |
实例当前使用的卷空间占总卷空间的比例。该值不能大于 1,因为使用的卷空间不能超过可用卷空间总量。 | 通过在利用率较高(接近 1)时发出警告,实现对卷空间的主动管理,避免写入失败。 |
kubernetes.io/pod/latencies/pod_first_ready (Beta 版) |
Pod 端到端启动延迟时间(从 Pod 创建到就绪),包括映像拉取时间。 | 诊断启动缓慢的 Pod。 |
使用 Metrics Explorer 直观呈现指标
如需直观呈现 GKE 环境的状态,请使用 Metrics Explorer 基于指标创建图表。
如需使用 Metrics Explorer,请完成以下步骤:
在 Google Cloud 控制台中,前往 Metrics Explorer 页面。
在指标字段中,选择或输入要检查的指标。
查看结果并观察一段时间内的任何趋势。
例如,如需调查特定命名空间中 Pod 的内存消耗情况,您可以执行以下操作:
- 在选择指标列表中,选择指标
kubernetes.io/container/memory/used_bytes
,然后点击应用。 - 点击添加过滤条件,然后选择 namespace_name。
- 在值列表中,选择要调查的命名空间。
- 在汇总字段中,依次选择总和 > pod_name,然后点击确定。此设置会为每个 Pod 显示单独的时序线。
- 点击保存图表。
生成的图表会显示每个 Pod 在不同时间点的内存用量,有助于您直观地识别内存消耗量异常高或出现峰值的任何 Pod。
Metrics Explorer 在构建要查看的指标方面具有极大的灵活性。如需详细了解 Metrics Explorer 的高级选项,请参阅 Cloud Monitoring 文档中的使用 Metrics Explorer 创建图表。
创建提醒以主动检测问题
如需在出现问题或指标超出特定阈值时收到通知,请在 Cloud Monitoring 中设置提醒政策。
例如,如需设置一项提醒政策,以便在容器 CPU 上限超过 80% 且持续 5 分钟时通知您,请执行以下操作:
在 Google Cloud 控制台中,前往提醒页面。
点击创建政策。
在选择指标框中,过滤
CPU limit utilization
,然后选择以下指标:kubernetes.io/container/cpu/limit_utilization。点击应用。
将添加过滤条件字段留空。此设置会在任何集群违反阈值时触发提醒。
在转换数据部分,执行以下操作:
- 在滚动窗口列表中,选择 1 分钟。此设置意味着 Google Cloud 每分钟计算一次平均值。
在滚动窗口函数列表中,选择平均值。
这两个设置都会每分钟平均计算每个容器的 CPU 限制利用率。
点击下一步。
在配置提醒部分中,执行以下操作:
- 对于条件类型,选择阈值。
- 在提醒触发器部分,选择任何时序违反。
- 在阈值位置部分,选择高于阈值。
- 对于阈值,输入
0.8
。此值表示您要监控的 80% 阈值。 - 点击高级选项。
- 在重新测试时间窗口列表中,选择 5 分钟。此设置意味着,只有当 CPU 利用率持续 5 分钟以上保持在 80% 以上时,系统才会触发提醒,从而减少因短暂的峰值而导致的误报。
- 在条件名称字段中,为条件指定一个描述性名称。
- 点击下一步。
在配置通知并最终确定提醒部分,执行以下操作:
- 在通知渠道列表中,选择您要接收提醒的渠道。如果您没有渠道,请点击管理通知渠道以创建一个渠道。
- 在为提醒政策命名字段中,为政策指定一个清晰且描述性的名称。
- 其他所有字段都保留默认值。
- 点击下一步。
检查您的政策,如果一切正常,请点击创建政策。
如需了解创建提醒的其他方式,请参阅 Cloud Monitoring 文档中的提醒概览。
借助 Gemini Cloud Assist 加快诊断速度
有时,即使您使用了前几部分中讨论的工具,问题的根本原因也不会立即显现出来。调查复杂案件可能非常耗时,并且需要深厚的专业知识。对于这种情况,Gemini Cloud Assist 可以提供帮助。它可以自动检测隐藏的模式、发现异常情况并提供摘要,帮助您快速查明可能的原因。
访问 Gemini Cloud Assist
如需访问 Gemini Cloud Assist,请完成以下步骤:
- 在 Google Cloud 控制台中,前往任意页面。
在 Google Cloud 控制台工具栏中,点击星光图标 打开或关闭 Gemini Cloud Assist 对话。
系统将打开 Cloud Assist 面板。您可以点击显示的示例提示,也可以在输入提示字段中输入提示。
探索示例提示
为帮助您了解 Gemini Cloud Assist 的用途,以下是一些提示示例:
主题背景 | 场景 | 提示示例 | Gemini Cloud Assist 可以提供哪些帮助 |
---|---|---|---|
令人困惑的错误消息 | Pod 处于 CrashLoopBackoff 状态,但错误消息难以理解。 |
此 GKE Pod 错误意味着什么,常见原因是什么:panic: runtime error: invalid memory address or nil pointer dereference ? |
Gemini Cloud Assist 会分析消息并以清晰的措辞进行解释。它还会提供潜在原因和解决方案。 |
性能问题 | 您的团队发现,在 GKE 中运行的应用的延迟时间较长。 | prod GKE 集群中的 api-gateway 服务延迟时间过长。我应该先检查哪些指标?您能否提供一些与 GKE 相关的常见原因? |
Gemini Cloud Assist 会建议您检查关键指标,探索潜在问题(例如资源限制或网络拥塞),并推荐用于进一步调查的工具和技术。 |
节点问题 | GKE 节点卡在 NotReady 状态。 |
我的某个 GKE 节点 (node-xyz ) 显示 NotReady 状态。排查此问题的典型步骤有哪些? |
Gemini Cloud Assist 提供分步调查方案,说明节点自动修复等概念,并建议相关的 kubectl 命令。 |
了解 GKE | 您不确定某个特定的 GKE 功能或如何实施最佳实践。 | 保护 GKE 集群的最佳实践有哪些?有没有什么方法可以了解更多信息? | Gemini Cloud Assist 可清晰说明 GKE 最佳实践。点击显示相关内容,即可查看指向官方文档的链接。 |
如需了解详情,请参阅以下资源:
- 了解如何撰写更好的提示。
- 了解如何使用 Gemini Cloud Assist 面板。
- 阅读 Gemini for Google Cloud 概览。
- 了解 Gemini for Google Cloud 如何使用您的数据。
使用 Gemini Cloud Assist 调查
除了互动式对话之外,Gemini Cloud Assist 还可以通过 Gemini Cloud Assist 调查执行更深入的自动化分析。此功能直接集成到 Logs Explorer 等工作流中,是一款强大的根本原因分析工具。
当您从错误或特定资源发起调查时,Gemini Cloud Assist 会分析日志、配置和指标。它会使用这些数据来生成有关可能根本原因的排名观测结果和假设,然后为您提供建议的后续步骤。您还可以将这些结果转移到 Google Cloud 支持服务工单中,以提供有价值的背景信息,帮助您更快地解决问题。
如需了解详情,请参阅 Gemini 文档中的 Gemini Cloud Assist 调查。
总结:问题排查场景示例
此示例展示了如何结合使用 GKE 工具来诊断和了解一个常见的实际问题:容器因内存不足而反复崩溃。
场景
您是 GKE 中运行的名为 product-catalog
的 Web 应用的随叫随到工程师。
当您收到 Cloud Monitoring 发送的自动提醒时,调查便开始了:
Alert: High memory utilization for container 'product-catalog' in 'prod' cluster.
此提醒会告知您存在问题,并指出该问题与 product-catalog
工作负载有关。
在 Google Cloud 控制台中确认问题
首先,您需要大致了解工作负载,以确认问题。
- 在 Google Cloud 控制台中,前往工作负载页面,然后过滤出
product-catalog
工作负载。 - 查看 Pod 状态列。您看到的不是正常的
3/3
,而是持续显示不健康状态的值:2/3
。此值表示应用的某个 Pod 的状态不是Ready
。 - 您想进一步调查,因此点击
product-catalog
工作负载的名称以转到其详情页面。 - 在详情页面上,查看受管理的 Pod 部分。您立即发现了一个问题:Pod 的
Restarts
列显示14
,这是一个异常高的数字。
如此高的重启次数证实了该问题会导致应用不稳定,并表明容器未通过健康检查或崩溃。
使用 kubectl
命令查找原因
既然您知道应用会反复重启,就需要找出原因。kubectl describe
命令是实现此目的的理想工具。
您会获得不稳定 Pod 的确切名称:
kubectl get pods -n prod
输出如下所示:
NAME READY STATUS RESTARTS AGE product-catalog-d84857dcf-g7v2x 0/1 CrashLoopBackOff 14 25m product-catalog-d84857dcf-lq8m4 1/1 Running 0 2h30m product-catalog-d84857dcf-wz9p1 1/1 Running 0 2h30m
您描述不稳定的 Pod 以获取详细的事件历史记录:
kubectl describe pod product-catalog-d84857dcf-g7v2x -n prod
您查看输出内容,并在
Last State
和Events
部分中找到线索:Containers: product-catalog-api: ... State: Waiting Reason: CrashLoopBackOff Last State: Terminated Reason: OOMKilled Exit Code: 137 Started: Mon, 23 Jun 2025 10:50:15 -0700 Finished: Mon, 23 Jun 2025 10:54:58 -0700 Ready: False Restart Count: 14 ... Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal Scheduled 25m default-scheduler Successfully assigned prod/product-catalog-d84857dcf-g7v2x to gke-cs-cluster-default-pool-8b8a777f-224a Normal Pulled 8m (x14 over 25m) kubelet Container image "us-central1-docker.pkg.dev/my-project/product-catalog/api:v1.2" already present on machine Normal Created 8m (x14 over 25m) kubelet Created container product-catalog-api Normal Started 8m (x14 over 25m) kubelet Started container product-catalog-api Warning BackOff 3m (x68 over 22m) kubelet Back-off restarting failed container
输出会提供两条关键线索:
- 首先,
Last State
部分显示容器已因Reason: OOMKilled
而终止,这表示它内存不足。Exit Code: 137
证实了这一原因,这是标准的 Linux 退出代码,表示进程因内存消耗过多而被终止。 - 其次,
Events
部分显示了消息为Back-off restarting failed container
的Warning: BackOff
事件。此消息确认容器处于故障循环中,这是您之前看到的CrashLoopBackOff
状态的直接原因。
- 首先,
使用指标直观呈现行为
kubectl describe
命令会告知您发生了什么情况,但 Cloud Monitoring 可以显示您的环境随时间变化的行为。
- 在 Google Cloud 控制台中,前往 Metrics Explorer。
- 您选择
container/memory/used_bytes
指标。 - 您可以将输出过滤到特定集群、命名空间和 Pod 名称。
该图表显示了一个明显的模式:内存使用量稳步攀升,然后在容器因内存不足而被终止并重新启动时突然降至零。此直观证据可确认是否存在内存泄漏或内存限制不足。
在日志中查找根本原因
现在,您知道容器内存不足,但仍不清楚具体原因。如需找出根本原因,请使用日志浏览器。
- 在 Google Cloud 控制台中,前往 Logs Explorer。
您可以编写查询,以过滤出特定容器在上次崩溃时间(您在
kubectl describe
命令的输出中看到的时间)之前的日志:resource.type="k8s_container" resource.labels.cluster_name="example-cluster" resource.labels.namespace_name="prod" resource.labels.pod_name="product-catalog-d84857dcf-g7v2x" timestamp >= "2025-06-23T17:50:00Z" timestamp < "2025-06-23T17:55:00Z"
在日志中,您会发现每次崩溃前都有一系列重复的消息:
{ "message": "Processing large image file product-image-large.jpg", "severity": "INFO" }, { "message": "WARN: Memory cache size now at 248MB, nearing limit.", "severity": "WARNING" }
这些日志条目表明,应用正尝试通过将大型图片文件完全加载到内存中来处理这些文件,最终导致容器的内存限制耗尽。
研究结果
通过结合使用这些工具,您可以全面了解问题:
- 监控提醒通知您出现了问题。
- Google Cloud 控制台显示,该问题影响了用户(重新启动)。
kubectl
命令指出了重启的确切原因 (OOMKilled
)。- Metrics Explorer 可直观呈现内存泄漏随时间变化的情况。
- 日志浏览器显示了导致内存问题的具体行为。
现在,您可以开始实现解决方案了。您可以优化应用代码,以便更高效地处理大型文件,也可以暂时增加工作负载的 YAML 清单中容器的内存限制(具体而言,是 spec.containers.resources.limits.memory
值)。
后续步骤
如需有关解决特定问题的建议,请查看 GKE 的问题排查指南。
如果您在文档中找不到问题的解决方案,请参阅获取支持以获取进一步的帮助,包括以下主题的建议:
- 请与 Cloud Customer Care 联系,以提交支持请求。
- 通过在 StackOverflow 上提问,并使用
google-kubernetes-engine
标记搜索类似问题,来从社区获得支持。您还可以加入#kubernetes-engine
Slack 频道,以获得更多社区支持。 - 使用公开问题跟踪器提交 bug 或功能请求。