IBM Cloud Docs
Configuration des sous-réseaux classiques et des adresses IP

Configuration des sous-réseaux classiques et des adresses IP

Vous pouvez modifier le pool d'adresses IP publiques ou privées portables disponibles en ajoutant des sous-réseaux à votre cluster IBM Cloud® Kubernetes Service.

Présentation de la mise en réseau classique dans IBM Cloud Kubernetes Service

Maîtrisez les concepts de base de réseau classique dans les clusters IBM Cloud Kubernetes Service . IBM Cloud Kubernetes Service utilise des VLANs, des sous-réseaux et des adresses IP pour assurer la connectivité réseau des composants de cluster.

Réseaux locaux virtuels (VLAN)

Lorsque vous créez un cluster, les noeuds worker du cluster sont connectés automatiquement à un VLAN. Un VLAN configure un groupe de noeuds worker et de pods comme s'ils étaient reliés physiquement au même câble et fournit un canal pour la connectivité entre les noeuds worker et les pods.

VLAN pour clusters standard
Dans les clusters standard, la première fois que vous créez un cluster dans une zone, un VLAN public et un VLAN privé sont automatiquement mis à votre disposition dans cette zone dans votre compte d'infrastructure IBM Cloud. Pour tous les autres clusters que vous créez dans cette zone, vous devez spécifier la paire de VLAN que vous souhaitez utiliser dans cette zone. Vous pouvez réutiliser le même VLAN public et le même VLAN privé que vous avez créés pour vous car les VLAN peuvent être partagés par plusieurs clusters. Vous pouvez connecter vos noeuds worker à la fois à un VLAN public et au VLAN privé, ou seulement au VLAN privé. Si vous désirez connecter vos noeuds worker uniquement à un VLAN privé, vous pouvez utiliser l'ID d'un VLAN existant ou créer un VLAN privé et utiliser l'ID lors de la création du cluster.

Pour afficher les réseaux locaux virtuels qui sont mis à disposition dans chaque zone pour votre compte, exécutez ibmcloud ks vlan ls --zone <zone>. Pour afficher les réseaux locaux virtuels sur lequel un cluster est mis à disposition, exécutez ibmcloud ks cluster get --cluster <cluster_name_or_ID> --show-resources et recherchez la section des réseaux locaux virtuels de sous-réseau.

L'infrastructure IBM Cloud gère les VLAN qui sont mis à disposition automatiquement lorsque vous créez votre premier cluster dans une zone. Si vous laissez un VLAN inactif, par exemple en supprimant tous les noeuds worker qui s'y trouvent, l'infrastructure IBM Cloud récupère ce VLAN. Par la suite, si vous avez besoin d'un nouveau VLAN, contactez le support IBM Cloud.

Puis-je changer d'avis sur mes VLAN par la suite ?
Vous pouvez changer la configuration de vos VLAN en modifiant les pools de noeuds worker dans votre cluster. Pour plus d'informations, voir Modification des connexions de VLAN de vos noeuds worker.

Sous-réseaux et adresses IP

En plus des noeuds worker et des pods, des sous-réseaux sont également automatiquement mis à disposition sur les VLAN. Les sous-réseaux fournissent la connectivité réseau aux composants de votre cluster en leur affectant des adresses IP.

Les sous-réseaux suivants sont automatiquement mis à disposition sur les VLAN public et privé.

Sous-réseaux de VLAN public

  • Le sous-réseau public principal détermine les adresses IP publiques qui sont affectées aux noeuds worker lors de la création du cluster. Plusieurs clusters figurant sur le même VLAN peuvent partager un sous-réseau public principal.
  • Le sous-réseau public portable est lié à un seul cluster et fournit le cluster avec 8 adresses IP publiques. 3 adresses IP sont réservées aux fonctions d'infrastructure IBM Cloud. 1 adresse IP est utilisée par l'ALB public entrant par défaut et 4 adresses IP peuvent être utilisées pour créer des services d'équilibrage de charge réseau public (NLB) ou plus d'ALB publiques. Les adresses IP publiques portables sont des adresses IP permanentes pouvant être utilisées pour accéder aux équilibreurs de charge de réseau ou aux équilibreurs de charge d'application via Internet. Si vous avez besoin de plus de 4 adresses IP pour les équilibreurs de charge de réseau ou les équilibreurs de charge d'application, voir Ajout d'adresses IP portables. Notez que ces adresses IP sont conçues pour être utilisées dans IBM Cloud Kubernetes Service. N'utilisez pas ces adresses IP pour d'autres objectifs en dehors d'IBM Cloud Kubernetes Service.

