Configuration de sous-réseaux VPC

Cloud privé virtuel

Vous pouvez modifier le pool d'adresses IP publiques ou privées portables en ajoutant des sous-réseaux à votre cluster de VPC Red Hat® OpenShift® on IBM Cloud®.

Le contenu de cette page est spécifique aux clusters VPC. Pour plus d'informations sur les clusters classiques, voir Configuration des sous-réseaux et des adresses IP pour les clusters classiques.

Présentation de la mise en réseau VPC dans Red Hat OpenShift on IBM Cloud

Familiarisez-vous avec les concepts de base de la mise en réseau VPC dans les clusters Red Hat OpenShift on IBM Cloud.

Sous-réseaux

Avant de créer un cluster VPC pour la première fois, vous devez créer un sous-réseau VPC dans chaque zone où vous souhaitez déployer des nœuds de travail. Un sous-réseau VPC correspond à une plage d'adresses IP privées spécifique (bloc CIDR) et configure un groupe de noeuds worker et de pods comme s'ils étaient reliés physiquement au même câble.

Lorsque vous créez un cluster, vous pouvez spécifier un seul sous-réseau VPC existant pour chaque zone. Chaque noeud worker que vous ajoutez dans un cluster est déployé avec une adresse IP privée issue du sous-réseau VPC dans cette zone. Une fois le noeud worker mis à disposition, l'adresse IP de noeud worker est conservée après une opération reboot, mais l'adresse IP de noeud worker est modifiée après des opérations replace et update.

Ne supprimez pas les sous-réseaux que vous associez à votre cluster lors de la création du cluster ou lorsque vous ajoutez des noeuds worker dans une zone. Si vous supprimez un sous-réseau VPC que votre cluster a utilisé, des problèmes peuvent se produire au niveau des équilibreurs de charge qui utilisent des adresses IP à partir du sous-réseau et il se peut que vous ne puissiez pas créer de nouveaux équilibreurs de charge.

De combien d'adresses IP ai-je besoin pour mon sous-réseau VPC?

Lorsque vous créez votre sous-réseau VPC, veillez à créer un sous-réseau disposant d'un nombre suffisant d'adresses IP pour votre cluster, par exemple 256. Vous ne pouvez pas modifier le nombre d'adresses IP qu'un sous-réseau VPC a plus tard.

Gardez à l'esprit les réservations d'adresse IP suivantes :

Par défaut, 5 adresses IP sont réservées par VPC à partir de chaque sous-réseau.
Une adresse IP provenant d'un sous-réseau de chaque zone dans laquelle votre cluster dispose de nœuds de travail est requise pour la passerelle des points de terminaison privés virtuels(VPE).
1 adresse IP est requise par noeud worker dans votre cluster.
1 adresse IP est requise à chaque fois que vous mettez à jour ou remplacez un noeud worker. Ces adresses IP sont finalement récupérées et disponibles pour être réutilisées.
2 adresses IP sont utilisées à chaque fois que vous créez un équilibreur de charge public ou privé. Si vous disposez d'un cluster multizone, ces 2 adresses IP sont réparties entre les zones, par conséquent, il se peut qu'aucun adresse IP ne soit réservée pour le sous-réseau.
D'autres ressources de mise en réseau que vous avez configurées pour le cluster, telles qu'une mise à l'échelle automatique VPNaaS ou LBaaS, peuvent nécessiter des adresses IP supplémentaires ou être soumises à d'autres limitations de service. Par exemple, la mise à l'échelle automatique LBaaS peut nécessiter jusqu'à 16 adresses IP par équilibreur de charge.

Quelles plages d'adresses IP puis-je utiliser pour les sous-réseaux de mon VPC?

La plage d'adresses IP par défaut des sous-réseaux VPC est 10.0.0.0 - 10.255.255.255. Pour obtenir la liste des plages d'adresses IP par zone VPC, voir Préfixes d'adresse par défaut VPC.

