Création d'un cluster classique dans la console

Pour commencer à créer votre cluster, accédez à la console et cliquez sur Créer un cluster.

Détails de l'emplacement

Lorsque vous créez un cluster, ses ressources restent dans l'emplacement où vous avez déployé le cluster.

• Groupe de ressources: un cluster ne peut être créé que dans un seul groupe de ressources et, une fois le cluster créé, vous ne pouvez plus modifier son groupe de ressources. Pour créer des clusters dans un autre groupe de ressources que le groupe par défaut, vous devez disposer au moins du rôle de plateforme Afficheur pour le groupe de ressources.

• Zone géographique: sélectionnez une zone dans laquelle créer le cluster, par exemple l'Amérique du Nord. La zone géographique permet de filtrer les valeurs Disponibilité et Métropole que vous pouvez sélectionner dans la console.

• Disponibilité: Un cluster peut être créé avec une configuration Zone unique ou Multizone. Un cluster multizone offre une haute disponibilité, avec le maître Red Hat OpenShift déployé dans une zone compatible avec plusieurs zones et trois répliques du maître réparties sur différentes zones.
  • Pour les clusters à zones multiples, choisissez un emplacement Metro. Pour des performances optimales, sélectionnez la région la plus proche de vous géographiquement. Vos zones de travail sont basées sur la région que vous avez choisie. Vous pouvez sélectionner les zones d'agent à appliquer et vos noeuds worker sont répartis dans vos zones pour la haute disponibilité. Chaque zone d'agent possède un VLAN public et privé. Si vous ne disposez pas de VLAN dans cette zone, ils sont créés pour vous.
  • Pour les clusters à zone unique, choisissez une zone de noeud worker unique dans laquelle héberger votre cluster. Pour des performances optimales, sélectionnez une zone de la ville qui se trouve physiquement la plus proche de chez vous. Chaque zone d'agent possède un VLAN public et privé. Si vous ne disposez pas de VLAN dans cette zone, ils sont créés pour vous.

Version de Kubernetes

Par défaut, les clusters sont créés avec la version Kubernetes par défaut. Vous pouvez spécifier une autre version prise en charge.

Pool de noeuds worker

Le pool de noeuds worker de cluster définit le nombre et le type de noeuds worker qui exécutent votre charge de travail. Vous pouvez modifier les détails de votre pool de noeuds worker à tout moment.

• Configuration: la configuration définit la quantité de CPU virtuel, de mémoire et d'espace disque configurée sur chaque nœud de travail et mise à la disposition des conteneurs. Les types de machines virtuelles et bare metal disponibles varient en fonction de la zone de déploiement du cluster.

• Système d'exploitation et Architecture: pour obtenir la liste des systèmes d'exploitation et des architectures disponibles par version de cluster, voir versions disponibles.

• Noeuds worker par zone: pour la haute disponibilité, au moins 3 noeuds worker par zone sont recommandés.

• Chiffrer le disque local: par défaut, les noeuds worker utilisent le chiffrement de disque AES 256 bits. Vous pouvez choisir de désactiver le chiffrement de disque lorsque vous créez le cluster.

Noeud final de service maître

Les noeuds finaux de service fournissent la communication au maître. Vous pouvez choisir de configurer votre cluster avec un noeud final de service de cloud public uniquement ou à la fois public et privé. Pour plus d'informations sur la configuration requise pour exécuter des applications accessibles sur internet ou pour faire en sorte que votre cluster reste privé, voir Planification de la configuration de votre réseau de cluster. Vous ne pouvez pas modifier les points de terminaison du service cloud après avoir créé le cluster.

Gestion des secrets Ingress

IBM Cloud Secrets Manager gère de manière centralisée les certificats de sous-domaine Ingress et d'autres secrets dans votre cluster. Vous pouvez choisir d'enregistrer une instance Secrets Manager dans votre cluster lors du processus de création de cluster. Vous pouvez également spécifier un groupe de secrets que vous pouvez utiliser pour contrôler l'accès aux secrets de votre cluster. Ces deux options peuvent être configurées ou modifiées après la création du cluster.

