Cette page a été traduite par l'API Cloud Translation.

Configurer des sous-réseaux pour la mise en réseau des charges de travail

Des sous-réseaux racine globaux sont attribués à chaque zone Google Distributed Cloud (GDC) isolée, avec le sous-réseau de l'API publique de gestion des adresses IP (IPAM). Les sous-réseaux racines mondiaux hébergent le pool de plages d'adresses IP racines (CIDR) qui est divisé dans chaque zone pour amorcer tous les clusters de l'organisation locataire, y compris le cluster d'infrastructure de l'organisation et les VM de charge de travail. Une petite partie de la plage d'adresses IP est également mise à la disposition des sous-réseaux racine en tant que pool d'adresses IP Anycast.

Une fois l'organisation créée, vous pouvez effectuer les tâches opérationnelles suivantes pour les sous-réseaux de votre univers GDC :

Créez les sous-réseaux requis pour une nouvelle zone.
Créez des sous-réseaux supplémentaires pour une zone existante.
Créez des sous-réseaux de nœuds supplémentaires pour l'organisation.

Créer des sous-réseaux globaux de plage racine pour la nouvelle zone

Chaque zone doit disposer de sous-réseaux globaux de plage racine. Lors de la phase d'amorçage initial de l'organisation de l'univers GDC, les sous-réseaux globaux sont générés automatiquement pour chaque zone. Toutefois, si une zone est ajoutée après l'installation initiale, vous devez créer manuellement les sous-réseaux mondiaux de la plage racine pour la nouvelle zone.

Définir la plage CIDR pour les sous-réseaux de la plage racine du réseau de la nouvelle zone

Comme pour les instructions d'installation de l'organisation pour définir une plage CIDR, les plages CIDR ne peuvent pas se chevaucher entre elles ni avec les sous-réseaux globaux racines existants, qui sont des sous-réseaux portant le libellé ipam.gdc.goog/usage: network-root-range dans leur spécification de ressource personnalisée.zone-infra-cidr

Le zone-infra-cidr existe dans chaque zone et peut être récupéré à partir du questionnaire d'accueil des clients (CIQ) si le client l'a défini.

Pour récupérer le zone-infra-cidr, exécutez la commande suivante :

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

Notez la plage CIDR.

Vous devez disposer d'un espace de noms dont le nom correspond à celui que vous attribuerez à votre organisation. Vérifiez que cet espace de noms existe :
```
kubectl --kubeconfig GLOBAL_ROOT_ADMIN_KUBECONFIG get namespace ORG_NAME
```
Récupérez les sous-réseaux globaux racines existants :
- Pour le cluster administrateur racine global, exécutez la commande suivante :
```
kubectl –kubeconfig GLOBAL_ROOT_ADMIN_KUBECONFIG get subnet \
    -n ORG_NAME  -l ipam.gdc.goog/usage=network-root-range
```
- Pour le serveur d'API d'administrateur de l'organisation mondiale, exécutez la commande suivante :
```
kubectl –kubeconfig GLOBAL_ORG_API_SERVER_KUBECONFIG get subnet \
    -n platform -l ipam.gdc.goog/usage=network-root-range
```
  Notez toutes les plages CIDR de la sortie.
Vérifiez que les nouvelles plages CIDR prévues ne chevauchent aucune des plages CIDR précédentes.

Une fois que vous avez vérifié que votre nouvelle plage CIDR est valide pour la nouvelle zone, assurez-vous qu'elle respecte les règles suivantes :

Champ de plage CIDR.	Taille minimale	VPC/VRF	Serveur d'API mondial
`zoneInfraVPCCIDR`	17	VPC d'infrastructure	Racine globale
`zoneDefaultVPCCIDR`	18	VPC par défaut	Organisation mondiale
`zoneOrgAdminExternalCIDR`	23	Segment de réseau administrateur	Racine globale
`zoneOrgDataExternalCIDR`	23	Segment de réseau de données	Racine globale

Créer des sous-réseaux dans le serveur d'API de l'administrateur racine global

Pour créer les sous-réseaux dans le serveur d'API d'administrateur racine global, procédez comme suit :

Répertoriez les zones de votre univers et recherchez le nom de la nouvelle zone :
```
kubectl --kubeconfig GLOBAL_ROOT_ADMIN_KUBECONFIG get zone -A
```

Créez le sous-réseau infra-vpc de la plage racine du réseau de la zone pour la nouvelle zone de l'organisation :

