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

Em um universo isolado do Google Distributed Cloud (GDC), é possível criar organizações v1 ou v2 que abrangem várias zonas. No entanto, há dois cenários de criação de organização que exigem configurações adicionais de CIDR antes da criação:

As seções a seguir abordam esses cenários e os pré-requisitos que você precisa concluir antes de criar a organização.

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

Não é possível provisionar uma organização da v1 em uma nova zona por padrão, já que muitas reivindicações de CIDR exigidas pela organização da v1 já estão atribuídas à organização raiz.

Você também precisa usar o recurso de endereço IP personalizado atual para a organização v1.

Configurações de CIDR do plano

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

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

    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 na saída.

    Por exemplo, o recurso CIDRClaim a seguir 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

    Anote esses blocos CIDR para evitar usá-los ao criar o CIDR externo e interno personalizados para sua organização.

  3. Verifique o zone-infra-cidr de cada zona e observe que os blocos CIDR atuais não são usados. Assim, você evita usá-los ao criar o CIDR personalizado para sua organização. Para mudar contextos zonais, use a CLI gdcloud.

  4. Imprima todas as sub-redes atuais com o rótulo 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 de cada recurso Subnet.

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

    Anote esses CIDRs para evitar usá-los ao criar o CIDR externo e interno personalizados para sua organização.

Configurar endereço IP personalizado

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

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

...

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

...

As seguintes condições precisam ser verdadeiras para os CIDR externos e internos personalizados:

  • Exclusivo no recurso OrganizationZonalConfig para cada zona.
  • Único no recurso OrganizationZonalConfig para cada organização v1 em todas as zonas.
  • Não pode se sobrepor ao zone-infra-cidr de cada zona.
  • Não é possível sobrepor com nenhuma sub-rede global com o rótulo ipam.gdc.goog/usage=network-root-range.

Depois que esses requisitos forem atendidos, continue as etapas de bootstrap da organização padrão para fazer o bootstrap da organização v1 na nova zona.

Configurar as definições de CIDR para a organização v2 na zona atual

Para provisionar uma organização da v2 em uma zona atual, crie manualmente o recurso CIDRClaim gpc-system/zone-infra-cidr. Também é necessário garantir que o bloco CIDR na nova declaração não se sobreponha a:

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

  • Qualquer reivindicação de CIDR gpc-system/zone-infra-cidr ou gpc-system/instance- em outras zonas do universo.

Configurações de CIDR do plano

  1. Imprima os recursos CIDRClaim atuais:

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

  2. Verifique os campos status.ipv4AllocationStatus.cidrBlocks e status.ipv6AllocationStatus.cidrBlocks de cada recurso CIDRClaim na saída.

    Por exemplo, o recurso CIDRClaim a seguir 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

    Anote esses blocos CIDR para evitar usá-los ao criar o zone-infra-cidr para sua organização v2.

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

  1. Encontre e anote as seguintes declarações de CIDR com o namespace 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 a seguir retorna as declarações de CIDR instance-external-cidr para a zona atual:

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

    Para alternar contextos zonais, use a CLI gdcloud.

  2. Crie um recurso CIDRClaim chamado 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 precisam ser exclusivos e não podem se sobrepor a nenhuma reivindicação de CIDR instance- no namespace gpc-system na zona atual ou em qualquer outra zona.

  3. Verifique o status do zone-infra-cidr para garantir que ele esteja pronto:

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

    Depois que a reivindicação de CIDR for Ready, continue com as etapas padrão de bootstrap da organização para fazer o bootstrap da organização v2 na nova zona.