Sous-réseaux de VLAN privé

  • Le sous-réseau privé principal détermine les adresses IP privées qui sont affectées aux noeuds worker lors de la création du cluster. Plusieurs clusters figurant sur le même VLAN peuvent partager un sous-réseau privé principal.
  • Le sous-réseau privé portable est lié à un seul cluster et fournit le cluster avec 8 adresses IP privées. 3 adresses IP sont réservées aux fonctions d'infrastructure IBM Cloud. 1 adresse IP est utilisée par l'ALB public entrant par défaut et 4 adresses IP peut être utilisées pour créer des services de l'équilibreur de charge de réseau privé (NLB) ou des ALB privées. Les adresses IP privées portables sont des adresses IP permanentes pouvant être utilisées pour accéder aux équilibreurs de charge de réseau ou aux équilibreurs de charge d'application via un réseau privé. Si vous avez besoin de plus de 4 adresses IP pour les équilibreurs de charge de réseau ou les équilibreurs de charge d'application privés, voir Ajout d'adresses IP portables. Notez que ces adresses IP sont conçues pour être utilisées dans IBM Cloud Kubernetes Service. N'utilisez pas ces adresses IP pour d'autres objectifs en dehors d'IBM Cloud Kubernetes Service.

Recherche des sous-réseaux mis à disposition dans votre compte

Pour afficher tous les sous-réseaux mis à disposition dans tous les groupes de ressources de votre compte, exécutez ibmcloud ks subnets --provider classic. Pour afficher les sous-réseaux publics et privés portables qui sont liés à un cluster, vous pouvez exécuter ibmcloud ks cluster get --cluster <cluster_name_or_ID> --show-resources et rechercher la section des VLAN de sous-réseau.

Dans IBM Cloud Kubernetes Service, les VLAN sont limités à 40 sous-réseaux. Si vous atteignez cette limite, vérifiez d'abord si vous pouvez réutiliser des sous-réseaux du VLAN pour créer d'autres clusters. Si vous avez besoin d'un nouveau VLAN, commandez-en un en contactant le support IBM Cloud. Ensuite, créez un cluster qui utilise ce nouveau VLAN.

Les adresses IP de mes nœuds de travail vont-elles changer?
Une adresse IP est affectée à votre noeud worker sur les VLAN publics ou privés que votre cluster utilise. Une fois le noeud worker mis à disposition, l'adresse IP de noeud worker est conservée après des opérations reboot et update, mais l'adresse IP de noeud worker est modifiée après une opération replace. De plus, l'adresse IP du noeud worker est utilisée pour l'identité de noeud worker dans la plupart des commandes kubectl. Si vous changez les VLAN que le pool de noeuds worker utilise, les nouveaux noeuds worker qui sont mis à disposition dans ce pool utilisent les nouveaux VLAN pour leurs adresses IP. Les adresses IP de noeud worker existantes ne changent pas, mais vous pouvez choisir de supprimer les noeuds worker qui utilisent les anciens réseaux locaux virtuels.
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 pod et de service personnalisés lors de la création du cluster, utilisez les options --pod-subnet et --service-subnet dans la commande CLI ibmcloud ks cluster create.

Pods

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.30.0.0/16.

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.

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

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.

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 suivantes :

  • 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

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.

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 et leurs relations avec les VLAN, voir cette rubrique de sécurité de cluster.

