1. お客様の組織を作成する

完了までの推定時間: 3 時間

スキルプロファイル: デプロイエンジニア

オペレーターは、組織を作成して、プラットフォームインフラストラクチャへのアクセスをお客様に提供できます。組織の作成に必要な権限を取得するには、組織管理者ロールを付与するようセキュリティ管理者に依頼してください。

Organization リソースは、Google Distributed Cloud（GDC）エアギャップリソース階層のルートノードであり、組織に属するすべてのリソースは組織ノードの下にグループ化されます。これにより、組織に属するすべてのリソースを集中管理できます。

組織の詳細については、組織の概要をご覧ください。

1.1. 始める前に

以下がインストールされていることを確認します。

システム内のブラウザ。
Git コマンドラインインターフェース（CLI）。
kubectl CLI。
gdcloud CLI。

1.2. OC IT ADFS で OIDC クライアントを作成する

ADFS OIDC 構成の手順に沿って、作成する組織に Operator がアクセスできるように、ADFS で OpenID Connect（OIDC）クライアントを作成します。OIDC クライアントのクライアント ID とクライアントシークレットを記録します。ルート管理クラスタや他の組織管理クラスタなどの他のクラスタや、ServiceNow などのサービスへの接続でクライアントを再利用しないでください。
作成する組織用に作成した ADFS OIDC クライアントの許可リストに、次の GKE Identity Service コールバック URL を追加します。
```
https://ais-core.ORG_NAME.GDC_URL.GDC_DOMAIN/finish-login
```
次に例を示します。
- 組織名: operations
- Distributed Cloud インスタンス名: google
- Distributed Cloud ドメイン名: gdch.test
この場合の GKE Identity Service コールバック URL は https://ais-core.operations.google.gdch.test/finish-login です。
次の GKE Identity Service コールバック URL を、GDC ユニバースの各ゾーン用に作成した ADFS OIDC クライアントの許可リストに追加します。
```
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 コールバック URL は https://ais-core.operations.zone-1.google.gdch.test/finish-login です。

以降のセクションで使用する変数を設定します。

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 組織を作成する場合は、グローバルサブネットを作成する前に、追加の前提条件のページをご覧ください。

グローバルルートサブネットは、テナント組織内のすべてのクラスタ（組織のインフラストラクチャクラスタやワークロード VM など）をブートストラップするために各ゾーンに分割されるルート 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

これらのサブネットは、各ゾーンで組織の組織インフラストラクチャクラスタをブートストラップするために必要です。

組織に割り当てる組織名と一致する名前の Namespace が必要です。この Namespace が存在することを確認します。
```
kubectl --kubeconfig GLOBAL_ROOT_ADMIN_KUBECONFIG get namespace
```
この Namespace が存在しない場合は、作成します。
```
kubectl --kubeconfig GLOBAL_ROOT_ADMIN_KUBECONFIG create namespace ORG_NAME
```

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

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

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

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/

組織のルートにある 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

サブネット YAML ファイルをステージングして commit します。
```
git add "IAC_REPO_PATH/iac/infrastructure"
git commit
```

マージリクエストを作成します。

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

コードレビューとマージを待ちます。

1.3.3. ゾーンのルートサブネットを分割する

グローバルルートサブネットは、すべてのゾーンのルート IP アドレス範囲（CIDR）をホストします。ゾーンで IP アドレス範囲を使用するには、まずグローバルルートサブネットを、ゾーンで使用できる小さなサブネットに分割する必要があります。各ゾーンには、少なくとも 1 つのルート 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 という名前の 2 つのゾーンがある場合、org-1 名前空間の OIQ からの infraVPCCIDR（10.0.0.0/16 など）を使用するグローバルルートサブネット 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
  name: infra-vpc-root-cidr
  namespace: org-1
spec:
  ipv4Request:
    cidr: 10.0.0.0/14
  type: Root

GDC プラットフォームにデプロイすると、コントローラは接頭辞長 /16 の infra-vpc-zone1-root-cidr と infra-vpc-zone2-root-cidr という名前の 2 つの子サブネットを自動的に作成します。

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 を設定することを前提としています。このアノテーションは、コントローラを一時停止してグローバルルートサブネットを調整します。これにより、ゾーンのルートサブネットとエニーキャストサブネットを手動で作成できます。

グローバルルートサブネットをゾーンの小さなサブネットに手動で分割するには、次の操作を行います。

ユニバース内のゾーンを一覧表示します。

kubectl --kubeconfig GLOBAL_ROOT_ADMIN_KUBECONFIG get zone -A

ゾーンに適用するルートサブネットの専用 CIDR を確認します。これは、ユニバース内の各ゾーンに対して行います。

専用 CIDR を、ORG_NAME-infra-vpc-zone1-root-cidr.yaml などの YAML ファイルでゾーンのサブネットに割り当てます。

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 ユニバースの各ゾーンで繰り返します。

エニーキャストサブネットに適用するルートサブネットの専用 CIDR を確認します。

専用 CIDR を YAML ファイル（ORG_NAME-infra-vpc-anycast-cidr.yaml など）のエニーキャストサブネットに割り当てます。

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

ゾーンサブネットの YAML ファイルをルート組織の IAC リポジトリにコピーします。たとえば、2 つのゾーンサブネット 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/

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

サブネット YAML ファイルをステージングして commit します。
```
git add "IAC_REPO_PATH/iac/infrastructure"
git commit
```

マージリクエストを作成します。

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

コードレビューとマージを待ちます。

1.3.3.2.1. infra-vpc のゾーンのルートサブネットを手動で分割する例

zone1 と zone2 という名前の 2 つのゾーンがある場合、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）と、専用の 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 という名前の 2 つのゾーンがある場合、org-1 名前空間の OIQ からの orgDataExternalCIDR（10.0.0.0/24 など）を使用するグローバルルートサブネット data-external-root-cidr の例は次のようになります。

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 という名前の 2 つのゾーンがある場合、org-1 名前空間の OIQ から orgAdminExternalCIDR（192.168.1.0/24 など）を使用するグローバルルートサブネット admin-external-root-cidr の例は次のようになります。

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 を使用して組織を作成します。

使用可能なサーバーとサーバータイプのリストを生成します。

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 サーバーがあることを確認してください。

iac リポジトリに移動し、新しい組織のディレクトリ構造を追加します。
```
mkdir -p infrastructure/global/orgs/root/ORG_NAME/
```

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 ルート鍵を生成します。これは、物理 HSM でバックアップされた Thales CipherTrust Manager に保存されるルート鍵です。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"

省略可: バージョン 1.14.2 以降では、ノード間 IPsec 暗号化はデフォルトで無効になっています。この IPsec 暗号化が必要な場合は、Organization カスタムリソース YAML ファイルを編集してアノテーションを追加することで、ノード間 IPsec 暗号化を有効にできます。
```
metadata:
    annotations:
        n2n.security.private.gdc.goog/node-to-node-encryption-disabled: "false"
