1. Buat organisasi pelanggan

Perkiraan waktu penyelesaian: 3 jam

Profil keterampilan: engineer deployment

Sebagai Operator, Anda dapat membuat organisasi untuk memberikan akses pelanggan ke infrastruktur platform. Untuk mendapatkan izin yang diperlukan untuk membuat organisasi, minta Admin Keamanan Anda untuk memberi Anda peran Admin Organisasi.

Resource Organization adalah node root hierarki resource air-gapped Google Distributed Cloud (GDC) dan semua resource yang termasuk dalam grup organisasi di bawah node organisasi. Hal ini memberikan visibilitas dan kontrol terpusat atas setiap resource yang menjadi milik organisasi.

Untuk mengetahui informasi selengkapnya tentang organisasi, lihat Ringkasan organisasi.

1.1. Sebelum memulai

Pastikan Anda telah menginstal berikut:

  • Browser di sistem Anda.

  • Antarmuka command line (CLI) Git.

  • kubectl CLI.

  • gdcloud CLI.

1.2. Membuat klien OIDC di OC IT ADFS

  1. Lihat petunjuk konfigurasi OIDC ADFS untuk membuat klien OpenID Connect (OIDC) di ADFS agar Operator dapat mengakses organisasi yang akan Anda buat. Catat ID klien dan rahasia klien OIDC. Anda tidak boleh menggunakan kembali klien dalam koneksi ke cluster lain, seperti cluster admin root dan cluster admin org lainnya, atau layanan seperti ServiceNow.

  2. Tambahkan URL callback GKE Identity Service berikut ke daftar yang diizinkan di klien OIDC ADFS yang Anda buat untuk organisasi yang akan Anda buat:

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

    Contoh:

    • nama organisasi: operations
    • Nama instance Distributed Cloud: google
    • Nama domain Distributed Cloud: gdch.test

    URL callback GKE Identity Service dalam hal ini adalah https://ais-core.operations.google.gdch.test/finish-login.

  3. Tambahkan URL panggilan balik GKE Identity Service berikut ke daftar yang diizinkan di klien OIDC ADFS yang Anda buat untuk setiap zona di semesta GDC Anda:

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

    Contoh:

    • nama organisasi: operations
    • nama zona: zone-1
    • Nama instance Distributed Cloud: google
    • Nama domain Distributed Cloud: gdch.test

    URL callback GKE Identity Service dalam hal ini adalah https://ais-core.operations.zone-1.google.gdch.test/finish-login.

  4. Tetapkan variabel berikut untuk digunakan di bagian selanjutnya:

    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

    Ganti variabel dengan nilai berikut:

    VariabelDefinisi
    ADFS_CERT_BASE64 File adfs.pem berenkode base64.
    ADFS_CLIENT_ID ID klien ADFS.
    ADFS_CLIENT_SECRET Rahasia bersama klien ADFS.
    ADFS_ISSUER_URI URI penerbit ADFS. Untuk mendapatkan URI, periksa jalur /adfs/.well-known/openid-configuration server ADFS:

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

    Nilainya biasanya https://adfs.domain.com/adfs.

1.3 Buat subnet global dan bagi subnet tersebut untuk setiap zona

Sebelum membuat organisasi, Anda harus membuat subnet root global dan membaginya untuk setiap zona dengan subnet IP address management (IPAM) public API. Jika Anda membuat organisasi v2 baru di zona yang sebelumnya memiliki organisasi v1, pastikan untuk melihat halaman prasyarat tambahan sebelum membuat subnet global.

Subnet root global menghosting kumpulan rentang alamat IP (CIDR) root yang dibagi ke setiap zona untuk mem-bootstrap semua cluster dalam organisasi tenant, termasuk cluster infrastruktur org, dan VM workload. Sebagian kecil rentang alamat IP juga disediakan untuk subnet root sebagai kumpulan alamat IP anycast. Anda dapat menetapkan CIDR khusus secara otomatis ke setiap zona menggunakan pengontrol, atau Anda dapat memberikan CIDR ke setiap zona secara manual.

Untuk mem-bootstrap organisasi, Anda memerlukan input rentang alamat IP internal dari Kuesioner Input Organisasi (OIQ). Anda harus menggunakan rentang alamat IP tersebut untuk membuat subnet root global di server API global.

Anda harus membuat subnet root yang berbeda untuk setiap server API global. Pemetaan kolom OIQ, nama subnet root global, dan server API global disediakan di bagian berikutnya.

1.3.1. Tentukan rentang CIDR untuk OIQ

Rentang CIDR tidak boleh tumpang-tindih satu sama lain dan tidak boleh tumpang-tindih dengan zone-infra-cidr.

zone-infra-cidr ada di setiap zona dan dapat diambil dari Customer Intake Questionnaire (CIQ) jika pelanggan mendefinisikannya.

Untuk mengambil zone-infra-cidr, jalankan:

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

Berikut adalah contoh output YAML:

apiVersion: system.private.gdc.goog/v1alpha1
kind: CIDRClaim
metadata:
  name: zone-infra-cidr
  namespace: gpc-system
spec:
  ipv4Spec:
    staticCidrBlocks:
    - 192.0.2.0/24
  ipv6Spec:
    staticCidrBlocks:
    - 2001:db8::/32
status:
  ipv4AllocationStatus:
    cidrBlocks:
    - 192.0.2.0/24
  ipv6AllocationStatus:
    cidrBlocks:
    - 2001:db8::/32

Dalam contoh ini, zone-infra-cidr adalah 192.0.2.0/24, sehingga kolom apa pun di OIQ tidak boleh tumpang-tindih dengan 192.0.2.0/24.

Tabel berikut menunjukkan kolom OIQ dan nilai minimum default yang sesuai:

Kolom OIQ Deskripsi Ukuran minimum yang dibutuhkan Ukuran minimum per zona untuk organisasi Nama subnet root global Server API global
infraVPCCIDR Beban kerja sistem, termasuk konsol organisasi, API pengelolaan, dan layanan pihak pertama. \( 15 - \lceil \log_2(ZoneNumber) \rceil \) 16 infra-vpc-root-cidr Root global
defaultVPCCIDR Endpoint dan beban kerja pengguna di VPC default di seluruh zona. \( 16 - \lceil \log_2(ZoneNumber) \rceil \) 16 default-vpc-root-cidr Organisasi global
orgAdminExternalCIDR Workload dan endpoint di cluster perimeter yang menangani traffic administratif antara jaringan eksternal dan organisasi. \( 22 - \lceil \log_2(ZoneNumber) \rceil \) 23 admin-external-root-cidr Root global
orgDataExternalCIDR Beban kerja dan endpoint yang dapat dijangkau secara eksternal oleh pengguna seperti load balancer eksternal dan NAT keluar. \( 22 - \lceil \log_2(ZoneNumber) \rceil \) 23 data-external-root-cidr Root global

Jika Anda tidak memiliki IP yang cukup sebagai saran minimum default, Anda harus mengikuti proses pemisahan manual untuk membuat subnet untuk setiap zona.

Pertimbangkan batasan berikut untuk rentang subnet IPv4:

  • orgDataExternalCIDR, orgAdminExternalCIDR, infraVPCCIDR, dan defaultVPCCIDR tidak boleh tumpang-tindih satu sama lain, dengan rentang yang dialokasikan lainnya dalam organisasi, dan dengan rentang IPv4 apa pun di Jaringan yang di-peering. CIDR untuk alamat ini berasal dari ruang alamat pribadi RFC 1918.

    Jaringan yang di-Peering: Dapat berupa subnet apa pun yang diiklankan dengan Jaringan eksternal melalui lampiran interkoneksi atau subnet yang di-peering dengan VPC lain dalam organisasi yang sama.

  • Jika organisasi berbagi resource AttachmentGroup interkoneksi yang sama, nilai orgDataExternalCIDR dan orgAdminExternalCIDR harus unik. Jika tidak, tumpang-tindih dengan organisasi lain diizinkan.

1.3.2. Membuat subnet global di server API admin root global

Anda harus membuat subnet berikut di server API admin root global sebelum membuat organisasi:

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

Subnet ini diperlukan untuk mem-bootstrap cluster infrastruktur org organisasi di setiap zona.

  1. Anda harus memiliki namespace dengan nama yang cocok dengan nama organisasi yang akan Anda tetapkan ke organisasi Anda. Konfirmasi bahwa namespace ini ada:

    kubectl --kubeconfig GLOBAL_ROOT_ADMIN_KUBECONFIG get namespace

    Jika namespace ini tidak ada, buat namespace tersebut:

    kubectl --kubeconfig GLOBAL_ROOT_ADMIN_KUBECONFIG create namespace ORG_NAME

  2. Buat file YAML subnet infra-vpc-root-cidr, seperti 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. Buat file YAML subnet admin-external-root-cidr, seperti 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. Buat file YAML subnet data-external-root-cidr, seperti 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. Salin file YAML subnet infra-vpc-root-cidr, admin-external-root-cidr, dan data-external-root-cidr ke repositori IAC untuk organisasi root:

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

  6. Pastikan file kustomization.yaml di root organisasi memiliki definisi Subnet yang baru ditambahkan. Periksa 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. Siapkan dan lakukan commit pada file YAML subnet:

    git add "IAC_REPO_PATH/iac/infrastructure"
