1. Crea un'organizzazione cliente

Tempo stimato per il completamento: 3 ore

Profilo delle competenze: ingegnere del deployment

In qualità di operatore, puoi creare un'organizzazione per fornire ai clienti l'accesso all'infrastruttura della piattaforma. Per ottenere le autorizzazioni necessarie per creare un'organizzazione, chiedi all'Amministratore sicurezza di concederti il ruolo Amministratore dell'organizzazione.

La risorsa Organization è il nodo radice della gerarchia di risorse air-gapped di Google Distributed Cloud (GDC) e di tutte le risorse che appartengono a un gruppo di organizzazioni sotto il nodo dell'organizzazione. In questo modo, puoi visualizzare e controllare centralmente ogni risorsa che appartiene a un'organizzazione.

Per saperne di più sulle organizzazioni, consulta la Panoramica dell'organizzazione.

1.1. Prima di iniziare

Assicurati di aver installato quanto segue:

  • Un browser nel tuo sistema.

  • L'interfaccia a riga di comando (CLI) Git.

  • L'interfaccia a riga di comando kubectl.

  • gcloud CLI.

1.2. Creare un client OIDC in OC IT ADFS

  1. Consulta le istruzioni per la configurazione di ADFS OIDC per creare un client OpenID Connect (OIDC) in ADFS per consentire all'operatore di accedere all'organizzazione che stai per creare. Registra l'ID client e il client secret del client OIDC. Non devi riutilizzare il client nelle connessioni ad altri cluster, come il cluster di amministrazione principale e altri cluster di amministrazione dell'organizzazione, o a servizi come ServiceNow.

  2. Aggiungi il seguente URL di callback di GKE Identity Service all'allowlist nel client ADFS OIDC che hai creato per l'organizzazione che creerai:

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

    Ad esempio:

    • Nome dell'organizzazione: operations
    • Nome dell'istanza Distributed Cloud: google
    • Nome di dominio Distributed Cloud: gdch.test

    L'URL di callback di GKE Identity Service in questo caso è https://ais-core.operations.google.gdch.test/finish-login.

  3. Aggiungi il seguente URL di callback del servizio di identità GKE all'allowlist nel client OIDC ADFS che hai creato per ogni zona del tuo universo GDC:

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

    Ad esempio:

    • Nome dell'organizzazione: operations
    • nome zona: zone-1
    • Nome dell'istanza Distributed Cloud: google
    • Nome di dominio Distributed Cloud: gdch.test

    L'URL di callback di GKE Identity Service in questo caso è https://ais-core.operations.zone-1.google.gdch.test/finish-login.

  4. Imposta le seguenti variabili da utilizzare nelle sezioni successive:

    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

    Sostituisci le variabili con i seguenti valori:

    VariabileDefinizione
    ADFS_CERT_BASE64 Il file adfs.pem con codifica base64.
    ADFS_CLIENT_ID L'identificatore client ADFS.
    ADFS_CLIENT_SECRET Il secret condiviso del client ADFS.
    ADFS_ISSUER_URI L'URI dell'emittente ADFS. Per ottenere l'URI, controlla il percorso /adfs/.well-known/openid-configuration del server ADFS:

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

    Il valore è in genere https://adfs.domain.com/adfs.

1.3 Crea subnet globali e dividile per ogni zona

Prima di creare un'organizzazione, devi creare le subnet root globali e dividerle per ogni zona con la subnet dell'API pubblica di gestione degli indirizzi IP (IPAM). Se stai creando una nuova organizzazione v2 in una zona che in precedenza aveva un'organizzazione v1, assicurati di visualizzare la pagina Prerequisiti aggiuntivi prima di creare le subnet globali.

Le subnet root globali ospitano il pool di intervalli di indirizzi IP root (CIDR) suddiviso in ogni zona per eseguire il bootstrap di tutti i cluster all'interno dell'organizzazione tenant, inclusi il cluster di infrastruttura dell'organizzazione e le VM dei carichi di lavoro. Una piccola parte dell'intervallo di indirizzi IP viene resa disponibile anche alle subnet radice come pool di indirizzi IP anycast. Puoi assegnare automaticamente CIDR dedicati a ogni zona utilizzando un controller oppure puoi fornire manualmente i CIDR a ogni zona.

Per eseguire il bootstrap di un'organizzazione, devi inserire l'intervallo di indirizzi IP interni dal questionario di input dell'organizzazione (OIQ). Devi utilizzare questi intervalli di indirizzi IP per creare la subnet root globale nel server API globale.

Devi creare subnet radice diverse per ogni server API globale. Il mapping del campo OIQ, del nome della subnet root globale e del server API globale è fornito nella sezione successiva.

1.3.1. Definisci l'intervallo CIDR per OIQ

Gli intervalli CIDR non possono sovrapporsi tra loro e non possono sovrapporsi a zone-infra-cidr.

Il zone-infra-cidr esiste in ogni zona e può essere recuperato dal questionario di acquisizione del cliente (CIQ) se il cliente lo ha definito.

Per recuperare zone-infra-cidr, esegui:

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

Di seguito è riportato un esempio di output 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

In questo esempio, zone-infra-cidr è 192.0.2.0/24, quindi nessun campo della query OIQ deve sovrapporsi a 192.0.2.0/24.

La tabella seguente mostra i campi OIQ e i relativi valori minimi predefiniti:

Campo OIQ Descrizione Dimensioni minime richieste Dimensione minima per zona per l'organizzazione Nome della subnet principale globale Server API globale
infraVPCCIDR Carichi di lavoro di sistema, inclusi la console dell'organizzazione, le API di gestione e i servizi proprietari. \( 15 - \lceil \log_2(ZoneNumber) \rceil \) 16 infra-vpc-root-cidr Radice globale
defaultVPCCIDR Carichi di lavoro ed endpoint utente nel VPC predefinito tra le zone. \( 16 - \lceil \log_2(ZoneNumber) \rceil \) 16 default-vpc-root-cidr Organizzazione globale
orgAdminExternalCIDR Workload ed endpoint nel cluster perimetrale che gestiscono il traffico amministrativo tra la rete esterna e l'organizzazione. \( 22 - \lceil \log_2(ZoneNumber) \rceil \) 23 admin-external-root-cidr Radice globale
orgDataExternalCIDR Carichi di lavoro ed endpoint raggiungibili esternamente dagli utenti, come bilanciatori del carico esterni e NAT in uscita. \( 22 - \lceil \log_2(ZoneNumber) \rceil \) 23 data-external-root-cidr Radice globale

Se non hai abbastanza IP come minimo predefinito suggerito, devi seguire la procedura di suddivisione manuale per creare le subnet per ogni zona.

Tieni presenti le seguenti limitazioni per gli intervalli di subnet IPv4:

  • orgDataExternalCIDR, orgAdminExternalCIDR, infraVPCCIDR e defaultVPCCIDR non devono sovrapporsi tra loro, con altri intervalli allocati all'interno dell'organizzazione e con eventuali intervalli IPv4 nelle reti in peering. I CIDR per questi provengono dallo spazio di indirizzi privati RFC 1918.

    Reti in peering: possono essere qualsiasi subnet pubblicizzata con reti esterne tramite collegamenti di interconnessione o subnet in peering con altri VPC nella stessa organizzazione.

  • Se le organizzazioni condividono le stesse risorse di interconnessione AttachmentGroup, i valori orgDataExternalCIDR e orgAdminExternalCIDR devono essere univoci. In caso contrario, la sovrapposizione con altre organizzazioni è consentita.

1.3.2. Crea subnet globali nel server API di amministrazione principale globale

Prima di creare un'organizzazione, devi creare le seguenti subnet nel server API di amministrazione principale globale:

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