Chiffrement

Activez le chiffrement de données avec un service de gestion de clés (KMS) pour chiffrer les secrets et autres informations sensibles dans votre cluster. Vous pouvez également activer KMS ultérieurement.

Détails du cluster

Vous pouvez personnaliser le nom de cluster unique et les balises que vous souhaitez utiliser pour organiser et identifier vos ressources IBM Cloud, telles que team ou billing department.

Si vous souhaitez ajouter un profil de confiance existant à votre cluster, indiquez l'ID du profil de confiance. Si vous ne spécifiez pas de profil de confiance, vous pouvez terminer le processus de création de cluster avec une clé API. Voir Configuration d'un profil de confiance pour plus d'informations.

Intégrations d'observabilité

Vous pouvez activer des intégrations d'observabilité supplémentaires que vous souhaitez inclure dans votre cluster. Certaines intégrations sont automatiquement activées si vous disposez d'une instance de plateforme existante de cette intégration. Dans ce cas, vous ne pouvez pas désactiver l'intégration. Si vous souhaitez utiliser une intégration et que vous ne disposez que d'une instance d'application existante de cette intégration, l'intégration est désactivée par défaut et vous devez l'activer manuellement.

• Journalisation: Vous pouvez utiliser IBM Cloud Logs pour gérer les journaux du système d'exploitation, des applications et de la plate-forme. Si vous souhaitez activer cette intégration ultérieurement, voir IBM Cloud Logs.

• Surveillance: L'intégration de services de surveillance permet une visibilité opérationnelle sur les performances et la santé de vos applications, services et plateformes. Si vous désactivez cette intégration et souhaitez l'activer ultérieurement, consultez Surveillance de l'état des clusters L'intégration Security and Compliance Center Workload Protection recherche et hiérarchise les vulnérabilités logicielles, détecte les menaces et y répond, et gère les configurations, les autorisations et la conformité depuis la source jusqu'à l'exécution. Pour plus d'informations, voir la page Protection de la charge de travail Prise en main.
• Spécifiez le type de configuration pour utiliser des instances nouvelles ou existantes de surveillance et de protection de la charge de travail. Si vous souhaitez utiliser des instances existantes de surveillance et de protection de la charge de travail, les instances de chaque intégration doivent être connectées. Dans ce cas, indiquez l'instance de surveillance ou de protection de la charge de travail que vous souhaitez utiliser ; vous ne pouvez pas indiquer les deux instances, mais les deux instances sont utilisées tant qu'elles sont connectées. Vous pouvez connecter des instances existantes à partir de la page de détails de l'instance Surveillance ou Protection de la charge de travail.

Création d'un cluster classique via l'interface de ligne de commande (CLI)

Créez votre cluster Classic à l'aide de l'interface IBM Cloud CLI.

• Veillez à remplir les conditions préalables pour préparer votre compte et définir la configuration de votre cluster. N'oubliez pas que vous avez besoin d'un cluster avec un minimum de 2 noeuds worker version 4x16 pour que les composants Red Hat OpenShift par défaut puissent être déployés.
• Installez les outils d'interface de ligne de commande IBM Cloud.

1. Connectez-vous à l'interface CLI d' IBM Cloud. Si vous vous connectez avec un ID fédéré, utilisez ibmcloud login --sso.

   ibmcloud login [--sso]
   

2. Si vous disposez de plusieurs comptes IBM Cloud, sélectionnez le compte sur lequel vous souhaitez créer votre cluster.

3. Pour créer des clusters dans un autre groupe de ressources que le groupe par défaut, ciblez ce groupe de ressources. Un cluster ne peut être créé que dans un seul groupe de ressources, et une fois le cluster créé, vous ne pouvez pas modifier son groupe de ressources. Vous devez disposer au moins du rôle Afficheur pour que le groupe de ressources puisse le cibler.

   ibmcloud target -g RESOURCE_GROUP_NAME
   

