Provisionner des adresses IP pour les charges de travail

Créez des sous-réseaux supplémentaires dans le cloud privé virtuel (VPC) interne de votre organisation ou dans le VPC par défaut pour répondre à vos besoins en matière de mise en réseau interne. Par exemple, ajoutez des sous-réseaux VPC pour vous assurer que vos charges de travail internes, telles que les machines virtuelles (VM) et les conteneurs, disposent de suffisamment d'adresses IP.

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

• Créer un sous-réseau de branche zonal pour les charges de travail : cette tâche est utile pour organiser ou allouer davantage les adresses IP internes existantes de votre zone aux charges de travail.
• Créer un sous-réseau feuille pour une charge de travail individuelle : cette tâche est utile lorsque vous disposez d'une nouvelle charge de travail 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 internes.
• Diviser le sous-réseau racine global sans allocation de zone : cette tâche est utile pour organiser davantage les adresses IP internes dans le serveur d'API global avant de les allouer à une zone.
• Ajouter un sous-réseau global de plage racine de réseau : cette tâche est utile lorsque votre VPC par défaut ne dispose plus d'un espace d'adresses IP internes global suffisant à 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.

Ce document s'adresse aux administrateurs de plate-forme et aux opérateurs d'applications chargés de gérer le trafic réseau de leur organisation. Pour en savoir plus, consultez Audiences pour la documentation GDC sous air gap.

Avant de commencer

Pour obtenir l'autorisation nécessaire pour créer des sous-réseaux, demandez à votre administrateur d'organisation IAM de vous accorder le rôle IAM d'administrateur d'organisation de 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 charges de travail

Pour subdiviser davantage les adresses IP de votre VPC par défaut zonal, vous pouvez créer un sous-réseau interne zonal à partir du sous-réseau racine zonal existant de la zone. 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, allouez un autre sous-réseau zonal à partir de la plage d'adresses IP globale avant de continuer.

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

  kubectl --kubeconfig MANAGEMENT_API_SERVER_KUBECONFIG apply -f - <<EOF
  apiVersion: ipam.gdc.goog/v1
  kind: Subnet
  metadata:
    labels:
      ipam.gdc.goog/vpc: default-vpc
    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 d'API de gestion zonale.

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

  • CIDR_PREFIX_LENGTH : longueur de préfixe de votre nouveau sous-réseau, par exemple 27. Ce champ alloue de manière dynamique la plage d'adresses IP disponible suivante de cette taille à partir du sous-réseau parent. Utilisez le champ prefixLength lorsque vous ne vous intéressez qu'à la taille du sous-réseau, et non à sa plage d'adresses IP spécifique.

    Pour attribuer une plage d'adresses IP spécifique, procédez comme suit :

    1. Supprimez la ligne prefixLength: CIDR_PREFIX_LENGTH.
    2. Ajoutez une ligne cidr: "YOUR_CIDR_BLOCK" à la place, par exemple cidr: "10.0.10.0/27".

    Utilisez le champ cidr lorsque vous suivez un plan d'adressage IP strict et que vous devez attribuer une plage d'adresses IP précise et prévisible. Cette plage doit être un sous-réseau valide et disponible dans le sous-réseau parent.

  • PARENT_SUBNET_NAME : nom du sous-réseau parent, par exemple default-vpc-zone0-cidr. Le sous-réseau parent est généralement un sous-réseau racine zonal dans le VPC par défaut.

  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 à une charge de travail interne.

Créer un sous-réseau feuille pour une charge de travail individuelle

Pour allouer une seule adresse IP à votre charge de travail, vous devez créer un sous-réseau feuille. Ce sous-réseau feuille doit avoir la valeur de champ type: Leaf et doit se trouver dans le même espace de noms de projet que votre ressource de charge de travail, telle qu'une VM ou un conteneur.

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 de branche zonal pour les charges de travail.

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

  kubectl --kubeconfig MANAGEMENT_API_SERVER_KUBECONFIG apply -f - <<EOF
  apiVersion: ipam.gdc.goog/v1
  kind: Subnet
  metadata:
    labels:
      ipam.gdc.goog/vpc: default-vpc
    name: SUBNET_NAME
    namespace: PROJECT_NAMESPACE
  spec:
    ipv4Request:
      prefixLength: 32
    parentReference:
      name: PARENT_SUBNET
      namespace: PARENT_NAMESPACE
    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 d'API de gestion zonale.
  • SUBNET_NAME : nom du sous-réseau feuille.
  • PROJECT_NAMESPACE : espace de noms correspondant au projet où se trouvent vos charges de travail.
  • PARENT_SUBNET : nom du sous-réseau parent à partir duquel ce sous-réseau feuille obtiendra son adresse IP.
  • PARENT_NAMESPACE : espace de noms PROJECT_NAMESPACE ou platform.

Votre adresse IP individuelle peut désormais être utilisée par vos charges de travail internes, telles que les VM et les conteneurs. Pour en savoir plus sur la configuration de l'adresse IP de vos charges de travail, consultez Créer une VM avec une adresse IP statique ou dynamique ou Configurer un équilibreur de charge interne pour les charges de travail de conteneur.

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 charges de travail à partir de la plage d'adresses IP racine zonale existante, vous pouvez allouer des adresses IP supplémentaires à partir de la plage racine d'adresses IP globale.

Pour allouer un sous-réseau zonal à partir de la plage d'adresses IP globale, procédez comme suit pour le réseau VPC par défaut dans l'espace de noms platform :