Queste subnet sono necessarie per eseguire il bootstrap del cluster dell'infrastruttura dell'organizzazione in ogni zona.

  1. Devi avere uno spazio dei nomi con un nome che corrisponda al nome dell'organizzazione che assegnerai alla tua organizzazione. Conferma che questo spazio dei nomi esiste:

    kubectl --kubeconfig GLOBAL_ROOT_ADMIN_KUBECONFIG get namespace

    Se questo spazio dei nomi non esiste, crealo:

    kubectl --kubeconfig GLOBAL_ROOT_ADMIN_KUBECONFIG create namespace ORG_NAME

  2. Crea il file YAML della subnet infra-vpc-root-cidr, ad esempio ORG_NAME-infra-vpc-root-cidr.yaml:

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

  3. Crea il file YAML della subnet admin-external-root-cidr, ad esempio ORG_NAME-admin-external-root-cidr.yaml:

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

  4. Crea il file YAML della subnet data-external-root-cidr, ad esempio ORG_NAME-data-external-root-cidr.yaml:

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

  5. Copia i file YAML delle subnet infra-vpc-root-cidr, admin-external-root-cidr e data-external-root-cidr nel repository IAC per l'organizzazione root:

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

  6. Assicurati che il file kustomization.yaml nella radice dell'organizzazione contenga le definizioni Subnet appena aggiunte. Controlla IAC_REPO_PATH/iac/infrastructure/global/orgs/root/kustomization.yaml:

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

  7. Esegui il commit dei file YAML della subnet:

    git add "IAC_REPO_PATH/iac/infrastructure"
git commit

  8. Crea richiesta di unione:

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

  9. Attendi la revisione del codice e l'unione.

1.3.3. Dividere le subnet radice per le zone

Le subnet root globali ospitano l'intervallo di indirizzi IP root (CIDR) per tutte le zone. Per utilizzare l'intervallo di indirizzi IP nella zona, le subnet root globali devono prima essere divise in subnet più piccole da utilizzare per le zone. Ogni zona deve avere almeno un intervallo di indirizzi IP root.

IPAM ha un controller globale che suddivide automaticamente la subnet root globale in subnet più piccole per le zone esistenti. Gli amministratori possono delegare ai controller IPAM la suddivisione automatica della subnet della zona se non si preoccupano dell'esatto blocco CIDR utilizzato da una determinata zona. Il controller monitora la creazione della subnet root globale e crea una subnet per ogni zona con una lunghezza del prefisso predefinita fissa.

Subnet radice della zona Lunghezza prefisso fissa predefinita
defaultZoneInfraVPCSubnetSize 16
defaultZoneAdminVRFSubnetSize 23
defaultZoneDataVRFSubnetSize 23
defaultZoneDefaultVPCSubnetSize 16
defaultAnycastSubnetSize 26

Le subnet radice globali devono avere nomi fissi se vuoi che i controller IPAM dividano automaticamente la subnet della zona:

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

Se imposti l'annotazione ipam.gdc.goog/pause-auto-division: true per le tue risorse Subnet, devi definire manualmente l'esatto blocco CIDR utilizzato da una determinata zona. Se crei le subnet root globali con nomi diversi, l'annotazione ipam.gdc.goog/pause-auto-division non ha effetto e le subnet globali non verranno suddivise automaticamente.

1.3.3.1. Suddividere automaticamente le subnet root per le zone

Il controller globale suddivide automaticamente la subnet radice globale in subnet più piccole per le zone esistenti. Ad esempio, considera il seguente flusso di lavoro per capire come il controller suddivide la subnet root globale in subnet più piccole per le zone esistenti:

Se esistono due zone denominate zone1 e zone2, una subnet di root globale di esempio infra-vpc-root-cidr che utilizza infraVPCCIDR, ad esempio 10.0.0.0/16, dallo spazio dei nomi OIQ in org-1 ha il seguente aspetto:

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

Quando viene eseguito il deployment sulla piattaforma GDC, il controller crea automaticamente due subnet secondarie denominate infra-vpc-zone1-root-cidr e infra-vpc-zone2-root-cidr con la lunghezza del prefisso /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. Dividere manualmente le subnet root per le zone

Questa sezione presuppone che tu abbia impostato l'annotazione ipam.gdc.goog/pause-auto-division: true quando crei le subnet root globali nel server API di amministrazione root globale. Questa annotazione mette in pausa il controller per riconciliare queste subnet root globali, consentendoti di creare manualmente la subnet root e la subnet anycast di una zona.

Per dividere manualmente la subnet root globale in subnet più piccole per le zone, completa i seguenti passaggi:

  1. Elenca le zone nel tuo universo:

    kubectl --kubeconfig GLOBAL_ROOT_ADMIN_KUBECONFIG get zone -A

  2. Conferma il CIDR dedicato della subnet principale che vuoi applicare alla tua zona. Esegui questa operazione per ogni zona del tuo universo.

  3. Assegna il CIDR dedicato alla subnet per la tua zona in un file YAML, ad esempio 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

    Ripeti questo passaggio per ogni zona del tuo universo GDC.

  4. Conferma il CIDR dedicato della subnet radice che vuoi applicare alla subnet anycast.

  5. Assegna il CIDR dedicato alla subnet anycast in un file YAML, ad esempio 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

  6. Copia i file YAML della subnet di zona nel repository IAC per l'organizzazione radice. Ad esempio, se avevi due file YAML di subnet di zona:

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

  7. Assicurati che il file kustomization.yaml nella radice dell'organizzazione contenga le definizioni Subnet appena aggiunte. Controlla IAC_REPO_PATH/iac/infrastructure/global/orgs/root/kustomization.yaml:

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

  8. Esegui il commit dei file YAML della subnet:

    git add "IAC_REPO_PATH/iac/infrastructure"
git commit

  9. Crea la richiesta di unione:

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

  10. Attendi la revisione del codice e l'unione.

1.3.3.2.1. Esempio di suddivisione manuale delle subnet radice per le zone per infra-vpc

Se esistono due zone denominate zone1 e zone2, una subnet di root globale di esempio infra-vpc-root-cidr che utilizza infraVPCCIDR, ad esempio 192.0.2.0/24, dallo spazio dei nomi OIQ in org-1 ha il seguente aspetto:

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

Crea manualmente la subnet per ogni zona denominata infra-vpc-zone1-root-cidr e infra-vpc-zone2-root-cidr e la subnet anycast infra-vpc-anycast-cidr con il CIDR dedicato che preferisci:

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

Assicurati di aggiungere tutti i file YAML della subnet al repository IAC.

1.3.3.2.2. Esempio di suddivisione manuale delle subnet radice per le zone per il segmento di rete dati

Se esistono due zone denominate zone1 e zone2, una subnet root globale di esempio data-external-root-cidr che utilizza orgDataExternalCIDR, ad esempio 10.0.0.0/24, dallo spazio dei nomi OIQ in org-1 ha il seguente aspetto:

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

Crea manualmente la subnet per ogni zona denominata data-external-zone1-root-cidr e data-external-zone2-root-cidr e la subnet anycast data-global-anycast-cidr con il CIDR dedicato che preferisci:

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

Assicurati di aggiungere tutti i file YAML della subnet al repository IAC.

1.3.3.2.3. Esempio di suddivisione manuale delle subnet radice per le zone per il segmento di rete amministrativa

Se esistono due zone denominate zone1 e zone2, una subnet root globale di esempio admin-external-root-cidr che utilizza orgAdminExternalCIDR, ad esempio 192.168.1.0/24, dallo spazio dei nomi OIQ in org-1 ha il seguente aspetto:

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

Crea manualmente la subnet per ogni zona denominata admin-external-zone1-root-cidr e admin-external-zone2-root-cidr e la subnet anycast admin-global-anycast-cidr con il CIDR dedicato che preferisci:

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

Assicurati di aggiungere tutti i file YAML della subnet al repository IAC.

1.4. Crea un'organizzazione con IAC