Cependant, dans plusieurs situations, les composants de votre cluster doivent être autorisés à communiquer sur plusieurs VLAN privés. Par exemple, si vous souhaitez créer un cluster à zones multiples, si vous avez plusieurs réseaux locaux virtuels pour un cluster, ou si vous avez plusieurs sous-réseaux sur le même réseau local virtuel, les nœuds worker sur différents sous-réseaux du même réseau local virtuel ou dans des réseaux locaux virtuels différents ne peuvent pas communiquer automatiquement entre eux. Vous devez activer une fonction de routeur virtuel (VRF) ou de Spanning VLAN pour votre compte d'infrastructure IBM Cloud.

Virtual Routing and Forwarding (VRF)
VRF permet à tous les réseaux locaux virtuels et sous-réseaux de votre compte d'infrastructure de communiquer entre eux. De plus, une fonction VRF est requise pour autoriser vos noeuds worker et le maître à communiquer via le noeud final de service de cloud privé. Pour activer la fonction VRF, voir Activation de VRF. Pour vérifier si la fonction VRF est déjà activée, utilisez la commande ibmcloud account show. Notez que la fonction VRF élimine l'option Spanning VLAN de votre compte car tous les VLAN sont en mesure de communiquer sauf si vous configurez un dispositif de passerelle pour gérer le trafic.
Spanning VLAN
Si vous ne pouvez pas ou ne souhaitez pas activer VRF, activez le réseau local virtuel. Pour effectuer cette action, vous devez disposer de l'autorisation Réseau > Gérer l'infrastructure VLAN Spanning du réseau ou vous pouvez demander au propriétaire du compte de l'activer. Pour vérifier si le réseau local virtuel est déjà activé, utilisez la ibmcloud ks vlan spanning get --region <region> commande. Notez que vous ne pouvez pas activer le noeud final de service de cloud privé si vous choisissez d'activer le réseau local virtuel s'étendant à la place d'un VRF.
Comment le VRF ou le VLAN affectent-ils la segmentation du réseau?
Lorsque la fonction VRF ou Spanning VLAN est activée, tout système connecté à l'un de vos VLAN privés dans le même compte IBM Cloud peut communiquer avec des noeuds worker. Vous pouvez isoler votre cluster des autres systèmes sur le réseau privé en appliquant des règles de réseau privéCalico. IBM Cloud Kubernetes Service est également compatible avec toutes les offres de pare-feu d'infrastructureIBM Cloud. Vous pouvez mettre en place un pare-feu, tel qu'un dispositif de routeur virtuel (VRA), avec des règles réseau personnalisées afin d'assurer une sécurité réseau dédiée pour votre cluster standard et détecter et parer à des intrusions réseau.

Utilisation de sous-réseaux existants pour créer un cluster

Lorsque vous créez un cluster standard, des sous-réseaux sont automatiquement créés pour vous. Néanmoins, au lieu d'utiliser les sous-réseaux mis à disposition automatiquement, vous pouvez utiliser des sous-réseaux portables existants dans votre compte d'infrastructure IBM Cloud ou réutiliser les sous-réseaux d'un cluster supprimé.

Utilisez cette option pour conserver des adresses IP statiques stables lors de création ou de suppression de clusters ou pour commander des blocs d'adresses IP plus importants. Si vous souhaitez à la place obtenir plus d'adresses IP privées ou publiques portables pour créer des services d'équilibreur de charge de réseau (NLB) ou des services d'équilibreur de charge d'application (ALB) Ingress, voir Ajout d'adresses IP portables.

Tous les sous-réseaux qui ont été automatiquement commandés lors de la création du cluster sont immédiatement marqués pour suppression après avoir supprimé un cluster, et vous ne pouvez pas réutiliser les sous-réseaux pour créer un nouveau cluster.

Avant de commencer

