Utiliser vos propres adresses IP avec des sous-réseaux externes

Cette page explique comment créer des sous-réseaux supplémentaires dans le segment de réseau de données de votre organisation pour répondre à vos besoins de mise en réseau externe. Vous devez ajouter des sous-réseaux pour vous assurer que vos services externes, tels que la traduction d'adresse réseau (NAT) de sortie et les équilibreurs de charge externes, disposent d'un nombre suffisant d'adresses IP pour répondre à leurs besoins réseau de connexion à des réseaux externes en dehors de votre organisation.

Plusieurs tâches sont décrites sur cette page. Elles ne doivent pas nécessairement être effectuées dans l'ordre :

• Créer un sous-réseau de branche zonal pour les services externes : cette tâche est utile pour organiser ou allouer davantage les adresses IP externes existantes de votre zone aux services.
• Créer un sous-réseau feuille pour un service individuel : cette tâche est utile lorsque vous avez un nouveau service qui n'a pas encore d'adresse IP à utiliser.
• Allouer un sous-réseau zonal à partir d'une plage d'adresses IP globales : cette tâche est utile lorsque votre zone ne dispose plus de suffisamment d'espace d'adresses IP externes.
• Diviser le sous-réseau global racine sans allocation de zone : cette tâche est utile pour mieux organiser les adresses IP externes dans le serveur d'API global avant de les allouer à une zone.
• Ajouter une nouvelle plage racine de réseau à un sous-réseau global : cette tâche est utile lorsque votre segment de réseau de données ne dispose plus d'un espace d'adresses IP externes globales suffisant pour l'allouer à vos zones.

Pour obtenir une présentation des sous-réseaux et de leurs concepts avant d'effectuer les tâches de cette page, consultez Sous-réseaux et adresses IP.

Cette page s'adresse aux administrateurs réseau du groupe des administrateurs de plate-forme et aux développeurs d'applications du groupe des opérateurs d'applications, qui sont chargés de gérer le trafic réseau de leur organisation. Pour en savoir plus, consultez la documentation sur les audiences pour GDC en mode air-gapped.

Avant de commencer

Pour obtenir l'autorisation nécessaire pour créer des sous-réseaux, demandez à votre administrateur IAM de l'organisation de vous accorder le rôle IAM d'administrateur de l'organisation des sous-réseaux (subnet-org-admin). Ce rôle n'est pas lié à un espace de noms.

Créer un sous-réseau de branche zonal pour les services externes

Vous pouvez créer un sous-réseau externe zonal à partir du sous-réseau racine zonal existant de la zone pour subdiviser davantage les adresses IP de votre segment de réseau de données zonal. Vous devez créer ce type de sous-réseau dans l'espace de noms platform. Si le sous-réseau racine zonal parent ne dispose pas de suffisamment d'adresses IP disponibles, allouez d'abord un autre sous-réseau zonal à partir de la plage d'adresses IP globale, puis revenez à cette procédure.

• Dans une fenêtre de terminal, créez le nouveau sous-réseau externe dans le serveur d'API de gestion zonale :

  kubectl -kubeconfig MANAGEMENT_API_SERVER_KUBECONFIG apply -f - <<EOF
  apiVersion: ipam.gdc.goog/v1
  kind: Subnet
  metadata:
    labels:
      ipam.gdc.goog/network-segment: data
    name: SUBNET_NAME
    namespace: platform
  spec:
    ipv4Request:
      prefixLength: CIDR_PREFIX_LENGTH
    networkSpec:
      enableGateway: true
      enableVLANID: false
    parentReference:
      name: PARENT_SUBNET_NAME
      namespace: platform
    type: Branch
  EOF
  

  Remplacez les éléments suivants :

  • MANAGEMENT_API_SERVER_KUBECONFIG : chemin d'accès au fichier kubeconfig de votre serveur d'API de gestion. Pour en savoir plus, consultez Ressources du serveur de l'API de gestion zonale.

  • SUBNET_NAME : nom de votre nouveau sous-réseau.

  • CIDR_PREFIX_LENGTH : longueur de préfixe CIDR du nouveau sous-réseau alloué de manière dynamique, par exemple 20. Pour définir statiquement le CIDR, remplacez le champ prefixLength par le champ cidr, puis définissez le bloc CIDR, tel que 10.0.10.0/27.

  • PARENT_SUBNET_NAME : nom du sous-réseau parent, tel que data-external-zone0-cidr. Le sous-réseau parent est généralement un sous-réseau racine zonal dans le segment de réseau de données.

  Pour en savoir plus, consultez la documentation de référence de l'API pour la ressource Subnet.

  Vous pouvez continuer à subdiviser vos sous-réseaux zonaux ou créer un sous-réseau feuille pour allouer une adresse IP individuelle directement à un service externe.

