Provisionner des adresses IP pour les charges de travail

Cette page explique comment créer 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. Vous devez créer un sous-réseau VPC pour vous assurer que vos charges de travail internes, telles que les machines virtuelles (VM) et les conteneurs, disposent d'un nombre suffisant d'adresses IP pour répondre à leurs besoins réseau au sein de votre organisation.

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

Pour obtenir une présentation des sous-réseaux et de leurs concepts avant d'effectuer les tâches décrites sur 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 charges de travail

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

  • Dans une fenêtre de terminal, créez le nouveau sous-réseau zonal 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/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 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 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

Vous devez créer un sous-réseau feuille pour attribuer une seule adresse IP à votre charge de travail. 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 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 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/vpc: default-vpc
  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 charges de travail.
    • 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 vos charges de travail internes, telles que les VM et les conteneurs. Pour savoir comment configurer l'adresse IP de vos charges de travail, consultez Déployer des charges de travail de machine virtuelle ou Déployer des 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 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 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 CIDR disponibles :

    kubectl --kubeconfig GLOBAL_API_SERVER_KUBECONFIG describe subnets --namespace platform \
    --label 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 mondial. 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 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 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 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 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 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

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

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

Pour diviser davantage un sous-réseau mondial sans l'attribuer à une zone pour que vos charges de travail l'utilisent, créez un sous-réseau mondial et ne définissez pas de stratégie de propagation dans la ressource personnalisée Subnet. Cette approche est utile 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 à une zone.

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 racine du VPC par défaut et vérifiez leurs CIDR disponibles :

    kubectl --kubeconfig GLOBAL_API_SERVER_KUBECONFIG describe subnets --namespace platform \
    --label 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 mondial. 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 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/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 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 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 mondial pour votre organisation dans le VPC par défaut 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 global de 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 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