Provisionner des adresses IP pour les charges de travail

Créez des sous-réseaux supplémentaires dans le cloud privé virtuel (VPC) interne ou le VPC par défaut de votre organisation pour répondre à vos besoins 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, mais 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 ne dispose pas encore d' adresse IP à utiliser.
• Allouer un sous-réseau zonal à partir d'une plage d'adresses IP globale : cette tâche est utile lorsque votre zone ne dispose plus de suffisamment d'espace d'adresses IP internes.
• Diviser le sous-réseau global racine 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 nouveau sous-réseau global de plage racine de réseau : Cette tâche est utile lorsque votre VPC par défaut ne dispose plus de suffisamment d'espace d'adresses IP internes globales à 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 est destiné aux administrateurs de plate-forme et aux opérateurs d'applications qui sont 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 à la création de sous-réseaux, demandez à votre administrateur IAM d'organisation de vous accorder le rôle IAM 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 dans 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 sous-réseau zonal dans le serveur d'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: 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 zonal.

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

  • CIDR_PREFIX_LENGTH : longueur de préfixe de votre nouveau sous-réseau, par exemple 27. Ce champ alloue dynamiquement la prochaine plage d'adresses IP disponible de cette taille à partir du sous-réseau parent. Utilisez le prefixLength champ lorsque vous ne vous souciez que de la taille du sous-réseau, et non de 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 cidr champ lorsque vous suivez un plan 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 Subnet ressource.

  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 résider 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 parentReference valeur 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 dans le serveur d'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 zonal.
  • SUBNET_NAME : nom du sous-réseau feuille.
  • PROJECT_NAMESPACE : espace de noms de projet correspondant à votre projet dans lequel 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: the PROJECT_NAMESPACE or the platform namespace.

Votre adresse IP individuelle est désormais disponible pour ê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 globale

Si votre zone ne fournit pas suffisamment d'adresses IP pour vos charges de travail à 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 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 racines 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 global. Les libellés sont constants 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 correspondent aux 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 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 à 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 de 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 de 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 nouveau 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 global.
   • SUBNET_NAME : nom du nouveau sous-réseau.
   • CIDR_PREFIX_LENGTH : longueur de préfixe CIDR du nouveau sous-réseau alloué dynamiquement, 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 le nouveau sous-réseau global de plage racine de 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 Subnet ressource.

4. Vérifiez que le sous-réseau est prêt et disponible dans le serveur d'API global en vous assurant 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 zonal et 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 zonal.

   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 global racine 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 globalement à 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 racines 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 global. Les libellés sont constants 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 correspondent aux 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 racines dont vous disposez. Notez donc tous les blocs CIDR disponibles et le sous-réseau à partir duquel ils proviennent.

2. Comparez le plus grand bloc CIDR disponible de l'étape précédente à 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 de 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 nouveau sous-réseau global de plage racine de 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 nouveau 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 global.
   • SUBNET_NAME : nom du nouveau sous-réseau.
   • CIDR_PREFIX_LENGTH : longueur de préfixe CIDR du nouveau sous-réseau alloué dynamiquement, 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.
   • PARENT_SUBNET_NAME : nom du sous-réseau parent, tel que default-vpc-root-cidr, ou le nouveau sous-réseau global de plage racine de 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 dans le serveur d'API global en vous assurant 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 nouveau sous-réseau global de plage racine de réseau

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

Pour créer un nouveau 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 global de plage racine de 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 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 avec le ipam.gdc.goog/usage: network-root-range libellé dans le même serveur d'API global.

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

Étape suivante

• 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 à haute disponibilité