Créer un sous-réseau feuille pour un service individuel

Vous devez créer un sous-réseau feuille pour allouer une seule adresse IP à votre service. Ce sous-réseau feuille doit avoir la valeur de champ type: Leaf et résider dans le même espace de noms de projet que votre service externe, tel qu'un équilibreur de charge externe ou une passerelle NAT de sortie.

Votre sous-réseau feuille doit être configuré avec une valeur prefixLength de 32, car il est destiné à allouer une seule adresse IP. La valeur parentReference fait référence à un sous-réseau précédemment alloué, tel que le sous-réseau zonal parent que vous avez créé dans Créer un sous-réseau zonal de branche pour les charges de travail.

• Dans une fenêtre de terminal, créez le sous-réseau feuille dans le serveur de l'API Management :

  kubectl --kubeconfig MANAGEMENT_API_SERVER_KUBECONFIG apply -f - <<EOF
  apiVersion: ipam.gdc.goog/v1
  kind: Subnet
  metadata:
    labels:
      ipam.gdc.goog/allocation-preference: default
      ipam.gdc.goog/network-segment: data
    name: SUBNET_NAME
    namespace: PROJECT_NAMESPACE
  spec:
    ipv4Request:
      prefixLength: 32
    parentReference:
      name: PARENT_SUBNET
      namespace: platform
    type: Leaf
  EOF
  

  Remplacez les éléments suivants :

  • MANAGEMENT_API_SERVER_KUBECONFIG : chemin d'accès au fichier kubeconfig de votre serveur d'API de gestion. Pour en savoir plus, consultez Ressources du serveur de l'API de gestion zonale.
  • SUBNET_NAME : nom du sous-réseau feuille.
  • PROJECT_NAMESPACE : espace de noms du projet correspondant à votre projet dans lequel se trouvent vos services.
  • PARENT_SUBNET : nom du sous-réseau parent à partir duquel ce sous-réseau feuille extraira son adresse IP.

Votre adresse IP individuelle est désormais disponible pour votre service externe. Pour savoir comment configurer l'adresse IP de votre service, consultez la documentation correspondante, par exemple Configurer des équilibreurs de charge externes.

Allouer un sous-réseau zonal à partir d'une plage d'adresses IP globales

Si votre zone ne fournit pas suffisamment d'adresses IP pour vos services externes à partir de la plage d'adresses IP du sous-réseau racine zonal existant, vous pouvez allouer des adresses IP supplémentaires à partir de la plage racine d'adresses IP globales.

Procédez comme suit pour le segment de réseau de données dans l'espace de noms platform :

1. Dans une fenêtre de terminal, décrivez tous les sous-réseaux racines du segment de réseau de données et vérifiez leurs CIDR disponibles :

   kubectl --kubeconfig GLOBAL_API_SERVER_KUBECONFIG describe subnets --namespace platform \
       --label ipam.gdc.goog/network-segment=data,ipam.gdc.goog/usage=network-root-range
   

   Remplacez GLOBAL_API_SERVER_KUBECONFIG par le chemin d'accès au fichier kubeconfig du serveur d'API global. Pour en savoir plus, consultez Ressources du serveur d'API mondial. Les libellés sont constants et doivent rester les mêmes.

   Le résultat ressemble à ce qui suit :

   Name:         data-external-root-cidr
   Namespace:    platform
   Labels:       ipam.gdc.goog/allocation-preference=default
                 ipam.gdc.goog/subnet-group=data-external-root-group
                 ipam.gdc.goog/usage=network-root-range
                 ipam.gdc.goog/network-segment=data
   Annotations:  <none>
   API Version:  ipam.global.gdc.goog/v1
   Kind:         Subnet
   Metadata:
     Creation Timestamp:  2025-06-18T23:05:38Z
     Finalizers:
       global-subnet-finalizer
     Generation:        1
     Resource Version:  439434
     UID:               5ed1c51a-b5ee-473e-a185-8e065a87ae8f
   Spec:
     ipv4Request:
       Cidr:                10.252.0.0/14
     Propagation Strategy:  None
     Type:                  Root
   Status:
     Children Refs:
       Name:       data-external-zone1-root-cidr
       Namespace:  platform
       Type:       SingleSubnet
     Conditions:
       Last Transition Time:  2025-06-18T23:05:38Z
       Message:               IP allocation finished successfully
       Observed Generation:   1
       Reason:                AllocationSucceeded
       Status:                True
       Type:                  Ready
     ipv4Allocation:
       Available CIDRs:
         10.254.0.0/15
         10.253.0.0/16
       Cidr:  10.252.0.0/14
   Events:    <none>
   

   Notez les valeurs Status.ipv4Allocation.Available CIDRs comme les CIDR disponibles, qui seront référencés à l'étape suivante. Dans le résultat précédent, les plages CIDR 10.254.0.0/15 et 10.253.0.0/16 sont disponibles. Il peut y avoir plusieurs sous-réseaux dans votre sortie en fonction du nombre de sous-réseaux racine dont vous disposez. Notez donc tous les CIDR disponibles et indiquez de quel sous-réseau provient le CIDR disponible.