Utilizza IAC per creare un'organizzazione:

  1. Genera un elenco dei server e dei tipi di server disponibili:

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

    L'output di esempio è simile al seguente:

    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

    Quando specifichi --server-quota e --admin-server in un secondo momento, assicurati di avere server available sufficienti per soddisfare la richiesta.

  2. Vai al repository iac e aggiungi la struttura di directory per la nuova organizzazione:

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

  3. Crea una risorsa personalizzata Organization:

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

    Ad esempio:

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

    Sostituisci le seguenti variabili:

    VariabileDefinizione
    ORG_NAME Il nome dell'organizzazione. Il nome di un'organizzazione deve soddisfare i seguenti criteri:
    • Essere composto da 3-19 lettere ASCII minuscole, cifre o trattini.
    • Deve iniziare con una lettera.
    • Non hanno trattini finali.
    • Non deve terminare con la stringa -system.
    LOG_RETENTION_POLICY La configurazione dei tempi di conservazione per audit log, log operativi e metriche in giorni.
    KMS_ROOT_KEY_TYPE Questa configurazione contiene il tipo di chiave radice scelto per il KMS di un'organizzazione. Ogni servizio KMS ha una chiave radice per criptare le chiavi generate dal KMS. Per impostazione predefinita, il KMS genera una chiave radice CTM, una chiave radice archiviata in Thales CipherTrust Manager di cui viene eseguito il backup da un HSM fisico. Puoi anche scegliere una chiave radice software archiviata come secret Kubernetes. Passa ctm-root o local-root per kmsRootKeyType.

    Un esempio del file YAML della risorsa personalizzata Organization generato è simile al seguente:

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

  4. (Facoltativo) In versione 1.14.2 e successive, la crittografia IPsec da nodo a nodo è disattivata per impostazione predefinita. Se è necessaria questa crittografia IPsec, puoi abilitare la crittografia IPsec da nodo a nodo modificando il file YAML della risorsa personalizzata Organization e aggiungendo un'annotazione:

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

    Un valore di "false" per questa annotazione attiva la crittografia.

  5. Crea una risorsa personalizzata OrganizationZonalConfig per ogni zona del deployment:

    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

    Ad esempio:

    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

    Sostituisci le seguenti variabili:

    VariabileDefinizione
    ORG_NAME Il nome dell'organizzazione. Il nome di un'organizzazione deve soddisfare i seguenti criteri:
    • Essere composto da 3-30 lettere ASCII minuscole, cifre o trattini.
    • Deve iniziare con una lettera.
    • Non hanno trattini finali.
    • Non deve terminare con la stringa -system.
    ZONES I nomi delle zone nel deployment.
    GDC_VERSION La versione del sistema GDC per cui creare l'organizzazione.
    SERVER_QUOTA I server da allocare per il cluster di amministrazione dell'organizzazione e il cluster di sistema quando vengono generati automaticamente. Se intendi eseguire risorse di unità di elaborazione grafica (GPU) che sono workload basati su VM, come API di intelligenza artificiale e machine learning (AI/ML) preaddestrate, devi eseguire il provisioning delle macchine GPU quando crei un'organizzazione. Per ulteriori informazioni, consulta la sezione Abilitare il supporto GPU per i cluster di sistema.
    ADMIN_SERVER Una coppia chiave-valore del tipo di server e della quantità di server di amministrazione dell'organizzazione da allocare per quel tipo di server. I tipi misti non sono supportati per i server. Il valore predefinito è o1-standard1-64-gdc-metal: 3.
    STORAGE_SIZE Le dimensioni dei diversi tipi di spazio di archiviazione da assegnare all'organizzazione. La dimensione minima dello spazio di archiviazione a blocchi per un'organizzazione è 250 Gi, che viene impostata con il flag BlockStandard.

    Un esempio del file YAML della risorsa personalizzata OrganizationZonalConfig generato è simile al seguente:

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

  6. Esamina i file YAML generati. I file si trovano nella directory HOME.

    1. Conferma il tipo di organizzazione. Puoi eseguire il provisioning di due tipi di organizzazione:

      • Architettura dell'organizzazione v1 (organizzazione v1)
      • Architettura dell'organizzazione v2 (organizzazione v2)

      Per impostazione predefinita, le nuove organizzazioni vengono sottoposte a provisioning in base al tipo di deployment impostato dalle impostazioni dei feature gate:

      • Per impostazione predefinita, i deployment di PRODUCTION generano organizzazioni v2.
      • ACCREDITED deployment generano organizzazioni v1 per impostazione predefinita.

      Nel raro caso in cui devi ignorare il tipo di organizzazione predefinito per il tuo tipo di deployment, aggiorna il campo spec.compatibilityOptions.architectureOverridePolicy nella risorsa personalizzata Organization generata con ForceV1 o ForceV2, a seconda del tipo di organizzazione che vuoi utilizzare. Ad esempio, il seguente snippet forza la creazione di un'organizzazione v2 in un deployment ACCREDITED:

      ...

spec:
...
  compatibilityOptions:
    architectureOverridePolicy: ForceV2

...

    2. Conferma le impostazioni rimanenti per assicurarti che componenti come lo spazio di archiviazione e la potenza di calcolo siano sufficienti per le esigenze della tua azienda.

  7. Copia le risorse personalizzate Organization e OrganizationZonalConfig nel repository nella directory della nuova organizzazione:

    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/

    Sostituisci quanto segue:

    • ORG_NAME: il nome dell'organizzazione definito nel comando gdcloud organizations config create utilizzando il parametro --name.
    • ZONE: il nome di ogni zona nel deployment. Il nome della zona viene derivato utilizzando il seguente formato: {generalRegion}-{regionQualifier}{regionCounter}-{zoneLetter}. Ad esempio: us-central1-b. Consulta la sezione Zona nel questionario di acquisizione del cliente per le descrizioni dei valori dell'attributo zona.

  8. Aggiungi il file kustomization.yaml per la nuova organizzazione:

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

  9. Aggiungi la nuova organizzazione come risorsa dell'organizzazione principale:

    1. Apri il file kustomization.yaml della radice globale:

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

    2. Aggiungi il nuovo Organization come risorsa alla fine dell'elenco di risorse esistente:

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

  10. Esegui il commit del file YAML dell'organizzazione e dei file kustomize:

    git add "IAC_REPO_PATH/iac/infrastructure"
git commit

  11. Crea richiesta di unione:

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

  12. Attendi la revisione del codice e l'unione.

  13. Verifica che siano disponibili le configurazioni globali e di zona dell'organizzazione:

    1. Verifica che l'organizzazione globale sia disponibile nel tuo universo GDC:

      kubectl get organization -A

      L'output è simile al seguente:

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

    2. Controlla lo stato dell'organizzazione globale:

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

      Assicurati che le condizioni status nell'output YAML siano True.

    3. Controlla lo stato della configurazione dell'organizzazione in ogni zona:

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

      Per cambiare contesto zonale, utilizza gcloud CLI per accedere a ogni zona prima di controllare lo stato dell'organizzazione. Assicurati che le condizioni status nell'output YAML per ogni zona siano True.

1.5. Crea subnet globali nel server API dell'organizzazione globale

Devi creare default-vpc-root-cidr nel server API globale dell'organizzazione all'interno dello spazio dei nomi platform dopo l'esecuzione del server API globale. Questa subnet radice alloca l'indirizzo IP per i cluster all'interno dell'organizzazione tenant, ad esempio i cluster utente, nonché gli indirizzi IP per i carichi di lavoro VM.

  1. Crea il file YAML della subnet default-vpc-root-cidr, ad esempio default-vpc-root-cidr.yaml:

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

  2. Vai al repository iac e aggiungi la struttura di directory per l'organizzazione globale:

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

  3. Copia il file YAML della subnet default-vpc-root-cidr nel repository IAC nella directory della nuova organizzazione:

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

  4. Crea il file kustomization.yaml nella cartella dell'organizzazione con le definizioni Subnet appena aggiunte. Controlla IAC_REPO_PATH /iac/infrastructure/global/orgs/ORG_NAME/kustomization.yaml:

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

  5. Esegui il commit del file YAML dell'organizzazione e dei file kustomize:

    git add "IAC_REPO_PATH/iac/infrastructure"
git commit

  6. Crea la richiesta di unione:

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

  7. Attendi la revisione del codice e l'unione.

Analogamente a come vengono suddivise le subnet globali nel cluster di amministrazione root globale, anche default-vpc-root-cidr viene suddiviso e propagato a ogni zona in modo che l'organizzazione zonale possa utilizzare gli indirizzi IP.

1.7. Configura NTPRelay per l'amministratore dell'organizzazione

Devi configurare manualmente l'autenticazione tra i NTPRelay root-admin e org-admin.

Segui NTP-P0001.3 (Root Admin -> Org Admin NTPRelay Encryption) per configurare la crittografia per questa organizzazione.