```
このアノテーションの値が "false" の場合、暗号化が有効になります。

デプロイ内の各ゾーンに 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`	組織管理クラスタとシステムクラスタが自動生成されるときに割り当てるサーバー。事前トレーニング済みの AI/ML API などの VM ベースのワークロードであるグラフィックプロセッシングユニット（GPU）リソースを実行する場合は、組織の作成時に GPU マシンをプロビジョニングする必要があります。詳細については、システムクラスタの GPU サポートを有効にするをご覧ください。
`ADMIN_SERVER`	サーバータイプと、そのサーバータイプに割り当てる組織管理者サーバーの量の Key-Value ペア。サーバーでは混合型はサポートされていません。デフォルト値は `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

生成された YAML ファイルを確認します。ファイルは HOME ディレクトリにあります。
1. 組織の種類を確認します。プロビジョニングできる組織タイプは次の 2 つです。
  - 組織 v1 アーキテクチャ（v1 組織）
  - Org v2 アーキテクチャ（v2 組織）
  デフォルトでは、新しい組織は、機能ゲートの設定で設定されたデプロイタイプに基づいてプロビジョニングされます。
  - PRODUCTION デプロイでは、デフォルトで v2 組織が生成されます。
  - ACCREDITED デプロイは、デフォルトで v1 組織を生成します。
  デプロイタイプのデフォルトの組織タイプをオーバーライドする必要がある場合は、生成された Organization カスタムリソースの spec.compatibilityOptions.architectureOverridePolicy フィールドを、使用する組織タイプに応じて ForceV1 または ForceV2 に更新します。たとえば、次のスニペットは、ACCREDITED デプロイで v2 組織の作成を強制します。
```
...

spec:
...
  compatibilityOptions:
    architectureOverridePolicy: ForceV2

...
```
2. 残りの設定を確認して、ストレージやコンピューティング能力などのコンポーネントが会社のニーズを満たしていることを確認します。
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: --name パラメータを使用して gdcloud organizations config create コマンドで定義した組織名。
- ZONE: デプロイ内の各ゾーンの名前。ゾーン名は {generalRegion}-{regionQualifier}{regionCounter}-{zoneLetter} という形式で派生します。例: us-central1-b。ゾーン属性値の説明については、お客様のオンボーディングアンケートのゾーンのセクションをご覧ください。

新しい組織の 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

新しい組織をルート組織のリソースとして追加します。
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
```
組織の YAML ファイルと kustomize ファイルをステージングして commit します。
```
git add "IAC_REPO_PATH/iac/infrastructure"
git commit
```

マージリクエストを作成します。

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

コードレビューとマージを待ちます。
グローバル組織とゾーン構成が使用可能であることを確認します。
1. グローバル組織が GDC ユニバースで使用可能であることを確認します。
```
kubectl get organization -A
```
  出力は次のようになります。
