1. Kundenorganisation erstellen

Geschätzte Dauer: 3 Stunden

Kompetenzprofil: Bereitstellungsingenieur

Als Betreiber können Sie eine Organisation erstellen, um Kunden Zugriff auf die Infrastruktur der Plattform zu gewähren. Bitten Sie Ihren Sicherheitsadministrator, Ihnen die Rolle „Organisationsadministrator“ zuzuweisen, um die Berechtigungen zu erhalten, die Sie zum Erstellen einer Organisation benötigen.

Die Organization-Ressource ist der Stammknoten der Google Distributed Cloud (GDC) Air-Gap-Ressourcenhierarchie. Alle Ressourcen, die zu einer Organisationsgruppe gehören, werden unter dem Organisationsknoten gruppiert. Dies ermöglicht die zentralisierte Sichtbarkeit und Steuerung aller Ressourcen einer Organisation.

Weitere Informationen zu Organisationen finden Sie unter Organisationen.

1.1 Hinweise

Prüfen Sie, ob Folgendes installiert ist:

• Ein Browser auf Ihrem System.

• Die Git-Befehlszeile.

• Die kubectl-Befehlszeile.

• Die gcloud CLI.

1.2 OIDC-Client in OC IT ADFS erstellen

1. Folgen Sie der Anleitung zur ADFS-OIDC-Konfiguration, um einen OpenID Connect-Client (OIDC) in ADFS für den Operator zu erstellen, damit er auf die Organisation zugreifen kann, die Sie erstellen möchten. Notieren Sie sich die Client-ID und den Clientschlüssel des OIDC-Clients. Sie dürfen den Client nicht für Verbindungen zu anderen Clustern wie dem Administrator-Root-Cluster und anderen Administratorclustern der Organisation oder zu Diensten wie ServiceNow wiederverwenden.

2. Fügen Sie die folgende GKE Identity Service-Callback-URL der Zulassungsliste im ADFS-OIDC-Client hinzu, den Sie für die Organisation erstellen möchten:

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

   Beispiel:

   • Name der Organisation: operations
   • Name der Distributed Cloud-Instanz: google
   • Domainname der Distributed Cloud: gdch.test

   Die GKE Identity Service-Callback-URL ist in diesem Fall https://ais-core.operations.google.gdch.test/finish-login.

3. Fügen Sie die folgende GKE Identity Service-Callback-URL der Zulassungsliste im ADFS-OIDC-Client hinzu, den Sie für jede Zone in Ihrem GDC-Universum erstellt haben:

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

   Beispiel:

   • Name der Organisation: operations
   • Zonenname: zone-1
   • Name der Distributed Cloud-Instanz: google
   • Domainname der Distributed Cloud: gdch.test

   Die GKE Identity Service-Callback-URL ist in diesem Fall https://ais-core.operations.zone-1.google.gdch.test/finish-login.

4. Legen Sie die folgenden Variablen für die Verwendung in den nächsten Abschnitten fest:

   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
   

   Ersetzen Sie die Variablen durch die folgenden Werte:

   Variable	Definition
   ADFS_CERT_BASE64	Die base64-codierte adfs.pem-Datei.
   ADFS_CLIENT_ID	Die ADFS-Client-ID.
   ADFS_CLIENT_SECRET	Das gemeinsame Secret des ADFS-Clients.
   ADFS_ISSUER_URI	Der ADFS-Aussteller-URI. Den URI finden Sie im Pfad /adfs/.well-known/openid-configuration des ADFS-Servers: curl -s https://fs.opscenter.local/adfs/.well-known/openid-configuration | jq '.issuer' "https://fs.opscenter.local/adfs" Der Wert ist in der Regel https://adfs.domain.com/adfs.

1.3 Globale Subnetze erstellen und für jede Zone aufteilen

Hinweis: Dieser Abschnitt gilt nur, wenn Sie eine Organisation der Version 2 erstellen. Wenn Sie eine Organisation der Version 1 erstellen, fahren Sie mit dem nächsten Abschnitt fort.

Bevor Sie eine Organisation erstellen, müssen Sie die globalen Stamm-Subnetze erstellen und sie mit dem IPAM-Subnetz (IP Address Management) für jede Zone aufteilen. Wenn Sie eine neue V2-Organisation in einer Zone erstellen, in der zuvor eine V1-Organisation vorhanden war, sollten Sie sich vor dem Erstellen Ihrer globalen Subnetze die Seite mit den zusätzlichen Voraussetzungen ansehen.

Globale Root-Subnetze hosten den Root-IP-Adressbereich (CIDR), der in jede Zone aufgeteilt wird, um alle Cluster in der Mandantenorganisation zu booten, einschließlich des Infrastrukturclusters der Organisation und der Arbeitslast-VMs. Ein kleiner Teil des IP-Adressbereichs wird auch als Anycast-IP-Adresspool für Stamm-Subnetze zur Verfügung gestellt. Sie können jeder Zone automatisch dedizierte CIDRs zuweisen lassen, indem Sie einen Controller verwenden, oder Sie können jeder Zone manuell CIDRs zuweisen.

Um eine Organisation zu initialisieren, benötigen Sie den internen IP-Adressbereich aus dem OIQ (Organization Input Questionnaire). Sie müssen diese IP-Adressbereiche verwenden, um das globale Stamm-Subnetz auf dem globalen API-Server zu erstellen.

Sie müssen für jeden globalen API-Server unterschiedliche Stamm-Subnetze erstellen. Die Zuordnung des OIQ-Felds, des globalen Stamm-Subnetzwerk-Namens und des globalen API-Servers finden Sie im nächsten Abschnitt.

1.3.1 CIDR-Bereich für OIQ definieren

CIDR-Bereiche dürfen sich nicht überschneiden und nicht mit dem zone-infra-cidr.

Die zone-infra-cidr ist in jeder Zone vorhanden und kann aus dem Customer Intake Questionnaire (CIQ) abgerufen werden, sofern der Kunde sie definiert hat.

Führen Sie Folgendes aus, um die zone-infra-cidr abzurufen:

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

Hier ein Beispiel für die YAML-Ausgabe:

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 diesem Beispiel ist zone-infra-cidr gleich 192.0.2.0/24. Daher dürfen sich keine Felder im OIQ mit 192.0.2.0/24 überschneiden.

In der folgenden Tabelle sind die OIQ-Felder und die entsprechenden Standardmindestwerte aufgeführt:

OIQ-Feld	Beschreibung	Erforderliche Mindestgröße	Mindestgröße pro Zone für die Organisation	Name des globalen Root-Subnetzes	Globaler API-Server
infraVPCCIDR	Systemarbeitslasten, einschließlich der Organisationskonsole, Management-APIs und Dienste von Google.	\( 15 - \lceil \log_2(ZoneNumber) \rceil \)	16	infra-vpc-root-cidr	Globale Root
defaultVPCCIDR	Nutzerarbeitslasten und Endpunkte in der Standard-VPC über Zonen hinweg.	\( 16 - \lceil \log_2(ZoneNumber) \rceil \)	16	default-vpc-root-cidr	Globale Organisation
orgAdminExternalCIDR	Arbeitslasten und Endpunkte im Perimeter-Cluster, die den administrativen Traffic zwischen dem externen Netzwerk und der Organisation verarbeiten.	\( 22 - \lceil \log_2(ZoneNumber) \rceil \)	23	admin-external-root-cidr	Globale Root
orgDataExternalCIDR	Arbeitslasten und Endpunkte, die für Nutzer extern erreichbar sind, z. B. externe Load-Balancer und Egress-NATs.	\( 22 - \lceil \log_2(ZoneNumber) \rceil \)	23	data-external-root-cidr	Globale Root

Wenn Sie nicht genügend IP-Adressen für das empfohlene Standardminimum haben, müssen Sie die Subnetze für jede Zone manuell aufteilen.

Für IPv4-Subnetzbereiche gelten die folgenden Einschränkungen:

• orgDataExternalCIDR, orgAdminExternalCIDR, infraVPCCIDR und defaultVPCCIDR dürfen sich nicht überschneiden, nicht mit anderen zugewiesenen Bereichen innerhalb der Organisation und nicht mit IPv4-Bereichen in Peering-Netzwerken. Die CIDRs für diese stammen aus dem privaten Adressbereich von RFC 1918.

  Peering-Netzwerke: Das können beliebige Subnetze sein, die mit externen Netzwerken über Interconnect-Anhänge beworben werden, oder Subnetze, die mit anderen VPCs in derselben Organisation verbunden sind.

• Wenn Organisationen dieselben AttachmentGroup-Ressourcen für die Verbindung nutzen, müssen die Werte für orgDataExternalCIDR und orgAdminExternalCIDR eindeutig sein. Andernfalls ist eine Überschneidung mit anderen Organisationen zulässig.

1.3.2 Globale Subnetze auf dem globalen API-Server für den Administrator erstellen

Sie müssen die folgenden Subnetze auf dem globalen Root-Admin-API-Server erstellen, bevor Sie eine Organisation erstellen:

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

Diese Subnetze sind erforderlich, um den Infrastrukturcluster der Organisation in jeder Zone zu starten.

Wichtig :Standardmäßig verwendet GDC einen Controller, um das globale Stamm-Subnetz automatisch aufzuteilen und jeder Zone Stamm-Subnetze zuzuweisen. Wenn Sie die Stamm-Subnetze für jede Zone manuell angeben oder einem vorhandenen Universum eine neue Zone hinzufügen möchten, müssen Sie die Annotation ipam.gdc.goog/pause-auto-division: true in den folgenden Subnet-Ressourcen festlegen, um manuelle Spezifikationen für die globale Aufteilung des Stamm-Subnetzes zu ermöglichen.

1. Sie benötigen einen Namespace mit einem Namen, der mit dem Namen der Organisation übereinstimmt, den Sie Ihrer Organisation zuweisen. Prüfen Sie, ob dieser Namespace vorhanden ist:

   kubectl --kubeconfig GLOBAL_ROOT_ADMIN_KUBECONFIG get namespace
   

   Wenn dieser Namespace nicht vorhanden ist, erstellen Sie ihn:

   kubectl --kubeconfig GLOBAL_ROOT_ADMIN_KUBECONFIG create namespace ORG_NAME
   