2. Comparez le plus grand CIDR disponible que vous avez noté à l'étape précédente avec la taille du CIDR que vous devez allouer à votre zone. Si le CIDR le plus grand disponible n'est pas assez grand pour allouer votre nouveau sous-réseau, ajoutez un nouveau sous-réseau global de plage racine réseau avant de continuer. Notez le sous-réseau parent à partir duquel vous décidez d'obtenir le CIDR pour votre nouveau sous-réseau.

   Par exemple, si vous avez besoin d'un CIDR /13, mais que les CIDR disponibles n'incluent que /15 et /16, vous devez créer un sous-réseau global pour la nouvelle plage racine du réseau. Si vous avez besoin d'un sous-réseau /15, vous pouvez allouer un nouveau sous-réseau zonal à partir du CIDR /15 existant.

3. Créez le sous-réseau dans le serveur d'API global :

   kubectl --kubeconfig GLOBAL_API_SERVER_KUBECONFIG apply -f - <<EOF
   apiVersion: ipam.global.gdc.goog/v1
   kind: Subnet
   metadata:
     labels:
       ipam.gdc.goog/network-segment: data
       ipam.gdc.goog/usage: zone-network-root-range
     name: SUBNET_NAME
     namespace: platform
   spec:
     ipv4Request:
       prefixLength: CIDR_PREFIX_LENGTH
     zone: ZONE_NAME
     propagationStrategy: SingleZone
     type: Branch
     parentReference:
       name: PARENT_SUBNET_NAME
       namespace: ORG_NAME
   EOF
   

   Remplacez les éléments suivants :

   • GLOBAL_API_SERVER_KUBECONFIG : chemin d'accès au fichier kubeconfig du serveur d'API global. Pour en savoir plus, consultez Ressources du serveur d'API global.
   • SUBNET_NAME : nom du nouveau sous-réseau.
   • CIDR_PREFIX_LENGTH : longueur du préfixe CIDR du nouveau sous-réseau alloué de manière dynamique, par exemple 20. Pour définir statiquement le CIDR, remplacez le champ prefixLength par le champ cidr, puis définissez le bloc CIDR, tel que 10.0.10.0/27.
   • ZONE_NAME : zone dans laquelle allouer le sous-réseau, par exemple zone1.
   • PARENT_SUBNET_NAME : nom du sous-réseau parent, tel que data-external-root-cidr, ou du nouveau sous-réseau global de plage racine du réseau que vous avez créé.
   • ORG_NAME : nom de l'organisation.

   Pour en savoir plus, consultez la documentation de référence de l'API pour la ressource globale Subnet.

4. Vérifiez que le sous-réseau est prêt et disponible sur le serveur d'API global en vérifiant que son type d'état Ready est true :

   kubectl --kubeconfig GLOBAL_API_SERVER_KUBECONFIG get subnet --namespace platform \
       SUBNET_NAME --output jsonpath='{.status.conditions[?(@.type=="Ready")].status}'
   

   Le résultat ressemble à ce qui suit :

   status:
     conditions:
     - lastTransitionTime: "2025-06-06T07:28:48Z"
       message: IP allocation finished successfully
       observedGeneration: 1
       reason: AllocationSucceeded
       status: "True"
       type: Ready
   