kubectl apply -f --kubeconfig GLOBAL_ROOT_ADMIN_KUBECONFIG - <<EOF
apiVersion: ipam.global.gdc.goog/v1
kind: Subnet
metadata:
  labels:
    ipam.gdc.goog/vpc: infra-vpc
    ipam.gdc.goog/usage: zone-network-root-range
  annotations:
    ipam.gdc.goog/pivot-destination: global-org
  name: infra-vpc-NEW_ZONE_NAME-root-cidr
  namespace: ORG_NAME
spec:
  ipv4Request:
    cidr: zoneInfraVPCCIDR
  zone: NEW_ZONE_NAME
  propagationStrategy: SingleZone
  type: Root
EOF

Créez le sous-réseau du segment de réseau de données de la plage racine du réseau de zone pour la nouvelle zone de l'organisation :

kubectl apply -f --kubeconfig GLOBAL_ROOT_ADMIN_KUBECONFIG - <<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
  annotations:
    ipam.gdc.goog/pivot-destination: global-org
  name: data-external-NEW_ZONE_NAME-root-cidr
  namespace: ORG_NAME
spec:
  ipv4Request:
    cidr: zoneOrgDataExternalCIDR
  zone: NEW_ZONE_NAME
  propagationStrategy: SingleZone
  type: Root
EOF

Créez le sous-réseau du segment de réseau d'administration de la plage racine du réseau de zone pour la nouvelle zone de l'organisation :

kubectl apply -f --kubeconfig GLOBAL_ROOT_ADMIN_KUBECONFIG - <<EOF
apiVersion: ipam.global.gdc.goog/v1
kind: Subnet
metadata:
  labels:
    ipam.gdc.goog/network-segment: admin
    ipam.gdc.goog/usage: zone-network-root-range
  annotations:
    ipam.gdc.goog/pivot-destination: global-org
  name: admin-external-NEW_ZONE_NAME-root-cidr
  namespace: ORG_NAME
spec:
  ipv4Request:
    cidr: zoneOrgAdminExternalCIDR
  zone: NEW_ZONE_NAME
  propagationStrategy: SingleZone
  type: Root
EOF

Créer des sous-réseaux dans le serveur d'API d'administration de l'organisation mondiale

Vous devez créer le sous-réseau VPC par défaut dans le serveur d'API de l'administrateur de l'organisation globale dans l'espace de noms platform une fois le serveur d'API en cours d'exécution.

Créez et appliquez la ressource personnalisée Subnet suivante :

kubectl apply -f --kubeconfig=GLOBAL_ORG_API_SERVER_KUBECONFIG - <<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: default-vpc-NEW_ZONE_NAME-root-cidr
  namespace: platform
spec:
  type: Root
  ipv4Request:
    cidr: zoneDefaultVPCCIDR
  zone: NEW_ZONE_NAME
  propagationStrategy: SingleZone
EOF

Sous-réseaux de mise à l'échelle

La ressource publique Subnet n'est pas compatible avec la mise à l'échelle automatique. Pour ajouter d'autres plages CIDR à un VPC ou à un segment de réseau géré par le client, vous devez créer des sous-réseaux et les regrouper avec certains libellés. En raison de l'accès requis au cluster d'administrateur racine, un client ne peut pas augmenter la taille de ses sous-réseaux de manière indépendante.

Règles de regroupement des sous-réseaux

Les sous-réseaux sont regroupés dans différentes catégories par libellés :

Catégorie	Libellé
VPC par défaut	`ipam.gdc.goog/vpc: default-vpc`
VPC d'infrastructure	`ipam.gdc.goog/vpc: infra-vpc`
Segment de réseau administrateur	`ipam.gdc.goog/network-segment: admin`
Segment de réseau de données	`ipam.gdc.goog/network-segment: data`

Lors du bootstrap initial, quatre plages CIDR ont été spécifiées dans le questionnaire d'intégration de l'organisation (OIQ). Ces quatre sous-réseaux globaux ont été créés dans le serveur d'API global lors de la création de l'organisation cliente. Ces sous-réseaux mondiaux correspondent à la plage CIDR de niveau racine pour chaque catégorie dans toutes les zones d'une organisation. Tous les sous-réseaux globaux de niveau racine portent le libellé ipam.gdc.goog/usage: network-root-range.