```
NAMESPACE    NAME    AGE
gpc-system   org     34s
gpc-system   root    14h
```
  注: 新しい組織のサーバーにアクセスできない場合、ネットワーク管理チームと協力して、新しく作成した組織の適切な IP アドレスとポートへの接続を有効にする必要がある場合があります。
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 アドレスを割り当てます。

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

iac リポジトリに移動し、グローバル組織のディレクトリ構造を追加します。
```
cd iac; mkdir -p infrastructure/global/orgs/ORG_NAME/
```
default-vpc-root-cidr サブネット YAML ファイルを新しい組織のディレクトリにある IAC リポジトリにコピーします。
```
cp YAML_FILE_PATH/default-vpc-root-cidr.yaml \
    IAC_REPO_PATH/iac/infrastructure/global/orgs/ORG_NAME/
```

新しく追加された Subnet 定義を使用して、組織フォルダに kustomization.yaml ファイルを作成します。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

組織の YAML ファイルと kustomize ファイルをステージングして commit します。
```
git add "IAC_REPO_PATH/iac/infrastructure"
git commit
```

マージリクエストを作成します。

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

コードレビューとマージを待ちます。

グローバルルート管理クラスタのグローバルサブネットが分割されるのと同様に、default-vpc-root-cidr も分割され、ゾーン組織が IP アドレスを使用できるように各ゾーンに伝播されます。

1.7. 組織管理者の NTPRelay を構成する

root-admin と org-admin の NTPRelay 間の認証を手動で構成する必要があります。

NTP-P0001.3（ルート管理者 -> 組織管理者 NTPRelay 暗号化）に沿って、この組織の暗号化を構成します。

1.8. IAC を使用して IO ID プロバイダを組織に接続する

ADFS ガイドを参照して、新しい組織の ADFS で OIDC クライアントを作成し、OIDC クライアントのクライアント ID とクライアントシークレットをメモします。
組織名を環境変数として設定します。
```
export ORG_NAME=ORG_NAME
```
ORG_NAME が組織の正式名称と一致することを確認します。
ルート管理クラスタの kubeconfig ファイルをエクスポートし、次の kubectl コマンドを実行して、クラスタ名とゾーン名を取得します。
```
export KUBECONFIG=ROOT_ADMIN_KUBECONFIG
kubectl get clusters -A
kubectl get zones -n mz-system
```

組織の 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 で ADFS へのリダイレクトログインリクエストを許可するために必要です。

組織の 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"` のようにします。

新しく作成したファイルを 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

組織の YAML ファイルと kustomize ファイルをステージングして commit します。
```
git add "infrastructure/global"
git add "infrastructure/zonal"
git commit
```
更新を GitLab に push します。
```
git -c http.sslVerify=false push
```
コードレビューとマージを待ちます。
Operator が組織にアクセスできることを確認するには、生成された組織にログインし、次のコマンドを実行して、組織の ClientConfig に ID プロバイダ（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
```

バージョン 1.14.3 では、すべての認証済みユーザーが gdcloud CLI を使用してユニバース内のゾーンを表示できるように、global-zone-viewer ロールを手動で適用する必要があります。ロールとロールバインディングのリソースを適用します。

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. 顧客 ID プロバイダを組織に接続する

顧客の ID プロバイダ（IdP）を組織に接続し、ID を使用して組織にログインするには、次の操作を行います。

組織の作成時に設定された最初の IO 管理者アカウントを使用して CLI からログインします。このアカウントは、組織管理者クラスタの org-iam-admin に自動的にバインドされます。
お客様に、作成する組織用に作成した OIDC または SAML クライアントの許可リストに、次のグローバル AIS コールバック URL を追加するよう依頼します。
```
https://ais-core.ORG_NAME.GDC_URL/finish-login
```
たとえば、GDC のルート URL が .google.gdch.test で、組織の名前が operations の場合、グローバル AIS コールバック URL は https://ais-core.operations.google.gdch.test/finish-login になります。

SAML クライアントを使用している場合は、次のグローバル AIS SAML コールバック URL も許可リストに追加する必要があります。
```
https://ais-core.ORG_NAME.GDC_URL/saml-callback
```
お客様に、各ゾーンで作成した OIDC または SAML クライアントの許可リストに次の AIS コールバック URL を追加するよう依頼します。たとえば、3 つのゾーンのユニバースの場合、ゾーン AIS コールバック URL は次のようになります。
```
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 のルート URL が .google.gdch.test、ゾーン名が zone-1、組織名が operations の場合、AIS コールバック URL は https://ais-core.operations.zone-1.google.gdch.test/finish-login です。

