Préconfigurer le CIDR pour les nouvelles organisations zonales

Dans un univers Google Distributed Cloud (GDC) isolé, vous pouvez créer des organisations v1 ou v2 qui couvrent plusieurs zones. Toutefois, deux scénarios de création d'organisation nécessitent des configurations CIDR supplémentaires avant de créer l'organisation :

Les sections suivantes couvrent ces scénarios et les conditions préalables que vous devez remplir avant de créer l'organisation.

Configurer les paramètres CIDR pour une organisation v1 dans une nouvelle zone

Par défaut, vous ne pouvez pas provisionner d'organisation v1 dans une nouvelle zone, car de nombreuses revendications CIDR requises par l'organisation v1 sont déjà attribuées à l'organisation racine.

Vous devez également utiliser la fonctionnalité d'adresse IP personnalisée existante pour l'organisation v1.

Paramètres CIDR du plan

Rassemblez les paramètres CIDR existants configurés dans votre zone afin d'éviter tout chevauchement de CIDR dans votre nouvelle organisation v1.

  1. Imprimez la ressource zone-infra-cidr CIDRClaim existante :

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

  2. Vérifiez les champs status.ipv4AllocationStatus.cidrBlocks et status.ipv6AllocationStatus.cidrBlocks de la ressource CIDRClaim dans le résultat.

    Par exemple, la ressource CIDRClaim suivante a réservé les blocs CIDR 192.0.2.0/21, 198.51.100.0/26, 203.0.113.0/23 et 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

    Notez ces blocs CIDR pour éviter de les utiliser lorsque vous créerez les CIDR externes et internes personnalisés pour votre organisation.

  3. Vérifiez le zone-infra-cidr de chaque zone et notez que les blocs CIDR existants ne sont pas utilisés. Vous pouvez ainsi éviter de les utiliser lorsque vous créez le CIDR personnalisé pour votre organisation. Pour changer de contexte zonal, utilisez la CLI gdcloud.

  4. Affichez tous les sous-réseaux existants avec le libellé network-root-range :

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

  5. Vérifiez les champs status.ipv4Allocation.cidr et status.ipv6Allocation.cidr pour chaque ressource Subnet.

    Par exemple, le infra-vpc-root-cidr suivant a réservé le 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

    Notez ces CIDR pour éviter de les utiliser lorsque vous créerez les CIDR externes et internes personnalisés pour votre organisation.

Configurer une adresse IP personnalisée

Dans le cadre du processus d'amorçage de l'organisation v1, des CIDR externes et internes personnalisés sont requis en entrée de la ressource personnalisée globale OrganizationZonalConfig pour prendre en charge l'amorçage de l'organisation v1 globale.

Dans la spécification de la ressource OrganizationZonalConfig, vous devez ajouter les configurations d'adresses IP personnalisées pour le CIDR externe et le CIDR interne. Les CIDR externes et internes personnalisés sont instanciés respectivement dans les revendications CIDR org-namespace/org-custom-external-cidr et org-namespace/org-custom-internal-cidr pour l'organisation zonale. Toutes les autres revendications CIDR et de sous-réseaux de cette organisation sont des enfants de ces deux revendications CIDR :

...

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

...

Les conditions suivantes doivent être remplies pour le CIDR externe personnalisé et le CIDR interne personnalisé :

  • Unique dans la ressource OrganizationZonalConfig pour chaque zone.
  • Unique dans la ressource OrganizationZonalConfig pour chaque organisation v1 existante dans toutes les zones.
  • Ne peut pas chevaucher le zone-infra-cidr de chaque zone.
  • Ne peut pas chevaucher un sous-réseau global portant le libellé ipam.gdc.goog/usage=network-root-range.

Une fois ces exigences remplies, vous pouvez poursuivre les étapes d'amorçage de l'organisation par défaut pour amorcer l'organisation v1 dans la nouvelle zone.

Configurer les paramètres CIDR pour une organisation v2 dans une zone existante

Pour provisionner une organisation v2 dans une zone existante, vous devez créer manuellement la ressource CIDRClaim gpc-system/zone-infra-cidr. Vous devez également vous assurer que le bloc CIDR de la nouvelle revendication CIDR ne chevauche pas les éléments suivants :

  • Les revendications CIDR gpc-system/instance- dans la zone.

  • Toute revendication CIDR gpc-system/zone-infra-cidr ou gpc-system/instance- dans d'autres zones de l'univers.

Paramètres CIDR du plan

  1. Imprimez les ressources CIDRClaim existantes :

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

  2. Vérifiez les champs status.ipv4AllocationStatus.cidrBlocks et status.ipv6AllocationStatus.cidrBlocks pour chaque ressource CIDRClaim dans le résultat.

    Par exemple, la ressource CIDRClaim suivante a réservé les blocs CIDR 192.0.2.0/21, 198.51.100.0/26, 203.0.113.0/23 et 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

    Notez ces blocs CIDR pour éviter de les utiliser lorsque vous créerez le zone-infra-cidr pour votre organisation v2.

Créer la revendication CIDR zone-infra-cidr

  1. Recherchez et notez les revendications CIDR suivantes avec l'espace de noms gpc-system dans chaque zone de votre univers :

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

    Par exemple, la commande suivante renvoie les revendications CIDR instance-external-cidr pour la zone actuelle :

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

    Pour basculer entre les contextes zonaux, utilisez la CLI gdcloud.

  2. Créez une ressource CIDRClaim nommée zone-infra-cidr qui ne chevauche pas les revendications CIDR vérifiées précédemment :

    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

    Les CIDR IPv4 et IPv6 doivent être uniques et ne peuvent pas chevaucher les revendications CIDR instance- existantes dans l'espace de noms gpc-system de la zone actuelle ni d'aucune autre zone existante.

  3. Vérifiez l'état de zone-infra-cidr pour vous assurer qu'il est prêt :

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

    Une fois la revendication CIDR Ready, vous pouvez poursuivre les étapes d'amorçage de l'organisation par défaut pour amorcer l'organisation v2 dans la nouvelle zone.