获取支持

Google 的主要支持目标是尽快解决生产突发事件。我们通过了解您的配置、分析日志和指标以及与合作伙伴协作来快速解决突发事件。

Cloud Customer Care提供各种支持套餐,以满足您的支持需求。所有 Cloud Customer Care 套餐都包含对 GKE 和 Google Distributed Cloud 的支持。如果您已有 Cloud Customer Care 支持套餐,则表示您已享有 GKE 和 Google Distributed Cloud 的支持服务。

如需了解详情,请参阅 Cloud Customer Care 中心

Google Distributed Cloud 支持的要求

如需有效地排查关键业务突发事件,您必须执行以下操作:

支持工具

Cloud Customer Care 团队依据以下三项信息来排查 Google Distributed Cloud 突发事件:

您的环境配置

创建支持请求时,请运行以下命令,提供有关集群设置的关键信息:

  • 对于所有集群类型,运行 bmctl check cluster --snapshot 命令来捕获 Kubernetes 和节点的相关信息。将生成的 tar 文件附加到支持请求。

  • 对于管理员集群、混合集群和独立集群,请运行 bmctl check cluster 命令来检查集群和节点的运行状况。将生成的日志附加到支持请求。这些日志应位于 bmctl-workspace/[CLUSTER_NAME]/log/check-cluster-[TIMESTAMP] 目录下。

  • 对于用户集群,首先创建包含集群名称和命名空间的健康检查 YAML 文件,然后在适当的管理员集群中应用该文件:

    1. 使用以下 healthcheck 属性创建 YAML 文件。 以下是 cluster-user1 命名空间中名为 user1 的集群的示例内容:

      apiVersion: baremetal.cluster.gke.io/v1
      kind: HealthCheck
      metadata:
        generateName: healthcheck-
        namespace: cluster-user1
      spec:
        clusterName: user1
      
    2. 创建 YAML 文件后,请使用 kubectl 命令在管理用户集群的管理员集群中应用自定义资源。以下是使用在上一步中创建的 YAML 文件的示例命令。在此示例中,ADMIN_KUBECONFIG 变量指定了管理员集群的 kubeconfig 文件的路径:

      kubectl --kubeconfig ADMIN_KUBECONFIG create -f healthcheck-user1.yaml
      

      该命令会返回以下响应:

      healthcheck.baremetal.cluster.gke.io/healthcheck-7c4qf created
      
    3. 等待健康检查作业完成。为此,请测试健康检查作业是否已完成调整。在前面的示例案例中,健康检查作业名称为 healthcheck.baremetal.cluster.gke.io/healthcheck-7c4qf。 以下是一个使用 kubectl 命令的示例测试,该命令将等待 30 分钟,直到健康检查作业完成为止:

      kubectl --kubeconfig ADMIN_KUBECONFIG wait healthcheck healthcheck-7c4qf \
          -n cluster-user1 --for=condition=Reconciling=False --timeout=30m
      

      健康检查作业完成后,前面的 kubectl 命令会返回:

      healthcheck.baremetal.cluster.gke.io/healthcheck-7c4qf condition met
      

      您可以使用以下命令查看健康检查作业结果:

      kubectl --kubeconfig ADMIN_KUBECONFIG get healthcheck healthcheck-7c4qf \
          -n cluster-user1
      

      该命令会返回以下结果:

      NAME                PASS   AGE
      healthcheck-7c4qf   true   17m
      
    4. 使用 kubectl 命令将健康检查作业 Pod 的所有日志收集到本地文件中。以下示例使用了上一个示例健康检查作业:

      kubectl --kubeconfig ADMIN_KUBECONFIG logs -n cluster-user1 \
          -l baremetal.cluster.gke.io/check-name=healthcheck-7c4qf --tail=-1 > \
          healthcheck-7c4qf.log
      

集群日志

创建新的 Google Distributed Cloud 集群时,Cloud Logging 代理默认处于启用状态且范围仅限定于系统级组件。这会将系统级日志复制到与集群关联的 Google Cloud 项目中。系统级日志来自以下命名空间中的 Kubernetes Pod:

  • kube-system
  • gke-system
  • gke-connect
  • istio-system
  • config-management-system
  • gatekeeper-system
  • cnrm-system
  • knative-serving