1.8. Connetti il provider di identità IO all'organizzazione con IAC

  1. Consulta la guida ADFS per creare un client OIDC in ADFS per la nuova organizzazione e annota l'ID client e il client secret del client OIDC.

  2. Imposta il nome dell'organizzazione come variabile di ambiente:

    export ORG_NAME=ORG_NAME

    Verifica che ORG_NAME corrisponda esattamente al nome dell'organizzazione.

  3. Esporta il file kubeconfig del cluster di amministrazione principale ed esegui questi comandi kubectl per ottenere i nomi del cluster e della zona:

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

  4. Aggiungi il file ioauthmethod.yaml per l'organizzazione:

    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

    Sostituisci le seguenti variabili:

    VariabileDefinizione
    ADFS_CERT_BASE64 La codifica Base64 del certificato utilizzato da ADFS per l'autofirma, che GKE Identity Service richiede per stabilire una connessione sicura con un'istanza ADFS interna.
    ADFS_ORG_CLIENT_ID L'ID OpenID Connect per il client dell'organizzazione in ADFS.
    ADFS_ORG_CLIENT_SECRET Il secret OpenID Connect per il client dell'organizzazione registrato in ADFS.
    ADFS_ISSUER_URI Un URI emittente valido, richiesto dal servizio di identità GKE per consentire le richieste di accesso con reindirizzamento ad ADFS.

  5. Aggiungi il file initial-admin.yaml per l'organizzazione:

    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

    Sostituisci le seguenti variabili:

    VariabileDefinizione
    USER Il nome utente con il prefisso dell'IO per accedere inizialmente al cluster. Ricorda di aggiungere il prefisso al nome utente.
    EXPIRATION Il timestamp formattato RFC 3339 in corrispondenza del quale il sistema revoca l'accesso. Ad esempio, "2020-11-14T00:20:12+00:00".

  6. Aggiungi i file appena creati al file kustomization.yaml in IAC_REPO_PATH /iac/infrastructure/global/orgs/ORG_NAME/kustomization.yaml:

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

  7. Esegui il commit del file YAML dell'organizzazione e dei file kustomize:

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

  8. Esegui il push dell'aggiornamento su GitLab:

    git -c http.sslVerify=false push

  9. Attendi la revisione del codice e l'unione.

  10. Per confermare che l'operatore può accedere all'organizzazione, accedi all'organizzazione generata ed esegui il seguente comando per verificare che esista un provider di identità (IdP) in ClientConfig dell'organizzazione:

    1. Imposta il file kubeconfig del cluster di amministrazione in base all'architettura della tua organizzazione:

      • Per un'organizzazione v1, esegui:

        export KUBECONFIG=ORG_ADMIN_CLUSTER_KUBECONFIG

        Sostituisci ORG_ADMIN_CLUSTER_KUBECONFIG con il percorso del file kubeconfig del cluster di amministrazione dell'organizzazione, ad esempio /tmp/${ORG}-admin-kubeconfig.

      • Per un'organizzazione v2, esegui:

        export KUBECONFIG=ORG_INFRA_CLUSTER_KUBECONFIG

        Sostituisci ORG_INFRA_CLUSTER_KUBECONFIG con il percorso del file kubeconfig del cluster dell'infrastruttura dell'organizzazione, ad esempio /tmp/${ORG}-infra-kubeconfig.

    2. Verifica che esista un IdP nel ClientConfig dell'organizzazione:

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

  11. Per la versione 1.14.3, devi applicare manualmente il ruolo global-zone-viewer per consentire a tutti gli utenti autenticati di visualizzare le zone in un universo utilizzando gcloud CLI. Applica le risorse di ruolo e associazione di ruolo:

    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

    Sostituisci ORG_GLOBAL_API_SERVER_KUBECONFIG con il file kubeconfig del server API globale dell'organizzazione. Per ulteriori informazioni, consulta Generare manualmente il file kubeconfig.

1.9. Connetti il provider di identità del cliente all'organizzazione

Per connettere un provider di identità (IdP) del cliente all'organizzazione e accedere all'organizzazione con le sue identità, completa i seguenti passaggi:

  1. Accedi dalla CLI con l'account amministratore IO iniziale impostato durante la creazione dell'organizzazione, che viene associato automaticamente a org-iam-admin nel cluster di amministrazione dell'organizzazione.

  2. Chiedi al cliente di aggiungere il seguente URL di callback AIS globale all'allowlist nel client OIDC o SAML che ha creato per l'organizzazione che stai per creare:

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

    Ad esempio, se l'URL principale di GDC è .google.gdch.test e il nome dell'organizzazione è operations, l'URL di callback AIS globale è https://ais-core.operations.google.gdch.test/finish-login.

    Se utilizzi un client SAML, devi anche aggiungere il seguente URL di callback SAML globale di AIS alla lista consentita:

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

  3. Chiedi al cliente di aggiungere il seguente URL di callback AIS all'allowlist nel client OIDC o SAML creato per ogni zona. Ad esempio, per un universo a tre zone, gli URL di callback AIS a livello di zona sono simili ai seguenti:

    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

    Se l'URL radice di GDC è .google.gdch.test, il nome della zona è zone-1 e il nome dell'organizzazione è operations, l'URL di callback AIS è https://ais-core.operations.zone-1.google.gdch.test/finish-login.

    Se utilizzi un client SAML, devi anche aggiungere i seguenti URL di callback SAML AIS alla lista consentita per ogni zona:

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

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

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

  4. Imposta il file kubeconfig del cluster di amministrazione in base all'architettura della tua organizzazione. Se hai già impostato la variabile kubeconfig, salta questo passaggio.

    • Per un'organizzazione v1, esegui:

        export KUBECONFIG=ORG_ADMIN_CLUSTER_KUBECONFIG

      Sostituisci ORG_ADMIN_CLUSTER_KUBECONFIG con il percorso del file kubeconfig del cluster di amministrazione dell'organizzazione, ad esempio /tmp/${ORG}-admin-kubeconfig.

    • Per un'organizzazione v2, esegui:

        export KUBECONFIG=MANAGEMENT_API_SERVER_KUBECONFIG

      Sostituisci MANAGEMENT_API_SERVER_KUBECONFIG con il percorso di kubeconfig del server API Management, ad esempio /tmp/${ORG}-management-kubeconfig.

  5. Dal ticket di richiesta del cliente per una nuova organizzazione, decidi se l'IdP utilizza OIDC o SAML. Segui la guida che corrisponde al tipo di IdP specificato:

Configurazione con OIDC

  1. Crea un file identity-provider-config.yaml e compilalo facendo riferimento ai ticket di creazione dell'organizzazione per i valori dell'IdP dell'amministratore dell'account:

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

  2. Di seguito sono riportate le descrizioni dettagliate dei campi:

    Attributo Tipo di attributo Descrizione
    certificateAuthorityData Obbligatorio Un certificato dell'autorità di certificazione con codifica Base64 e formato PEM standard per il provider OIDC.
    clientID Obbligatorio L'ID per l'applicazione client che effettua richieste di autenticazione al provider OpenID.
    clientSecret Obbligatorio Il secret condiviso tra l'applicazione client OIDC e il provider OIDC.
    extraParams Facoltativo Un elenco separato da virgole di coppie chiave-valore che sono codificate come query e inviate con la richiesta dell'endpoint di autenticazione.
    groupPrefix Facoltativo Il prefisso da anteporre all'attestazione dei gruppi per evitare conflitti con i gruppi esistenti, in genere utilizzato quando si configurano più provider di identità.
    Devi includere il prefisso del gruppo prima di tutti i nomi dei gruppi. Ad esempio, se hai myprefix- come prefisso del gruppo e un gruppo denominato groupA nel tuo provider di identità, quando aggiungi una policy o un binding, devi eseguire il binding di myprefix-groupA. Il nome del gruppo è impostato nel campo groupsClaim.
    groupsClaim Facoltativo Il nome dell'attestazione nel token ID OIDC che contiene le informazioni sui gruppi dell'utente. Questo nome deve corrispondere a quello dell'attestazione che contiene le informazioni sull'appartenenza al gruppo nel tuo provider OIDC.
    issuerURI Obbligatorio L'URL a cui vengono inviate le richieste di autorizzazione al tuo provider OIDC. Questo URI deve indirizzare al livello all'interno di .well-known/openid-configuration.
    scopes Facoltativo Un elenco separato da virgole di identificatori per specificare quali privilegi di accesso vengono richiesti oltre all'ambito openid.
    userClaim Obbligatorio Il nome dell'attestazione nel token ID OIDC che contiene il nome utente. Ad esempio, se l'attestazione utente è email, gli utenti vengono identificati dal campo utente nel token OIDC.
    Se questo valore non è presente nel token ID, l'autenticazione non va a buon fine.
    userPrefix Facoltativo Il prefisso da anteporre alle attestazioni utente per evitare conflitti con i nomi utente esistenti, in genere utilizzato quando si configurano più provider di identità.
    Ad esempio, se l'attributo utente è email e il prefisso utente è prefix-, gli utenti vengono identificati come prefix-sally@example.com. L'utente è sally@example.com e il prefisso, prefix-, viene aggiunto all'utente per distinguere i diversi provider di identità.
    Si consiglia di inserire un separatore alla fine del prefisso, come descritto in precedenza in questa tabella per l'impostazione groupPrefix.

  3. (Facoltativo) Se il tuo provider di identità utilizza attributi personalizzati, configura prima gli attributi nel tuo IdP. Poi aggiungi le coppie chiave-valore corrispondenti nella sezione oidc del file identity-provider-config.yaml per ulteriori rivendicazioni relative a utenti o gruppi, ad esempio il reparto o la data di nascita. Quando applichi le modifiche alla configurazione del provider di identità, GKE Identity Service riconosce gli attributi personalizzati. Ecco un esempio di attributi personalizzati:

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

  4. Configura la configurazione del provider di identità:

    kubectl apply -f identity-provider-config.yaml

  5. Attendi la riconfigurazione dei vari componenti del sistema.

  6. Verifica la configurazione aprendo la console dell'interfaccia utente di amministrazione della piattaforma in un browser web. Seleziona Accedi con pa-idp-oidc dalla pagina di reindirizzamento. Se viene eseguito il reindirizzamento all'istanza IdP dell'account PA e dopo l'accesso con l'istanza IdP dell'account PA viene eseguito il reindirizzamento alla pagina della console dell'interfaccia utente amministratore della piattaforma, la configurazione è riuscita. In caso contrario, controlla i valori in identity-provider-config.yaml e ripeti il passaggio precedente.

