1. 创建客户组织

预计完成时间：3 小时

技能配置文件：部署工程师

作为运营商，您可以创建组织，以便为客户提供对平台基础架构的访问权限。如需获得创建组织所需的权限，请让您的 Security Admin 为您授予组织管理员角色。

Organization 资源是 Google Distributed Cloud (GDC) 气隙资源层次结构的根节点，属于组织的所有资源都会在组织节点下进行分组。这使您可以集中查看和控制属于组织的所有资源。

如需详细了解组织，请参阅组织概览。

1.1. 准备工作

确保您已安装以下各项：

  • 系统中的浏览器。

  • Git 命令行界面 (CLI)。

  • kubectl CLI。

  • gdcloud CLI。

1.2. 在 OC IT ADFS 中创建 OIDC 客户端

  1. 请参阅 ADFS OIDC 配置说明，在 ADFS 中为操作员创建一个 OpenID Connect (OIDC) 客户端，以便操作员访问您将要创建的组织。记录 OIDC 客户端的客户端 ID 和客户端密钥。您不得在连接到其他集群（例如根管理员集群和其他组织管理员集群）或服务（例如 ServiceNow）时重复使用客户端。

  2. 将以下 GKE Identity Service 回调网址添加到您为要创建的组织创建的 ADFS OIDC 客户端中的许可名单：

    https://ais-core.ORG_NAME.GDC_URL.GDC_DOMAIN/finish-login

    例如：

    • 组织名称：operations
    • 分布式云实例名称：google
    • 分布式云域名：gdch.test

    在这种情况下，GKE Identity Service 回调网址为 https://ais-core.operations.google.gdch.test/finish-login。

  3. 将以下 GKE Identity Service 回调网址添加到您为 GDC 宇宙中的每个地区创建的 ADFS OIDC 客户端中的许可名单：

    https://ais-core.ORG_NAME.ZONE.GDC_URL.GDC_DOMAIN/finish-login

    例如：

    • 组织名称：operations
    • 地区名称：zone-1
    • 分布式云实例名称：google
    • 分布式云域名：gdch.test

    在这种情况下，GKE Identity Service 回调网址为 https://ais-core.operations.zone-1.google.gdch.test/finish-login。

  4. 设置以下变量，以便在后续部分中使用：

    export ADFS_CERT_BASE64=ADFS_CERT_BASE64
export ADFS_CLIENT_ID=ADFS_CLIENT_ID
export ADFS_CLIENT_SECRET=ADFS_CLIENT_SECRET
export ADFS_ISSUER_URI=ADFS_ISSUER_URI

    将变量替换为以下值：

    变量定义
    ADFS_CERT_BASE64 经过 base64 编码的 adfs.pem 文件。
    ADFS_CLIENT_ID ADFS 客户端标识符。
    ADFS_CLIENT_SECRET ADFS 客户端共享密钥。
    ADFS_ISSUER_URI ADFS 颁发者 URI。如需获取该 URI，请检查 ADFS 服务器的 /adfs/.well-known/openid-configuration 路径：

    curl -s https://fs.opscenter.local/adfs/.well-known/openid-configuration | jq '.issuer' "https://fs.opscenter.local/adfs"

    该值通常为 https://adfs.domain.com/adfs。

1.3 创建全球子网并将其划分为每个可用区

在创建组织之前，您必须先创建全局根子网，然后使用 IP 地址管理 (IPAM) 公共 API 子网将这些子网划分为各个可用区。如果您要在之前有 v1 组织的区域中创建新的 v2 组织，请务必在创建全局子网之前查看其他前提条件页面。

全局根子网托管根 IP 地址范围 (CIDR) 池，该池会拆分到每个可用区，以启动租户组织内的所有集群，包括组织基础架构集群和工作负载虚拟机。IP 地址范围的一小部分也作为任播 IP 地址池提供给根子网。您可以使用控制器自动为每个可用区分配专用 CIDR，也可以手动为每个可用区提供 CIDR。

如需引导组织，您需要从组织输入问卷 (OIQ) 中获取内部 IP 地址范围输入。您必须使用这些 IP 地址范围在全局 API 服务器中创建全局根子网。

您必须为每个全局 API 服务器创建不同的根子网。下一部分将提供 OIQ 字段、全局根子网名称和全局 API 服务器的映射。

1.3.1. 为 OIQ 定义 CIDR 范围

CIDR 范围不得相互重叠，也不得与 zone-infra-cidr 重叠。

zone-infra-cidr 存在于每个可用区中，如果客户定义了该值，则可以从客户意见征集问卷 (CIQ) 中检索该值。

如需检索 zone-infra-cidr，请运行以下命令：

kubectl --kubeconfig ROOT_ADMIN_KUBECONFIG get cidrclaim -n gpc-system zone-infra-cidr

以下是 YAML 输出示例：

apiVersion: system.private.gdc.goog/v1alpha1
kind: CIDRClaim
metadata:
  name: zone-infra-cidr
  namespace: gpc-system
spec:
  ipv4Spec:
    staticCidrBlocks:
    - 192.0.2.0/24
  ipv6Spec:
    staticCidrBlocks:
    - 2001:db8::/32
status:
  ipv4AllocationStatus:
    cidrBlocks:
    - 192.0.2.0/24
  ipv6AllocationStatus:
    cidrBlocks:
    - 2001:db8::/32

在此示例中，zone-infra-cidr 为 192.0.2.0/24，因此 OIQ 中的任何字段都不得与 192.0.2.0/24 重叠。

下表显示了 OIQ 字段及其对应的默认最小值：

OIQ 字段 说明 最小尺寸要求 组织的每个可用区的最小大小 全局根子网名称 全局 API 服务器
infraVPCCIDR 系统工作负载，包括组织控制台、管理 API 和第一方服务。 \( 15 - \lceil \log_2(ZoneNumber) \rceil \) 16 infra-vpc-root-cidr 全局根
defaultVPCCIDR 默认 VPC 中的用户工作负载和端点（跨可用区）。 \( 16 - \lceil \log_2(ZoneNumber) \rceil \) 16 default-vpc-root-cidr 全球组织
orgAdminExternalCIDR 外围集群中处理外部网络与组织之间管理流量的工作负载和端点。 \( 22 - \lceil \log_2(ZoneNumber) \rceil \) 23 admin-external-root-cidr 全局根
orgDataExternalCIDR 可供用户从外部访问的工作负载和端点，例如外部负载平衡器和出站 NAT。 \( 22 - \lceil \log_2(ZoneNumber) \rceil \) 23 data-external-root-cidr 全局根

如果您的 IP 不足，无法达到建议的默认最小值，您必须按照手动拆分流程为每个可用区创建子网。

请注意 IPv4 子网范围的以下限制：

  • orgDataExternalCIDR、orgAdminExternalCIDR、infraVPCCIDR 和 defaultVPCCIDR 不得相互重叠，不得与组织内的其他已分配范围重叠，也不得与对等互连网络中的任何 IPv4 范围重叠。这些 CIDR 来自 RFC 1918 专用地址空间。

    对等互连的网络：可以是任何通过互联附件通告的具有外部网络的子网，也可以是与同一组织中的其他 VPC 对等互连的子网。

  • 如果组织共享相同的互连 AttachmentGroup 资源，则 orgDataExternalCIDR 和 orgAdminExternalCIDR 值必须是唯一的。否则，允许与其他组织重叠。

1.3.2. 在全局根管理员 API 服务器中创建全局子网

在创建组织之前，您必须在全局根管理员 API 服务器中创建以下子网：

  • infra-vpc-root-cidr
  • admin-external-root-cidr
  • data-external-root-cidr

这些子网是引导组织在每个可用区中的组织基础架构集群所必需的。

  1. 您必须拥有一个命名空间，其名称与您将分配给组织的组织名称一致。确认此命名空间存在：

    kubectl --kubeconfig GLOBAL_ROOT_ADMIN_KUBECONFIG get namespace

    如果此命名空间不存在，请创建它：

    kubectl --kubeconfig GLOBAL_ROOT_ADMIN_KUBECONFIG create namespace ORG_NAME

  2. 创建 infra-vpc-root-cidr 子网 YAML 文件，例如 ORG_NAME-infra-vpc-root-cidr.yaml：

    apiVersion: ipam.global.gdc.goog/v1
kind: Subnet
metadata:
  labels:
    ipam.gdc.goog/vpc: infra-vpc
    ipam.gdc.goog/usage: network-root-range
  annotations:
    ipam.gdc.goog/pivot-destination: global-org
  name: infra-vpc-root-cidr
  namespace: ORG_NAME
spec:
  ipv4Request:
    cidr: INFRA_VPC_CIDR
  type: Root

  3. 创建 admin-external-root-cidr 子网 YAML 文件，例如 ORG_NAME-admin-external-root-cidr.yaml：

    apiVersion: ipam.global.gdc.goog/v1
kind: Subnet
metadata:
  labels:
    ipam.gdc.goog/network-segment: admin
    ipam.gdc.goog/usage: network-root-range
  annotations:
    ipam.gdc.goog/pivot-destination: global-org
  name: admin-external-root-cidr
  namespace: ORG_NAME
spec:
  ipv4Request:
    cidr: ORG_ADMIN_EXTERNAL_CIDR
  type: Root

  4. 创建 data-external-root-cidr 子网 YAML 文件，例如 ORG_NAME-data-external-root-cidr.yaml：

    apiVersion: ipam.global.gdc.goog/v1
kind: Subnet
metadata:
  labels:
    ipam.gdc.goog/network-segment: data
    ipam.gdc.goog/usage: network-root-range
  annotations:
    ipam.gdc.goog/pivot-destination: global-org
  name: data-external-root-cidr
  namespace: ORG_NAME
spec:
  ipv4Request:
    cidr: ORG_DATA_EXTERNAL_CIDR
  type: Root

  5. 将 infra-vpc-root-cidr、admin-external-root-cidr 和 data-external-root-cidr 子网 YAML 文件复制到根组织的 IAC 代码库：

    cp YAML_FILE_PATH/ORG_NAME-infra-vpc-root-cidr.yaml \
    IAC_REPO_PATH/iac/infrastructure/global/orgs/root/
cp YAML_FILE_PATH/ORG_NAME-admin-external-root-cidr.yaml \
    IAC_REPO_PATH/iac/infrastructure/global/orgs/root/
cp YAML_FILE_PATH/ORG_NAME-data-external-root-cidr.yaml \
    IAC_REPO_PATH/iac/infrastructure/global/orgs/root/

  6. 确保组织根目录中的 kustomization.yaml 文件包含新添加的 Subnet 定义。检查 IAC_REPO_PATH/iac/infrastructure/global/orgs/root/kustomization.yaml：

    apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
metadata:
  name: global-root-kustomization
resources:
-   ... # existing resource items
- ORG_NAME-admin-external-root-cidr.yaml
- ORG_NAME-data-external-root-cidr.yaml
- ORG_NAME-infra-vpc-root-cidr.yaml

  7. 暂存并提交子网 YAML 文件：

    git add "IAC_REPO_PATH/iac/infrastructure"
git commit

  8. 创建合并请求：

    git checkout -b ${USERNAME1}-branch
git -c http.sslVerify=false push -o merge_request.create origin {USERNAME1}-branch

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

1.3.3. 拆分可用区的根子网

全局根子网托管所有可用区的根 IP 地址范围 (CIDR)。如需使用相应可用区中的 IP 地址范围，必须先将全局根子网拆分为更小的子网，供可用区使用。每个可用区都必须至少有一个根 IP 地址范围。

IPAM 具有一个全局控制器，可自动将全局根子网拆分为现有可用区中的较小子网。如果管理员不关心特定可用区使用的确切 CIDR 块，则可以委托 IPAM 控制器自动划分可用区的子网。控制器会监控全局根子网的创建，并为每个可用区创建一个具有固定默认前缀长度的子网。

地区根子网 默认固定前缀长度
defaultZoneInfraVPCSubnetSize 16
defaultZoneAdminVRFSubnetSize 23
defaultZoneDataVRFSubnetSize 23
defaultZoneDefaultVPCSubnetSize 16
defaultAnycastSubnetSize 26

如果您希望 IPAM 控制器自动划分可用区的子网，则全局根子网必须具有固定的名称：

  • infra-vpc-root-cidr
  • admin-external-root-cidr
  • data-external-root-cidr
  • default-vpc-root-cidr