您可以通过Logs Explorer查询日志。

如需了解详情,请参阅配置日志记录和监控

Google Cloud CLI 和远程集群访问

如果您创建了支持请求,Cloud Customer Care 可能会要求您对集群进行远程只读访问,以帮助更有效地诊断和解决问题。为了使Cloud Customer Care具有足够的访问权限来远程排查集群问题,请确保您已安装并更新为 Google Cloud CLI 的最新版本。Google Cloud CLI 的版本必须为 401.0.0 或更高,才能为 Cloud Customer Care 提供所需的权限。我们建议您定期更新 Google Cloud CLI,以获取额外的权限和其他增强功能。

如需安装 gcloud CLI 的最新组件,请使用 gcloud components update 命令。如需详细了解如何向 Cloud Customer Care 授予集群的远程只读权限,请参阅远程 GKE 集群支持

集群指标

除了日志之外,Cloud Monitoring 代理还会捕获指标。 这会将系统级指标复制到与集群关联的 Google Cloud 项目中。系统级指标来自在集群日志部分中列出的同一命名空间中运行的 Kubernetes Pod。

如需了解详情,请参阅配置日志记录和监控

我们如何对您的环境进行问题排查

以下是典型支持突发事件的一个示例:

  1. 集群管理员在 Google Cloud 控制台中通过 Cloud Customer Care 创建支持请求。然后,他们分别选择 GKE 和 Google Distributed Cloud 作为类别组件。他们输入所需信息,并将相关 bmctl 命令的输出附加到该支持请求。

  2. 支持请求会转交至专门负责 Google Distributed Cloud 的技术支持工程师。

  3. 支持工程师检查快照的内容,以获取环境的上下文。

  4. 支持工程师检查 Google Cloud项目中的日志和指标,输入支持请求 ID 作为业务理由,这会在内部记录。

  5. 支持工程师会以评估和建议的形式回应案例。支持工程师和用户继续排查问题,直到找到解决方案。

Google 提供什么支持?

一般情况下,Cloud Customer Care 支持作为 Google Distributed Cloud 和 Cloud Service Mesh、Policy Controller、Config Sync 以及 Config Controller 的一部分提供的所有软件组件。下表更完整地列出了哪些功能受支持,哪些功能不受支持:

