1. 建立客戶機構

預計完成時間：3 小時

技能設定檔：部署工程師

身為「營運商」，您可以建立機構，讓客戶存取平台基礎架構。如要取得建立機構所需的權限，請要求安全管理員授予您機構管理員角色。

Organization 資源是 Google Distributed Cloud (GDC) 氣隙資源階層的根節點，屬於機構的所有資源都以機構節點分組。如此即可對屬於機構的所有資源提供集中式的瀏覽權限和控制。

如要進一步瞭解機構，請參閱機構總覽。

1.1. 事前準備

請確認已安裝下列項目：

  • 系統中的瀏覽器。

  • Git 指令列介面 (CLI)。

  • kubectl CLI。

  • gdcloud CLI。

1.2. 在 OC IT ADFS 中建立 OIDC 用戶端

  1. 請參閱 ADFS OIDC 設定操作說明，在 ADFS 中為 Operator 建立 OpenID Connect (OIDC) 用戶端，以便存取您要建立的機構。記下 OIDC 用戶端的用戶端 ID 和用戶端密鑰。您不得在連線至其他叢集 (例如根管理員叢集和其他機構管理員叢集) 或服務 (例如 ServiceNow) 時重複使用用戶端。

  2. 在為要建立的機構建立的 ADFS OIDC 用戶端中，將下列 GKE Identity Service 回呼網址新增至允許清單：

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

    例如：

    • 機構名稱：operations
    • Distributed Cloud 執行個體名稱：google
    • Distributed Cloud 網域名稱：gdch.test

    這種情況下，GKE Identity Service 回呼網址為 https://ais-core.operations.google.gdch.test/finish-login。

  3. 在您為 GDC 宇宙中每個區域建立的 ADFS OIDC 用戶端中，將下列 GKE Identity Service 回呼網址加入允許清單：

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

    例如：

    • 機構名稱：operations
    • 可用區名稱：zone-1
    • Distributed Cloud 執行個體名稱：google
    • Distributed Cloud 網域名稱：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 用戶端 ID。
    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) 集區，並分割至各個區域，以啟動租戶機構中的所有叢集，包括機構基礎架構叢集和工作負載 VM。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 私人位址空間。

    對等互連網路：可以是透過互連附件向外部網路宣傳的任何子網路，也可以是與同一機構中其他虛擬私有雲建立對等互連的子網路。

  • 如果機構共用相同的互連網路 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 的兩個區域，則使用 infraVPCCIDR 的全域根子網路 infra-vpc-root-cidr 範例 (例如 10.0.0.0/16) 會來自 org-1 命名空間中的 OIQ，如下所示：

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. 手動分割區域的根子網路 (基礎架構虛擬私有雲範例)