4. Passez en revue les zones dans lesquelles vous pouvez créer votre cluster. Dans la sortie de la commande suivante, le type d'emplacement des zones est dc. Pour étendre votre cluster à plusieurs zones, vous devez créer le cluster dans une zone compatible avec plusieurs zones. Les zones compatibles avec plusieurs zones ont une valeur de métropole dans la colonne Métropole multizone. Si vous souhaitez créer un cluster multizone, vous pouvez utiliser la console IBM Cloud ou vous pouvez ajouter d'autres zones à votre cluster une fois le cluster créé.

   ibmcloud oc locations
   

   Si vous sélectionnez une zone à l'étranger, il se peut que vous ayez besoin d'une autorisation légale pour stocker physiquement les données dans un pays étranger.

5. Passez en revue les versions de noeud worker qui sont disponibles dans cette zone. La version définit le nombre d'UC virtuelles, de mémoire et d'espace disque configuré dans chaque noeud worker et rendu disponible pour vos applications. Les noeuds worker des clusters classiques peuvent être créés en tant que machines virtuelles sur une infrastructure partagée ou dédiée, ou en tant que machines bare metal qui vous sont dédiées. Après avoir créé votre cluster, vous pouvez ajouter différentes versions en ajoutant un pool de noeuds worker.

   Avant de créer une machine bare metal, assurez-vous de vouloir en mettre une à disposition. Les machines bare metal sont facturées au mois. Si vous commandez une machine bare metal par erreur, vous êtes facturé pour tout le mois, même si vous annulez immédiatement la machine.
   

   ibmcloud oc flavors --zone ZONE
   

6. Vérifiez si vous disposez de VLAN existants dans les zones que vous souhaitez inclure dans votre cluster et notez l'ID du VLAN. Si vous ne disposez pas d'un réseau local virtuel public ou privé dans l'une des zones que vous souhaitez utiliser dans votre cluster, IBM Cloud Kubernetes Service crée automatiquement ces réseaux locaux virtuels lorsque vous créez le cluster.

   ibmcloud oc vlan ls --zone ZONE
   

   Exemple de sortie

   ID        Name   Number   Type      Router
   1519999   vlan   1355     private   bcr02a.dal10
   1519898   vlan   1357     private   bcr02a.dal10
   1518787   vlan   1252     public    fcr02a.dal10
   1518888   vlan   1254     public    fcr02a.dal10
   

   S'il existe déjà un VLAN public et un VLAN privé, notez les routeurs correspondants. Les routeurs de VLAN privé commencent toujours par bcr (routeur de back end) et les routeurs de VLAN public par fcr (routeur de front-end). Lorsque vous créez un cluster et que vous spécifiez les VLAN publics et privés, le nombre et la combinaison de lettres après ces préfixes doivent correspondre. Dans l'exemple de sortie, n'importe quel VLAN privé peut être utilisé avec n'importe quel VLAN public étant donné que les routeurs incluent tous 02a.dal10.