git commit

  8. Buat permintaan penggabungan:

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

  9. Tunggu peninjauan dan penggabungan kode.

1.3.3. Membagi subnet root untuk zona

Subnet root global menghosting rentang alamat IP root (CIDR) untuk semua zona. Untuk menggunakan rentang alamat IP di zona, subnet root global harus terlebih dahulu dibagi menjadi subnet yang lebih kecil agar dapat digunakan oleh zona. Setiap zona harus memiliki setidaknya satu rentang alamat IP root.

IPAM memiliki pengontrol global yang secara otomatis membagi subnet root global menjadi subnet yang lebih kecil untuk zona yang ada. Administrator dapat mendelegasikan ke pengontrol IPAM untuk membagi subnet zona secara otomatis jika mereka tidak peduli dengan blok CIDR yang tepat yang digunakan zona tertentu. Pengontrol memantau pembuatan subnet root global, dan membuat subnet untuk setiap zona dengan panjang awalan default tetap.

Subnet root zona Panjang awalan tetap default
defaultZoneInfraVPCSubnetSize 16
defaultZoneAdminVRFSubnetSize 23
defaultZoneDataVRFSubnetSize 23
defaultZoneDefaultVPCSubnetSize 16
defaultAnycastSubnetSize 26

Subnet root global harus memiliki nama tetap jika Anda ingin pengontrol IPAM membagi subnet zona secara otomatis:

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

Jika Anda menyetel anotasi ipam.gdc.goog/pause-auto-division: true untuk resource Subnet, Anda harus menentukan blok CIDR persis yang digunakan zona tertentu secara manual. Jika Anda membuat subnet root global dengan nama yang berbeda, anotasi ipam.gdc.goog/pause-auto-division tidak akan berpengaruh dan subnet global tidak akan dibagi secara otomatis.

1.3.3.1. Membagi subnet root secara otomatis untuk zona

Pengontrol global secara otomatis membagi subnet root global menjadi subnet yang lebih kecil untuk zona yang ada. Misalnya, pertimbangkan alur kerja berikut untuk memahami cara pengontrol membagi subnet root global menjadi subnet yang lebih kecil untuk zona yang ada:

Jika ada dua zona bernama zone1 dan zone2, contoh subnet root global infra-vpc-root-cidr yang menggunakan infraVPCCIDR, seperti 10.0.0.0/16, dari OIQ di namespace org-1 akan terlihat seperti ini:

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

Saat di-deploy ke platform GDC, pengontrol akan otomatis membuat dua subnet turunan bernama infra-vpc-zone1-root-cidr dan infra-vpc-zone2-root-cidr dengan panjang awalan /16:

apiVersion: ipam.global.gdc.goog/v1
kind: Subnet
metadata:
  labels:
    ipam.gdc.goog/vpc: infra-vpc
    ipam.gdc.goog/usage: zone-network-root-range
  annotations:
    ipam.gdc.goog/pivot-destination: global-org
  name: infra-vpc-zone1-root-cidr
  namespace: org-1
spec:
  ipv4Request:
    prefixLength: 16
  zone: zone1
  propagationStrategy: SingleZone
  type: Branch
  parentReference:
    name: infra-vpc-root-cidr
    namespace: org-1

apiVersion: ipam.global.gdc.goog/v1
kind: Subnet
metadata:
  labels:
    ipam.gdc.goog/vpc: infra-vpc
    ipam.gdc.goog/usage: zone-network-root-range
  annotations:
    ipam.gdc.goog/pivot-destination: global-org
  name: infra-vpc-zone2-root-cidr
  namespace: org-1
spec:
  ipv4Request:
    prefixLength: 16
  zone: zone2
  propagationStrategy: SingleZone
  type: Branch
  parentReference:
    name: infra-vpc-root-cidr
    namespace: org-1

1.3.3.2. Membagi subnet root secara manual untuk zona

Bagian ini mengasumsikan Anda menetapkan anotasi ipam.gdc.goog/pause-auto-division: true saat membuat subnet root global di server API admin root global. Anotasi ini menjeda pengontrol untuk merekonsiliasi subnet root global tersebut, yang memungkinkan Anda membuat subnet root dan subnet anycast zona secara manual.

Untuk membagi subnet root global secara manual menjadi subnet yang lebih kecil untuk zona, lakukan langkah-langkah berikut:

  1. Mencantumkan zona di semesta Anda:

    kubectl --kubeconfig GLOBAL_ROOT_ADMIN_KUBECONFIG get zone -A

  2. Konfirmasi CIDR khusus dari subnet root yang ingin Anda terapkan ke zona. Lakukan hal ini untuk setiap zona di semesta Anda.

  3. Tetapkan CIDR khusus ke subnet untuk zona Anda dalam file YAML, seperti ORG_NAME-infra-vpc-zone1-root-cidr.yaml:

    apiVersion: ipam.global.gdc.goog/v1
kind: Subnet
metadata:
  labels:
    ipam.gdc.goog/vpc: infra-vpc
    ipam.gdc.goog/usage: zone-network-root-range
  annotations:
    ipam.gdc.goog/pivot-destination: global-org
  name: infra-vpc-zone1-root-cidr
  namespace: ORG_NAME
spec:
  ipv4Request:
    cidr: ZONAL_CIDR
  zone: ZONE_NAME
  propagationStrategy: SingleZone
  type: Branch
  parentReference:
    name: infra-vpc-root-cidr
    namespace: ORG_NAME

    Ulangi langkah ini untuk setiap zona di semesta GDC Anda.

  4. Konfirmasi CIDR khusus dari subnet root yang ingin Anda terapkan ke subnet anycast.

  5. Tetapkan CIDR khusus ke subnet anycast dalam file YAML, seperti ORG_NAME-infra-vpc-anycast-cidr.yaml:

    apiVersion: ipam.global.gdc.goog/v1
kind: Subnet
metadata:
  labels:
    ipam.gdc.goog/vpc: infra-vpc
  annotations:
    ipam.gdc.goog/pivot-destination: global-org
  name: infra-vpc-anycast-cidr
  namespace: ORG_NAME
spec:
  ipv4Request:
    cidr: ANYCAST_CIDR
  propagationStrategy: None
  type: Branch
  parentReference:
    name: infra-vpc-root-cidr
    namespace: ORG_NAME

  6. Salin file YAML subnet zonal ke repositori IAC untuk organisasi root. Misalnya, jika Anda memiliki dua file YAML subnet zona:

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

  7. Pastikan file kustomization.yaml di root organisasi memiliki definisi Subnet yang baru ditambahkan. Periksa 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. Siapkan dan lakukan commit pada file YAML subnet:

    git add "IAC_REPO_PATH/iac/infrastructure"
git commit

  9. Buat permintaan penggabungan:

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

  10. Tunggu peninjauan dan penggabungan kode.

1.3.3.2.1. Contoh pemisahan manual subnet root untuk zona bagi infra-vpc

Jika ada dua zona bernama zone1 dan zone2, contoh subnet root global infra-vpc-root-cidr yang menggunakan infraVPCCIDR, seperti 192.0.2.0/24, dari OIQ di namespace org-1 akan terlihat seperti ini:

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

Buat subnet secara manual untuk setiap zona bernama infra-vpc-zone1-root-cidr dan infra-vpc-zone2-root-cidr, serta subnet anycast infra-vpc-anycast-cidr dengan CIDR khusus yang Anda tentukan:

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

Pastikan untuk menambahkan semua file YAML subnet ke repositori IAC.

1.3.3.2.2. Contoh pemisahan manual subnet root untuk zona bagi segmen jaringan data

Jika ada dua zona bernama zone1 dan zone2, contoh subnet root global data-external-root-cidr yang menggunakan orgDataExternalCIDR, seperti 10.0.0.0/24, dari OIQ di namespace org-1 akan terlihat seperti ini:

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

Buat subnet secara manual untuk setiap zona bernama data-external-zone1-root-cidr dan data-external-zone2-root-cidr, serta subnet anycast data-global-anycast-cidr dengan CIDR khusus yang Anda tentukan:

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

Pastikan untuk menambahkan semua file YAML subnet ke repositori IAC.