Si vous devez créer votre cluster à l'aide des sous-réseaux d'une plage personnalisée, voir la rubrique relative aux préfixes d'adresse personnalisés. Toutefois, si vous utilisez des sous-réseaux personnalisés pour vos nœuds worker, vous devez vous assurer que la plage d'adresses IP des sous-réseaux de nœuds worker ne se chevauchent pas avec le sous-réseau de pods de votre cluster.

Si vous avez défini votre propre sous-réseau de pods dans l'option « --pod-subnet » lors de la création du cluster, vos pods se voient attribuer des adresses IP issues de cette plage.
Si vous n'avez pas spécifié de sous-réseau de pod personnalisé lors de la création du cluster, celui-ci utilise le sous-réseau de pod par défaut. Dans le premier cluster que vous créez dans un VPC, le sous-réseau de pod par défaut est 172.17.0.0/18. Dans le deuxième cluster que vous créez dans ce VPC, le sous-réseau de pod par défaut est 172.17.64.0/18. Dans chaque cluster suivant, la plage de sous-réseaux de pod correspond au prochain sous-réseau /18 non superposé disponible.

Comment créer des sous-réseaux pour l'accès à l'infrastructure classique?

Si vous activez l'accès classique lorsque vous créez votre VPC, des préfixes d'adresse par défaut d'accès classique déterminent automatiquement les plages d'adresses IP de tous les sous-réseaux que vous créez. Cependant, les plages d'adresses IP par défaut des sous-réseaux VPC d'accès classique entrent en conflit avec les sous-réseaux du plan de contrôle Red Hat OpenShift on IBM Cloud. Vous devez plutôt créer le VPC sans les préfixes d'adresse par défaut automatiques, puis créer vos propres préfixes d'adresse et sous-réseaux dans ces plages pour votre cluster.

Puis-je définir des sous-réseaux pour les pods et les services de mon cluster?

Si vous prévoyez de connecter votre cluster à des réseaux sur site via IBM Cloud Direct Link ou un service VPN, vous pouvez éviter les conflits de sous-réseau en spécifiant un routage CIDR de sous-réseau personnalisé qui fournit les adresses IP privées pour vos pods, et un routage CIDR de sous-réseau personnalisé qui fournit les adresses IP privées pour les services.

Pour définir des sous-réseaux personnalisés pour les pods et les services lors de la création d'un cluster, utilisez les options --pod-subnet et --service-subnet dans la commande CLI ibmcloud oc cluster create .

Pour afficher les sous-réseaux de pod et de service que votre cluster utilise, recherchez les zones Pod Subnet et Service Subnet dans la sortie de la commande ibmcloud oc cluster get.

Pods

Plage par défaut

Dans le premier cluster que vous créez dans un VPC, le sous-réseau de pod par défaut est 172.17.0.0/18. Dans le deuxième cluster que vous créez dans ce VPC, le sous-réseau de pod par défaut est 172.17.64.0/18. Dans chaque cluster suivant, la plage de sous-réseaux de pod correspond au prochain sous-réseau /18 non superposé disponible.

Taille requise

Lorsque vous spécifiez un sous-réseau personnalisé, pensez à la taille du cluster que vous prévoyez de créer et au nombre de nœuds worker que vous pouvez ajouter à l'avenir. Le sous-réseau doit avoir un routage CIDR d'au moins /23, ce qui fournit suffisamment d'adresses IP de pod pour un maximum de quatre noeuds worker dans un cluster. Pour des clusters plus volumineux, utilisez /22 afin d'avoir suffisamment d'adresses IP de pod pour huit noeuds worker. Utilisez /21 pour avoir suffisamment d'adresses IP de pod pour 16 noeuds worker, etc.