5. Vérifiez que le sous-réseau zonal est créé dans le serveur d'API de gestion zonale et que son type d'état Ready est true :

   kubectl --kubeconfig MANAGEMENT_API_SERVER_KUBECONFIG get subnet --namespace platform \
       SUBNET_NAME --output jsonpath='{.status.conditions[?(@.type=="Ready")].status}'
   

   Remplacez MANAGEMENT_API_SERVER_KUBECONFIG par le chemin d'accès au fichier kubeconfig de votre serveur d'API de gestion. Pour en savoir plus, consultez Ressources du serveur de l'API de gestion zonale.

   Le résultat ressemble à ce qui suit :

   status:
     conditions:
     - lastTransitionTime: "2025-06-06T07:29:34Z"
       message: IP allocation finished successfully
       observedGeneration: 1
       reason: AllocationSucceeded
       status: "True"
       type: Ready
   

   À partir de ce nouveau sous-réseau zonal, vous pouvez créer d'autres sous-réseaux enfants zonaux ou allouer une adresse IP individuelle directement à un service externe.

Diviser le sous-réseau global racine sans allocation de zone

Si vous souhaitez continuer à organiser votre plage d'adresses IP accessibles à l'échelle mondiale à partir du sous-réseau racine global sans attribuer les adresses IP à vos services externes zonaux, créez un sous-réseau global et ne définissez pas de stratégie de propagation dans la ressource personnalisée Subnet.

Dans l'espace de noms platform, procédez comme suit pour diviser votre sous-réseau racine global dans le champ d'application global uniquement :

1. Dans une fenêtre de terminal, décrivez tous les sous-réseaux racines du segment de réseau de données et vérifiez leurs CIDR disponibles :

   kubectl --kubeconfig GLOBAL_API_SERVER_KUBECONFIG describe subnets --namespace platform \
       --label ipam.gdc.goog/network-segment=data,ipam.gdc.goog/usage=network-root-range
   

   Remplacez GLOBAL_API_SERVER_KUBECONFIG par le chemin d'accès au fichier kubeconfig du serveur d'API global. Pour en savoir plus, consultez Ressources du serveur d'API mondial. Les libellés sont constants et doivent rester les mêmes.

   Le résultat ressemble à ce qui suit :

   Name:         data-external-root-cidr
   Namespace:    platform
   Labels:       ipam.gdc.goog/allocation-preference=default
                 ipam.gdc.goog/subnet-group=data-external-root-group
                 ipam.gdc.goog/usage=network-root-range
                 ipam.gdc.goog/network-segment=data
   Annotations:  <none>
   API Version:  ipam.global.gdc.goog/v1
   Kind:         Subnet
   Metadata:
     Creation Timestamp:  2025-06-18T23:05:38Z
     Finalizers:
       global-subnet-finalizer
     Generation:        1
     Resource Version:  439434
     UID:               5ed1c51a-b5ee-473e-a185-8e065a87ae8f
   Spec:
     ipv4Request:
       Cidr:                10.252.0.0/14
     Propagation Strategy:  None
     Type:                  Root
   Status:
     Children Refs:
       Name:       data-external-zone1-root-cidr
       Namespace:  platform
       Type:       SingleSubnet
     Conditions:
       Last Transition Time:  2025-06-18T23:05:38Z
       Message:               IP allocation finished successfully
       Observed Generation:   1
       Reason:                AllocationSucceeded
       Status:                True
       Type:                  Ready
     ipv4Allocation:
       Available CIDRs:
         10.254.0.0/15
         10.253.0.0/16
       Cidr:  10.252.0.0/14
   Events:    <none>
   

   Notez les valeurs Status.ipv4Allocation.Available CIDRs comme les CIDR disponibles, qui seront référencés à l'étape suivante. Dans le résultat précédent, les plages CIDR 10.254.0.0/15 et 10.253.0.0/16 sont disponibles. Il peut y avoir plusieurs sous-réseaux dans votre sortie en fonction du nombre de sous-réseaux racine dont vous disposez. Notez donc tous les CIDR disponibles et indiquez de quel sous-réseau provient le CIDR disponible.

2. Comparez le plus grand CIDR disponible que vous avez noté à l'étape précédente avec la taille du CIDR que vous devez allouer à votre nouveau sous-réseau mondial. Si le plus grand bloc CIDR disponible n'est pas assez grand pour allouer votre nouveau sous-réseau, ajoutez un nouveau sous-réseau global de plage racine de réseau avant de continuer. Notez le sous-réseau parent à partir duquel vous décidez d'obtenir le CIDR pour votre nouveau sous-réseau.

   Par exemple, si vous avez besoin d'un CIDR /13, mais que les CIDR disponibles n'incluent que /15 et /16, vous devez créer un sous-réseau global pour la nouvelle plage racine du réseau. Si vous avez besoin d'un sous-réseau /15, vous pouvez allouer le nouveau sous-réseau mondial à partir du CIDR /15 existant.