1.3.3.2.3. Contoh pemisahan manual subnet root untuk zona bagi segmen jaringan admin

Jika ada dua zona bernama zone1 dan zone2, contoh subnet root global admin-external-root-cidr yang menggunakan orgAdminExternalCIDR, seperti 192.168.1.0/24, dari OIQ di namespace org-1 akan terlihat seperti ini:

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

Buat subnet secara manual untuk setiap zona bernama admin-external-zone1-root-cidr dan admin-external-zone2-root-cidr serta subnet anycast admin-global-anycast-cidr dengan CIDR khusus yang Anda tentukan:

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

Pastikan untuk menambahkan semua file YAML subnet ke repositori IAC.

1.4. Membuat organisasi dengan IAC

Menggunakan IAC untuk membuat organisasi:

  1. Buat daftar server dan jenis server yang tersedia:

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

    Contoh outputnya mirip dengan berikut ini:

    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

    Saat menentukan --server-quota dan --admin-server nanti, pastikan Anda memiliki server available yang cukup untuk memenuhi permintaan.

  2. Buka repositori iac dan tambahkan struktur direktori untuk organisasi baru:

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

  3. Buat resource kustom Organization:

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

    Contoh:

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

    Ganti variabel berikut:

    VariabelDefinisi
    ORG_NAME Nama organisasi. Nama organisasi harus memenuhi kriteria berikut:
    • Terdiri dari 3 hingga 19 huruf ASCII kecil, digit, atau tanda hubung.
    • Awali dengan huruf.
    • Tidak memiliki tanda hubung di akhir.
    • Tidak boleh diakhiri dengan string -system.
    LOG_RETENTION_POLICY Konfigurasi waktu retensi untuk log audit, log operasional, dan metrik dalam hari.
    KMS_ROOT_KEY_TYPE Konfigurasi ini menyimpan jenis kunci root yang dipilih untuk KMS organisasi. Setiap layanan KMS memiliki kunci root untuk mengenkripsi kunci yang dihasilkan oleh KMS. Secara default, KMS membuat kunci root CTM, kunci root yang disimpan di Thales CipherTrust Manager yang di-backup oleh HSM fisik. Anda juga dapat memilih kunci root software yang disimpan sebagai secret kubernetes. Teruskan ctm-root atau local-root untuk kmsRootKeyType.

    Contoh file YAML resource kustom Organization yang dihasilkan mirip dengan berikut ini:

    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. Opsional: Di versi 1.14.2 dan yang lebih baru, enkripsi IPsec node-ke-node dinonaktifkan secara default. Jika enkripsi IPsec ini diperlukan, Anda dapat mengaktifkan enkripsi IPsec node-ke-node dengan mengedit file YAML resource kustom Organization dan menambahkan anotasi:

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

    Nilai "false" untuk anotasi ini akan mengaktifkan enkripsi.

  5. Buat resource kustom OrganizationZonalConfig untuk setiap zona dalam deployment:

    gdcloud organizations zonal-configs create --name ORG_NAME \
    --zones=ZONES \
    --version GDC_VERSION \
    --server-quota SERVER_QUOTA \
    --storage-sku STORAGE_SIZE \
    --admin-server ADMIN_SERVER

    Contoh:

    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

    Ganti variabel berikut:

    VariabelDefinisi
    ORG_NAME Nama organisasi. Nama organisasi harus memenuhi kriteria berikut:
    • Terdiri dari 3 hingga 30 huruf kecil ASCII, angka, atau tanda hubung.
    • Awali dengan huruf.
    • Tidak memiliki tanda hubung di akhir.
    • Tidak boleh diakhiri dengan string -system.
    ZONES Nama zona dalam deployment.
    GDC_VERSION Versi sistem GDC untuk membuat organisasi.
    SERVER_QUOTA Server yang akan dialokasikan untuk cluster admin org dan cluster sistem saat dibuat secara otomatis. Jika Anda ingin menjalankan resource unit pemrosesan grafis (GPU) yang merupakan workload berbasis VM, seperti API kecerdasan buatan dan machine learning (AI/ML) yang telah dilatih sebelumnya, Anda harus menyediakan mesin GPU saat membuat organisasi. Untuk mengetahui informasi selengkapnya, lihat bagian Mengaktifkan dukungan GPU untuk cluster sistem.
    ADMIN_SERVER Pasangan nilai kunci jenis server dan jumlah server admin org yang akan dialokasikan untuk jenis server tersebut. Jenis campuran tidak didukung untuk server. Nilai defaultnya adalah o1-standard1-64-gdc-metal: 3.
    STORAGE_SIZE Ukuran berbagai jenis penyimpanan yang akan ditetapkan untuk organisasi. Ukuran penyimpanan blok minimum untuk organisasi adalah 250 GiB, yang ditetapkan dengan flag BlockStandard.

    Contoh file YAML resource kustom OrganizationZonalConfig yang dihasilkan mirip dengan berikut ini:

    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. Tinjau file YAML yang dibuat. File berada di direktori HOME.

    1. Konfirmasi jenis organisasi Anda. Ada dua jenis organisasi yang dapat Anda sediakan:

      • Arsitektur Org v1 (organisasi v1)
      • Arsitektur Org v2 (organisasi v2)

      Secara default, organisasi baru disediakan berdasarkan jenis deployment Anda seperti yang ditetapkan oleh setelan gerbang fitur Anda:

      • Deployment PRODUCTION membuat organisasi v2 secara default.
      • Deployment ACCREDITED membuat organisasi v1 secara default.

      Jika Anda harus mengganti jenis organisasi default untuk jenis deployment, perbarui kolom spec.compatibilityOptions.architectureOverridePolicy di resource kustom Organization yang dihasilkan menjadi ForceV1 atau ForceV2, bergantung pada jenis organisasi yang ingin Anda gunakan. Misalnya, cuplikan berikut memaksa pembuatan organisasi v2 dalam deployment ACCREDITED:

      ...

spec:
...
  compatibilityOptions:
    architectureOverridePolicy: ForceV2

...

    2. Konfirmasi setelan yang tersisa untuk memastikan komponen seperti penyimpanan dan daya komputasi cukup untuk kebutuhan perusahaan Anda.

  7. Salin resource kustom Organization dan OrganizationZonalConfig ke repositori di direktori organisasi baru:

    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/

    Ganti kode berikut:

    • ORG_NAME: nama organisasi yang Anda tentukan dalam perintah gdcloud organizations config create menggunakan parameter --name.
    • ZONE: nama setiap zona dalam deployment. Nama zona diperoleh menggunakan format berikut: {generalRegion}-{regionQualifier}{regionCounter}-{zoneLetter}. Misalnya, us-central1-b. Lihat bagian Zona dalam Kuesioner Penerimaan Pelanggan untuk mengetahui deskripsi nilai atribut zona.

  8. Tambahkan file kustomization.yaml untuk organisasi baru:

    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. Tambahkan organisasi baru sebagai resource organisasi root:

    1. Buka file kustomization.yaml root global:

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

    2. Tambahkan Organization baru sebagai resource di akhir daftar resource yang ada:

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

  10. Siapkan dan lakukan commit pada file YAML organisasi dan file kustomisasi:

    git add "IAC_REPO_PATH/iac/infrastructure"
git commit

  11. Buat permintaan penggabungan:

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

  12. Tunggu peninjauan dan penggabungan kode.

  13. Pastikan konfigurasi organisasi global dan zona tersedia:

    1. Verifikasi bahwa organisasi global tersedia di semesta GDC Anda:

      kubectl get organization -A

      Outputnya mirip dengan hal berikut ini:

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

    2. Periksa status organisasi global:

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

      Pastikan kondisi status dalam output YAML adalah True.

    3. Periksa status konfigurasi organisasi di setiap zona:

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

      Untuk mengalihkan konteks zona, gunakan gcloud CLI untuk login ke setiap zona sebelum memeriksa status organisasi. Pastikan kondisi status dalam output YAML untuk setiap zona adalah True.

1.5. Membuat subnet global di server API organisasi global

Anda harus membuat default-vpc-root-cidr di server API global organisasi dalam namespace platform setelah server API global berjalan. Subnet root ini mengalokasikan alamat IP untuk cluster di dalam organisasi tenant, seperti cluster pengguna, serta alamat IP untuk workload VM.

  1. Buat file YAML subnet default-vpc-root-cidr, seperti 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. Buka repositori iac dan tambahkan struktur direktori untuk organisasi global:

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

  3. Salin file YAML subnet default-vpc-root-cidr ke repositori IAC di direktori organisasi baru:

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

  4. Buat file kustomization.yaml di folder organisasi dengan definisi Subnet yang baru ditambahkan. Periksa 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. Siapkan dan lakukan commit pada file YAML organisasi dan file kustomisasi:

    git add "IAC_REPO_PATH/iac/infrastructure"