Configurazione con SAML

  1. Crea un file identity-provider-config.yaml e compilalo facendo riferimento ai ticket di creazione dell'organizzazione per i valori dell'IDP dell'account PA:

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

  2. Di seguito sono riportate le descrizioni dettagliate dei campi:

    .
    Attributo Tipo di attributo Descrizione
    idpCertificateDataList Obbligatorio I certificati IdP utilizzati per verificare la risposta SAML. Questi certificati devono essere codificati in base64 standard e in formato PEM. Per facilitare la rotazione dei certificati del provider di identità, sono supportati al massimo due certificati.
    idpEntityID Obbligatorio L'ID entità SAML per il provider SAML, specificato in formato URI. Ad esempio, https://www.idp.com/saml.
    idpSingleSignOnURI Obbligatorio L'URI dell'endpoint SSO del provider SAML. Ad esempio, `https://www.idp.com/saml/sso`.
    groupPrefix Facoltativo Il prefisso facoltativo da anteporre a ogni nome del gruppo.
    userPrefix Facoltativo Il prefisso facoltativo da anteporre al nome utente.
    userAttribute Facoltativo Il nome dell'attributo nella risposta SAML che contiene il nome utente. Se questo attributo non è presente nella risposta SAML, l'autenticazione non riesce.
    groupsAttribute Facoltativo Il nome dell'attributo nella risposta SAML che contiene i gruppi dell'utente.

  3. (Facoltativo) Se il tuo provider di identità utilizza attributi personalizzati, configura prima gli attributi nel tuo IdP. Poi aggiungi le coppie chiave-valore corrispondenti nella sezione saml del file identity-provider-config.yaml per ulteriori rivendicazioni relative a utenti o gruppi, ad esempio il reparto o la data di nascita. Quando applichi le modifiche alla configurazione del provider di identità, GKE Identity Service riconosce gli attributi personalizzati. Ecco un esempio di attributi personalizzati:

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

  4. Configura la patch di configurazione del provider di identità:

    kubectl apply -f identity-provider-config.yaml

  5. Attendi la riconfigurazione dei vari componenti del sistema.

  6. Verifica la configurazione aprendo la console dell'interfaccia utente di amministrazione della piattaforma in un browser web. Seleziona Log in with pa-idp-oidc (Accedi con pa-idp-oidc) dalla pagina di reindirizzamento. Se viene eseguito il reindirizzamento all'istanza IdP dell'account PA e dopo l'accesso con l'istanza IdP dell'account PA viene eseguito il reindirizzamento alla pagina della console dell'interfaccia utente amministratore della piattaforma, la configurazione è riuscita. In caso contrario, controlla i valori in identity-provider-config.yaml e ripeti il passaggio precedente.

Prefisso utente e gruppo

I prefissi di utenti e gruppi devono essere impostati per ogni IdP in Distributed Cloud per evitare conflitti di denominazione tra account di IdP diversi. Il prefisso viene utilizzato con il nome dell'utente e del gruppo per concatenare il nome del soggetto nei binding dei ruoli nel cluster. Ad esempio, per un utente con nome jack@example.com, e il prefisso utente dell'IdP è example-org-idp-, il nome del soggetto nel cluster sarebbe example-org-idp-jack@example.com.

Per decidere il valore del prefisso:

  • Includi il livello della gerarchia (radice, organizzazione, progetto).
  • Includi il nome dell'IdP (adfs, keycloak).
  • Ti consigliamo di aggiungere un carattere separatore come - come suffisso perché non viene aggiunto alcun separatore tra il prefisso e il nome utente.

Assegnare l'amministratore iniziale

Per concedere l'accesso iniziale all'organizzazione, il PA deve essere assegnato come amministratore dell'organizzazione. Per assegnare il PA come amministratore iniziale, crea un IAMRoleBinding nel server API globale:

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 Stabilisci la connettività di rete per l'organizzazione

Un'organizzazione appena creata è isolata e non è possibile accedervi da nessuna rete esterna. Per rendere operativa l'organizzazione, devi connetterla a una o più reti esterne utilizzando il servizio Interconnect.

Questo processo prevede la configurazione di un insieme di risorse personalizzate che definiscono la connessione logica. Di seguito sono riportati due scenari comuni per fornire la connettività a una nuova organizzazione.

Scenario 1: collegamento di un'organizzazione a un interconnessione condivisa esistente

Se hai un interconnessione esistente per una rete condivisa, devi solo aggiornare AttachmentGroup e RoutePolicy per includere la nuova organizzazione.

  1. Aggiorna AttachmentGroup: un AttachmentGroup specifica quali organizzazioni possono utilizzare un insieme di collegamenti VLAN. Modifica il file YAML AttachmentGroup e aggiungi la nuova organizzazione all'elenco spec.entities. Per un'organizzazione v2, devi specificare la rete domainType (OrgAdmin, OrgData o OrgMixed) a cui connetterti.

    Esempio di aggiornamento AttachmentGroup:

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

  2. Aggiorna il RoutePolicy: Un RoutePolicy definisce i prefissi IP pubblicizzati. Modifica la policy e aggiungi le subnet IP esterni per la nuova organizzazione a spec.out.ipPrefixList. In questo modo, il traffico in entrata può raggiungere l'organizzazione.

    Esempio di aggiornamento RoutePolicy:

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

  3. Applica le modifiche utilizzando kubectl apply con il processo Infrastructure as Code (IaC).

Scenario 2: creazione di una nuova interconnessione dedicata

Per una connessione dedicata, devi creare un nuovo insieme di risorse di interconnessione. L'intero processo prevede la creazione di cinque risorse personalizzate in ordine.

  1. Crea un InterconnectLink per ogni nuova connessione fisica.
  2. Crea un InterconnectGroup per raggruppare i link fisici e consentire la nuova organizzazione.
  3. Crea un AttachmentGroup e specifica la nuova organizzazione nell'elenco entities.
  4. Crea un RoutePolicy che consenta i prefissi IP in entrata e in uscita per questa connessione dedicata.
  5. Crea una o più risorse InterconnectAttachment per definire le VLAN e le sessioni BGP.

Per esempi completi e passaggi dettagliati per ciascuna di queste risorse, consulta la documentazione Configurare un'interconnessione.

1.11 Configurare il webhook di Alertmanager per connettersi a ServiceNow