2. Erstellen Sie die YAML-Datei für das infra-vpc-root-cidr-Subnetz, z. B. 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. Erstellen Sie die YAML-Datei für das admin-external-root-cidr-Subnetz, z. B. 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. Erstellen Sie die YAML-Datei für das data-external-root-cidr-Subnetz, z. B. 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. Kopieren Sie die YAML-Dateien für die Subnetze infra-vpc-root-cidr, admin-external-root-cidr und data-external-root-cidr in das IAC-Repository für die Stammorganisation:

   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. Prüfen Sie, ob die Datei kustomization.yaml im Stammverzeichnis der Organisation die neu hinzugefügten Subnet-Definitionen enthält. Prüfen Sie 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. Stellen Sie die YAML-Dateien für das Subnetz bereit und übertragen Sie sie:

   git add "IAC_REPO_PATH/iac/infrastructure"
   git commit
   

8. Zusammenführungsanfrage erstellen:

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

9. Warten Sie auf die Codeüberprüfung und das Zusammenführen.

1.3.3 Stamm-Subnetze für Zonen aufteilen

Globale Stamm-Subnetze enthalten den Stamm-IP-Adressbereich (CIDR) für alle Zonen. Damit der IP-Adressbereich in der Zone verwendet werden kann, müssen die globalen Stamm-Subnetze zuerst in kleinere Subnetze aufgeteilt werden. Jede Zone muss mindestens einen Root-IP-Adressbereich haben.

IPAM hat einen globalen Controller, der das globale Stamm-Subnetz automatisch in kleinere Subnetze für vorhandene Zonen aufteilt. Administratoren können IPAM-Controllern die Aufgabe übertragen, das Subnetz der Zone automatisch aufzuteilen, wenn sie sich nicht für den genauen CIDR-Block interessieren, den eine bestimmte Zone verwendet. Der Controller überwacht die Erstellung des globalen Stamm-Subnetzes und erstellt für jede Zone ein Subnetz mit einer festen Standardpräfixlänge.

Subnetz des Zonen-Roots	Standardlänge des festen Präfixes
defaultZoneInfraVPCSubnetSize	16
defaultZoneAdminVRFSubnetSize	23
defaultZoneDataVRFSubnetSize	23
defaultZoneDefaultVPCSubnetSize	16
defaultAnycastSubnetSize	26

Die globalen Stamm-Subnetze müssen feste Namen haben, wenn die IPAM-Controller das Subnetz der Zone automatisch aufteilen sollen:

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

Wenn Sie die Annotation ipam.gdc.goog/pause-auto-division: true für Ihre Subnet-Ressourcen festlegen, müssen Sie den genauen CIDR-Block, der von einer bestimmten Zone verwendet wird, manuell definieren. Wenn Sie die globalen Stamm-Subnetze mit unterschiedlichen Namen erstellen, hat die Annotation ipam.gdc.goog/pause-auto-division keine Auswirkungen und die globalen Subnetze werden nicht automatisch aufgeteilt.

1.3.3.1. Root-Subnetze für Zonen automatisch aufteilen

Der globale Controller teilt das globale Stamm-Subnetz automatisch in kleinere Subnetze für vorhandene Zonen auf. Sehen Sie sich beispielsweise den folgenden Workflow an, um zu verstehen, wie der Controller das globale Stamm-Subnetz in kleinere Subnetze für vorhandene Zonen aufteilt:

Wenn es zwei Zonen mit den Namen zone1 und zone2 gibt, sieht ein Beispiel für ein globales Stamm-Subnetz infra-vpc-root-cidr mit dem infraVPCCIDR, z. B. 10.0.0.0/16, aus dem OIQ im Namespace org-1 so aus:

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

Wenn der Controller auf der GDC-Plattform bereitgestellt wird, erstellt er automatisch zwei untergeordnete Subnetze mit den Namen infra-vpc-zone1-root-cidr und infra-vpc-zone2-root-cidr mit der Präfixlänge /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

Hinweis :Dieser Workflow gilt nur für bestimmte globale Root-Subnetze. Daraus wird auch ein Anycast-Subnetz erstellt. Das Anycast-Subnetz ist das einzige Subnetz auf dem globalen API-Server.

1.3.3.2. Stamm-Subnetze für Zonen manuell aufteilen

In diesem Abschnitt wird davon ausgegangen, dass Sie die Anmerkung ipam.gdc.goog/pause-auto-division: true beim Erstellen der globalen Stamm-Subnetze auf dem globalen Stamm-Admin-API-Server festgelegt haben. Durch diese Annotation wird der Controller angehalten, um diese globalen Root-Subnetze abzugleichen. So können Sie das Root-Subnetz und das Anycast-Subnetz einer Zone manuell erstellen.

So teilen Sie das globale Root-Subnetz manuell in kleinere Subnetze für Zonen auf:

1. Listen Sie die Zonen in Ihrem Universum auf:

   kubectl --kubeconfig GLOBAL_ROOT_ADMIN_KUBECONFIG get zone -A
   

2. Bestätigen Sie den dedizierten CIDR-Bereich aus dem Stamm-Subnetz, den Sie auf Ihre Zone anwenden möchten. Wiederholen Sie diesen Schritt für jede Zone in Ihrem Universum.

3. Weisen Sie dem Subnetz für Ihre Zone in einer YAML-Datei, z. B. ORG_NAME-infra-vpc-zone1-root-cidr.yaml, den dedizierten CIDR zu:

   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
   

   Wiederholen Sie diesen Schritt für jede Zone in Ihrem GDC-Universum.

4. Bestätigen Sie den dedizierten CIDR-Bereich des Stamm-Subnetzes, den Sie auf das Anycast-Subnetz anwenden möchten.

5. Weisen Sie das dedizierte CIDR dem Anycast-Subnetz in einer YAML-Datei wie ORG_NAME-infra-vpc-anycast-cidr.yaml zu:

   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. Kopieren Sie die YAML-Dateien für zonale Subnetze in das IAC-Repository für die Stammorganisation. Angenommen, Sie haben zwei zonale Subnetz-YAML-Dateien:

   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. Prüfen Sie, ob die Datei kustomization.yaml im Stammverzeichnis der Organisation die neu hinzugefügten Subnet-Definitionen enthält. Prüfen Sie 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. Stellen Sie die YAML-Dateien für das Subnetz bereit und übertragen Sie sie:

   git add "IAC_REPO_PATH/iac/infrastructure"
   git commit
   

9. Zusammenführungsanfrage erstellen:

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

10. Warten Sie auf die Codeüberprüfung und das Zusammenführen.

1.3.3.2.1. Beispiel für das manuelle Aufteilen von Stamm-Subnetzen für Zonen für infra-vpc

Wenn es zwei Zonen mit den Namen zone1 und zone2 gibt, sieht ein globales Stamm-Subnetz infra-vpc-root-cidr mit dem infraVPCCIDR, z. B. 192.0.2.0/24, aus dem OIQ im Namespace org-1 so aus:

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

Erstellen Sie das Subnetz für jede Zone mit den Namen infra-vpc-zone1-root-cidr und infra-vpc-zone2-root-cidr sowie das Anycast-Subnetz infra-vpc-anycast-cidr mit dem von Ihnen gewählten dedizierten CIDR manuell:

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

Fügen Sie dem IAC-Repository alle YAML-Dateien für Subnetze hinzu.

1.3.3.2.2. Manuelle Aufteilung von Stamm-Subnetzen für Zonen – Beispiel für das Datensicherheitssegment

Wenn es zwei Zonen mit den Namen zone1 und zone2 gibt, sieht ein globales Stamm-Subnetz data-external-root-cidr mit dem orgDataExternalCIDR, z. B. 10.0.0.0/24, aus dem OIQ im Namespace org-1 so aus:

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

Erstellen Sie das Subnetz für jede Zone mit den Namen data-external-zone1-root-cidr und data-external-zone2-root-cidr sowie das Anycast-Subnetz data-global-anycast-cidr mit dem von Ihnen gewählten dedizierten CIDR manuell:

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

Fügen Sie dem IAC-Repository alle YAML-Dateien für Subnetze hinzu.

1.3.3.2.3. Beispiel für das manuelle Aufteilen von Stamm-Subnetzen für Zonen für das Administratornetzwerksegment

Wenn es zwei Zonen mit den Namen zone1 und zone2 gibt, sieht ein globales Stamm-Subnetz admin-external-root-cidr mit dem orgAdminExternalCIDR, z. B. 192.168.1.0/24, aus dem OIQ im Namespace org-1 so aus:

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

Erstellen Sie das Subnetz für jede Zone mit den Namen admin-external-zone1-root-cidr und admin-external-zone2-root-cidr sowie das Anycast-Subnetz admin-global-anycast-cidr mit dem von Ihnen ausgewählten dedizierten CIDR-Bereich manuell:

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

Fügen Sie dem IAC-Repository alle YAML-Dateien für Subnetze hinzu.

1.4 Organisation mit IAC erstellen

So erstellen Sie eine Organisation mit IAC:

1. So generieren Sie eine Liste der verfügbaren Server und Servertypen:

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

   Die Beispielausgabe sieht etwa so aus:

   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
   

   Wenn Sie --server-quota und --admin-server später angeben, müssen Sie darauf achten, dass Sie genügend available-Server haben, um die Anfrage zu erfüllen.

2. Rufen Sie das iac-Repository auf und fügen Sie die Verzeichnisstruktur für die neue Organisation hinzu:

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