Pour chaque zone, un sous-réseau global enfant est créé dans le serveur d'API global en le découpant à partir des sous-réseaux de niveau racine. Chaque sous-réseau mondial enfant héberge la plage CIDR d'une catégorie dans la zone spécifique et porte le libellé ipam.gdc.goog/usage: zone-network-root-range. Le sous-réseau enfant global d'une zone est automatiquement propagé à la zone spécifique.

Cas d'utilisation typiques de l'upscaling

Pour allouer le plus efficacement possible des sous-réseaux supplémentaires afin d'étendre vos sous-réseaux existants, tenez compte des cas d'utilisation recommandés pour chaque catégorie de sous-réseau. Déterminez la catégorie que vous souhaitez mettre à l'échelle avant de commencer le processus.

VPC par défaut

Les sous-réseaux de default-vpc sont principalement utilisés pour allouer les plages CIDR des pods et des services pour le cluster de services partagés, le cluster d'utilisateur et default-vpc-default-node-subnet pour l'adresse IP du nœud de cluster et l'adresse IP de la charge de travail pour l'organisation.

L'échec de la création d'un cluster d'utilisateur est un scénario courant dans lequel une mise à l'échelle du sous-réseau peut être nécessaire.

La création d'un cluster d'utilisateur peut échouer si la sous-réseau parent du CIDR de pod ou de service du cluster d'utilisateur est introuvable. Voici un exemple de message d'échec :

could not find parent for subnet platform/user-vm-1-service-cidr

Ce problème peut être dû à plusieurs raisons directement liées à la nécessité de mettre à l'échelle un sous-réseau. Pour confirmer, procédez comme suit :

Vérifiez les champs podCIDRSize et serviceCIDRSize dans la section .spec.clusterNetwork de la ressource personnalisée Cluster :

kubectl --kubeconfig MANAGEMENT_API_SERVER_KUBECONFIG get cluster \
    -n platform USER_CLUSTER_NAME -oyaml

La sortie ressemble à ceci :

Example:
spec:
  clusterNetwork:
    podCIDRSize: 20
    serviceCIDRSize: 20

Recherchez les sous-réseaux parents du sous-réseau existant :

kubectl --kubeconfig MANAGEMENT_API_SERVER_KUBECONFIG get subnet -n platform  -l \
    ipam.gdc.goog/vpc=default-vpc,ipam.gdc.goog/usage=zone-network-root-range

La sortie ressemble à ceci :

Example:
NAME                     PARENT   READY   IPV4 CIDR        IPV6 CIDR
default-vpc-zone0-cidr            True    198.51.100.0/18

Recherchez tous les sous-réseaux alloués par les sous-réseaux parents :

kubectl --kubeconfig MANAGEMENT_API_SERVER_KUBECONFIG get subnet -n platform  -l \
    ipam.gdc.goog/vpc=default-vpc,ipam.gdc.goog/usage!=zone-network-root-range

La sortie ressemble à ceci :

Example:
default-vpc-default-node-subnet       {"name":"default-vpc-zone0-cidr","namespace":"platform"}   True    198.51.100.0/23
g-org-1-shared-service-pod-cidr       {"name":"default-vpc-zone0-cidr","namespace":"platform"}   True    198.51.16.0/20
g-org-1-shared-service-service-cidr   {"name":"default-vpc-zone0-cidr","namespace":"platform"}   True    198.51.2.0/23
user-vm-1-pod-cidr                    {"name":"default-vpc-zone0-cidr","namespace":"platform"}   True    198.51.8.0/21
user-vm-1-service-cidr                {"name":"default-vpc-zone0-cidr","namespace":"platform"}   True    198.51.4.0/23
user-vm-2-pod-cidr                    {"name":"default-vpc-zone0-cidr","namespace":"platform"}   True    198.51.32.0/21
user-vm-2-service-cidr                {"name":"default-vpc-zone0-cidr","namespace":"platform"}   True    198.51.6.0/23

Dans cet exemple, un CIDR parent /18 a alloué quatre CIDR /23, un CIDR /20 et deux CIDR /21. Le nouveau cluster d'utilisateur demande un CIDR /20 pour podCIDRSize et un CIDR /20 pour serviceCIDRSize, ce qui est insuffisant.

Dans ce cas, vous devez ajouter des sous-réseaux pour une catégorie pour le VPC par défaut.

VPC d'infrastructure

Les sous-réseaux de infra-vpc sont principalement utilisés pour allouer les CIDR de pod et de service d'une organisation pour le cluster d'infrastructure et le cluster de périmètre, ainsi que l'adresse IP du nœud pour le cluster de périmètre.

