Cette page a été traduite par l'API Cloud Translation.

1. Créer une organisation client

Durée estimée : 3 heures

Profil de compétences : ingénieur de déploiement

En tant qu'opérateur, vous pouvez créer une organisation pour permettre aux clients d'accéder à l'infrastructure de la plate-forme. Pour obtenir les autorisations nécessaires pour créer une organisation, demandez à votre Administrateur de sécurité de vous attribuer le rôle d'administrateur de l'organisation.

La ressource Organization est le nœud racine de la hiérarchie des ressources Google Distributed Cloud (GDC) air-gapped. Toutes les ressources appartenant à un groupe d'organisation sont regroupées dans le nœud d'organisation. Cela permet de centraliser la visibilité et le contrôle sur l'ensemble des ressources appartenant à une organisation.

Pour en savoir plus sur les organisations, consultez la présentation des organisations.

1.1. Avant de commencer

Assurez-vous d'avoir installé les éléments suivants :

Un navigateur sur votre système.
Interface de ligne de commande (CLI) Git.
La CLI kubectl.
gdcloud CLI.

1.2. Créer un client OIDC dans OC IT ADFS

Consultez les instructions de configuration d'ADFS OIDC pour créer un client OpenID Connect (OIDC) dans ADFS afin que l'opérateur puisse accéder à l'organisation que vous allez créer. Notez l'ID client et le code secret du client OIDC. Vous ne devez pas réutiliser le client pour les connexions à d'autres clusters, tels que le cluster d'administrateur racine et d'autres clusters d'administrateur d'organisation, ni à des services tels que ServiceNow.
Ajoutez l'URL de rappel GKE Identity Service suivante à la liste d'autorisation dans le client ADFS OIDC que vous avez créé pour l'organisation que vous allez créer :
```
https://ais-core.ORG_NAME.GDC_URL.GDC_DOMAIN/finish-login
```
Exemple :
- Nom de l'organisation : operations
- Nom de l'instance Distributed Cloud : google
- Nom de domaine Distributed Cloud : gdch.test
Dans ce cas, l'URL de rappel GKE Identity Service est https://ais-core.operations.google.gdch.test/finish-login.
Ajoutez l'URL de rappel GKE Identity Service suivante à la liste d'autorisation dans le client ADFS OIDC que vous avez créé pour chaque zone de votre univers GDC :
```
https://ais-core.ORG_NAME.ZONE.GDC_URL.GDC_DOMAIN/finish-login
```
Exemple :
- Nom de l'organisation : operations
- Nom de la zone : zone-1
- Nom de l'instance Distributed Cloud : google
- Nom de domaine Distributed Cloud : gdch.test
Dans ce cas, l'URL de rappel GKE Identity Service est https://ais-core.operations.zone-1.google.gdch.test/finish-login.

Définissez les variables suivantes à utiliser dans les sections suivantes :

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

Remplacez les variables par les valeurs suivantes :

Variable	Définition
`ADFS_CERT_BASE64`	Fichier `adfs.pem` encodé en base64.
`ADFS_CLIENT_ID`	Identifiant client ADFS.
`ADFS_CLIENT_SECRET`	Clé secrète partagée du client ADFS.
`ADFS_ISSUER_URI`	URI de l'émetteur ADFS. Pour obtenir l'URI, vérifiez le chemin d'accès `/adfs/.well-known/openid-configuration` du serveur ADFS : `curl -s https://fs.opscenter.local/adfs/.well-known/openid-configuration \| jq '.issuer' "https://fs.opscenter.local/adfs"` La valeur est généralement `https://adfs.domain.com/adfs`.

1.3 Créer des sous-réseaux mondiaux et les diviser pour chaque zone

Avant de créer une organisation, vous devez créer les sous-réseaux racine globaux et les diviser pour chaque zone avec le sous-réseau de l'API publique de gestion des adresses IP (IPAM). Si vous créez une organisation v2 dans une zone qui possédait auparavant une organisation v1, veillez à consulter la page des conditions préalables supplémentaires avant de créer vos sous-réseaux mondiaux.

Les sous-réseaux racine globaux hébergent le pool de plages d'adresses IP racine (CIDR) qui est divisé dans chaque zone pour amorcer tous les clusters de l'organisation locataire, y compris le cluster d'infrastructure de l'organisation et les VM de charge de travail. Une petite partie de la plage d'adresses IP est également mise à la disposition des sous-réseaux racine en tant que pool d'adresses IP anycast. Vous pouvez attribuer automatiquement des CIDR dédiés à chaque zone à l'aide d'un contrôleur ou fournir manuellement des CIDR à chaque zone.

Pour amorcer une organisation, vous avez besoin de la plage d'adresses IP internes saisie dans le questionnaire d'entrée de l'organisation (OIQ). Vous devez utiliser ces plages d'adresses IP pour créer le sous-réseau racine global dans le serveur d'API global.

Vous devez créer des sous-réseaux racine différents pour chaque serveur d'API global. Le mappage du champ OIQ, du nom du sous-réseau racine global et du serveur d'API global est fourni dans la section suivante.

1.3.1. Définir la plage CIDR pour OIQ

Les plages CIDR ne peuvent pas se chevaucher entre elles ni avec zone-infra-cidr.

Le zone-infra-cidr existe dans chaque zone et peut être récupéré à partir du questionnaire d'accueil des clients si le client l'a défini.

Pour récupérer le zone-infra-cidr, exécutez la commande suivante :

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

Voici un exemple de résultat 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

Dans cet exemple, zone-infra-cidr est 192.0.2.0/24. Par conséquent, aucun champ de l'OIQ ne doit chevaucher 192.0.2.0/24.

Le tableau suivant présente les champs de l'OIQ et leurs valeurs minimales par défaut correspondantes :

Champ OIQ	Description	Taille minimale requise	Taille minimale par zone pour l'organisation	Nom du sous-réseau racine global	Serveur d'API mondial
`infraVPCCIDR`	Charges de travail système, y compris la console d'organisation, les API de gestion et les services propriétaires.	$ 15 - \lceil \log_2(ZoneNumber) \rceil $	16	`infra-vpc-root-cidr`	Racine globale
`defaultVPCCIDR`	Charges de travail et points de terminaison utilisateur dans le VPC par défaut, répartis dans les zones.	$ 16 - \lceil \log_2(ZoneNumber) \rceil $	16	`default-vpc-root-cidr`	Organisation mondiale
`orgAdminExternalCIDR`	Charges de travail et points de terminaison du cluster de périmètre qui gèrent le trafic administratif entre le réseau externe et l'organisation.	$ 22 - \lceil \log_2(ZoneNumber) \rceil $	23	`admin-external-root-cidr`	Racine globale
`orgDataExternalCIDR`	Charges de travail et points de terminaison accessibles aux utilisateurs en externe, tels que les équilibreurs de charge externes et les NAT de sortie.	$ 22 - \lceil \log_2(ZoneNumber) \rceil $	23	`data-external-root-cidr`	Racine globale

Si vous ne disposez pas d'un nombre suffisant d'adresses IP par rapport au minimum suggéré par défaut, vous devez suivre la procédure de fractionnement manuel pour créer les sous-réseaux pour chaque zone.

Tenez compte des limites suivantes pour les plages de sous-réseaux IPv4 :

orgDataExternalCIDR, orgAdminExternalCIDR, infraVPCCIDR et defaultVPCCIDR ne doivent pas se chevaucher, ni chevaucher d'autres plages allouées au sein de l'organisation ni aucune plage IPv4 dans les réseaux appairés. Les CIDR correspondants proviennent de l'espace d'adressage privé RFC 1918.

Réseaux appairés : il peut s'agir de sous-réseaux annoncés avec des réseaux externes via des pièces jointes d'interconnexion ou de sous-réseaux appairés avec d'autres VPC de la même organisation.
Si des organisations partagent les mêmes ressources AttachmentGroup d'interconnexion, les valeurs orgDataExternalCIDR et orgAdminExternalCIDR doivent être uniques. Sinon, le chevauchement avec d'autres organisations est autorisé.

1.3.2. Créer des sous-réseaux mondiaux dans le serveur d'API de l'administrateur racine mondial

Avant de créer une organisation, vous devez créer les sous-réseaux suivants dans le serveur d'API d'administrateur racine global :

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

Ces sous-réseaux sont nécessaires pour amorcer le cluster d'infrastructure de l'organisation dans chaque zone.

Vous devez disposer d'un espace de noms dont le nom correspond à celui que vous attribuerez à votre organisation. Vérifiez que cet espace de noms existe :
```
kubectl --kubeconfig GLOBAL_ROOT_ADMIN_KUBECONFIG get namespace
```
Si cet espace de noms n'existe pas, créez-le :
```
kubectl --kubeconfig GLOBAL_ROOT_ADMIN_KUBECONFIG create namespace ORG_NAME
```

Créez le fichier YAML du sous-réseau infra-vpc-root-cidr, par exemple 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

Créez le fichier YAML du sous-réseau admin-external-root-cidr, par exemple 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

Créez le fichier YAML du sous-réseau data-external-root-cidr, par exemple 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

Copiez les fichiers YAML de sous-réseau infra-vpc-root-cidr, admin-external-root-cidr et data-external-root-cidr dans le dépôt IAC pour l'organisation racine :

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/

Assurez-vous que le fichier kustomization.yaml à la racine de l'organisation contient les définitions Subnet nouvellement ajoutées. Vérifiez 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