3. Benutzerdefinierte Organization-Ressource erstellen:

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

   Beispiel:

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

   Ersetzen Sie die folgenden Variablen:

   Variable	Definition
   ORG_NAME	Der Name der Organisation. Der Name einer Organisation muss die folgenden Kriterien erfüllen: 3 bis 19 ASCII-Kleinbuchstaben, Ziffern oder Bindestriche enthalten. Muss mit einem Buchstaben beginnen. Am Ende darf kein Bindestrich stehen. Darf nicht mit der Zeichenfolge -system enden.
   LOG_RETENTION_POLICY	Die Konfiguration der Aufbewahrungszeiten für Audit-Logs, Betriebslogs und Messwerte in Tagen.
   KMS_ROOT_KEY_TYPE	Diese Konfiguration enthält den für das KMS einer Organisation ausgewählten Stammschlüsseltyp. Jeder KMS-Dienst hat einen Root-Schlüssel zum Verschlüsseln der vom KMS generierten Schlüssel. Standardmäßig generiert der KMS einen CTM-Root-Schlüssel, einen Root-Schlüssel, der in Thales CipherTrust Manager gespeichert und durch ein physisches HSM gesichert wird. Sie können auch einen Software-Root-Schlüssel auswählen, der als Kubernetes-Secret gespeichert ist. Übergeben Sie entweder ctm-root oder local-root für kmsRootKeyType.

   Ein Beispiel für die generierte YAML-Datei für die benutzerdefinierte Ressource Organization sieht in etwa so aus:

   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. Optional: In Version 1.14.2 und höher ist die IPsec-Verschlüsselung zwischen Knoten standardmäßig deaktiviert. Wenn diese IPsec-Verschlüsselung erforderlich ist, können Sie die Node-to-Node-IPsec-Verschlüsselung aktivieren, indem Sie die YAML-Datei der benutzerdefinierten Ressource Organization bearbeiten und eine Annotation hinzufügen:

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

   Ein Wert von "false" für diese Annotation aktiviert die Verschlüsselung.

5. Erstellen Sie für jede Zone im Deployment eine benutzerdefinierte OrganizationZonalConfig-Ressource:

   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
   

   Beispiel:

   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
   

   Vorabversion :Ab Version 1.14.4 bietet GDC die Möglichkeit, asymmetrische Organisationen über Zonen hinweg zu erstellen. Beispielsweise kann sich jede benutzerdefinierte OrganizationZonalConfig-Ressource für jede Zone unterscheiden. Ebenso können Sie für eine vorhandene Zone darauf verzichten, eine benutzerdefinierte OrganizationZonalConfig-Ressource zu erstellen.

   Ersetzen Sie die folgenden Variablen:

   Variable	Definition
   ORG_NAME	Der Name der Organisation. Der Name einer Organisation muss die folgenden Kriterien erfüllen: 3 bis 30 ASCII-Kleinbuchstaben, Ziffern oder Bindestriche enthalten. Muss mit einem Buchstaben beginnen. Am Ende darf kein Bindestrich stehen. Darf nicht mit der Zeichenfolge -system enden.
   ZONES	Die Namen der Zonen in der Bereitstellung.
   GDC_VERSION	Die Version des GDC-Systems, für die die Organisation erstellt werden soll.
   SERVER_QUOTA	Die Server, die für den Administratorcluster der Organisation und den Systemcluster zugewiesen werden sollen, wenn sie automatisch generiert werden. Wenn Sie GPU-Ressourcen (Graphics Processing Unit) ausführen möchten, die VM-basierte Arbeitslasten sind, z. B. vortrainierte APIs für künstliche Intelligenz und maschinelles Lernen (KI/ML), müssen Sie beim Erstellen einer Organisation GPU-Maschinen bereitstellen. Weitere Informationen finden Sie im Abschnitt GPU-Unterstützung für Systemcluster aktivieren.
   ADMIN_SERVER	Ein Schlüssel/Wert-Paar aus dem Servertyp und der Anzahl der Organisationsadministrator-Server, die für diesen Servertyp zugewiesen werden sollen. Gemischte Typen werden für Server nicht unterstützt. Der Standardwert ist o1-standard1-64-gdc-metal: 3.
   STORAGE_SIZE	Die Größe der verschiedenen Speichertypen, die der Organisation zugewiesen werden sollen. Die Mindestgröße für Blockspeicher für eine Organisation beträgt 250 GiB. Sie wird mit dem Flag BlockStandard festgelegt.

   Ein Beispiel für die generierte YAML-Datei für die benutzerdefinierte Ressource OrganizationZonalConfig sieht in etwa so aus:

   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. Überprüfen Sie die generierten YAML-Dateien. Die Dateien befinden sich im Verzeichnis HOME.

   1. Bestätigen Sie den Organisationstyp. Es gibt zwei Arten von Organisationen, die Sie bereitstellen können:

      • Org v1-Architektur (v1-Organisation)
      • Architektur von Organisation v2 (Organisation v2)

      Neue Organisationen werden standardmäßig basierend auf Ihrem Bereitstellungstyp bereitgestellt, der durch Ihre Feature-Gate-Einstellungen festgelegt wird:

      • Bei PRODUCTION-Bereitstellungen werden standardmäßig V2-Organisationen erstellt.
      • Bei ACCREDITED-Bereitstellungen werden standardmäßig Organisationen der Version 1 erstellt.

      In dem seltenen Fall, dass Sie den Standardorganisationstyp für Ihren Bereitstellungstyp überschreiben müssen, aktualisieren Sie das Feld spec.compatibilityOptions.architectureOverridePolicy in Ihrer generierten benutzerdefinierten Ressource Organization auf ForceV1 oder ForceV2, je nachdem, welchen Organisationstyp Sie verwenden möchten. Das folgende Snippet erzwingt beispielsweise die Erstellung einer v2-Organisation in einer ACCREDITED-Bereitstellung:

      ...
      
      spec:
      ...
        compatibilityOptions:
          architectureOverridePolicy: ForceV2
      
      ...
      

   2. Prüfen Sie die verbleibenden Einstellungen, um sicherzustellen, dass Komponenten wie Speicher und Rechenleistung für die Anforderungen Ihres Unternehmens ausreichen.

7. Kopieren Sie die benutzerdefinierten Ressourcen Organization und OrganizationZonalConfig in das Repository im Verzeichnis der neuen Organisation:

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

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

   Ersetzen Sie Folgendes:

   • ORG_NAME: Der Organisationsname, den Sie im Befehl gdcloud organizations config create mit dem Parameter --name definiert haben.
   • ZONE: Der Name jeder Zone in der Bereitstellung. Der Zonenname wird im folgenden Format abgeleitet: {generalRegion}-{regionQualifier}{regionCounter}-{zoneLetter}. Beispiel: us-central1-b Beschreibungen der Attributwerte für Zonen finden Sie im Abschnitt „Zone“ im Fragebogen zur Kundenaufnahme.

8. Fügen Sie die Datei kustomization.yaml für die neue Organisation hinzu:

   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. Fügen Sie die neue Organisation als Ressource der Stammorganisation hinzu:

   1. Öffnen Sie die globale Stammdatei kustomization.yaml:

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

   2. Fügen Sie die neue Organization als Ressource am Ende der vorhandenen Ressourcenliste hinzu:

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

10. Stellen Sie die YAML-Datei der Organisation und die Kustomize-Dateien bereit und committen Sie sie:

    git add "IAC_REPO_PATH/iac/infrastructure"
    git commit
    

11. Zusammenführungsanfrage erstellen:

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

12. Warten Sie auf die Codeüberprüfung und das Zusammenführen.

13. Prüfen Sie, ob die globale Organisation und die zonalen Konfigurationen verfügbar sind:

    1. Prüfen Sie, ob die globale Organisation in Ihrem GDC-Universum verfügbar ist:

       kubectl get organization -A
       

       Die Ausgabe sieht etwa so aus:

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

       Hinweis :Wenn Sie nicht auf die Server der neuen Organisation zugreifen können, müssen Sie möglicherweise mit Ihrem Netzwerkadministrationsteam zusammenarbeiten, um die Verbindung zu den entsprechenden IP-Adressen und Ports für die neu erstellte Organisation zu aktivieren.

    2. Globalen Organisationsstatus prüfen:

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

       Prüfen Sie, ob die status-Bedingungen in der YAML-Ausgabe True sind.

    3. Prüfen Sie den Status der Organisationskonfiguration in jeder Zone:

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

       Wenn Sie zonale Kontexte wechseln möchten, melden Sie sich mit der gcloud CLI in jeder Zone an, bevor Sie den Organisationsstatus prüfen. Die status-Bedingungen in der YAML-Ausgabe für jede Zone müssen True sein.

1.5 Globale Subnetze auf dem globalen API-Server der Organisation erstellen

Hinweis: Dieser Abschnitt gilt nur, wenn Sie eine Organisation der Version 2 erstellen. Wenn Sie eine Organisation der Version 1 erstellen, fahren Sie mit dem nächsten Abschnitt fort.

Sie müssen die default-vpc-root-cidr auf dem globalen API-Server der Organisation im Namespace platform erstellen, nachdem der globale API-Server ausgeführt wird. In diesem Stamm-Subnetz wird die IP-Adresse für Cluster innerhalb der Mandantenorganisation, z. B. Nutzercluster, sowie IP-Adressen für VM-Arbeitslasten zugewiesen.

1. Erstellen Sie die YAML-Datei für das default-vpc-root-cidr-Subnetz, z. B. 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. Wechseln Sie zum Repository iac und fügen Sie die Verzeichnisstruktur für die globale Organisation hinzu:

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

3. Kopieren Sie die YAML-Datei für das default-vpc-root-cidr-Subnetz in das IAC-Repository im Verzeichnis der neuen Organisation:

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

4. Erstellen Sie die Datei kustomization.yaml im Organisationsordner mit den neu hinzugefügten Subnet-Definitionen. Prüfen Sie 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. Stellen Sie die YAML-Datei der Organisation und die Kustomize-Dateien bereit und committen Sie sie:

   git add "IAC_REPO_PATH/iac/infrastructure"
   git commit
   

6. Zusammenführungsanfrage erstellen:

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

7. Warten Sie auf die Codeüberprüfung und das Zusammenführen.

Ähnlich wie die globalen Subnetze im globalen Administratorcluster auf oberster Ebene aufgeteilt werden, wird auch default-vpc-root-cidr aufgeteilt und an jede Zone weitergegeben, damit die zonale Organisation IP-Adressen nutzen kann.

1.7. NTPRelay für Organisationsadministrator konfigurieren

Sie müssen die Authentifizierung zwischen den NTPRelays des Root-Administrators und des Organisationsadministrators manuell konfigurieren.

Folgen Sie NTP-P0001.3 (Root Admin -> Org Admin NTPRelay Encryption), um die Verschlüsselung für diese Organisation zu konfigurieren.

1.8. IO-Identitätsanbieter mit IAC mit der Organisation verbinden