7. Créez votre cluster standard.

   ibmcloud oc cluster create classic --zone <zone> --flavor <flavor> --hardware <shared_or_dedicated> --public-vlan <public_VLAN_ID> --private-vlan <private_VLAN_ID> --workers <number> [--operating-system (REDHAT_8_64)] --name <cluster_name> --version <major.minor.patch>_openshift --public-service-endpoint [--private-service-endpoint] [--pod-subnet] [--service-subnet] [--disable-disk-encrypt] [--sm-group GROUP] [--sm-instance INSTANCE] [--trusted-profile-id]
   

   --zone <zone>

   Spécifiez l'ID de zone IBM Cloud que vous avez choisi précédemment et que vous souhaitez utiliser pour créer votre cluster.

   --flavor <flavor>

   Spécifiez la version du noeud worker que vous avez choisi précédemment.

   --hardware <shared_or_dedicated>

   Spécifiez le niveau d'isolement de matériel pour votre noeud worker. Utilisez dedicated pour que les ressources physiques disponibles vous soient dédiées exclusivement ou shared pour permettre leur partage avec d'autres clients IBM. La valeur par défaut est partagée. Cette valeur est facultative pour les clusters standard de MV. Pour les versions bare metal, indiquez dedicated.

   --public-vlan <public_vlan_id>

   Si vous disposez déjà d'un VLAN public configuré dans votre compte d'infrastructure IBM Cloud pour cette zone, entrez l'ID du VLAN public que vous avez extrait précédemment. Si vous n'avez pas de réseau local virtuel dans votre compte, ne spécifiez pas cette option. IBM Cloud Kubernetes Service crée automatiquement un réseau local virtuel pour vous. Les routeurs de VLAN privé commencent toujours par bcr (routeur de back end) et les routeurs de VLAN public par fcr (routeur de front-end). Lorsque vous créez un cluster et que vous spécifiez les VLAN publics et privés, le nombre et la combinaison de lettres après ces préfixes doivent correspondre.

   --private-vlan <private_vlan_id>

   Si vous disposez déjà d'un VLAN public configuré dans votre compte d'infrastructure IBM Cloud pour cette zone, entrez l'ID du VLAN privé que vous avez extrait précédemment. Si vous n'avez pas de réseau local virtuel privé dans votre compte, ne spécifiez pas cette option. IBM Cloud Kubernetes Service crée automatiquement un réseau local virtuel privé pour vous. Les routeurs de VLAN privé commencent toujours par bcr (routeur de back end) et les routeurs de VLAN public par fcr (routeur de front-end). Lorsque vous créez un cluster et que vous spécifiez les VLAN publics et privés, le nombre et la combinaison de lettres après ces préfixes doivent correspondre.

   --name <name>

   Indiquez un nom pour le cluster. Le nom doit commencer par une lettre, peut contenir des lettres, des nombres, des points (.) et des tirets (-) et ne doit pas dépasser 35 caractères. Utilisez un nom unique dans les régions. Le nom du cluster et la région dans laquelle est déployé le cluster constituent le nom de domaine qualifié complet du sous-domaine Ingress. Pour garantir que ce sous-domaine est unique dans une région, le nom de cluster peut être tronqué et complété par une valeur aléatoire dans le nom de domaine Ingress.

   --workers <number>

   Spécifiez le nombre de noeuds worker à inclure dans le cluster. La valeur par défaut est 1.

   --version <major.minor.patch>

   Version Red Hat OpenShift du noeud maître du cluster. Cette valeur est obligatoire. Lorsque la version n'est pas spécifiée, le cluster est créé avec la version par défaut Kubernetes prise en charge. Si vous ne spécifiez pas de version Red Hat OpenShift prise en charge, votre cluster est créé en tant que cluster Kubernetes de communauté. Pour voir les versions disponibles, exécutez la commande ibmcloud oc versions.

   --public-service-endpoint

   Activez le noeud final de service cloud public pour que le maître Red Hat OpenShift soit accessible sur le réseau public, par exemple pour exécuter des commandes oc depuis votre interface de ligne de commande et pour que votre maître Red Hat OpenShift et les noeuds worker puissent communiquer sur le VLAN public. Vous devez activer le noeud final de service de cloud public et ne pas le désactiver ultérieurement. Après avoir créé le cluster, vous pouvez obtenir le noeud final en exécutant ibmcloud oc cluster get --cluster <cluster_name_or_ID>.

   --private-service-endpoint

   Dans VRF-activé et les comptes de noeud final de service : Activez le noeud final de service de cloud privé pour que votre maître Red Hat OpenShift et les nœuds worker puissent communiquer sur le réseau local virtuel privé. Si vous spécifiez cette option, vous devez également activer le point de terminaison du service cloud public à l'aide de l'option --public-service-endpoint. Notez que vous ne pouvez pas modifier ultérieurement les nœuds finaux de service de cloud. Après avoir créé le cluster, vous pouvez obtenir le noeud final en exécutant ibmcloud oc cluster get --cluster <cluster_name_or_ID>.

   --pod-subnet

   Par défaut, tous les pods qui sont déployés sur un noeud worker se voient affecter une adresse IP privée comprise dans la plage 172.30.0.0/16. Si vous prévoyez de connecter votre cluster à des réseaux locaux 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 les pods. Lorsque vous choisissez une taille de sous-réseau, vous devez prendre en compte la taille du cluster que vous prévoyez de créer et le nombre de noeuds d'agent que vous êtes susceptible d'ajouter ultérieurement. 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. Notez que les sous-réseaux de pod et de service ne peuvent pas se chevaucher. Le sous-réseau du service se trouve dans la plage 172.21.0.0/16 par défaut. 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.254.255
   • 198.18.0.0 - 198.19.255.255

   --service-subnet

   Par défaut, tous les services qui sont déployés sur un cluster se voient affecter une adresse IP privée comprise dans la plage 172.21.0.0/16. 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 les services.

   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. 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.254.255 - 198.18.0.0 - 198.19.255.255

   Notez que les sous-réseaux de pod et de service ne peuvent pas se chevaucher. Le sous-réseau du pod se trouve dans la plage 172.30.0.0/16 par défaut.

   --disable-disk-encrypt

   Par défaut, les noeuds worker disposent du chiffrement de disque avec l'algorithme AES 256 bits. Incluez cette option si vous désirez désactiver le chiffrement.

   --entitlement ocp_entitled

   N'incluez cette option que pour un cluster disposant d'un Red Hat OpenShift droit. Lorsque vous spécifiez le nombre de nœuds de travail (--workers) et la configuration (--flavor), veillez à n'indiquer que le nombre et la taille des nœuds de travail que vous êtes autorisé à utiliser dans IBM Passport Advantage. Une fois votre cluster créé, la licence Red Hat OpenShift pour les noeuds worker que vous êtes autorisé à utiliser dans le pool de noeuds worker default ne vous est pas facturée. Ne dépassez pas les autorisations d'utilisation dont vous disposez. Gardez à l'esprit que les autorisations d'utilisation dont vous disposez pour OpenShift Container Platform peuvent être utilisées avec d'autres fournisseurs de cloud ou dans d'autres environnements. Pour éviter tout problème de facturation, prenez soin d'utiliser uniquement ce que vous êtes autorisé à utiliser. Par exemple, vous pouvez disposer d'une autorisation d'utilisation relative aux licences OCP pour deux noeuds worker de 4 UC et 16 Go de mémoire, et vous créez ce pool de noeuds worker avec deux noeuds worker de 4 UC et 16 Go de mémoire. Vous avez utilisé toute votre autorisation, et vous ne pouvez pas utiliser la même autorisation pour d'autres pools d'agents, fournisseurs de cloud ou environnements.

   --sm-group GROUP

   L'ID du groupe de secrets de l'instance d' Secrets Manager, où vos secrets sont stockés. Pour obtenir un ID de groupe de secrets, voir la référence de l'interface de ligne de commandeSecrets Manager.

   --sm-instance INSTANCE

   Le CRN de l'instance Secrets Manager. Pour obtenir le CRN d'une instance, exécutez ibmcloud oc ingress instance ls --cluster CLUSTER.

   --trusted-profile-id ID

   Spécifiez l'ID d'un profil de confiance existant à associer au cluster. Avec les profils de confiance, vous pouvez accorder l'accès aux ressources de votre compte sans avoir à gérer des informations d'identification IAM distinctes. Voir Configuration d'un profil de confiance pour plus d'informations.