SAML クライアントを使用している場合は、次の AIS SAML コールバック URL を各ゾーンの許可リストに追加する必要があります。
```
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
```
組織のアーキテクチャに応じて、管理クラスタの 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 は、/tmp/${ORG}-management-kubeconfig などの Management API サーバー kubeconfig のパスに置き換えます。
新しい組織のお客様のリクエストチケットから、IdP が OIDC と SAML のどちらを使用しているかを判断します。指定された IdP タイプに対応するガイドに沿って操作します。
- OIDC を使用して設定する
- SAML を使用して設定する
注: OIDC または SAML のいずれかの設定を選択して続行します。これは、お客様の IdP に基づいています。両方を設定しないでください。

OIDC を使用して設定する

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

各フィールドの詳細な説明は次のとおりです。

属性	属性のタイプ	説明
`certificateAuthorityData`	必須	OIDC プロバイダ用の標準の Base64 エンコード形式と PEM 形式の認証局証明書。
`clientID`	必須	OpenID プロバイダへの認証リクエストを行うクライアントアプリケーションの ID。
`clientSecret`	必須	OIDC クライアントアプリケーションと OIDC プロバイダ間の共有シークレット。
`extraParams`	省略可	クエリエンコードされ、認証エンドポイントリクエストとともに送信される Key-Value ペアのカンマ区切りのリスト。
`groupPrefix`	省略可	既存のグループと競合しないようにグループクレームに追加する接頭辞。通常は、複数の ID プロバイダを構成するときに使用されます。すべてのグループ名の前にグループプレフィックスを付ける必要があります。たとえば、グループプレフィックスとして `myprefix-` があり、ID プロバイダに `groupA` という名前のグループがある場合、ポリシーまたはバインディングを追加するときに `myprefix-groupA` をバインドする必要があります。グループ名は `groupsClaim` フィールドで設定されます。注: GDC は、接頭辞とグループ名の間に区切り文字を挿入しません。読みやすくするために、接頭辞の末尾に `-` や `:` などの区切り文字を挿入します。それ以外のモードの場合、`prefix` と `sally@example.com` は `prefixsally@example.com` として識別されます。
`groupsClaim`	省略可	ユーザーのグループ情報を保持する OIDC ID トークンに含まれるクレームの名前。この名前は、OIDC プロバイダのグループメンバーシップ情報を含むクレームの名前と同じである必要があります。
`issuerURI`	必須	認可リクエストが OIDC プロバイダに送信される URL。この URI は、`.well-known/openid-configuration` 内のレベルを指す必要があります。
`scopes`	省略可	`openid` スコープに加えてリクエストされているアクセス権限を指定する識別子のカンマ区切りリスト。
`userClaim`	必須	ユーザー名を保持する OIDC ID トークンのクレームの名前。たとえば、ユーザークレームが `email` の場合、ユーザーは OIDC トークンのユーザーフィールドによって識別されます。 ID トークンがない場合、認証は失敗します。
`userPrefix`	省略可	既存のユーザー名と競合しないように、ユーザークレームの先頭に付加する接頭辞。通常は、複数の ID プロバイダを構成するときに使用されます。たとえば、ユーザークレームが `email` で、ユーザー接頭辞が `prefix-` の場合、ユーザーは `prefix-sally@example.com` として識別されます。ユーザーは `sally@example.com` であり、異なる ID プロバイダを区別するために、接頭辞 `prefix-` はユーザーの接頭辞になります。この表で前述したように、 `groupPrefix` を設定する際は、接頭辞の末尾に区切り文字を挿入することをおすすめします。

省略可: ID プロバイダがカスタム属性を使用している場合は、まず IdP で属性を構成します。次に、ユーザーやグループに関する追加のクレーム（部門や誕生日など）について、identity-provider-config.yaml ファイルの oidc セクションに対応する Key-Value ペアを追加します。ID プロバイダ構成に変更を適用すると、GKE Identity Service はカスタム属性を認識します。カスタム属性の例を次に示します。
```
  "attributeMapping": {
  "attribute.birthday": "assertion.birthday",
  "attribute.department": "assertion.department"
  }
```

ID プロバイダ構成を構成します。

kubectl apply -f identity-provider-config.yaml

さまざまなシステムコンポーネントが再構成されるまで待ちます。
ウェブブラウザで Platform Admin UI コンソールを開いて、構成を確認します。リダイレクトページで [Log in with pa-idp-oidc] を選択します。PA アカウント IdP インスタンスにリダイレクトされ、PA アカウント IdP インスタンスでログインした後、プラットフォーム管理者 UI コンソールページにリダイレクトされる場合、構成は成功しています。それ以外の場合は、identity-provider-config.yaml の値を確認して、前の手順をもう一度適用します。

SAML を使用して設定する

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

各フィールドの詳細な説明は次のとおりです。

