管理组织资源

作为 Google Distributed Cloud (GDC) 空气隔离环境的基础设施运维人员 (IO)，您需要验证系统健康状况、配置用户和网络，以及管理底层硬件系统（例如计算、存储和网络）的生命周期。

准备工作

要完成本文档，您需要拥有以下资源的访问权限：

  • gdcloud CLI 或 kubectl CLI

  • Linux 环境

如需获得管理组织所需的权限，请让您的安全管理员为您授予组织管理员 (organization-admin) 角色。

访问和监控服务器

访问 GDC 服务器并监控其状态，以确保它们安全、最新且正常运行。

如需详细了解如何监控组织的服务器，请参阅查询和查看指标页面。

管理服务器的生命周期

服务器生命周期管理包括以下功能：

  • 重启设备。
  • 正在重置映像。
  • 主板管理控制器 (BMC) 和复杂可编程逻辑器件 (CPLD) 固件更新。
  • 操作系统或软件更新。
  • 操作系统配置，例如安全设置。

在维护窗口期间，我们会定期执行以下操作：基础操作系统安全补丁、服务器主机软件的软件包升级和服务器固件升级。

维护窗口包括以下操作：

  • 为服务器操作系统安装紧急安全更新。
  • 升级一个或多个服务器上的宿主软件包。
  • 升级一个或多个服务器上的固件。

添加和管理工作负载服务器

如需添加其他工作负载服务器或管理现有工作负载服务器，请更新存储在 iac 代码库中的 OrganizationZonalConfig 自定义资源：

  1. 生成可用服务器和服务器类型的列表：

    kubectl get servers -n gpc-system -o \
    jsonpath='{range .items[?(@.status.bareMetalHostStatus.provisionState=="available")]}{.metadata.name}{"\t"}{.spec.serverHardware.machineClassName}{"\t"}{.status.bareMetalHostStatus.provisionState}{"\n"}{end}'

    输出类似于以下内容：

    ag-aa-bm04   o1-standard1-64-gdc-metal   available
ag-ab-bm07   o1-standard1-64-gdc-metal   available
ag-ab-bm11   o1-highmem1-96-gdc-metal    available
ag-ab-bm12   o1-highmem1-96-gdc-metal    available
ag-ab-bm13   o1-highmem1-96-gdc-metal    available
ag-ab-bm14   o1-highgpu1-48-gdc-metal    available
ag-ab-bm15   o1-highgpu1-48-gdc-metal    available
ag-ab-bm16   o1-highgpu1-48-gdc-metal    available

    请注意哪些服务器可用，并在修改组织的工作负载服务器时确保仅分配可用的服务器。

  2. 在 iac 代码库中打开 OrganizationZonalConfig 自定义资源 YAML 文件：

    vim IAC_REPO_PATH/iac/infrastructure/global/orgs/root/ORG_NAME-ZONE.yaml

    替换以下内容：

    • IAC_REPO_PATH：iac 代码库的文件夹路径。
    • ORG_NAME：组织的名称。
    • ZONE：相应宇宙中可用区的名称。时区名称采用以下格式：{generalRegion}-{regionQualifier}{regionCounter}-{zoneLetter}。例如 us-central1-b。如需了解地区属性值，请参阅客户意见征集问卷中的地区部分。

  3. 更新 YAML 文件的 workloadServers 部分。添加新的工作负载服务器或管理每种类型的现有服务器数量：

    ...
workloadServers:
  o1-highmem1-40-gdc-metal: 1
  o1-standard1-64-gdc-metal: 2
  o1-highmem1-96-gdc-metal: 3
  o1-highmem1-104-gdc-metal: 4
  o1-highmem1-448-gdc-metal: 5
  o1-highgpu1-48-gdc-metal: 6
...

  4. 保存并关闭互动编辑器。

  5. 暂存并提交对组织区域配置 YAML 文件的更改：

    git add IAC_REPO_PATH/iac/infrastructure/global/orgs/root/ORG_NAME-ZONE
git commit

  6. 将更新推送到 GitLab：

    git -c http.sslVerify=false push

  7. 等待代码审核和合并。

  8. 对于分布式云部署中所有分布式云区域的所有 GitLab 代码库，重复执行上述步骤，并使用相同的内容和目录结构。

    在分布式云部署中，每个可用区都包含单独的断开连接的 GitLab 实例。对于在 GitLab 中创建、更新或删除的每个全球性资源，您都必须将完全相同的内容提交到每个可用区的 GitLab 代码库。全局根协调器 pod 在主分布式云地区中运行，该地区在全局 API 中 zoneselectionresult 自定义资源的 primary 字段中定义。协调器会将数据从主区域的 GitLab 同步到全局 API。

  9. 验证您分配的工作负载服务器是否可供使用：

    kubectl --kubeconfig /root/release/root-admin/root-admin-kubeconfig get servers -n gpc-system -o \
    jsonpath='{range .items[?(@.spec.nodePoolClaimRef.namespace=="org-1")]}{.metadata.name}{"\t"}{.status.provisionReady}{"\n"}{end}'

    如果工作负载服务器设置为 true，则表示可用。输出内容类似如下：

    zi-aa-bm04      true
zi-aa-bm05      true
zi-aa-bm06      true

增加存储空间容量

每个组织在某个可用区可用的存储空间量在 OrganizationZonalConfig 资源的 capacities 字段中定义。

如需增加这些存储类别的配额，请更新每个可用区中的 OrganizationZonalConfig 资源。

  1. 在 iac 代码库中打开 OrganizationZonalConfig 自定义资源 YAML 文件：

    vim IAC_REPO_PATH/iac/infrastructure/global/orgs/root/ORG_NAME-ZONE.yaml

    替换以下内容：

    • IAC_REPO_PATH：iac 代码库的文件夹路径。
    • ORG_NAME：组织的名称。
    • ZONE：相应全球可用区的名称，例如 us-central1-b。如需详细了解区域属性值，请参阅客户意见征集问卷的区域部分。

  2. 使用存储类型的新配额值更新 YAML 文件的 capacities 部分。例如：

    # Several lines of code are omitted here.
spec:
  capacities:
    storage:
      file-standard: FILE_QUOTA
      block-standard: BLOCK_QUOTA
      object-standard: OBJECT_QUOTA

    替换以下内容：

    • FILE_QUOTA：相应可用区中文件存储的新配额值，例如 10Ti。
    • BLOCK_QUOTA：相应可用区中块存储的新配额值，例如 10Ti。
    • OBJECT_QUOTA：相应可用区中对象存储的新配额值，例如 10Ti。

    如需详细了解如何在 OrganizationZonalConfig 资源中定义存储容量，请参阅 TypedResourceCapacities 参考文档。

  3. 保存并关闭互动编辑器。

  4. 暂存并提交对组织区域配置 YAML 文件的更改：

    git add IAC_REPO_PATH/iac/infrastructure/global/orgs/root/ORG_NAME-ZONE
git commit

  5. 将更新推送到 GitLab：

    git -c http.sslVerify=false push

  6. 等待代码审核和合并。

  7. 针对 GDC 部署中所有 GDC 区域的所有 GitLab 代码库，重复执行上述步骤，并使用相同的内容和目录结构。