8. Vérifiez que la création du cluster a été demandée. Pour les machines virtuelles, la commande des postes de noeud worker et la mise à disposition et la configuration du cluster dans votre compte peuvent prendre quelques minutes. Les machines physiques bare metal sont mises à disposition par interaction manuelle avec l'infrastructure IBM Cloud et cette opération peut prendre plus d'un jour ouvrable.

   ibmcloud oc cluster ls
   

   Lorsque la mise à disposition du maître Red Hat OpenShift est terminée, votre cluster passe à l'état (State) normal. Lorsque votre maître Red Hat OpenShift est prêt, la mise à disposition de vos noeuds worker est initiée.

   NAME         ID                         State      Created          Workers    Zone      Version     Resource Group Name   Provider
   mycluster    blrs3b1d0p0p2f7haq0g       normal   20170201162433   3          dal10     4.21.27_1544_openshift      Default             classic
   

   Votre cluster n'est pas à l'état normal ? Consultez la rubrique Débogage des clusters pour obtenir de l'aide. Par exemple, si votre cluster est mis à disposition dans un compte qui est protégé par un dispositif de passerelle de pare-feu, vous devez configurer vos paramètres de pare-feu pour autoriser le trafic sortant vers les ports et les adresses IP appropriés.

9. Vérifiez le statut des noeuds worker.

   ibmcloud oc worker ls --cluster <cluster_name_or_ID>
   

   Lorsque les noeuds worker sont prêts, leur état passe à normal et leur statut indique Ready. Lorsque le statut du noeud indique Ready, vous pouvez accéder au cluster. Notez que même si le cluster est prêt, certaines parties du cluster qui sont utilisées par d'autres services, telles que les secrets Ingress ou les secrets d'extraction d'image de registre, sont peut-être toujours en cours de traitement. Notez que si vous avez créé votre cluster avec un VLAN privé uniquement, aucune adresse IP publique n'est affectée à vos noeuds worker.

   ID                                                     Public IP        Private IP     Flavor              State    Status   Zone    Version
   kube-blrs3b1d0p0p2f7haq0g-mycluster-default-000001f7   169.xx.xxx.xxx  10.xxx.xx.xxx   u3c.2x4.encrypted   normal   Ready    dal10   1.35.7_1526
   

   A chaque noeud worker sont affectés un ID de noeud worker unique et un nom de domaine qui ne doivent pas être modifiés manuellement après la création du cluster. Si vous modifiez l'ID ou le nom de domaine, le Red Hat OpenShift maître ne pourra plus gérer votre cluster.