Organisez et validez les fichiers YAML de sous-réseau :

git add "IAC_REPO_PATH/iac/infrastructure"
git commit

Créez une requête de fusion :

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

Attendez que le code soit examiné et fusionné.

1.3.3. Fractionner les sous-réseaux racine pour les zones

Les sous-réseaux racine mondiaux hébergent la plage d'adresses IP racine (CIDR) pour toutes les zones. Pour que les zones puissent utiliser la plage d'adresses IP, les sous-réseaux racine globaux doivent d'abord être divisés en sous-réseaux plus petits. Chaque zone doit comporter au moins une plage d'adresses IP racine.

IPAM dispose d'un contrôleur global qui divise automatiquement le sous-réseau racine global en sous-réseaux plus petits pour les zones existantes. Les administrateurs peuvent déléguer aux contrôleurs IPAM la division automatique du sous-réseau de la zone s'ils ne se soucient pas du bloc CIDR exact utilisé par une zone donnée. Le contrôleur surveille la création du sous-réseau racine global et crée un sous-réseau pour chaque zone avec une longueur de préfixe par défaut fixe.

Sous-réseau de la zone racine	Longueur de préfixe fixe par défaut
`defaultZoneInfraVPCSubnetSize`	16
`defaultZoneAdminVRFSubnetSize`	23
`defaultZoneDataVRFSubnetSize`	23
`defaultZoneDefaultVPCSubnetSize`	16
`defaultAnycastSubnetSize`	26

Les sous-réseaux racine globaux doivent avoir des noms fixes si vous souhaitez que les contrôleurs IPAM divisent automatiquement le sous-réseau de la zone :

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

Si vous définissez l'annotation ipam.gdc.goog/pause-auto-division: true pour vos ressources Subnet, vous devez définir manuellement le bloc CIDR exact utilisé par une zone donnée. Si vous créez les sous-réseaux racine mondiaux avec des noms différents, l'annotation ipam.gdc.goog/pause-auto-division n'a aucun effet et les sous-réseaux mondiaux ne seront pas divisés automatiquement.

1.3.3.1. Diviser automatiquement les sous-réseaux racine pour les zones

Le contrôleur mondial divise automatiquement le sous-réseau racine mondial en sous-réseaux plus petits pour les zones existantes. Par exemple, examinez le workflow suivant pour comprendre comment le contrôleur divise le sous-réseau racine global en sous-réseaux plus petits pour les zones existantes :

Si deux zones sont nommées zone1 et zone2, un exemple de sous-réseau racine global infra-vpc-root-cidr utilisant infraVPCCIDR, tel que 10.0.0.0/16, à partir de l'OIQ dans l'espace de noms org-1 se présente comme suit :

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

Lorsqu'il est déployé sur la plate-forme GDC, le contrôleur crée automatiquement deux sous-réseaux enfants nommés infra-vpc-zone1-root-cidr et infra-vpc-zone2-root-cidr avec la longueur de préfixe /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. Répartir manuellement les sous-réseaux racine pour les zones

Cette section suppose que vous avez défini l'annotation ipam.gdc.goog/pause-auto-division: true lors de la création des sous-réseaux racine globaux dans le serveur d'API d'administration racine globale. Cette annotation suspend le contrôleur pour réconcilier ces sous-réseaux racine globaux, ce qui vous permet de créer manuellement le sous-réseau racine et le sous-réseau anycast d'une zone.

Pour diviser manuellement le sous-réseau racine global en sous-réseaux plus petits pour les zones, procédez comme suit :

Répertoriez les zones de votre univers :

kubectl --kubeconfig GLOBAL_ROOT_ADMIN_KUBECONFIG get zone -A

Confirmez le CIDR dédié du sous-réseau racine que vous souhaitez appliquer à votre zone. Faites cela pour chaque zone de votre univers.

Attribuez le bloc CIDR dédié au sous-réseau de votre zone dans un fichier YAML, tel que ORG_NAME-infra-vpc-zone1-root-cidr.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

Répétez cette étape pour chaque zone de votre univers GDC.

Confirmez le CIDR dédié du sous-réseau racine que vous souhaitez appliquer au sous-réseau anycast.

Attribuez le CIDR dédié au sous-réseau anycast dans un fichier YAML, tel que 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

Copiez les fichiers YAML de sous-réseau zonal dans le dépôt IAC pour l'organisation racine. Par exemple, si vous aviez deux fichiers YAML de sous-réseau zonal :

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

Organisez et validez les fichiers YAML de sous-réseau :

git add "IAC_REPO_PATH/iac/infrastructure"
git commit

Créez la demande de fusion :

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

Attendez que le code soit examiné et fusionné.

1.3.3.2.1. Exemple de fractionnement manuel des sous-réseaux racine pour les zones dans infra-vpc

Si deux zones sont nommées zone1 et zone2, un exemple de sous-réseau racine global infra-vpc-root-cidr utilisant infraVPCCIDR, tel que 192.0.2.0/24, à partir de l'OIQ dans l'espace de noms org-1 se présente comme suit :

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

Créez manuellement le sous-réseau pour chaque zone nommée infra-vpc-zone1-root-cidr et infra-vpc-zone2-root-cidr, ainsi que le sous-réseau anycast infra-vpc-anycast-cidr avec le CIDR dédié de votre choix :

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

Veillez à ajouter tous les fichiers YAML de sous-réseau au dépôt IAC.

1.3.3.2.2. Exemple de répartition manuelle des sous-réseaux racine pour les zones du segment de réseau de données

Si deux zones sont nommées zone1 et zone2, un exemple de sous-réseau racine global data-external-root-cidr utilisant orgDataExternalCIDR, tel que 10.0.0.0/24, à partir de l'OIQ dans l'espace de noms org-1 se présente comme suit :

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

Créez manuellement le sous-réseau pour chaque zone nommée data-external-zone1-root-cidr et data-external-zone2-root-cidr, ainsi que le sous-réseau anycast data-global-anycast-cidr avec le CIDR dédié de votre choix :

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

Veillez à ajouter tous les fichiers YAML de sous-réseau au dépôt IAC.

1.3.3.2.3. Exemple de fractionnement manuel des sous-réseaux racine pour les zones du segment de réseau d'administration

Si deux zones sont nommées zone1 et zone2, un exemple de sous-réseau racine global admin-external-root-cidr utilisant orgAdminExternalCIDR, tel que 192.168.1.0/24, à partir de l'OIQ dans l'espace de noms org-1 se présente comme suit :

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

Créez manuellement le sous-réseau pour chaque zone nommée admin-external-zone1-root-cidr et admin-external-zone2-root-cidr, ainsi que le sous-réseau anycast admin-global-anycast-cidr avec le CIDR dédié de votre choix :

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

Veillez à ajouter tous les fichiers YAML de sous-réseau au dépôt IAC.

1.4. Créer une organisation avec IAC

Utilisez IAC pour créer une organisation :

Générez une liste des serveurs et des types de serveurs disponibles :

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

Le résultat ressemble à celui de l'exemple ci-dessous.

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

Lorsque vous spécifiez --server-quota et --admin-server ultérieurement, assurez-vous d'avoir suffisamment de serveurs available pour répondre à la demande.

Accédez au dépôt iac et ajoutez la structure de répertoire pour la nouvelle organisation :
```
mkdir -p infrastructure/global/orgs/root/ORG_NAME/
```

Créez une ressource personnalisée Organization :

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

Exemple :

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

Remplacez les variables suivantes :

Variable	Définition
`ORG_NAME`	Nom de l'organisation. Le nom d'une organisation doit répondre aux critères suivants : comporter entre 3 et 19 lettres ASCII minuscules, chiffres ou traits d'union ; Commencez par une lettre. ne se terminent pas par un trait d'union ; ne pas se terminer par la chaîne `-system` ;
`LOG_RETENTION_POLICY`	Configuration des durées de conservation des journaux d'audit, des journaux opérationnels et des métriques (en jours).
`KMS_ROOT_KEY_TYPE`	Cette configuration contient le type de clé racine choisi pour le KMS d'une organisation. Chaque service KMS dispose d'une clé racine pour chiffrer les clés générées par le KMS. Par défaut, le KMS génère une clé racine CTM, une clé racine stockée dans Thales CipherTrust Manager et sauvegardée par un HSM physique. Vous pouvez également choisir une clé racine logicielle stockée en tant que secret Kubernetes. Transmettez `ctm-root` ou `local-root` pour `kmsRootKeyType`.

Voici un exemple de fichier YAML de ressource personnalisée Organization généré :

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"

Facultatif : Dans la version 1.14.2 et ultérieures, le chiffrement IPsec de nœud à nœud est désactivé par défaut. Si ce chiffrement IPsec est requis, vous pouvez l'activer de nœud à nœud en modifiant le fichier YAML de ressource personnalisée Organization et en ajoutant une annotation :
```
metadata:
    annotations:
        n2n.security.private.gdc.goog/node-to-node-encryption-disabled: "false"
```
Si vous définissez la valeur de cette annotation sur "false", le chiffrement est activé.

Créez une ressource personnalisée OrganizationZonalConfig pour chaque zone du déploiement :

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

Exemple :

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

Aperçu : GDC permet de créer des organisations asymétriques dans les zones en tant que fonctionnalité en aperçu à partir de la version 1.14.4. Par exemple, chaque ressource personnalisée OrganizationZonalConfig peut être différente pour chaque zone. De même, vous pouvez choisir de ne pas créer de ressource personnalisée OrganizationZonalConfig pour une zone existante.

