升级集群

本文档介绍了如何升级 Google Distributed Cloud (GDC) 网闸隔离 Kubernetes 集群的 Kubernetes 版本。您必须为集群规划例行升级,以确保它们包含最新的 Kubernetes 功能和修复。

本文档面向平台管理员群组中的 IT 管理员、安全工程师和网络管理员等受众群体,他们负责管理其组织内的 Kubernetes 资源。如需了解详情,请参阅 GDC 网闸隔离配置文档的受众群体。

准备工作

如需完成本文档中的任务,您必须请求必要的权限并准备环境。

申请 IAM 角色

您必须拥有特定角色,才能获得升级 Kubernetes 集群所需的权限。您必须请求范围限定为您的项目和组织的角色。

组织角色

如需列出 Kubernetes 集群的可用升级版本,请让您的 IAM 组织管理员为您授予用户集群管理员 (user-cluster-admin) 角色。此角色未绑定到命名空间。

如果您管理的是标准集群,并且无法从平台管理员群组获取用户集群管理员角色,则必须请求他们为您提供可用的 Kubernetes 升级版本列表。

项目角色

如需创建、删除、修改或查看集群升级,请让您的 IAM 项目管理员为您授予标准集群管理员 (standard-cluster-admin) 角色。此角色会绑定到您的项目命名空间。

准备环境

如需使用 API 对 Kubernetes 集群运行命令,请确保您拥有以下资源:

  • 下载并安装 gdcloud CLI。

  • 安装 kubectl CLI。

  • 找到 Kubernetes 集群名称,或向平台管理员群组的成员询问集群名称。

  • 在这些说明中,请使用 Kubernetes 集群名称替换 CLUSTER_NAME。

  • 登录并生成管理 API 服务器的 kubeconfig 文件。

  • 在这些说明中,请使用 Management API 服务器的 kubeconfig 路径替换 MANAGEMENT_API_SERVER。

升级 Kubernetes 集群

使用 UserClusterUpgradeRequest API 升级现有 Kubernetes 集群。

如需使用 API 升级 Kubernetes 集群,请按以下步骤操作:

  1. 通过输出 UserClusterMetadata 对象的 kubernetesVersion 值,列出可用的 Kubernetes 升级版本:

    kubectl --kubeconfig MANAGEMENT_API_SERVER \
        get userclustermetadata -o=custom-columns='TARGET_VERSION:.spec.kubernetesVersion'
    

    将 MANAGEMENT_API_SERVER 替换为管理 API 服务器的 kubeconfig 文件的路径。

    该命令会返回可用 Kubernetes 版本的列表:

    TARGET_VERSION
    1.30.1000-gke.85
    
  2. 请注意上一个输出中您要将集群升级到的 Kubernetes 版本。您在下一步的升级请求中指定的 targetVersion 必须是这些可用版本之一。

  3. 通过创建 UserClusterUpgradeRequest 资源来请求集群升级:

      kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f - <<EOF
      apiVersion: cluster.gdc.goog/v1
      kind: UserClusterUpgradeRequest
      metadata:
        name: CLUSTER_NAME
        namespace: CLUSTER_NAMESPACE
      spec:
        clusterRef:
          name: CLUSTER_NAME
        targetVersion: TARGET_VERSION
      EOF
    

    替换以下内容:

    • MANAGEMENT_API_SERVER:Management API 服务器的 kubeconfig 文件的路径。
    • CLUSTER_NAME:要升级的 Kubernetes 集群的名称,例如 user-vm-2。
    • CLUSTER_NAMESPACE:Kubernetes 集群的命名空间。对于共享集群,请使用 platform 命名空间。对于标准集群,请使用集群的项目命名空间。
    • TARGET_VERSION:在上一步中确定的升级目标版本,例如 1.30.1000-gke.85。

    Kubernetes 集群的平均升级时间约为 20 分钟。

  4. 通过监控 UserClusterUpgradeRequest 资源来验证集群升级:

    kubectl --kubeconfig MANAGEMENT_API_SERVER \
        describe userclusterupgraderequest CLUSTER_NAME \
        -n CLUSTER_NAMESPACE
    

    替换以下内容:

    • MANAGEMENT_API_SERVER:Management API 服务器的 kubeconfig 文件的路径。
    • CLUSTER_NAME:要升级的 Kubernetes 集群的名称,例如 user-vm-2。
    • CLUSTER_NAMESPACE:Kubernetes 集群的命名空间。对于共享集群,请使用 platform 命名空间。对于标准集群,请使用集群的项目命名空间。

    检查输出的 Spec 部分。它包含 Current Version 和 Target Version。如果 Current Version 和 Target Version 不同,则升级仍在进行中。

    Spec:
      ...
      Current Version: 1.29.500-gke.60
      Target Version: 1.30.1000-gke.85
    Status:
      Conditions:
      - Message: Upgrade is in progress
        Reason: UpgradeInProgress
        Status: "False"
        Type: Succeeded
    

    当 Succeeded 条件的状态为 True 且 Current Version 与 Target Version 匹配时,升级即已成功完成。

    如果 Succeeded 条件的状态为 False,则升级失败。如果您遇到与 Kubernetes 集群升级相关的错误,请与基础架构运维人员群组联系,以获取进一步的帮助。

验证升级后的集群状态

Kubernetes 集群升级后,通过检查 Cluster 资源状态,确认集群及其组件运行状况良好:

  1. 查看 Cluster 资源的 status.conditions 和 status.componentsConditions 字段:

    kubectl --kubeconfig MANAGEMENT_API_SERVER \
        get cluster CLUSTER_NAME \
        -n CLUSTER_NAMESPACE -o yaml
    

    替换以下内容:

    • MANAGEMENT_API_SERVER:Management API 服务器的 kubeconfig 文件的路径。
    • CLUSTER_NAME:Kubernetes 集群的名称,例如 user-vm-2。
    • CLUSTER_NAMESPACE:Kubernetes 集群的命名空间。对于共享集群,请使用 platform 命名空间。对于标准集群,请使用集群的项目命名空间。
  2. 在输出中,验证 status 部分中的以下内容:

    • 在 status.conditions 中,验证 Ready 条件的 status 是否为 True,以及 Reconciling 条件的 status 是否为 False。
    • 在 status.componentsConditions 中,验证 Ready 条件的 status 是否为 True,Reconciling 条件的 status 是否为 False,以及是否没有任何条件显示 reason 为 ReconciliationError 或 Reconciling。

    对于具有三个控制平面节点和三个工作器节点的 Kubernetes 集群,升级大约需要 20 分钟。如果集群或其组件在 20 分钟后仍处于 Reconciling 状态,或者任何条件显示 ReconciliationError,请与您的基础架构运维人员群组联系,以获取进一步帮助。

后续步骤