Segui i passaggi descritti in MON-T0016 per connettere il webhook di Alertmanager a ServiceNow per la creazione di incident.

1.12 Configura il listino prezzi di fatturazione per l'organizzazione

Il sottocomponente Fatturazione per un'organizzazione richiede che i prodotti o i servizi da fatturare siano configurati con la risorsa personalizzata SKUDescription. Un singolo SKUDescription descrive un singolo prodotto o servizio da fatturare insieme al relativo prezzo. Una raccolta di oggetti SKUDescription può quindi essere considerata il listino prezzi di un'organizzazione. I passaggi seguenti configurano il prospetto dei prezzi per l'organizzazione in IAC.

1.12.1 Ottenere il prospetto dei prezzi

Se non disponi già delle risorse del foglio dei prezzi SKUDescription per un'organizzazione, contatta l'Ufficio di gestione del programma (PMO) per ottenere il foglio dei prezzi. Il prospetto dei prezzi deve essere una serie di file YAML contenenti risorse SKUDescription.

1.12.2 Determinare se il listino prezzi è condiviso o meno

Il prospetto dei prezzi può essere condiviso tra tutte le organizzazioni o configurato per ogni organizzazione. L'Ufficio di gestione del progetto può informarti se il foglio dei prezzi è condiviso o meno.

1.12.2.1 Foglio prezzi condiviso

Se il prospetto dei prezzi è condiviso, inseriscilo nella cartella IAC condivisa common-data.

  1. Se questa organizzazione non è la prima a essere creata, il foglio dei prezzi potrebbe già esistere nella cartella condivisa common-data. Se il foglio dei prezzi esiste, verifica che siano stati seguiti i passaggi 2-4 e procedi con il passaggio 5.

  2. Crea la cartella condivisa per il foglio prezzi.

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

    Sostituisci IAC_REPO_PATH con il percorso del repository IAC.

  3. Salva le risorse YAML del foglio dei prezzi SKUDescription in questa cartella. Successivamente, la cartella skudescriptions deve contenere file YAML separati per area. Configura la struttura delle cartelle e i file YAML in modo che siano in linea con il tuo caso d'uso della fatturazione:

    • Fatturazione gestita dal partner: Google addebita l'importo al partner. Colloca le risorse SKUDescription nello spazio dei nomi partner-billing-system.

    • Fatturazione cliente: il partner addebita l'importo all'utente finale. Colloca le risorse SKUDescription nello spazio dei nomi billing-system.

    Gli esempi riportati di seguito mostrano le strutture dei file dei modelli di fatturazione sia per la fatturazione dei clienti sia per quella gestita dai partner. Per ogni modello, vengono visualizzati due servizi, di calcolo e di archiviazione, con due file YAML per ogni servizio:

    Fatturazione cliente:

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

    Fatturazione gestita dal partner:

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

  4. Verifica che nella directory sia presente un file kustomization.yaml che includa tutti i file YAML del listino prezzi 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

  5. Esporta la variabile di ambiente ORG_CLUSTER:

    • Per un'organizzazione v1, esegui:

      export ORG_CLUSTER=ORG_ADMIN_CLUSTER_NAME

    • Per un'organizzazione v2, esegui:

      export ORG_CLUSTER=ORG_INFRA_CLUSTER_NAME

  6. Crea la directory di fatturazione skudescriptions nell'organizzazione:

    • Per un'organizzazione v1:

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

    • Per un'organizzazione v2:

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

    Sostituisci ORG_CLUSTER_NAME con il nome del cluster di amministrazione dell'organizzazione, a seconda del tipo di versione dell'organizzazione.

  7. Includi il listino prezzi comune nell'organizzazione:

    • Per un'organizzazione 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

    • Per un'organizzazione v2:

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

  8. Esegui il commit del file YAML e personalizza i file:

    cd IAC_REPO_PATH
git add "iac"
git commit

  9. Esegui il push dell'aggiornamento su GitLab:

    git -c http.sslVerify=false push

  10. Attendi la revisione del codice e l'unione.

  11. Verifica che gli oggetti SKUDescription esistano nel cluster specificato per il tuo modello di fatturazione corrispondente.

    Esporta il valore KUBECONFIG in base al tipo di organizzazione.

    • Per un'organizzazione v1, esegui:

      export KUBECONFIG=ORG_ADMIN_CLUSTER_KUBECONFIG

      Sostituisci ORG_ADMIN_CLUSTER_KUBECONFIG con il percorso del file kubeconfig del cluster di amministrazione dell'organizzazione, ad esempio /tmp/${ORG}-admin-kubeconfig.

    • Per un'organizzazione v2, esegui:

      export KUBECONFIG=MANAGEMENT_API_SERVER_KUBECONFIG

      Sostituisci MANAGEMENT_API_SERVER_KUBECONFIG con il percorso di kubeconfig del server API Management, ad esempio /tmp/${ORG}-management-kubeconfig.

    Esegui l'interfaccia a riga di comando kubectl:

    Per la fatturazione cliente:

    
kubectl get SKUDescription -n billing-system

    Per la fatturazione partner:

    
kubectl get SKUDescription -n partner-billing-system

1.12.2.2 Foglio dei prezzi specifico dell'organizzazione

Se il prospetto dei prezzi è specifico per un'organizzazione, devi inserirlo nella cartella del cluster dell'organizzazione.

  1. Crea la directory di fatturazione skudescriptions nel cluster dell'organizzazione:

    • Per un'organizzazione v1:

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

    • Per un'organizzazione v2:

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

  2. Salva le risorse YAML del foglio dei prezzi SKUDescription in questa cartella. Successivamente, la cartella skudescriptions deve contenere file YAML separati per area. Nell'esempio seguente, vengono visualizzati due servizi, compute e storage, con due file YAML ciascuno:

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

  3. Assicurati che nella directory sia presente un file kustomization.yaml che includa tutti i file YAML del listino prezzi SKUDescription.

    • Per un'organizzazione 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

    • Per un'organizzazione v2:

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

  4. Assicurati che il file kustomization.yaml nella radice dell'organizzazione contenga la cartella bil/skudescriptions appena aggiunta. Controlla IAC_REPO_PATH/iac/infrastructure/zonal/zones/ZONE_NAME/ORG_CLUSTER_NAME/kustomization.yaml per un'organizzazione v1 e IAC_REPO_PATH/iac/infrastructure/zonal/zones/ZONE_NAME/ORG_CLUSTER_NAME-management/kustomization.yaml per un'organizzazione v2 :

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

  5. Esegui il commit e il trasferimento temporaneo del file YAML e dei file kustomize:

    cd IAC_REPO_PATH
git add "iac"
git commit

  6. Esegui il push dell'aggiornamento su GitLab:

    git -c http.sslVerify=false push

  7. Attendi la revisione del codice e l'unione.

  8. Verifica che gli oggetti SKUDescription esistano nel cluster specificato:

    • Per un'organizzazione v1, esegui:

      export KUBECONFIG=ORG_ADMIN_CLUSTER_KUBECONFIG

kubectl get SKUDescription -n billing-system

      Sostituisci ORG_ADMIN_CLUSTER_KUBECONFIG con il percorso del file kubeconfig del cluster di amministrazione dell'organizzazione, ad esempio /tmp/${ORG}-admin-kubeconfig.

    • Per un'organizzazione v2, esegui:

      export KUBECONFIG=MANAGEMENT_API_SERVER_KUBECONFIG

kubectl get SKUDescription -n billing-system

      Sostituisci MANAGEMENT_API_SERVER_KUBECONFIG con il percorso di kubeconfig del server API Management, ad esempio /tmp/${ORG}-management-kubeconfig. .

1.13 Create Billing recurring usages

Distributed Cloud offre stock keeping unit (SKU) che comportano addebiti ricorrenti. Tuttavia, Distributed Cloud non tiene traccia dei costi di utilizzo per determinati SKU. Per gestire queste informazioni, utilizza la risorsa RecurringUsage. Per dettagli e istruzioni sulla creazione di utilizzi ricorrenti, vedi Creare utilizzi ricorrenti.

1.14 Configurare la fatturazione per un'organizzazione