Comme cela appartient à la configuration de l'infrastructure GDC interne, et que chaque organisation ne dispose que d'un seul cluster d'infrastructure d'organisation et d'un seul cluster de périmètre, les opérations de mise à l'échelle ne sont généralement pas nécessaires pour infra-vpc.

Segment de réseau administrateur

Les sous-réseaux du segment de réseau d'administration sont principalement utilisés pour allouer des adresses IP dans le routage et le transfert virtuels (VRF) de l'administrateur de l'organisation. Un sous-réseau de nœuds par défaut ou un sous-réseau avec des informations de passerelle est créé dans l'organisation. Ce sous-réseau par défaut alloue l'adresse IP du nœud de cluster d'infrastructure de l'organisation et l'adresse IP du nœud de cluster de périmètre.

Étant donné que le segment de réseau d'administration appartient à la configuration de l'infrastructure GDC interne, et que chaque organisation ne peut avoir qu'un seul cluster d'infrastructure d'organisation et un seul cluster de périmètre, ce sous-réseau n'aura généralement pas besoin d'être mis à l'échelle.

Segment de réseau de données

Les sous-réseaux du segment de réseau de données sont principalement utilisés pour allouer des adresses IP dans le VRF de données de l'organisation. Un sous-réseau de nœuds par défaut ou un sous-réseau avec des informations de passerelle est créé dans l'organisation. Ce sous-réseau par défaut attribue les adresses IP des nœuds du cluster d'infrastructure de l'organisation et du cluster de périmètre.

Étant donné que le segment de réseau de données appartient à la configuration de l'infrastructure GDC interne, et que chaque organisation ne peut avoir qu'un seul cluster d'infrastructure d'organisation et un seul cluster de périmètre, ce sous-réseau n'aura généralement pas besoin d'être mis à l'échelle.

Ajouter des sous-réseaux à une catégorie

Vous pouvez ajouter d'autres sous-réseaux pour une catégorie en fonction du type de sous-réseau. Les types suivants sont éligibles à l'ajout de sous-réseaux :

VPC d'infrastructure
Segment de réseau administrateur
Segment de réseau de données
VPC par défaut

Déterminez le type de sous-réseau pour lequel vous souhaitez ajouter des sous-réseaux, puis suivez les étapes ci-dessous pour ce type de sous-réseau :

Dans le serveur d'API d'administrateur racine global, obtenez le type de sous-réseau racine et vérifiez son champ CIDR maskSize à partir de subnet.status.ipv4Allocation.cidr :
```
kubectl --kubeconfig GLOBAL_ROOT_ADMIN_KUBECONFIG get subnet -n ORG_NAME \
    -l ipam.gdc.goog/SUBNET_TYPE,ipam.gdc.goog/usage=network-root-range
```
Remplacez les éléments suivants :
- GLOBAL_ROOT_ADMIN_KUBECONFIG : chemin d'accès au fichier kubeconfig du cluster d'administrateur racine.
- ORG_NAME : nom de l'organisation.
- SUBNET_TYPE : type de sous-réseau, tel que vpc=infra-vpc, network-segment=admin, network-segment=data ou vpc=default-vpc.
Notez cette valeur comme étant le CIDR total, qui sera référencé ultérieurement.
Récupérez tous les sous-réseaux enfants du sous-réseau racine et vérifiez chaque champ CIDR maskSize à partir de subnet.status.ipv4Allocation.cidr :
```
kubectl --kubeconfig GLOBAL_ROOT_ADMIN_KUBECONFIG get subnet -n ORG_NAME \
    -l ipam.gdc.goog/SUBNET_TYPE,ipam.gdc.goog/usage!=network-root-range
```
Notez chaque valeur en tant que CIDR utilisé, qui sera référencé ultérieurement.
Calculez le CIDR disponible du sous-réseau en fonction du CIDR total et du CIDR utilisé. Si le CIDR disponible n'est pas assez grand pour allouer le nouveau sous-réseau, ajoutez un nouveau sous-réseau global de plage racine réseau. Passez ensuite à l'étape suivante.
Créez le sous-réseau dans le serveur d'API d'administrateur racine global :
```
kubectl --kubeconfig GLOBAL_ROOT_ADMIN_KUBECONFIG apply -f - <<EOF
apiVersion: ipam.global.gdc.goog/v1
kind: Subnet
metadata:
  labels:
    ipam.gdc.goog/SUBNET_TYPE_LABEL
    ipam.gdc.goog/usage: zone-network-root-range
  annotations:
    ipam.gdc.goog/pivot-destination: global-org
  name: SUBNET_NAME
  namespace: ORG_NAME
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_ROOT_ADMIN_KUBECONFIG : chemin d'accès au fichier kubeconfig du cluster d'administrateur racine.
- SUBNET_TYPE_LABEL : type de sous-réseau, qui doit correspondre à l'une des valeurs suivantes : vpc: infra-vpc, network-segment: admin, network-segment: data ou vpc: default-vpc.
- SUBNET_NAME : nom du nouveau sous-réseau.
- ORG_NAME : nom de l'organisation.
- CIDR_PREFIX_LENGTH : longueur de préfixe du nouveau sous-réseau, par exemple 20.
- ZONE_NAME : nom de la zone du sous-réseau, tel que zone1.
- PARENT_SUBNET_NAME : nom du sous-réseau parent, tel que infra-vpc-root-cidr, admin-external-root-cidr, data-external-root-cidr ou default-vpc-root-cidr.
Vérifiez que le sous-réseau est prêt en vérifiant que son type d'état Ready est true.
Vérifiez qu'un sous-réseau mondial est créé dans le serveur d'API mondial de l'organisation et qu'il est prêt :
```
kubectl --kubeconfig GLOBAL_ORG_ADMIN_KUBECONFIG get subnet -n NAMESPACE -l \
    ipam.gdc.goog/SUBNET_TYPE,ipam.gdc.goog/usage=zone-network-root-range