Pour les clusters de VPC, vous pouvez spécifier la taille de sous-réseau en l'incluant dans l'option --pod-subnet. Par exemple: --pod-subnet 0.0.0.0/X où X est la taille de sous-réseau de pod requise. Ensuite, le sous-réseau de pod est automatiquement sélectionné. Lors de l'attribution automatique du sous-réseau du pod, l'attribution commencera à partir de 172.17.0.0, le sous-réseau maximal est limité à 13, et la taille minimale du sous-réseau est limitée à 23.

Il existe une limite globale pour les nœuds de travail. Vous ne pouvez pas dépasser 500 nœuds de travail sur l'ensemble des clusters d'une région.

Exigences de plage

Les sous-réseaux de pod et de service ne peuvent pas se chevaucher les uns les autres, et le sous-réseau pod ne peut pas chevaucher les sous-réseaux VPC de vos nœuds worker. Le sous-réseau que vous choisissez doit se trouver dans l'une des plages ci-après.

172.17.0.0 - 172.17.255.255
172.21.0.0 - 172.31.255.255
192.168.0.0 - 192.168.254.255
198.18.0.0 - 198.19.255.255

services

Plage par défaut

Tous les services déployés sur le cluster reçoivent par défaut une adresse IP privée dans la plage 172.21.0.0/16.

Taille requise

Lorsque vous spécifiez un sous-réseau personnalisé, le sous-réseau doit être spécifié au format CIDR avec une taille au moins /24, ce qui permet un maximum de 255 services dans le cluster ou plus.

Exigences de plage

Les sous-réseaux de pod et de service ne peuvent pas se chevaucher. Le sous-réseau que vous choisissez doit se trouver dans l'une des plages ci-après.

172.17.0.0 - 172.17.255.255
172.21.0.0 - 172.31.255.255
192.168.0.0 - 192.168.254.255
198.18.0.0 - 198.19.255.255

Passerelles publiques

Une passerelle publique active un sous-réseau et tous les noeuds worker rattachés au sous-réseau pour établir des connexions sortantes sur Internet. Si les noeuds finaux de service cloud publics et privés sont activés pour votre cluster, vous devez activer une passerelle publique sur les sous-réseaux VPC sur lesquels les noeuds worker sont déployés pour accéder aux composants Red Hat OpenShift par défaut sans être connecté au réseau privé de votre VPC.

Lorsque vous créez un cluster de VPC et activez les noeuds finaux de service cloud public et privé lors de la création du cluster, le noeud final de service cloud public est utilisé par défaut pour accéder aux composants tels que la console Web Red Hat OpenShift de votre cluster. Pour que les pods de la console puissent établir une connexion publique sécurisée sur Internet via le noeud final de service public, vous devez activer une passerelle publique sur chaque sous-réseau VPC sur lequel vos noeuds worker sont déployés.

Lorsque vous créez un cluster de VPC et n'activez que le noeud final de service cloud privé lors de la création du cluster, le noeud final de service cloud privé est utilisé par défaut pour accéder aux composants Red Hat OpenShift tels que la console Web Red Hat OpenShift ou OperatorHub. Vous devez être connecté au réseau VPC privé (par exemple, via une connexion VPN) pour accéder à ces composants ou exécuter des commandes kubectl sur votre cluster. En outre, si un service IBM Cloud ne prend pas en charge des noeuds finaux de service cloud privés, vos noeuds worker doivent être connectés à un sous-réseau auquel une passerelle publique est connectée. Les pods sur ces noeuds worker peuvent communiquer de manière sécurisée avec les services sur le réseau public via la passerelle publique du sous-réseau. Notez qu'une passerelle publique n'est pas requise sur vos sous-réseaux pour autoriser le trafic réseau entrant à partir d'Internet vers les services LoadBalancer ou les équilibreurs de charge d'application.

Dans un VPC, vous ne pouvez créer qu'une seule passerelle publique par zone, mais cette passerelle publique peut être connectée à plusieurs sous-réseaux dans la zone. Pour plus d'informations sur les passerelles publiques, voir A propos de la mise en réseau pour VPC.

