GKE 问题排查简介

Autopilot Standard

---

本页面将介绍 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 控制台还提供强大的日志记录和监控工具，让您能够调查过去故障的根本原因，并主动预防未来发生类似问题。如需详细了解这些工具，请参阅使用 Cloud Logging 进行历史分析和使用 Cloud Monitoring 执行主动监控部分。

查找集群问题

Kubernetes 集群页面可让您大致了解集群的健康状况。如要确定任何集群问题，不妨从此页面着手。

• 首先，在 Google Cloud 控制台中，前往 Kubernetes 集群页面。

  转到 KUBERNETES 集群

以下是一些示例，展示了如何使用此页面进行问题排查：

• 如需有关改进集群健康状况、升级策略和费用优化的建议，请点击查看建议。
• 如需识别健康状况不佳的集群，请查看状态列。任何没有绿色对勾标记的集群都需要注意。
• 如需查看潜在问题，请查看通知列。点击任意通知消息即可了解详情。

调查特定集群

发现集群存在问题后，您可以探索相应集群的详情页面，获取有助于排查集群问题并了解其配置的深入信息。

如需前往集群的详情页面，请执行以下操作：

1. 转到 Kubernetes 集群页面

   转到 KUBERNETES 集群

2. 查看名称列，然后点击要调查的集群的名称。

以下是一些示例，展示了如何使用集群详情页面排查集群问题：

• 对于常规健康检查，请尝试以下选项：

  • 如需查看集群级信息中心，请前往可观测性标签页。默认情况下，GKE 会在您创建集群时启用 Cloud Monitoring。启用 Cloud Monitoring 后，GKE 会自动设置此页面上的信息中心。以下视图可能非常有助于问题排查：

    • 概览：查看集群的健康状况、资源利用率和关键事件的简要摘要。此信息中心可帮助您快速评估集群的总体状态并找出潜在问题。
    • 流量指标：查看基于节点的网络指标，深入了解 Kubernetes 工作负载之间的流量。
    • 工作负载状态：查看 Deployment、Pod 和容器的状态。识别出现故障或健康状况不佳的实例，并检测资源限制条件。

    • 控制平面：查看控制平面的健康状况和性能。借助此信息中心，您可以监控 kube-apiserver 和 etcd 等组件的关键指标，识别性能瓶颈，并检测组件故障。

      提示：您可以基于这些信息中心创建自定义信息中心。您可以复制预定义的信息中心，然后对其进行自定义，以纳入与您的需求相关的特定指标、过滤条件或可视化图表。

  • 如需查看近期发生的应用错误，请前往应用错误标签页。此标签页会显示错误发生次数、首次发生时间以及上次发生时间，可帮助您确定错误优先级并按优先顺序解决问题。

    如需进一步调查错误，请点击相应错误消息以查看详细的错误报告，其中包含相关日志的链接。

• 如果您是在最近升级或变更后排查问题，请查看集群详情标签页中的集群基本信息部分。确认版本字段中是否列出所需版本。如需进一步调查，请点击升级部分中的显示升级历史记录。

• 如果您使用的是 Standard 集群，并且 Pod 陷入 Pending 状态，或者您怀疑节点过载，请检查节点标签页。Autopilot 集群没有节点标签页，因为对于此类集群，GKE 会为您管理节点。

  • 在节点池部分中，检查自动扩缩是否正确配置，以及机器类型是否适合您的工作负载。
  • 在节点部分中，查找是否有任何节点的状态不是 Ready。NotReady 状态表示节点本身存在问题，例如资源压力或 kubelet 问题（kubelet 是在每个节点上运行以管理容器的代理）。

查找工作负载问题

如果您怀疑特定应用（例如 Deployment 失败的应用）存在问题，请前往 Google Cloud 控制台中的工作负载页面。此页面集中显示了集群中运行的所有应用。

• 首先，在 Google Cloud 控制台中，前往工作负载页面。

  转到“工作负载”

提示：如果您在处理资源众多的项目，不妨使用过滤条件栏将视图范围缩小到特定集群或命名空间。