Pour créer un cluster à l'aide de sous-réseaux existants :

  1. Procurez-vous l'ID du sous-réseau et l'ID du VLAN sur lequel figure ce sous-réseau.

    ibmcloud ks subnets --provider classic
    

    Dans cet exemple de sortie, l'ID du sous-réseau est 1602829 et l'ID du VLAN est 2234945 :

    GETting subnet list...
    OK
    ID        Network             Gateway          VLAN ID   Type      Bound Cluster
    1550165   10.xxx.xx.xxx/26    10.xxx.xx.xxx    2234947   private
    1602829   169.xx.xxx.xxx/28   169.xx.xxx.xxx   2234945   public
    
  2. Créez un cluster à partir de l'interface CLI à l'aide de l'ID de VLAN que vous avez identifié. Inclure l'option « --no-subnet » pour empêcher la création automatique d'un nouveau sous-réseau IP public portable et d'un nouveau sous-réseau IP privé portable.

    ibmcloud ks cluster create classic --zone dal10 --flavor b3c.4x16 --no-subnet --public-vlan 2234945 --private-vlan 2234947 --workers 3 --name my_cluster
    

    Si vous ne vous souvenez pas dans quelle zone se trouve le VLAN pour l'option --zone, vous pouvez vérifier si le VLAN se trouve dans une certaine zone en exécutant ibmcloud ks vlan ls --zone <zone>.

  3. Vérifiez que le cluster a été créé. La commande des machines de noeud worker et la configuration et la mise à disposition du cluster dans votre compte peuvent prendre jusqu'à 15 minutes.

    ibmcloud ks cluster ls
    

    Lorsque la mise à disposition de votre cluster est terminée, la valeur de State passe à deployed.

    NAME         ID                                   State      Created          Workers    Zone      Version     Resource Group Name   Provider
    mycluster    aaf97a8843a29941b49a598f516da72101   deployed   20170201162433   3          dal10     1.32      Default             classic
    
  4. Vérifiez le statut des noeuds worker.

    ibmcloud ks worker ls --cluster <cluster_name_or_ID>
    

    Avant de passer à l'étape suivante, les noeuds worker doivent être prêts. La valeur de State passe à normal et la zone Status affiche Ready.

    ID                                                  Public IP        Private IP     Machine Type   State      Status   Zone     Version
    prod-dal10-pa8dfcc5223804439c87489886dbbc9c07-w1    169.xx.xxx.xxx   10.xxx.xx.xxx  free           normal     Ready    dal10      1.32
    
  5. Ajoutez le sous-réseau à votre cluster en spécifiant l'ID du sous-réseau. Lorsque vous rendez disponible un sous-réseau pour un cluster, un fichier configmap Kubernetes est créé pour vous et inclut toutes les adresses IP publiques portables disponibles que vous pouvez utiliser. S'il n'existe aucun équilibreur de charge d'application (ALB) Ingress dans la zone où se trouve le VLAN du sous-réseau, une adresse IP publique portable et une adresse IP privée portable sont automatiquement utilisées pour créer les équilibreurs de charge d’application public et privé pour cette zone. Vous pouvez utiliser toutes les autres adresses publiques et privées portables de ce sous-réseau pour créer des services d'équilibreur de charge de réseau pour vos applications.

    ibmcloud ks cluster subnet add --cluster <cluster_name_or_id> --subnet-id <subnet_ID>
    
  6. Vérifiez que le sous-réseau est ajouté à votre cluster.

    ibmcloud ks cluster get --cluster <cluster_name> --show-resources
    
  7. Important : pour activer la communication entre des noeuds worker qui se trouvent dans différents sous-réseaux d'un même VLAN, vous devez activer le routage entre les sous-réseaux sur le même VLAN.

Gestion des adresses IP portables existantes

Par défaut, 4 adresses IP publiques portables et 4 adresses IP privées portables peuvent être utilisées pour exposer des applications individuelles sur le réseau public ou privé en créant un service d'équilibreur de charge de réseau (NLB) ou en créant des équilibreurs de charge d'application (ALB) Ingress supplémentaires. Pour créer un service d'équilibreur de charge de réseau ou d'équilibreur de charge d'application, vous devez avoir au moins une adresse IP portable du type approprié. Vous pouvez afficher les adresses IP portables disponibles ou libérer une adresse IP portable utilisée.

Affichage des adresses IP publiques portables disponibles

Pour répertorier toutes les adresses IP portables de votre cluster, utilisées et disponibles, vous pouvez exécuter la commande suivante.

kubectl get cm ibm-cloud-provider-vlan-ip-config -n kube-system -o yaml