1. Erstellen Sie einen OIDC-Client in ADFS für die neue Organisation und notieren Sie sich die Client-ID und den Clientschlüssel des OIDC-Clients.

2. Legen Sie den Namen Ihrer Organisation als Umgebungsvariable fest:

   export ORG_NAME=ORG_NAME
   

   Prüfen Sie, ob ORG_NAME genau mit dem Namen der Organisation übereinstimmt.

3. Exportieren Sie die kubeconfig-Datei des Administratorclusters auf Stammebene und führen Sie die folgenden kubectl-Befehle aus, um die Cluster- und Zonennamen abzurufen:

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

4. Fügen Sie die Datei ioauthmethod.yaml für die Organisation hinzu:

   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
   

   Ersetzen Sie die folgenden Variablen:

   Variable	Definition
   ADFS_CERT_BASE64	Die Base64-Codierung des Zertifikats, das ADFS zum Selbstsignieren verwendet und das GKE Identity Service benötigt, um eine sichere Verbindung mit einer internen ADFS-Instanz herzustellen.
   ADFS_ORG_CLIENT_ID	Die OpenID Connect-ID für den Client der Organisation in ADFS.
   ADFS_ORG_CLIENT_SECRET	Der OpenID Connect-Schlüssel für den Client der Organisation, der in ADFS registriert ist.
   ADFS_ISSUER_URI	Ein gültiger Aussteller-URI, der vom GKE Identity Service benötigt wird, um Weiterleitungsanmeldungsanfragen an ADFS zuzulassen.

5. Fügen Sie die Datei initial-admin.yaml für die Organisation hinzu:

   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: [e-mail]
   EOF
   

   Ersetzen Sie die folgenden Variablen:

   Variable	Definition
   USER	Der Nutzername mit dem Präfix des IO, mit dem Sie sich zuerst im Cluster anmelden. Denken Sie daran, das Präfix an den Nutzernamen anzuhängen.
   EXPIRATION	Der Zeitstempel im RFC 3339-Format, zu dem das System den Zugriff widerruft. Beispiel: "2020-11-14T00:20:12+00:00".

6. Hängen Sie neu erstellte Dateien an die Datei kustomization.yaml unter IAC_REPO_PATH /iac/infrastructure/global/orgs/ORG_NAME/kustomization.yaml an:

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

7. Stellen Sie die YAML-Datei der Organisation und die Kustomize-Dateien bereit und committen Sie sie:

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

8. Übertragen Sie die Aktualisierung per Push an GitLab:

   git -c http.sslVerify=false push
   

9. Warten Sie auf die Codeüberprüfung und das Zusammenführen.

10. Um zu bestätigen, dass der Operator auf die Organisation zugreifen kann, melden Sie sich in der generierten Organisation an und führen Sie den folgenden Befehl aus, um zu prüfen, ob in der ClientConfig der Organisation ein Identitätsanbieter (IdP) vorhanden ist:

    1. Legen Sie die kubeconfig-Datei des Administratorclusters entsprechend der Architektur Ihrer Organisation fest:

       • Führen Sie für eine v1-Organisation Folgendes aus:

         export KUBECONFIG=ORG_ADMIN_CLUSTER_KUBECONFIG
         

         Ersetzen Sie ORG_ADMIN_CLUSTER_KUBECONFIG durch den Pfad zur kubeconfig des Administratorclusters der Organisation, z. B. /tmp/${ORG}-admin-kubeconfig.

       • Führen Sie für eine v2-Organisation Folgendes aus:

         export KUBECONFIG=ORG_INFRA_CLUSTER_KUBECONFIG
         

         Ersetzen Sie ORG_INFRA_CLUSTER_KUBECONFIG durch den Pfad zur kubeconfig des Infrastrukturclusters der Organisation, z. B. /tmp/${ORG}-infra-kubeconfig.

    2. Prüfen Sie, ob in der ClientConfig der Organisation ein IdP vorhanden ist:

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

11. Bei Version 1.14.3 müssen Sie die Rolle global-zone-viewer manuell anwenden, damit alle authentifizierten Nutzer die Zonen in einem Universum mit der gcloud CLI ansehen können. Wenden Sie die Ressourcen für Rolle und Rollenbindung an:

    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
    

    Ersetzen Sie ORG_GLOBAL_API_SERVER_KUBECONFIG durch die kubeconfig-Datei des globalen API-Servers der Organisation. Weitere Informationen finden Sie unter kubeconfig-Datei manuell generieren.

1.9. Identitätsanbieter des Kunden mit der Organisation verbinden

So verbinden Sie einen Kundenidentitätsanbieter (IdP) mit der Organisation und melden sich mit den Identitäten des Kunden in der Organisation an:

1. Melden Sie sich über die CLI mit dem ursprünglichen IO-Administratorkonto an, das bei der Organisationseinrichtung festgelegt wurde. Dieses Konto ist automatisch an org-iam-admin im Administratorcluster der Organisation gebunden.

2. Bitte den Kunden, die folgende globale AIS-Callback-URL auf die Zulassungsliste im OIDC- oder SAML-Client zu setzen, den er für die Organisation erstellt hat, die Sie erstellen werden:

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

   Wenn die Stamm-URL von GDC beispielsweise .google.gdch.test lautet und der Name der Organisation operations ist, lautet die globale AIS-Callback-URL https://ais-core.operations.google.gdch.test/finish-login.

   Wenn Sie einen SAML-Client verwenden, müssen Sie auch die folgende globale AIS-SAML-Callback-URL zur Zulassungsliste hinzufügen:

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

3. Bitte den Kunden, die folgende AIS-Callback-URL in der Zulassungsliste des OIDC- oder SAML-Clients hinzuzufügen, den er für jede Zone erstellt hat. Für ein Universum mit drei Zonen sehen die zonalen AIS-Callback-URLs beispielsweise so aus:

   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
   

   Wenn die Stamm-URL von GDC .google.gdch.test, der Zonenname zone-1 und der Name der Organisation operations ist, lautet die AIS-Callback-URL https://ais-core.operations.zone-1.google.gdch.test/finish-login.

   Wenn Sie einen SAML-Client verwenden, müssen Sie auch die folgenden AIS-SAML-Callback-URLs für jede Zone zur Zulassungsliste hinzufügen:

   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. Legen Sie die kubeconfig-Datei des Administratorclusters entsprechend der Architektur Ihrer Organisation fest. Wenn Sie die kubeconfig-Variable bereits festgelegt haben, überspringen Sie diesen Schritt.

   • Führen Sie für eine v1-Organisation Folgendes aus:

       export KUBECONFIG=ORG_ADMIN_CLUSTER_KUBECONFIG
     

     Ersetzen Sie ORG_ADMIN_CLUSTER_KUBECONFIG durch den Pfad zur kubeconfig des Administratorclusters der Organisation, z. B. /tmp/${ORG}-admin-kubeconfig.

   • Führen Sie für eine v2-Organisation Folgendes aus:

       export KUBECONFIG=MANAGEMENT_API_SERVER_KUBECONFIG
     

     Ersetzen Sie MANAGEMENT_API_SERVER_KUBECONFIG durch den Pfad zur kubeconfig des Management API-Servers, z. B. /tmp/${ORG}-management-kubeconfig.

5. Entscheiden Sie anhand des Kundensupporttickets für eine neue Organisation, ob der IdP OIDC oder SAML verwendet. Folgen Sie der Anleitung für den entsprechenden Identitätsanbietertyp:

   • Mit OIDC einrichten
   • Einrichtung mit SAML
   Hinweis :Wählen Sie entweder die OIDC- oder die SAML-Einrichtung aus. Dies hängt vom IdP des Kunden ab. Richten Sie nicht beide ein.

Einrichtung mit OIDC

1. Erstellen Sie eine identity-provider-config.yaml-Datei und füllen Sie sie aus. Verwenden Sie dazu die Tickets zur Organisationserstellung, um die Werte für den Account-IdP des primären Administrators zu ermitteln:

   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
   

   Hinweis :Weisen Sie dem IdP ein Präfix zu, wenn der Kunde keines angibt. Weitere Informationen finden Sie unter Nutzer- und Gruppenpräfix.

2. Hier finden Sie die detaillierten Beschreibungen der Felder:

   Attribut	Attributtyp	Beschreibung
   certificateAuthorityData	Verbindlich	Ein standardmäßig base64-codiertes, PEM-formatiertes Zertifizierungsstellen-Zertifikat für den OIDC-Anbieter.
   clientID	Verbindlich	Die ID für die Clientanwendung, die Authentifizierungsanfragen an den OpenID-Anbieter sendet.
   clientSecret	Verbindlich	Das gemeinsame Secret zwischen der OIDC-Clientanwendung und dem OIDC-Anbieter.
   extraParams	Optional	Eine durch Kommas getrennte Liste von Schlüssel/Wert-Paaren, die abfragecodiert und mit der Authentifizierungsendpunktanfrage gesendet werden.
   groupPrefix	Optional	Das Präfix, das der Gruppenanforderung vorangestellt werden soll, um Konflikte mit vorhandenen Gruppen zu vermeiden. Es wird in der Regel verwendet, wenn mehrere Identitätsanbieter konfiguriert werden. Sie müssen das Gruppenpräfix vor allen Gruppennamen einfügen. Wenn Sie beispielsweise myprefix- als Gruppenpräfix und eine Gruppe mit dem Namen groupA in Ihrem Identitätsanbieter haben, müssen Sie beim Hinzufügen einer Richtlinie oder Bindung myprefix-groupA binden. Der Gruppenname wird im Feld groupsClaim festgelegt. Hinweis: GDC fügt kein Trennzeichen zwischen dem Präfix und dem Gruppennamen ein. Fügen Sie am Ende des Präfixes ein Trennzeichen wie - oder : ein, um die Lesbarkeit zu verbessern. Andernfalls werden prefix und [e-mail] als [e-mail] identifiziert.
   groupsClaim	Optional	Der Name des Anspruchs im OIDC-ID-Token, das die Informationen der Nutzergruppe enthält. Dieser Name muss mit dem Namen des Anspruchs übereinstimmen, der Informationen zur Gruppenmitgliedschaft in Ihrem OIDC-Anbieter enthält.
   issuerURI	Verbindlich	Die URL, über die Autorisierungsanfragen an Ihren OIDC-Anbieter gesendet werden. Dieser URI muss auf die Ebene innerhalb von .well-known/openid-configuration verweisen.
   scopes	Optional	Eine durch Kommas getrennte Liste von Kennungen, die angeben, welche Zugriffsrechte zusätzlich zum openid-Bereich angefordert werden.
   userClaim	Verbindlich	Der Name der Anforderung im OIDC-ID-Token, das den Nutzernamen enthält. Wenn die Nutzeranforderung beispielsweise email lautet, werden die Nutzer durch das Nutzerfeld im OIDC-Token identifiziert. Wenn dies im ID-Token fehlt, schlägt die Authentifizierung fehl.
   userPrefix	Optional	Das Präfix, das den Nutzeranforderungen vorangestellt werden soll, um Konflikte mit vorhandenen Nutzernamen zu vermeiden. Es wird in der Regel verwendet, wenn mehrere Identitätsanbieter konfiguriert werden. Wenn die Nutzeranforderung beispielsweise email und das Nutzerpräfix prefix- lautet, werden Nutzer als [e-mail] identifiziert. Der Nutzer ist [e-mail] und das Präfix prefix- wird dem Nutzer vorangestellt, um zwischen verschiedenen Identitätsanbietern zu unterscheiden. Wir empfehlen, am Ende des Präfixes ein Trennzeichen einzufügen, wie oben in dieser Tabelle für die Einstellung von groupPrefix beschrieben.