Remplacez les variables suivantes :

Variable	Définition
`ORG_NAME`	Nom de l'organisation. Le nom d'une organisation doit répondre aux critères suivants : comporter entre 3 et 30 lettres ASCII minuscules, chiffres ou traits d'union. Commencez par une lettre. ne se terminent pas par un trait d'union ; ne pas se terminer par la chaîne `-system` ;
`ZONES`	Noms des zones du déploiement.
`GDC_VERSION`	Version du système GDC pour lequel créer l'organisation.
`SERVER_QUOTA`	Nombre de serveurs à allouer au cluster d'administrateur de l'organisation et au cluster système lorsqu'ils sont générés automatiquement. Si vous prévoyez d'exécuter des ressources de processeur graphique (GPU) qui sont des charges de travail basées sur des VM, comme des API d'intelligence artificielle et de machine learning (IA/ML) préentraînés, vous devez provisionner des machines GPU lorsque vous créez une organisation. Pour en savoir plus, consultez la section Activer la prise en charge des GPU pour les clusters système.
`ADMIN_SERVER`	Paire clé-valeur du type de serveur et du nombre de serveurs d'administrateur de l'organisation à allouer pour ce type de serveur. Les types mixtes ne sont pas acceptés pour les serveurs. La valeur par défaut est `o1-standard1-64-gdc-metal: 3`.
`STORAGE_SIZE`	Taille des différents types de stockage à attribuer à l'organisation. La taille minimale du stockage par blocs pour une organisation est de 250 Gio, qui est définie avec l'indicateur `BlockStandard`.

Voici un exemple de fichier YAML de ressource personnalisée OrganizationZonalConfig généré :

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

Examinez les fichiers YAML générés. Les fichiers se trouvent dans le répertoire HOME.
1. Confirmez le type d'organisation. Vous pouvez provisionner deux types d'organisations :
  - Architecture de l'organisation v1
  - Architecture de l'organisation v2
  Par défaut, les nouvelles organisations sont provisionnées en fonction de votre type de déploiement, tel que défini par les paramètres de vos fonctionnalités :
  - Les déploiements PRODUCTION génèrent des organisations v2 par défaut.
  - Les déploiements ACCREDITED génèrent des organisations v1 par défaut.
  Dans le cas rare où vous devez remplacer le type d'organisation par défaut pour votre type de déploiement, mettez à jour le champ spec.compatibilityOptions.architectureOverridePolicy dans la ressource personnalisée Organization générée en ForceV1 ou ForceV2, selon le type d'organisation que vous souhaitez utiliser. Par exemple, l'extrait suivant force la création d'une organisation v2 dans un déploiement ACCREDITED :
```
...

spec:
...
  compatibilityOptions:
    architectureOverridePolicy: ForceV2

...
```
2. Vérifiez les paramètres restants pour vous assurer que les composants tels que l'espace de stockage et la puissance de calcul sont suffisants pour les besoins de votre entreprise.
Copiez les ressources personnalisées Organization et OrganizationZonalConfig dans le dépôt du répertoire de la nouvelle organisation :
```
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/
```
Remplacez les éléments suivants :
- ORG_NAME : nom de l'organisation que vous avez défini dans la commande gdcloud organizations config create à l'aide du paramètre --name.
- ZONE : nom de chaque zone du déploiement. Le nom de la zone est dérivé à l'aide du format suivant : {generalRegion}-{regionQualifier}{regionCounter}-{zoneLetter}. Par exemple, us-central1-b. Pour obtenir une description des valeurs de l'attribut "Zone", consultez la section "Zone" du questionnaire d'accueil des clients.

Ajoutez le fichier kustomization.yaml pour la nouvelle organisation :

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

Ajoutez la nouvelle organisation en tant que ressource de l'organisation racine :

Ouvrez le fichier racine global kustomization.yaml :

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

Ajoutez le nouveau Organization en tant que ressource à la fin de la liste de ressources existante :

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

Organisez et validez le fichier YAML de l'organisation et les fichiers Kustomize :
```
git add "IAC_REPO_PATH/iac/infrastructure"
git commit
```

Créez une requête de fusion :

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

Attendez que le code soit examiné et fusionné.
Vérifiez que l'organisation mondiale et les configurations zonales sont disponibles :
1. Vérifiez que l'organisation mondiale est disponible dans votre univers GDC :
```
kubectl get organization -A
```
  Le résultat ressemble à ce qui suit :
```
NAMESPACE    NAME    AGE
gpc-system   org     34s
gpc-system   root    14h
```
  Remarque : Si vous n'arrivez pas à accéder aux serveurs de la nouvelle organisation,vous devrez peut-être collaborer avec votre équipe d'administration réseau pour activer la connectivité aux adresses IP et aux ports appropriés pour l'organisation nouvellement créée.
2. Vérifiez l'état de l'organisation mondiale :
```
kubectl --kubeconfig GLOBAL_ROOT_ADMIN_KUBECONFIG \
    get organization/ORG_NAME -n gpc-system -o yaml
```
  Assurez-vous que les conditions status dans la sortie YAML sont True.
3. Vérifiez l'état de la configuration de l'organisation dans chaque zone :
```
kubeconfig --kubeconfig ROOT_ADMIN_KUBECONFIG \
    get organization/ORG_NAME -n gpc-system -o yaml
```
  Pour changer de contexte zonal, utilisez la CLI gdcloud pour vous connecter à chaque zone avant de vérifier l'état de l'organisation. Assurez-vous que les conditions status dans le résultat YAML pour chaque zone sont True.

1.5. Créer des sous-réseaux mondiaux dans le serveur d'API de l'organisation mondiale

Vous devez créer default-vpc-root-cidr dans le serveur d'API global de l'organisation, dans l'espace de noms platform, une fois le serveur d'API global en cours d'exécution. Ce sous-réseau racine attribue l'adresse IP des clusters au sein de l'organisation locataire, tels que les clusters d'utilisateur, ainsi que les adresses IP des charges de travail de VM.

Créez le fichier YAML du sous-réseau default-vpc-root-cidr, par exemple 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

Accédez au dépôt iac et ajoutez la structure de répertoire pour l'organisation mondiale :
```
cd iac; mkdir -p infrastructure/global/orgs/ORG_NAME/
```
Copiez le fichier YAML du sous-réseau default-vpc-root-cidr dans le dépôt IAC, dans le répertoire de la nouvelle organisation :
```
cp YAML_FILE_PATH/default-vpc-root-cidr.yaml \
    IAC_REPO_PATH/iac/infrastructure/global/orgs/ORG_NAME/
```

Créez le fichier kustomization.yaml dans le dossier de l'organisation avec les définitions Subnet nouvellement ajoutées. Vérifiez 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

Organisez et validez le fichier YAML de l'organisation et les fichiers Kustomize :
```
git add "IAC_REPO_PATH/iac/infrastructure"
git commit
```

Créez la demande de fusion :

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

Attendez que le code soit examiné et fusionné.

Comme les sous-réseaux mondiaux du cluster d'administrateur racine mondial sont divisés, default-vpc-root-cidr est également divisé et propagé à chaque zone pour que l'organisation zonale puisse consommer des adresses IP.

1.7. Configurer org-admin NTPRelay

Vous devez configurer manuellement l'authentification entre les NTPRelays root-admin et org-admin.