Pour afficher uniquement les adresses IP publiques portables disponibles pour créer des équilibreurs de charge de réseau publics ou davantage d'équilibreurs de charge d'application publics, vous pouvez utiliser la procédure décrite ci-après.

Avant de commencer

Pour répertorier les adresses IP publiques portables disponibles :

  1. Créez un fichier de configuration de service Kubernetes nommé myservice.yaml et définissez un service de type LoadBalancer avec une adresse IP d'équilibreur de charge de réseau factice. L'exemple suivant utilise l'adresse IP 1.1.1.1 comme adresse IP d'équilibreur de charge de réseau. Remplacez <zone> par la zone où vous souhaitez vérifier les adresses IP disponibles.

    apiVersion: v1
    kind: Service
    metadata:
      labels:
        run: myservice
      name: myservice
      namespace: default
      annotations:
        service.kubernetes.io/ibm-load-balancer-cloud-provider-zone: "<zone>"
    spec:
      ports:
      - port: 80
        protocol: TCP
        targetPort: 80
      selector:
        run: myservice
      sessionAffinity: None
      type: LoadBalancer
      loadBalancerIP: 1.1.1.1
    
  2. Créez le service dans votre cluster.

    kubectl apply -f myservice.yaml
    
  3. Inspectez le service.

    kubectl describe service myservice
    

    La création de ce service échoue car le maître Kubernetes ne trouve pas l'adresse IP NLB spécifiée dans la mappe de configuration Kubernetes. Lorsque vous exécutez cette commande, le message d'erreur s'affiche, ainsi que la liste des adresses IP publiques disponibles pour le cluster.

    Error on cloud load balancer a8bfa26552e8511e7bee4324285f6a4a for service default/myservice with UID 8bfa2655-2e85-11e7-bee4-324285f6a4af: Requested cloud provider IP 1.1.1.1 is not available. The following cloud provider IP addresses are available: <list_of_IP_addresses>
    

Libération des adresses IP utilisées

Vous pouvez libérer une adresse IP portable utilisée en supprimant le service d'équilibreur de charge de réseau (NLB) ou en désactivant l'équilibreur de charge d'application Ingress (ALB) qui l'utilise.

Avant de commencer

Pour supprimer un équilibreur de charge de réseau ou désactiver un équilibreur de charge d'application :

  1. Répertoriez les services disponibles dans votre cluster.
    kubectl get services | grep LoadBalancer
    
  2. Retirez le service d'équilibreur de charge de réseau ou désactivez le service d'équilibrage de charge d'application qui utilise une adresse IP publique ou privée.
    • Supprimez un équilibreur de charge de réseau :
      kubectl delete service <service_name>
      
    • Désactivez un équilibreur de charge d'application :
      ibmcloud ks ingress alb disable --alb <ALB_ID> -c <cluster_name_or_ID>
      

Ajout d'adresses IP portables

Par défaut, 4 adresses IP publiques portables et 4 adresses IP privées portables peuvent être utilisées pour exposer des applications individuelles sur le réseau public ou privé en créant un service d'équilibreur de charge de réseau (NLB). Pour créer plus de 4 équilibreurs de charge de réseau publics ou privés, vous pouvez obtenir des adresses IP supplémentaires en ajoutant des sous-réseaux au cluster.

Lorsque vous rendez un sous-réseau accessible à un cluster, les adresses IP de ce sous-réseau sont utilisées pour la mise en réseau du cluster. Pour éviter des conflits d'adresse IP, prenez soin d'utiliser un sous-réseau avec un seul cluster. N'utilisez pas en même temps un sous-réseau pour plusieurs clusters ou à d'autres fins hors d'IBM Cloud Kubernetes Service.

Ajout d'adresses IP portables en commandant d'autres sous-réseaux

Vous pouvez obtenir d'autres adresses IP portables pour les services d'équilibreur de charge de réseau en créant un nouveau sous-réseau dans un compte d'infrastructure IBM Cloud et en le rendant disponible pour le cluster que vous avez spécifié.