3. Optional: Wenn Ihr Identitätsanbieter benutzerdefinierte Attribute verwendet, konfigurieren Sie die Attribute zuerst in Ihrem IdP. Fügen Sie dann die entsprechenden Schlüssel/Wert-Paare im Abschnitt oidc der Datei identity-provider-config.yaml für zusätzliche Behauptungen über Nutzer oder Gruppen hinzu, z. B. ihre Abteilung oder ihr Geburtstag. Wenn Sie die Änderungen an der Konfiguration des Identitätsanbieters anwenden, erkennt GKE Identity Service die benutzerdefinierten Attribute. Hier ein Beispiel für benutzerdefinierte Attribute:

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

4. Konfigurieren Sie die Konfiguration des Identitätsanbieters:

   kubectl apply -f identity-provider-config.yaml
   

5. Warten Sie, bis die verschiedenen Systemkomponenten neu konfiguriert wurden.

6. Überprüfen Sie die Konfiguration, indem Sie die Platform Admin UI-Konsole in einem Webbrowser öffnen. Wählen Sie auf der Weiterleitungsseite Mit pa-idp-oidc anmelden aus. Wenn Sie zur IdP-Instanz des PA-Kontos weitergeleitet und nach der Anmeldung mit der IdP-Instanz des PA-Kontos wieder zur Seite der Plattformadministrator-UI-Konsole weitergeleitet werden, ist die Konfiguration erfolgreich. Prüfen Sie andernfalls die Werte in identity-provider-config.yaml und wiederholen Sie den vorherigen Schritt.

Einrichtung mit SAML

1. Erstellen Sie eine identity-provider-config.yaml-Datei und füllen Sie sie aus. Verwenden Sie dazu die Tickets zur Erstellung der Organisation, um die Werte für den Account-IdP des PA zu ermitteln:

   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
   

   Hinweis :Weisen Sie dem IdP ein Präfix zu, wenn der Kunde keines angibt. Weitere Informationen finden Sie unter Nutzer- und Gruppenpräfix.

2. Hier finden Sie die detaillierten Beschreibungen der Felder:

   .

   Attribut	Attributtyp	Beschreibung
   idpCertificateDataList	Verbindlich	Die Zertifikate des Identitätsanbieters, die zur Überprüfung der SAML-Antwort verwendet werden. Diese Zertifikate müssen standardmäßig Base64-codiert und im PEM-Format vorliegen. Es werden nur maximal zwei Zertifikate unterstützt, um die Zertifikatsrotation des Identitätsanbieters zu ermöglichen.
   idpEntityID	Verbindlich	Die SAML-Entitäts-ID für den SAML-Anbieter im URI-Format. Beispiel: https://www.idp.com/saml.
   idpSingleSignOnURI	Verbindlich	Der URI zum SSO-Endpunkt des SAML-Anbieters. Beispiel: `https://www.idp.com/saml/sso`.
   groupPrefix	Optional	Das optionale Präfix, das jedem Gruppennamen vorangestellt werden soll.
   userPrefix	Optional	Das optionale Präfix, das dem Nutzernamen vorangestellt werden soll.
   userAttribute	Optional	Der Name des Attributs in der SAML-Antwort, das den Nutzernamen enthält. Wenn dieses Attribut in der SAML-Antwort fehlt, schlägt die Authentifizierung fehl.
   groupsAttribute	Optional	Der Name des Attributs in der SAML-Antwort, das die Gruppen des Nutzers enthält.

3. Optional: Wenn Ihr Identitätsanbieter benutzerdefinierte Attribute verwendet, konfigurieren Sie die Attribute zuerst in Ihrem IdP. Fügen Sie dann die entsprechenden Schlüssel/Wert-Paare im Abschnitt saml der Datei identity-provider-config.yaml für zusätzliche Behauptungen über Nutzer oder Gruppen hinzu, z. B. ihre Abteilung oder ihr Geburtstag. Wenn Sie die Änderungen an der Konfiguration des Identitätsanbieters anwenden, erkennt GKE Identity Service die benutzerdefinierten Attribute. Hier ein Beispiel für benutzerdefinierte Attribute:

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

4. Konfigurieren Sie den Patch für die Konfiguration des Identitätsanbieters:

   kubectl apply -f identity-provider-config.yaml
   

5. Warten Sie, bis die verschiedenen Systemkomponenten neu konfiguriert wurden.

6. Überprüfen Sie die Konfiguration, indem Sie die Platform Admin UI-Konsole in einem Webbrowser öffnen. Wählen Sie auf der Weiterleitungsseite Mit pa-idp-oidc anmelden aus. Wenn Sie zur IdP-Instanz des PA-Kontos weitergeleitet und nach der Anmeldung mit der IdP-Instanz des PA-Kontos wieder zur Seite der Plattformadministrator-UI-Konsole weitergeleitet werden, ist die Konfiguration erfolgreich. Prüfen Sie andernfalls die Werte in identity-provider-config.yaml und wiederholen Sie den vorherigen Schritt.

Nutzer- und Gruppenpräfix

Nutzer- und Gruppenpräfixe müssen für jeden Identitätsanbieter in Distributed Cloud festgelegt werden, um Namenskonflikte zwischen Konten verschiedener Identitätsanbieter zu vermeiden. Das Präfix wird mit dem Nutzer- und Gruppennamen verwendet, um den Betreffnamen in den Rollenbindungen im Cluster zu verketten. Wenn beispielsweise ein Nutzer den Namen [e-mail] hat und das Nutzerpräfix des IdP example-org-idp- ist, lautet der Betreffname im Cluster [e-mail].

So legen Sie den Wert des Präfixes fest:

• Geben Sie die Hierarchieebene an (Stamm, Organisation, Projekt).
• Geben Sie den Namen des Identitätsanbieters (IdP) an (adfs, keycloak).
• Es wird empfohlen, ein Trennzeichen wie - als Suffix hinzuzufügen, da zwischen dem Präfix und dem Nutzernamen kein Trennzeichen eingefügt wird.

Ersten Administrator zuweisen

Damit die PA den ersten Zugriff auf die Organisation erhält, muss sie als Administrator für die Organisation zugewiesen werden. Um die PA als ersten Administrator zuzuweisen, erstellen Sie ein IAMRoleBinding auf dem globalen API-Server:

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 Netzwerkverbindung für die Organisation herstellen

Eine neu erstellte Organisation ist isoliert und kann nicht über ein externes Netzwerk aufgerufen werden. Damit die Organisation betriebsbereit ist, müssen Sie sie über den Interconnect-Dienst mit einem oder mehreren externen Netzwerken verbinden.

Dazu müssen Sie eine Reihe von benutzerdefinierten Ressourcen konfigurieren, die die logische Verbindung definieren. Im Folgenden werden zwei gängige Szenarien für die Bereitstellung von Konnektivität für eine neue Organisation beschrieben.

Szenario 1: Organisation an eine vorhandene gemeinsame Interconnect-Verbindung anhängen

Wenn Sie bereits eine Interconnect-Verbindung für ein gemeinsames Netzwerk haben, müssen Sie nur die AttachmentGroup und RoutePolicy aktualisieren, um die neue Organisation einzubeziehen.

1. AttachmentGroup aktualisieren:Mit einem AttachmentGroup wird angegeben, welche Organisationen eine Gruppe von VLAN-Anhängen verwenden können. Bearbeiten Sie die YAML-Datei AttachmentGroup und fügen Sie die neue Organisation der Liste spec.entities hinzu. Bei einer V2-Organisation müssen Sie das Netzwerk domainType (OrgAdmin, OrgData oder OrgMixed) angeben, mit dem eine Verbindung hergestellt werden soll.

   Beispiel für die Aktualisierung von AttachmentGroup:

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

2. RoutePolicy aktualisieren:Ein RoutePolicy definiert, welche IP-Präfixe beworben werden. Bearbeiten Sie die Richtlinie und fügen Sie die externen IP-Subnetze für die neue Organisation dem spec.out.ipPrefixList hinzu. Dadurch kann eingehender Traffic die Organisation erreichen.

   Beispiel für die Aktualisierung von 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. Änderungen anwenden: Verwenden Sie kubectl apply mit Ihrem Infrastruktur-als-Code-Prozess (IaC).

Szenario 2: Neue Dedicated Interconnect-Verbindung erstellen

Für eine dedizierte Verbindung müssen Sie einen neuen Satz von Interconnect-Ressourcen erstellen. Dazu müssen Sie fünf benutzerdefinierte Ressourcen in der richtigen Reihenfolge erstellen.

1. Erstellen Sie für jede neue physische Verbindung ein InterconnectLink.
2. Erstellen Sie eine InterconnectGroup, um die physischen Links zu bündeln und die neue Organisation zu genehmigen.
3. Erstellen Sie eine AttachmentGroup und geben Sie die neue Organisation in der Liste entities an.
4. Erstellen Sie eine RoutePolicy, die die eingehenden und ausgehenden IP-Präfixe für diese dedizierte Verbindung zulässt.
5. Erstellen Sie eine oder mehrere InterconnectAttachment-Ressourcen, um die VLANs und BGP-Sitzungen zu definieren.