git commit

  6. Buat permintaan penggabungan:

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

  7. Tunggu peninjauan dan penggabungan kode.

Mirip dengan cara subnet global di cluster admin root global dibagi, default-vpc-root-cidr juga dibagi dan dipropagasi ke setiap zona agar organisasi zonal dapat menggunakan alamat IP.

1.7. Mengonfigurasi NTPRelay org-admin

Anda harus mengonfigurasi autentikasi secara manual antara NTPRelay root-admin dan org-admin.

Ikuti NTP-P0001.3 (Root Admin -> Org Admin NTPRelay Encryption) untuk mengonfigurasi enkripsi untuk organisasi ini.

1.8. Menghubungkan penyedia identitas IO ke organisasi dengan IAC

  1. Lihat panduan ADFS untuk membuat klien OIDC di ADFS untuk organisasi baru dan catat ID klien dan rahasia klien dari klien OIDC.

  2. Tetapkan nama organisasi Anda sebagai variabel lingkungan:

    export ORG_NAME=ORG_NAME

    Pastikan ORG_NAME cocok dengan nama organisasi yang tepat.

  3. Ekspor file kubeconfig cluster admin root dan jalankan perintah kubectl berikut untuk mendapatkan nama cluster dan zona:

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

  4. Tambahkan file ioauthmethod.yaml untuk organisasi:

    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

    Ganti variabel berikut:

    VariabelDefinisi
    ADFS_CERT_BASE64 Encoding base64 dari sertifikat yang digunakan ADFS untuk menandatangani sendiri, yang diperlukan oleh GKE Identity Service untuk membuat koneksi yang aman dengan instance ADFS internal.
    ADFS_ORG_CLIENT_ID ID OpenID Connect untuk klien organisasi di ADFS.
    ADFS_ORG_CLIENT_SECRET Rahasia OpenID Connect untuk klien organisasi yang terdaftar di ADFS.
    ADFS_ISSUER_URI URI penerbit yang valid, yang diperlukan oleh Layanan Identitas GKE untuk mengizinkan permintaan login pengalihan ke ADFS.

  5. Tambahkan file initial-admin.yaml untuk organisasi:

    cat > infrastructure/global/orgs/${ORG_NAME}/initial-admin.yaml << EOF
apiVersion: iam.private.gdc.goog/v1alpha1
kind: ExpirationClusterRoleBinding
metadata:
  name: iac-binding-USER-org-iam-admin
spec:
  expirationTimestamp: EXPIRATION
  roleRef:
    apiGroup: rbac.authorization.k8s.io
    kind: ClusterRole
    name: organization-iam-admin
  subjects:
    - apiGroup: rbac.authorization.k8s.io
      kind: User
      name: gdch-infra-operator-USER@opscenter.local
EOF

    Ganti variabel berikut:

    VariabelDefinisi
    USER Nama pengguna dengan awalan IO untuk login ke cluster pada awalnya. Jangan lupa untuk menambahkan awalan ke nama pengguna.
    EXPIRATION Stempel waktu berformat RFC 3339 saat sistem mencabut akses. Contoh, "2020-11-14T00:20:12+00:00"

  6. Tambahkan file yang baru dibuat ke file kustomization.yaml di IAC_REPO_PATH /iac/infrastructure/global/orgs/ORG_NAME/kustomization.yaml:

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

  7. Siapkan dan lakukan commit pada file YAML organisasi dan file kustomisasi:

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

  8. Kirim update ke GitLab:

    git -c http.sslVerify=false push

  9. Tunggu peninjauan dan penggabungan kode.

  10. Untuk mengonfirmasi bahwa Operator dapat mengakses organisasi, login ke organisasi yang dibuat dan jalankan perintah berikut untuk memverifikasi bahwa penyedia identitas (IdP) ada di ClientConfig organisasi:

    1. Tetapkan file kubeconfig cluster admin Anda, bergantung pada arsitektur organisasi Anda:

      • Untuk organisasi v1, jalankan:

        export KUBECONFIG=ORG_ADMIN_CLUSTER_KUBECONFIG

        Ganti ORG_ADMIN_CLUSTER_KUBECONFIG dengan jalur ke kubeconfig cluster admin org, seperti /tmp/${ORG}-admin-kubeconfig.

      • Untuk organisasi v2, jalankan:

        export KUBECONFIG=ORG_INFRA_CLUSTER_KUBECONFIG

        Ganti ORG_INFRA_CLUSTER_KUBECONFIG dengan jalur ke kubeconfig cluster infrastruktur org, seperti /tmp/${ORG}-infra-kubeconfig.

    2. Verifikasi bahwa IdP ada di ClientConfig organisasi:

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

  11. Untuk versi 1.14.3, Anda harus menerapkan peran global-zone-viewer secara manual agar semua pengguna terautentikasi dapat melihat zona di universe menggunakan gcloud CLI. Terapkan resource binding peran dan peran:

    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

    Ganti ORG_GLOBAL_API_SERVER_KUBECONFIG dengan file kubeconfig server API global organisasi. Untuk mengetahui informasi selengkapnya, lihat Membuat file kubeconfig secara manual.

1.9. Menghubungkan penyedia identitas pelanggan ke organisasi

Untuk menghubungkan penyedia identitas (IdP) pelanggan ke organisasi dan login ke organisasi dengan identitas mereka, selesaikan langkah-langkah berikut:

  1. Login dari CLI dengan akun Admin IO awal yang ditetapkan selama pembuatan organisasi, yang otomatis terikat ke org-iam-admin di cluster admin org.

  2. Minta pelanggan untuk menambahkan URL callback AIS global berikut ke daftar yang diizinkan di klien OIDC atau SAML yang dibuat pelanggan untuk organisasi yang akan Anda buat:

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

    Misalnya, jika URL root GDC berada di .google.gdch.test dan nama organisasi adalah operations, URL callback AIS global adalah https://ais-core.operations.google.gdch.test/finish-login.

    Jika menggunakan klien SAML, Anda juga harus menambahkan URL callback SAML AIS global berikut ke daftar yang diizinkan:

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

  3. Minta pelanggan untuk menambahkan URL callback AIS berikut ke daftar yang diizinkan di klien OIDC atau SAML yang dibuat pelanggan untuk setiap zona. Misalnya, untuk semesta tiga zona, URL callback AIS zonal mirip dengan berikut ini:

    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

    Jika URL root GDC adalah .google.gdch.test, nama zona adalah zone-1, dan nama organisasi adalah operations, URL panggilan balik AIS adalah https://ais-core.operations.zone-1.google.gdch.test/finish-login.

    Jika Anda menggunakan klien SAML, Anda juga harus menambahkan URL panggilan balik SAML AIS berikut ke daftar yang diizinkan untuk setiap zona:

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

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

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

  4. Tetapkan file kubeconfig cluster admin Anda, bergantung pada arsitektur organisasi Anda. Jika Anda sudah menyetel variabel kubeconfig, lewati langkah ini.

    • Untuk organisasi v1, jalankan:

        export KUBECONFIG=ORG_ADMIN_CLUSTER_KUBECONFIG

      Ganti ORG_ADMIN_CLUSTER_KUBECONFIG dengan jalur ke kubeconfig cluster admin org, seperti /tmp/${ORG}-admin-kubeconfig.

    • Untuk organisasi v2, jalankan:

        export KUBECONFIG=MANAGEMENT_API_SERVER_KUBECONFIG

      Ganti MANAGEMENT_API_SERVER_KUBECONFIG dengan jalur ke kubeconfig server Management API, seperti /tmp/${ORG}-management-kubeconfig.

  5. Dari tiket permintaan pelanggan untuk organisasi baru, tentukan apakah IdP menggunakan OIDC atau SAML. Ikuti panduan yang sesuai dengan jenis IdP yang diberikan:

Penyiapan dengan OIDC

  1. Buat file identity-provider-config.yaml, dan isi dengan merujuk pada tiket pembuatan organisasi untuk nilai IdP Akun PA:

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

  2. Berikut deskripsi mendetail kolom-kolomnya:

    Atribut Jenis atribut Deskripsi
    certificateAuthorityData Wajib Sertifikat otoritas sertifikat berformat PEM yang dienkode ke base64 standar untuk penyedia OIDC.
    clientID Wajib ID untuk aplikasi klien yang membuat permintaan autentikasi ke penyedia OpenID.
    clientSecret Wajib Rahasia bersama antara aplikasi klien OIDC dan penyedia OIDC.
    extraParams Opsional Daftar pasangan nilai kunci yang dipisahkan koma yang dikodekan kueri dan dikirim dengan permintaan endpoint otentikasi.
    groupPrefix Opsional Awalan yang akan ditambahkan ke klaim grup untuk mencegah bentrokan dengan grup yang ada, biasanya digunakan saat mengonfigurasi beberapa penyedia identitas.
    Anda harus menyertakan awalan grup sebelum semua nama grup Anda. Misalnya, jika Anda memiliki myprefix- sebagai awalan grup dan grup bernama groupA di penyedia identitas, saat menambahkan kebijakan atau binding, Anda harus mengikat myprefix-groupA. Nama grup ditetapkan di kolom groupsClaim.
    groupsClaim Opsional Nama klaim di Token ID OIDC yang menyimpan informasi grup pengguna. Nama ini harus sama dengan nama klaim yang berisi informasi keanggotaan grup di penyedia OIDC Anda.
    issuerURI Wajib URL tempat permintaan otorisasi dikirim ke penyedia OIDC Anda. URI ini harus mengarah ke level di dalam .well-known/openid-configuration.
    scopes Opsional Daftar ID yang dipisahkan koma untuk menentukan hak istimewa akses yang diminta selain cakupan openid.
    userClaim Wajib Nama klaim di Token ID OIDC yang menyimpan nama pengguna. Misalnya, jika klaim pengguna adalah email, maka pengguna diidentifikasi oleh kolom pengguna dalam token OIDC.
    Jika tidak ada di Token ID, autentikasi akan gagal.
    userPrefix Opsional Awalan yang akan ditambahkan ke klaim pengguna untuk mencegah bentrokan dengan nama pengguna yang ada, biasanya digunakan saat mengonfigurasi beberapa penyedia identitas.
    Misalnya, jika klaim pengguna adalah email, dan awalan pengguna adalah prefix-, maka pengguna diidentifikasi sebagai prefix-sally@example.com. Pengguna adalah sally@example.com dan awalan, prefix-, ditambahkan pada pengguna untuk membedakan penyedia identitas yang berbeda.
    Sebaiknya sisipkan pemisah di akhir awalan seperti yang dijelaskan sebelumnya dalam tabel ini untuk menetapkan groupPrefix.

  3. Opsional: Jika penyedia identitas Anda menggunakan atribut kustom, konfigurasikan atribut di IdP Anda terlebih dahulu. Kemudian, tambahkan pasangan nilai kunci yang sesuai di bagian oidc file identity-provider-config.yaml untuk klaim tambahan tentang pengguna atau grup, seperti departemen atau tanggal lahir mereka. Saat Anda menerapkan perubahan pada konfigurasi penyedia identitas, GKE Identity Service akan mengenali atribut kustom. Berikut adalah contoh atribut kustom:

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

  4. Konfigurasi konfigurasi penyedia identitas:

    kubectl apply -f identity-provider-config.yaml

  5. Tunggu hingga berbagai komponen sistem dikonfigurasi ulang.

  6. Verifikasi konfigurasi dengan membuka konsol UI Admin Platform di browser web. Pilih Log in with pa-idp-oidc dari halaman pengalihan. Jika Anda dialihkan ke instance IdP Akun PA dan dialihkan kembali ke halaman konsol UI Admin Platform setelah login dengan instance IdP Akun PA, konfigurasi berhasil. Jika tidak, periksa nilai di identity-provider-config.yaml dan terapkan kembali langkah sebelumnya.

Penyiapan dengan SAML

  1. Buat file identity-provider-config.yaml, dan isi dengan merujuk pada tiket pembuatan organisasi untuk nilai IdP Akun PA:

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

  2. Berikut deskripsi mendetail kolom-kolomnya:

    .
    Atribut Jenis atribut Deskripsi
    idpCertificateDataList Wajib Sertifikat IDP yang digunakan untuk memverifikasi respons SAML. Sertifikat ini harus dienkode dengan base64 standar, dan diformat PEM. Hanya maksimum dua sertifikat yang didukung untuk memfasilitasi rotasi sertifikat IdP.
    idpEntityID Wajib ID entitas SAML untuk penyedia SAML, yang ditentukan dalam format URI. Misalnya, https://www.idp.com/saml.
    idpSingleSignOnURI Wajib URI ke endpoint SSO penyedia SAML. Misalnya, `https://www.idp.com/saml/sso`.
    groupPrefix Opsional Awalan opsional yang akan ditambahkan ke setiap nama grup.
    userPrefix Opsional Awalan opsional yang akan ditambahkan ke nama pengguna.
    userAttribute Opsional Nama atribut dalam respons SAML yang menyimpan nama pengguna. Jika atribut ini tidak ada dalam respons SAML, autentikasi akan gagal.
    groupsAttribute Opsional Nama atribut dalam respons SAML yang menyimpan grup pengguna.

  3. Opsional: Jika penyedia identitas Anda menggunakan atribut kustom, konfigurasikan atribut di IdP Anda terlebih dahulu. Kemudian, tambahkan pasangan nilai kunci yang sesuai di bagian saml file identity-provider-config.yaml untuk klaim tambahan tentang pengguna atau grup, seperti departemen atau tanggal lahir mereka. Saat Anda menerapkan perubahan pada konfigurasi penyedia identitas, GKE Identity Service akan mengenali atribut kustom. Berikut adalah contoh atribut kustom:

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

  4. Konfigurasi patch konfigurasi penyedia identitas:

    kubectl apply -f identity-provider-config.yaml

  5. Tunggu hingga berbagai komponen sistem dikonfigurasi ulang.

  6. Verifikasi konfigurasi dengan membuka konsol UI Admin Platform di browser web. Pilih Log in with pa-idp-oidc dari halaman pengalihan. Jika Anda dialihkan ke instance IdP Akun PA dan dialihkan kembali ke halaman konsol UI Admin Platform setelah login dengan instance IdP Akun PA, konfigurasi berhasil. Jika tidak, periksa nilai di identity-provider-config.yaml dan terapkan kembali langkah sebelumnya.

Prefiks pengguna dan grup

Awalan pengguna dan grup harus ditetapkan untuk setiap IdP di Distributed Cloud guna menghindari konflik penamaan di antara akun dari IdP yang berbeda. Awalan digunakan dengan nama pengguna dan grup untuk menggabungkan nama subjek dalam binding peran di cluster. Misalnya, untuk pengguna dengan nama jack@example.com, dan awalan pengguna IdP adalah example-org-idp-, nama subjeknya di cluster adalah example-org-idp-jack@example.com.

Untuk menentukan nilai awalan:

  • Sertakan tingkat hierarki (root, organisasi, project).
  • Sertakan nama IdP (adfs, keycloak).
  • Sebaiknya tambahkan karakter pemisah seperti - sebagai akhiran karena tidak ada pemisah yang ditambahkan antara awalan dan nama pengguna.

Menetapkan administrator awal

Untuk memberikan akses awal PA ke organisasi, PA harus ditetapkan sebagai administrator untuk organisasi tersebut. Untuk menetapkan PA sebagai administrator awal, buat IAMRoleBinding di server API global:

kubectl apply -f --kubeconfig=GLOBAL_API_SERVER_KUBECONFIG - <<EOF
apiVersion: iam.global.gdc.goog/v1
kind: IAMRoleBinding
metadata:
  name: PA_INITIAL_ADMIN_EMAIL-binding
  namespace: platform
spec:
  roleRef:
    apiGroup: iam.global.gdc.goog
    kind: IAMRole
    name: organization-iam-admin
  subjects:
  - apiGroup: rbac.authorization.k8s.io
    kind: User
    name: PA_IDP_PREFIXPA_INITIAL_ADMIN_EMAIL
EOF

1.10 Membuat konektivitas jaringan untuk organisasi

Organisasi yang baru dibuat diisolasi dan tidak dapat diakses dari jaringan eksternal mana pun. Agar organisasi dapat beroperasi, Anda harus menghubungkannya ke satu atau beberapa jaringan eksternal menggunakan layanan Interconnect.

Proses ini melibatkan konfigurasi serangkaian resource kustom yang menentukan koneksi logis. Berikut adalah dua skenario umum untuk menyediakan konektivitas ke organisasi baru.

Skenario 1: Menghubungkan organisasi ke interkoneksi bersama yang ada

Jika Anda memiliki interkoneksi yang sudah ada untuk jaringan bersama, Anda hanya perlu memperbarui AttachmentGroup dan RoutePolicy untuk menyertakan organisasi baru.

  1. Perbarui AttachmentGroup: AttachmentGroup menentukan organisasi mana yang dapat menggunakan serangkaian lampiran VLAN. Edit file YAML AttachmentGroup dan tambahkan organisasi baru ke daftar spec.entities. Untuk organisasi v2, Anda harus menentukan jaringan domainType (OrgAdmin, OrgData, atau OrgMixed) yang akan dihubungkan.

    Contoh pembaruan 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. Perbarui RoutePolicy: RoutePolicy menentukan prefiks IP mana yang diiklankan. Edit kebijakan dan tambahkan subnet IP eksternal untuk organisasi baru ke spec.out.ipPrefixList. Hal ini memungkinkan traffic masuk menjangkau organisasi.

    Contoh pembaruan 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. Terapkan perubahan menggunakan kubectl apply dengan proses Infrastructure as Code (IaC).