Noeuds finaux privés virtuels (VPE)

Consultez la section Comprendre la mise en réseau sécurisée par défaut des clusters VPC pour obtenir des informations sur les VPE.

Segmentation du réseau

La segmentation du réseau décrit l'approche utilisée pour diviser un réseau en plusieurs sous-réseaux. Les applications qui s'exécutent dans un sous-réseau ne peuvent pas voir ou accéder à des applications dans un autre sous-réseau. Pour plus d'informations sur les options de segmentation du réseau, voir cette rubrique sur la sécurité des clusters.

Les sous-réseaux fournissent un canal pour établir la connectivité entre les noeuds worker au sein du cluster. De plus, tout système connecté à l'un des sous-réseaux privés du même VPC peut communiquer avec les noeuds worker. Par exemple, tous les sous-réseaux d'un VPC peuvent communiquer via un routage de couche 3 privé avec un routeur VPC intégré.

Si vous possédez plusieurs clusters qui doivent communiquer entre eux, vous pouvez créer les clusters dans le même VPC. Cependant, si vos clusters n'ont pas besoin de communiquer, vous pouvez réaliser une meilleure segmentation du réseau en créant des clusters dans des VPC distincts. Vous pouvez également créer des listes de contrôle d'accès (ACL) pour vos sous-réseaux VPC pour effectuer une médiation du trafic sur le réseau privé. Les ACL sont constituées de règles entrantes et sortantes qui définissent les entrées et les sorties autorisées pour chaque sous-réseau VPC.

Limitations des réseaux VPC

Lorsque vous créez des sous-réseaux VPC pour vos clusters, gardez à l'esprit les fonctions et limitations décrites ci-après.

La taille de routage CIDR par défaut de chaque sous-réseau VPC est /24, qui peut prendre en charge jusqu'à 253 noeuds worker. Si vous prévoyez de déployer plus de 250 noeuds worker par zone dans un cluster, pensez à créer un sous-réseau plus grand.
Une fois que vous avez créé un sous-réseau VPC, vous ne pouvez pas le redimensionner ou modifier sa plage d'adresses IP.
Plusieurs clusters compris dans le même VPC peuvent partager des sous-réseaux VPC. Toutefois, les sous-réseaux de service et de service personnalisés ne peuvent pas être partagés entre plusieurs clusters.
Les sous-réseaux VPC sont associés à une région à zone unique et ne peuvent pas s'étendre sur plusieurs zones ou régions.
Après avoir créé un sous-réseau, vous ne pouvez pas le déplacer vers une autre zone, région ou VPC.
Si des nœuds worker sont connectés à un sous-réseau existant dans une zone, vous ne pouvez pas modifier le sous-réseau de cette zone dans le cluster.
Les plages 172.16.0.0/16, 172.18.0.0/16, 172.19.0.0/16 et 172.20.0.0/16 sont interdites.
Dans un VPC, vous ne pouvez créer qu'une seule passerelle publique par zone, mais cette passerelle publique peut être connectée à plusieurs sous-réseaux dans la zone.
Les préfixes d'adresse par défaut d'accès classique sont en conflit avec les sous-réseaux du plan de contrôle Red Hat OpenShift on IBM Cloud. Vous devez créer le VPC sans les préfixes d'adresse par défaut automatiques, puis créer vos propres préfixes d'adresse et sous-réseaux dans ces plages pour votre cluster.

Création d'un sous-réseau VPC et connexion d'une passerelle publique

Créez un sous-réseau VPC pour votre cluster et connectez éventuellement une passerelle publique à ce sous-réseau.

Création d'un sous-réseau VPC dans la console

Utilisez la console IBM Cloud pour créer un sous-réseau VPC pour votre cluster et connecter éventuellement une passerelle publique à ce sous-réseau.

