Pré-configure o CIDR para novas organizações zonais

Num universo isolado do Google Distributed Cloud (GDC), pode criar organizações v1 ou v2 que abrangem várias zonas. No entanto, existem dois cenários de criação de organizações que requerem configurações de CIDR adicionais antes da criação da organização:

As secções seguintes abordam estes cenários e os pré-requisitos que tem de concluir antes de criar a organização.

Configure as definições de CIDR para a organização v1 na nova zona

Por predefinição, não pode aprovisionar uma organização v1 numa nova zona, uma vez que muitas reivindicações CIDR necessárias para a organização v1 já estão atribuídas à organização raiz.

Também tem de usar a funcionalidade de endereço IP personalizado existente para a organização da v1.

Planeie as definições de CIDR

Reúna as definições de CIDR existentes configuradas na sua zona para poder evitar a sobreposição de CIDR na sua nova organização v1.

  1. Imprima o recurso zone-infra-cidr CIDRClaim existente:

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

  2. Verifique os campos status.ipv4AllocationStatus.cidrBlocks e status.ipv6AllocationStatus.cidrBlocks do recurso CIDRClaim no resultado.

    Por exemplo, o recurso CIDRClaim seguinte reservou os blocos 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

    Tome nota destes blocos CIDR para poder evitar usá-los quando criar o CIDR externo personalizado e o CIDR interno personalizado para a sua organização.

  3. Verifique o zone-infra-cidr de cada zona e repare que os blocos CIDR existentes não são usados para que possa evitar usá-los quando criar o CIDR personalizado para a sua organização. Para mudar os contextos zonais, use a CLI gdcloud.

  4. Imprima todas as sub-redes existentes com a etiqueta network-root-range:

    kubectl --kubeconfig=GLOBAL_ROOT_ADMIN_KUBECONFIG get subnet \
    -l ipam.gdc.goog/usage=network-root-range -A

  5. Verifique os campos status.ipv4Allocation.cidr e status.ipv6Allocation.cidr para cada recurso Subnet.

    Por exemplo, o seguinte infra-vpc-root-cidr reservou o 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

    Tome nota destes CIDRs para poder evitar usá-los quando criar o CIDR externo personalizado e o CIDR interno personalizado para a sua organização.

Configure um endereço IP personalizado

Como parte do processo de arranque da organização v1, são necessários CIDRs externos personalizados e CIDRs internos personalizados como entrada para o recurso personalizado global para suportar o arranque global da organização v1.OrganizationZonalConfig

Na especificação do recurso OrganizationZonalConfig, tem de adicionar as configurações de endereço IP personalizadas para o CIDR externo e o CIDR interno. Os CIDRs externos personalizados e internos personalizados são instanciados nas reivindicações de CIDR org-namespace/org-custom-external-cidr e org-namespace/org-custom-internal-cidr, respetivamente, para a organização zonal. Todas as outras reivindicações de CIDR e reivindicações de sub-rede desta organização são secundárias destas duas reivindicações de CIDR:

...

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

...

O seguinte tem de ser verdadeiro para o CIDR externo personalizado e o CIDR interno personalizado:

  • Único no recurso OrganizationZonalConfig para cada zona.
  • Único no recurso OrganizationZonalConfig para cada organização v1 existente em todas as zonas.
  • Não pode sobrepor-se ao zone-infra-cidr de cada zona.
  • Não pode sobrepor-se a nenhuma sub-rede global com a etiqueta ipam.gdc.goog/usage=network-root-range.

Depois de cumprir estes requisitos, pode continuar os passos de arranque predefinidos da organização para arrancar a organização v1 na nova zona.

Configure as definições de CIDR para a organização v2 na zona existente

Para aprovisionar uma organização v2 numa zona existente, tem de criar manualmente o recurso CIDRClaimgpc-system/zone-infra-cidr. Também tem de se certificar de que o bloco CIDR na nova reivindicação CIDR não se sobrepõe ao seguinte:

  • As gpc-system/instance- reivindicações de CIDR na zona.

  • Quaisquer reivindicações de CIDR gpc-system/zone-infra-cidr ou gpc-system/instance- noutras zonas do universo.

Planeie as definições de CIDR

  1. Imprima os recursos CIDRClaim existentes:

    kubectl --kubeconfig=ROOT_ADMIN_KUBECONFIG get cidrclaim -n gpc-system

  2. Verifique os campos status.ipv4AllocationStatus.cidrBlocks e status.ipv6AllocationStatus.cidrBlocks para cada recurso CIDRClaim no resultado.

    Por exemplo, o recurso CIDRClaim seguinte reservou os blocos 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

    Tome nota destes blocos CIDR para poder evitar usá-los quando criar o zone-infra-cidr para a sua organização v2.

Crie a reivindicação de zone-infra-cidr CIDR

  1. Encontre e tome nota das seguintes reivindicações de CIDR com o espaço de nomes gpc-system em cada zona do seu 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

    Por exemplo, o comando seguinte devolve as reivindicações de CIDR para a zona atual:instance-external-cidr

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

    Para mudar os contextos zonais, use a CLI gdcloud.

  2. Crie um recurso CIDRClaim denominado zone-infra-cidr que não se sobreponha às reivindicações de CIDR verificadas anteriormente:

    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

    Os CIDRs IPv4 e IPv6 têm de ser exclusivos e não podem sobrepor-se a nenhuma reivindicação de CIDR existente no espaço de nomes gpc-system na zona atual ou em quaisquer outras zonas existentes.instance-

  3. Verifique o estado do zone-infra-cidr para se certificar de que está pronto:

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

    Após a reivindicação do CIDR ser Ready, pode continuar os passos de arranque predefinidos da organização para arrancar a organização v2 na nova zona.