Skenario 2: Membuat dedicated interconnect baru

Untuk koneksi khusus, Anda harus membuat serangkaian resource interkoneksi baru. Seluruh prosesnya melibatkan pembuatan lima resource kustom secara berurutan.

  1. Buat InterconnectLink untuk setiap koneksi fisik baru.
  2. Buat InterconnectGroup untuk menggabungkan link fisik dan mengizinkan organisasi baru.
  3. Buat AttachmentGroup dan tentukan organisasi baru dalam daftar entities.
  4. Buat RoutePolicy yang mengizinkan awalan IP masuk dan keluar untuk koneksi khusus ini.
  5. Buat satu atau beberapa resource InterconnectAttachment untuk menentukan VLAN dan sesi BGP.

Untuk contoh lengkap dan langkah-langkah mendetail untuk setiap resource ini, lihat dokumentasi Mengonfigurasi interkoneksi.

1.11 Menyiapkan webhook Alertmanager untuk terhubung ke ServiceNow

Ikuti langkah-langkah di MON-T0016 untuk menghubungkan webhook alertmanager ke ServiceNow untuk pembuatan insiden.

1.12 Mengonfigurasi lembar harga Penagihan untuk organisasi

Subkomponen Penagihan untuk organisasi mengharuskan produk atau layanan yang akan ditagih dikonfigurasi dengan resource kustom SKUDescription. Satu SKUDescription menjelaskan satu produk atau layanan yang akan ditagih beserta harganya. Kumpulan objek SKUDescription dapat dianggap sebagai daftar harga untuk organisasi. Langkah-langkah berikut mengonfigurasi lembar harga untuk organisasi di IAC.

1.12.1 Mendapatkan lembar harga

Jika Anda belum memiliki resource lembar harga SKUDescription untuk organisasi, hubungi Program Management Office (PMO) untuk mendapatkan lembar harga. Lembar harga harus berupa serangkaian file YAML yang berisi SKUDescription resource.

1.12.2 Menentukan apakah lembar harga dibagikan atau tidak

Lembar harga dapat dibagikan di semua organisasi atau dikonfigurasi berdasarkan per organisasi. PMO dapat memberi tahu Anda apakah spreadsheet harga dibagikan atau tidak.

1.12.2.1 Lembar harga bersama

Jika lembar harga dibagikan, tempatkan lembar harga di folder IAC bersama.common-data

  1. Jika organisasi ini bukan organisasi pertama yang dibuat, lembar harga mungkin sudah ada di folder common-data bersama. Jika lembar harga ada, pastikan langkah 2-4 telah diikuti dan lanjutkan ke langkah 5.

  2. Buat folder bersama untuk lembar harga.

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

    Ganti IAC_REPO_PATH dengan jalur ke repositori IAC.

  3. Simpan resource YAML lembar harga SKUDescription ke dalam folder ini. Setelah itu, folder skudescriptions harus berisi file YAML yang dipisahkan berdasarkan area. Konfigurasi struktur folder dan file YAML agar sesuai dengan kasus penggunaan penagihan Anda:

    • Penagihan yang dioperasikan partner: Google menagih partner. Tempatkan resource SKUDescription di namespace partner-billing-system.

    • Penagihan pelanggan: Partner menagih pengguna akhir. Tempatkan resource SKUDescription di namespace billing-system.

    Contoh berikut menunjukkan struktur file model penagihan pelanggan dan penagihan yang dioperasikan partner. Untuk setiap model, Anda akan melihat dua layanan, komputasi dan penyimpanan, dengan dua file YAML untuk setiap layanan:

    Penagihan pelanggan:

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

    Penagihan yang dioperasikan partner:

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

  4. Pastikan ada file kustomization.yaml di direktori yang menyertakan semua file YAML lembar harga SKUDescription.

    touch IAC_REPO_PATH/iac/infrastructure/common-data/bil/skudescriptions/kustomization.yaml