Suivez NTP-P0001.3 (Administrateur racine > Administrateur de l'organisation : chiffrement NTPRelay) pour configurer le chiffrement pour cette organisation.

1.8. Associer le fournisseur d'identité IO à l'organisation avec IAC

Consultez le guide ADFS pour créer un client OIDC dans ADFS pour la nouvelle organisation, puis notez l'ID client et le code secret du client OIDC.
Définissez le nom de votre organisation en tant que variable d'environnement :
```
export ORG_NAME=ORG_NAME
```
Vérifiez que ORG_NAME correspond exactement au nom de l'organisation.
Exportez le fichier kubeconfig du cluster d'administrateur racine, puis exécutez les commandes kubectl suivantes pour obtenir les noms du cluster et de la zone :
```
export KUBECONFIG=ROOT_ADMIN_KUBECONFIG
kubectl get clusters -A
kubectl get zones -n mz-system
```

Ajoutez le fichier ioauthmethod.yaml pour l'organisation :

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

Remplacez les variables suivantes :

Variable	Définition
`ADFS_CERT_BASE64`	Encodage en base64 du certificat utilisé par ADFS pour s'auto-signer, dont GKE Identity Service a besoin pour établir une connexion sécurisée avec une instance ADFS interne.
`ADFS_ORG_CLIENT_ID`	ID OpenID Connect du client de l'organisation dans ADFS.
`ADFS_ORG_CLIENT_SECRET`	Code secret OpenID Connect pour le client de l'organisation enregistré dans AD FS.
`ADFS_ISSUER_URI`	URI d'émetteur valide, requis par GKE Identity Service pour autoriser les requêtes de connexion par redirection vers ADFS.

Ajoutez le fichier initial-admin.yaml pour l'organisation :

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

Remplacez les variables suivantes :

Variable	Définition
`USER`	Nom d'utilisateur avec le préfixe de l'IO pour se connecter au cluster initialement. N'oubliez pas d'ajouter le préfixe au nom d'utilisateur.
`EXPIRATION`	Code temporel au format RFC 3339 auquel le système révoque l'accès. Par exemple, `"2020-11-14T00:20:12+00:00"`.

Ajoutez les fichiers nouvellement créés au fichier kustomization.yaml à l'adresse 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

Organisez et validez le fichier YAML de l'organisation et les fichiers Kustomize :
```
git add "infrastructure/global"
git add "infrastructure/zonal"
git commit
```
Transférez la mise à jour vers GitLab :
```
git -c http.sslVerify=false push
```
Attendez que le code soit examiné et fusionné.
Pour confirmer que l'opérateur peut accéder à l'organisation, connectez-vous à l'organisation générée et exécutez la commande suivante pour vérifier qu'un fournisseur d'identité (IdP) existe dans le ClientConfig de l'organisation :
1. Définissez le fichier kubeconfig de votre cluster d'administrateur en fonction de l'architecture de votre organisation :
  - Pour une organisation v1, exécutez la commande suivante :
```
export KUBECONFIG=ORG_ADMIN_CLUSTER_KUBECONFIG
```
    Remplacez ORG_ADMIN_CLUSTER_KUBECONFIG par le chemin d'accès au fichier kubeconfig du cluster d'administrateur de l'organisation, par exemple /tmp/${ORG}-admin-kubeconfig.
  - Pour une organisation v2, exécutez la commande suivante :
```
export KUBECONFIG=ORG_INFRA_CLUSTER_KUBECONFIG
```
    Remplacez ORG_INFRA_CLUSTER_KUBECONFIG par le chemin d'accès au fichier kubeconfig du cluster d'infrastructure de l'organisation, par exemple /tmp/${ORG}-infra-kubeconfig.
2. Vérifiez qu'un fournisseur d'identité existe dans le ClientConfig de l'organisation :
```
kubectl get ClientConfig default -n kube-public -o yaml
```

Pour la version 1.14.3, vous devez appliquer manuellement le rôle global-zone-viewer pour autoriser tous les utilisateurs authentifiés à afficher les zones d'un univers à l'aide de la gcloud CLI. Appliquez les ressources de rôle et de liaison de rôle :

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

Remplacez ORG_GLOBAL_API_SERVER_KUBECONFIG par le fichier kubeconfig du serveur d'API global de l'organisation. Pour en savoir plus, consultez Générer manuellement un fichier kubeconfig.

1.9. Associer le fournisseur d'identité du client à l'organisation

Pour associer un fournisseur d'identité (IdP) client à l'organisation et vous connecter à l'organisation avec vos identités, procédez comme suit :

Connectez-vous à partir de l&#CLI avec le compte administrateur IO initial défini lors de la création de l'organisation, qui est automatiquement lié à org-iam-admin dans le cluster d'administrateur de l'organisation.
Demandez au client d'ajouter l'URL de rappel AIS globale suivante à la liste d'autorisation dans le client OIDC ou SAML qu'il a créé pour l'organisation que vous allez créer :
```
https://ais-core.ORG_NAME.GDC_URL/finish-login
```
Par exemple, si l'URL racine de GDC est .google.gdch.test et que le nom de l'organisation est operations, l'URL de rappel AIS globale est https://ais-core.operations.google.gdch.test/finish-login.

Si vous utilisez un client SAML, vous devez également ajouter l'URL de rappel SAML AIS globale suivante à la liste d'autorisation :
```
https://ais-core.ORG_NAME.GDC_URL/saml-callback
```
Demandez au client d'ajouter l'URL de rappel AIS suivante à la liste d'autorisation dans le client OIDC ou SAML qu'il a créé pour chaque zone. Par exemple, pour un univers à trois zones, les URL de rappel AIS zonales sont semblables à ce qui suit :
```
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
```
Si l'URL racine de GDC est .google.gdch.test, le nom de la zone est zone-1 et le nom de l'organisation est operations, l'URL de rappel AIS est https://ais-core.operations.zone-1.google.gdch.test/finish-login.

Si vous utilisez un client SAML, vous devez également ajouter les URL de rappel SAML AIS suivantes à la liste d'autorisation pour chaque zone :
```
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
```
Définissez le fichier kubeconfig de votre cluster d'administrateur en fonction de l'architecture de votre organisation. Si vous avez déjà défini votre variable kubeconfig, ignorez cette étape.
- Pour une organisation v1, exécutez la commande suivante :
```
  export KUBECONFIG=ORG_ADMIN_CLUSTER_KUBECONFIG
```
  Remplacez ORG_ADMIN_CLUSTER_KUBECONFIG par le chemin d'accès au fichier kubeconfig du cluster d'administrateur de l'organisation, par exemple /tmp/${ORG}-admin-kubeconfig.
- Pour une organisation v2, exécutez la commande suivante :
```
  export KUBECONFIG=MANAGEMENT_API_SERVER_KUBECONFIG
```
  Remplacez MANAGEMENT_API_SERVER_KUBECONFIG par le chemin d'accès au fichier kubeconfig du serveur de l'API Management, par exemple /tmp/${ORG}-management-kubeconfig.
À partir de la demande client pour une nouvelle organisation, déterminez si l'IdP utilise OIDC ou SAML. Suivez le guide correspondant au type d'IdP donné :
- Configurer avec OIDC
- Configurer avec SAML
Remarque : Choisissez la configuration OIDC ou SAML à suivre. Cela dépend de l'IdP du client. Ne configurez pas les deux.

Configurer avec OIDC

Créez un fichier identity-provider-config.yaml et remplissez-le en vous référant aux tickets de création d'organisation pour les valeurs de l'IdP du compte de l'administrateur principal :

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

Voici la description détaillée des champs :

Attribut	Type d'attribut	Description
`certificateAuthorityData`	Obligatoire	Certificat d'autorité de certification encodé en base64 standard et au format PEM pour le fournisseur OIDC.
`clientID`	Obligatoire	ID de l'application cliente qui envoie des requêtes d'authentification au fournisseur OpenID.
`clientSecret`	Obligatoire	Secret partagé entre l'application cliente OIDC et le fournisseur OIDC.
`extraParams`	Facultatif	Liste de paires clé/valeur séparées par des virgules, encodées par requête et envoyées avec la requête de point de terminaison d'authentification.
`groupPrefix`	Facultatif	Préfixe à ajouter à la revendication de groupes pour éviter les conflits avec les groupes existants. Il est généralement utilisé lors de la configuration de plusieurs fournisseurs d'identité. Vous devez inclure le préfixe de groupe avant tous les noms de groupe. Par exemple, si vous avez `myprefix-` comme préfixe de groupe et un groupe nommé `groupA` dans votre fournisseur d'identité, lorsque vous ajoutez une règle ou une liaison, vous devez lier `myprefix-groupA`. Le nom du groupe est défini dans le champ `groupsClaim`. Remarque : GDC n'insère pas de séparateur entre le préfixe et le nom du groupe. Insérez un séparateur tel que `-` ou `:` à la fin du préfixe pour améliorer la lisibilité. Sinon, `prefix` et `sally@example.com` sont identifiés comme `prefixsally@example.com`.
`groupsClaim`	Facultatif	Nom de la revendication dans le jeton d'ID OIDC qui contient les informations sur les groupes de l'utilisateur. Ce nom doit être identique à celui de la revendication qui contient les informations d'appartenance à un groupe dans votre fournisseur OIDC.
`issuerURI`	Obligatoire	URL où les requêtes d'autorisation sont envoyées à votre fournisseur OIDC. Cet URI doit pointer vers le niveau à l'intérieur de `.well-known/openid-configuration`.
`scopes`	Facultatif	Liste d'identifiants séparés par des virgules permettant de spécifier les droits d'accès demandés en plus du champ d'application `openid`.
`userClaim`	Obligatoire	Nom de la revendication dans le jeton d'ID OIDC qui contient le nom d'utilisateur. Par exemple, si la revendication utilisateur est `email`, les utilisateurs sont identifiés par le champ utilisateur du jeton OIDC. S'il est absent du jeton d'ID, l'authentification échouera.
`userPrefix`	Facultatif	Préfixe à ajouter aux revendications utilisateur pour éviter les conflits avec les noms d'utilisateur existants. Il est généralement utilisé lors de la configuration de plusieurs fournisseurs d'identité. Par exemple, si la revendication utilisateur est `email` et que le préfixe utilisateur est `prefix-`, les utilisateurs sont identifiés comme suit : `prefix-sally@example.com`. L'utilisateur est `sally@example.com`, et le préfixe `prefix-` est ajouté en tant que préfixe à l'utilisateur pour distinguer les différents fournisseurs d'identité. Nous vous recommandons d'insérer un séparateur à la fin du préfixe, comme indiqué précédemment dans ce tableau pour la définition de `groupPrefix`.

Facultatif : Si votre fournisseur d'identité utilise des attributs personnalisés, configurez-les d'abord dans votre IdP. Ajoutez ensuite les paires clé-valeur correspondantes dans la section oidc du fichier identity-provider-config.yaml pour obtenir des revendications supplémentaires concernant les utilisateurs ou les groupes, comme leur service ou leur date de naissance. Lorsque vous appliquez les modifications à la configuration du fournisseur d'identité, GKE Identity Service reconnaît les attributs personnalisés. Voici un exemple d'attributs personnalisés :
```
  "attributeMapping": {
  "attribute.birthday": "assertion.birthday",
  "attribute.department": "assertion.department"
  }
```
Configurez la configuration du fournisseur d'identité :
```
kubectl apply -f identity-provider-config.yaml
```
Attendez que les différents composants du système soient reconfigurés.
Vérifiez la configuration en ouvrant la console de l'interface utilisateur de l'administrateur de plate-forme dans un navigateur Web. Sur la page de redirection, sélectionnez Se connecter avec pa-idp-oidc. Si vous êtes redirigé vers l'instance IdP du compte administrateur de plate-forme, puis de nouveau vers la page de la console de l'UI de l'administrateur de plate-forme après vous être connecté avec l'instance IdP du compte administrateur de plate-forme, la configuration est réussie. Sinon, vérifiez les valeurs dans identity-provider-config.yaml et réappliquez l'étape précédente.

Configurer avec SAML

Créez un fichier identity-provider-config.yaml et remplissez-le en vous référant aux tickets de création d'organisation pour les valeurs de l'ID du fournisseur d'identité du compte de l'administrateur principal :

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

Voici la description détaillée des champs :

Attribut	Type d'attribut	Description
`idpCertificateDataList`	Obligatoire	Certificats IdP utilisés pour valider la réponse SAML. Ces certificats doivent être encodés en base64 standard et au format PEM. Seuls deux certificats maximum sont acceptés pour faciliter la rotation des certificats du fournisseur d'identité.
`idpEntityID`	Obligatoire	ID d'entité SAML du fournisseur SAML, spécifié au format URI. Par exemple, https://www.idp.com/saml.
`idpSingleSignOnURI`	Obligatoire	URI du point de terminaison SSO du fournisseur SAML. Par exemple, "https://www.idp.com/saml/sso".
`groupPrefix`	Facultatif	Préfixe facultatif à ajouter à chaque nom de groupe.
`userPrefix`	Facultatif	Préfixe facultatif à ajouter au nom d'utilisateur.
`userAttribute`	Facultatif	Nom de l'attribut de la réponse SAML qui contient le nom d'utilisateur. Si cet attribut est absent de la réponse SAML, l'authentification échoue.
`groupsAttribute`	Facultatif	Nom de l'attribut de la réponse SAML qui contient les groupes de l'utilisateur.

Facultatif : Si votre fournisseur d'identité utilise des attributs personnalisés, configurez-les d'abord dans votre IdP. Ajoutez ensuite les paires clé-valeur correspondantes dans la section saml du fichier identity-provider-config.yaml pour obtenir des revendications supplémentaires concernant les utilisateurs ou les groupes, comme leur service ou leur date de naissance. Lorsque vous appliquez les modifications à la configuration du fournisseur d'identité, GKE Identity Service reconnaît les attributs personnalisés. Voici un exemple d'attributs personnalisés :
```
  "attributeMapping": {
  "attribute.birthday": "assertion.birthday",
  "attribute.department": "assertion.department"
  }
```
Configurez le correctif de configuration du fournisseur d'identité :
```
kubectl apply -f identity-provider-config.yaml
```
Attendez que les différents composants du système soient reconfigurés.
Vérifiez la configuration en ouvrant la console de l'interface utilisateur de l'administrateur de plate-forme dans un navigateur Web. Sélectionnez Se connecter avec pa-idp-oidc sur la page de redirection. Si vous êtes redirigé vers l'instance IdP du compte administrateur de plate-forme, puis de nouveau vers la page de la console de l'UI de l'administrateur de plate-forme après vous être connecté avec l'instance IdP du compte administrateur de plate-forme, la configuration est réussie. Sinon, vérifiez les valeurs dans identity-provider-config.yaml et réappliquez l'étape précédente.

Préfixe d'utilisateur et de groupe

Des préfixes d'utilisateur et de groupe doivent être définis pour chaque fournisseur d'identité dans Distributed Cloud afin d'éviter les conflits de noms entre les comptes de différents fournisseurs d'identité. Le préfixe est utilisé avec le nom de l'utilisateur et du groupe pour concaténer le nom du sujet dans les liaisons de rôle du cluster. Par exemple, pour un utilisateur nommé jack@example.com et un préfixe utilisateur du fournisseur d'identité example-org-idp-, le nom du sujet dans le cluster est example-org-idp-jack@example.com.

Pour déterminer la valeur du préfixe :

Indiquez le niveau de la hiérarchie (racine, organisation, projet).
Incluez le nom de l'IdP (adfs, keycloak).
Il est recommandé d'ajouter un caractère de séparation tel que - en tant que suffixe, car aucun séparateur n'est ajouté entre le préfixe et le nom d'utilisateur.

Attribuer un administrateur initial

Pour accorder à l'administrateur délégué un accès initial à l'organisation, il doit être désigné comme administrateur de l'organisation. Pour attribuer le rôle d'administrateur initial à l'administrateur de parc, créez un IAMRoleBinding dans le serveur d'API global :

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 Établir la connectivité réseau pour l'organisation

Une organisation nouvellement créée est isolée et n'est accessible depuis aucun réseau externe. Pour rendre l'organisation opérationnelle, vous devez la connecter à un ou plusieurs réseaux externes à l'aide du service Interconnect.

Ce processus implique la configuration d'un ensemble de ressources personnalisées qui définissent la connexion logique. Voici deux scénarios courants pour fournir une connectivité à une nouvelle organisation.

Scénario 1 : Associer une organisation à une interconnexion partagée existante

Si vous disposez déjà d'une interconnexion pour un réseau partagé, il vous suffit de mettre à jour AttachmentGroup et RoutePolicy pour inclure la nouvelle organisation.

Mettez à jour AttachmentGroup : AttachmentGroup spécifie les organisations qui peuvent utiliser un ensemble de rattachements de VLAN. Modifiez le fichier YAML AttachmentGroup et ajoutez la nouvelle organisation à la liste spec.entities. Pour une organisation v2, vous devez spécifier le réseau domainType (OrgAdmin, OrgData ou OrgMixed) à connecter.

Exemple de mise à jour 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

Mettez à jour le RoutePolicy : un RoutePolicy définit les préfixes d'adresses IP qui sont annoncés. Modifiez la règle et ajoutez les sous-réseaux IP externes de la nouvelle organisation à spec.out.ipPrefixList. Cela permet au trafic entrant d'atteindre l'organisation.

Exemple de mise à jour 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 ...

Appliquez les modifications à l'aide de kubectl apply avec votre processus Infrastructure as Code (IaC).

Scénario 2 : Créer une interconnexion dédiée

Pour une connexion dédiée, vous devez créer un nouvel ensemble de ressources d'interconnexion. L'ensemble du processus consiste à créer cinq ressources personnalisées dans l'ordre.

Créez un InterconnectLink pour chaque nouvelle connexion physique.
Créez un InterconnectGroup pour regrouper les liens physiques et autoriser la nouvelle organisation.
Créez un AttachmentGroup et spécifiez la nouvelle organisation dans la liste entities.
Créez un RoutePolicy qui autorise les préfixes IP entrants et sortants pour cette connexion dédiée.
Créez une ou plusieurs ressources InterconnectAttachment pour définir les VLAN et les sessions BGP.

Pour obtenir des exemples complets et des instructions détaillées pour chacune de ces ressources, consultez la documentation Configurer une interconnexion.

1.11 Configurer le webhook Alertmanager pour se connecter à ServiceNow

Suivez la procédure décrite dans MON-T0016 pour connecter le webhook Alertmanager à ServiceNow afin de créer des incidents.

1.12 Configurer la feuille de tarifs de facturation pour l'organisation

Le sous-composant de facturation d'une organisation exige que les produits ou services à facturer soient configurés avec la ressource personnalisée SKUDescription. Un seul SKUDescription décrit un seul produit ou service à facturer avec son prix. Une collection d'objets SKUDescription peut donc être considérée comme la fiche tarifaire d'une organisation. Les étapes suivantes permettent de configurer la grille tarifaire pour l'organisation dans IAC.

1.12.1 Obtenir la grille tarifaire

Si vous ne disposez pas déjà des ressources de la feuille tarifaire SKUDescription pour une organisation, contactez le bureau de gestion des programmes (PMO) pour obtenir la feuille tarifaire. La grille tarifaire doit se composer d'une série de fichiers YAML contenant des ressources SKUDescription.

1.12.2 Déterminer si la fiche tarifaire est partagée ou non

La fiche tarifaire peut être partagée entre toutes les organisations ou configurée pour chaque organisation. Le PMO peut vous indiquer si la grille tarifaire est partagée ou non.

Si la grille tarifaire est partagée, placez-la dans le dossier IAC partagé common-data.

Si cette organisation n'est pas la toute première à avoir été créée, il est possible que la fiche tarifaire existe déjà dans le dossier partagé common-data. Si la fiche tarifaire existe, vérifiez que les étapes 2 à 4 ont été suivies, puis passez à l'étape 5.
Créez le dossier partagé pour la grille tarifaire.
```
mkdir -p IAC_REPO_PATH/iac/infrastructure/common-data/bil/skudescriptions/
```
Remplacez IAC_REPO_PATH par le chemin d'accès au dépôt IAC.
Enregistrez les ressources YAML de la fiche tarifaire SKUDescription dans ce dossier. Ensuite, le dossier skudescriptions doit contenir des fichiers YAML séparés par zone. Configurez la structure des dossiers et les fichiers YAML pour qu'ils correspondent à votre cas d'utilisation de la facturation :
- Facturation gérée par le partenaire : Google facture le partenaire. Placez les ressources SKUDescription dans l'espace de noms partner-billing-system.
- Facturation client : le partenaire facture l'utilisateur final. Placez les ressources SKUDescription dans l'espace de noms billing-system.
Les exemples suivants montrent les structures de fichier des modèles de facturation des clients et des partenaires. Pour chaque modèle, vous voyez deux services, Compute et Storage, avec deux fichiers YAML pour chacun d'eux :

Facturation client :
```
├── customer
     ├── compute
     │   ├── compute-sku1.yaml
     │   └── compute-sku2.yaml
     └── storage
         ├── storage-sku1.yaml
         └── storage-sku2.yaml
```
Facturation gérée par le partenaire :
```
├── partner
     ├── compute
     │   ├── partner-compute-sku1.yaml
     │   └── partner-compute-sku2.yaml
     └── storage
         ├── partner-storage-sku1.yaml
         └── partner-storage-sku2.yaml
```

Vérifiez qu'il existe un fichier kustomization.yaml dans le répertoire qui inclut tous les fichiers YAML de la feuille de tarifs SKUDescription.

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

Exportez la variable d'environnement ORG_CLUSTER :
- Pour une organisation v1, exécutez la commande suivante :
```
export ORG_CLUSTER=ORG_ADMIN_CLUSTER_NAME
```
- Pour une organisation v2, exécutez la commande suivante :
```
export ORG_CLUSTER=ORG_INFRA_CLUSTER_NAME
```
Créez le répertoire de facturation skudescriptions dans l'organisation :
- Pour une organisation v1 :
```
mkdir -p IAC_REPO_PATH/iac/infrastructure/zonal/zones/ZONE_NAME/ORG_CLUSTER_NAME/bil/skudescriptions
```
- Pour une organisation v2 :
```
mkdir -p IAC_REPO_PATH/iac/infrastructure/zonal/zones/ZONE_NAME/ORG_CLUSTER_NAME-management/bil/skudescriptions
```
Remplacez ORG_CLUSTER_NAME par le nom du cluster d'administrateur de l'organisation, en fonction du type de version de votre organisation.

Incluez la grille tarifaire commune dans l'organisation :

Pour une organisation 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

Pour une organisation 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

Organisez et validez le fichier YAML, puis personnalisez les fichiers :
```
cd IAC_REPO_PATH
git add "iac"
git commit
```
Transférez la mise à jour vers GitLab :
```
git -c http.sslVerify=false push
```
Attendez que le code soit examiné et fusionné.
Vérifiez que les objets SKUDescription existent sur le cluster donné pour votre modèle de facturation correspondant.

Exportez la valeur KUBECONFIG en fonction du type d'organisation.
- Pour une organisation v1, exécutez la commande suivante :
```
export KUBECONFIG=ORG_ADMIN_CLUSTER_KUBECONFIG
```
  Remplacez ORG_ADMIN_CLUSTER_KUBECONFIG par le chemin d'accès au fichier kubeconfig du cluster d'administrateur de l'organisation, par exemple /tmp/${ORG}-admin-kubeconfig.
- Pour une organisation v2, exécutez la commande suivante :
```
export KUBECONFIG=MANAGEMENT_API_SERVER_KUBECONFIG
```
  Remplacez MANAGEMENT_API_SERVER_KUBECONFIG par le chemin d'accès au fichier kubeconfig du serveur de l'API Management, par exemple /tmp/${ORG}-management-kubeconfig.
Exécutez la CLI kubectl :

Pour la facturation des clients :
```
kubectl get SKUDescription -n billing-system
```
Pour la facturation partenaire :
```
kubectl get SKUDescription -n partner-billing-system
```

1.12.2.2 Fiche tarifaire spécifique à l'organisation

Si la grille tarifaire est spécifique à une organisation, vous devez la placer dans le dossier du cluster de l'organisation.

Créez le répertoire de facturation skudescriptions dans le cluster de l'organisation :

Pour une organisation v1 :

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

Pour une organisation v2 :

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

Enregistrez les ressources YAML de la fiche tarifaire SKUDescription dans ce dossier. Ensuite, le dossier skudescriptions doit contenir des fichiers YAML séparés par zone. Dans l'exemple suivant, vous voyez deux services, compute et storage, avec deux fichiers YAML chacun :
```
.
├── compute
│   ├── compute-sku1.yaml
│   └── compute-sku2.yaml
└── storage
    ├── storage-sku1.yaml
    └── storage-sku2.yaml
```

Assurez-vous qu'un fichier kustomization.yaml se trouve dans le répertoire qui inclut tous les fichiers YAML de la fiche tarifaire SKUDescription.

Pour une organisation 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

Pour une organisation 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

Assurez-vous que le fichier kustomization.yaml à la racine de l'organisation contient le dossier bil/skudescriptions que vous venez d'ajouter. Vérifiez IAC_REPO_PATH/iac/infrastructure/zonal/zones/ZONE_NAME/ORG_CLUSTER_NAME/kustomization.yaml pour une organisation v1 et IAC_REPO_PATH/iac/infrastructure/zonal/zones/ZONE_NAME/ORG_CLUSTER_NAME-management/kustomization.yaml pour une organisation v2 :
```
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
-   ... # existing resource items
-   bil/skudescriptions
```
Organisez et validez le fichier YAML et les fichiers kustomize :
```
cd IAC_REPO_PATH
git add "iac"
git commit
```
Transférez la mise à jour vers GitLab :
```
git -c http.sslVerify=false push
```
Attendez que le code soit examiné et fusionné.
Vérifiez que les objets SKUDescription existent sur le cluster donné :
- Pour une organisation v1, exécutez la commande suivante :
```
export KUBECONFIG=ORG_ADMIN_CLUSTER_KUBECONFIG

kubectl get SKUDescription -n billing-system
```
  Remplacez ORG_ADMIN_CLUSTER_KUBECONFIG par le chemin d'accès au fichier kubeconfig du cluster d'administrateur de l'organisation, par exemple /tmp/${ORG}-admin-kubeconfig.
- Pour une organisation v2, exécutez la commande suivante :
```
export KUBECONFIG=MANAGEMENT_API_SERVER_KUBECONFIG

kubectl get SKUDescription -n billing-system
```
  Remplacez MANAGEMENT_API_SERVER_KUBECONFIG par le chemin d'accès au fichier kubeconfig du serveur de l'API Management, par exemple /tmp/${ORG}-management-kubeconfig. .

1.13 Créer des utilisations récurrentes pour la facturation

Distributed Cloud propose des unités de gestion des stocks (SKU) qui entraînent des frais récurrents. Toutefois, Distributed Cloud ne suit pas vos coûts d'utilisation pour certains SKU. Pour gérer ces informations, utilisez la ressource RecurringUsage. Pour obtenir des informations et des instructions sur la création d'utilisations récurrentes, consultez Créer des utilisations récurrentes.

1.14 Configurer la facturation pour une organisation

Le sous-composant de facturation ne commence à calculer les coûts pour une organisation qu'une fois l'heure de début de la facturation atteinte. La valeur par défaut de l'heure de début de la facturation est 9999-01-01T00:00:00-07:00. Par conséquent, une fois qu'une organisation est considérée comme prête, l'OI remplace l'heure de début de la facturation pour lancer le workflow de facturation.

1.14.1 Obtenir l'heure de début de la facturation

L'heure de début de la facturation doit correspondre au début de la période de performance, qui est indiquée dans votre contrat. Si vous ne connaissez pas encore la date de début de la facturation pour une organisation, contactez le bureau de gestion du programme (PMO) pour obtenir ces informations.

1.14.2 Associer un compte de paiement pour la facturation à une organisation

Les environnements Google Distributed Cloud (GDC) isolés nécessitent un compte de facturation pour suivre les coûts des projets et des organisations. Si vous n'associez pas de compte de facturation à une organisation ou à un projet, vous perdrez les données de coûts associées à la ressource.

Pour facturer l'utilisation des services au client, tous les comptes de facturation d'une organisation utilisent une seule et même grille tarifaire.

1.14.2.1 Avant de commencer

Avant de continuer, demandez à votre administrateur de sécurité de vous accorder les rôles requis suivants. Ces rôles sont associés à l'espace de noms du projet pour la facturation au niveau du projet ou à l'espace de noms de la plate-forme pour la facturation au niveau de l'organisation :

Administrateur de compte de facturation de l'organisation : crée, gère et associe la ressource BillingAccount. Demandez à votre administrateur de sécurité de vous accorder le rôle organization-billing-account-admin.
Utilisateur du compte de facturation de l'organisation : lecture, liste et association de la ressource BillingAccount. Demandez à votre administrateur de sécurité de vous accorder le rôle organization-billing-account-user.
Gestionnaire de compte de facturation de l'organisation : lit, liste, crée et met à jour la ressource BillingAccountBinding. Demandez à votre administrateur de sécurité de vous accorder le rôle organization-billing-manager.

1.14.2.2 Créer un compte de facturation

Un compte de facturation est identifié de manière unique par son name et son namespace. Pour créer un compte de facturation, utilisez une ressource personnalisée pour établir name et namespace :

Créez un fichier YAML, puis ajoutez la ressource personnalisée BillingAccount et le contenu suivant :
```
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"
```
Remplacez les variables suivantes :
- BIL_ACCOUNT_NAME : nom du compte de facturation. Par exemple : test-billing-account.
- BIL_DISPLAY_NAME : nom à afficher du compte de facturation. Par exemple : "Test Billing Account".
Vérifiez votre type de configuration de paiement. Les comptes de facturation Distributed Cloud doivent disposer de l'une des configurations de paiement suivantes :
- cloudBillingConfig : configuration de paiement par défaut. Cette configuration stocke un ID de compte de facturation Cloud.
- customConfig : configuration personnalisée permettant aux partenaires de stocker leur configuration de paiement pour facturer l'organisation. customConfig accepte un dictionnaire de chaînes clé/valeur, avec une clé obligatoire payment-config-type.
Les exemples suivants montrent des extraits de fichier YAML BillingAccount pour différentes configurations de paiement :

cloudBillingConfig
```
spec:
  paymentSystemConfig:
    cloudBillingConfig:
      accountID: CLOUD_BILLING_ACCOUNT_ID
```
Remplacez CLOUD_BILLING_ACCOUNT_ID par l'ID de votre compte de facturationGoogle Cloud .

customConfig
```
spec:
  paymentSystemConfig:
    customConfig:
      "payment-config-type": PAYMENT_CONFIG_TYPE
```
Remplacez PAYMENT_CONFIG_TYPE par le type de configuration de paiement de votre choix pour votre configuration de facturation personnalisée.

Si vous ne disposez pas des informations de configuration customConfig de votre organisation, saisissez les informations suivantes :
```
spec:
  paymentSystemConfig:
    customConfig:
      "payment-config-type": "N/A"
```
Le fichier YAML suivant montre une ressource BillingAccount complète avec la configuration 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"
```
Enregistrez le fichier YAML de la ressource personnalisée. Exécutez l'CLI kubectl pour appliquer la ressource dans le cluster d'organisation pour l'organisation ou le projet spécifique que vous souhaitez facturer :
```
kubectl --kubeconfig $ORG_KUBECONFIG apply -f billingaccount.yaml
```

1.14.2.3 Associer une organisation à un compte de facturation

Pour associer une organisation à un BillingAccount, procédez comme suit :

Ajoutez le contenu suivant au fichier YAML billingaccountbinding.yaml :
- Dans la section billingAccountRef, remplissez le champ name avec le contenu du champ name de l'BillingAccount que vous souhaitez associer.
- Dans la section metadata, renseignez le champ namespace avec le contenu du champ identique dans la ressource BillingAccount. Dans cet exemple, l'espace de noms de l'organisation est platform :
```
apiVersion: billing.gdc.goog/v1
kind: BillingAccountBinding
metadata:
  name: billing
  namespace: platform
spec:
  billingAccountRef:
    name: BIL_ACCOUNT_NAME
    namespace: platform
```

Appliquez le fichier billingaccountbinding.yaml :

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

1.14.3 Avant de commencer

Avant de continuer, demandez à votre Administrateur de sécurité de vous attribuer le rôle Bil Monitor (bil-monitor) dans le cluster d'administration de l'organisation pour l'espace de noms billing-system. Cette autorisation vous permet de lire les ressources associées pour la validation.

1.14.4 Remplacer l'heure de début de la facturation

Créez deux fichiers YAML avec les chemins d'accès suivants :
- 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.
  - Créez les sous-répertoires nécessaires pour chaque fichier s'ils sont manquants.

Ajoutez la ressource SubcomponentOverride et le contenu suivant à chaque fichier :

Pour la facturation des clients :

Fichier 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

Fichier 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

Pour la facturation gérée par un partenaire :

Ajoutez l'indicateur enablePartnerBilling: true à la fin de chaque fichier YAML :

Fichier 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

Fichier 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

Remplacez les variables suivantes :

ORG_NAME : nom de l'organisation. Exemple : org-1.
BILLING_START_TIME : code temporel pour démarrer le workflow de facturation.Il doit être au format RFC 3339. Par exemple, si le workflow de facturation commence le 01/01/2024 avec le fuseau horaire "Heure normale du Pacifique des États-Unis et du Canada (UTC-8)", ajoutez la valeur de code temporel 2024-01-01T00:00:00-08:00.
BILLING_TIMEZONE : fuseau horaire du workflow de facturation. Le fuseau horaire doit être au format RFC 3339. Par exemple, si le fuseau horaire de facturation est l'heure normale du Pacifique des États-Unis et du Canada (UTC-8), ajoutez la valeur du fuseau horaire sous la forme PST8PDT.

Important : Pour les architectures Org v2 (organisations v2), vous avez besoin d'un SubcomponentOverride supplémentaire pour les espaces de noms suivants afin de distribuer OperableParameters aux sous-composants du serveur de l'API Management :

Fichier 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

Fichier 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

Enregistrez et stockez les fichiers YAML dans le dossier infrastructure/zonal/zones/ZONE_NAME/root-admin/components/bil/ORG_NAME.
Créez une demande d'extraction contenant les fichiers YAML ainsi que le fichier de personnalisation nécessaire.

1.14.5 Valider l'heure de début de la facturation

Vérifiez que vous avez remplacé l'heure de début de la facturation pour le monétiseur et la génération de factures :

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 Configurer la règle de réseau du proxy de stockage d'objets sur le cluster d'administrateur de l'organisation

1.15.1 Créer le fichier YAML de règle de réseau

Créez le fichier YAML de règle de réseau allow-obs-system-ingress-traffic, par exemple 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 Appliquer le règlement du réseau au cluster d'administrateur de l'organisation

kubectl --kubeconfig ORG_ADMIN_KUBECONFIG apply -f networkpolicy.yaml

1.16. Créer un site de sauvegarde

Si vous profitez de la reprise après sinistre, vous devez répéter les étapes précédentes pour le site de sauvegarde. Si vous n'avez pas activé la reprise après sinistre, ignorez cette section.

Suivez les sections 1.4. - 1.9. pour créer une autre organisation pour le site de sauvegarde.

1.17. Résoudre les problèmes de création d'organisation

1.17.1. Vérifiez que toutes les ressources déployées sont opérationnelles et présentes.

Le processus de création d'une organisation crée plusieurs ressources dans différents clusters Kubernetes. Commencez par vérifier les ressources déployées et assurez-vous qu'elles sont en bon état. Les sections suivantes décrivent les ressources créées pour une organisation appelée operations.

1.17.2. Confirmer toutes les ressources déployées dans le cluster d'administrateur racine

Pour vérifier que toutes les ressources du cluster administrateur racine sont opérationnelles et présentes, procédez comme suit :

Obtenez la configuration kubeconfig requise pour le cluster d'administrateur racine en suivant IAM-R0004. Assurez-vous de définir les variables d'environnement et l'alias suivants pour ces instructions de validation :
```
export KUBECONFIG=ROOT_ADMIN_KUBECONFIG
export ORG="ORG_NAME"
alias k=kubectl
```

Vérifiez que les ressources de pare-feu sont disponibles :

Établissez une connexion SSH au pare-feu et vérifiez qu'un vsys a été créé :
```
show config running | match 'vsys[0-9] '
```
Le résultat ressemble à ce qui suit :
```
vsys1 {
vsys2 {
```

Vérifiez la ressource FirewallVirtualSystem :

k get firewallvirtualsystem -n gpc-system

Le résultat ressemble à ce qui suit :

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

Vérifiez que les ressources de stockage sont disponibles :

Vérifiez la ressource StorageVirtualMachine :

k get StorageVirtualMachine -n gpc-system

Le résultat ressemble à ce qui suit :

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

Vérifiez que les ressources HSM sont disponibles :

Vérifiez les HSM :

k get hsms -n gpc-system

Le résultat ressemble à ce qui suit :

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

Vérifiez le cluster HSM :

k get hsmcluster -n gpc-system

Le résultat ressemble à ce qui suit :

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

Vérifiez le locataire HSM :

k get hsmtenant -A

Le résultat ressemble à ce qui suit :

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

Vérifiez que les ressources de la machine et du nœud sont disponibles :

Consultez les ressources AddressPoolClaim :

k get addresspoolclaims -A

Le résultat ressemble à ce qui suit :

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

Consultez les ressources NodePoolClaim :

k get nodepoolclaims -A

Le résultat ressemble à ce qui suit :

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

Consultez les ressources NodePool :

k get nodepool -A

Le résultat ressemble à ce qui suit :

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

Vérifiez les clusters Bare Metal :

k get baremetalclusters -A

Le résultat ressemble à ce qui suit :

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

Vérifiez les machines Bare Metal :

k get baremetalmachines -A

Le résultat ressemble à ce qui suit :

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

Vérifiez les serveurs. Ils sont à l'état provisioned :

k get servers -n gpc-system | grep provisioned

Le résultat ressemble à ce qui suit :

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

Vérifiez le cluster Kubernetes :

k get cluster -A

Le résultat ressemble à ce qui suit :

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

Vérifiez les secrets du fichier kubeconfig :

k get secrets -A | grep kubeconfig

Le résultat ressemble à ce qui suit :

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

1.17.3. Confirmer toutes les ressources déployées dans les clusters d'organisation v1

Suivez les étapes ci-dessous pour vérifier que toutes les ressources du cluster administrateur et du cluster système d'une organisation v1 sont saines et présentes. Si vous disposez d'une organisation v2, passez à la section suivante.

1.17.3.1. Confirmer toutes les ressources déployées dans un cluster d'administrateur d'organisation

Obtenez la configuration kubeconfig requise pour le cluster d'administrateur racine en suivant IAM-R0004. Veillez à définir les variables d'environnement et l'alias suivants pour ces instructions de validation :

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

Vérifiez que les ressources de la machine et du nœud sont disponibles :

Vérifiez les clusters Bare Metal :

ka get baremetalclusters -A

Le résultat ressemble à ce qui suit :

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

Vérifiez les machines Bare Metal :

ka get baremetalmachines -A

Le résultat ressemble à ce qui suit :

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

Vérifiez les machines :

ka get machines -A

Le résultat ressemble à ce qui suit :

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

Consultez les ressources VirtualmachinesInstance :

ka get virtualmachineinstances -A

Le résultat ressemble à ce qui suit :

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

Consultez les ressources NodePool :

ka get nodepools -A

Le résultat ressemble à ce qui suit :

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

Vérifiez les clusters Kubernetes :

ka get clusters -A

Le résultat ressemble à ce qui suit :

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

Vérifiez les nœuds :

ka get nodes -A

Le résultat ressemble à ce qui suit :

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

Vérifiez les secrets du fichier kubeconfig :

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

Le résultat ressemble à ce qui suit :

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

1.17.3.2. Confirmer toutes les ressources déployées dans le cluster d'utilisateur système

Pour vérifier que toutes les ressources du cluster système sont opérationnelles et présentes, procédez comme suit :

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

Vérifiez que les ressources de la machine et du nœud sont disponibles :

Vérifiez la ressource VirtualmachineInstance :

ku get vmi -A

Le résultat ressemble à ce qui suit (si un cluster d'utilisateur a été créé) :

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

Vérifiez les nœuds :

ku get nodes

Le résultat ressemble à ce qui suit :

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

Vérifiez les allocations de GPU :

ku get gpuallocations -A

Le résultat ressemble à ce qui suit :

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. Confirmer toutes les ressources déployées dans les clusters d'organisation v2

Suivez les étapes ci-dessous pour confirmer que toutes les ressources du cluster d'infrastructure de l'organisation dans une organisation v2 sont opérationnelles et présentes. Si vous disposez d'une organisation v1, ignorez cette section.

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

Vérifiez que les nœuds et les serveurs d'API sont opérationnels :

Vérifiez les nœuds :

ka get nodes -A

Le résultat ressemble à ce qui suit :

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

Vérifiez les secrets du fichier kubeconfig :

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

Le résultat ressemble à ce qui suit :

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

Vérifiez les allocations de GPU pour confirmer que les ressources GPU sont prêtes, le cas échéant :

ka get gpuallocations -A

Le résultat ressemble à ce qui suit :

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. Confirmez que toutes les ressources de l'organisation ont été rapprochées.

Pour vérifier que toutes les ressources liées à l'organisation dans le cluster d'administration racine mondial et zonal sont saines et présentes, procédez comme suit, en supposant que l'objectif est de créer une organisation operations avec deux zones : zone-1 et zone-2.

Suivez Accéder à l'API d'administrateur racine global pour accéder au serveur d'API global et utilisez l'alias suivant pour l'API kubectl d'administrateur racine global.
```
alias kga='kubectl --kubeconfig ROOT_ADMIN_KUBECONFIG
export ORG="ORG_NAME"
```

Vérifiez que les ressources d'organisation globales sont disponibles :

Vérifiez les ressources Organization globales :

kga get organization -A

Le résultat ressemble à ce qui suit :

NAMESPACE    NAME         READY
gpc-system   operations
gpc-system   root

Vérifiez les ressources OrganizationReplica globales :

kga get organizationreplica -A

Le résultat ressemble à ce qui suit :

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

Vérifiez les ressources OrganizationZonalConfig globales :

kga get organizationzonalconfig -A

Le résultat ressemble à ce qui suit :

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

Vérifiez les ressources OrganizationZonalConfigReplica globales :

kga get organizationzonalconfigreplica -A

Le résultat ressemble à ce qui suit :

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

Définissez l'alias de configuration kubeconfig du cluster d'administrateur racine zonal :
```
alias ka='kubectl --kubeconfig /root/GDC_VERSION/root-admin/root-admin-kubeconfig'
```

Vérifiez que les ressources d'organisation zonales sont disponibles :

Consultez les ressources Organization :

ka get organization -A

Le résultat ressemble à ce qui suit :

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

Consultez les ressources OrganizationReplica :

ka get organizationreplica -A

Le résultat ressemble à ce qui suit :

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

Consultez les ressources OrganizationZonalConfigReplica :

ka get organizationzonalconfigreplica -A

Le résultat ressemble à ce qui suit :

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

Suivez Autoriser n'importe quelle adresse à accéder à une organisation pour autoriser le trafic DCI dans les clusters d'administrateur de l'organisation, du site source au site de sauvegarde.

Champ OIQ	Description	Taille minimale requise	Taille minimale par zone pour l'organisation	Nom du sous-réseau racine global	Serveur d'API mondial
`infraVPCCIDR`	Charges de travail système, y compris la console d'organisation, les API de gestion et les services propriétaires.	\( 15 - \lceil \log_2(ZoneNumber) \rceil \)	16	`infra-vpc-root-cidr`	Racine globale
`defaultVPCCIDR`	Charges de travail et points de terminaison utilisateur dans le VPC par défaut, répartis dans les zones.	\( 16 - \lceil \log_2(ZoneNumber) \rceil \)	16	`default-vpc-root-cidr`	Organisation mondiale
`orgAdminExternalCIDR`	Charges de travail et points de terminaison du cluster de périmètre qui gèrent le trafic administratif entre le réseau externe et l'organisation.	\( 22 - \lceil \log_2(ZoneNumber) \rceil \)	23	`admin-external-root-cidr`	Racine globale
`orgDataExternalCIDR`	Charges de travail et points de terminaison accessibles aux utilisateurs en externe, tels que les équilibreurs de charge externes et les NAT de sortie.	\( 22 - \lceil \log_2(ZoneNumber) \rceil \)	23	`data-external-root-cidr`	Racine globale

1. Créer une organisation client

1.1. Avant de commencer

1.2. Créer un client OIDC dans OC IT ADFS

1.3 Créer des sous-réseaux mondiaux et les diviser pour chaque zone

1.3.1. Définir la plage CIDR pour OIQ

1.3.2. Créer des sous-réseaux mondiaux dans le serveur d'API de l'administrateur racine mondial

1.3.3. Fractionner les sous-réseaux racine pour les zones

1.3.3.1. Diviser automatiquement les sous-réseaux racine pour les zones

1.3.3.2. Répartir manuellement les sous-réseaux racine pour les zones

1.3.3.2.1. Exemple de fractionnement manuel des sous-réseaux racine pour les zones dans infra-vpc

1.3.3.2.2. Exemple de répartition manuelle des sous-réseaux racine pour les zones du segment de réseau de données

1.3.3.2.3. Exemple de fractionnement manuel des sous-réseaux racine pour les zones du segment de réseau d'administration

1.4. Créer une organisation avec IAC

1.5. Créer des sous-réseaux mondiaux dans le serveur d'API de l'organisation mondiale

1.7. Configurer org-admin NTPRelay

1.8. Associer le fournisseur d'identité IO à l'organisation avec IAC

1.9. Associer le fournisseur d'identité du client à l'organisation

Configurer avec OIDC

Configurer avec SAML

Préfixe d'utilisateur et de groupe

Attribuer un administrateur initial

1.10 Établir la connectivité réseau pour l'organisation

Scénario 1 : Associer une organisation à une interconnexion partagée existante

Scénario 2 : Créer une interconnexion dédiée

1.11 Configurer le webhook Alertmanager pour se connecter à ServiceNow

1.12 Configurer la feuille de tarifs de facturation pour l'organisation

1.12.1 Obtenir la grille tarifaire

1.12.2 Déterminer si la fiche tarifaire est partagée ou non

1.12.2.1 Fiche tarifaire partagée

1.12.2.2 Fiche tarifaire spécifique à l'organisation

1.13 Créer des utilisations récurrentes pour la facturation

1.14 Configurer la facturation pour une organisation

1.14.1 Obtenir l'heure de début de la facturation

1.14.2 Associer un compte de paiement pour la facturation à une organisation

1.14.2.1 Avant de commencer

1.14.2.2 Créer un compte de facturation

1.14.2.3 Associer une organisation à un compte de facturation

1.14.3 Avant de commencer

1.14.4 Remplacer l'heure de début de la facturation

1.14.5 Valider l'heure de début de la facturation

1.15 Configurer la règle de réseau du proxy de stockage d'objets sur le cluster d'administrateur de l'organisation

1.15.1 Créer le fichier YAML de règle de réseau

1.15.2 Appliquer le règlement du réseau au cluster d'administrateur de l'organisation

1.16. Créer un site de sauvegarde

1.17. Résoudre les problèmes de création d'organisation

1.17.1. Vérifiez que toutes les ressources déployées sont opérationnelles et présentes.

1.17.2. Confirmer toutes les ressources déployées dans le cluster d'administrateur racine

1.17.3. Confirmer toutes les ressources déployées dans les clusters d'organisation v1

1.17.3.1. Confirmer toutes les ressources déployées dans un cluster d'administrateur d'organisation

1.17.3.2. Confirmer toutes les ressources déployées dans le cluster d'utilisateur système

1.17.4. Confirmer toutes les ressources déployées dans les clusters d'organisation v2

1.17.5. Confirmez que toutes les ressources de l'organisation ont été rapprochées.