如果您为 Subnet 资源设置了 ipam.gdc.goog/pause-auto-division: true 注解，则必须手动定义特定可用区使用的确切 CIDR 块。如果您创建的全局根子网具有不同的名称，则 ipam.gdc.goog/pause-auto-division 注解无效，并且全局子网不会自动划分。

1.3.3.1. 自动拆分地区的根子网

全局控制器会自动将全局根子网拆分为较小的子网，以供现有可用区使用。例如，请考虑以下工作流，了解控制器如何将全局根子网拆分为现有可用区的较小子网：

如果有两个地区分别名为 zone1 和 zone2，则 org-1 命名空间中来自 OIQ 的全局根子网 infra-vpc-root-cidr（使用 infraVPCCIDR，例如 10.0.0.0/16）的示例如下所示：

apiVersion: ipam.global.gdc.goog/v1
kind: Subnet
metadata:
  labels:
    ipam.gdc.goog/vpc: infra-vpc
    ipam.gdc.goog/usage: network-root-range
  annotations:
    ipam.gdc.goog/pivot-destination: global-org
  name: infra-vpc-root-cidr
  namespace: org-1
spec:
  ipv4Request:
    cidr: 10.0.0.0/14
  type: Root

部署到 GDC 平台时，控制器会自动创建两个名为 infra-vpc-zone1-root-cidr 和 infra-vpc-zone2-root-cidr 的子网，前缀长度为 /16：

apiVersion: ipam.global.gdc.goog/v1
kind: Subnet
metadata:
  labels:
    ipam.gdc.goog/vpc: infra-vpc
    ipam.gdc.goog/usage: zone-network-root-range
  annotations:
    ipam.gdc.goog/pivot-destination: global-org
  name: infra-vpc-zone1-root-cidr
  namespace: org-1
spec:
  ipv4Request:
    prefixLength: 16
  zone: zone1
  propagationStrategy: SingleZone
  type: Branch
  parentReference:
    name: infra-vpc-root-cidr
    namespace: org-1

apiVersion: ipam.global.gdc.goog/v1
kind: Subnet
metadata:
  labels:
    ipam.gdc.goog/vpc: infra-vpc
    ipam.gdc.goog/usage: zone-network-root-range
  annotations:
    ipam.gdc.goog/pivot-destination: global-org
  name: infra-vpc-zone2-root-cidr
  namespace: org-1
spec:
  ipv4Request:
    prefixLength: 16
  zone: zone2
  propagationStrategy: SingleZone
  type: Branch
  parentReference:
    name: infra-vpc-root-cidr
    namespace: org-1

1.3.3.2. 手动拆分可用区的根子网

本部分假设您在全局根管理员 API 服务器中创建全局根子网时设置了注解 ipam.gdc.goog/pause-auto-division: true。此注解会暂停控制器来协调这些全局根子网，从而让您手动创建区域的根子网和任播子网。

如需手动将全局根子网拆分为更小的子网以用于各个可用区，请完成以下操作：

  1. 列出您的影音平台中的地区：

    kubectl --kubeconfig GLOBAL_ROOT_ADMIN_KUBECONFIG get zone -A

  2. 确认您要应用于相应可用区的根子网中的专用 CIDR。针对您所在宇宙中的每个可用区执行此操作。

  3. 在 YAML 文件（例如 ORG_NAME-infra-vpc-zone1-root-cidr.yaml）中为可用区的子网分配专用 CIDR：

    apiVersion: ipam.global.gdc.goog/v1
kind: Subnet
metadata:
  labels:
    ipam.gdc.goog/vpc: infra-vpc
    ipam.gdc.goog/usage: zone-network-root-range
  annotations:
    ipam.gdc.goog/pivot-destination: global-org
  name: infra-vpc-zone1-root-cidr
  namespace: ORG_NAME
spec:
  ipv4Request:
    cidr: ZONAL_CIDR
  zone: ZONE_NAME
  propagationStrategy: SingleZone
  type: Branch
  parentReference:
    name: infra-vpc-root-cidr
    namespace: ORG_NAME

    针对 GDC 宇宙中的每个区域重复执行此步骤。

  4. 确认要应用于任播子网的根子网中的专用 CIDR。

  5. 在 YAML 文件（例如 ORG_NAME-infra-vpc-anycast-cidr.yaml）中将专用 CIDR 分配给任播子网：

    apiVersion: ipam.global.gdc.goog/v1
kind: Subnet
metadata:
  labels:
    ipam.gdc.goog/vpc: infra-vpc
  annotations:
    ipam.gdc.goog/pivot-destination: global-org
  name: infra-vpc-anycast-cidr
  namespace: ORG_NAME
spec:
  ipv4Request:
    cidr: ANYCAST_CIDR
  propagationStrategy: None
  type: Branch
  parentReference:
    name: infra-vpc-root-cidr
    namespace: ORG_NAME

  6. 将可用区子网 YAML 文件复制到根组织的 IAC 代码库。例如，如果您有两个区域子网 YAML 文件：

    cp YAML_FILE_PATH/ORG_NAME-infra-vpc-zone1-root-cidr.yaml \
    IAC_REPO_PATH/iac/infrastructure/global/orgs/root/
cp YAML_FILE_PATH/ORG_NAME-infra-vpc-zone2-root-cidr.yaml \
    IAC_REPO_PATH/iac/infrastructure/global/orgs/root/
cp YAML_FILE_PATH/ORG_NAME-infra-vpc-anycast-cidr.yaml \
    IAC_REPO_PATH/iac/infrastructure/global/orgs/root/

  7. 确保组织根目录中的 kustomization.yaml 文件包含新添加的 Subnet 定义。检查 IAC_REPO_PATH/iac/infrastructure/global/orgs/root/kustomization.yaml：

    apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
metadata:
  name: global-root-kustomization
resources:
-   ... # existing resource items
- ORG_NAME-infra-vpc-zone1-root-cidr.yaml
- ORG_NAME-infra-vpc-zone2-root-cidr.yaml
- ORG_NAME-infra-vpc-anycast-cidr.yaml

  8. 暂存并提交子网 YAML 文件：

    git add "IAC_REPO_PATH/iac/infrastructure"
git commit

  9. 创建合并请求：

    git checkout -b ${USERNAME1}-branch
git -c http.sslVerify=false push -o merge_request.create origin {USERNAME1}-branch

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

1.3.3.2.1. 手动拆分地区根子网的示例（适用于 infra-vpc）

如果有两个地区，分别名为 zone1 和 zone2，则 org-1 命名空间中来自 OIQ 的使用 infraVPCCIDR（例如 192.0.2.0/24）的全局根子网 infra-vpc-root-cidr 如下所示：

apiVersion: ipam.global.gdc.goog/v1
kind: Subnet
metadata:
  labels:
    ipam.gdc.goog/vpc: infra-vpc
    ipam.gdc.goog/usage: network-root-range
  annotations:
    ipam.gdc.goog/pivot-destination: global-org
    ipam.gdc.goog/pause-auto-division: "true"
  name: infra-vpc-root-cidr
  namespace: org-1
spec:
  ipv4Request:
    cidr: 192.0.2.0/24
  type: Root

手动创建每个可用区的子网（分别命名为 infra-vpc-zone1-root-cidr 和 infra-vpc-zone2-root-cidr）以及任意广播子网 infra-vpc-anycast-cidr，并使用您决定的专用 CIDR：

apiVersion: ipam.global.gdc.goog/v1
kind: Subnet
metadata:
  labels:
    ipam.gdc.goog/vpc: infra-vpc
    ipam.gdc.goog/usage: zone-network-root-range
  annotations:
    ipam.gdc.goog/pivot-destination: global-org
  name: infra-vpc-zone1-root-cidr
  namespace: org-1
spec:
  ipv4Request:
    cidr: 192.0.2.0/26
  zone: zone1
  propagationStrategy: SingleZone
  type: Branch
  parentReference:
    name: infra-vpc-root-cidr
    namespace: org-1

apiVersion: ipam.global.gdc.goog/v1
kind: Subnet
metadata:
  labels:
    ipam.gdc.goog/vpc: infra-vpc
    ipam.gdc.goog/usage: zone-network-root-range
  annotations:
    ipam.gdc.goog/pivot-destination: global-org
  name: infra-vpc-zone2-root-cidr
  namespace: org-1
spec:
  ipv4Request:
    cidr: 192.0.2.64/26
  zone: zone2
  propagationStrategy: SingleZone
  type: Branch
  parentReference:
    name: infra-vpc-root-cidr
    namespace: org-1

apiVersion: ipam.global.gdc.goog/v1
kind: Subnet
metadata:
  labels:
    ipam.gdc.goog/vpc: infra-vpc
  annotations:
    ipam.gdc.goog/pivot-destination: global-org
  name: infra-vpc-anycast-cidr
  namespace: org-1
spec:
  ipv4Request:
    cidr: 192.0.2.128/26
  propagationStrategy: None
  type: Branch
  parentReference:
    name: infra-vpc-root-cidr
    namespace: org-1

请务必将所有子网 YAML 文件添加到 IAC 代码库。

1.3.3.2.2. 手动拆分数据网段的区域根子网示例

如果有两个地区，分别名为 zone1 和 zone2，则使用 orgDataExternalCIDR（例如 10.0.0.0/24）的全局根子网 data-external-root-cidr（来自 org-1 命名空间中的 OIQ）如下所示：

apiVersion: ipam.global.gdc.goog/v1
kind: Subnet
metadata:
  labels:
    ipam.gdc.goog/network-segment: data
    ipam.gdc.goog/usage: network-root-range
  annotations:
    ipam.gdc.goog/pivot-destination: global-org
    ipam.gdc.goog/pause-auto-division: "true"
  name: data-external-root-cidr
  namespace: org-1
spec:
  ipv4Request:
    cidr: 10.0.0.0/24
  type: Root

手动创建每个可用区的子网（分别命名为 data-external-zone1-root-cidr 和 data-external-zone2-root-cidr）以及任意广播子网 data-global-anycast-cidr，并使用您决定的专用 CIDR：

apiVersion: ipam.global.gdc.goog/v1
kind: Subnet
metadata:
  labels:
    ipam.gdc.goog/network-segment: data
    ipam.gdc.goog/usage: zone-network-root-range
  annotations:
    ipam.gdc.goog/pivot-destination: global-org
  name: data-external-zone1-root-cidr
  namespace: org-1
spec:
  ipv4Request:
    cidr: 10.0.0.0/26
  zone: zone1
  propagationStrategy: SingleZone
  type: Branch
  parentReference:
    name: data-external-root-cidr
    namespace: org-1

apiVersion: ipam.global.gdc.goog/v1
kind: Subnet
metadata:
  labels:
    ipam.gdc.goog/network-segment: data
    ipam.gdc.goog/usage: zone-network-root-range
  annotations:
    ipam.gdc.goog/pivot-destination: global-org
  name: data-external-zone2-root-cidr
  namespace: org-1
spec:
  ipv4Request:
    cidr: 10.0.0.64/26
  zone: zone2
  propagationStrategy: SingleZone
  type: Branch
  parentReference:
    name: data-external-root-cidr
    namespace: org-1

apiVersion: ipam.global.gdc.goog/v1
kind: Subnet
metadata:
  labels:
    ipam.gdc.goog/network-segment: data
  annotations:
    ipam.gdc.goog/pivot-destination: global-org
  name: data-global-anycast-cidr
  namespace: org-1
spec:
  ipv4Request:
    cidr: 10.0.0.128/26
  propagationStrategy: None
  type: Branch
  parentReference:
    name: data-external-root-cidr
    namespace: org-1

请务必将所有子网 YAML 文件添加到 IAC 代码库。

1.3.3.2.3. 手动拆分区域的根子网（管理员网络段示例）

如果有两个可用区分别命名为 zone1 和 zone2，则使用 orgAdminExternalCIDR 的全局根子网 admin-external-root-cidr 示例（例如 org-1 命名空间中 OIQ 的 192.168.1.0/24）如下所示：

apiVersion: ipam.global.gdc.goog/v1
kind: Subnet
metadata:
  labels:
    ipam.gdc.goog/network-segment: admin
    ipam.gdc.goog/usage: network-root-range
  annotations:
    ipam.gdc.goog/pivot-destination: global-org
    ipam.gdc.goog/pause-auto-division: "true"
  name: admin-external-root-cidr
  namespace: org-1
