Preconfigurare CIDR per le nuove organizzazioni di zona

In un universo air-gap di Google Distributed Cloud (GDC), puoi creare organizzazioni v1 o v2 che si estendono su più zone. Tuttavia, esistono due scenari di creazione dell'organizzazione che richiedono configurazioni CIDR aggiuntive prima della creazione dell'organizzazione:

Le sezioni seguenti trattano questi scenari e i prerequisiti che devi completare prima di creare l'organizzazione.

Configura le impostazioni CIDR per l'organizzazione v1 nella nuova zona

Per impostazione predefinita, non puoi eseguire il provisioning di un'organizzazione v1 in una nuova zona, poiché molti CIDR richiesti dall'organizzazione v1 sono già assegnati all'organizzazione radice.

Devi anche utilizzare la funzionalità esistente per gli indirizzi IP personalizzati per l'organizzazione v1.

Impostazioni CIDR del piano

Raccogli le impostazioni CIDR esistenti configurate nella tua zona per evitare sovrapposizioni CIDR nella nuova organizzazione v1.

  1. Stampa la risorsa zone-infra-cidr CIDRClaim esistente:

    kubectl --kubeconfig=ROOT_ADMIN_KUBECONFIG get cidrclaim \
        -n gpc-system zone-infra-cidr
    
  2. Controlla i campi status.ipv4AllocationStatus.cidrBlocks e status.ipv6AllocationStatus.cidrBlocks della risorsa CIDRClaim nell'output.

    Ad esempio, la seguente risorsa CIDRClaim ha riservato i blocchi CIDR 192.0.2.0/21, 198.51.100.0/26, 203.0.113.0/23 e 2001:db8::/66:

    apiVersion: system.private.gdc.goog/v1alpha1
    kind: CIDRClaim
    metadata:
      name: zone-infra-cidr
      namespace: gpc-system
    spec:
      ipv4Spec:
        staticCidrBlocks:
        - 192.0.2.0/21
        - 198.51.100.0/26
        - 203.0.113.0/23
      ipv6Spec:
        staticCidrBlocks:
        - 2001:db8::/66
    status:
      ipv4AllocationStatus:
        cidrBlocks:
        - 192.0.2.0/21
        - 198.51.100.0/26
        - 203.0.113.0/23
      ipv6AllocationStatus:
        cidrBlocks:
        - 2001:db8::/66
    

    Prendi nota di questi blocchi CIDR per evitare di utilizzarli quando crei i CIDR esterni personalizzati e i CIDR interni personalizzati per la tua organizzazione.

  3. Controlla zone-infra-cidr di ogni zona e annota i blocchi CIDR esistenti che non vengono utilizzati per evitare di utilizzarli quando crei il CIDR personalizzato per la tua organizzazione. Per cambiare i contesti di zona, utilizza gcloud CLI.

  4. Stampa tutte le subnet esistenti con l'etichetta network-root-range:

    kubectl --kubeconfig=GLOBAL_ROOT_ADMIN_KUBECONFIG get subnet \
        -l ipam.gdc.goog/usage=network-root-range -A
    
  5. Controlla i campi status.ipv4Allocation.cidr e status.ipv6Allocation.cidr per ogni risorsa Subnet.

    Ad esempio, il seguente infra-vpc-root-cidr ha riservato il CIDR 192.0.2.0/15:

    apiVersion: ipam.global.gdc.goog/v1
    kind: Subnet
    metadata:
      labels:
        ipam.gdc.goog/usage: network-root-range
        ipam.gdc.goog/vpc: infra-vpc
      name: infra-vpc-root-cidr
      namespace: org-1
    spec:
      ipv4Request:
        cidr: 192.0.2.0/15
      propagationStrategy: None
      type: Root
    status:
        ipv4Allocation:
        cidr: 192.0.2.0/15
    

    Prendi nota di questi CIDR per evitare di utilizzarli quando crei il CIDR esterno personalizzato e il CIDR interno personalizzato per la tua organizzazione.

Configura un indirizzo IP personalizzato

Nell'ambito della procedura di bootstrapping dell'organizzazione v1, i CIDR esterni personalizzati e interni personalizzati sono necessari come input per la risorsa personalizzata globale OrganizationZonalConfig per supportare il bootstrap dell'organizzazione v1 globale.

Nella specifica della risorsa OrganizationZonalConfig, devi aggiungere le configurazioni personalizzate dell'indirizzo IP per il CIDR esterno e il CIDR interno. I CIDR esterni personalizzati e interni personalizzati vengono istanziati rispettivamente nelle rivendicazioni CIDR org-namespace/org-custom-external-cidr e org-namespace/org-custom-internal-cidr per l'organizzazione zonale. Tutti gli altri CIDR e subnet di questa organizzazione sono elementi secondari di questi due CIDR:

...