以下是一些示例，展示了如何使用此页面进行问题排查：

• 如需识别健康状况不佳的工作负载，请查看状态列。任何没有绿色对勾标记的工作负载都需要注意。
• 如果应用无响应，请查看 Pod 列。例如，如果状态为 1/3，则表示三个应用副本中只有一个在运行，这表明存在问题。

调查特定工作负载

当您通过概况确定存在问题的工作负载后，请探索相应工作负载的详情页面，开始隔离导致问题的根本原因。

如需前往工作负载的详情页面，请执行以下操作：

1. 转到工作负载页面。

   转到“工作负载”

2. 查看名称列，然后点击要调查的工作负载的名称。

以下是一些示例，展示了如何使用工作负载详情页面排查工作负载问题：

• 如需检查工作负载的配置，请使用工作负载的概览和详情标签页。您可以使用此信息来验证事件（例如是否部署了正确的容器映像标记），或检查工作负载的资源请求和限制。

  注意：您可能没有概览标签页，具体取决于您的工作负载类型。例如，StatefulSet 只有详情标签页。不过，这两个标签页都有助于您查看配置。

• 如需查找特定崩溃 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
  "[e-mail]" cannot list resource "pods" in API group "" in the
  namespace "default"
  

  如果您没有所需权限，请让集群管理员为您分配必要的角色。

获取正在运行的内容的概况

kubectl get 命令可帮助您从整体上了解集群中正在发生的概况。使用以下命令可查看两个最重要的集群组件（节点和 Pod）的状态：

1. 如需检查节点健康状况是否良好，请查看所有节点及其状态的详细信息：

   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 之外的任何状态都需要进一步调查。

2. 如需检查 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。

提示：在 kubectl get 命令中添加 -o wide，即可查看有关资源的更多信息。例如，kubectl get nodes -o wide 命令会在输出中添加以下列：Internal-IP、External-IP、OS-Image、Kernel-Version 和 Container-Runtime。

详细了解特定资源

发现问题后，您需要了解更多详情。例如，状态不是 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 日志。Logs Explorer 提供了强大的过滤选项，可帮助您筛选、隔离并查明问题。

如需访问和使用 Logs Explorer，请完成以下步骤：

1. 在 Google Cloud 控制台中，前往 Logs Explorer 页面。

   转到日志浏览器

2. 在查询窗格中，输入查询。使用 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 相关的查询。

3. 点击运行查询。

4. 如需查看完整的日志消息（包括 JSON 载荷、元数据和时间戳），请点击相应日志条目。

如需详细了解 GKE 日志，请参阅 GKE 日志简介。

使用 Cloud Monitoring 执行主动监控

问题发生后，查看日志是问题排查的关键步骤。不过，一个真正具有弹性的系统还需要采取主动方法来在问题发生之前识别出问题，从而避免问题导致服务中断。

如要主动发现未来可能出现的问题并跟踪一段时间内的关键绩效指标，不妨使用 Cloud Monitoring。Cloud Monitoring 提供信息中心、指标和提醒功能。这些工具有助于您发现不断上升的错误率、不断增加的延迟时间或资源限制，从而帮助您在用户受到影响之前积极应对。

查看实用指标

GKE 会自动将一组指标发送到 Cloud Monitoring。以下各部分列出了一些最重要的问题排查指标：

• 容器性能和健康状况指标
• 节点性能和健康状况指标
• Pod 性能和健康状况指标

如需查看完整的 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	容器实际的内存用量（以字节为单位）。	跟踪内存消耗情况，以识别潜在的内存泄漏或内存不足错误风险。
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，因为用量可能超过请求量。	识别超额预配或预配不足的内存请求，以改进调度并防止出现内存不足错误。

节点性能和健康状况指标

如果您需要诊断底层 GKE 基础架构的问题，不妨检查这些指标。这些指标对于了解节点的整体健康状况和容量至关重要，有助于您调查节点是否处于不健康或高压状态，或者节点是否有足够的内存来调度新的 Pod。