Umfassende Beispiele und detaillierte Schritte für jede dieser Ressourcen finden Sie in der Dokumentation Interconnect konfigurieren.

1.11 Alertmanager-Webhook für die Verbindung zu ServiceNow einrichten

Folgen Sie der Anleitung unter MON-T0016, um den Alertmanager-Webhook mit ServiceNow zu verbinden und Vorfälle zu erstellen.

1.12 Abrechnungspreisliste für die Organisation konfigurieren

Für die Abrechnungskomponente einer Organisation muss das Produkt oder die abzurechnenden Dienste mit der benutzerdefinierten Ressource SKUDescription konfiguriert werden. Ein einzelnes SKUDescription beschreibt ein einzelnes Produkt oder eine einzelne Dienstleistung, die zusammen mit dem Preis in Rechnung gestellt werden soll. Eine Sammlung von SKUDescription-Objekten kann daher als Preisliste für eine Organisation betrachtet werden. Mit den folgenden Schritten wird das Preisblatt für die Organisation in IAC konfiguriert.

1.12.1 Preisliste abrufen

Wenn Sie die SKUDescription-Preislistenressourcen für eine Organisation noch nicht haben, wenden Sie sich an das Program Management Office (PMO), um die Preisliste zu erhalten. Die Preisliste muss eine Reihe von YAML-Dateien mit SKUDescription-Ressourcen sein.

1.12.2 Feststellen, ob die Preistabelle freigegeben ist

Die Preisliste kann entweder für alle Organisationen freigegeben oder für jede Organisation einzeln konfiguriert werden. Das PMO kann Ihnen mitteilen, ob die Preisliste freigegeben ist.

1.12.2.1 Freigegebenes Preisblatt

Wenn die Preistabelle freigegeben ist, legen Sie sie im freigegebenen IAC-Ordner common-data ab.

1. Wenn diese Organisation nicht die allererste ist, die erstellt wird, ist das Preisblatt möglicherweise bereits im freigegebenen Ordner common-data vorhanden. Wenn die Preistabelle vorhanden ist, prüfen Sie, ob die Schritte 2 bis 4 ausgeführt wurden, und fahren Sie mit Schritt 5 fort.

2. Erstellen Sie den freigegebenen Ordner für die Preistabelle.

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

   Ersetzen Sie IAC_REPO_PATH durch den Pfad zum IAC-Repository.

3. Speichern Sie die YAML-Ressourcen für die SKUDescription-Preistabelle in diesem Ordner. Danach muss der Ordner skudescriptions YAML-Dateien enthalten, die nach Bereich getrennt sind. Konfigurieren Sie die Ordnerstruktur und die YAML-Dateien entsprechend Ihrem Abrechnungsanwendungsfall:

   • Partnerabrechnung: Google stellt dem Partner die Kosten in Rechnung. Platzieren Sie die SKUDescription-Ressourcen im Namespace partner-billing-system.

   • Kundenabrechnung: Der Partner stellt dem Endnutzer die Kosten in Rechnung. Platzieren Sie die SKUDescription-Ressourcen im Namespace billing-system.

   Die folgenden Beispiele zeigen sowohl die Dateistrukturen für die Kundenabrechnung als auch für das Abrechnungsmodell, das vom Partner betrieben wird. Für jedes Modell werden zwei Dienste angezeigt: „compute“ und „storage“. Jeder Dienst hat zwei YAML-Dateien:

   Kundenabrechnung:

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

   Partnerabrechnung:

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

4. Prüfen Sie, ob sich im Verzeichnis eine kustomization.yaml-Datei befindet, die alle YAML-Dateien für die SKUDescription-Preistabelle enthält.

   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. Exportieren Sie die Umgebungsvariable ORG_CLUSTER:

   • Führen Sie für eine v1-Organisation Folgendes aus:

     export ORG_CLUSTER=ORG_ADMIN_CLUSTER_NAME
     

   • Führen Sie für eine v2-Organisation Folgendes aus:

     export ORG_CLUSTER=ORG_INFRA_CLUSTER_NAME
     

6. Erstellen Sie das Abrechnungsverzeichnis skudescriptions in der Organisation:

   • Für eine v1-Organisation:

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

   • Für eine v2-Organisation:

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

   Ersetzen Sie ORG_CLUSTER_NAME durch den Namen des Administratorclusters der Organisation, je nach Versionstyp Ihrer Organisation.

7. Fügen Sie die gemeinsame Preistabelle in die Organisation ein:

   • Für eine v1-Organisation:

     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
     

   • Für eine v2-Organisation:

     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. Stellen Sie die YAML-Datei bereit und committen Sie sie. Passen Sie die Dateien an:

   cd IAC_REPO_PATH
   git add "iac"
   git commit
   

9. Übertragen Sie die Aktualisierung per Push an GitLab:

   git -c http.sslVerify=false push
   

10. Warten Sie auf die Codeüberprüfung und das Zusammenführen.

11. Prüfen Sie, ob die SKUDescription-Objekte für Ihr entsprechendes Abrechnungsmodell im angegebenen Cluster vorhanden sind.

    Exportieren Sie den Wert KUBECONFIG entsprechend dem Organisationstyp.

    • Führen Sie für eine v1-Organisation Folgendes aus:

      export KUBECONFIG=ORG_ADMIN_CLUSTER_KUBECONFIG
      

      Ersetzen Sie ORG_ADMIN_CLUSTER_KUBECONFIG durch den Pfad zur kubeconfig des Administratorclusters der Organisation, z. B. /tmp/${ORG}-admin-kubeconfig.

    • Führen Sie für eine v2-Organisation Folgendes aus:

      export KUBECONFIG=MANAGEMENT_API_SERVER_KUBECONFIG
      

      Ersetzen Sie MANAGEMENT_API_SERVER_KUBECONFIG durch den Pfad zur kubeconfig des Management API-Servers, z. B. /tmp/${ORG}-management-kubeconfig.

    Führen Sie die kubectl-Befehlszeile aus:

    Für die Kundenabrechnung:

    
    kubectl get SKUDescription -n billing-system
    

    Partnerabrechnung:

    
    kubectl get SKUDescription -n partner-billing-system
    

1.12.2.2 Organisationsspezifische Preisliste

Wenn die Preistabelle für eine bestimmte Organisation gilt, müssen Sie sie im Ordner des Organisationsclusters platzieren.

1. Erstellen Sie das Abrechnungsverzeichnis skudescriptions im Organisationscluster:

   • Für eine v1-Organisation:

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

   • Für eine v2-Organisation:

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

2. Speichern Sie die YAML-Ressourcen der SKUDescription-Preisliste in diesem Ordner. Danach muss der Ordner skudescriptions YAML-Dateien enthalten, die nach Bereich getrennt sind. Im folgenden Beispiel sehen Sie zwei Dienste, „compute“ und „storage“, mit jeweils zwei YAML-Dateien:

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

3. Achten Sie darauf, dass sich im Verzeichnis eine kustomization.yaml-Datei befindet, die alle SKUDescription-Preislisten-YAML-Dateien enthält.

   • Für eine v1-Organisation:

     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
     

   • Für eine v2-Organisation:

     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. Prüfen Sie, ob die Datei kustomization.yaml im Stammverzeichnis der Organisation den neu hinzugefügten Ordner bil/skudescriptions enthält. Prüfen Sie IAC_REPO_PATH/iac/infrastructure/zonal/zones/ZONE_NAME/ORG_CLUSTER_NAME/kustomization.yaml für eine V1-Organisation und IAC_REPO_PATH/iac/infrastructure/zonal/zones/ZONE_NAME/ORG_CLUSTER_NAME-management/kustomization.yaml für eine V2-Organisation :

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

5. Stellen Sie die YAML-Datei und die Kustomize-Dateien bereit und committen Sie sie:

   cd IAC_REPO_PATH
   git add "iac"
   git commit
   

6. Übertragen Sie die Aktualisierung per Push an GitLab:

   git -c http.sslVerify=false push
   

7. Warten Sie auf die Codeüberprüfung und das Zusammenführen.

8. Prüfen Sie, ob die SKUDescription-Objekte im angegebenen Cluster vorhanden sind:

   • Führen Sie für eine v1-Organisation Folgendes aus:

     export KUBECONFIG=ORG_ADMIN_CLUSTER_KUBECONFIG
     
     kubectl get SKUDescription -n billing-system
     

     Ersetzen Sie ORG_ADMIN_CLUSTER_KUBECONFIG durch den Pfad zur kubeconfig des Administratorclusters der Organisation, z. B. /tmp/${ORG}-admin-kubeconfig.

   • Führen Sie für eine v2-Organisation Folgendes aus:

     export KUBECONFIG=MANAGEMENT_API_SERVER_KUBECONFIG
     
     kubectl get SKUDescription -n billing-system
     

     Ersetzen Sie MANAGEMENT_API_SERVER_KUBECONFIG durch den Pfad zur kubeconfig des Management API-Servers, z. B. /tmp/${ORG}-management-kubeconfig. .

1.13 Wiederkehrende Abrechnungsnutzungen erstellen

Distributed Cloud bietet Artikelnummern (Stock Keeping Units, SKUs) an, für die wiederkehrende Gebühren anfallen. Distributed Cloud erfasst jedoch nicht Ihre Nutzungskosten für bestimmte SKUs. Verwenden Sie die Ressource RecurringUsage, um solche Informationen zu verwalten. Weitere Informationen und Anleitungen zum Erstellen wiederkehrender Verwendungen finden Sie unter Wiederkehrende Verwendungen erstellen.

1.14 Abrechnung für eine Organisation konfigurieren

Die Abrechnungskomponente beginnt erst mit der Berechnung der Kosten für eine Organisation, wenn die Abrechnungsstartzeit erreicht ist. Die Startzeit für die Abrechnung hat den Standardwert 9999-01-01T00:00:00-07:00. Wenn eine Organisation als bereit gilt, wird die Abrechnungsstartzeit im IO überschrieben, um den Abrechnungsworkflow zu starten.