1. Dans une fenêtre de terminal, décrivez tous les sous-réseaux racine du VPC par défaut et vérifiez leurs blocs CIDR disponibles :

   kubectl --kubeconfig GLOBAL_API_SERVER_KUBECONFIG describe subnets --namespace platform \
       -l ipam.gdc.goog/vpc=default-vpc,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 globales. Les étiquettes sont constantes et doivent rester les mêmes.

   Le résultat ressemble à ce qui suit :

   Name:         default-vpc-root-cidr
   Namespace:    platform
   Labels:       ipam.gdc.goog/allocation-preference=default
                 ipam.gdc.goog/subnet-group=default-vpc-root-group
                 ipam.gdc.goog/usage=network-root-range
                 ipam.gdc.goog/vpc=default-vpc
   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:       default-vpc-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. Ces valeurs sont les blocs CIDR disponibles auxquels l'étape suivante fait référence. Dans le résultat précédent, les plages CIDR 10.254.0.0/15 et 10.253.0.0/16 sont disponibles. Le résultat peut afficher plusieurs sous-réseaux. Notez tous les blocs CIDR disponibles et leurs sous-réseaux sources.

2. Comparez le plus grand bloc CIDR disponible de l'étape précédente avec la taille du bloc CIDR nécessaire pour votre zone. 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 réseau avant de continuer. Notez le sous-réseau parent à partir duquel vous décidez d'obtenir le bloc CIDR pour votre nouveau sous-réseau.

   Par exemple, si vous avez besoin d'un bloc CIDR /13, mais que les CIDR disponibles n'incluent que /15 et /16, vous devez ajouter un nouveau sous-réseau global de plage racine réseau. Si vous avez besoin d'un sous-réseau /15, vous pouvez allouer un nouveau sous-réseau zonal à partir du bloc 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/vpc: default-vpc
       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 globales.
   • 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 le CIDR de manière statique, remplacez le champ prefixLength par le champ cidr, puis définissez le bloc CIDR, par exemple 10.0.10.0/27.
   • ZONE_NAME : zone pour laquelle allouer le sous-réseau, par exemple zone1.
   • PARENT_SUBNET_NAME : nom du sous-réseau parent, tel que default-vpc-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 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éé sur 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 d'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 à une charge de travail interne.

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

Pour diviser davantage un sous-réseau global sans l'allouer à une zone, créez un sous-réseau global et omettez la stratégie de propagation dans la ressource personnalisée Subnet. Cette approche est utile si vous souhaitez continuer à organiser votre plage d'adresses IP accessible de manière globale à partir du sous-réseau racine global sans allouer les adresses IP à une zone.

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

1. Dans une fenêtre de terminal, décrivez tous les sous-réseaux racine du VPC par défaut et vérifiez leurs blocs CIDR disponibles :

   kubectl --kubeconfig GLOBAL_API_SERVER_KUBECONFIG describe subnets --namespace platform \
       -l ipam.gdc.goog/vpc=default-vpc,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 globales. Les étiquettes sont constantes et doivent rester les mêmes.

   Le résultat ressemble à ce qui suit :

   Name:         default-vpc-root-cidr
   Namespace:    platform
   Labels:       ipam.gdc.goog/allocation-preference=default
                 ipam.gdc.goog/subnet-group=default-vpc-root-group
                 ipam.gdc.goog/usage=network-root-range
                 ipam.gdc.goog/vpc=default-vpc
   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:       default-vpc-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. Ces valeurs sont les blocs CIDR disponibles auxquels l'étape suivante fait référence. Dans le résultat précédent, les plages CIDR 10.254.0.0/15 et 10.253.0.0/16 sont disponibles. Votre résultat peut contenir plusieurs sous-réseaux en fonction du nombre de sous-réseaux racine dont vous disposez. Notez donc tous les blocs CIDR disponibles, ainsi que le sous-réseau dont provient le bloc CIDR disponible.

2. Comparez le plus grand bloc CIDR disponible de l'étape précédente avec la taille du bloc CIDR nécessaire pour votre nouveau sous-réseau global. 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 réseau avant de continuer. Notez le sous-réseau parent à partir duquel vous décidez d'obtenir le bloc CIDR pour votre nouveau sous-réseau.

   Par exemple, si vous avez besoin d'un bloc CIDR /13, mais que les CIDR disponibles n'incluent que /15 et /16, vous devez créer un sous-réseau global de plage racine réseau. Si vous avez besoin d'un sous-réseau /15, vous pouvez allouer le nouveau sous-réseau global à partir du bloc 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/vpc: default-vpc
       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 globales.
   • 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 de manière statique 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 default-vpc-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 global de votre organisation dans le VPC par défaut est disponible. Vous pouvez créer un sous-réseau pour une zone particulière à partir de ce nouveau sous-réseau parent global.

Ajouter un sous-réseau global de plage racine de réseau

Les sous-réseaux globaux portant l'étiquette 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 réseau dans le serveur d'API global. Vous pouvez créer plusieurs sous-réseaux globaux racines, si nécessaire.

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 sous-réseau global de la nouvelle plage racine du réseau pour le VPC par défaut 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/vpc: default-vpc
      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 globales.
  • SUBNET_NAME : nom du nouveau sous-réseau.
  • NEW_CIDR : nouvelle plage CIDR du sous-réseau. Ce CIDR ne peut chevaucher aucun CIDR de tous les sous-réseaux existants portant l'étiquette ipam.gdc.goog/usage: network-root-range sur le même serveur d'API global.

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
• Déployer une application de VM à haute disponibilité
• Déployer une application de conteneur hautement disponible