spec:
  ipv4Request:
    cidr: 192.168.1.0/24
  type: Root

手动创建每个可用区的子网（分别命名为 admin-external-zone1-root-cidr 和 admin-external-zone2-root-cidr）以及任意广播子网 admin-global-anycast-cidr，并使用您决定的专用 CIDR：

apiVersion: ipam.global.gdc.goog/v1
kind: Subnet
metadata:
  labels:
    ipam.gdc.goog/network-segment: admin
    ipam.gdc.goog/usage: zone-network-root-range
  annotations:
    ipam.gdc.goog/pivot-destination: global-org
  name: admin-external-zone1-root-cidr
  namespace: org-1
spec:
  ipv4Request:
    cidr: 192.168.1.0/26
  zone: zone1
  propagationStrategy: SingleZone
  type: Branch
  parentReference:
    name: admin-external-root-cidr
    namespace: org-1

apiVersion: ipam.global.gdc.goog/v1
kind: Subnet
metadata:
  labels:
    ipam.gdc.goog/network-segment: admin
    ipam.gdc.goog/usage: zone-network-root-range
  annotations:
    ipam.gdc.goog/pivot-destination: global-org
  name: admin-external-zone2-root-cidr
  namespace: org-1
spec:
  ipv4Request:
    cidr: 192.168.1.64/26
  zone: zone2
  propagationStrategy: SingleZone
  type: Branch
  parentReference:
    name: admin-external-root-cidr
    namespace: org-1

apiVersion: ipam.global.gdc.goog/v1
kind: Subnet
metadata:
  labels:
    ipam.gdc.goog/network-segment: data
  annotations:
    ipam.gdc.goog/pivot-destination: global-org
  name: admin-global-anycast-cidr
  namespace: org-1
spec:
  ipv4Request:
    cidr: 192.168.1.128/26
  propagationStrategy: None
  type: Branch
  parentReference:
    name: admin-external-root-cidr
    namespace: org-1

请务必将所有子网 YAML 文件添加到 IAC 代码库。

1.4. 使用 IAC 创建组织

使用 IAC 创建组织：

  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

    稍后指定 --server-quota 和 --admin-server 时，请确保您有足够的 available 服务器来满足请求。

  2. 前往 iac 代码库，然后为新组织添加目录结构：

    mkdir -p infrastructure/global/orgs/root/ORG_NAME/

  3. 创建 Organization 自定义资源：

    gdcloud organizations config create --name ORG_NAME \
    --log-retention-policy LOG_RETENTION_POLICY \
    --kms-root-key-type KMS_ROOT_KEY_TYPE

    例如：

    gdcloud organizations config create --name org-1 \
    --log-retention-policy paAuditLogsRetentionTime=400,ioAuditLogsRetentionTime=2000,operationalLogsRetentionTime=90,metricsRetentionTime=90 \
    --kms-root-key-type ctm-root

    执行以下变量替换操作：

    变量定义
    ORG_NAME 组织的名称。组织的名称必须符合以下条件：
    • 包含 3 到 19 个小写 ASCII 字母、数字或连字符。
    • 以字母开头。
    • 不得以连字符结尾。
    • 不得以字符串 -system 结尾。
    LOG_RETENTION_POLICY 审核日志、操作日志和指标的保留时间配置（以天为单位）。
    KMS_ROOT_KEY_TYPE 此配置用于保存为组织的 KMS 选择的根密钥类型。 每个 KMS 服务都有一个根密钥，用于加密由 KMS 生成的密钥。默认情况下，KMS 会生成 CTM 根密钥，即存储在 Thales CipherTrust Manager 中并由物理 HSM 备份的根密钥。您还可以选择以 Kubernetes Secret 形式存储的软件根密钥。 为 kmsRootKeyType 传入 ctm-root 或 local-root。

    生成的 Organization 自定义资源 YAML 文件示例如下：

    apiVersion: resourcemanager.global.private.gdc.goog/v1alpha1
kind: Organization
metadata:
    namespace: gpc-system
    name: org-1
spec:
    type: Tenant
    logRetentionPolicy:
        paAuditLogsRetentionTime: 400
        ioAuditLogsRetentionTime: 2000
        operationalLogsRetentionTime: 90
        metricsRetentionTime: 90
    securityConfig:
      kmsRootKeyType: "ctm-root"

  4. 可选：在 1.14.2 及更高版本中，节点到节点 IPsec 加密默认处于停用状态。如果需要此 IPsec 加密，您可以修改 Organization 自定义资源 YAML 文件并添加注解，以启用节点到节点 IPsec 加密：

    metadata:
    annotations:
        n2n.security.private.gdc.goog/node-to-node-encryption-disabled: "false"

    此注解的值为 "false" 时，表示启用加密。

  5. 为部署中的每个可用区创建 OrganizationZonalConfig 自定义资源：

    gdcloud organizations zonal-configs create --name ORG_NAME \
    --zones=ZONES \
    --version GDC_VERSION \
    --server-quota SERVER_QUOTA \
    --storage-sku STORAGE_SIZE \
    --admin-server ADMIN_SERVER

    例如：

    gdcloud organizations zonal-configs create --name org-1 \
    --zones=us-central1-a,us-central1-b \
    --version 1.9.2-gdch.153 \
    --server-quota 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 \
    --storage-sku block-standard=100Ti,file-standard=100Ti,object-standard=100Ti \
    --admin-server o1-standard1-64-gdc-metal=3

    执行以下变量替换操作：

    变量定义
    ORG_NAME 组织的名称。组织的名称必须符合以下条件：
    • 包含 3 到 30 个小写 ASCII 字母、数字或连字符。
    • 以字母开头。
    • 不得以连字符结尾。
    • 不得以字符串 -system 结尾。
    ZONES 部署中的可用区名称。
    GDC_VERSION 要创建组织的 GDC 系统版本。
    SERVER_QUOTA 自动生成组织管理员集群和系统集群时要为其分配的服务器。如果您打算运行基于虚拟机的 GPU 资源工作负载（例如预训练的人工智能和机器学习 [AI/ML] API），则必须在创建组织时预配 GPU 机器。如需了解详情，请参阅为系统集群启用 GPU 支持部分。
    ADMIN_SERVER 一个键值对，包含服务器类型和要为该服务器类型分配的组织管理员服务器数量。服务器不支持混合类型。默认值为 o1-standard1-64-gdc-metal: 3。
    STORAGE_SIZE 要为组织分配的不同存储类型的大小。 组织的最小块存储空间大小为 250Gi，可通过 BlockStandard 标志进行设置。

    生成的 OrganizationZonalConfig 自定义资源 YAML 文件示例如下：

    apiVersion: resourcemanager.global.private.gdc.goog/v1alpha1
kind: OrganizationZonalConfig
metadata:
  namespace: gpc-system
  name: org-1-zone1-config
spec:
  organizationRef:
    name: org-1
  zone: zone1
  version: 1.5.0-gdch.11
  capacities:
    storage:
      block-standard: 10Ti
      file-standard: 10Ti
      object-nearline: 10Ti
      object-standard: 10Ti
    workloadServers:
      o1-highmem1-40-gdc-metal: 1

  6. 查看生成的 YAML 文件。这些文件位于 HOME 目录中。

    1. 确认组织类型。您可以预配两种类型的组织：

      • 组织 v1 架构（v1 组织）
      • 组织 v2 架构（v2 版组织）

      默认情况下，系统会根据您的部署类型（由功能门设置决定）预配新组织：

      • PRODUCTION 部署默认生成 v2 组织。
      • ACCREDITED 部署默认生成 v1 组织。

      在极少数情况下，您必须替换部署类型的默认组织类型，请将生成的 Organization 自定义资源中的 spec.compatibilityOptions.architectureOverridePolicy 字段更新为 ForceV1 或 ForceV2，具体取决于您要使用的组织类型。例如，以下代码段强制在 ACCREDITED 部署中创建 v2 版组织：

      ...

spec:
...
  compatibilityOptions:
    architectureOverridePolicy: ForceV2

...

    2. 确认其余设置，确保存储空间和计算能力等组件足以满足贵公司的需求。

  7. 将 Organization 和 OrganizationZonalConfig 自定义资源复制到新组织的目录中的代码库：

    cp YAML_FILE_PATH/ORG_NAME.yaml IAC_REPO_PATH/iac/infrastructure/global/orgs/root/ORG_NAME/

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

    替换以下内容：

    • ORG_NAME：您在 gdcloud organizations config create 命令中使用 --name 参数定义的组织名称。
    • ZONE：部署中每个可用区的名称。地区名称采用以下格式：{generalRegion}-{regionQualifier}{regionCounter}-{zoneLetter}。 例如 us-central1-b。如需了解区域属性值的说明，请参阅客户意见征集问卷中的“区域”部分。

  8. 为新组织添加 kustomization.yaml 文件：

    cat > IAC_REPO_PATH/iac/infrastructure/global/orgs/root/ORG_NAME/kustomization.yaml << EOF
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
metadata:
  name: ORG_NAME-kustomization
resources:
-   ORG_NAME.yaml
-   ORG_NAME-ZONE.yaml
EOF

  9. 将新组织添加为根组织的资源：

    1. 打开全局根 kustomization.yaml 文件：

      vim /iac/infrastructure/global/orgs/root/kustomization.yaml

    2. 将新的 Organization 作为资源添加到现有资源列表的末尾：

      apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
metadata:
  name: global-root-kustomization
resources:
-   ... # existing resource items
-   ORG_NAME

  10. 暂存并提交组织 YAML 文件和 kustomize 文件：

    git add "IAC_REPO_PATH/iac/infrastructure"
git commit

  11. 创建合并请求：

    git checkout -b ${USERNAME1}-branch
git -c http.sslVerify=false push -o merge_request.create origin {USERNAME1}-branch

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

  13. 验证全局组织和可用区配置是否可用：

    1. 验证全局组织是否在您的 GDC 宇宙中可用：

      kubectl get organization -A

      输出类似于以下内容：

      NAMESPACE    NAME    AGE
gpc-system   org     34s
gpc-system   root    14h

    2. 检查全局组织状态：

      kubectl --kubeconfig GLOBAL_ROOT_ADMIN_KUBECONFIG \
    get organization/ORG_NAME -n gpc-system -o yaml

      确保 YAML 输出中的 status 条件为 True。

    3. 检查每个区域中的组织配置状态：

      kubeconfig --kubeconfig ROOT_ADMIN_KUBECONFIG \
    get organization/ORG_NAME -n gpc-system -o yaml

      如需切换可用区上下文，请先使用 gdcloud CLI 登录每个可用区，然后再检查组织状态。确保每个可用区在 YAML 输出中的 status 条件均为 True。

1.5. 在全局组织 API 服务器中创建全局子网

您必须在全局 API 服务器运行后，在组织的全局 API 服务器的 platform 命名空间内创建 default-vpc-root-cidr。此根子网会为租户组织内的集群（例如用户集群）分配 IP 地址，还会为虚拟机工作负载分配 IP 地址。

  1. 创建 default-vpc-root-cidr 子网 YAML 文件，例如 default-vpc-root-cidr.yaml：

    apiVersion: ipam.global.gdc.goog/v1
kind: Subnet
metadata:
  labels:
    ipam.gdc.goog/allocation-preference: default
    ipam.gdc.goog/vpc: default-vpc
    ipam.gdc.goog/usage: network-root-range
  name: default-vpc-root-cidr # don't change the name if you want IPAM controller to automatically divide the zone's subnet.
  namespace: platform
spec:
  type: Root
  ipv4Request:
    cidr: DEFAULT_VPC_CIDR

  2. 前往 iac 代码库，然后添加全局组织的目录结构：

    cd iac; mkdir -p infrastructure/global/orgs/ORG_NAME/

  3. 将 default-vpc-root-cidr 子网 YAML 文件复制到新组织的目录中的 IAC 代码库：

    cp YAML_FILE_PATH/default-vpc-root-cidr.yaml \
    IAC_REPO_PATH/iac/infrastructure/global/orgs/ORG_NAME/

  4. 在组织文件夹中创建 kustomization.yaml 文件，其中包含新添加的 Subnet 定义。检查 IAC_REPO_PATH /iac/infrastructure/global/orgs/ORG_NAME/kustomization.yaml：

    cat > infrastructure/global/orgs/ORG_NAME/kustomization.yaml << EOF
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
metadata:
  name: ORG_NAME-kustomization