属性	属性のタイプ	説明
`idpCertificateDataList`	必須	SAML レスポンスの検証に使用される IDP 証明書。これらの証明書は標準の Base64 エンコード形式と PEM 形式にする必要があります。IdP 証明書のローテーションを容易にするため、サポートされる証明書は 2 つまでです。
`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 レスポンスの属性の名前。

省略可: ID プロバイダがカスタム属性を使用している場合は、まず IdP で属性を構成します。次に、ユーザーやグループに関する追加のクレーム（部門や誕生日など）について、identity-provider-config.yaml ファイルの saml セクションに対応する Key-Value ペアを追加します。ID プロバイダ構成に変更を適用すると、GKE Identity Service はカスタム属性を認識します。カスタム属性の例を次に示します。
```
  "attributeMapping": {
  "attribute.birthday": "assertion.birthday",
  "attribute.department": "assertion.department"
  }
```
ID プロバイダ構成パッチを構成します。
```
kubectl apply -f identity-provider-config.yaml
```
さまざまなシステムコンポーネントが再構成されるまで待ちます。
ウェブブラウザで Platform Admin UI コンソールを開いて、構成を確認します。リダイレクトページで [Log in with pa-idp-oidc] を選択します。PA アカウント IdP インスタンスにリダイレクトされ、PA アカウント IdP インスタンスでログインした後、プラットフォーム管理者 UI コンソールページにリダイレクトされる場合、構成は成功しています。それ以外の場合は、identity-provider-config.yaml の値を確認して、前の手順をもう一度適用します。

ユーザーとグループの接頭辞

異なる IdP のアカウント間で名前の競合が発生しないように、Distributed Cloud のすべての IdP にユーザーとグループの接頭辞を設定する必要があります。この接頭辞は、ユーザー名とグループ名とともに使用され、クラスタ内のロールバインディングのサブジェクト名を連結します。たとえば、名前が jack@example.com のユーザーで、IdP のユーザー接頭辞が example-org-idp- の場合、クラスタ内のサブジェクト名は example-org-idp-jack@example.com になります。

接頭辞の値を決定するには:

階層レベル（ルート、組織、プロジェクト）を含めます。
IdP の名前（adfs、keycloak）を含めます。
接頭辞とユーザー名の間に区切り文字は追加されないため、- などの区切り文字を接尾辞として追加することをおすすめします。

最初の管理者を割り当てる

PA に組織への初回アクセス権を付与するには、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 つ以上の外部ネットワークに接続する必要があります。

このプロセスでは、論理接続を定義する一連のカスタムリソースを構成します。新しい組織に接続を提供する一般的なシナリオは次の 2 つです。

シナリオ 1: 組織を既存の共有インターコネクトに接続する

共有ネットワークの既存の相互接続がある場合は、新しい組織を含めるように AttachmentGroup と RoutePolicy を更新するだけで済みます。

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
```

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 ...

Infrastructure as Code（IaC）プロセスで kubectl apply を使用して、変更を適用します。

シナリオ 2: 新しい専用相互接続を作成する

専用接続の場合は、新しい一連の Interconnect リソースを作成する必要があります。プロセス全体では、5 つのカスタムリソースを順番に作成します。

新しい物理接続ごとに InterconnectLink を作成します。
InterconnectGroup を作成して、物理リンクをバンドルし、新しい組織を許可します。
AttachmentGroup を作成し、entities リストで新しい組織を指定します。
この専用接続のインバウンドとアウトバウンドの IP プレフィックスを許可する RoutePolicy を作成します。
1 つ以上の InterconnectAttachment リソースを作成して、VLAN と BGP セッションを定義します。

これらの各リソースの包括的な例と詳細な手順については、インターコネクトを構成するのドキュメントをご覧ください。

1.11 Alertmanager Webhook を設定して ServiceNow に接続する

MON-T0016 の手順に沿って、アラートマネージャーの Webhook を ServiceNow に接続してインシデントを作成します。

1.12 組織の課金料金表を構成する

組織の Billing サブコンポーネントでは、請求対象のプロダクトまたはサービスがカスタムリソース SKUDescription で構成されている必要があります。単一の SKUDescription は、請求対象となる単一の商品またはサービスとその価格を表します。したがって、SKUDescription オブジェクトのコレクションは、組織の価格表と見なすことができます。次の手順では、IAC で組織の価格表を構成します。

1.12.1 料金表を入手する

組織の SKUDescription 価格表リソースがまだない場合は、プログラム管理オフィス（PMO）に連絡して価格表を入手してください。料金表は、SKUDescription リソースを含む一連の YAML ファイルである必要があります。

1.12.2 価格表が共有されているかどうかを判断する

価格表は、すべての組織で共有することも、組織ごとに構成することもできます。価格表が共有されているかどうかは、PMO にお問い合わせください。

価格表が共有されている場合は、common-data 共有 IAC フォルダに価格表を配置します。