Les adresses IP publiques portables sont facturées au mois. Si vous retirez des adresses IP publiques portables après la mise à disposition de votre sous-réseau, vous devez quand même payer les frais mensuels, même si vous ne les avez utilisées que brièvement.

Avant de commencer

Pour commander un sous-réseau :

  1. Provisionnez un nouveau sous-réseau.

    ibmcloud ks cluster subnet create --cluster <cluster_name_or_id> --size <subnet_size> --vlan <VLAN_ID>
    
    Paramètres d'un sous-réseau
    Paramètre Description
    <cluster_name_or_id> Remplacez <cluster_name_or_id> par le nom ou l'ID du cluster.
    <subnet_size> Remplacez <subnet_size> par le nombre d'adresses IP que vous souhaitez créer dans le sous-réseau portable. Valeurs admises : 8, 16, 32 ou 64. Notez que, lorsque vous ajoutez des adresses IP portables à votre sous-réseau, trois adresses IP sont utilisées pour les opérations de réseau internes au cluster. Vous ne pouvez pas utiliser ces trois adresses IP pour vos équilibreurs de charge d'application (ALB) ou pour créer des services de équilibreur de charge réseau (NLB). Par exemple, si vous demandez huit adresses IP publiques portables, vous pouvez en utiliser cinq pour exposer vos applications au public.
    <VLAN_ID> Remplacez <VLAN_ID> par l'ID du réseau local virtuel public ou privé sur lequel vous souhaitez allouer les adresses IP publiques ou privées portables. Vous devez sélectionner un VLAN public ou privé auquel un noeud worker existant est connecté. Pour vérifier les réseaux locaux virtuels publics ou privés sur lequel vos nœuds worker sont connectés, exécutez ibmcloud ks cluster get --cluster <cluster> --show-resources et recherchez la section des réseaux locaux virtuels de sous-réseau dans le résultat. Le sous-réseau est fourni dans la même zone que le VLAN.
  2. Vérifiez que le sous-réseau a bien été créé et ajouté à votre cluster. Le CIDR du sous-réseau est répertorié dans la section Subnet VLANs.

    ibmcloud ks cluster get --cluster <cluster_name_or_ID> --show-resources
    

    Dans cet exemple de sortie, un deuxième sous-réseau a été ajouté au VLAN public 2234945.

    Subnet VLANs
    VLAN ID   Subnet CIDR          Public   User-managed
    2234947   10.xxx.xx.xxx/29     false    false
    2234945   169.xx.xxx.xxx/29    true     false
    2234945   169.xx.xxx.xxx/29    true     false
    
  3. Important : pour activer la communication entre des noeuds worker qui se trouvent dans différents sous-réseaux d'un même VLAN, vous devez activer le routage entre les sous-réseaux sur le même VLAN.

Ajout d'adresses IP portables en ajoutant des sous-réseaux existants à votre cluster

Vous pouvez obtenir d'autres adresses IP portables pour les services d'équilibreur de charge de réseau en rendant un sous-réseau existant dans un compte d'infrastructure IBM Cloud disponible pour le cluster que vous avez spécifié.

Avant de commencer