resources:
- default-vpc-root-cidr.yaml
EOF

  5. 暂存并提交组织 YAML 文件和 kustomize 文件：

    git add "IAC_REPO_PATH/iac/infrastructure"
git commit

  6. 创建合并请求：

    git checkout -b ${USERNAME1}-branch
git -c http.sslVerify=false push -o merge_request.create origin {USERNAME1}-branch

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

与全局根管理员集群中的全局子网的拆分方式类似，default-vpc-root-cidr 也会拆分并传播到每个可用区，以供可用区级组织使用 IP 地址。

1.7. 配置组织管理员 NTPRelay

您必须手动配置根管理员和组织管理员 NTPRelay 之间的身份验证。

按照 NTP-P0001.3（根管理员 -> 组织管理员 NTPRelay 加密）为相应组织配置加密。

1.8. 使用 IAC 将 IO 身份提供方连接到组织

  1. 请参阅 ADFS 指南，了解如何在 ADFS 中为新组织创建 OIDC 客户端，并记下 OIDC 客户端的客户端 ID 和客户端密钥。

  2. 将组织名称设置为环境变量：

    export ORG_NAME=ORG_NAME

    验证 ORG_NAME 是否与组织的准确名称一致。

  3. 导出根管理员集群 kubeconfig 文件，然后运行以下 kubectl 命令以获取集群和可用区名称：

    export KUBECONFIG=ROOT_ADMIN_KUBECONFIG
kubectl get clusters -A
kubectl get zones -n mz-system

  4. 为组织添加 ioauthmethod.yaml 文件：

    cat > infrastructure/global/orgs/${ORG_NAME}/ioauthmethod.yaml << EOF
apiVersion: iam.global.private.gdc.goog/v1alpha1
kind: IOAuthMethod
metadata:
  name: io-idp-authmethod
  namespace: gpc-system
oidc:
  certificateAuthorityData: ADFS_CERT_BASE64
  clientID: ADFS_ORG_CLIENT_ID
  clientSecret: ADFS_ORG_CLIENT_SECRET
  groupPrefix: gdch-infra-operator-
  groupsClaim: groups
  issuerURI: ADFS_ISSUER_URI
  scopes: openid email offline_access
  userClaim: email
  userPrefix: gdch-infra-operator-
  cloudConsoleRedirectURI: http://cloud.console.not.enabled
  kubectlRedirectURI: http://localhost:9879/callback
EOF

    执行以下变量替换操作：

    变量定义
    ADFS_CERT_BASE64 ADFS 用于自签名的证书的 Base64 编码，GKE Identity Service 需要此编码才能与内部 ADFS 实例建立安全连接。
    ADFS_ORG_CLIENT_ID 组织在 ADFS 中的客户端的 OpenID Connect ID。
    ADFS_ORG_CLIENT_SECRET 在 ADFS 中注册的组织客户端的 OpenID Connect 密钥。
    ADFS_ISSUER_URI 有效的提供方 URI，GKE Identity Service 需要此 URI 才能允许将重定向登录请求发送到 ADFS。

  5. 为组织添加 initial-admin.yaml 文件：

    cat > infrastructure/global/orgs/${ORG_NAME}/initial-admin.yaml << EOF
apiVersion: iam.private.gdc.goog/v1alpha1
kind: ExpirationClusterRoleBinding
metadata:
  name: iac-binding-USER-org-iam-admin
spec:
  expirationTimestamp: EXPIRATION
  roleRef:
    apiGroup: rbac.authorization.k8s.io
    kind: ClusterRole
    name: organization-iam-admin
  subjects:
    - apiGroup: rbac.authorization.k8s.io
      kind: User
      name: gdch-infra-operator-USER@opscenter.local
EOF

    执行以下变量替换操作：

    变量定义
    USER 带有 IO 前缀的用户名，用于最初登录集群。请务必将前缀附加到用户名。
    EXPIRATION 系统撤消访问权限的时间戳（采用 RFC 3339 格式）。例如，"2020-11-14T00:20:12+00:00"。

  6. 将新创建的文件附加到 IAC_REPO_PATH /iac/infrastructure/global/orgs/ORG_NAME/kustomization.yaml 中的 kustomization.yaml 文件：

    apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
metadata:
  name: ORG_NAME-kustomization
resources:
-   ... # existing resource items
- ioauthmethod.yaml
- initial-admin.yaml

  7. 暂存并提交组织 YAML 文件和 kustomize 文件：

    git add "infrastructure/global"
git add "infrastructure/zonal"
git commit

  8. 将更新推送到 GitLab：

    git -c http.sslVerify=false push

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

  10. 如需确认该 Operator 是否可以访问组织，请登录到生成的组织，然后运行以下命令来验证组织的 ClientConfig 中是否存在身份提供方 (IdP)：

    1. 根据组织架构设置管理员集群 kubeconfig 文件：

      • 对于 v1 组织，请运行：

        export KUBECONFIG=ORG_ADMIN_CLUSTER_KUBECONFIG

        将 ORG_ADMIN_CLUSTER_KUBECONFIG 替换为组织管理员集群 kubeconfig 的路径，例如 /tmp/${ORG}-admin-kubeconfig。

      • 对于 v2 组织，请运行：

        export KUBECONFIG=ORG_INFRA_CLUSTER_KUBECONFIG

        将 ORG_INFRA_CLUSTER_KUBECONFIG 替换为组织基础架构集群 kubeconfig 的路径，例如 /tmp/${ORG}-infra-kubeconfig。

    2. 验证组织 ClientConfig 中是否存在 IdP：

      kubectl get ClientConfig default -n kube-public -o yaml

  11. 对于版本 1.14.3，您必须手动应用 global-zone-viewer 角色，以允许所有经过身份验证的用户使用 gdcloud CLI 查看宇宙中的可用区。应用角色和角色绑定资源：

    kubectl --kubeconfig ORG_GLOBAL_API_SERVER_KUBECONFIG apply -f - <<EOF
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: global-zone-viewer
  namespace: mz-system
rules:
- apiGroups:
  - location.mz.global.private.gdc.goog
  resources:
  - zones
  verbs:
  - get
  - list
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: global-zone-viewer-binding
  namespace: mz-system
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: global-zone-viewer
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: Group
  name: system:authenticated
EOF

    将 ORG_GLOBAL_API_SERVER_KUBECONFIG 替换为组织的全局 API 服务器的 kubeconfig 文件。如需了解详情，请参阅手动生成 kubeconfig 文件。

1.9. 将客户身份提供方与组织相关联

如需将客户身份提供方 (IdP) 连接到组织，并使用客户身份提供方登录组织，请完成以下步骤：

  1. 使用组织创建期间设置的初始 IO 管理员账号从 CLI 登录，该账号会自动绑定到组织管理员集群中的 org-iam-admin。

  2. 请客户将以下全局 AIS 回调网址添加到客户为要创建的组织创建的 OIDC 或 SAML 客户端中的许可名单：

    https://ais-core.ORG_NAME.GDC_URL/finish-login

    例如，如果 GDC 的根网址为 .google.gdch.test，组织的名称为 operations，则全局 AIS 回调网址为 https://ais-core.operations.google.gdch.test/finish-login。

    如果您使用的是 SAML 客户端，还必须将以下全局 AIS SAML 回调网址添加到许可名单：

    https://ais-core.ORG_NAME.GDC_URL/saml-callback

  3. 请客户将以下 AIS 回调网址添加到客户为每个区域创建的 OIDC 或 SAML 客户端中的许可名单。例如，对于三可用区宇宙，可用区级 AIS 回调网址类似于以下网址：

    https://ais-core.ORG_NAME.ZONE_1.GDC_URL/finish-login

https://ais-core.ORG_NAME.ZONE_2.GDC_URL/finish-login

https://ais-core.ORG_NAME.ZONE_3.GDC_URL/finish-login

    如果 GDC 的根网址为 .google.gdch.test，时区名称为 zone-1，组织名称为 operations，则 AIS 回调网址为 https://ais-core.operations.zone-1.google.gdch.test/finish-login。

    如果您使用的是 SAML 客户端，还必须将以下 AIS SAML 回调网址添加到每个区域的许可名单中：

    https://ais-core.ORG_NAME.ZONE_1.GDC_URL/saml-callback

https://ais-core.ORG_NAME.ZONE_2.GDC_URL/saml-callback

https://ais-core.ORG_NAME.ZONE_3.GDC_URL/saml-callback

  4. 根据组织架构设置管理员集群 kubeconfig 文件。如果您已设置 kubeconfig 变量，请跳过此步骤。

    • 对于 v1 组织，请运行：

        export KUBECONFIG=ORG_ADMIN_CLUSTER_KUBECONFIG

      将 ORG_ADMIN_CLUSTER_KUBECONFIG 替换为组织管理员集群 kubeconfig 的路径，例如 /tmp/${ORG}-admin-kubeconfig。

    • 对于 v2 组织，请运行：

        export KUBECONFIG=MANAGEMENT_API_SERVER_KUBECONFIG

      将 MANAGEMENT_API_SERVER_KUBECONFIG 替换为管理 API 服务器 kubeconfig 的路径，例如 /tmp/${ORG}-management-kubeconfig。

  5. 根据新组织的客户请求工单，确定 IdP 使用的是 OIDC 还是 SAML。请按照与给定 IdP 类型对应的指南操作：

使用 OIDC 进行设置

  1. 创建一个 identity-provider-config.yaml 文件，然后参考 PA 的账号 IdP 的组织创建工单来填充该文件：

    cat << EOF > identity-provider-config.yaml
apiVersion: iam.global.gdc.goog/v1
kind: IdentityProviderConfig
metadata:
  name: pa-idp-oidc
  namespace: platform
spec:
  oidc:
    certificateAuthorityData: "PA_IDP_BASE64_ENCODED_CERTIFICATE"
    clientID: PA_IDP_CLIENT_ID
    clientSecret: PA_IDP_CLIENT_SECRET
    groupPrefix: PA_IDP_GROUP_CLAIM
    groupsClaim: PA_IDP_PREFIX
    issuerURI: PA_IDP_ISSUER_URI
    scopes: openid email profile
    userClaim: PA_IDP_USER_CLAIM
    userPrefix: PA_IDP_PREFIX
EOF

  2. 以下是各个字段的详细说明：

    属性 属性类型 说明
    certificateAuthorityData 必填 OIDC 提供方的标准 base64 编码的 PEM 格式证书授权机构证书。
    clientID 必填 向 OpenID 提供方发出身份验证请求的客户端应用的 ID。
    clientSecret 必填 OIDC 客户端应用和 OIDC 提供方之间的共享密钥。
    extraParams 可选 以英文逗号分隔的键值对列表，将采用查询编码并随身份验证端点请求发送。
    groupPrefix 可选 要附加到群组声明的前缀，以防止与现有群组冲突，通常在配置多个身份提供方时使用。
    所有群组名称之前都必须包含群组前缀。例如，如果您的身份提供商将 myprefix- 作为群组前缀，并将群组命名为 groupA，那么在添加政策或绑定时，您必须绑定 myprefix-groupA。组名称在 groupsClaim 字段中设置。
    groupsClaim 可选 包含用户群组信息的 OIDC ID 令牌中的声明名称。此名称必须与 OIDC 提供商中包含群组成员资格信息的声明的名称相同。
    issuerURI 必填 用于向您的 OIDC 提供方发送授权请求的网址。 此 URI 必须指向 .well-known/openid-configuration 内的级别。
    scopes 可选 以英文逗号分隔的标识符列表，用于指定除了 openid 范围之外请求哪些访问权限。
    userClaim 必填 OIDC ID 令牌中包含用户名的声明的名称。 例如，如果用户声明为 email，则由 OIDC 令牌中的用户字段进行识别。
    如果 ID 令牌缺少此项，则身份验证将失败。
    userPrefix 可选 要附加到用户声明的前缀，以防止与现有用户名冲突，通常在配置多个身份提供方时使用。
    例如，如果用户声明为 email，且用户前缀为 prefix-，则用户会被标识为 prefix-sally@example.com。用户是 sally@example.com，并且前缀 prefix- 用作用户前缀来区分不同的身份提供商。
    建议您在前缀的末尾插入一个分隔符，如本表中之前所述的设置 groupPrefix。

  3. 可选：如果您的身份提供方使用自定义属性，请先在 IdP 中配置这些属性。然后，在 identity-provider-config.yaml 文件的 oidc 部分中添加相应的键值对，以添加有关用户或群组的其他声明，例如其部门或生日。将更改应用于身份提供方配置后，GKE Identity Service 会识别自定义属性。以下是自定义属性的示例：

      "attributeMapping": {
  "attribute.birthday": "assertion.birthday",
  "attribute.department": "assertion.department"
  }

  4. 配置身份提供方配置：

    kubectl apply -f identity-provider-config.yaml

  5. 等待各种系统组件重新配置。

  6. 在 Web 浏览器中打开平台管理界面控制台，验证配置。在重定向页面中选择 Log in with pa-idp-oidc。如果您被重定向到 PA 账号 IdP 实例，并且在使用 PA 账号 IdP 实例登录后被重定向回 Platform Admin 界面控制台页面，则表示配置成功。否则，请检查 identity-provider-config.yaml 中的值，然后重新应用上一步。

