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 VPC IBM Cloud® Kubernetes Service.

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 IBM Cloud Kubernetes Service

Familiarisez-vous avec les concepts de base de la mise en réseau VPC dans les clusters IBM Cloud Kubernetes Service.

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 où 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 mes sous-réseaux 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. Le sous-réseau de pod de varie en fonction du sous-réseau que vous avez choisi lors de la création du cluster et du type d'infrastructure de votre cluster :

  • Si vous avez spécifié 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 IBM Cloud Kubernetes Service. 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 spécifier 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 spécifier des sous-réseaux de pods et de services personnalisés lors de la création d'un cluster, utilisez les options --service-subnet --pod-subnet et de la commande CLI ibmcloud ks 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 ks 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.255.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.255.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 vos noeuds worker doivent accéder à un noeud final public en dehors du cluster, vous pouvez activer une passerelle publique sur le sous-réseau VPC sur lequel les noeuds worker sont déployés.

Si un service IBM Cloud ne prend pas en charge des noeuds finaux de service de cloud privé, vos noeuds worker doivent être connectés à un sous-réseau auquel est connectée une passerelle publique. 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 liés à une région multizone à campus 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 IBM Cloud Kubernetes Service. 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.

  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 du VPC que vous avez créé.
  3. Sélectionnez l'emplacement et la zone où vous souhaitez créer le sous-réseau.
  4. 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.
  5. Choisissez si vous souhaitez connecter une passerelle de réseau public à votre sous-réseau. Une passerelle de réseau public est requise lorsque vous souhaitez que votre cluster ait accès à des noeuds finaux publics, tels qu'une URL publique d'une autre application, ou un service IBM Cloud qui prend uniquement en charge les noeuds finaux de service cloud publics.
  6. Cliquez sur Créer un sous-réseau.
  7. 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

  1. 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]
  2. 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.

  1. Obtenez l'ID de VPC dans lequel vous souhaitez créer le sous-réseau.

    ibmcloud ks vpcs

  2. 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.

  3. 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   -

  4. 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)

  5. 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 IBM Cloud Kubernetes Service. 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

  1. 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.
  2. 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 appartenir à 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.255.255.
  3. 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. Choisissez si vous souhaitez connecter une passerelle de réseau public à votre sous-réseau. Une passerelle de réseau public est requise lorsque vous souhaitez que votre cluster ait accès à des noeuds finaux publics, tels qu'une URL publique d'une autre application, ou un service IBM Cloud qui prend uniquement en charge les noeuds finaux de service cloud publics.
    7. Cliquez sur Créer un sous-réseau.
  4. 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

  1. 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]
  2. 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
  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 appartenir à 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.255.255.
    ibmcloud is vpc-address-prefix-create <prefix_name> <vpc_id> <zone> <prefix_range>
  4. 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>
  5. Facultatif : connectez une passerelle de réseau public à votre sous-réseau. Une passerelle de réseau public est requise lorsque vous souhaitez que votre cluster ait accès à des noeuds finaux publics, tels qu'une URL publique d'une autre application, ou un service IBM Cloud qui prend uniquement en charge les noeuds finaux de service cloud publics.
    1. 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)
    ```
  6. 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.

Limitation du trafic de réseau public à un sous-réseau avec une passerelle publique

Améliorez la sécurité de votre cluster IBM Cloud® Kubernetes Service en limitant le nombre de noeuds worker autorisés à disposer d'un accès externe via une passerelle publique de sous-réseau VPC.

Si des pods de vos noeuds worker doivent se connecter à un noeud final externe public, vous pouvez connecter une passerelle publique au sous-réseau sur lequel se trouvent ces noeuds worker. Par exemple, votre cluster VPC peut se connecter automatiquement à d'autres services IBM Cloud qui prennent en charge des noeuds finaux de service de cloud privé, par exemple, IBM Cloud Container Registry. Toutefois, si vous devez accéder à des services IBM Cloud qui prennent en charge uniquement les noeuds finaux de service cloud publics, vous pouvez connecter une passerelle publique au sous-réseau afin que vos pods puissent envoyer des demandes via le réseau public.

Vous pouvez isoler ce trafic réseau dans votre cluster en connectant une passerelle publique à un seul sous-réseau de votre cluster. Ensuite, vous pouvez utiliser l'affinité d'application pour déployer des pods d'application nécessitant un accès aux noeuds finaux externes uniquement sur le sous-réseau doté d'une passerelle publique connectée.

Dans les clusters VPC, un sous-réseau est limité à une zone. Lorsque vous connectez une passerelle publique à un seul sous-réseau et que vous planifiez des pods d'application nécessitant un accès public uniquement aux noeuds worker de ce sous-réseau, ces pods sont isolés dans une zone de votre cluster.

  1. Ciblez la région du VPC dans lequel votre cluster est déployé.

    ibmcloud target -r <region>

  2. Vérifiez si une passerelle publique existe dans une zone où se trouvent des noeuds worker. 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 une zone où figurent des noeuds worker et dans le VPC dans lequel se trouve votre cluster, notez l'ID de la passerelle.
    • Si vous ne diposez pas de passerelle publique dans une zone où se trouvent des workers et dans le VPC où se trouve votre, 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

    ```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   -
    ```

  3. Répertoriez les noeuds worker présents dans votre cluster. Pour la zone dans laquelle vous avez activé la passerelle publique, notez l'adresse IP principale (Primary IP) d'un noeud worker.

    ibmcloud ks worker ls -c <cluster_name_or_ID>

    Exemple de sortie

    ID                                                   Primary IP     Flavor   State    Status   Zone         Version
kube-bl25g33d0if1cmfn0p8g-vpctest-default-000005ac   10.240.02.00   c2.2x4   normal   Ready    us-south-2   1.35.7
kube-bl25g33d0if1cmfn0p8g-vpctest-default-00000623   10.240.01.00   c2.2x4   normal   Ready    us-south-1   1.35.7

  4. Décrivez le noeud worker. Dans la sortie Labels, notez l'ID de sous-réseau du libellé ibm-cloud.kubernetes.io/subnet-id, comme 5f5787a4-f560-471b-b6ce-20067ac93439 dans l'exemple suivant :

    kubectl describe node <worker_primary_ip>

    Exemple de sortie

    NAME:               10.240.01.00
Roles:              <none>
Labels:             arch=amd64
beta.kubernetes.io/arch=amd64
beta.kubernetes.io/instance-type=c2.2x4
beta.kubernetes.io/os=linux
failure-domain.beta.kubernetes.io/region=us-south
failure-domain.beta.kubernetes.io/zone=us-south-1
ibm-cloud.kubernetes.io/ha-worker=true
ibm-cloud.kubernetes.io/iaas-provider=gc
ibm-cloud.kubernetes.io/internal-ip=10.240.0.77
ibm-cloud.kubernetes.io/machine-type=c2.2x4
ibm-cloud.kubernetes.io/os=UBUNTU_20_64
ibm-cloud.kubernetes.io/region=us-south
ibm-cloud.kubernetes.io/sgx-enabled=false
ibm-cloud.kubernetes.io/subnet-id=5f5787a4-f560-471b-b6ce-20067ac93439
ibm-cloud.kubernetes.io/worker-id=kube-bl25g33d0if1cmfn0p8g-vpcprod-default-00001093
ibm-cloud.kubernetes.io/worker-pool-id=bl25g33d0if1cmfn0p8g-5aa474f
ibm-cloud.kubernetes.io/worker-pool-name=default
ibm-cloud.kubernetes.io/worker-version=1.15.3_1517
ibm-cloud.kubernetes.io/zone=us-south-1
kubernetes.io/arch=amd64
kubernetes.io/hostname=10.240.0.77
kubernetes.io/os=linux
Annotations:        node.alpha.kubernetes.io/ttl: 0
...

  5. En utilisant les ID de la passerelle publique et du sous-réseau, connectez la passerelle publique au sous-réseau. Les noeuds worker qui sont déployés sur ce sous-réseau dans cette zone ont désormais accès à des noeuds finaux externes.

    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)

  6. Dans le fichier de déploiement de votre application, ajoutez une règle d'affinité pour le libellé d'ID de sous-réseau que vous avez trouvé à l'étape 4.

    Dans la section Affinité de cet exemple, YAML, ibm-cloud.kubernetes.io/subnet-id est key et <subnet_ID> est le value.

    apiVersion: apps/v1
kind: Deployment
metadata:
  name: with-node-affinity
spec:
  template:
    spec:
      affinity:
        nodeAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
            - matchExpressions:
              - key: ibm-cloud.kubernetes.io/subnet-id
                operator: In
                values:
                - <subnet_ID>
...

  7. Appliquez le fichier de configuration de déploiement mis à jour.

    kubectl apply -f with-node-affinity.yaml

  8. Vérifiez que les pods d'application se sont déployés sur les noeuds worker appropriés.

    1. Affichez la liste des pods de votre cluster. Dans la sortie, identifiez un pod pour votre application. Notez l'adresse IP privée du noeud (NODE) correspondant au noeud worker dans lequel figure le pod.
        kubectl get pods -o wide
    ```
    Dans cet exemple de sortie, le pod d'application `cf-py-d7b7d94db-vp8pq` se trouve sur un noeud worker dont l'adresse IP est `10.240.01.00`.
    ```sh {: screen}
    NAME                   READY     STATUS              RESTARTS   AGE       IP               NODE
    cf-py-d7b7d94db-vp8pq  1/1       Running             0          15d       172.30.xxx.xxx   10.240.01.00
    ```
2. Répertoriez les noeuds worker présents dans votre cluster. Dans la sortie, recherchez les noeuds worker situés dans la zone où vous avez connecté la passerelle publique. Vérifiez que le noeud worker avec l'adresse IP privée que vous avez identifiée à l'étape précédente est déployé dans cette zone.

```sh {: pre}
    ibmcloud ks worker ls --cluster <cluster_name_or_ID>
    ```
    Exemple de sortie
    ```sh {: screen}
    ID                                                   Primary IP     Flavor   State    Status   Zone         Version
    kube-bl25g33d0if1cmfn0p8g-vpctest-default-000005ac   10.240.02.00   c2.2x4   normal   Ready    us-south-2   1.35.7
    kube-bl25g33d0if1cmfn0p8g-vpctest-default-00000623   10.240.01.00   c2.2x4   normal   Ready    us-south-1   1.35.7
    ```

  9. Facultatif : si vous utilisez des listes de contrôle d'accès (ACL) pour contrôler le trafic réseau de votre cluster, créez des règles entrantes et sortantes dans la liste de contrôle d'accès de ce sous-réseau pour autoriser les entrées depuis et les sorties vers les noeuds finaux publics externes auxquels vos pods doivent accéder.