この組織が最初に作成された組織でない場合、価格表は共有 common-data フォルダにすでに存在している可能性があります。価格表が存在する場合は、ステップ 2 ～ 4 が完了していることを確認し、ステップ 5 に進みます。
価格表の共有フォルダを作成します。
```
mkdir -p IAC_REPO_PATH/iac/infrastructure/common-data/bil/skudescriptions/
```
IAC_REPO_PATH は、IAC リポジトリのパスに置き換えます。
SKUDescription の料金表 YAML リソースをこのフォルダに保存します。その後、skudescriptions フォルダには、エリアごとに分割された YAML ファイルが含まれている必要があります。課金ユースケースに合わせてフォルダ構造と YAML ファイルを構成します。
- パートナー運営の請求: Google はパートナーに請求します。SKUDescription リソースを partner-billing-system Namespace に配置します。
- お客様への請求: パートナー様がエンドユーザーに請求します。SKUDescription リソースを billing-system Namespace に配置します。
次の例は、顧客の請求とパートナーが運営する請求モデルの両方のファイル構造を示しています。モデルごとに、コンピューティングとストレージの 2 つのサービスが表示され、各サービスに 2 つの 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
```

すべての SKUDescription 価格表 YAML ファイルを含むディレクトリに kustomization.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

ORG_CLUSTER 環境変数をエクスポートします。
- v1 組織の場合は、次のコマンドを実行します。
```
export ORG_CLUSTER=ORG_ADMIN_CLUSTER_NAME
```
- v2 組織の場合は、次のコマンドを実行します。
```
export ORG_CLUSTER=ORG_INFRA_CLUSTER_NAME
```
組織に 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 を組織の管理者クラスタの名前に置き換えます。

組織に共通の価格表を含めます。

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

YAML ファイルをステージングして commit し、ファイルをカスタマイズします。
```
cd IAC_REPO_PATH
git add "iac"
git commit
```
更新を GitLab に push します。
```
git -c http.sslVerify=false push
```
コードレビューとマージを待ちます。
対応する課金モデルの 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 組織固有の料金表

価格表が組織に固有の場合は、価格表を組織クラスタフォルダに配置する必要があります。

組織クラスタに 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

SKUDescription の料金表 YAML リソースをこのフォルダに保存します。その後、skudescriptions フォルダには、エリアごとに分割された YAML ファイルが必要です。次の例では、コンピューティングとストレージの 2 つのサービスがあり、それぞれに 2 つの YAML ファイルがあります。
```
.
├── compute
│   ├── compute-sku1.yaml
│   └── compute-sku2.yaml
└── storage
    ├── storage-sku1.yaml
    └── storage-sku2.yaml
```

すべての 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

組織のルートにある 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
```
YAML ファイルと kustomize ファイルをステージングして commit します。
```
cd IAC_REPO_PATH
git add "iac"
git commit
```
更新を GitLab に push します。
```
git -c http.sslVerify=false push
```
コードレビューとマージを待ちます。
指定されたクラスタに 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 始める前に

続行する前に、セキュリティ管理者に次の必要なロールを付与するよう依頼してください。これらのロールは、プロジェクトレベルの課金の場合はプロジェクト Namespace に、組織レベルの課金の場合はプラットフォーム Namespace にバインドされます。

組織の請求先アカウント管理者: BillingAccount リソースの作成、管理、バインドを行います。セキュリティ管理者に organization-billing-account-admin ロールを付与するよう依頼します。
組織の請求先アカウントユーザー: BillingAccount リソースの読み取り、一覧表示、バインドを行います。セキュリティ管理者に organization-billing-account-user ロールを付与するよう依頼します。
組織の請求先アカウント管理者: BillingAccountBinding リソースの読み取り、一覧表示、作成、更新を行います。セキュリティ管理者に organization-billing-manager ロールを付与するよう依頼します。

1.14.2.2 新しい請求先アカウントを作成する

請求先アカウントは、name と namespace によって一意に識別されます。請求先アカウントを作成するには、カスタムリソースを使用して name と namespace を確立します。

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"。
お支払い構成のタイプを確認します。Distributed Cloud 請求先アカウントには、次のいずれかの支払い構成が必要です。
- cloudBillingConfig: デフォルトの支払い構成。この構成には、Cloud 請求先アカウント ID が保存されます。
- customConfig: パートナーが組織に請求するための支払い構成を保存するためのカスタム構成。customConfig は、Key-Value 文字列のディクショナリをサポートしています。必須のキーは 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 ファイルは、cloudBillingConfig 構成を含む完全な BillingAccount リソースを示しています。
```
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"
```
カスタムリソースの YAML ファイルを保存します。kubectl CLI を実行して、課金対象の特定の組織またはプロジェクトの組織クラスタ内のリソースを適用します。
```
kubectl --kubeconfig $ORG_KUBECONFIG apply -f billingaccount.yaml
```

1.14.2.3 組織を請求先アカウントにリンクする

組織を BillingAccount にリンクする手順は次のとおりです。