1.14.1 Abrechnungsbeginn abrufen

Der Abrechnungsbeginn muss am Anfang des Leistungszeitraums liegen, der in Ihrem Vertrag angegeben ist. Wenn Sie die Abrechnungsstartzeit für eine Organisation noch nicht haben, wenden Sie sich an das Program Management Office (PMO), um die Informationen zu erhalten.

1.14.2 Rechnungszahlungskonto einer Organisation zuordnen

Für Google Distributed Cloud-Umgebungen (GDC) ohne Internetverbindung ist ein Rechnungskonto erforderlich, um die Kosten für Projekte und Organisationen zu erfassen. Wenn Sie kein Rechnungskonto mit einer Organisation oder einem Projekt verknüpfen, gehen die Kostendaten für die Ressource verloren.

Wenn die Dienstnutzung dem Kunden in Rechnung gestellt werden soll, wird für alle Rechnungskonten innerhalb einer Organisation eine einzige Preistabelle verwendet.

1.14.2.1 Vorbereitung

Bitten Sie Ihren Sicherheitsadministrator, Ihnen die folgenden erforderlichen Rollen zuzuweisen, bevor Sie fortfahren. Diese Rollen sind entweder an den Projektnamespace für die Abrechnung auf Projektebene oder an den Plattformnamespace für die Abrechnung auf Organisationsebene gebunden:

• Administrator des Abrechnungskontos der Organisation: Er kann die BillingAccount-Ressource erstellen, verwalten und binden. Bitten Sie Ihren Sicherheitsadministrator, Ihnen die Rolle organization-billing-account-admin zuzuweisen.

• Nutzer des Abrechnungskontos der Organisation: Die BillingAccount-Ressource kann gelesen, aufgelistet und gebunden werden. Bitten Sie Ihren Sicherheitsadministrator, Ihnen die Rolle organization-billing-account-user zuzuweisen.

• Organization Billing Account Manager: Berechtigung zum Lesen, Auflisten, Erstellen und Aktualisieren der BillingAccountBinding-Ressource. Bitten Sie Ihren Sicherheitsadministrator, Ihnen die Rolle organization-billing-manager zuzuweisen.

1.14.2.2 Neues Rechnungskonto erstellen

Ein Abrechnungskonto wird eindeutig durch seine name und namespace identifiziert. Wenn Sie ein Rechnungskonto erstellen möchten, verwenden Sie eine benutzerdefinierte Ressource, um name und namespace festzulegen:

1. Erstellen Sie eine YAML-Datei und fügen Sie die benutzerdefinierte Ressource BillingAccount und den folgenden Inhalt hinzu:

   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"
   

   Ersetzen Sie die folgenden Variablen:

   • BIL_ACCOUNT_NAME: der Name des Rechnungskontos. Beispiel: test-billing-account.
   • BIL_DISPLAY_NAME: der Anzeigename des Abrechnungskontos. Beispiel: "Test Billing Account".

2. Prüfen Sie den Typ Ihrer Zahlungskonfiguration. Für Distributed Cloud-Rechnungskonten muss eine der folgenden Zahlungskonfigurationen festgelegt sein:

   • cloudBillingConfig: die Standardkonfiguration für die Zahlung. In dieser Konfiguration wird eine Cloud-Rechnungskonto-ID gespeichert.

   • customConfig: Eine benutzerdefinierte Konfiguration für Partner zum Speichern ihrer Zahlungskonfiguration für die Abrechnung der Organisation. customConfig unterstützt ein Dictionary mit Schlüssel/Wert-Strings und dem obligatorischen Schlüssel payment-config-type.

   Die folgenden Beispiele zeigen BillingAccount-YAML-Dateischnipsel für verschiedene Zahlungskonfigurationen:

   cloudBillingConfig

   spec:
     paymentSystemConfig:
       cloudBillingConfig:
         accountID: CLOUD_BILLING_ACCOUNT_ID
   

   Ersetzen Sie CLOUD_BILLING_ACCOUNT_ID durch IhreGoogle Cloud Abrechnungskonto-ID.

   customConfig

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

   Ersetzen Sie PAYMENT_CONFIG_TYPE durch den von Ihnen ausgewählten Zahlungskonfigurationstyp für Ihre benutzerdefinierte Abrechnungskonfiguration.

   Wenn Sie die Informationen für die customConfig-Konfiguration Ihrer Organisation nicht haben, geben Sie die folgenden Details ein:

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

   Die folgende YAML-Datei zeigt eine vollständige BillingAccount-Ressource mit der cloudBillingConfig-Konfiguration:

   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. Speichern Sie die YAML-Datei der benutzerdefinierten Ressource. Führen Sie die kubectl-Befehlszeile aus, um die Ressource im Organisationscluster für die jeweilige Organisation oder das Projekt anzuwenden, die bzw. das Sie abrechnen möchten:

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

1.14.2.3 Rechnungskonto mit einer Organisation verknüpfen

So verknüpfen Sie eine Organisation mit einer BillingAccount:

1. Fügen Sie der YAML-Datei billingaccountbinding.yaml den folgenden Inhalt hinzu:

   • Füllen Sie im Bereich billingAccountRef das Feld name mit dem Inhalt des Felds name in der BillingAccount aus, die Sie verknüpfen möchten.
   • Füllen Sie im Abschnitt metadata das Feld namespace mit dem Inhalt des identischen Felds in der Ressource BillingAccount aus. In diesem Beispiel lautet der Organisations-Namespace platform:

   apiVersion: billing.gdc.goog/v1
   kind: BillingAccountBinding
   metadata:
     name: billing
     namespace: platform
   spec:
     billingAccountRef:
       name: BIL_ACCOUNT_NAME
       namespace: platform
   

2. Wenden Sie die Datei billingaccountbinding.yaml an:

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

1.14.3 Vorbereitung

Bitten Sie Ihren Sicherheitsadministrator, Ihnen die Rolle „Bil Monitor“ (bil-monitor) im Organisationsadministratorcluster für den Namespace billing-system zuzuweisen, bevor Sie fortfahren. Mit dieser Berechtigung können Sie zugehörige Ressourcen zur Validierung lesen.

1.14.4 Startzeit der Abrechnung überschreiben

1. Erstellen Sie zwei YAML-Dateien mit den folgenden Pfaden:

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

     • Erstellen Sie die erforderlichen Unterverzeichnisse für jede Datei, falls sie fehlen.

2. Fügen Sie die SubcomponentOverride-Ressource und den folgenden Inhalt in jede Datei ein:

   Für die Kundenabrechnung:

   • bil-monetizer-override.yaml-Datei:

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

   • bil-invoice-override.yaml-Datei:

     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
     

   Für die Abrechnung durch Partner:

   • Fügen Sie das Flag enablePartnerBilling: true am Ende jeder YAML-Datei hinzu:

   • bil-monetizer-override.yaml-Datei:

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

   • bil-invoice-override.yaml-Datei:

     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
     

   Ersetzen Sie die folgenden Variablen:

   • ORG_NAME: der Name der Organisation. Beispiel: org-1

   • BILLING_START_TIME: Der Zeitstempel für den Beginn des Abrechnungsablaufs.Der Zeitstempel muss dem RFC 3339-Format entsprechen. Wenn der Abrechnungsworkflow beispielsweise am 01.01.2024 in der Zeitzone US and Canadian Pacific Standard Time (UTC-8) beginnt, fügen Sie den Zeitstempelwert als 2024-01-01T00:00:00-08:00 hinzu.

   • BILLING_TIMEZONE: die Zeitzone des Abrechnungsworkflows. Die Zeitzone muss dem RFC 3339-Format entsprechen. Wenn die Abrechnungszeitzone beispielsweise US-amerikanische und kanadische Pazifikzeit (UTC-8) ist, fügen Sie den Zeitzonenwert als PST8PDT hinzu.

   Wichtig: Für Org v2-Architekturen (Organisationen der Version 2) benötigen Sie ein zusätzliches SubcomponentOverride für die folgenden Namespaces, um OperableParameters an die Management API-Serverunterkomponenten zu verteilen:

   • bil-monetizer-override-mp.yaml-Datei:

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

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

     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. Speichern Sie die YAML-Dateien im Ordner infrastructure/zonal/zones/ZONE_NAME/root-admin/components/bil/ORG_NAME.

4. Erstellen Sie einen Pull-Request mit den YAML-Dateien und der erforderlichen Kustomization-Datei.

1.14.5 Abrechnungsbeginn validieren

Prüfen Sie, ob Sie die Abrechnungsstartzeit für die Monetarisierung und die Rechnungserstellung überschrieben haben:

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 Netzwerkrichtlinie des Objekt-Storage-Proxys im Administratorcluster der Organisation konfigurieren

Hinweis: Gilt nur für die Org v2-Architektur (v2-Organisation). Überspringen, wenn die Architektur der Organisation V1 ist (V1-Organisation).

1.15.1 YAML-Datei für die Netzwerkrichtlinie erstellen

Erstellen Sie die YAML-Datei für die allow-obs-system-ingress-traffic-Netzwerkrichtlinie, z. B. 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 Netzwerkrichtlinie auf den Administratorcluster der Organisation anwenden

kubectl --kubeconfig ORG_ADMIN_KUBECONFIG apply -f networkpolicy.yaml

1.16. Sicherungswebsite erstellen

Wenn Sie die Unterstützung für die Notfallwiederherstellung nutzen, müssen Sie die vorherigen Schritte für den Sicherungsstandort noch einmal ausführen. Wenn Sie die Notfallwiederherstellung nicht aktiviert haben, überspringen Sie diesen Abschnitt.

1. Folgen Sie den Anweisungen in Abschnitt 1.4. – 1.9. eine weitere Organisation für die Sicherungswebsite zu erstellen.

1.17. Fehlerbehebung beim Erstellen einer Organisation

1.17.1. Prüfen, ob alle bereitgestellten Ressourcen fehlerfrei und vorhanden sind

Beim Erstellen einer Organisation werden mehrere Ressourcen in verschiedenen Kubernetes-Clustern erstellt. Prüfen Sie zuerst die bereitgestellten Ressourcen und stellen Sie sicher, dass sie sich in einem guten Zustand befinden. In den folgenden Abschnitten werden die Ressourcen beschrieben, die für eine Organisation mit dem Namen operations erstellt werden.