3. Créez le sous-réseau dans le serveur d'API global :

   kubectl --kubeconfig GLOBAL_API_SERVER_KUBECONFIG apply -f - <<EOF
   apiVersion: ipam.global.gdc.goog/v1
   kind: Subnet
   metadata:
     labels:
       ipam.gdc.goog/network-segment: data
       ipam.gdc.goog/usage: zone-network-root-range
     name: SUBNET_NAME
     namespace: platform
   spec:
     ipv4Request:
       prefixLength: CIDR_PREFIX_LENGTH
     propagationStrategy: None
     type: Branch
     parentReference:
       name: PARENT_SUBNET_NAME
       namespace: ORG_NAME
   EOF
   

   Remplacez les éléments suivants :

   • GLOBAL_API_SERVER_KUBECONFIG : chemin d'accès au fichier kubeconfig du serveur d'API global. Pour en savoir plus, consultez Ressources du serveur d'API global.
   • SUBNET_NAME : nom du nouveau sous-réseau.
   • CIDR_PREFIX_LENGTH : longueur du préfixe CIDR du nouveau sous-réseau alloué de manière dynamique, par exemple 20. Pour définir statiquement le CIDR, remplacez le champ prefixLength par le champ cidr, puis définissez le bloc CIDR, tel que 10.0.10.0/27.
   • PARENT_SUBNET_NAME : nom du sous-réseau parent, tel que data-external-root-cidr, ou du nouveau sous-réseau global de plage racine du réseau que vous avez créé.
   • ORG_NAME : nom de l'organisation.

   Pour en savoir plus, consultez la documentation de référence de l'API pour la ressource globale Subnet.

4. Vérifiez que le sous-réseau est prêt et disponible sur le serveur d'API global en vérifiant que son type d'état Ready est true :

   kubectl --kubeconfig GLOBAL_API_SERVER_KUBECONFIG get subnet --namespace platform \
       SUBNET_NAME --output jsonpath='{.status.conditions[?(@.type=="Ready")].status}'
   

   Le résultat ressemble à ce qui suit :

   status:
     conditions:
     - lastTransitionTime: "2025-06-06T07:28:48Z"
       message: IP allocation finished successfully
       observedGeneration: 1
       reason: AllocationSucceeded
       status: "True"
       type: Ready
   

Le nouveau sous-réseau mondial pour votre organisation dans le segment de réseau de données est disponible. Vous pouvez créer un sous-réseau pour une zone spécifique à partir de ce nouveau sous-réseau parent mondial.

Ajouter un nouveau sous-réseau global à la plage racine du réseau

Les sous-réseaux mondiaux portant le libellé ipam.gdc.goog/usage: network-root-range hébergent le CIDR pour toutes les zones du réseau. Si le CIDR est épuisé, vous devez créer un sous-réseau de plage racine de réseau dans le serveur d'API global. Si nécessaire, vous pouvez créer plusieurs sous-réseaux racine globaux.

Pour créer un sous-réseau de plage racine de réseau, procédez comme suit :

• Dans une fenêtre de terminal, créez le nouveau sous-réseau mondial de plage racine du réseau pour le segment de réseau de données dans l'espace de noms platform :

  kubectl --kubeconfig GLOBAL_API_SERVER_KUBECONFIG apply -f - <<EOF
  apiVersion: ipam.global.gdc.goog/v1
  kind: Subnet
  metadata:
    labels:
      ipam.gdc.goog/network-segment: data
      ipam.gdc.goog/usage: network-root-range
    name: SUBNET_NAME
    namespace: platform
  spec:
    ipv4Request:
      cidr: NEW_CIDR
    type: Root
  EOF
  

  Remplacez les éléments suivants :

  • GLOBAL_API_SERVER_KUBECONFIG : chemin d'accès au fichier kubeconfig du serveur d'API global. Pour en savoir plus, consultez Ressources du serveur d'API global.
  • SUBNET_NAME : nom du nouveau sous-réseau.
  • NEW_CIDR : nouveau CIDR du sous-réseau. Ce CIDR ne peut pas chevaucher un CIDR dans tous les sous-réseaux existants portant le libellé ipam.gdc.goog/usage: network-root-range sur le même serveur d'API globale.

Ce nouveau sous-réseau de plage racine globale peut être subdivisé dans le serveur d'API global ou alloué à une zone spécifique.

Étapes suivantes

• Sous-réseaux et adresses IP
• Présentation de la mise en réseau
• Configurer des équilibreurs de charge externes