spec:
  capacities:
    customIPConfig:
      externalCIDRs:
      - CUSTOM_EXTERNAL_CIDR
      internalCIDRs:
      - CUSTOM_INTERNAL_CIDR

...

Per il CIDR esterno personalizzato e il CIDR interno personalizzato devono essere soddisfatte le seguenti condizioni:

  • Univoco nella risorsa OrganizationZonalConfig per ogni zona.
  • Unico nella risorsa OrganizationZonalConfig per ogni organizzazione v1 esistente in tutte le zone.
  • Non può sovrapporsi a zone-infra-cidr per ogni zona.
  • Non può sovrapporsi ad alcuna subnet globale con l'etichetta ipam.gdc.goog/usage=network-root-range.

Una volta soddisfatti questi requisiti, puoi continuare i passaggi di bootstrap dell'organizzazione predefinita per eseguire il bootstrap dell'organizzazione v1 nella nuova zona.

Configurare le impostazioni CIDR per l'organizzazione v2 nella zona esistente

Per eseguire il provisioning di un'organizzazione v2 in una zona esistente, devi creare manualmente la risorsa CIDRClaim gpc-system/zone-infra-cidr. Devi inoltre assicurarti che il blocco CIDR all'interno della nuova richiesta CIDR non si sovrapponga a quanto segue:

  • Le rivendicazioni CIDR gpc-system/instance- nella zona.

  • Qualsiasi rivendicazione CIDR gpc-system/zone-infra-cidr o gpc-system/instance- in altre zone dell'universo.

Impostazioni CIDR del piano

  1. Stampa le risorse CIDRClaim esistenti:

    kubectl --kubeconfig=ROOT_ADMIN_KUBECONFIG get cidrclaim -n gpc-system
    
  2. Controlla i campi status.ipv4AllocationStatus.cidrBlocks e status.ipv6AllocationStatus.cidrBlocks per ogni risorsa CIDRClaim dell'output.

    Ad esempio, la seguente risorsa CIDRClaim ha riservato i blocchi CIDR 192.0.2.0/21, 198.51.100.0/26, 203.0.113.0/23 e 2001:db8::/66:

    apiVersion: system.private.gdc.goog/v1alpha1
    kind: CIDRClaim
    metadata:
      name: instance-external-cidr
      namespace: gpc-system
    spec:
      ipv4Spec:
        staticCidrBlocks:
        - 192.0.2.0/21
        - 198.51.100.0/26
        - 203.0.113.0/23
      ipv6Spec:
        staticCidrBlocks:
        - 2001:db8::/66
    status:
      ipv4AllocationStatus:
        cidrBlocks:
        - 192.0.2.0/21
        - 198.51.100.0/26
        - 203.0.113.0/23
      ipv6AllocationStatus:
        cidrBlocks:
        - 2001:db8::/66
    

    Prendi nota di questi blocchi CIDR per evitare di utilizzarli quando crei il zone-infra-cidr per la tua organizzazione v2.

Crea la rivendicazione CIDR zone-infra-cidr

  1. Trova e annota le seguenti rivendicazioni CIDR con lo spazio dei nomi gpc-system in ogni zona del tuo universo:

    • instance-external-cidr
    • instance-internal-pod-network-cidr
    • instance-internal-cluster-ip-cidr
    • instance-internal-physical-network-cidr
    • instance-internal-cidr
    • zone-infra-cidr

    Ad esempio, il seguente comando restituisce le rivendicazioni CIDR instance-external-cidr per la zona corrente:

    kubectl --kubeconfig=ROOT_ADMIN_KUBECONFIG get cidrclaim -n gpc-system instance-external-cidr
    

    Per cambiare i contesti di zona, utilizza gcloud CLI.

  2. Crea una risorsa CIDRClaim denominata zone-infra-cidr che non si sovrapponga alle rivendicazioni CIDR controllate in precedenza:

    kubectl --kubeconfig=ROOT_ADMIN_KUBECONFIG apply -f - <<EOF
    apiVersion: system.private.gdc.goog/v1alpha1
    kind: CIDRClaim
    metadata:
      name: zone-infra-cidr
      namespace: gpc-system
    spec:
      ipv4Spec:
        staticCidrBlocks:
        - IPV4_CIDR
      ipv6Spec:
        staticCidrBlocks:
        - IPV6_CIDR
    EOF
    

    I CIDR IPv4 e IPv6 devono essere univoci e non possono sovrapporsi a rivendicazioni CIDR instance- esistenti nello spazio dei nomi gpc-system nella zona corrente o in qualsiasi altra zona esistente.

  3. Controlla lo stato di zone-infra-cidr per assicurarti che sia pronto:

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

    Una volta che la rivendicazione CIDR è Ready, puoi continuare i passaggi di bootstrap dell'organizzazione predefinita per eseguire il bootstrap dell'organizzazione v2 nella nuova zona.