1.17.2. Alle bereitgestellten Ressourcen im Stamm-Admincluster bestätigen

Führen Sie die folgenden Schritte aus, um zu prüfen, ob alle Ressourcen im Administratorcluster des Stammverzeichnisses fehlerfrei und vorhanden sind:

1. Rufen Sie die erforderliche kubeconfig-Konfiguration für den Stamm-Administratorcluster gemäß IAM-R0004 ab. Legen Sie die folgenden Umgebungsvariablen und Aliase für diese Bestätigungsanleitung fest:

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

2. Prüfen Sie, ob die Firewallressourcen verfügbar sind:

   1. Stellen Sie eine SSH-Verbindung zur Firewall her und prüfen Sie, ob ein neues vsys erstellt wurde:

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

      Die Ausgabe sieht etwa so aus:

      vsys1 {
      vsys2 {
      

   2. Prüfen Sie die Ressource FirewallVirtualSystem:

      k get firewallvirtualsystem -n gpc-system
      

      Die Ausgabe sieht etwa so aus:

      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. Prüfen Sie, ob die Speicherressourcen verfügbar sind:

   1. Prüfen Sie die Ressource StorageVirtualMachine:

      k get StorageVirtualMachine -n gpc-system
      

      Die Ausgabe sieht etwa so aus:

      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. Prüfen Sie, ob die HSM-Ressourcen verfügbar sind:

   1. HSMs prüfen:

      k get hsms -n gpc-system
      

      Die Ausgabe sieht etwa so aus:

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

   2. HSM-Cluster prüfen:

      k get hsmcluster -n gpc-system
      

      Die Ausgabe sieht etwa so aus:

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

   3. HSM-Mandanten prüfen:

      k get hsmtenant -A
      

      Die Ausgabe sieht etwa so aus:

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

5. Prüfen Sie, ob die Maschinen- und Knotenressourcen verfügbar sind:

   1. Prüfen Sie die AddressPoolClaim-Ressourcen:

      k get addresspoolclaims -A
      

      Die Ausgabe sieht etwa so aus:

      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. Prüfen Sie die NodePoolClaim-Ressourcen:

      k get nodepoolclaims -A
      

      Die Ausgabe sieht etwa so aus:

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

   3. Prüfen Sie die NodePool-Ressourcen:

      k get nodepool -A
      

      Die Ausgabe sieht etwa so aus:

      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. Bare Metal-Cluster prüfen:

      k get baremetalclusters -A
      

      Die Ausgabe sieht etwa so aus:

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

   5. Prüfen Sie die Bare Metal-Maschinen:

      k get baremetalmachines -A
      

      Die Ausgabe sieht etwa so aus:

      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. Prüfen Sie die Server. Sie befinden sich im Status provisioned:

      k get servers -n gpc-system | grep provisioned
      

      Die Ausgabe sieht etwa so aus:

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

   7. Kubernetes-Cluster prüfen:

      k get cluster -A
      

      Die Ausgabe sieht etwa so aus:

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

   8. Prüfen Sie die Secrets für die kubeconfig-Datei:

      k get secrets -A | grep kubeconfig
      

      Die Ausgabe sieht etwa so aus:

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

1.17.3. Alle bereitgestellten Ressourcen in V1-Organisationsclustern bestätigen

Führen Sie die folgenden Schritte aus, um zu bestätigen, dass alle Ressourcen im Administratorcluster und Systemcluster einer v1-Organisation fehlerfrei und vorhanden sind. Wenn Sie eine Organisation der Version 2 haben, fahren Sie mit dem nächsten Abschnitt fort.

1.17.3.1. Alle bereitgestellten Ressourcen in einem Administratorcluster der Organisation bestätigen

1. Rufen Sie die erforderliche kubeconfig-Konfiguration für den Stamm-Administratorcluster gemäß IAM-R0004 ab. Legen Sie die folgenden Umgebungsvariablen und Aliasse für diese Bestätigungsanleitung fest:

   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. Prüfen Sie, ob die Maschinen- und Knotenressourcen verfügbar sind:

   1. Bare Metal-Cluster prüfen:

      ka get baremetalclusters -A
      

      Die Ausgabe sieht etwa so aus:

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

   2. Prüfen Sie die Bare Metal-Maschinen:

      ka get baremetalmachines -A
      

      Die Ausgabe sieht etwa so aus:

      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. Maschinen prüfen:

      ka get machines -A
      

      Die Ausgabe sieht etwa so aus:

      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. Prüfen Sie die VirtualmachinesInstance-Ressourcen:

      ka get virtualmachineinstances -A
      

      Die Ausgabe sieht etwa so aus:

      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. Prüfen Sie die NodePool-Ressourcen:

      ka get nodepools -A
      

      Die Ausgabe sieht etwa so aus:

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

   6. Kubernetes-Cluster prüfen:

      ka get clusters -A
      

      Die Ausgabe sieht etwa so aus:

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

   7. Knoten prüfen:

      ka get nodes -A
      

      Die Ausgabe sieht etwa so aus:

      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. Prüfen Sie die Secrets für die kubeconfig-Datei:

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

      Die Ausgabe sieht etwa so aus:

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

1.17.3.2. Alle bereitgestellten Ressourcen im Systemnutzercluster bestätigen

Führen Sie die folgenden Schritte aus, um zu bestätigen, dass alle Ressourcen im Systemcluster fehlerfrei und vorhanden sind:

1. Rufen Sie die erforderliche kubeconfig-Konfiguration für den Stamm-Administratorcluster gemäß IAM-R0004 ab. Legen Sie die folgenden Umgebungsvariablen und Aliasse für diese Bestätigungsanleitung fest:

   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. Prüfen Sie, ob die Maschinen- und Knotenressourcen verfügbar sind:

   1. Prüfen Sie die Ressource VirtualmachineInstance:

      ku get vmi -A
      

      Die Ausgabe sieht in etwa so aus (wenn ein Nutzercluster erstellt wurde):

      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. Knoten prüfen:

      ku get nodes
      

      Die Ausgabe sieht etwa so aus:

      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. Prüfen Sie die GPU-Zuweisungen:

      ku get gpuallocations -A
      

      Die Ausgabe sieht etwa so aus:

      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. Alle bereitgestellten Ressourcen in V2-Organisationsclustern bestätigen

Führen Sie die folgenden Schritte aus, um zu bestätigen, dass alle Ressourcen im Cluster der Organisationsinfrastruktur in einer V2-Organisation fehlerfrei sind und vorhanden sind. Wenn Sie eine Organisation der Version 1 haben, überspringen Sie diesen Abschnitt.

1. Rufen Sie die erforderliche kubeconfig-Konfiguration für den Stamm-Administratorcluster gemäß IAM-R0004 ab. Legen Sie die folgenden Umgebungsvariablen und Aliasse für diese Bestätigungsanleitung fest:

   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. Prüfen Sie, ob die Knoten und API-Server fehlerfrei sind:

   1. Knoten prüfen:

      ka get nodes -A
      

      Die Ausgabe sieht etwa so aus:

      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. Prüfen Sie die Secrets für die kubeconfig-Datei:

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

      Die Ausgabe sieht etwa so aus:

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

3. Prüfen Sie die GPU-Zuweisungen, um zu bestätigen, dass die GPU-Ressourcen bereit sind (falls zutreffend):

   ka get gpuallocations -A
   

   Die Ausgabe sieht etwa so aus:

   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. Prüfen, ob alle Organisationsressourcen abgeglichen wurden

Führen Sie die folgenden Schritte aus, um zu bestätigen, dass alle organisationsbezogenen Ressourcen im globalen und zonalen Root-Admin-Cluster fehlerfrei und vorhanden sind. Angenommen, das Ziel ist, eine operations-Organisation mit zwei Zonen zu erstellen: zone-1 und zone-2.

Hinweis :Für jede Ressource können Sie die status mit kubectl describe aufrufen, um detailliertere Informationen zu Fehlern zu erhalten. status ist ein aggregierter Status aller Zonen. Das Feld rolloutStatus enthält zonale Weiterleitungsdetails und das Feld replicaStatus enthält zonale Details zur Ressourcenbereitstellung.

1. Folgen Sie der Anleitung unter Auf globale Root-Admin-API zugreifen, um auf den globalen API-Server zuzugreifen, und verwenden Sie den folgenden Alias für die globale Root-Admin-API kubectl.

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

2. Prüfen Sie, ob globale Organisationsressourcen verfügbar sind:

   1. Prüfen Sie die globalen Organization-Ressourcen:

      kga get organization -A
      

      Die Ausgabe sieht etwa so aus:

      NAMESPACE    NAME         READY
      gpc-system   operations
      gpc-system   root
      

   2. Prüfen Sie die globalen OrganizationReplica-Ressourcen:

      kga get organizationreplica -A
      

      Die Ausgabe sieht etwa so aus:

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

   3. Prüfen Sie die globalen OrganizationZonalConfig-Ressourcen:

      kga get organizationzonalconfig -A
      

      Die Ausgabe sieht etwa so aus:

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

   4. Prüfen Sie die globalen OrganizationZonalConfigReplica-Ressourcen:

      kga get organizationzonalconfigreplica -A
      

      Die Ausgabe sieht etwa so aus:

      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. Legen Sie den Alias für die kubeconfig-Konfiguration des zonalen Administratorclusters fest:

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

4. Prüfen Sie, ob zonale Organisationsressourcen verfügbar sind:

   1. Prüfen Sie die Organization-Ressourcen:

      ka get organization -A
      

      Die Ausgabe sieht etwa so aus:

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

   2. Prüfen Sie die OrganizationReplica-Ressourcen:

      ka get organizationreplica -A
      

      Die Ausgabe sieht etwa so aus:

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

   3. Prüfen Sie die OrganizationZonalConfigReplica-Ressourcen:

      ka get organizationzonalconfigreplica -A
      

      Die Ausgabe sieht etwa so aus:

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

5. Folgen Sie der Anleitung unter Beliebigen Adressen den Zugriff auf eine Organisation erlauben, um DCI-Traffic in den Administratorclustern der Organisation von der Quellwebsite zur Sicherungswebsite zuzulassen.