Google Cloud 支持 不支持
Kubernetes 和容器运行时环境 客户对负载均衡器的选择(手动负载均衡)
Connect 和 Connect Agent 客户代码(请参阅开发者支持
Google Cloud 运维、Monitoring、Logging和代理 客户选择的操作系统
捆绑的负载均衡器 物理或虚拟服务器、存储和网络
Ingress 控制器 外部 DNS、DHCP 和身份系统
GKE Identity Service
Cloud Service Mesh
Policy Controller
Config Sync
Config Controller

版本支持政策

此版本支持政策旨在帮助您灵活地安排符合业务需求的升级,同时平衡 Kubernetes 和 Google Distributed Cloud 的快速发展。

Google Distributed Cloud 纯软件遵循 Kubernetes 版本控制方案和发布周期。次要版本大约每年发布三次。每个受支持的次要版本的补丁大约每月发布一次。与 Kubernetes 一样,Google Distributed Cloud 同时支持最新的三个次要版本。

Google 为每个 Google Distributed Cloud 次要版本提供以下时间段内的支持(以较晚者为准):

  • 次要版本首次发布后的 12 个月。
  • 发布第三个后续次要版本。

例如,次要版本 1.33 于 2025 年 9 月 2 日发布。此次要版本及其所有补丁的支持期限为 2026 年 9 月 2 日或次要版本 1.36 的发布日期(以较晚的日期为准)。

我们建议您使用产品的最新次要版本和推荐的补丁版本来维护 Google Distributed Cloud 环境。

此版本支持政策包括:

  • Cloud Customer Care 的故障修复支持。
  • 修补 Kubernetes 和相关组件的 CVE 安全漏洞。
  • 对 Kubernetes 和相关组件应用常规补丁程序。

当您的版本服务终止后,您可以继续提交支持请求,以获得以下方面的支持:

  • 帮助解决技术问题。
  • 协助解决结算问题。
  • 关于产品使用方面的指导,包括排查问题和测试方面的帮助。

扩展支持可作为一次性活动有条件地获得批准,但需满足版本固定和未来升级时间表要求。如需了解详情,请与您账号的首席客户工程师或客户经理联系。或者,您可以通过 Google Cloud 控制台提交支持请求。此类请求会转到您账号的客户工程团队那里。

支持期

下表显示了 Google Distributed Cloud 支持的次要版本以及最早的服务终止 (EOL) 日期:

Google Distributed Cloud 版本 发布日期 服务终止日期*
1.33 2025-09-02 2026-09-02 或 1.36 发布日期
1.32 2025-05-06 2026-05-06 或 1.35 发布日期
1.31 2024-12-18 2025-12-18 或 1.34 发布日期

* 服务终止 (EOL) 为这两个日期中较晚的日期。

如需详细了解 Google Distributed Cloud 和相关Google Cloud 产品的版本兼容性,请参阅版本和升级支持

版本控制方案

Google Distributed Cloud 使用 Kubernetes 语义化版本控制来引用受支持的 Kubernetes 版本,但附加 GKE 补丁版本。这会生成 x.y.z-gke.N 形式的版本号。

Kubernetes 主要版本 (x)
如果向公共 API 引入任何向后不兼容的更改,则主要版本通常会递增。主要版本将 Kubernetes 版本从 x.y 递增到 x+1.y
Kubernetes 次要版本 (y)
Kubernetes 每年发布三次新的次要版本。每个发布周期大约为 15 周。已弃用的 API 可能会与新的次要版本一起移除。次要版本将 Kubernetes 版本从 1.y 递增到 1.y+1;例如,Kubernetes 1.29 是 Kubernetes 1.28 之后的次要版本。
Google Distributed Cloud 补丁版本 (z-gke.N)
补丁版本(例如 1.28.300-gke.131)会将补丁版本 (z) 递增 100,并包含 -gke.N 后缀,用于指示 build。补丁版本包含安全更新和 bug 修复。 Google Distributed Cloud 补丁发布版本与 Kubernetes 补丁版本无关。

责任共担模型

在 Google Distributed Cloud 上运行关键业务生产应用需要多方承担不同的责任。以下部分列出了不同方的角色和相应的责任(未详尽列出)。

Google 的责任

  • 维护和分发 Google Distributed Cloud 软件包。
  • 在 Google Distributed Cloud 有可用升级时通知用户,并为之前的版本生成升级脚本。

    Google Distributed Cloud 仅支持依序升级集群(例如 1.31 → 1.32 → 1.33,不支持 1.31 → 1.33)。升级节点池时,在某些情况下,您可以跳过某个次要版本。如需详细了解升级逻辑,请参阅版本规则

  • 运行 Connect 和 Cloud Operations 服务。

  • 针对与 Google 提供的组件相关的任何问题,进行问题排查、提供解决办法以及纠正根本原因

用户的责任

  • 本地集群的整体系统管理。
  • 维护部署在集群上的所有应用工作负载。
  • 运行、维护和修补数据中心基础架构,包括网络、服务器、操作系统、存储以及与Google Cloud的连接。
  • 如果选择了手动负载平衡器选项,则需要运行、维护和修补网络负载平衡器。
  • 定期升级 Google Distributed Cloud 版本。
  • 监控集群和应用,并响应任何突发事件。
  • 确保 Cloud Operations 代理已部署到集群。
  • 向 Google 提供环境详细信息,以便进行问题排查。

开发者支持

Google 不会专门针对您的应用工作负载提供支持。但是,我们会尽最大努力为开发者提供支持,以确保开发者可以在 Google Distributed Cloud 上运行应用。我们认为,在开发过程中尽早采取行动有助于避免部署时发生重大突发事件。

这个尽最大努力的开发者支持可供使用付费支持套餐的客户使用,并且会被视为 P3 优先级(阻止发布的问题)或 P4 优先级(一般咨询)。在此分类中,优先级 0 是最高优先级。