YAML ファイル billingaccountbinding.yaml に次の内容を追加します。
- billingAccountRef セクションで、リンクする BillingAccount の name フィールドのコンテンツを name フィールドに入力します。
- metadata セクションで、namespace フィールドに BillingAccount リソースの同じフィールドのコンテンツを入力します。この例では、組織の Namespace は platform です。
```
apiVersion: billing.gdc.goog/v1
kind: BillingAccountBinding
metadata:
  name: billing
  namespace: platform
spec:
  billingAccountRef:
    name: BIL_ACCOUNT_NAME
    namespace: platform
```

billingaccountbinding.yaml ファイルを適用します。

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

1.14.3 始める前に

続行する前に、セキュリティ管理者に billing-system Namespace の組織管理者クラスタで請求モニタリング（bil-monitor）ロールを付与するよう依頼してください。この権限により、検証に関連するリソースを読み取ることができます。

1.14.4 請求開始時間をオーバーライドする

次のパスで 2 つの 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。
  - 必要なサブディレクトリがない場合は、ファイルごとに作成します。

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

YAML ファイルを保存して infrastructure/zonal/zones/ZONE_NAME/root-admin/components/bil/ORG_NAME フォルダに保存します。
必要な kustomization ファイルとともに YAML ファイルを含む 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.4 に沿って対応します。- 1.9. バックアップサイト用の別の組織を作成します。

1.17. 組織の作成に関するトラブルシューティング

1.17.1. デプロイされたすべてのリソースが正常で存在することを確認する

組織の作成プロセスでは、複数の Kubernetes クラスタに複数のリソースが作成されます。まず、デプロイされたリソースを確認し、良好な状態であることを確認します。以降のセクションでは、operations という名前の組織に対して作成されたリソースの概要について説明します。

1.17.2. ルート管理クラスタにデプロイされたすべてのリソースを確認する

次の手順を完了して、ルート管理クラスタ内のすべてのリソースが正常で存在することを確認します。

IAM-R0004 に従って、ルート管理クラスタに必要な kubeconfig 構成を取得します。次の環境変数とエイリアスをこの検証手順に設定してください。
```
export KUBECONFIG=ROOT_ADMIN_KUBECONFIG
export ORG="ORG_NAME"
alias k=kubectl
```
ファイアウォールリソースが使用可能であることを確認します。
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
```

ストレージリソースが使用可能であることを確認します。

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

HSM リソースが使用可能であることを確認します。

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

HSM クラスタを確認します。

k get hsmcluster -n gpc-system

出力は次のようになります。

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

HSM テナントを確認します。

k get hsmtenant -A

出力は次のようになります。

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

マシンとノードのリソースが使用可能であることを確認します。

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

NodePoolClaim リソースを確認します。

k get nodepoolclaims -A

出力は次のようになります。

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

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

ベアメタルクラスタを確認します。

k get baremetalclusters -A

出力は次のようになります。

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

ベアメタルマシンを確認します。

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

サーバーを確認します。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

Kubernetes クラスタを確認します。

k get cluster -A

出力は次のようになります。

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

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. 組織管理クラスタにデプロイされたすべてのリソースを確認する

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 baremetalclusters -A

出力は次のようになります。

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

ベアメタルマシンを確認します。

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

マシンを確認します。

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

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

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

Kubernetes クラスタを確認します。

ka get clusters -A

出力は次のようになります。

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

ノードを確認します。

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

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. システムユーザークラスタにデプロイされたすべてのリソースを確認する

次の手順に沿って、システムクラスタ内のすべてのリソースが正常に存在することを確認します。

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}"

マシンとノードのリソースが使用可能であることを確認します。

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

ノードを確認します。

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

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 組織の組織インフラストラクチャクラスタ内のすべてのリソースが正常に存在することを確認します。v1 組織がある場合は、このセクションをスキップします。

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}"

ノードと API サーバーが正常な状態であることを確認します。

ノードを確認します。

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

kubeconfig の Secret を確認します。

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

出力は次のようになります。

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

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. すべての組織リソースが調整されていることを確認する

ターゲットが 2 つのゾーン（zone-1 と zone-2）を持つ operations 組織の作成であると仮定して、グローバルルート管理クラスタとゾーンルート管理クラスタ内の組織関連のリソースがすべて正常で存在することを確認するには、次の操作を行います。

グローバルルート管理者 API にアクセスするに沿って、グローバル API サーバーにアクセスし、グローバルルート管理者 API kubectl に次のエイリアスを使用します。
```
alias kga='kubectl --kubeconfig ROOT_ADMIN_KUBECONFIG
export ORG="ORG_NAME"
```

グローバル組織リソースが使用可能であることを確認します。

グローバル Organization リソースを確認します。

kga get organization -A

出力は次のようになります。

NAMESPACE    NAME         READY
gpc-system   operations
gpc-system   root

グローバル 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

グローバル OrganizationZonalConfig リソースを確認します。

kga get organizationzonalconfig -A

出力は次のようになります。

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

グローバル 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

ゾーンルート管理クラスタの kubeconfig 構成エイリアスを設定します。
```
alias ka='kubectl --kubeconfig /root/GDC_VERSION/root-admin/root-admin-kubeconfig'
```

ゾーン組織リソースが使用可能であることを確認します。

Organization リソースを確認します。

ka get organization -A

出力は次のようになります。

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

OrganizationReplica リソースを確認します。

ka get organizationreplica -A

出力は次のようになります。

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

OrganizationZonalConfigReplica リソースを確認します。

ka get organizationzonalconfigreplica -A

出力は次のようになります。

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

組織へのアクセスをすべてのアドレスに許可するの手順に沿って、ソースサイトからバックアップサイトへの組織管理クラスタで DCI トラフィックを許可します。

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`	グローバルルート