指标	说明	对问题排查的重要性
kubernetes.io/node/cpu/allocatable_utilization	实例当前使用的 CPU 占可分配 CPU 的比例。	指示 Pod 的总 CPU 用量是否致使节点的可用 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，请完成以下步骤：

1. 在 Google Cloud 控制台中，前往 Metrics Explorer 页面。

   进入 Metrics Explorer

2. 在指标字段中，选择或输入要检查的指标。

3. 查看结果并观察一段时间内的任何趋势。

例如，如需调查特定命名空间中 Pod 的内存消耗情况，您可以执行以下操作：

1. 在选择指标列表中，选择指标 kubernetes.io/container/memory/used_bytes，然后点击应用。
2. 点击添加过滤条件，然后选择 namespace_name。
3. 在值列表中，选择要调查的命名空间。
4. 在汇总字段中，依次选择总和 > pod_name，然后点击确定。此设置会为每个 Pod 显示单独的时序线。
5. 点击保存图表。

生成的图表会显示每个 Pod 在一段时间内不同时间点的内存用量，有助于您直观地识别内存消耗量异常高或出现激增的任何 Pod。

Metrics Explorer 在构建所需查看的指标方面具有极大的灵活性。如需详细了解 Metrics Explorer 的高级选项，请参阅 Cloud Monitoring 文档中的使用 Metrics Explorer 创建图表。

创建提醒以主动检测问题

如需在出现问题或指标超出特定阈值时收到通知，您可以在 Cloud Monitoring 中设置提醒政策。

例如，如需设置一项提醒政策，以便在超过容器 CPU 限额的 80% 且该状态持续 5 分钟的情况下通知您，请执行以下操作：

1. 在 Google Cloud 控制台中，前往提醒页面。

   前往提醒

2. 点击创建政策。

3. 在选择指标框中，过滤 CPU limit utilization，然后选择以下指标：kubernetes.io/container/cpu/limit_utilization。

4. 点击应用。

5. 将添加过滤条件字段留空。此设置会在有任何集群违反阈值限制时触发提醒。

6. 在转换数据部分，执行以下操作：

   1. 在滚动窗口列表中，选择 1 分钟。此设置意味着 Google Cloud 每分钟会计算一次平均值。

   2. 在滚动窗口函数列表中，选择平均值。

      这两个设置都会每分钟计算每个容器的 CPU 限额的平均利用率一次。

7. 点击下一步。

8. 在配置提醒部分中，执行以下操作：

   1. 在条件类型部分，选择阈值。
   2. 在提醒触发器部分，选择任何时序违反。
   3. 在阈值位置部分，选择高于阈值。
   4. 在阈值部分，输入 0.8。此值表示您要监控的阈值为 80%。
   5. 点击高级选项。
   6. 在重新测试窗口列表中，选择 5 分钟。此设置意味着，只有当 CPU 利用率持续 5 分钟以上保持在 80% 以上时，系统才会触发提醒，从而减少因短暂峰值而导致的误报。
   7. 在条件名称字段中，为条件指定一个描述性名称。
   8. 点击下一步。

9. 在配置通知并最终确定提醒部分，执行以下操作：

   1. 在通知渠道列表中，选择您要接收提醒的渠道。如果您没有渠道，请点击管理通知渠道以创建一个渠道。
   2. 在为提醒政策命名字段中，为政策指定一个清晰的描述性名称。
   3. 其他所有字段都保留默认值。
   4. 点击下一步。

10. 检查您的政策，如果一切正常，请点击创建政策。

如需了解创建提醒的其他方式，请参阅 Cloud Monitoring 文档中的提醒概览。

借助 Gemini Cloud Assist 加快诊断速度

预览版

此产品或功能需遵守服务专用条款的“通用服务条款”部分中的“非正式版产品条款”。 非正式版产品和功能“按原样”提供，可能只能获得有限的支持。 如需了解详情，请参阅发布阶段说明。

有时，即使您使用了前几部分中探讨的工具，问题的根本原因也不会立即显现出来。调查复杂案例可能非常耗时，并且需要深厚的专业知识。对于这种情况，Gemini Cloud Assist 可以提供帮助。它可以自动检测隐藏的模式、发现异常情况并提供摘要，帮助您快速查明可能的原因。