10. Facultatif: si vous avez créé votre cluster dans une région multizone, vous pouvez répartir le pool de workers par défaut entre les différentes zones afin d'améliorer la disponibilité du cluster.

11. Une fois votre cluster créé, vous pouvez commencer à gérer votre cluster en configurant votre session CLI.

Votre cluster est prêt pour vos charges de travail ! Vous pouvez également ajouter une balise à votre cluster pour faciliter la gestion des ressources IBM Cloud, telles que l'équipe ou le service de facturation qui utilise le cluster.

Exemples de commandes permettant de créer des clusters classiques

Exemple de commande permettant de créer un cluster Classic sur une machine virtuelle partagée.

ibmcloud oc cluster create classic --name my_cluster --version 4.21_openshift --zone dal10 --flavor b3c.4x16 --hardware shared --workers 3

Exemple de commande permettant de créer un cluster classique sur un serveur bare metal.

ibmcloud oc cluster create classic --name my_cluster --version 4.21_openshift --zone dal10 --flavor mb2c.4x32 --hardware dedicated --workers 3 --public-vlan <public_VLAN_ID> --private-vlan <private_VLAN_ID>

Exemple de commande permettant de créer un cluster Classic avec un droit d' IBM Cloud Pak, pour un pool de travail par défaut composé de 3 nœuds de travail dotés chacun de 4 cœurs et de 16 Mo de mémoire.

ibmcloud oc cluster create classic --name cloud_pak_cluster --version 4.21_openshift --zone dal10 --flavor b3c.4x16 --hardware dedicated --workers 3 --entitlement ENTITLEMENT --public-vlan PUBLIC-VLAN-ID --private-vlan PRIVATE-VLAN-ID [--operating-system (REDHAT_8_64)]

Exemple de commande pour créer un cluster classique avec des nœuds de travail RHEL 9.

ibmcloud oc cluster create classic --name my_cluster --zone dal10 --flavor b3c.4x16 --version 4.9.28_openshift --operating-system RHEL_9_64

Pour un cluster multizone classique, une fois que vous avez créé le cluster dans une métropole multizone, ajoutez des zones. Exemple de commande permettant d'ajouter une zone à un cluster classique.