Il sottocomponente di fatturazione non inizia a calcolare i costi per un'organizzazione finché non viene raggiunta l'ora di inizio della fatturazione. L'ora di inizio fatturazione ha un valore predefinito di 9999-01-01T00:00:00-07:00. Pertanto, dopo che un'organizzazione è considerata pronta, l'IO esegue l'override dell'ora di inizio della fatturazione per avviare il workflow di fatturazione.

1.14.1 Ottieni l'ora di inizio della fatturazione

L'ora di inizio della fatturazione deve corrispondere all'inizio del periodo di esecuzione, disponibile nel contratto. Se non hai ancora l'ora di inizio della fatturazione per un'organizzazione, contatta l'Ufficio di gestione del programma (PMO) per ottenere le informazioni.

1.14.2 Mappa l'account di pagamento della fatturazione a un'organizzazione

Gli ambienti air-gap di Google Distributed Cloud (GDC) richiedono un account di fatturazione per monitorare i costi per progetti e organizzazioni. Se non colleghi un account di fatturazione a un'organizzazione o a un progetto, perderai i dati sui costi associati alla risorsa.

Per addebitare l'utilizzo del servizio al cliente, tutti gli account di fatturazione all'interno di un'organizzazione utilizzano un unico listino prezzi.

1.14.2.1 Prima di iniziare

Prima di continuare, chiedi all'Amministratore sicurezza di concederti i seguenti ruoli obbligatori. Questi ruoli vengono associati allo spazio dei nomi del progetto per la fatturazione a livello di progetto o allo spazio dei nomi della piattaforma per la fatturazione a livello di organizzazione:

  • Amministratore account di fatturazione dell'organizzazione: crea, gestisci e associa la risorsa BillingAccount. Chiedi all'Amministratore sicurezza di concederti il ruolo organization-billing-account-admin.

  • Utente dell'account di fatturazione dell'organizzazione: legge, elenca e associa la risorsa BillingAccount. Chiedi all'Amministratore sicurezza di concederti il ruolo organization-billing-account-user.

  • Gestore account di fatturazione dell'organizzazione: legge, elenca, crea e aggiorna la risorsa BillingAccountBinding. Chiedi all'Amministratore sicurezza di concederti il ruolo organization-billing-manager.

1.14.2.2 Crea un nuovo account di fatturazione

Un account di fatturazione è identificato in modo univoco dal suo name e dal suo namespace. Per creare un account di fatturazione, utilizza una risorsa personalizzata per stabilire name e namespace:

  1. Crea un file YAML e aggiungi la risorsa personalizzata BillingAccount e i seguenti contenuti:

    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"

    Sostituisci le seguenti variabili:

    • BIL_ACCOUNT_NAME: il nome dell'account di fatturazione. Ad esempio. test-billing-account.
    • BIL_DISPLAY_NAME: il nome visualizzato dell'account di fatturazione. Ad esempio. "Test Billing Account".

  2. Verifica il tipo di configurazione dei pagamenti. Gli account di fatturazione Distributed Cloud devono avere una delle seguenti configurazioni di pagamento:

    • cloudBillingConfig: la configurazione di pagamento predefinita. Questa configurazione memorizza un ID account di fatturazione Cloud.

    • customConfig: una configurazione personalizzata per i partner per memorizzare la configurazione di pagamento per fatturare all'organizzazione. customConfig supporta un dizionario di stringhe chiave-valore, con una chiave obbligatoria payment-config-type.

    Gli esempi seguenti mostrano snippet di file YAML BillingAccount per diverse configurazioni di pagamento:

    cloudBillingConfig

    spec:
  paymentSystemConfig:
    cloudBillingConfig:
      accountID: CLOUD_BILLING_ACCOUNT_ID

    Sostituisci CLOUD_BILLING_ACCOUNT_ID con l'Google Cloud ID account di fatturazione.

    customConfig

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

    Sostituisci PAYMENT_CONFIG_TYPE con il tipo di configurazione di pagamento scelto per la configurazione di fatturazione personalizzata.

    Se non disponi delle informazioni per la configurazione customConfig della tua organizzazione, inserisci i seguenti dettagli:

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

    Il seguente file YAML mostra una risorsa BillingAccount completa con la configurazione cloudBillingConfig:

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

  3. Salva il file YAML della risorsa personalizzata. Esegui l'interfaccia a riga di comando di kubectl per applicare la risorsa nel cluster dell'organizzazione per l'organizzazione o il progetto specifico a cui vuoi addebitare i costi:

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

Per collegare un'organizzazione a un BillingAccount:

  1. Aggiungi i seguenti contenuti al file YAML billingaccountbinding.yaml:

    • Nella sezione billingAccountRef, compila il campo name con i contenuti del campo name del BillingAccount che vuoi collegare.
    • Nella sezione metadata, compila il campo namespace con i contenuti del campo identico nella risorsa BillingAccount. In questo esempio, lo spazio dei nomi dell'organizzazione è platform:
    apiVersion: billing.gdc.goog/v1
kind: BillingAccountBinding
metadata:
  name: billing
  namespace: platform
spec:
  billingAccountRef:
    name: BIL_ACCOUNT_NAME
    namespace: platform

  2. Applica il file billingaccountbinding.yaml:

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

1.14.3 Prima di iniziare

Prima di continuare, chiedi all'Amministratore sicurezza di concederti il ruolo Bil Monitor (bil-monitor) nel cluster di amministrazione dell'organizzazione per lo spazio dei nomi billing-system. Questa autorizzazione ti consente di leggere le risorse correlate per la convalida.

1.14.4 Sostituisci l'ora di inizio della fatturazione

  1. Crea due file YAML con i seguenti percorsi:

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

      • Crea le sottodirectory necessarie per ogni file se non sono presenti.

  2. Aggiungi la risorsa SubcomponentOverride e i seguenti contenuti a ogni file:

    Per la fatturazione cliente:

    • File 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

    • File 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

    Per la fatturazione gestita dal partner:

    • Aggiungi il flag enablePartnerBilling: true alla fine di ogni file YAML:

    • File 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

    • File 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

    Sostituisci le seguenti variabili:

    • ORG_NAME: il nome dell'organizzazione. Ad esempio: org-1.

    • BILLING_START_TIME: il timestamp per avviare il flusso di lavoro di fatturazione.Il timestamp deve seguire il formato RFC 3339. Ad esempio, se il flusso di lavoro di fatturazione inizia il 01/01/2024 con il fuso orario del Pacifico (UTC-8) di Stati Uniti e Canada, aggiungi il valore del timestamp come 2024-01-01T00:00:00-08:00.

    • BILLING_TIMEZONE: il fuso orario del flusso di lavoro di fatturazione. Il fuso orario deve seguire il formato RFC 3339. Ad esempio, se il fuso orario di fatturazione è il fuso orario standard della costa del Pacifico degli Stati Uniti e del Canada (UTC-8), aggiungi il valore del fuso orario come PST8PDT.

    • File 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

    • File bil-invoice-override-mp.yaml:

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

  3. Salva e archivia i file YAML nella cartella infrastructure/zonal/zones/ZONE_NAME/root-admin/components/bil/ORG_NAME.

  4. Crea una richiesta di pull contenente i file YAML insieme al file di personalizzazione necessario.

1.14.5 Convalida l'ora di inizio della fatturazione

Verifica di aver sostituito l'ora di inizio della fatturazione per il monetizzatore e la generazione delle fatture:

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 Configura la policy di rete del proxy di archiviazione degli oggetti nel cluster di amministrazione dell'organizzazione

1.15.1 Crea il file YAML della policy di rete

Crea il file YAML del criterio di rete allow-obs-system-ingress-traffic, ad esempio 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 Applica il criterio di rete al cluster di amministrazione dell'organizzazione

kubectl --kubeconfig ORG_ADMIN_KUBECONFIG apply -f networkpolicy.yaml

1.16. Creare un sito di backup

Se usufruisci dell'assistenza per il ripristino di emergenza, devi completare di nuovo i passaggi precedenti per il sito di backup. Se non hai attivato il ripristino di emergenza, salta questa sezione.

  1. Segui le indicazioni della sezione 1.4. - 1.9. per creare un'altra organizzazione per il sito di backup.

1.17. Risolvere i problemi relativi alla creazione dell'organizzazione

1.17.1. Conferma che tutte le risorse di cui è stato eseguito il deployment siano integre e presenti