Pour rendre un sous-réseau disponible pour votre cluster :

  1. Passez en revue les ID des VLAN publics ou privés sur lesquels vous souhaitez allouer les adresses IP publiques ou privées portables. Vous devez sélectionner un VLAN public ou privé auquel un noeud worker existant est connecté.
    ibmcloud ks cluster get --cluster <cluster_name_or_id> --show-resources
    
    Dans la sortie, recherchez les ID VLAN (VLAN ID) à la section Subnet VLANs.
    Subnet VLANs
    VLAN ID   Subnet CIDR          Public   User-managed
    2234947   10.xxx.xx.xxx/29     false    false
    2234945   169.xx.xxx.xxx/29    true     false
    
  2. Procurez-vous l'ID du sous-réseau à utiliser. Vérifiez que le sous-réseau se trouve sur l'un des ID VLAN que vous avez trouvés à l'étape précédente et qu'il n'est pas déjà lié à un autre cluster.
    ibmcloud ks subnets --provider classic
    
    Dans cet exemple de sortie, l'ID du sous-réseau est 1602829, qui correspond à l'ID VLAN 2234945.
    GETting subnet list...
    OK
    ID        Network             Gateway          VLAN ID   Type      Bound Cluster
    1550165   10.xxx.xx.xxx/26    10.xxx.xx.xxx    2234947   private
    1602829   169.xx.xxx.xxx/28   169.xx.xxx.xxx   2234945   public
    
  3. Rendez le sous-réseau disponible pour votre cluster.
    ibmcloud ks cluster subnet add --cluster <cluster_name_or_id> --subnet-id <subnet_ID>
    
  4. Vérifiez que le sous-réseau a bien été créé et ajouté à votre cluster. Le CIDR du sous-réseau est répertorié dans la section Subnet VLANs.
    ibmcloud ks cluster get --cluster <cluster_name> --show-resources
    
    Dans cet exemple de sortie, un deuxième sous-réseau a été ajouté au VLAN public 2234945.
    Subnet VLANs
    VLAN ID   Subnet CIDR          Public   User-managed
    2234947   10.xxx.xx.xxx/29     false    false
    2234945   169.xx.xxx.xxx/29    true     false
    2234945   169.xx.xxx.xxx/29    true     false
    
  5. Important : pour activer la communication entre des noeuds worker qui se trouvent dans différents sous-réseaux d'un même VLAN, vous devez activer le routage entre les sous-réseaux sur le même VLAN.

Gestion du routage de sous-réseaux

Dans des clusters classiques, si vous disposez de plusieurs VLAN pour votre cluster, de plusieurs sous-réseaux sur le même VLAN ou d'un cluster classique multizone, vous devez activer une fonction VRF (Virtual Router Function) pour votre compte d'infrastructure IBM Cloud de sorte que vos noeuds worker puissent communiquer entre eux sur le réseau privé. Pour activer la fonction VRF, voir Activation de VRF. Pour vérifier si la fonction VRF est déjà activée, utilisez la commande ibmcloud account show. Si vous ne pouvez pas ou ne souhaitez pas activer VRF, activez Réseau local virtuel. Pour effectuer cette action, vous devez disposer de l'autorisation Réseau > Gérer l'infrastructure VLAN étendue du réseau, ou vous pouvez demander au propriétaire du compte de l'activer. Pour vérifier si la répartition VLAN est déjà activée, utilisez le ibmcloud ks vlan spanning get --region <region> commande.

Passez en revue les scénarios suivants nécessitant également la fonction Spanning VLAN.

L'option Spanning VLAN est désactivée pour les clusters qui sont créés dans un compte VRF. Lorsque VRF est activé, tous les VLAN du compte peuvent communiquer automatiquement entre eux via le réseau privé. Pour plus d'informations, voir Planification de votre configuration de réseau de cluster : Communication entre les noeuds worker.

Activation du routage entre les sous-réseaux principaux sur le même VLAN

Lorsque vous créez un cluster, des sous-réseaux public et privé principaux sont mis à disposition sur les VLAN public et privé. Le sous-réseau public principal se termine par /28 et fournit 14 adresses IP publiques pour vos noeuds worker. Le sous-réseau privé principal se termine par /26 et fournit jusqu'à 62 adresses IP privées pour les noeuds worker.

Vous pouvez dépasser les 14 adresses IP publiques et les 62 adresses IP privées initiales correspondant à vos noeuds worker en disposant d'un cluster volumineux ou de plusieurs clusters de taille plus petite au même emplacement sur le même VLAN. Lorsqu'un sous-réseau public ou privé atteint le nombre limite de noeuds worker, un autre sous-réseau principal est commandé dans le même VLAN.

Pour garantir que les noeuds worker de ces sous-réseaux principaux situés sur le même VLAN peuvent communiquer, vous devez activer la fonction Spanning VLAN. Pour obtenir les instructions correspondantes, voir Activer ou désactiver le Spanning VLAN.

Pour vérifier si le réseau local virtuel est déjà activé, utilisez la ibmcloud ks vlan spanning get --region <region>commande.

Gestion du routage de sous-réseaux pour les dispositifs de passerelle