Dans le tableau de bord du sous-réseau VPC, cliquez sur Créer.
Entrez un nom pour votre sous-réseau et sélectionnez le nom du VPC que vous avez créé.
Sélectionnez l'emplacement et la zone où vous souhaitez créer le sous-réseau.
Indiquez le nombre d'adresses IP à créer.
- Les sous-réseaux VPC fournissent des adresses IP pour vos noeuds worker et des services d'équilibreur de charge dans le cluster, par conséquent, créez un sous-réseau VPC avec suffisamment d'adresses IP, par exemple 256. Vous ne pouvez pas modifier le nombre d'IP qu'un sous-réseau VPC a plus tard.
- Si vous entrez une plage d'adresses IP, n'utilisez pas les plages réservées suivantes : 172.16.0.0/16, 172.18.0.0/16, 172.19.0.0/16et 172.20.0.0/16.
Pour exécuter des composants Red Hat OpenShift par défaut, tels que la console Web ou OperatorHub, et pour autoriser votre cluster à accéder à des noeuds finaux publics, tels qu'une adresse URL publique d'une autre application ou un service IBM Cloud qui prend uniquement en charge les noeuds finaux de service cloud publics, vous devez connecter une passerelle publique à votre sous-réseau.
Cliquez sur Créer un sous-réseau.
Utilisez le sous-réseau pour Créer un cluster, Créer un nouveau pool worker ou Ajouter le sous-réseau à un pool de travailleurs existant.> Ne supprimez pas les sous-réseaux que vous associez à votre cluster lors de la création du cluster ou lorsque vous ajoutez des noeuds worker dans une zone. Si vous supprimez un sous-réseau VPC que votre cluster a utilisé, des problèmes peuvent se produire au niveau des équilibreurs de charge qui utilisent des adresses IP à partir du sous-réseau et il se peut que vous ne puissiez pas créer de nouveaux équilibreurs de charge.

Création d'un sous-réseau VPC dans l'interface CLI

Utilisez l'interface de ligne de commande IBM Cloud pour créer un sous-réseau VPC pour votre cluster et connecter éventuellement une passerelle publique à ce sous-réseau.

Avant de commencer

A partir de votre ligne de commande, connectez-vous à votre compte IBM Cloud et ciblez la région et le groupe de ressources IBM Cloud dans lesquels vous souhaitez créer votre cluster de VPC. Pour connaître les régions prises en charge, voir Création d'un VPC dans une autre région. Le groupe de ressources du cluster peut être différent du groupe de ressources VPC. A l'invite, entrez vos données d'identification IBM Cloud. Si vous disposez d'un identifiant fédéré, utilisez l'option « --sso » pour vous connecter.
```
ibmcloud login -r REGION [-g <resource_group>] [--sso]
```
Créez un VPC dans la même région que celle où vous souhaitez créer le cluster.

Pour créer un sous-réseau VPC, procédez comme suit.

Obtenez l'ID de VPC dans lequel vous souhaitez créer le sous-réseau.
```
ibmcloud oc vpcs
```
Créez le sous-réseau. Pour plus d'informations sur les options de cette commande, reportez-vous aux informations de référence de l'interface de ligne de commande.
```
ibmcloud is subnet-create SUBNET_NAME VPC_ID --zone VPC_ZONE --ipv4-address-count NUMBER_OF_IP_ADDRESS
```
- Les sous-réseaux VPC fournissent des adresses IP pour vos noeuds worker et des services d'équilibreur de charge dans le cluster, par conséquent, créez un sous-réseau VPC avec suffisamment d'adresses IP, par exemple 256. Vous ne pouvez pas modifier le nombre d'IP qu'un sous-réseau VPC a plus tard.
- N'utilisez pas les plages réservées suivantes : 172.16.0.0/16, 172.18.0.0/16, 172.19.0.0/16 et 172.20.0.0/16.