使用 SAML 进行设置

  1. 创建一个 identity-provider-config.yaml 文件，然后参考 PA 的账号 IdP 的组织创建工单中的值来填充该文件：

    cat << EOF > identity-provider-config.yaml
apiVersion: iam.global.gdc.goog/v1
kind: IdentityProviderConfig
metadata:
  name: pa-idp-saml
  namespace: platform
spec:
  saml:
    idpEntityID: PA_IDP_ISSUER_URI
    idpSingleSignOnURI: PA_IDP_SSO_URI
    groupPrefix: PA_IDP_PREFIX
    groupsAttribute: PA_IDP_GROUPS_ATTRIBUTE
    idpCertificateDataList: [PA_IDP_SAML_CERT]
    userAttribute: PA_IDP_USER_ATTRIBUTE
    userPrefix: PA_IDP_PREFIX
EOF

  2. 以下是各个字段的详细说明：

    .
    属性 属性类型 说明
    idpCertificateDataList 必填 用于验证 SAML 响应的 IDP 证书。 这些证书应采用标准的 base64 编码和 PEM 格式。最多支持两个证书，以便于 IdP 证书轮替。
    idpEntityID 必填 SAML 提供方的 SAML 实体 ID，以 URI 格式指定。例如，https://www.idp.com/saml。
    idpSingleSignOnURI 必填 SAML 提供方的 SSO 端点的 URI。例如，`https://www.idp.com/saml/sso`。
    groupPrefix 可选 要附加到每个组名称的可选前缀。
    userPrefix 可选 要附加到用户名的可选前缀。
    userAttribute 可选 SAML 响应中包含用户名的属性的名称。如果 SAML 响应中缺少此属性，身份验证会失败。
    groupsAttribute 可选 SAML 响应中包含用户群组的属性的名称。

  3. 可选：如果您的身份提供方使用自定义属性，请先在 IdP 中配置这些属性。然后，在 identity-provider-config.yaml 文件的 saml 部分中添加相应的键值对，以添加有关用户或群组的其他声明，例如其部门或生日。将更改应用于身份提供方配置后，GKE Identity Service 会识别自定义属性。以下是自定义属性的示例：

      "attributeMapping": {
  "attribute.birthday": "assertion.birthday",
  "attribute.department": "assertion.department"
  }

  4. 配置身份提供方配置补丁：

    kubectl apply -f identity-provider-config.yaml

  5. 等待各种系统组件重新配置。

  6. 在 Web 浏览器中打开平台管理界面控制台，验证配置。在重定向页面中选择 Log in with pa-idp-oidc。如果您被重定向到 PA 账号 IdP 实例，并且在使用 PA 账号 IdP 实例登录后被重定向回 Platform Admin 界面控制台页面，则表示配置成功。否则，请检查 identity-provider-config.yaml 中的值，然后重新应用上一步。

用户和群组前缀

必须为分布式云中的每个 IdP 设置用户和群组前缀，以避免不同 IdP 的账号之间出现命名冲突。前缀与用户和群组名称一起使用，以连接集群中角色绑定的正文名称。例如，如果用户的名称为 jack@example.com，且 IdP 的用户前缀为 example-org-idp-，则该用户在集群中的正文名称为 example-org-idp-jack@example.com。

确定前缀的值：

  • 包括层次结构级别（根、组织、项目）。
  • 包含 IdP 的名称（adfs、keycloak）。
  • 建议添加一个分隔符（例如 -）作为后缀，因为前缀和用户名之间未添加分隔符。

分配初始管理员

如需授予 PA 对组织的初始访问权限，必须将其分配为组织的管理员。如需将 PA 分配为初始管理员，请在全局 API 服务器中创建 IAMRoleBinding：

kubectl apply -f --kubeconfig=GLOBAL_API_SERVER_KUBECONFIG - <<EOF
apiVersion: iam.global.gdc.goog/v1
kind: IAMRoleBinding
metadata:
  name: PA_INITIAL_ADMIN_EMAIL-binding
  namespace: platform
spec:
  roleRef:
    apiGroup: iam.global.gdc.goog
    kind: IAMRole
    name: organization-iam-admin
  subjects:
  - apiGroup: rbac.authorization.k8s.io
    kind: User
    name: PA_IDP_PREFIXPA_INITIAL_ADMIN_EMAIL
EOF

1.10 为组织建立网络连接

新创建的组织是隔离的，无法从任何外部网络访问。为了使组织正常运行，您必须使用 Interconnect 服务将其连接到一个或多个外部网络。

此过程涉及配置一组用于定义逻辑连接的自定义资源。以下是为新组织提供连接的两种常见方案。

场景 1：将组织附加到现有共享互连

如果您已为共享网络创建互连，只需更新 AttachmentGroup 和 RoutePolicy 以纳入新组织。

  1. 更新 AttachmentGroup：AttachmentGroup 用于指定哪些组织可以使用一组 VLAN 连接。修改 AttachmentGroup YAML 文件，并将新组织添加到 spec.entities 列表中。对于 v2 组织，您必须指定要连接的网络 domainType（OrgAdmin、OrgData 或 OrgMixed）。

    示例 AttachmentGroup 更新：

    apiVersion: system.private.gdc.goog/v1alpha1
kind: AttachmentGroup
metadata:
  name: attachment-group-shared
  namespace: gpc-system
spec:
  identifier: shared-network
  entities:
  - orgName: existing-org-1 # Existing organization
    domainType: OrgMixed
  - orgName: new-customer-org # Add the new organization
    domainType: OrgMixed

  2. 更新 RoutePolicy：RoutePolicy 用于定义要通告的 IP 前缀。修改政策，并将新组织的外部 IP 子网添加到 spec.out.ipPrefixList 中。这样，入站流量就可以到达组织。

    示例 RoutePolicy 更新：

    apiVersion: system.private.gdc.goog/v1alpha1
kind: RoutePolicy
metadata:
  name: shared-routepolicy
  namespace: gpc-system
spec:
  # ... other fields ...
  out:
    asPathAccessList:
    - action: Permit
      asPathRegex: ".*"
    ipPrefixList:
    - action: Permit
      ipPrefix: EXTERNAL_SUBNET_OF_EXISTING_ORG_1
    - action: Permit
      ipPrefix: EXTERNAL_SUBNET_OF_NEW_CUSTOMER_ORG # Add new prefix
    # ... deny rules ...

  3. 使用 kubectl apply 通过基础设施即代码 (IaC) 流程应用更改。

方案 2：创建新的专用互连

对于专用连接，您必须创建一组新的互连资源。整个流程涉及按顺序创建五个自定义资源。

  1. 为每个新的物理连接创建 InterconnectLink。
  2. 创建 InterconnectGroup 以捆绑实体链接并允许新组织。
  3. 创建 AttachmentGroup，并在 entities 列表中指定新组织。
  4. 创建 RoutePolicy，以允许此专用连接的入站和出站 IP 前缀。
  5. 创建一个或多个 InterconnectAttachment 资源来定义 VLAN 和 BGP 会话。

如需查看每种资源的完整示例和详细步骤，请参阅配置互连文档。

1.11 设置 Alertmanager webhook 以连接到 ServiceNow

按照 MON-T0016 中的步骤将 Alertmanager Webhook 连接到 ServiceNow 以创建突发事件。

1.12 为组织配置结算价目表

组织的结算子组件要求待结算的产品或服务配置有自定义资源 SKUDescription。单个 SKUDescription 描述要结算的单个产品或服务及其价格。因此，SKUDescription 对象的集合可以视为组织的价目表。以下步骤将通过 IAC 为组织配置价目表。

1.12.1 获取价格表

如果您还没有组织的 SKUDescription 价目表资源，请与项目管理办公室 (PMO) 联系以获取价目表。价格表必须是一系列包含 SKUDescription 资源的 YAML 文件。

1.12.2 确定价目表是否已共享

价格表可以跨所有组织共享，也可以按组织进行配置。PMO 可以告知您价格表是否已共享。

1.12.2.1 共享价格表

如果价目表是共享的，请将价目表放在共享的 IAC 文件夹中。common-data

  1. 如果此组织不是创建的第一个组织，则价格表可能已存在于共享 common-data 文件夹中。如果价目表存在，请验证是否已遵循第 2-4 步，然后继续执行第 5 步。

  2. 为价目表创建共享文件夹。

    mkdir -p IAC_REPO_PATH/iac/infrastructure/common-data/bil/skudescriptions/

    将 IAC_REPO_PATH 替换为 IAC 代码库的路径。

  3. 将 SKUDescription 价目表 YAML 资源保存到此文件夹中。之后，skudescriptions 文件夹必须包含按区域分隔的 YAML 文件。配置文件夹结构和 YAML 文件，使其与您的结算使用情形相符：

    • 合作伙伴运营的结算：Google 向合作伙伴收取费用。将 SKUDescription 资源放置在 partner-billing-system 命名空间中。

    • 客户结算：合作伙伴向最终用户收费。将 SKUDescription 资源放置在 billing-system 命名空间中。

    以下示例展示了客户结算和合作伙伴运营的结算模式文件结构。对于每个模型，您会看到两项服务（计算和存储），每项服务都有两个 YAML 文件：

    客户结算：

    ├── customer
     ├── compute
     │   ├── compute-sku1.yaml
     │   └── compute-sku2.yaml
     └── storage
         ├── storage-sku1.yaml
         └── storage-sku2.yaml

    合作伙伴运营的结算：

    ├── partner
     ├── compute
     │   ├── partner-compute-sku1.yaml
     │   └── partner-compute-sku2.yaml
     └── storage
         ├── partner-storage-sku1.yaml
         └── partner-storage-sku2.yaml

  4. 验证目录中是否存在 kustomization.yaml 文件，该文件包含所有 SKUDescription 价目表 YAML 文件。

    touch IAC_REPO_PATH/iac/infrastructure/common-data/bil/skudescriptions/kustomization.yaml