```
Remplacez NAMESPACE par l'espace de noms du sous-réseau. Utilisez infra-network pour le sous-réseau infra-vpc et platform pour les autres types de sous-réseaux.

Vérifiez que le sous-réseau zonal est créé dans l'espace de noms de l'organisation du cluster d'administrateur racine et qu'il est prêt :

kubectl --kubeconfig ROOT_ADMIN_KUBECONFIG get subnet -n ORG_NAME \
    -l ipam.gdc.goog/SUBNET_TYPE,ipam.gdc.goog/usage=zone-network-root-range

Vérifiez que le sous-réseau zonal est créé dans le serveur de l'API Management dans l'espace de noms platform et qu'il est prêt :

kubectl --kubeconfig MANAGEMENT_API_SERVER_KUBECONFIG get subnet -n NAMESPACE \
    -l ipam.gdc.goog/SUBNET_TYPE,ipam.gdc.goog/usage=zone-network-root-range

La mise à niveau du sous-réseau pour votre organisation dans la zone que vous avez spécifiée est terminée. Vos administrateurs peuvent créer d'autres sous-réseaux enfants à partir du nouveau sous-réseau.

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 de cette catégorie. Si elle est épuisée, vous devez créer un sous-réseau network-root-range dans le serveur d'API global. Si nécessaire, vous pouvez créer plusieurs sous-réseaux racine mondiaux.

Pour créer un sous-réseau network-root-range, procédez comme suit :

Créez un fichier YAML, tel que subnet-network-root.yaml, pour le nouveau sous-réseau global de plage racine de votre réseau :
```
apiVersion: ipam.global.gdc.goog/v1
kind: Subnet
metadata:
  labels:
    ipam.gdc.goog/SUBNET_TYPE
    ipam.gdc.goog/usage: network-root-range
  annotations:
    ipam.gdc.goog/pivot-destination: global-org
  name: SUBNET_NAME
  namespace: ORG_NAME
spec:
  ipv4Request:
    cidr: NEW_CIDR
  type: Root
```
Remplacez les éléments suivants :
- SUBNET_TYPE : type de sous-réseau, qui doit correspondre à l'une des valeurs suivantes : vpc: infra-vpc, network-segment: admin, network-segment: data ou vpc: default-vpc.
- API_SERVER_ANNOTATION : annotation permettant d'identifier que ce sous-réseau doit pivoter vers un autre serveur d'API. Pour infra-vpc ou les segments de réseau admin et datanet, utilisez ipam.gdc.goog/pivot-destination: global-org. Si vous ajoutez une plage racine default-vpc, ne définissez pas cette annotation.
- SUBNET_NAME : nom du nouveau sous-réseau.
- ORG_NAME : nom de l'organisation.
- 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 d'administrateur racine global.