Vérifiez si une passerelle publique existe dans les zones où vous souhaitez créer un cluster. Dans un VPC, vous ne pouvez créer qu'une seule passerelle publique par zone, mais cette passerelle publique peut être connectée à plusieurs sous-réseaux dans la zone.

ibmcloud is public-gateways

Exemple de sortie

ID                                     Name                                       VPC                          Zone         Floating IP                  Created                     Status      Resource group
26426426-6065-4716-a90b-ac7ed7917c63   test-pgw                                   testvpc(36c8f522-.)          us-south-1   169.xx.xxx.xxx(26466378-.)   2019-09-20T16:27:32-05:00   available   -
2ba2ba2b-fffa-4b0c-bdca-7970f09f9b8a   pgw-73b62bc0-b53a-11e9-9838-f3f4efa02374   team3(ff537d43-.)            us-south-2   169.xx.xxx.xxx(2ba9a280-.)   2019-08-02T10:30:29-05:00   available   -

S'il existe déjà une passerelle publique dans chaque zone, notez les ID des passerelles publiques.
Si vous n'avez pas de passerelle publique dans chaque zone, créez une passerelle publique. Envisagez de nommer la passerelle publique au format <cluster>-<zone>-gateway. Dans la sortie, notez l'ID de la passerelle publique.

ibmcloud is public-gateway-create <gateway_name> <VPC_ID> <zone>

Exemple de sortie

ID               26466378-6065-4716-a90b-ac7ed7917c63
Name             mycluster-us-south-1-gateway
Floating IP      169.xx.xx.xxx(26466378-6065-4716-a90b-ac7ed7917c63)
Status           pending
Created          2019-09-20T16:27:32-05:00
Zone             us-south-1
VPC              myvpc(36c8f522-4f0d-400c-8226-299f0b8198cf)
Resource group   -

En utilisant les ID de la passerelle publique et du sous-réseau, connectez la passerelle publique au sous-réseau.

ibmcloud is subnet-update <subnet_ID> --public-gateway-id <gateway_ID>

Exemple de sortie

ID                  91e946b4-7094-46d0-9223-5c2dea2e5023
Name                mysubnet1
IPv4 CIDR           10.240.xx.xx/24
Address available   250
Address total       256
ACL                 allow-all-network-acl-36c8f522-4f0d-400c-8226-299f0b8198cf(585bc142-5392-45d4-afdd-d9b59ef2d906)
Gateway             mycluster-us-south-1-gateway(26466378-6065-4716-a90b-ac7ed7917c63)
Created             2019-08-21T09:43:11-05:00
Status              available
Zone                us-south-1
VPC                 myvpc(36c8f522-4f0d-400c-8226-299f0b8198cf)

Utilisez le sous-réseau pour créer un cluster, créer un nouveau pool de noeuds worker ou ajouter le sous-réseau à un pool de noeuds worker existant. Ne supprimez pas les sous-réseaux que vous associez à votre cluster lors de la création du cluster ou lorsque vous ajoutez des noeuds worker dans une zone. Si vous supprimez un sous-réseau VPC que votre cluster a utilisé, des problèmes peuvent se produire au niveau des équilibreurs de charge qui utilisent des adresses IP à partir du sous-réseau et il se peut que vous ne puissiez pas créer de nouveaux équilibreurs de charge.

Création de sous-réseaux VPC pour un accès classique

Si vous activez l'accès classique lorsque vous créez votre VPC, des préfixes d'adresse par défaut d'accès classique déterminent automatiquement les plages d'adresses IP de tous les sous-réseaux que vous créez. Cependant, les plages d'adresses IP par défaut des sous-réseaux VPC d'accès classique entrent en conflit avec les sous-réseaux du plan de contrôle Red Hat OpenShift on IBM Cloud. Vous devez donc plutôt créer le VPC sans les préfixes d'adresse par défaut automatique et créer vos propres préfixes d'adresse. Ensuite, chaque fois que vous créez des sous-réseaux pour votre cluster, vous créez les sous-réseaux dans les plages de préfixes d'adresse que vous avez créées.