cd IAC_REPO_PATH/iac/infrastructure/common-data/bil/skudescriptions/
kustomize edit add resource */*.yaml

  5. 导出 ORG_CLUSTER 环境变量：

    • 对于 v1 组织，请运行：

      export ORG_CLUSTER=ORG_ADMIN_CLUSTER_NAME

    • 对于 v2 组织，请运行：

      export ORG_CLUSTER=ORG_INFRA_CLUSTER_NAME

  6. 在组织中创建 skudescriptions 结算目录：

    • 对于 v1 组织：

      mkdir -p IAC_REPO_PATH/iac/infrastructure/zonal/zones/ZONE_NAME/ORG_CLUSTER_NAME/bil/skudescriptions

    • 对于 v2 组织：

      mkdir -p IAC_REPO_PATH/iac/infrastructure/zonal/zones/ZONE_NAME/ORG_CLUSTER_NAME-management/bil/skudescriptions

    将 ORG_CLUSTER_NAME 替换为组织的管理员集群的名称，具体取决于组织的版本类型。

  7. 在组织中包含通用价目表：

    • 对于 v1 组织：

      cat > IAC_REPO_PATH/iac/infrastructure/zonal/zones/ZONE_NAME/ORG_CLUSTER_NAME/bil/skudescriptions/kustomization.yaml << EOF
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
- ../../../../common-data/bil/skudescriptions
EOF

    • 对于 v2 组织：

      cat > IAC_REPO_PATH/iac/infrastructure/zonal/zones/ZONE_NAME/ORG_CLUSTER_NAME-management/bil/skudescriptions/kustomization.yaml << EOF
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
- ../../../../common-data/bil/skudescriptions
EOF

  8. 暂存并提交 YAML 文件，然后自定义文件：

    cd IAC_REPO_PATH
git add "iac"
git commit

  9. 将更新推送到 GitLab：

    git -c http.sslVerify=false push

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

  11. 验证给定集群中是否存在与相应结算模式对应的 SKUDescription 对象。

    根据组织的类型导出 KUBECONFIG 值。

    • 对于 v1 组织，请运行：

      export KUBECONFIG=ORG_ADMIN_CLUSTER_KUBECONFIG

      将 ORG_ADMIN_CLUSTER_KUBECONFIG 替换为组织管理员集群 kubeconfig 的路径，例如 /tmp/${ORG}-admin-kubeconfig。

    • 对于 v2 组织，请运行：

      export KUBECONFIG=MANAGEMENT_API_SERVER_KUBECONFIG

      将 MANAGEMENT_API_SERVER_KUBECONFIG 替换为管理 API 服务器 kubeconfig 的路径，例如 /tmp/${ORG}-management-kubeconfig。

    运行 kubectl CLI：

    客户结算：

    
kubectl get SKUDescription -n billing-system

    合作伙伴结算：

    
kubectl get SKUDescription -n partner-billing-system

1.12.2.2 组织特有的价目表

如果价目表特定于某个组织，您必须将价目表放在组织集群文件夹中。

  1. 在组织集群中创建 skudescriptions 结算目录：

    • 对于 v1 组织：

      mkdir -p IAC_REPO_PATH/iac/infrastructure/zonal/zones/ZONE_NAME/ORG_CLUSTER_NAME/bil/skudescriptions

    • 对于 v2 组织：

      mkdir -p IAC_REPO_PATH/iac/infrastructure/zonal/zones/ZONE_NAME/ORG_CLUSTER_NAME-management/bil/skudescriptions

  2. 将 SKUDescription 价目表 YAML 资源保存到此文件夹中。之后，skudescriptions 文件夹必须包含按区域分隔的 YAML 文件。在以下示例中，您会看到两个服务（计算和存储），每个服务都有两个 YAML 文件：

    .
├── compute
│   ├── compute-sku1.yaml
│   └── compute-sku2.yaml
└── storage
    ├── storage-sku1.yaml
    └── storage-sku2.yaml

  3. 确保包含所有 SKUDescription 价目表 YAML 文件的目录中有一个 kustomization.yaml 文件。

    • 对于 v1 组织：

      touch IAC_REPO_PATH/iac/infrastructure/zonal/zones/ZONE_NAME/ORG_CLUSTER_NAME/bil/skudescriptions/kustomization.yaml
cd IAC_REPO_PATH/iac/infrastructure/zonal/zones/ZONE_NAME/ORG_CLUSTER_NAME/bil/skudescriptions/
kustomize edit add resource */*.yaml

    • 对于 v2 组织：

      touch IAC_REPO_PATH/iac/infrastructure/zonal/zones/ZONE_NAME/ORG_CLUSTER_NAME-management/bil/skudescriptions/kustomization.yaml
