Preconfigura el CIDR para las organizaciones zonales nuevas

En un universo aislado de Google Distributed Cloud (GDC), puedes crear organizaciones de la versión 1 o 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 abordan estas situaciones y los requisitos previos que debes completar antes de crear la organización.

Configura los parámetros de CIDR para la organización de la versión 1 en la zona nueva

De forma predeterminada, no puedes aprovisionar una organización de la versión 1 en una zona nueva, ya que muchas de las 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 debes usar la función de direcciones IP personalizadas existente para la organización de la versión 1.

Configuración de CIDR del plan

Recopila la configuración de CIDR existente en tu zona para evitar la superposición de CIDR en tu nueva organización de la versión 1.

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

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

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

    Por ejemplo, el siguiente recurso CIDRClaim reservó 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

    Toma nota de estos bloques de CIDR para que puedas evitar usarlos cuando crees el CIDR externo personalizado y el CIDR interno personalizado para tu organización.

  3. Verifica el zone-infra-cidr de cada zona y ten en cuenta que no se usan los bloques CIDR existentes para que puedas evitar usarlos cuando crees el CIDR personalizado para tu organización. Para cambiar contextos zonales, usa la CLI de gdcloud.

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

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

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

    Por ejemplo, el siguiente objeto infra-vpc-root-cidr reservó 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 CIDR para evitar usarlos cuando crees el CIDR externo personalizado y el CIDR interno personalizado para tu organización.

Configura una dirección IP personalizada

Como parte del proceso de bootstrapping de la organización de la versión 1, se requieren CIDR externos y CIDR internos personalizados como entrada para el recurso personalizado OrganizationZonalConfig global para admitir el bootstrapping de la organización global de la versión 1.

En la especificación del recurso OrganizationZonalConfig, debes agregar las configuraciones de direcciones IP personalizadas para el CIDR externo y el CIDR interno. Los CIDR externos personalizados y los CIDR internos personalizados se crean como las reclamaciones de CIDR org-namespace/org-custom-external-cidr y org-namespace/org-custom-internal-cidr, respectivamente, para la organización zonal. Todos los demás reclamos de CIDR y reclamos de subred de esta organización son secundarios de estos dos reclamos de CIDR:

...

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

...

Lo siguiente debe ser verdadero tanto para el CIDR externo personalizado como para el CIDR interno personalizado:

  • Es único en el recurso OrganizationZonalConfig para cada zona.
  • Es único en el recurso OrganizationZonalConfig para cada organización existente de la versión 1 en todas las zonas.
  • No se puede superponer con el zone-infra-cidr de cada zona.
  • No se puede superponer 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 de arranque predeterminados de la organización para arrancar la organización de la versión 1 en la zona nueva.

Configura los parámetros de CIDR para la organización de la versión 2 en la zona existente

Para aprovisionar una organización de la versión 2 en una zona existente, debes crear manualmente el recurso CIDRClaim gpc-system/zone-infra-cidr. También debes asegurarte de que el bloque CIDR dentro del nuevo reclamo de CIDR no se superponga con lo siguiente:

  • Son los reclamos de CIDR de gpc-system/instance- en la zona.

  • Cualquier reclamo de CIDR de gpc-system/zone-infra-cidr o gpc-system/instance- en otras zonas del universo

Configuración de CIDR del plan

  1. Imprime los recursos CIDRClaim existentes:

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

  2. Verifica los campos status.ipv4AllocationStatus.cidrBlocks y status.ipv6AllocationStatus.cidrBlocks de cada recurso CIDRClaim del resultado.

    Por ejemplo, el siguiente recurso CIDRClaim reservó 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 de CIDR para evitar usarlos cuando crees el zone-infra-cidr para tu organización de la versión 2.

Crea el reclamo de CIDR zone-infra-cidr

  1. Busca y anota los siguientes reclamos 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 los reclamos de CIDR de instance-external-cidr para la zona actual:

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

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

  2. Crea un recurso CIDRClaim llamado zone-infra-cidr que no se superponga con los reclamos de CIDR verificados 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

    Los CIDR de IPv4 e IPv6 deben ser únicos y no pueden superponerse con ningún reclamo de CIDR de instance- existente en el espacio de nombres gpc-system de la zona actual ni en ninguna otra zona existente.

  3. Verifica el estado de zone-infra-cidr para asegurarte de que esté listo:

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

    Después de que el reclamo de CIDR sea Ready, puedes continuar con los pasos predeterminados de inicio de la organización para iniciar la organización de la versión 2 en la zona nueva.