Création de sous-réseaux VPC pour un accès classique dans la console

Créez un VPC à accès classique sans préfixes d'adresse par défaut.
1. Dans le tableau de bord des clouds privés virtuels (VPC), cliquez sur Créer.
2. Indiquez le nom, le groupe de ressources et les balises.
3. Cochez la case Activer l'accès aux ressources classiques et désélectionnez la case Créer un préfixe par défaut pour chaque zone.
4. Sélectionnez la région pour le VPC.
5. Cliquez sur Nouveau cloud privé virtuel.
Créez des préfixes d'adresse dans chaque zone.
1. Cliquez sur le nom de votre PC pour afficher ses détails.
2. Cliquez sur l'onglet Préfixes d'adresse, puis sur Créer.
3. Pour chaque zone dans laquelle vous prévoyez de créer des sous-réseaux, créez un ou plusieurs préfixes d'adresse. Les préfixes d'adresse doivent être dans l'une des plages suivantes : 10.0.0.0 - 10.255.255.255, 172.17.0.0 - 172.17.255.255, 172.21.0.0 - 172.31.255.255, 192.168.0.0 - 192.168.254.255.
Créez des sous-réseaux qui utilisent vos préfixes d'adresse.
1. Dans le tableau de bord du sous-réseau VPC, cliquez sur Créer.
2. Entrez un nom pour votre sous-réseau et sélectionnez le nom de votre VPC à accès classique.
3. Sélectionnez l'emplacement et la zone où vous souhaitez créer le sous-réseau.
4. Sélectionnez le préfixe d'adresse que vous avez créé pour cette zone.
5. Indiquez le nombre d'adresses IP à créer. Les sous-réseaux VPC fournissent des adresses IP pour vos noeuds worker et des services d'équilibreur de charge dans le cluster, par conséquent, créez un sous-réseau VPC avec suffisamment d'adresses IP, par exemple 256. Vous ne pouvez pas modifier le nombre d'IP qu'un sous-réseau VPC a plus tard.
6. Pour exécuter des composants Red Hat OpenShift par défaut, tels que la console Web ou OperatorHub, et pour autoriser votre cluster à accéder à des noeuds finaux publics, tels qu'une adresse URL publique d'une autre application ou un service IBM Cloud qui prend uniquement en charge les noeuds finaux de service cloud publics, vous devez connecter une passerelle publique à votre sous-réseau.
7. Cliquez sur Créer un sous-réseau.
Utilisez les sous-réseaux pour créer un cluster. Ne supprimez pas les sous-réseaux que vous associez à votre cluster lors de la création du cluster ou lorsque vous ajoutez des noeuds worker dans une zone. Si vous supprimez un sous-réseau VPC que votre cluster a utilisé, des problèmes peuvent se produire au niveau des équilibreurs de charge qui utilisent des adresses IP à partir du sous-réseau et il se peut que vous ne puissiez pas créer de nouveaux équilibreurs de charge.

Création de sous-réseaux VPC pour un accès classique à partir de l'interface CLI