如果有名為 zone1 和 zone2 的兩個可用區，則使用 infraVPCCIDR 的範例全域根子網路 infra-vpc-root-cidr (例如 192.0.2.0/24) 來自 org-1 命名空間，如下所示：

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 的子網路，以及使用您決定的專屬 CIDR 建立任播子網路 infra-vpc-anycast-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 的全域根子網路 data-external-root-cidr 範例 (例如 10.0.0.0/24) 來自 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 的子網路，以及使用您決定的專屬 CIDR 建立任播子網路 data-global-anycast-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 範例 (例如 192.168.1.0/24) 會來自 org-1 命名空間中的 OIQ，如下所示：

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)，以及使用您決定的專屬 CIDR 建立任播子網路 admin-global-anycast-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 密鑰形式儲存的軟體根金鑰。 傳入 ctm-root 或 local-root 用於 kmsRootKeyType。

    產生的 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 系統自動產生機構管理員叢集和系統叢集時，要為這些叢集分配的伺服器。如果您打算執行以 VM 為基礎的工作負載 (例如預先訓練的人工智慧和機器學習 (AI/ML) API) 的圖形處理器 (GPU) 資源，則建立機構時必須佈建 GPU 機器。詳情請參閱「為系統叢集啟用 GPU 支援」一節。
    ADMIN_SERVER 伺服器類型和要為該伺服器類型分配的機構管理員伺服器數量鍵/值組合。伺服器不支援混合類型。預設值為 o1-standard1-64-gdc-metal: 3。
    STORAGE_SIZE 為機構指派的不同儲存空間類型大小。 機構的區塊儲存空間大小下限為 250 Gi，可使用 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. 確認機構類型。您可以佈建兩種機構類型：

      • Org v1 架構 (v1 組織)
      • Org v2 架構 (v2 機構)

      根據預設，系統會根據您透過功能閘設定的部署類型，佈建新機構：

      • PRODUCTION 部署作業預設會產生 v2 機構。
      • ACCREDITED 部署作業預設會產生第 1 版機構。

      在極少數情況下，您必須覆寫部署類型的預設機構類型，請將產生的 Organization 自訂資源中的 spec.compatibilityOptions.architectureOverridePolicy 欄位更新為 ForceV1 或 ForceV2，視您要使用的機構類型而定。舉例來說，下列程式碼片段會在 ACCREDITED 部署作業中強制建立第 2 版機構：

      ...

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 位址，以及 VM 工作負載的 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. 將新建立的檔案附加至 kustomization.yaml 檔案 (位於 IAC_REPO_PATH /iac/infrastructure/global/orgs/ORG_NAME/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. 如要確認運算子可以存取機構，請登入產生的機構，然後執行下列指令，驗證機構的 ClientConfig 中是否有身分識別提供者 (IdP)：

    1. 根據機構架構設定管理員叢集 kubeconfig 檔案：

      • 如果是第 1 版機構，請執行：

        export KUBECONFIG=ORG_ADMIN_CLUSTER_KUBECONFIG

        將 ORG_ADMIN_CLUSTER_KUBECONFIG 替換為機構管理員叢集 kubeconfig 的路徑，例如 /tmp/${ORG}-admin-kubeconfig。

      • 如果是第 2 版機構，請執行：

        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) 連線至機構，並使用該機構的 ID 登入，請完成下列步驟：

  1. 使用建立機構時設定的初始 IO 管理員帳戶，從 CLI 登入，該帳戶會自動繫結至機構管理員叢集中的 org-iam-admin。

  2. 請要求客戶在為您要建立的機構建立的 OIDC 或 SAML 用戶端中，將下列全域 AIS 回呼網址新增至允許清單：

    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. 請客戶在為每個區域建立的 OIDC 或 SAML 用戶端中，將下列 AIS 回呼網址新增至允許清單。舉例來說，如果是三個區域的宇宙，區域 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 變數，請略過這個步驟。

    • 如果是第 1 版機構，請執行：

        export KUBECONFIG=ORG_ADMIN_CLUSTER_KUBECONFIG

      將 ORG_ADMIN_CLUSTER_KUBECONFIG 替換為機構管理員叢集 kubeconfig 的路徑，例如 /tmp/${ORG}-admin-kubeconfig。

    • 如果是第 2 版機構，請執行：

        export KUBECONFIG=MANAGEMENT_API_SERVER_KUBECONFIG

      將 MANAGEMENT_API_SERVER_KUBECONFIG 替換為 Management 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 選用 以半形逗號分隔的 ID 清單，用於指定除了 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. 在網頁瀏覽器中開啟 Platform Admin UI 控制台，驗證設定。在重新導向頁面中選取「Log in with pa-idp-oidc」。如果您重新導向至 PA 帳戶 IdP 執行個體，並在透過 PA 帳戶 IdP 執行個體登入後，重新導向回平台管理員 UI 控制台頁面，即表示設定成功。否則，請檢查 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 提供者的單一登入端點 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. 在網頁瀏覽器中開啟 Platform Admin UI 控制台，驗證設定。在重新導向頁面中選取「Log in with pa-idp-oidc」。如果您重新導向至 PA 帳戶 IdP 執行個體，並在透過 PA 帳戶 IdP 執行個體登入後，重新導向回平台管理員 UI 控制台頁面，即表示設定成功。否則，請檢查 identity-provider-config.yaml 中的值，然後重新執行上一個步驟。

使用者和群組前置字串

您必須為 Distributed Cloud 中的每個 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 為機構建立網路連線

新建立的機構會與外部網路隔離，因此無法從外部網路存取。如要讓機構正常運作，您必須使用互連服務，將機構連線至一或多個外部網路。

這項程序需要設定一組自訂資源，用於定義邏輯連線。以下是為新機構提供連線的兩種常見情境。

情境 1：將機構附加至現有的共用互連

如果共用網路已有互連，您只需要更新 AttachmentGroup 和 RoutePolicy，加入新機構即可。

  1. 更新 AttachmentGroup： AttachmentGroup 會指定哪些機構可以使用一組 VLAN 連結。編輯 AttachmentGroup YAML 檔案，並將新機構加到 spec.entities 清單。如果是第 2 版機構，您必須指定要連線的網路 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. 使用基礎架構即程式碼 (IaC) 程序，透過 kubectl apply 套用變更。