1. お客様の組織を作成する コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。

1.1. 始める前に

1.2. OC IT ADFS で OIDC クライアントを作成する

1.3 グローバル サブネットを作成し、ゾーンごとに分割する

1.3.1. OIQ の CIDR 範囲を定義する

1.3.2. グローバル ルート管理者 API サーバーにグローバル サブネットを作成する

1.3.3. ゾーンのルート サブネットを分割する

1.3.3.1. ゾーンのルート サブネットを自動的に分割する

1.3.3.2. ゾーンのルート サブネットを手動で分割する

1.3.3.2.1. infra-vpc のゾーンのルートサブネットを手動で分割する例

1.3.3.2.2. データ ネットワーク セグメントのゾーンのルート サブネットを手動で分割する例

1.3.3.2.3. 管理者ネットワーク セグメントのゾーンのルートサブネットを手動で分割する例

1.4. IAC を使用して組織を作成する

1.5. グローバル組織 API サーバーにグローバル サブネットを作成する

1.7. 組織管理者の NTPRelay を構成する

1.8. IAC を使用して IO ID プロバイダを組織に接続する

1.9. 顧客 ID プロバイダを組織に接続する

OIDC を使用して設定する

SAML を使用して設定する

ユーザーとグループの接頭辞

最初の管理者を割り当てる

1.10 組織のネットワーク接続を確立する

シナリオ 1: 組織を既存の共有インターコネクトに接続する

シナリオ 2: 新しい専用相互接続を作成する

1.11 Alertmanager Webhook を設定して ServiceNow に接続する

1.12 組織の課金料金表を構成する

1.12.1 料金表を入手する

1.12.2 価格表が共有されているかどうかを判断する

1.12.2.1 共有料金表

1.12.2.2 組織固有の料金表

1.13 請求の定期的な使用状況を作成する

1.14 組織の課金を構成する

1.14.1 請求開始時間を取得する

1.14.2 請求先お支払いアカウントを組織にマッピングする

1.14.2.1 始める前に

1.14.2.2 新しい請求先アカウントを作成する

1.14.2.3 組織を請求先アカウントにリンクする

1.14.3 始める前に

1.14.4 請求開始時間をオーバーライドする

1.14.5 請求開始時刻を検証する

1.15 組織の管理クラスタでオブジェクト ストレージ プロキシのネットワーク ポリシーを構成する

1.15.1 ネットワーク ポリシーの YAML ファイルを作成する

1.15.2 ネットワーク ポリシーを組織の管理クラスタに適用する

1.16. バックアップ サイトを作成する

1.17. 組織の作成に関するトラブルシューティング

1.17.1. デプロイされたすべてのリソースが正常で存在することを確認する

1.17.2. ルート管理クラスタにデプロイされたすべてのリソースを確認する

1.17.3. v1 組織クラスタにデプロイされたすべてのリソースを確認する

1.17.3.1. 組織管理クラスタにデプロイされたすべてのリソースを確認する

1.17.3.2. システム ユーザー クラスタにデプロイされたすべてのリソースを確認する

1.17.4. v2 組織クラスタにデプロイされたすべてのリソースを確認する

1.17.5. すべての組織リソースが調整されていることを確認する

1. お客様の組織を作成する

1.3 グローバルサブネットを作成し、ゾーンごとに分割する

1.3.2. グローバルルート管理者 API サーバーにグローバルサブネットを作成する

1.3.3. ゾーンのルートサブネットを分割する

1.3.3.1. ゾーンのルートサブネットを自動的に分割する

1.3.3.2. ゾーンのルートサブネットを手動で分割する

1.3.3.2.2. データネットワークセグメントのゾーンのルートサブネットを手動で分割する例

1.3.3.2.3. 管理者ネットワークセグメントのゾーンのルートサブネットを手動で分割する例

1.5. グローバル組織 API サーバーにグローバルサブネットを作成する

1.15 組織の管理クラスタでオブジェクトストレージプロキシのネットワークポリシーを構成する

1.15.1 ネットワークポリシーの YAML ファイルを作成する

1.15.2 ネットワークポリシーを組織の管理クラスタに適用する

1.16. バックアップサイトを作成する

1.17.3.2. システムユーザークラスタにデプロイされたすべてのリソースを確認する