作为一项尚处于发展早期的技术，Gemini for Google Cloud产品可能会生成看似合理但实际上不正确的输出。我们建议您在使用 Gemini for Google Cloud 产品的输出前先进行验证。 如需了解详情，请参阅 Gemini for Google Cloud 和 Responsible AI。

访问 Gemini Cloud Assist

如需访问 Gemini Cloud Assist，请完成以下步骤：

1. 在 Google Cloud 控制台中，前往任意页面。

2. 在 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 控制台中确认问题

首先，您需要大致了解工作负载，以确认问题。

1. 在 Google Cloud 控制台中，前往工作负载页面，然后过滤出 product-catalog 工作负载。
2. 查看 Pod 状态列。您看到的不是表明健康状况良好的 3/3 值，而是持续显示的 2/3 值，而这是一种不健康的状态值。该值表示应用的某个 Pod 的状态不是 Ready。
3. 您需要进一步调查，因而您点击 product-catalog 工作负载的名称以前往其详情页面。
4. 在详情页面上，查看托管式 Pod 部分。您立即发现了一个问题：有 Pod 的 Restarts 列显示 14，这是一个异常高的数字。

如此高的重启次数证实了是该问题导致了应用不稳定，并表明有容器未通过健康检查或发生崩溃。

使用 kubectl 命令查找原因

既然您已了解应用反复重启的问题，那么就需要找出导致该问题的原因。kubectl describe 命令非常适合用来实现此目的。

1. 您会获得不稳定 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
   

2. 您描述了该不稳定的 Pod 以获取详细的事件记录：

   kubectl describe pod product-catalog-d84857dcf-g7v2x -n prod
   

3. 您查看了输出内容，并在 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 部分显示 Warning: BackOff 事件以及相应的 Back-off restarting failed container 消息。此消息证实了容器处于故障循环中，这是导致您之前看到的 CrashLoopBackOff 状态的直接原因。

使用指标直观呈现行为

kubectl describe 命令会告知您发生了什么情况，但 Cloud Monitoring 可以显示您的环境在一段时间内的行为变化。

1. 在 Google Cloud 控制台中，前往 Metrics Explorer。
2. 选择 container/memory/used_bytes 指标。
3. 您可以过滤输出以将结果范围缩小到针对特定的集群、命名空间和 Pod 名称。

该图表显现出一个明显的模式：最初内存用量稳步攀升，然后在容器因内存不足而被终止并重启后突然降至零。该直观证据证实了存在内存泄漏或内存限额不足的问题。

在日志中查找根本原因

现在，您知道容器内存不足，但仍不清楚具体原因。如要找出根本原因，您可以使用 Logs Explorer。

1. 在 Google Cloud 控制台中，前往 Logs Explorer。

2. 您可以编写查询，以过滤出特定容器自上次崩溃时间（您在 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"
   

3. 在日志中，您会发现每次崩溃前都有一系列重复的消息：

   {
     "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 直观呈现了一段时间内的内存泄漏变化情况。
• Logs Explorer 揭示了导致内存问题的具体行为。

现在，您可以开始实现解决方案了。您可以优化应用代码，以便更高效地处理大型文件；也可以在工作负载的 YAML 清单中暂时增加容器的内存限额（具体而言，即 spec.containers.resources.limits.memory 值），作为临时的解决方法。

后续步骤

• 如需有关解决特定问题的建议，请查看 GKE 的问题排查指南。

• 如果您在文档中找不到问题的解决方案，请参阅获取支持以获取进一步的帮助，包括以下主题的建议：

  • 请与 Cloud Customer Care 联系，以提交支持请求。
  • 通过在 StackOverflow 上提问并使用 google-kubernetes-engine 标记搜索类似问题，从社区获得支持。您还可以加入 #kubernetes-engine Slack 频道，以获得更多社区支持。
  • 使用公开问题跟踪器提交 bug 或功能请求。