cd IAC_REPO_PATH/iac/infrastructure/common-data/bil/skudescriptions/
kustomize edit add resource */*.yaml

  5. Ekspor variabel lingkungan ORG_CLUSTER:

    • Untuk organisasi v1, jalankan:

      export ORG_CLUSTER=ORG_ADMIN_CLUSTER_NAME

    • Untuk organisasi v2, jalankan:

      export ORG_CLUSTER=ORG_INFRA_CLUSTER_NAME

  6. Buat direktori penagihan skudescriptions di organisasi:

    • Untuk organisasi v1:

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

    • Untuk organisasi v2:

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

    Ganti ORG_CLUSTER_NAME dengan nama cluster admin organisasi, bergantung pada jenis versi organisasi Anda.

  7. Sertakan lembar harga umum dalam organisasi:

    • Untuk organisasi v1:

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

    • Untuk organisasi v2:

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

  8. Siapkan dan lakukan commit pada file YAML, lalu sesuaikan file:

    cd IAC_REPO_PATH
git add "iac"
git commit

  9. Kirim update ke GitLab:

    git -c http.sslVerify=false push

  10. Tunggu peninjauan dan penggabungan kode.

  11. Pastikan objek SKUDescription ada di cluster tertentu untuk model penagihan yang sesuai.

    Ekspor nilai KUBECONFIG sesuai dengan jenis organisasi.

    • Untuk organisasi v1, jalankan:

      export KUBECONFIG=ORG_ADMIN_CLUSTER_KUBECONFIG

      Ganti ORG_ADMIN_CLUSTER_KUBECONFIG dengan jalur ke kubeconfig cluster admin org, seperti /tmp/${ORG}-admin-kubeconfig.

    • Untuk organisasi v2, jalankan:

      export KUBECONFIG=MANAGEMENT_API_SERVER_KUBECONFIG

      Ganti MANAGEMENT_API_SERVER_KUBECONFIG dengan jalur ke kubeconfig server Management API, seperti /tmp/${ORG}-management-kubeconfig.

    Jalankan kubectl CLI:

    Untuk penagihan pelanggan:

    
kubectl get SKUDescription -n billing-system

    Untuk penagihan partner:

    
kubectl get SKUDescription -n partner-billing-system

1.12.2.2 Lembar harga khusus organisasi

Jika lembar harga khusus untuk organisasi, Anda harus menempatkan lembar harga di folder cluster organisasi.

  1. Buat direktori penagihan skudescriptions di cluster organisasi:

    • Untuk organisasi v1:

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

    • Untuk organisasi v2:

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

  2. Simpan resource YAML lembar harga SKUDescription ke dalam folder ini. Setelah itu, folder skudescriptions harus memiliki file YAML yang dipisahkan berdasarkan area. Dalam contoh berikut, Anda melihat dua layanan, komputasi dan penyimpanan, dengan masing-masing dua file YAML:

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

  3. Pastikan ada file kustomization.yaml di direktori yang mencakup semua file YAML lembar harga SKUDescription.

    • Untuk organisasi v1:

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

    • Untuk organisasi v2:

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

  4. Pastikan file kustomization.yaml di root organisasi memiliki folder bil/skudescriptions yang baru ditambahkan. Periksa IAC_REPO_PATH/iac/infrastructure/zonal/zones/ZONE_NAME/ORG_CLUSTER_NAME/kustomization.yaml untuk organisasi v1 dan IAC_REPO_PATH/iac/infrastructure/zonal/zones/ZONE_NAME/ORG_CLUSTER_NAME-management/kustomization.yaml untuk organisasi v2 :

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

  5. Siapkan dan lakukan commit pada file YAML dan file kustomize:

    cd IAC_REPO_PATH
git add "iac"
git commit

  6. Kirim update ke GitLab:

    git -c http.sslVerify=false push

  7. Tunggu peninjauan dan penggabungan kode.

  8. Verifikasi bahwa objek SKUDescription ada di cluster yang diberikan:

    • Untuk organisasi v1, jalankan:

      export KUBECONFIG=ORG_ADMIN_CLUSTER_KUBECONFIG

kubectl get SKUDescription -n billing-system

      Ganti ORG_ADMIN_CLUSTER_KUBECONFIG dengan jalur ke kubeconfig cluster admin org, seperti /tmp/${ORG}-admin-kubeconfig.

    • Untuk organisasi v2, jalankan:

      export KUBECONFIG=MANAGEMENT_API_SERVER_KUBECONFIG

kubectl get SKUDescription -n billing-system

      Ganti MANAGEMENT_API_SERVER_KUBECONFIG dengan jalur ke kubeconfig server Management API, seperti /tmp/${ORG}-management-kubeconfig. .

1.13 Membuat penggunaan berulang Penagihan

Distributed Cloud menawarkan unit penyimpanan persediaan (SKU) yang menimbulkan biaya berulang. Namun, Distributed Cloud tidak melacak biaya penggunaan Anda untuk SKU tertentu. Untuk mengelola informasi tersebut, gunakan resource RecurringUsage. Untuk mengetahui detail dan petunjuk tentang cara membuat penggunaan berulang, lihat Membuat penggunaan berulang.

1.14 Mengonfigurasi Penagihan untuk organisasi

Subkomponen penagihan tidak mulai menghitung biaya untuk organisasi hingga waktu mulai penagihan tercapai. Waktu mulai penagihan memiliki nilai default 9999-01-01T00:00:00-07:00. Oleh karena itu, setelah organisasi dianggap siap, IO akan menggantikan waktu mulai penagihan untuk memulai alur kerja penagihan.

1.14.1 Mendapatkan waktu mulai penagihan

Waktu mulai penagihan harus berada di awal periode pelaksanaan, yang tersedia dalam kontrak Anda. Jika Anda belum memiliki waktu mulai penagihan untuk organisasi, hubungi Program Management Office (PMO) untuk mendapatkan informasi tersebut.

1.14.2 Memetakan akun pembayaran penagihan ke organisasi

Lingkungan air-gapped Google Distributed Cloud (GDC) memerlukan akun penagihan untuk melacak biaya project dan organisasi. Jika Anda tidak menautkan akun penagihan ke organisasi atau project, Anda akan kehilangan data biaya yang terkait dengan resource.

Untuk menagih penggunaan layanan kepada pelanggan, semua akun penagihan dalam organisasi menggunakan satu lembar harga.

1.14.2.1 Sebelum memulai

Sebelum melanjutkan, minta Admin Keamanan Anda untuk memberi Anda peran yang diperlukan berikut. Peran ini terikat ke namespace project untuk penagihan tingkat project, atau namespace platform untuk penagihan tingkat organisasi:

  • Administrator Akun Penagihan Organisasi: membuat, mengelola, dan mengikat resource BillingAccount. Minta Admin Keamanan Anda untuk memberi Anda peran organization-billing-account-admin.

  • Pengguna Akun Penagihan Organisasi: membaca, mencantumkan, dan mengikat BillingAccount resource. Minta Admin Keamanan Anda untuk memberi Anda peran organization-billing-account-user.

  • Pengelola Akun Penagihan Organisasi: membaca, mencantumkan, membuat, dan memperbarui resource BillingAccountBinding. Minta Admin Keamanan Anda untuk memberi Anda peran organization-billing-manager.

1.14.2.2 Membuat akun penagihan baru

Akun penagihan diidentifikasi secara unik oleh name dan namespace-nya. Untuk membuat akun penagihan, gunakan resource kustom untuk membuat name dan namespace:

  1. Buat file YAML, lalu tambahkan resource kustom BillingAccount dan konten berikut:

    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"

    Ganti variabel berikut:

    • BIL_ACCOUNT_NAME: nama akun penagihan. Contoh. test-billing-account.
    • BIL_DISPLAY_NAME: nama tampilan akun penagihan. Contoh. "Test Billing Account".

  2. Verifikasi jenis konfigurasi pembayaran Anda. Akun penagihan Distributed Cloud harus memiliki salah satu konfigurasi pembayaran berikut:

    • cloudBillingConfig: konfigurasi pembayaran default. Konfigurasi ini menyimpan ID akun Penagihan Cloud.

    • customConfig: konfigurasi kustom bagi partner untuk menyimpan konfigurasi pembayaran mereka guna menagih organisasi. customConfig mendukung kamus string key-value, dengan kunci wajib payment-config-type.

    Contoh berikut menunjukkan cuplikan file YAML BillingAccount untuk berbagai konfigurasi pembayaran:

    cloudBillingConfig

    spec:
  paymentSystemConfig:
    cloudBillingConfig:
      accountID: CLOUD_BILLING_ACCOUNT_ID

    Ganti CLOUD_BILLING_ACCOUNT_ID dengan Google Cloud ID akun penagihan Anda.

    customConfig

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

    Ganti PAYMENT_CONFIG_TYPE dengan jenis konfigurasi pembayaran yang Anda pilih untuk konfigurasi penagihan kustom.

    Jika Anda tidak memiliki informasi untuk konfigurasi customConfig organisasi Anda, masukkan detail berikut:

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

    File YAML berikut menampilkan resource BillingAccount lengkap dengan konfigurasi cloudBillingConfig:

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

  3. Simpan file YAML resource kustom. Jalankan kubectl CLI untuk menerapkan resource di cluster organisasi untuk organisasi atau project tertentu yang ingin Anda tagih:

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

Untuk menautkan organisasi ke BillingAccount, lakukan langkah-langkah berikut:

  1. Tambahkan konten berikut ke file YAML billingaccountbinding.yaml:

    • Di bagian billingAccountRef, isi kolom name dengan konten dari kolom name di BillingAccount yang ingin Anda tautkan.
    • Di bagian metadata, isi kolom namespace dengan konten dari kolom yang identik di resource BillingAccount. Dalam contoh ini, namespace organisasi adalah platform:
    apiVersion: billing.gdc.goog/v1
kind: BillingAccountBinding
metadata:
  name: billing
  namespace: platform
spec:
  billingAccountRef:
    name: BIL_ACCOUNT_NAME
    namespace: platform

  2. Terapkan file billingaccountbinding.yaml:

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

1.14.3 Sebelum memulai

Sebelum melanjutkan, minta Admin Keamanan Anda untuk memberi Anda peran Bil Monitor (bil-monitor) di cluster admin org untuk namespace billing-system. Izin ini memungkinkan Anda membaca resource terkait untuk validasi.

1.14.4 Mengganti waktu mulai penagihan

  1. Buat dua file YAML dengan jalur berikut:

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

      • Buat subdirektori yang diperlukan untuk setiap file jika tidak ada.

  2. Tambahkan resource SubcomponentOverride dan konten berikut ke setiap file:

    Untuk penagihan pelanggan:

    • File bil-monetizer-override.yaml:

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

    • File bil-invoice-override.yaml:

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

    Untuk penagihan yang dioperasikan partner:

    • Tambahkan tanda enablePartnerBilling: true di akhir setiap file YAML:

    • File bil-monetizer-override.yaml:

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

    • File bil-invoice-override.yaml:

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

    Ganti variabel berikut:

    • ORG_NAME: nama organisasi. Contoh: org-1.

    • BILLING_START_TIME: stempel waktu untuk memulai alur kerja penagihan.Stempel waktu harus mengikuti format RFC 3339. Misalnya, jika alur kerja penagihan dimulai pada 01/01/2024 dengan zona waktu Waktu Standar Pasifik AS dan Kanada (UTC-8), tambahkan nilai stempel waktu sebagai 2024-01-01T00:00:00-08:00.

    • BILLING_TIMEZONE: zona waktu alur kerja penagihan. Zona waktu harus mengikuti format RFC 3339. Misalnya, jika zona waktu penagihan adalah Waktu Standar Pasifik AS dan Kanada (UTC-8), tambahkan nilai zona waktu sebagai PST8PDT.

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

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

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

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

  3. Simpan dan simpan file YAML di folder infrastructure/zonal/zones/ZONE_NAME/root-admin/components/bil/ORG_NAME.

  4. Buat pull request yang berisi file YAML beserta file kustomisasi yang diperlukan.

1.14.5 Validasi waktu mulai penagihan

Pastikan Anda telah mengganti waktu mulai penagihan untuk monetizer serta pembuatan invoice:

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 Mengonfigurasi kebijakan jaringan proxy penyimpanan objek di cluster admin organisasi

1.15.1 Buat file YAML kebijakan jaringan

Buat file YAML kebijakan jaringan allow-obs-system-ingress-traffic, seperti 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 Terapkan kebijakan jaringan ke cluster admin organisasi

kubectl --kubeconfig ORG_ADMIN_KUBECONFIG apply -f networkpolicy.yaml

1.16. Membuat situs cadangan

Jika Anda memanfaatkan dukungan pemulihan dari bencana, Anda harus menyelesaikan langkah-langkah sebelumnya lagi untuk situs cadangan. Jika Anda tidak mengaktifkan pemulihan bencana, lewati bagian ini.

  1. Ikuti bagian 1.4. - 1.9. untuk membuat organisasi lain bagi situs cadangan.

1.17. Memecahkan masalah pembuatan organisasi

1.17.1. Pastikan semua resource yang di-deploy dalam kondisi baik dan ada

Proses pembuatan organisasi membuat beberapa resource di berbagai cluster Kubernetes. Pertama, periksa resource yang di-deploy dan pastikan resource tersebut dalam kondisi baik. Bagian berikut menguraikan resource yang dibuat untuk organisasi bernama operations.

1.17.2. Konfirmasi semua resource yang di-deploy di cluster admin root

Selesaikan langkah-langkah berikut untuk mengonfirmasi bahwa semua resource di cluster admin root dalam kondisi baik dan ada:

  1. Dapatkan konfigurasi kubeconfig yang diperlukan untuk cluster admin root dengan mengikuti IAM-R0004. Pastikan untuk menetapkan variabel lingkungan dan alias berikut untuk petunjuk verifikasi ini:

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

  2. Pastikan resource firewall tersedia:

    1. Buat koneksi SSH ke firewall dan pastikan ada vsys baru yang dibuat:

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

      Outputnya mirip dengan hal berikut ini:

      vsys1 {
vsys2 {

    2. Periksa resource FirewallVirtualSystem:

      k get firewallvirtualsystem -n gpc-system

      Outputnya mirip dengan hal berikut ini:

      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. Pastikan resource penyimpanan tersedia:

    1. Periksa resource StorageVirtualMachine:

      k get StorageVirtualMachine -n gpc-system

      Outputnya mirip dengan hal berikut ini:

      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. Konfirmasi bahwa resource HSM tersedia:

    1. Periksa HSM:

      k get hsms -n gpc-system

      Outputnya mirip dengan hal berikut ini:

      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. Periksa cluster HSM:

      k get hsmcluster -n gpc-system

      Outputnya mirip dengan hal berikut ini:

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

    3. Periksa tenant HSM:

      k get hsmtenant -A

      Outputnya mirip dengan hal berikut ini:

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

  5. Konfirmasi bahwa resource mesin dan node tersedia:

    1. Periksa resource AddressPoolClaim:

      k get addresspoolclaims -A

      Outputnya mirip dengan hal berikut ini:

      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. Periksa resource NodePoolClaim:

      k get nodepoolclaims -A

      Outputnya mirip dengan hal berikut ini:

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

    3. Periksa resource NodePool:

      k get nodepool -A

      Outputnya mirip dengan hal berikut ini:

      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. Periksa cluster bare metal:

      k get baremetalclusters -A

      Outputnya mirip dengan hal berikut ini:

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

    5. Periksa mesin bare metal:

      k get baremetalmachines -A

      Outputnya mirip dengan hal berikut ini:

      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. Periksa server. Mereka berada dalam status provisioned:

      k get servers -n gpc-system | grep provisioned

      Outputnya mirip dengan hal berikut ini:

      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. Periksa cluster Kubernetes:

      k get cluster -A

      Outputnya mirip dengan hal berikut ini:

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

    8. Periksa secret untuk kubeconfig:

      k get secrets -A | grep kubeconfig

      Outputnya mirip dengan hal berikut ini:

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

1.17.3. Mengonfirmasi semua resource yang di-deploy di cluster organisasi v1

Selesaikan langkah-langkah berikut untuk mengonfirmasi bahwa semua resource di cluster admin org dan cluster sistem dalam organisasi v1 berfungsi dengan baik dan ada. Jika Anda memiliki organisasi v2, lanjutkan ke bagian berikutnya.

1.17.3.1. Mengonfirmasi semua resource yang di-deploy di cluster admin org

  1. Dapatkan konfigurasi kubeconfig yang diperlukan untuk cluster admin root dengan mengikuti IAM-R0004. Pastikan untuk menetapkan variabel lingkungan dan alias berikut untuk petunjuk verifikasi ini:

    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. Konfirmasi bahwa resource mesin dan node tersedia:

    1. Periksa cluster bare metal:

      ka get baremetalclusters -A

      Outputnya mirip dengan hal berikut ini:

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

    2. Periksa mesin bare metal:

      ka get baremetalmachines -A

      Outputnya mirip dengan hal berikut ini:

      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. Periksa mesin:

      ka get machines -A

      Outputnya mirip dengan hal berikut ini:

      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. Periksa resource VirtualmachinesInstance:

      ka get virtualmachineinstances -A

      Outputnya mirip dengan hal berikut ini:

      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. Periksa resource NodePool:

      ka get nodepools -A

      Outputnya mirip dengan hal berikut ini:

      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. Periksa cluster Kubernetes:

      ka get clusters -A

      Outputnya mirip dengan hal berikut ini:

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

    7. Periksa node:

      ka get nodes -A

      Outputnya mirip dengan hal berikut ini:

      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. Periksa secret untuk kubeconfig:

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

      Outputnya mirip dengan hal berikut ini:

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

1.17.3.2. Konfirmasi semua resource yang di-deploy di cluster pengguna sistem

Selesaikan langkah-langkah berikut untuk mengonfirmasi bahwa semua resource di cluster sistem dalam kondisi baik dan ada:

  1. Dapatkan konfigurasi kubeconfig yang diperlukan untuk cluster admin root dengan mengikuti IAM-R0004. Pastikan untuk menetapkan variabel lingkungan dan alias berikut untuk petunjuk verifikasi ini:

    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. Konfirmasi bahwa resource mesin dan node tersedia:

    1. Periksa resource VirtualmachineInstance:

      ku get vmi -A

      Outputnya mirip dengan berikut ini (jika cluster pengguna telah dibuat):

      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. Periksa node:

      ku get nodes

      Outputnya mirip dengan hal berikut ini:

      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. Periksa alokasi GPU:

      ku get gpuallocations -A

      Outputnya mirip dengan hal berikut ini:

      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. Mengonfirmasi semua resource yang di-deploy di cluster organisasi v2

Selesaikan langkah-langkah berikut untuk mengonfirmasi bahwa semua resource di cluster infrastruktur org dalam organisasi v2 berfungsi dengan baik dan ada. Jika Anda memiliki organisasi v1, lewati bagian ini.

  1. Dapatkan konfigurasi kubeconfig yang diperlukan untuk cluster admin root dengan mengikuti IAM-R0004. Pastikan untuk menetapkan variabel lingkungan dan alias berikut untuk petunjuk verifikasi ini:

    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. Konfirmasi bahwa node dan server API responsif:

    1. Periksa node:

      ka get nodes -A

      Outputnya mirip dengan hal berikut ini:

      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. Periksa secret untuk kubeconfig:

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

      Outputnya mirip dengan hal berikut ini:

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

  3. Periksa alokasi GPU untuk mengonfirmasi bahwa resource GPU sudah siap, jika berlaku:

    ka get gpuallocations -A

    Outputnya mirip dengan hal berikut ini:

    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. Pastikan semua resource Organisasi telah disesuaikan

Selesaikan langkah-langkah berikut untuk mengonfirmasi bahwa semua resource terkait organisasi di cluster admin root global dan per zona dalam kondisi baik dan ada, dengan asumsi targetnya adalah membuat organisasi operations dengan dua zona: zone-1 dan zone-2.

  1. Ikuti Mengakses API admin root global untuk mengakses server API global dan gunakan alias berikut untuk kubectl API admin root global.

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

  2. Pastikan resource organisasi global tersedia:

    1. Periksa resource Organization global:

      kga get organization -A

      Outputnya mirip dengan hal berikut ini:

      NAMESPACE    NAME         READY
gpc-system   operations
gpc-system   root

    2. Periksa resource OrganizationReplica global:

      kga get organizationreplica -A

      Outputnya mirip dengan hal berikut ini:

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

    3. Periksa resource OrganizationZonalConfig global:

      kga get organizationzonalconfig -A

      Outputnya mirip dengan hal berikut ini:

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

    4. Periksa resource OrganizationZonalConfigReplica global:

      kga get organizationzonalconfigreplica -A

      Outputnya mirip dengan hal berikut ini:

      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. Tetapkan alias konfigurasi kubeconfig cluster admin root zonal:

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

  4. Pastikan resource organisasi zonal tersedia:

    1. Periksa resource Organization:

      ka get organization -A

      Outputnya mirip dengan hal berikut ini:

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

    2. Periksa resource OrganizationReplica:

      ka get organizationreplica -A

      Outputnya mirip dengan hal berikut ini:

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

    3. Periksa resource OrganizationZonalConfigReplica:

      ka get organizationzonalconfigreplica -A

      Outputnya mirip dengan hal berikut ini:

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

  5. Ikuti Mengizinkan alamat apa pun untuk mengakses organisasi untuk mengizinkan traffic DCI di cluster admin org dari situs sumber ke situs cadangan.