情境 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 環境變數：

    • 如果是第 1 版機構，請執行：

      export ORG_CLUSTER=ORG_ADMIN_CLUSTER_NAME

    • 如果是第 2 版機構，請執行：

      export ORG_CLUSTER=ORG_INFRA_CLUSTER_NAME

  6. 在機構中建立 skudescriptions 帳單目錄：

    • 如果是第 1 版機構：

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

    • 如果是第 2 版機構：

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

    視貴機構的版本類型而定，將 ORG_CLUSTER_NAME 替換為機構管理員叢集的名稱。

  7. 在機構中加入通用價格表：

    • 如果是第 1 版機構：

      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

    • 如果是第 2 版機構：

      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 值。

    • 如果是第 1 版機構，請執行：

      export KUBECONFIG=ORG_ADMIN_CLUSTER_KUBECONFIG

      將 ORG_ADMIN_CLUSTER_KUBECONFIG 替換為機構管理員叢集 kubeconfig 的路徑，例如 /tmp/${ORG}-admin-kubeconfig。

    • 如果是第 2 版機構，請執行：

      export KUBECONFIG=MANAGEMENT_API_SERVER_KUBECONFIG

      將 MANAGEMENT_API_SERVER_KUBECONFIG 替換為 Management 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 帳單目錄：

    • 如果是第 1 版機構：

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

    • 如果是第 2 版機構：

      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. 確認目錄中是否有 kustomization.yaml 檔案，其中包含所有 SKUDescription 價目表 YAML 檔案。

    • 如果是第 1 版機構：

      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

    • 如果是第 2 版機構：

      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 資料夾。請檢查 v1 機構的 IAC_REPO_PATH/iac/infrastructure/zonal/zones/ZONE_NAME/ORG_CLUSTER_NAME/kustomization.yaml 和 v2 機構的 IAC_REPO_PATH/iac/infrastructure/zonal/zones/ZONE_NAME/ORG_CLUSTER_NAME-management/kustomization.yaml：

    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 物件：

    • 如果是第 1 版機構，請執行：

      export KUBECONFIG=ORG_ADMIN_CLUSTER_KUBECONFIG

kubectl get SKUDescription -n billing-system

      將 ORG_ADMIN_CLUSTER_KUBECONFIG 替換為機構管理員叢集 kubeconfig 的路徑，例如 /tmp/${ORG}-admin-kubeconfig。

    • 如果是第 2 版機構，請執行：

      export KUBECONFIG=MANAGEMENT_API_SERVER_KUBECONFIG

kubectl get SKUDescription -n billing-system

      將 MANAGEMENT_API_SERVER_KUBECONFIG 替換為 Management 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 事前準備

繼續操作前，請要求安全管理員授予下列必要角色。這些角色會繫結至專案命名空間 (適用於專案層級帳單) 或平台命名空間 (適用於機構層級帳單)：

  • 機構帳單帳戶管理員：建立、管理及繫結 BillingAccount 資源。請安全性管理員授予您 organization-billing-account-admin 角色。

  • 機構帳單帳戶使用者：讀取、列出及繫結 BillingAccount 資源。請安全性管理員授予您 organization-billing-account-user 角色。

  • 機構帳單帳戶管理員：讀取、列出、建立及更新 BillingAccountBinding 資源。請安全性管理員授予您 organization-billing-manager 角色。

1.14.2.2 建立新的帳單帳戶

帳單帳戶的專屬 ID 為 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. 確認付款設定類型。Distributed Cloud 帳單帳戶必須採用下列其中一種付款設定：

    • 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 部分，請在 namespace 欄位中填入 BillingAccount 資源中相同欄位的內容。在本例中，機構命名空間為 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 事前準備

請先要求安全管理員在 billing-system 命名空間的機構管理叢集中，授予您帳單監控者 (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 檔案的提取要求。

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 在機構管理叢集上設定物件儲存空間 Proxy 的網路政策

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 的密鑰：

      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 機構的機構管理員叢集和系統叢集中的所有資源都正常運作且存在。如果您有第 2 版機構，請跳至下一節。

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 的密鑰：

      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 的密鑰：

      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. 確認所有機構資源都已完成協調

假設目標是建立具有兩個可用區 (operations 和 zone-2) 的機構，請完成下列步驟，確認全域和區域根管理叢集中的所有機構相關資源都正常運作且存在。zone-1

  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 流量。