Il processo di creazione dell'organizzazione crea più risorse in diversi cluster Kubernetes. Per prima cosa, controlla le risorse di cui è stato eseguito il deployment e assicurati che siano in buono stato. Le sezioni seguenti descrivono le risorse create per un'organizzazione chiamata operations.

1.17.2. Conferma tutte le risorse di cui è stato eseguito il deployment nel cluster di amministrazione principale

Completa i seguenti passaggi per verificare che tutte le risorse nel cluster di amministrazione principale siano integre e presenti:

  1. Ottieni la configurazione kubeconfig richiesta per il cluster di amministrazione root seguendo le istruzioni riportate in IAM-R0004. Assicurati di impostare le seguenti variabili di ambiente e l'alias per queste istruzioni di verifica:

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

  2. Verifica che le risorse firewall siano disponibili:

    1. Stabilisci una connessione SSH al firewall e verifica che sia stato creato un nuovo vsys:

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

      L'output è simile al seguente:

      vsys1 {
vsys2 {

    2. Consulta la risorsa FirewallVirtualSystem:

      k get firewallvirtualsystem -n gpc-system

      L'output è simile al seguente:

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

  3. Verifica che le risorse di archiviazione siano disponibili:

    1. Consulta la risorsa StorageVirtualMachine:

      k get StorageVirtualMachine -n gpc-system

      L'output è simile al seguente:

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

  4. Verifica che le risorse HSM siano disponibili:

    1. Controlla gli HSM:

      k get hsms -n gpc-system

      L'output è simile al seguente:

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

    2. Controlla il cluster HSM:

      k get hsmcluster -n gpc-system

      L'output è simile al seguente:

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

    3. Controlla il tenant HSM:

      k get hsmtenant -A

      L'output è simile al seguente:

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

  5. Verifica che le risorse della macchina e del nodo siano disponibili:

    1. Consulta le risorse di AddressPoolClaim:

      k get addresspoolclaims -A

      L'output è simile al seguente:

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

    2. Consulta le risorse di NodePoolClaim:

      k get nodepoolclaims -A

      L'output è simile al seguente:

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

    3. Consulta le risorse di NodePool:

      k get nodepool -A

      L'output è simile al seguente:

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

    4. Controlla i cluster bare metal:

      k get baremetalclusters -A

      L'output è simile al seguente:

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

    5. Controlla le macchine bare metal:

      k get baremetalmachines -A

      L'output è simile al seguente:

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

    6. Controlla i server. Si trovano nello stato provisioned:

      k get servers -n gpc-system | grep provisioned

      L'output è simile al seguente:

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

    7. Controlla il cluster Kubernetes:

      k get cluster -A

      L'output è simile al seguente:

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

    8. Controlla i secret per kubeconfig:

      k get secrets -A | grep kubeconfig

      L'output è simile al seguente:

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

1.17.3. Conferma tutte le risorse di cui è stato eseguito il deployment nei cluster dell'organizzazione v1

Completa i seguenti passaggi per verificare che tutte le risorse nel cluster di amministrazione dell'organizzazione e nel cluster di sistema di un'organizzazione v1 siano integre e presenti. Se hai un'organizzazione v2, vai alla sezione successiva.

1.17.3.1. Conferma tutte le risorse di cui è stato eseguito il deployment in un cluster di amministrazione dell'organizzazione

  1. Ottieni la configurazione kubeconfig richiesta per il cluster di amministrazione root seguendo le istruzioni riportate in IAM-R0004. Assicurati di impostare le seguenti variabili di ambiente e l'alias per queste istruzioni di verifica:

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

  2. Verifica che le risorse della macchina e del nodo siano disponibili:

    1. Controlla i cluster bare metal:

      ka get baremetalclusters -A

      L'output è simile al seguente:

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

    2. Controlla le macchine bare metal:

      ka get baremetalmachines -A

      L'output è simile al seguente:

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

    3. Controlla le macchine:

      ka get machines -A

      L'output è simile al seguente:

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

    4. Consulta le risorse di VirtualmachinesInstance:

      ka get virtualmachineinstances -A

      L'output è simile al seguente:

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

    5. Consulta le risorse di NodePool:

      ka get nodepools -A

      L'output è simile al seguente:

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

    6. Controlla i cluster Kubernetes:

      ka get clusters -A

      L'output è simile al seguente:

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

    7. Controlla i nodi:

      ka get nodes -A

      L'output è simile al seguente:

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

    8. Controlla i secret per kubeconfig:

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

      L'output è simile al seguente:

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

1.17.3.2. Conferma tutte le risorse di cui è stato eseguito il deployment nel cluster utente di sistema

Completa i seguenti passaggi per verificare che tutte le risorse nel cluster di sistema siano integre e presenti:

  1. Ottieni la configurazione kubeconfig richiesta per il cluster di amministrazione root seguendo le istruzioni riportate in IAM-R0004. Assicurati di impostare le seguenti variabili di ambiente e l'alias per queste istruzioni di verifica:

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

  2. Verifica che le risorse della macchina e del nodo siano disponibili:

    1. Consulta la risorsa VirtualmachineInstance:

      ku get vmi -A

      L'output è simile al seguente (se è stato creato un cluster utente):

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

    2. Controlla i nodi:

      ku get nodes

      L'output è simile al seguente:

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

    3. Controlla le allocazioni delle GPU:

      ku get gpuallocations -A

      L'output è simile al seguente:

      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. Conferma tutte le risorse di cui è stato eseguito il deployment nei cluster dell'organizzazione v2

Completa i seguenti passaggi per verificare che tutte le risorse nel cluster dell'infrastruttura dell'organizzazione in un'organizzazione v2 siano integre e presenti. Se hai un'organizzazione v1, salta questa sezione.

  1. Ottieni la configurazione kubeconfig richiesta per il cluster di amministrazione root seguendo le istruzioni riportate in IAM-R0004. Assicurati di impostare le seguenti variabili di ambiente e l'alias per queste istruzioni di verifica:

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

  2. Verifica che i nodi e i server API siano integri:

    1. Controlla i nodi:

      ka get nodes -A

      L'output è simile al seguente:

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

    2. Controlla i secret per kubeconfig:

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

      L'output è simile al seguente:

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

  3. Se applicabile, controlla le allocazioni GPU per verificare che le risorse GPU siano pronte:

    ka get gpuallocations -A

    L'output è simile al seguente:

    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. Conferma che tutte le risorse dell'organizzazione siano state riconciliate

Completa i seguenti passaggi per verificare che tutte le risorse correlate all'organizzazione nel cluster di amministrazione radice globale e zonale siano integre e presenti, supponendo che l'obiettivo sia creare un'organizzazione operations con due zone: zone-1 e zone-2.

  1. Segui la procedura descritta in Accedere all'API Admin root globale per accedere al server API globale e utilizza il seguente alias per kubectl dell'API Admin root globale.

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

  2. Verifica che le risorse dell'organizzazione globale siano disponibili:

    1. Consulta le risorse globali di Organization:

      kga get organization -A

      L'output è simile al seguente:

      NAMESPACE    NAME         READY
gpc-system   operations
gpc-system   root

    2. Consulta le risorse globali di OrganizationReplica:

      kga get organizationreplica -A

      L'output è simile al seguente:

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

    3. Consulta le risorse globali di OrganizationZonalConfig:

      kga get organizationzonalconfig -A

      L'output è simile al seguente:

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

    4. Consulta le risorse globali di OrganizationZonalConfigReplica:

      kga get organizationzonalconfigreplica -A

      L'output è simile al seguente:

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

  3. Imposta l'alias di configurazione kubeconfig del cluster di amministrazione principale zonale:

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

  4. Verifica che le risorse dell'organizzazione a livello di zona siano disponibili:

    1. Consulta le risorse di Organization:

      ka get organization -A

      L'output è simile al seguente:

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

    2. Consulta le risorse di OrganizationReplica:

      ka get organizationreplica -A

      L'output è simile al seguente:

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

    3. Consulta le risorse di OrganizationZonalConfigReplica:

      ka get organizationzonalconfigreplica -A

      L'output è simile al seguente:

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

  5. Segui la procedura descritta in Consenti a qualsiasi indirizzo di accedere a un'organizzazione per consentire il traffico DCI nei cluster di amministrazione dell'organizzazione dal sito di origine al sito di backup.