Preconfigurar CIDR para nuevas organizaciones zonales

En un universo aislado de Google Distributed Cloud (GDC), puedes crear organizaciones de la versión 1 o de la versión 2 que abarquen varias zonas. Sin embargo, hay dos situaciones de creación de organizaciones que requieren configuraciones de CIDR adicionales antes de crear la organización:

En las siguientes secciones se describen estos casos y los requisitos que debes cumplir antes de crear la organización.

Configurar los ajustes de CIDR de la organización de la versión 1 en la nueva zona

De forma predeterminada, no puedes aprovisionar una organización de la versión 1 en una zona nueva, ya que muchas reclamaciones de CIDR que requiere la organización de la versión 1 ya están asignadas a la organización raíz.

También debe usar la función de dirección IP personalizada para la organización de la versión 1.

Configuración de CIDR del plan

Recoge los ajustes de CIDR configurados en tu zona para evitar que se solapen en tu nueva organización de la versión 1.

  1. Imprime el recurso zone-infra-cidr CIDRClaim:

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

  2. Comprueba los campos status.ipv4AllocationStatus.cidrBlocks y status.ipv6AllocationStatus.cidrBlocks del recurso CIDRClaim en el resultado.

    Por ejemplo, el siguiente recurso CIDRClaim ha reservado los bloques CIDR 192.0.2.0/21, 198.51.100.0/26, 203.0.113.0/23 y 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

    Anota estos bloques CIDR para evitar usarlos al crear el CIDR externo personalizado y el CIDR interno personalizado de tu organización.

  3. Consulta la zone-infra-cidr de cada zona y ten en cuenta que los bloques CIDR que ya existen no se usan, de modo que puedas evitar usarlos al crear el CIDR personalizado de tu organización. Para cambiar de contexto de zona, usa la CLI de gdcloud.

  4. Imprime todas las subredes con la etiqueta network-root-range:

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

  5. Comprueba los campos status.ipv4Allocation.cidr y status.ipv6Allocation.cidr de cada recurso Subnet.

    Por ejemplo, el siguiente infra-vpc-root-cidr ha reservado el 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

    Anota estos CIDRs para no usarlos al crear el CIDR externo personalizado y el CIDR interno personalizado de tu organización.

Configurar una dirección IP personalizada

Como parte del proceso de arranque de la organización de la versión 1, se necesitan CIDRs externos y personalizados como entrada para el recurso personalizado global OrganizationZonalConfig para admitir el arranque de la organización global de la versión 1.

En la OrganizationZonalConfig especificación de recursos, debes añadir las configuraciones de direcciones IP personalizadas para el CIDR externo y el CIDR interno. Los CIDRs externos personalizados y los CIDRs internos personalizados se crean en las reclamaciones de CIDR org-namespace/org-custom-external-cidr y org-namespace/org-custom-internal-cidr, respectivamente, para la organización zonal. El resto de las reclamaciones de CIDR y de subred de esta organización son elementos secundarios de estas dos reclamaciones de CIDR:

...

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

...

Tanto el CIDR externo personalizado como el CIDR interno personalizado deben cumplir los siguientes requisitos:

  • Es único en el recurso OrganizationZonalConfig de cada zona.
  • Es único en el recurso OrganizationZonalConfig de cada organización de la versión 1 que exista en todas las zonas.
  • No puede solaparse con el zone-infra-cidr de cada zona.
  • No puede solaparse con ninguna subred global que tenga la etiqueta ipam.gdc.goog/usage=network-root-range.

Una vez que se cumplan estos requisitos, puedes continuar con los pasos predeterminados de arranque de la organización para arrancar la organización de la versión 1 en la nueva zona.

Configurar los ajustes de CIDR para la organización de la versión 2 en una zona ya creada

Para aprovisionar una organización de la versión 2 en una zona, debes crear manualmente el recurso CIDRClaimgpc-system/zone-infra-cidr. También debes asegurarte de que el bloque CIDR de la nueva reclamación CIDR no se solape con lo siguiente:

  • Las reclamaciones de gpc-system/instance- CIDR de la zona.

  • Cualquier reclamación de gpc-system/zone-infra-cidr o gpc-system/instance- CIDR en otras zonas del universo.

Configuración de CIDR del plan

  1. Imprime los recursos CIDRClaim:

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

  2. Comprueba los campos status.ipv4AllocationStatus.cidrBlocks y status.ipv6AllocationStatus.cidrBlocks de cada recurso CIDRClaim de la salida.

    Por ejemplo, el siguiente recurso CIDRClaim ha reservado los bloques CIDR 192.0.2.0/21, 198.51.100.0/26, 203.0.113.0/23 y 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

    Anota estos bloques CIDR para no usarlos al crear el zone-infra-cidr de tu organización de la versión 2.

Crea la reclamación de zone-infra-cidr CIDR

  1. Busca y anota las siguientes reclamaciones de CIDR con el espacio de nombres gpc-system en cada zona de tu 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 ejemplo, el siguiente comando devuelve las reclamaciones de CIDR de instance-external-cidr de la zona actual:

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

    Para cambiar de contexto de zona, usa la CLI de gdcloud.

  2. Crea un recurso CIDRClaim llamado zone-infra-cidr que no se solape con las reclamaciones de CIDR comprobadas 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

    Las notaciones CIDR de IPv4 e IPv6 deben ser únicas y no pueden solaparse con ninguna notación CIDR del espacio de nombres instance-gpc-system de la zona actual ni de ninguna otra zona.

  3. Comprueba el estado de la zone-infra-cidr para asegurarte de que esté lista:

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

    Una vez que se haya Ready la reclamación de CIDR, puedes continuar con los pasos predeterminados de arranque de la organización para arrancar la organización de la versión 2 en la nueva zona.