cd IAC_REPO_PATH/iac/infrastructure/zonal/zones/ZONE_NAME/ORG_CLUSTER_NAME-management/bil/skudescriptions/
kustomize edit add resource */*.yaml

  4. 确保组织根目录中的 kustomization.yaml 文件包含新添加的 bil/skudescriptions 文件夹。检查 IAC_REPO_PATH/iac/infrastructure/zonal/zones/ZONE_NAME/ORG_CLUSTER_NAME/kustomization.yaml（适用于 v1 组织）和 IAC_REPO_PATH/iac/infrastructure/zonal/zones/ZONE_NAME/ORG_CLUSTER_NAME-management/kustomization.yaml（适用于 v2 组织）：

    apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
-   ... # existing resource items
-   bil/skudescriptions

  5. 暂存并提交 YAML 文件和 kustomize 文件：

    cd IAC_REPO_PATH
git add "iac"
git commit

  6. 将更新推送到 GitLab：

    git -c http.sslVerify=false push

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

  8. 验证指定集群中是否存在 SKUDescription 对象：

    • 对于 v1 组织，请运行：

      export KUBECONFIG=ORG_ADMIN_CLUSTER_KUBECONFIG

kubectl get SKUDescription -n billing-system

      将 ORG_ADMIN_CLUSTER_KUBECONFIG 替换为组织管理员集群 kubeconfig 的路径，例如 /tmp/${ORG}-admin-kubeconfig。

    • 对于 v2 组织，请运行：

      export KUBECONFIG=MANAGEMENT_API_SERVER_KUBECONFIG

kubectl get SKUDescription -n billing-system

      将 MANAGEMENT_API_SERVER_KUBECONFIG 替换为管理 API 服务器 kubeconfig 的路径，例如 /tmp/${ORG}-management-kubeconfig。 。

1.13 创建结算周期性用量

Distributed Cloud 提供会产生周期性费用的库存量单位 (SKU)。不过，Distributed Cloud 不会跟踪某些 SKU 的使用费用。如需管理此类信息，请使用 RecurringUsage 资源。如需详细了解如何创建周期性使用情况，请参阅创建周期性使用情况。

1.14 为组织配置结算

结算子组件在达到结算开始时间之前不会开始计算组织的费用。结算开始时间的默认值为 9999-01-01T00:00:00-07:00。因此，在组织被视为准备就绪后，IO 会替换结算开始时间，以开始结算工作流。

1.14.1 获取结算开始时间

结算开始时间必须是合同中规定的履约期开始时间。如果您尚未获得组织的结算开始时间，请与项目管理办公室 (PMO) 联系以获取相关信息。

1.14.2 将结算付款账号映射到组织

Google Distributed Cloud (GDC) 空气隔离环境需要结算账号来跟踪项目和组织的费用。如果您未将结算账号与组织或项目相关联，则会丢失与相应资源相关联的费用数据。

为了向客户收取服务使用费，组织内的所有结算账号都使用同一份价目表。

1.14.2.1 准备工作

在继续操作之前，请让您的 Security Admin 授予您以下必需的角色。这些角色会绑定到项目级结算的项目命名空间，或组织级结算的平台命名空间：

  • 组织结算账号管理员：创建、管理和绑定 BillingAccount 资源。请让 Security Admin 为您授予 organization-billing-account-admin 角色。

  • 组织结算账号用户：读取、列出和绑定 BillingAccount 资源。请让 Security Admin 为您授予 organization-billing-account-user 角色。

  • 组织结算账号管理员：读取、列出、创建和更新 BillingAccountBinding 资源。请让 Security Admin 为您授予 organization-billing-manager 角色。

1.14.2.2 创建新的结算账号

结算账号由其 name 和 namespace 唯一标识。如需创建结算账号，请使用自定义资源来建立 name 和 namespace：

  1. 创建一个 YAML 文件，并添加 BillingAccount 自定义资源和以下内容：

    apiVersion: billing.gdc.goog/v1
kind: BillingAccount
metadata:
  namespace: platform
  name: BIL_ACCOUNT_NAME
spec:
  displayName: BIL_DISPLAY_NAME
  paymentSystemConfig:
    cloudBillingConfig:
      accountID: "012345-6789AB-CDEF01"

    执行以下变量替换操作：

    • BIL_ACCOUNT_NAME：结算账号的名称。例如。test-billing-account。
    • BIL_DISPLAY_NAME：结算账号的显示名称。例如。"Test Billing Account"。

  2. 验证您的付款配置类型。分布式云结算账号必须具有以下付款配置之一：

    • cloudBillingConfig：默认付款配置。此配置用于存储 Cloud Billing 账号 ID。

    • customConfig：合作伙伴用于存储其付款配置以向组织收取费用的自定义配置。customConfig 支持键值字符串的字典，其中包含一个必需的键 payment-config-type。

    以下示例展示了不同付款配置的 BillingAccount YAML 文件代码段：

    cloudBillingConfig

    spec:
  paymentSystemConfig:
    cloudBillingConfig:
      accountID: CLOUD_BILLING_ACCOUNT_ID

    将 CLOUD_BILLING_ACCOUNT_ID 替换为您的Google Cloud 结算账号 ID。

    customConfig

    spec:
  paymentSystemConfig:
    customConfig:
      "payment-config-type": PAYMENT_CONFIG_TYPE

    将 PAYMENT_CONFIG_TYPE 替换为您为自定义结算配置选择的付款配置类型。

    如果您没有组织的 customConfig 配置信息，请输入以下详细信息：

    spec:
  paymentSystemConfig:
    customConfig:
      "payment-config-type": "N/A"

    以下 YAML 文件展示了一个完整的 BillingAccount 资源，其中包含 cloudBillingConfig 配置：

    apiVersion: billing.gdc.goog/v1
kind: BillingAccount
metadata:
  namespace: platform
  name: test-billing-account
spec:
  displayName: "Test Billing Account"
  paymentSystemConfig:
    cloudBillingConfig:
      accountID: "012345-6789AB-CDEF01"

  3. 保存自定义资源 YAML 文件。运行 kubectl CLI，以将组织集群中的资源应用于您要结算的特定组织或项目：

    kubectl --kubeconfig $ORG_KUBECONFIG apply -f billingaccount.yaml

如需将组织与 BillingAccount 相关联，请执行以下操作：

  1. 将以下内容添加到 YAML 文件 billingaccountbinding.yaml 中：

    • 在 billingAccountRef 部分中，使用要关联的 BillingAccount 中的 name 字段的内容填充 name 字段。
    • 在 metadata 部分中，使用 BillingAccount 资源中相同字段的内容填充 namespace 字段。在此示例中，组织命名空间为 platform：
    apiVersion: billing.gdc.goog/v1
kind: BillingAccountBinding
metadata:
  name: billing
  namespace: platform
spec:
  billingAccountRef:
    name: BIL_ACCOUNT_NAME
    namespace: platform

  2. 应用 billingaccountbinding.yaml 文件：

    kubectl --kubeconfig $ORG_KUBECONFIG apply -f billingaccountbinding.yaml

1.14.3 准备工作

在继续操作之前，请让您的 Security Admin 在组织管理集群中为 billing-system 命名空间授予您 Bil Monitor (bil-monitor) 角色。此权限可让您读取相关资源以进行验证。

1.14.4 覆盖结算开始时间

  1. 创建两个 YAML 文件，路径如下：

    • infrastructure/zonal/zones/ZONE_NAME/root-admin/components/bil/ORG_NAME/bil-monetizer-override.yaml。

    • infrastructure/zonal/zones/ZONE_NAME/root-admin/components/bil/ORG_NAME/bil-invoice-override.yaml。

      • 如果缺少每个文件所需的相关子目录，请创建这些子目录。

  2. 在 SubcomponentOverride 资源中添加以下内容到每个文件中：

    客户结算：

    • bil-monetizer-override.yaml 文件：

      apiVersion: lcm.private.gdc.goog/v1
kind: SubcomponentOverride
metadata:
  name: bil-monetizer
  namespace: ORG_NAME
spec:
  subComponentRef: bil-monetizer
  backend:
    operableParameters:
      billingStartTime: BILLING_START_TIME
      billingTimezone: BILLING_TIMEZONE

    • bil-invoice-override.yaml 文件：

      apiVersion: lcm.private.gdc.goog/v1
kind: SubcomponentOverride
metadata:
  name: bil-invoice
  namespace: ORG_NAME
spec:
  subComponentRef: bil-invoice
  backend:
    operableParameters:
      billingStartTime: BILLING_START_TIME
      billingTimezone: BILLING_TIMEZONE

    对于合作伙伴运营的结算：

    • 在每个 YAML 文件的末尾添加 enablePartnerBilling: true 标志：

    • bil-monetizer-override.yaml 文件：

      apiVersion: lcm.private.gdc.goog/v1
kind: SubcomponentOverride
metadata:
  name: bil-monetizer
  namespace: ORG_NAME
spec:
  subComponentRef: bil-monetizer
  backend:
    operableParameters:
      billingStartTime: BILLING_START_TIME
      billingTimezone: BILLING_TIMEZONE
      enablePartnerBilling: true

    • bil-invoice-override.yaml 文件：

      apiVersion: lcm.private.gdc.goog/v1
kind: SubcomponentOverride
metadata:
  name: bil-invoice
  namespace: ORG_NAME
spec:
  subComponentRef: bil-invoice
  backend:
    operableParameters:
      billingStartTime: BILLING_START_TIME
      billingTimezone: BILLING_TIMEZONE
      enablePartnerBilling: true

    执行以下变量替换操作：

    • ORG_NAME：组织的名称。 例如：org-1。

    • BILLING_START_TIME：开始结算工作流程的时间戳。时间戳必须采用 RFC 3339 格式。例如，如果结算工作流程于 2024 年 1 月 1 日开始，且时区为美国和加拿大太平洋标准时间 (UTC-8)，则添加的时间戳值为 2024-01-01T00:00:00-08:00。

    • BILLING_TIMEZONE：结算工作流的时区。 时区必须采用 RFC 3339 格式。例如，如果结算时区是美国和加拿大太平洋标准时间 (UTC-8)，请添加时区值 PST8PDT。

    • bil-monetizer-override-mp.yaml 文件：

      apiVersion: lcm.private.gdc.goog/v1
kind: SubcomponentOverride
metadata:
  name: bil-monetizer
  namespace: ORG_NAME-mp
spec:
  subComponentRef: bil-monetizer
  backend:
    operableParameters:
      billingStartTime: BILLING_START_TIME
      billingTimezone: BILLING_TIMEZONE
      enablePartnerBilling: true

    • bil-invoice-override-mp.yaml 文件：

      apiVersion: lcm.private.gdc.goog/v1
kind: SubcomponentOverride
metadata:
  name: bil-invoice
  namespace: ORG_NAME-mp
spec:
  subComponentRef: bil-invoice
  backend:
    operableParameters:
      billingStartTime: BILLING_START_TIME
      billingTimezone: BILLING_TIMEZONE
      enablePartnerBilling: true

  3. 将 YAML 文件保存并存储在 infrastructure/zonal/zones/ZONE_NAME/root-admin/components/bil/ORG_NAME 文件夹中。

  4. 创建一个包含 YAML 文件以及必要 Kustomization 文件的 pull 请求。

1.14.5 验证结算开始时间

验证您是否已替换创收者的结算开始时间和账单生成时间：

kubectl --kubeconfig ORG_ADMIN_KUBECONFIG \
    get deployment billing-monetizer -n billing-system \
    -o jsonpath='{.spec.template.spec.containers[0].args}{"\n"}'

kubectl --kubeconfig ORG_ADMIN_KUBECONFIG \
    get cronjob billing-ig-job -n billing-system \
    -o jsonpath='{.spec.jobTemplate.spec.template.spec.containers[0].args}{"\n"}'

1.15 在组织的管理员集群上配置对象存储代理的网络政策

1.15.1 创建网络政策 YAML 文件

创建 allow-obs-system-ingress-traffic 网络政策 YAML 文件，例如 networkpolicy.yaml：

  apiVersion: networking.k8s.io/v1
  kind: NetworkPolicy
  metadata:
    annotations:
      policy.network.gke.io/enable-logging: "true"
      resourcemanager.gdc.goog/propagated-name: allow-obs-system-ingress-traffic
    name: allow-obs-system-ingress-traffic
    namespace: obj-system
  spec:
    ingress:
    - from:
      - namespaceSelector:
          matchLabels:
            resourcemanager.gdc.goog/project-name: obs-system
    podSelector: {}
    policyTypes:
    - Ingress

1.15.2 将网络政策应用于组织的管理员集群

kubectl --kubeconfig ORG_ADMIN_KUBECONFIG apply -f networkpolicy.yaml

1.16. 创建备份网站

如果您利用灾难恢复支持，则必须再次为备份网站完成上述步骤。如果您未启用灾难恢复，请跳过此部分。

  1. 请按照第 1.4 节中的说明操作。- 1.9. 创建另一个组织作为备份网站。

1.17. 排查组织创建问题

1.17.1. 确认所有已部署的资源都处于正常状态且存在

组织创建过程会在不同的 Kubernetes 集群中创建多个资源。首先，检查已部署的资源，确保它们处于良好状态。以下部分概述了为名为 operations 的组织创建的资源。

1.17.2. 确认根管理员集群中的所有已部署资源

完成以下步骤，确认根管理员集群中的所有资源是否健康且存在：

  1. 按照 IAM-R0004 中的说明，获取根管理员集群所需的 kubeconfig 配置。 请务必为这些验证说明设置以下环境变量和别名：

    export KUBECONFIG=ROOT_ADMIN_KUBECONFIG
export ORG="ORG_NAME"
alias k=kubectl

  2. 确认防火墙资源可用：

    1. 建立与防火墙的 SSH 连接，并确认已创建新的 vsys：

      show config running | match 'vsys[0-9] '

      输出类似于以下内容：

      vsys1 {
vsys2 {

    2. 检查 FirewallVirtualSystem 资源：

      k get firewallvirtualsystem -n gpc-system

      输出类似于以下内容：

      NAME                                   AGE
kb-ab-fw01-internal-vsys2-operations   4d19h
kb-ab-fw01-vsys-root-admin             13d
kb-ac-fw01-internal-vsys2-operations   4d19h
kb-ac-fw01-vsys-root-admin             13d

  3. 确认存储资源可用：

    1. 检查 StorageVirtualMachine 资源：

      k get StorageVirtualMachine -n gpc-system

      输出类似于以下内容：

      NAME               STORAGEORG   MGMTIP      READY   AGE
operations-admin   operations   10.0.2.10   True    5d22h
operations-user    operations   10.0.2.18   True    5d22h
root-admin         root         10.0.2.2    True    13d

  4. 确认 HSM 资源可用：

    1. 检查 HSM：

      k get hsms -n gpc-system

      输出类似于以下内容：

      NAMESPACE    NAME          AGE    IP               READY   REASON
gpc-system   zk-aa-hsm01   2h     198.51.100.192   True    ReconcileHSMSuccess
gpc-system   zk-aa-hsm02   2h     198.51.100.193   True    ReconcileHSMSuccess
gpc-system   zk-ab-hsm01   2h     198.51.100.194   True    ReconcileHSMSuccess

    2. 检查 HSM 集群：

      k get hsmcluster -n gpc-system

      输出类似于以下内容：

      NAMESPACE    NAME          AGE   READY   REASON
gpc-system   hsmcluster    38h   True    ReconcileHSMClusterSuccess

    3. 检查 HSM 租户：

      k get hsmtenant -A

      输出类似于以下内容：

      NAMESPACE    NAME         AGE     READY   REASON
gpc-system   root         13d     True    ReconcileHSMTenantSuccess
operations   operations   5d22h   True    ReconcileHSMTenantSuccess

  5. 确认机器和节点资源可用：

    1. 检查 AddressPoolClaim 资源：

      k get addresspoolclaims -A

      输出类似于以下内容：

      NAMESPACE    NAME                                              AGE
operations   admin-control-plane-node-pool                     5d23h
operations   operations-admin-dns-default-ipv4-ipc             5d23h
operations   operations-admin-load-balancer-default-ipv4-ipc   5d23h

    2. 检查 NodePoolClaim 资源：

      k get nodepoolclaims -A

      输出类似于以下内容：

      NAMESPACE    NAME                            AGE
operations   admin-control-plane-node-pool   5d23h
root         root-admin-control-plane        13d

    3. 检查 NodePool 资源：

      k get nodepool -A

      输出类似于以下内容：

      NAMESPACE    NAME                            READY   RECONCILING   STALLED   UNDERMAINTENANCE   UNKNOWN
operations   admin-control-plane-node-pool   3       0             0         0                  0
root         root-admin-control-plane        3       0             0         0                  0

    4. 检查裸金属集群：

      k get baremetalclusters -A

      输出类似于以下内容：

      NAMESPACE    NAME               CLUSTER            READY
operations   operations-admin   operations-admin   true
root         root-admin         root-admin         true

    5. 检查裸金属机器：

      k get baremetalmachines -A

      输出类似于以下内容：

      NAMESPACE    NAME           CLUSTER            READY   INSTANCEID                 MACHINE
operations   10.251.82.28   operations-admin   true    baremetal://10.251.82.28   10.251.82.28
operations   10.251.82.29   operations-admin   true    baremetal://10.251.82.29   10.251.82.29
operations   10.251.82.30   operations-admin   true    baremetal://10.251.82.30   10.251.82.30
root         10.251.80.2    root-admin         true    baremetal://10.251.80.2    10.251.80.2
root         10.251.80.3    root-admin         true    baremetal://10.251.80.3    10.251.80.3
root         10.251.80.4    root-admin         true    baremetal://10.251.80.4    10.251.80.4

    6. 检查服务器。它们处于 provisioned 状态：

      k get servers -n gpc-system | grep provisioned

      输出类似于以下内容：

      kb-aa-bm01   13d          o1-highmem1-40-gdc-metal    10.251.252.61   10.251.80.2              10.251.252.62   provisioned   true
kb-aa-bm02   13d          o1-standard1-64-gdc-metal   10.251.252.63   10.251.82.28             10.251.252.64   provisioned   true
kb-aa-bm03   13d          o1-standard1-64-gdc-metal   10.251.252.65   10.251.82.29             10.251.252.66   provisioned   true
kb-aa-bm04   13d          o1-standard1-64-gdc-metal   10.251.252.67   10.251.82.30             10.251.252.68   provisioned   true
kb-aa-bm08   13d          o1-highmem1-96-gdc-metal    10.251.252.75   10.0.35.2                10.251.252.76   provisioned   true
kb-aa-bm10   13d          o1-highmem1-96-gdc-metal    10.251.252.79   10.0.35.4                10.251.252.80   provisioned   true
kb-aa-bm14   13d          o1-highgpu1-48-gdc-metal    10.251.252.87   10.0.35.9                10.251.252.88   provisioned   true
kb-aa-bm15   13d          o1-highgpu1-48-gdc-metal    10.251.252.89   10.0.35.10               10.251.252.90   provisioned   true
kb-aa-bm16   13d          o1-highgpu1-48-gdc-metal    10.251.252.91   10.0.35.11               10.251.252.92   provisioned   true
kb-ab-bm01   13d          o1-highmem1-40-gdc-metal    10.251.253.61   10.251.80.3              10.251.253.62   provisioned   true
kb-ac-bm01   13d          o1-highmem1-40-gdc-metal    10.251.254.61   10.251.80.4              10.251.254.62   provisioned   true

    7. 检查 Kubernetes 集群：

      k get cluster -A

      输出类似于以下内容：

      NAMESPACE    NAME               AGE
operations   operations-admin   5d23h
root         root-admin         13d

    8. 检查 kubeconfig 的 Secret：

      k get secrets -A | grep kubeconfig

      输出类似于以下内容：

      operations    operations-admin-kubeconfig   Opaque        1      5d22h
root          root-admin-kubeconfig         Opaque        1      13d

1.17.3. 确认 v1 组织集群中的所有已部署资源

完成以下步骤，确认 v1 组织中的组织管理员集群和系统集群中的所有资源都处于健康状态且存在。如果您拥有 v2 组织，请跳至下一部分。

1.17.3.1. 确认组织管理员集群中的所有已部署资源

  1. 按照 IAM-R0004 中的说明，获取根管理员集群所需的 kubeconfig 配置。 请务必为这些验证说明设置以下环境变量和别名：

    export ORG="ORG_NAME"
export KUBECONFIG=ROOT_ADMIN_KUBECONFIG
k get secrets -n ${ORG} ${ORG}-admin-kubeconfig -o jsonpath='{.data.value}' \
    | base64 -d > /tmp/${ORG}-admin-kubeconfig
export ORG_ADMIN_KUBECONFIG=/tmp/${ORG}-admin-kubeconfig
alias ka="kubectl --kubeconfig ${ORG_ADMIN_KUBECONFIG}"

  2. 确认机器和节点资源可用：

    1. 检查裸金属集群：

      ka get baremetalclusters -A

      输出类似于以下内容：

      NAMESPACE                    NAME                 CLUSTER              READY
operations-system-cluster    operations-system    operations-system    true

    2. 检查裸金属机器：

      ka get baremetalmachines -A

      输出类似于以下内容：

      NAMESPACE                    NAME            CLUSTER              READY   INSTANCEID                  MACHINE
operations-system-cluster    10.0.35.10      operations-system    true    baremetal://10.0.35.10      10.0.35.10
operations-system-cluster    10.0.35.11      operations-system    true    baremetal://10.0.35.11      10.0.35.11
operations-system-cluster    10.0.35.2       operations-system    true    baremetal://10.0.35.2       10.0.35.2
operations-system-cluster    10.0.35.3       operations-system    true    baremetal://10.0.35.3       10.0.35.3
operations-system-cluster    10.0.35.4       operations-system    true    baremetal://10.0.35.4       10.0.35.4
operations-system-cluster    10.0.35.9       operations-system    true    baremetal://10.0.35.9       10.0.35.9
operations-system-cluster    10.251.82.205   operations-system    true    baremetal://10.251.82.205   10.251.82.205
operations-system-cluster    10.251.82.206   operations-system    true    baremetal://10.251.82.206   10.251.82.206
operations-system-cluster    10.251.82.207   operations-system    true    baremetal://10.251.82.207   10.251.82.207
operations-system-cluster    10.251.82.232   operations-system    true    baremetal://10.251.82.232   10.251.82.232

    3. 检查机器：

      ka get machines -A

      输出类似于以下内容：

      NAMESPACE                    NAME            NODEPOOL
operations-system-cluster    10.0.35.10      worker-node-pool-o1-highgpu1-48-gdc-metal
operations-system-cluster    10.0.35.11      worker-node-pool-o1-highgpu1-48-gdc-metal
operations-system-cluster    10.0.35.2       worker-node-pool-o1-highmem1-96-gdc-metal
operations-system-cluster    10.0.35.3       worker-node-pool-o1-highmem1-96-gdc-metal
operations-system-cluster    10.0.35.4       worker-node-pool-o1-highmem1-96-gdc-metal
operations-system-cluster    10.0.35.9       worker-node-pool-o1-highgpu1-48-gdc-metal
operations-system-cluster    10.251.82.205   control-plane-node-pool
operations-system-cluster    10.251.82.206   control-plane-node-pool
operations-system-cluster    10.251.82.207   control-plane-node-pool
operations-system-cluster    10.251.82.232   control-plane-node-pool

    4. 检查 VirtualmachinesInstance 资源：

      ka get virtualmachineinstances -A

      输出类似于以下内容：

      NAMESPACE                    NAME          AGE     PHASE     IP              NODENAME     READY
operations-system-cluster    vm-19753801   2d16h   Running   10.251.82.207   kb-aa-bm02   True
operations-system-cluster    vm-3661f750   4d19h   Running   10.251.82.232   kb-aa-bm03   True
operations-system-cluster    vm-3c77c480   5d20h   Running   10.251.82.206   kb-aa-bm04   True

    5. 检查 NodePool 资源：

      ka get nodepools -A

      输出类似于以下内容：

      NAMESPACE                    NAME                                        READY   RECONCILING   STALLED   UNDERMAINTENANCE   UNKNOWN
operations-system-cluster    control-plane-node-pool                     3       0             0         0                  0
operations-system-cluster    worker-node-pool-o1-highgpu1-48-gdc-metal   3       0             0         0                  0
operations-system-cluster    worker-node-pool-o1-highmem1-96-gdc-metal   2       0             0         0                  0

    6. 检查 Kubernetes 集群：

      ka get clusters -A

      输出类似于以下内容：

      NAMESPACE                    NAME                 AGE
operations-system-cluster    operations-system    5d20h

    7. 检查节点：

      ka get nodes -A

      输出类似于以下内容：

      NAME         STATUS   ROLES                  AGE     VERSION
kb-aa-bm02   Ready    control-plane,master   5d23h   v1.23.5-gke.1505
kb-aa-bm03   Ready    control-plane,master   5d23h   v1.23.5-gke.1505
kb-aa-bm04   Ready    control-plane,master   5d23h   v1.23.5-gke.1505

    8. 检查 kubeconfig 的 Secret：

      ka get secret -n ${ORG}-system-cluster ${ORG}-system-kubeconfig

      输出类似于以下内容：

      NAME                           TYPE     DATA   AGE
operations-system-kubeconfig   Opaque   1      5d20h

1.17.3.2. 确认系统用户集群中的所有已部署资源

完成以下步骤，确认系统集群中的所有资源是否正常且存在：

  1. 按照 IAM-R0004 中的说明，获取根管理员集群所需的 kubeconfig 配置。 请务必为这些验证说明设置以下环境变量和别名：

    export ORG="ORG_NAME"
export KUBECONFIG=ROOT_ADMIN_KUBECONFIG
k get secrets -n ${ORG} ${ORG}-admin-kubeconfig -o jsonpath='{.data.value}' \
    | base64 -d > /tmp/${ORG}-admin-kubeconfig
export ORG_ADMIN_KUBECONFIG=/tmp/${ORG}-admin-kubeconfig
alias ka="kubectl --kubeconfig ${ORG_ADMIN_KUBECONFIG}"
ka get secret -n ${ORG}-system-cluster ${ORG}-system-kubeconfig -o jsonpath='{.data.value}' \
    | base64 -d > /tmp/${ORG}-system-kubeconfig
export SYSTEM_KUBECONFIG=/tmp/${ORG}-system-kubeconfig
alias ku="kubectl --kubeconfig ${SYSTEM_KUBECONFIG}"

  2. 确认机器和节点资源可用：

    1. 检查 VirtualmachineInstance 资源：

      ku get vmi -A

      输出类似于以下内容（如果已创建用户集群）：

      NAMESPACE       NAME            AGE     PHASE     IP            NODENAME     READY
gdc-vm-infra   vm-61aa554d     3d21h   Running   10.0.35.6     kb-aa-bm10   True
gdc-vm-infra   vm-b627da1f     3d21h   Running   10.0.35.5     kb-aa-bm08   True

    2. 检查节点：

      ku get nodes

      输出类似于以下内容：

      NAME          STATUS                     ROLES                  AGE     VERSION
kb-aa-bm10    Ready                      worker                 5d20h   v1.23.5-gke.1505
kb-aa-bm14    Ready                      worker                 38h     v1.23.5-gke.1505
kb-aa-bm15    Ready                      worker                 38h     v1.23.5-gke.1505
kb-aa-bm16    Ready                      worker                 38h     v1.23.5-gke.1505
vm-19753801   Ready                      control-plane,master   5d21h   v1.23.5-gke.1505
vm-3661f750   Ready                      control-plane,master   4d20h   v1.23.5-gke.1505
vm-3c77c480   Ready                      control-plane,master   5d20h   v1.23.5-gke.1505

    3. 检查 GPU 分配情况：

      ku get gpuallocations -A

      输出类似于以下内容：

      NAMESPACE   NAME         ALLOCATED   DEVICEMODEL
vm-system   kb-aa-bm14   true        A100 PCIe 40GB
vm-system   kb-aa-bm15   true        A100 PCIe 40GB
vm-system   kb-aa-bm16

1.17.4. 确认 v2 组织集群中的所有已部署资源

完成以下步骤，确认 v2 组织中的组织基础架构集群中的所有资源都处于正常状态且存在。如果您拥有第 1 版组织，请跳过此部分。

  1. 按照 IAM-R0004 中的说明，获取根管理员集群所需的 kubeconfig 配置。 请务必为这些验证说明设置以下环境变量和别名：

    export ORG="ORG_NAME"
export KUBECONFIG=ROOT_ADMIN_KUBECONFIG
k get secrets -n ${ORG} ${ORG}-admin-kubeconfig -o jsonpath='{.data.value}' \
    | base64 -d > /tmp/${ORG}-admin-kubeconfig
export ORG_ADMIN_KUBECONFIG=/tmp/${ORG}-admin-kubeconfig
alias ka="kubectl --kubeconfig ${ORG_ADMIN_KUBECONFIG}"

  2. 确认节点和 API 服务器运行状况良好：

    1. 检查节点：

      ka get nodes -A

      输出类似于以下内容：

      NAME         STATUS   ROLES                  AGE     VERSION
kb-aa-bm02   Ready    control-plane,master   5d23h   v1.23.5-gke.1505
kb-aa-bm03   Ready    control-plane,master   5d23h   v1.23.5-gke.1505
kb-aa-bm04   Ready    control-plane,master   5d23h   v1.23.5-gke.1505
kb-aa-bm05   Ready    worker                 5d23h   v1.23.5-gke.1505
kb-aa-bm06   Ready    worker                 5d23h   v1.23.5-gke.1505
kb-aa-bm07   Ready    worker                 5d23h   v1.23.5-gke.1505

    2. 检查 kubeconfig 的 Secret：

      ka get secret -n management-kube-system kube-admin-remote-kubeconfig

      输出类似于以下内容：

      NAME                           TYPE     DATA   AGE
kube-admin-remote-kubeconfig   Opaque   1      5d20h

  3. 检查 GPU 分配情况，以确认 GPU 资源是否已准备就绪（如果适用）：

    ka get gpuallocations -A

    输出类似于以下内容：

    NAMESPACE   NAME         ALLOCATED   DEVICEMODEL
vm-system   kb-aa-bm14   true        A100 PCIe 40GB
vm-system   kb-aa-bm15   true        A100 PCIe 40GB
vm-system   kb-aa-bm16

1.17.5. 确认所有组织资源均已协调

完成以下步骤，以确认全局和可用区级根管理员集群中的所有组织相关资源都处于健康状态且存在，假设目标是创建具有两个可用区（zone-1 和 zone-2）的 operations 组织。

  1. 按照访问全局根管理员 API 中的说明访问全局 API 服务器，并使用以下别名来访问全局根管理员 API kubectl。

    alias kga='kubectl --kubeconfig ROOT_ADMIN_KUBECONFIG
export ORG="ORG_NAME"

  2. 确认全局组织资源可用：

    1. 检查全局 Organization 资源：

      kga get organization -A

      输出类似于以下内容：

      NAMESPACE    NAME         READY
gpc-system   operations
gpc-system   root

    2. 检查全局 OrganizationReplica 资源：

      kga get organizationreplica -A

      输出类似于以下内容：

      NAMESPACE    NAME               AGE
gpc-system   operations-zone1   3d16h
gpc-system   operations-zone2   3d16h
gpc-system   root-zone1         3d17h
gpc-system   root-zone2         3d16h

    3. 检查全局 OrganizationZonalConfig 资源：

      kga get organizationzonalconfig -A

      输出类似于以下内容：

      NAMESPACE    NAME                      AGE
gpc-system   operations-zone1-config   3d16h
gpc-system   operations-zone2-config   3d16h

    4. 检查全局 OrganizationZonalConfigReplica 资源：

      kga get organizationzonalconfigreplica -A

      输出类似于以下内容：

      NAMESPACE    NAME                             AGE
gpc-system   operations-zone1-config-zone1    3d16h
gpc-system   operations-zone1-config-zone2    3d16h
gpc-system   operations-zone2-config-zone1    3d16h
gpc-system   operations-zone2-config-zone2    3d16h

  3. 设置区域根管理员集群的 kubeconfig 配置别名：

    alias ka='kubectl --kubeconfig /root/GDC_VERSION/root-admin/root-admin-kubeconfig'

  4. 确认地区组织资源可用：

    1. 检查 Organization 资源：

      ka get organization -A

      输出类似于以下内容：

      NAMESPACE    NAME         READY
gpc-system   operations   True
gpc-system   root         True

    2. 检查 OrganizationReplica 资源：

      ka get organizationreplica -A

      输出类似于以下内容：

      NAMESPACE    NAME         AGE
gpc-system   operations   3d16h
gpc-system   root         3d17h

    3. 检查 OrganizationZonalConfigReplica 资源：

      ka get organizationzonalconfigreplica -A

      输出类似于以下内容：

      NAMESPACE    NAME                       AGE
gpc-system   operations-zone1-config    3d16h
gpc-system   operations-zone2-config    3d16h

  5. 按照允许任何地址访问组织中的步骤操作，以允许组织管理员集群中的 DCI 流量从源网站流向备份网站。