A partir de votre ligne de commande, connectez-vous à votre compte IBM Cloud et ciblez la région et le groupe de ressources IBM Cloud dans lesquels vous souhaitez créer votre cluster de VPC. Pour connaître les régions prises en charge, voir Création d'un VPC dans une autre région. Le groupe de ressources du cluster peut être différent du groupe de ressources VPC. A l'invite, entrez vos données d'identification IBM Cloud. Si vous disposez d'un identifiant fédéré, utilisez l'option « --sso » pour vous connecter.
```
ibmcloud login -r <region> [-g <resource_group>] [--sso]
```
Créez un VPC à accès classique sans préfixes d'adresse par défaut. Dans la sortie, copiez l'ID du VPC.
```
ibmcloud is vpc-create <name> --classic-access --address-prefix-management manual
```
Pour chaque zone dans laquelle vous prévoyez de créer des sous-réseaux, créez un ou plusieurs préfixes d'adresse. Les préfixes d'adresse doivent être dans l'une des plages suivantes : 10.0.0.0 - 10.255.255.255, 172.17.0.0 - 172.17.255.255, 172.21.0.0 - 172.31.255.255, 192.168.0.0 - 192.168.254.255.
```
ibmcloud is vpc-address-prefix-create <prefix_name> <vpc_id> <zone> <prefix_range>
```
Créez des sous-réseaux dans chaque zone qui utilisent vos préfixes d'adresse. Pour plus d'informations sur les options de cette commande, reportez-vous aux informations de référence de l'interface de ligne de commande. Les sous-réseaux VPC fournissent des adresses IP pour vos noeuds worker et des services d'équilibreur de charge dans le cluster, par conséquent, créez un sous-réseau VPC avec suffisamment d'adresses IP, par exemple 256. Vous ne pouvez pas modifier le nombre d'IP qu'un sous-réseau VPC a plus tard.
```
ibmcloud is subnet-create <subnet_name> <vpc_id> --zone <vpc_zone> --ipv4-address-count <number_of_ip_address> --ipv4-cidr-block <prefix_range>
```

Pour exécuter des composants Red Hat OpenShift par défaut, tels que la console Web ou OperatorHub, et pour autoriser votre cluster à accéder à des noeuds finaux publics, tels qu'une adresse URL publique d'une autre application ou un service IBM Cloud qui prend uniquement en charge les noeuds finaux de service cloud publics, vous devez connecter une passerelle publique à votre sous-réseau.

Créez une passerelle publique dans chaque zone. Envisagez de nommer la passerelle publique au format <cluster>-<zone>-gateway. Dans la sortie, notez l'ID de la passerelle publique.

    ibmcloud is public-gateway-create <gateway_name> <VPC_ID> <zone>
    ```
    Exemple de sortie
    ```sh {: screen}
    ID               26466378-6065-4716-a90b-ac7ed7917c63
    Name             mycluster-us-south-1-gateway
    Floating IP      169.xx.xx.xxx(26466378-6065-4716-a90b-ac7ed7917c63)
    Status           pending
    Created          2019-09-20T16:27:32-05:00
    Zone             us-south-1
    VPC              myvpc(36c8f522-4f0d-400c-8226-299f0b8198cf)
    Resource group   -
    ```
2. En utilisant les ID de la passerelle publique et du sous-réseau, connectez la passerelle publique au sous-réseau.
```sh {: pre}
    ibmcloud is subnet-update <subnet_ID> --public-gateway-id <gateway_ID>
    ```
    Exemple de sortie
    ```sh {: screen}
    ID                  91e946b4-7094-46d0-9223-5c2dea2e5023
    Name                mysubnet1
    IPv4 CIDR           10.240.xx.xx/24
    Address available   250
    Address total       256
    ACL                 allow-all-network-acl-36c8f522-4f0d-400c-8226-299f0b8198cf(585bc142-5392-45d4-afdd-d9b59ef2d906)
    Gateway             mycluster-us-south-1-gateway(26466378-6065-4716-a90b-ac7ed7917c63)
    Created             2019-08-21T09:43:11-05:00
    Status              available
    Zone                us-south-1
    VPC                 myvpc(36c8f522-4f0d-400c-8226-299f0b8198cf)
    ```

Utilisez les sous-réseaux pour créer un cluster. Ne supprimez pas les sous-réseaux que vous associez à votre cluster lors de la création du cluster ou lorsque vous ajoutez des noeuds worker dans une zone. Si vous supprimez un sous-réseau VPC que votre cluster a utilisé, des problèmes peuvent se produire au niveau des équilibreurs de charge qui utilisent des adresses IP à partir du sous-réseau et il se peut que vous ne puissiez pas créer de nouveaux équilibreurs de charge.