ibmcloud oc zone add classic --zone <zone> --cluster <cluster_name_or_ID> --worker-pool <pool_name> --private-vlan <private_VLAN_ID> --public-vlan <public_VLAN_ID>

Création d'un cluster classique à zone unique avec Terraform

Terraform sur IBM Cloud permet une mise à disposition prévisible et cohérente de l'infrastructure et des ressources de la plateforme IBM Cloud, y compris les clusters classiques. Pour créer un cluster classique avec Terraform, vous devez d'abord créer un fichier de configuration Terraform qui déclare le type de ressource de cluster que vous souhaitez créer. Ensuite, vous appliquez le fichier de configuration Terraform. Pour plus d'informations sur Terraform, voir About Terraform on IBM Cloud.

Avant de commencer :

• Installez l'interface de ligne de commande Terraform et le plug-in IBM Cloud Provider.
• Assurez-vous que vous disposez d'une clé API IBM Cloud.

1. Créer un fichier de fournisseur Terraform. Sauvegardez le fichier dans votre répertoire Terraform. Pour plus d'informations, voir la documentation Terraform IBM Cloud Provider.

   Exemple de fichier de fournisseur Terraform.

   terraform {
   required_providers {
       ibm = {
       source = "IBM-Cloud/ibm"
       version = "1.53.0"
       }
   }
   }
   provider "ibm" {
   region = "us-south"
   ibmcloud_api_key = "<api-key>"
   }
   

2. Créez un fichier de configuration Terraform pour un cluster classique. Sauvegardez le fichier dans votre répertoire Terraform. L'exemple de configuration suivant crée un cluster classique avec trois nœuds de travail dans une zone. Pour plus d'informations et pour connaître les options de configuration de cluster, voir la documentation Terraform ibm_container_cluster.

   Exemple de fichier de configuration Terraform.

   resource "ibm_container_cluster" "testacc_cluster" {
   name            = "test-classic"
   datacenter      = "dal10"
   machine_type    = "b3c.4x16"
   hardware        = "shared"
   public_vlan_id  = "<vlan_id>"
   private_vlan_id = "<vlan_id"
   subnet_id       = ["<subnet_id>"]
   default_pool_size = 3
   }
   

   name

   Nom du cluster.

   datacenter

   La zone dans laquelle créer le cluster. Pour afficher les zones disponibles, exécutez ibmcloud oc zones --provider classic.

   machine_type

   Version du noeud worker. La version détermine la quantité de mémoire, d'UC et d'espace disque disponible pour vos noeuds worker. Pour obtenir la liste des versions de noeud worker disponibles, exécutez ibmcloud oc flavors --zone <zone> --provider classic ou consultez Versions classiques.

   hardware

   Le niveau d'isolation matérielle de vos nœuds de travail. Utilisez dedicated pour que les ressources physiques disponibles vous soient dédiées exclusivement ou shared pour permettre leur partage avec d'autres clients IBM. Cette option est disponible uniquement pour les versions de noeuds worker de machine virtuelle.

   public_vlan_id et private_vlan_id

   Optionnel. ID du VLAN public ou privé que vous souhaitez utiliser pour vos noeuds worker. Pour trouver les VLAN et les sous-réseaux disponibles, exécutez ibmcloud oc vlans --zone <zone>.

   subnet_id

   Optionnel. ID d'un sous-réseau existant que vous souhaitez utiliser pour vos noeuds worker. Pour rechercher des sous-réseaux existants, exécutez ibmcloud oc subnets --provider classic --zone <zone>.

   default_pool_size

   Nombre de noeuds worker que vous souhaitez ajouter au pool de noeuds worker par défaut.

3. Dans l'interface de ligne de commande, accédez à votre répertoire Terraform.

   cd <terraform_directory>
   

4. Exécutez les commandes pour initialiser et planifier vos actions Terraform. Vérifiez la sortie du plan pour vous assurer que les actions correctes sont effectuées.

   terraform init
   

   terraform plan
   

5. Appliquez les fichiers Terraform pour créer le cluster. Accédez ensuite à la console IBM Cloud pour vérifier que le cluster est mis à disposition.

   terraform apply