Lorsque vous créez un cluster, un sous-réseau portable public et un sous-réseau portable privé sont commandés sur les VLAN auxquels est connecté le cluster. Ces sous-réseaux fournissent les adresses IP des services d'équilibreur de charge d'application (ALB) Ingress et d'équilibreur de charge de réseau (NLB).

Cependant, si vous disposez déjà d'un dispositif de routage, tel qu'un dispositif de routeur virtuel (VRA), les sous-réseaux portables récemment ajoutés des VLAN auxquels est connecté le cluster, ne sont pas configurés sur le routeur. Pour utiliser des équilibreurs de charge de réseau et des équilibreurs de charge d'application, vous devez vous assurer que les dispositifs réseau peuvent effectuer le routage entre les sous-réseaux sur le même VLAN en activant la fonction VRF (Virtual Router Function) pour votre compte d'infrastructure IBM Cloud. Pour activer la fonction VRF, voir Activation de VRF. Si vous ne pouvez pas ou ne souhaitez pas activer VRF, activez Réseau local virtuel.

Retrait de sous-réseaux d'un cluster

Si vous n'avez plus besoin des sous-réseaux, vous pouvez les retirer de votre cluster. Une fois le sous-réseau retiré, il n'est plus disponible pour votre cluster, mais il existe toujours dans votre compte d'infrastructure IBM Cloud.

Avant de commencer, examinez les considérations suivantes.

  • Les sous-réseaux peuvent être déconnectés d'un cluster uniquement si aucune des adresses IP dérivées de cette plage de sous-réseaux n'est utilisée sur votre cluster.
  • Les adresses IP publiques portables sont facturées au mois. Si vous retirez le sous-réseau, vous devez quand même payer les frais mensuels liés à l'utilisation des adresses IP, même si vous ne les avez utilisées que brièvement.
  • Si les noeuds worker utilisaient auparavant le sous-réseau que vous souhaitez déconnecter mais qu'aucun noeud worker n'est actuellement connecté à un sous-réseau sur le réseau local virtuel (VLAN) de ce sous-réseau, le sous-réseau n'est pas visible pour le cluster. Vous pouvez à la place annuler le sous-réseau directement dans la console d' IBM Cloud s Classic Infrastructure.
  1. Recherchez le routage CIDR pour le sous-réseau que vous souhaitez retirer.
    ibmcloud ks cluster get --cluster <cluster_name> --show-resources
    
    Dans cet exemple de sortie, le routage CIDR du sous-réseau à retirer est 169.1.1.1/29.
    Subnet VLANs
    VLAN ID   Subnet CIDR          Public   User-managed
    2234947   10.xxx.xx.xxx/29     false    false
    2234945   169.xx.xxx.xxx/29    true     false
    2234945   169.1.1.1/29         true     false
    
  2. A l'aide du routage CIDR que vous avez trouvé lors de l'étape précédente, procurez-vous l'ID du sous-réseau à retirer.
    ibmcloud ks subnets --provider classic
    
    Dans cet exemple de sortie, le sous-réseau doté du routage CIDR 169.1.1.1/29 porte l'ID 1602829.
    ID        Network             Gateway          VLAN ID   Type      Bound Cluster
    ...
    1602829   169.1.1.1/29        169.1.1.2        2234945   public    df253b6025d64944ab99ed63bb4567b6
    
  3. Déconnectez le sous-réseau de votre cluster. Le sous-réseau reste disponible dans votre compte d'infrastructure IBM Cloud.
    ibmcloud ks cluster subnet detach --cluster <cluster_name_or_ID> --subnet-id <subnet_ID>
    
  4. Vérifiez que le sous-réseau n'est plus lié à votre cluster.
    ibmcloud ks cluster get --cluster <cluster_name> --show-resources
    
    Dans cet exemple de sortie, le sous-réseau doté du routage CIDR 169.1.1.1/29 a été retiré.
    Subnet VLANs
    VLAN ID   Subnet CIDR          Public   User-managed
    2234947   10.xxx.xx.xxx/29     false    false
    2234945   169.xx.xxx.xxx/29    true     false