Création d'un cluster VPC dans la console

Créez votre cluster VPC d' Red Hat OpenShift s à l'aide de la console IBM Cloud. Suivez les instructions de la console pour effectuer les configurations de cluster suivantes. Pour commencer à créer votre cluster, accédez à la console et cliquez sur Créer un cluster.

Virtual Private Cloud

Sélectionnez l'instance Virtual Private Cloud (VPC) existante dans laquelle vous souhaitez créer votre cluster. Si vous ne disposez pas d'un VPC, vous pouvez en créer un.

Emplacement

Passez en revue les zones de noeud worker et les sous-réseaux de votre cluster. Les zones sont filtrées en fonction du VPC que vous avez sélectionné, et incluent les sous-réseaux VPC que vous avez créés précédemment. En fonction du niveau de disponibilité souhaité pour votre cluster, sélectionnez une ou plusieurs zones. Par défaut, les ressources de votre cluster sont réparties sur trois zones pour la haute disponibilité. Vous pouvez ajouter des zones à votre cluster ultérieurement.

Version

Sélectionnez votre version de cluster. Par défaut, les clusters sont créés avec la version Kubernetes par défaut, mais vous pouvez spécifier une autre version prise en charge.

Licence

Appliquez une autorisation d'utilisation ou achetez une licence pour votre cluster. Pour plus d'informations, voir Affectation de licences logicielles à votre compte, Ajout de packages Cloud Pak, d'autorisations ou de licences à votre cluster et la foire aux questionsCloud Pak.

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.

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

• Configuration: la configuration définit l'architecture, le nombre de cœurs de processeur virtuels, la mémoire, le nombre de GPU et l'espace disque configurés sur chaque nœud de travail et mis à la disposition des conteneurs. Les types de machines virtuelles et bare metal disponibles varient en fonction de la zone de déploiement du cluster. Pour obtenir la liste des versions disponibles, voir VPC flavors.
• Lorsque vous choisissez une version dans la console, vous pouvez filtrer les versions disponibles par Type de machine, Architecture et Système d'exploitation. Les types de machine disponibles sont shared ou dedicated. Notez que l'option dedicated n'est disponible que si vous disposez déjà d'un pool d'hôtes dédié dans votre compte. Pour obtenir la liste des systèmes d'exploitation et des architectures disponibles par version de cluster, voir les versions disponibles.

• 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. Si vous activez le chiffrement, chaque noeud worker du pool de noeuds worker est chiffré à l'aide des données d'identification du fournisseur KMS que vous gérez. Seuls les noeuds du pool de noeuds worker default sont chiffrés. Une fois que vous avez créé le cluster, si vous créez d'autres pools de noeuds worker, vous devez activer le chiffrement dans chaque pool séparément. Chaque pool de noeuds worker de votre cluster peut utiliser la même instance KMS et la même clé racine, la même instance KMS avec des clés racine différentes ou des instances différentes.

• Stockage secondaire: Vous pouvez mettre à disposition un disque secondaire sur vos noeuds worker, tel qu'un disque de stockage par blocs 900gb.5iops-tier. Lorsque vous ajoutez un disque secondaire, ce disque est utilisé pour l'environnement d'exécution de conteneur, tandis que le disque principal est utilisé pour le système d'exploitation. Les disques secondaires sont utiles dans les scénarios où davantage de stockage de conteneur est nécessaire, comme l'exécution de pods avec des images volumineuses. Notez que lors de l'utilisation du stockage secondaire, les pods peuvent ne pas être en mesure d'utiliser l'intégralité des capacités IOPS/bande passante des volumes en raison des systèmes de fichiers superposés. Les disques secondaires sont mis à disposition dans votre compte et vous pouvez les voir dans la console VPC. Les frais de ces disques sont distincts du coût de chaque travailleur et apparaissent sous la forme d'une ligne distincte sur votre facture. Ces volumes secondaires sont également pris en compte dans le calcul de l'utilisation du quota de votre compte. Si vous prévoyez d'utiliser le stockage secondaire sur des noeuds sur lesquels des volumes persistants peuvent être connectés, il est fortement recommandé d'utiliser les niveaux 10-iops ou supérieurs. En effet, l'allocation de bande passante de stockage pour les noeuds est partagée entre les volumes de stockage secondaires et les réservations de volume persistant associées. Lors de l'utilisation de 5-iops, les niveaux peuvent entraîner une dégradation des performances lors de l'extraction d'images ou de l'écriture de pods dans le stockage. Pour plus d'informations sur l'allocation de bande passante, consultez la section Allocation de bande passante dans les instances de serveur virtuel.

• GPU: Si vous prévoyez de déployer des charges de travail d'IA, visuelles ou graphiques de haute qualité dans votre cluster, veillez à sélectionner une variante de nœud de travail GPU.

Des types d'arômes supplémentaires, y compris les arômes avec NVIDIA V100, A100, H100, et H200 GPU, sont disponibles uniquement pour les comptes figurant sur la liste blanche. Pour demander l'accès à d'autres versions sur liste autorisée, demandez l'accès à la liste autorisée.

Chiffrement du pool de nœuds worker

Gérez le chiffrement de vos nœuds de travail en activant un fournisseur de service de gestion des clés (KMS) au niveau du pool de nœuds de travail. Sélectionnez votre instance KMS et votre CRN.

Plug-in réseau 4.20 ou version ultérieure

Sélectionnez l'interface réseau de conteneur (CNI) que vous souhaitez utiliser. Choisissez entre « Calico » et « Open Virtual Network ». Veuillez noter qu’Open Virtual Network est disponible uniquement pour les nœuds de travail RHCOS et pour la version 4.20 et les versions ultérieures du cluster d’ OpenShift. Pour plus d'informations, consultez la section « Sélection d'une interface réseau de conteneur(CNI) ».

Paramètres réseau

Les noeuds finaux de service fournissent la communication au maître. Vous pouvez choisir de configurer votre cluster avec un noeud final de service public ou à la fois un noeud final de service de cloud public et un noeud final de service de cloud 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.

Registre interne

Sélectionnez votre instance COS. Les images de conteneur stockées dans le registre interne de votre cluster Red Hat OpenShift on IBM Cloud sont automatiquement sauvegardées dans un compartiment Object Storage. Les données stockées dans le compartiment de stockage d'objets sont conservées même si vous supprimez le cluster.

Protection du trafic sortant

Le comportement par défaut des clusters de la version 4.15 et des versions ultérieures consiste à autoriser uniquement le trafic réseau nécessaire au cluster à fonctionner et à désactiver toutes les autres connexions sortantes. Si vous disposez d'applications ou de services qui nécessitent une connexion à l'Internet public, tels que GitHub référentiels, Docker Moyeu,quay.io, le Red Hat Marketplace et OperatorHub, notez que vous devez soit désactiver complètement la protection du trafic sortant (afin que tout le trafic sortant soit autorisé), soit ajouter des règles de groupe de sécurité pour autoriser uniquement le trafic sortant dont vous avez besoin.

Chiffrement de cluster

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.

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.

Groupes de sécurité VPC

Fournissez jusqu’à quatre groupes de sécurité personnalisés à appliquer à tous les nœuds de travail du cluster VPC, en plus du groupe de sécurité kube-<clusterID>. Pour plus d'informations, voir Comprendre la mise en réseau VPC en cluster Secure by Default.

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.

Choisissez le groupe de ressources dans lequel créer votre cluster. 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. 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.

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 et Protection de la charge de travail: l'intégration du service de surveillance permet d'obtenir une visibilité opérationnelle sur les performances et l'état de santé de vos applications, services et plateformes. Si vous désactivez cette intégration et souhaitez l'activer ultérieurement, voir Surveillance de l'état des clusters. L'intégration du Security and Compliance Center Workload Protection détecte 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é de la source à 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 de clusters VPC à partir de l'interface de ligne de commande (CLI)

• Assurez-vous de remplir les conditions préalables pour préparer votre compte et définir la configuration de votre cluster.
• Installez l'interface de ligne de commande IBM Cloud et le plug-in Red Hat OpenShift on IBM Cloud.
• Installez le plug-in de l'interface de ligne de commande VPC.

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. 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. Les clusters de noeuds worker de votre VPC ont-ils besoin d'envoyer et de recevoir des informations vers et depuis une infrastructure IBM Cloud classique ? Suivez les étapes de la section Création de sous-réseaux VPC pour l'accès classique afin de créer un VPC activé pour l'accès classique et des sous-réseaux VPC sans préfixes d'adresse par défaut automatique.

3. Créez un sous-réseau pour votre VPC.

   • Si vous souhaitez créer un cluster multizone, répétez cette étape pour créer des sous-réseaux supplémentaires dans toutes les zones que vous souhaitez inclure dans votre cluster.
   • 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.
   • Si les noeuds worker doivent accéder à des noeuds finaux publics ou que vous prévoyez d'activer les noeuds finaux de service cloud public et privé, vous devez connecter une passerelle publique à chaque sous-réseau pour accéder aux composants Red Hat OpenShift par défaut, tels que la console Web ou OperatorHub.
   • Important : Ne supprimez pas les sous-réseaux que vous avez associés à 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.
   • Pour plus d'informations, voir Présentation de la mise en réseau VPC dans Red Hat OpenShift on IBM Cloud : Sous-réseaux.

4. Créez le cluster dans votre VPC. Vous pouvez utiliser la commande ibmcloud oc cluster create vpc-gen2 pour créer un cluster à zone unique dans votre VPC avec des noeuds worker connectés à un seul sous-réseau VPC. 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éé. La mise à disposition du cluster prend quelques minutes.

   ibmcloud oc cluster create vpc-gen2 --name CLUSTER_NAME --zone VPC_ZONE --vpc-id VPC_ID --subnet-id VPC_SUBNET_ID --flavor WORKER_FLAVOR --version 4.21_openshift --cos-instance COS_CRN --workers NUMBER_WORKERS_PER_ZONE [--offering OFFERING] [--sm-group GROUP] [--sm-instance INSTANCE] [--trusted-profile-id ID] [--pod-subnet] [--service-subnet] [--disable-public-service-endpoint] [[--kms-account-id KMS_ACCOUNT_ID] --kms-instance KMS_INSTANCE_ID --crk ROOT_KEY_ID] [--secondary-storage STORAGE] [--disable-outbound-traffic-protection] [--operating-system SYSTEM] [--cni CNI]
   

   --name <cluster_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.

   --zone <zone>

   Indiquez la zone IBM Cloud dans laquelle vous souhaitez créer votre cluster. Prenez soin d'utiliser une zone qui correspond à l'emplacement de métropole que vous avez sélectionné lors de la création de votre VPC et que vous disposez d'un sous-réseau VPC existant pour cette zone. Par exemple, si vous avez créé votre VPC dans la métropole de Dallas, la valeur us-south-1, us-south-2ou us-south-3 doit être affectée à votre zone. Pour répertorier les zones de cluster de VPC disponibles, exécutez la commande ibmcloud oc zone ls --provider vpc-gen2. Notez que lorsque vous sélectionnez une zone en dehors de votre pays, une autorisation légale peut être nécessaire pour que les données puissent être physiquement stockées dans un pays étranger.

   --vpc-id <vpc_ID>

   Entrez l'ID du VPC que vous avez créé précédemment. Pour extraire l'ID de votre VPC, exécutez ibmcloud oc vpcs.

   --subnet-id <subnet_ID>

   Entrez l'ID du sous-réseau VPC que vous avez créé précédemment. Lorsque vous créez un cluster de VPC à partir de l'interface de ligne de commande, vous pouvez initialement créer votre cluster dans une zone avec un seul sous-réseau. Pour créer un cluster multizone, ajoutez d'autres zones avec les sous-réseaux que vous avez créés précédemment à votre cluster une fois celui-ci créé. Pour répertorier les ID de vos sous-réseaux dans tous les groupes de ressources, exécutez ibmcloud oc subnets --provider vpc-gen2 --vpc-id &lt,VPC_ID> --zone <subnet_zone>.

   --flavor <worker_flavor>

   Entrez la version de noeud worker que vous souhaitez utiliser. 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 VPC ne peuvent être créés en tant que machines virtuelles que sur une infrastructure partagée. Les machines bare metal ou SDS ne sont pas prises en charge. Pour afficher les versions disponibles, commencez par répertorier les zones VPC disponibles à l'aide de ibmcloud oc zone ls --provider vpc-gen2, puis utilisez la zone pour répertorier les versions prises en charge en exécutant ibmcloud oc flavors --zone <VPC_zone> --provider vpc-gen2. Après avoir créé votre cluster, vous pouvez ajouter différentes versions en ajoutant un noeud worker ou un pool de noeuds worker au cluster.

   --version 4.21_openshift

   Version Red Hat OpenShift du noeud maître du cluster. Pour voir les versions disponibles, exécutez la commande ibmcloud oc versions.

   --cos-instance <cos_CRN>

   Inclure l'ID CRN d'une instance IBM Cloud Object Storage standard pour sauvegarder le registre interne de votre cluster. Pour répertorier le CRN des instances existantes, exécutez la commande ibmcloud resource service-instances --long et recherchez l'ID de votre instance de stockage d'objets. Pour créer une instance de stockage d'objet standard, exécutez ibmcloud resource service-instance-create <name> cloud-object-storage standard global et notez son ID.

   --workers <number>

   Spécifiez le nombre de noeuds worker à inclure dans le cluster. Si vous ne spécifiez pas cette option, un cluster dont la valeur minimale est 1 est créé.

   --operating-system RHEL_9_64|REDHAT_8_64|RHCOS: Facultatif. Système d'exploitation des noeuds worker dans votre cluster. Pour obtenir une liste des systèmes d'exploitation disponibles par version de cluster, consultez les informations relatives à la version du site Red Hat OpenShift on IBM Cloud. Si aucune option n'est spécifiée, le système d'exploitation par défaut correspondant à la version de la grappe est utilisé.

   --offering <offering>

   Optionnel. Indiquez le type d'offre de cluster. Les valeurs autorisées sont kubernetes, openshift et openshift-vs. Utilisez openshift-vs pour créer un cluster « Red Hat OpenShift Virtualization Service » doté de fonctionnalités de virtualisation préconfigurées. Pour plus d'informations, consultez la présentation du service de virtualisation « Red Hat OpenShift ».

   --cluster-security-group <group_ID>

   Optionnel. Indiquez un ou plusieurs ID groupe de sécurité à appliquer à tous les noeuds worker du cluster. Pour OpenShift version 4.15 et Kubernetes version 1.30 et versions ultérieures, ces groupes de sécurité sont appliqués en plus du groupe de sécurité IBM kube-clusterID. Pour les versions de cluster antérieures, spécifiez l'option --cluster-security-group cluster pour appliquer le groupe de sécurité kube-clusterID. Si aucune valeur n'est spécifiée, un ensemble par défaut de groupes de sécurité incluant kube-clusterID est appliqué. Pour plus d'informations, voir Ajout de groupes de sécurité VPC aux clusters et aux pools de noeuds worker lors de la création.

   Les groupes de sécurité appliqués à un cluster ne peuvent pas être modifiés une fois le cluster créé. Vous pouvez modifier les règles des groupes de sécurité qui sont appliqués au cluster, mais vous ne pouvez pas ajouter ou supprimer des groupes de sécurité au niveau du cluster. Si vous appliquez les groupes de sécurité incorrects lors de la création du cluster, vous devez supprimer le cluster et créez en un nouveau. Voir Ajout de groupes de sécurité VPC aux clusters et aux pools de noeuds worker lors de la création pour plus de détails avant d'ajouter des groupes de sécurité à votre cluster.

   --sm-group GROUP

   Optionnel. 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. Utilisez cette option pour spécifier un groupe de secrets qui contrôle qui, dans votre équipe, a accès aux secrets de cluster.

   --sm-instance INSTANCE

   Optionnel. Le CRN de l'instance Secrets Manager. Pour obtenir le CRN d'une instance, exécutez ibmcloud oc ingress instance ls --cluster CLUSTER. Incluez cette option si vous souhaitez enregistrer une instance Secrets Manager dans le 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.

   --pod-subnet

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

   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.

   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 CIDR d'au moins /23, ce qui fournit suffisamment d'adresses IP de pod pour un maximum de quatre nœuds de travail 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. Si vous utilisez des sous-réseaux à plage personnalisée pour vos nœuds de travail, vous devez vous assurer que les sous-réseaux de vos nœuds de travail ne chevauchent pas le sous-réseau de pods de votre cluster. Le sous-réseau que vous choisissez doit être compris 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 d'au moins /24, ce qui permet un maximum de 255 services dans le cluster ou plus. Le sous-réseau que vous choisissez doit être compris 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.

   --disable-public-service-endpoint

   Incluez cette option dans votre commande pour créer votre cluster de VPC avec un noeud final de service cloud privé uniquement. Si vous n'incluez pas cette option, votre cluster est configuré avec un nœud final de service de cloud public et privé. Le noeud final de service détermine comment votre maître Red Hat OpenShift et les noeuds worker communiquent, comment votre cluster peut accéder à d'autres services et applications IBM Cloud en dehors du cluster et comment vos utilisateurs se connectent à votre cluster. Pour plus d'informations, voir Planification de la configuration réseau de votre cluster. Si vous activez cette option, votre cluster est créé avec des routeurs et des contrôleurs Ingress qui, par défaut, exposent vos applications uniquement sur le réseau privé. Si vous souhaitez ultérieurement exposer des applications sur un réseau public, vous devez créer manuellement des routeurs publics et des contrôleurs Ingress.

   --kms-account-id <KMS_acount_ID>

   Facultatif: doit être inclus si les options --kms-instance-id et --crk sont fournies et que l'instance KMS réside dans un compte différent du compte du cluster, sinon elle peut être omise. La configuration du chiffrement à l'aide d'un KMS à partir d'un autre compte est disponible uniquement pour les comptes sur liste autorisée. Pour être ajouté à la liste autorisée, ouvrez un cas avec le support.

   --kms-instance <KMS_instance_ID>

   Facultatif : incluez l'ID d'une instance de service de gestion de clés (KMS) à utiliser pour chiffrer le disque local sur les nœuds worker dans le pool d'agents default. Pour répertorier les instances KMS disponibles, exécutez la commande ibmcloud oc kms instance ls. Si vous incluez cette option, vous devez également inclure l'option --crk. Pour pouvoir utiliser le chiffrement KMS, vous devez créer une instance KMS et configurer l'autorisation de service requise dans IAM. Voir Gestion du chiffrement des noeuds worker de votre cluster.

   --crk <root_key>

   Facultatif : incluez l'ID de la clé racine dans l'instance KMS à utiliser pour chiffrer le disque local sur les nœuds worker dans le pool d'agents default. Pour répertorier les clés racine disponibles, exécutez la commande ibmcloud oc kms crk ls --instance-id. Si vous incluez cette option, vous devez également inclure l'option --kms-instance. Pour pouvoir utiliser le chiffrement KMS, vous devez créer une instance KMS et configurer l'autorisation de service requise dans IAM. Voir Gestion du chiffrement des noeuds worker de votre cluster.

   --secondary-storage STORAGE

   Optionnel. L'option de stockage pour cette variante. Par exemple, 900gb.5iops-tier. Lorsque vous ajoutez un disque secondaire, ce disque est utilisé pour l'environnement d'exécution de conteneur, tandis que le disque principal est utilisé pour le système d'exploitation. Pour afficher les options de stockage d'une version, exécutez la commande ibmcloud oc flavor get --flavor FLAVOR --zone ZONE --provider vpc-gen2. Pour afficher la liste des versions de noeud worker VPC, voir VPC flavors.

   --disable-outbound-traffic-protection

   Optionnel. Désactiver la protection du trafic sortant.

   --cni CNI

   Définir le plugin réseau pour le cluster. Calico est défini par défaut. Valeurs acceptées : Calico, OVNKubernetes.

   --offering OFFERING

   Optionnel. Indiquez le type d'offre de cluster. Utilisez openshift-vs pour créer un cluster de services de virtualisation « Red Hat OpenShift » doté de fonctionnalités de virtualisation préconfigurées. Si aucune option n'est spécifiée, un cluster « OpenShift » standard est créé. Pour plus d'informations, consultez la présentation du service de virtualisation « Red Hat OpenShift ».

5. Vérifiez que la création du cluster a été demandée. La commande des machines de noeud worker et la configuration et la mise à disposition du cluster dans votre compte peuvent prendre quelques minutes.

   ibmcloud oc cluster ls
   

   Lorsque la mise à disposition du maître Red Hat OpenShift est terminée, le cluster passe à l'état normal. Lorsque le maître Red Hat OpenShift est prêt, vos noeuds worker sont configurés.

   NAME         ID                                   State      Created          Workers    Zone      Version     Resource Group Name   Provider
   mycluster    aaf97a8843a29941b49a598f516da72101   normal   20170201162433   3          Dallas     4.21.27_1544_openshift      Default               vpc-gen2
   

6. Vérifiez le statut des noeuds worker.

   ibmcloud oc worker ls --cluster <cluster_name_or_ID>
   

   Lorsque les noeuds worker sont prêts, ils passent à l'état (State) normal et prennent le statut (Status) Ready. Lorsque le noeud prend le statut (Status) 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.

   ID                                                     Public IP        Private IP     Flavor              State    Status   Zone    Version
   kube-blrs3b1d0p0p2f7haq0g-mycluster-default-000001f7   169.xx.xxx.xxx  10.xxx.xx.xxx   b3c.4x16.encrypted  normal   Ready    dal10   4.21.27_1544_openshift
   

   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.

Exemples de commandes permettant de créer des clusters de VPC

Les versions avec stockage d'instance sont disponibles pour les comptes sur liste autorisée. Pour être ajouté à la liste autorisée, ouvrez un cas avec le support.

Exemple de commande permettant de créer un cluster de VPC avec 3 noeuds worker dans us-east-1.

ibmcloud oc cluster create vpc-gen2 --name my_cluster --version 4.21_openshift --zone us-east-1 --vpc-id VPC-ID --subnet-id VPC-SUBNET-ID --cos-instance COS-CRN--flavor bx2.4x16 --workers 3

Exemple de commande pour créer un cluster VPC avec 3 nœuds de travail dans 'us-east-1 avec une plage et une taille de sous-réseau de pod personnalisées et une protection du trafic sortant désactivée.

ibmcloud oc cluster create vpc-gen2 --name my_cluster --version 4.21_openshift --zone us-east-1 --vpc-id VPC-ID --subnet-id VPC-SUBNET-ID --cos-instance COS-CRN --flavor bx2.4x16 --workers 3 --pod-subnet 0.0.0.0/15 --disable-outbound-traffic-protection

Exemple de commande pour un cluster de VPC avec des noeuds worker qui exécutent le système d'exploitation Red Hat CoreOS (RHCOS).

ibmcloud oc cluster create vpc-gen2 --name my_cluster --zone us-south-1 --flavor b3c.4x16 --vpc_ID VPC-ID --subnet-id SUBNET-ID --operating-system RHCOS

Exemple de commande pour un cluster VPC avec des nœuds de travail exécutant le système d'exploitation RHEL 9 et une protection du trafic sortant désactivée.

ibmcloud oc cluster create vpc-gen2 --name my_cluster --zone us-south-1 --flavor b3c.4x16 --vpc_ID VPC-ID --subnet-id SUBNET-ID --operating-system RHEL_9_64 --disable-outbound-traffic-protection

Exemple de commande permettant de créer un cluster avec 3 noeuds worker dans us-south-1 et d'activer le chiffrement de disque de noeud worker en fournissant l'ID d'instance de votre fournisseur KMS, l'ID de compte et CRK.

ibmcloud oc cluster create vpc-gen2 --name <cluster_name> --zone us-south-1 --vpc-id VPC-ID --subnet-id SUBNET-ID --flavor b3c.4x16 --workers 3 --kms-account-id KMS-ACCOUNT-ID --kms-instance-id KMS-INSTANCE-ID --crk CRK

Exemple de commande pour ajouter des nœuds de travailleur en ajoutant une zone à un cluster VPC multizone.

ibmcloud oc zone add vpc-gen2 --zone ZONE --cluster <cluster_name_or_ID> --worker-pool WORKER-POOL --subnet-id SUBNET-ID

Création d'un cluster VPC avec Terraform

• Terraform sur IBM Cloud permet un approvisionnement prévisible et cohérent de l'infrastructure et IBM Cloud des ressources de la plateforme, y compris les clusters VPC.

• Pour créer un cluster VPC 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, consultez la section À propos de Terraform sur IBM Cloud.

• Le module Terraform IBM- Red Hat OpenShift VPC cluster on IBM Cloud comprend un code d'infrastructure prêt à l'emploi et des exemples pratiques qui peuvent accélérer votre déploiement. Si vous cherchez à provisionner rapidement et de manière cohérente un environnement OpenShift de niveau entreprise, ce module est un excellent point de départ.

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. a) Créer un fichier de configuration Terraform pour un cluster VPC. Sauvegardez le fichier dans votre répertoire Terraform. 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_vpc_cluster" "cluster" {
       name              = "tf-vpc"
       vpc_id            = "<vpc_id>"
       flavor            = "bx2.16x64"
       worker_count      = "3"
       operating_system  = "REDHAT_8_64"
       kube_version      = "1.28.2"
       resource_group_id = "<resource_group_id>"
       zones {
           subnet_id = "<subnet_id>"
           name      = "us-south-1"
       }
   }
   

   name

   Obligatoire. Nom du cluster.

   vpc_id

   Obligatoire. L'ID du VPC que vous souhaitez utiliser pour votre cluster. Pour répertorier les VPC disponibles, exécutez ibmcloud is vpcs.

   flavor

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

   worker_count

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

   operating_system

   Système d'exploitation des noeuds worker dans le pool de noeuds worker. Pour obtenir la liste des systèmes d'exploitation pris en charge par version de cluster, voir Informations sur la version deRed Hat OpenShift on IBM Cloud.

   kube_version

   La version Kubernetes de votre cluster. Par défaut, les clusters sont créés avec la version Kubernetes par défaut, mais vous pouvez spécifier une autre version prise en charge.

   resource_group_id

   ID du groupe de ressources. Pour afficher les groupes de ressources disponibles, exécutez ibmcloud resource groups. Si aucune valeur n'est fournie, le groupe de ressources par défaut est utilisé.

   zones

   Bloc imbriqué qui décrit les zones du pool de noeuds worker par défaut du cluster VPC.

   • subnet_id: obligatoire. ID du sous-réseau VPC que vous souhaitez utiliser pour vos noeuds worker. Pour rechercher des sous-réseaux existants, exécutez ibmcloud oc subnets --provider classic --zone <zone>.

   • name: Obligatoire. Nom de zone du pool de noeuds worker par défaut. Pour afficher les zones disponibles, exécutez ibmcloud oc zones --provider vpc-gen2.

   b) Si vous préférez utiliser Terraform IBM Modules, vous pouvez vous référer à l'exemple ci-dessous pour l'approvisionnement Red Hat OpenShift Cluster sur VPC Gen2

       locals {
           worker_pools = [
               {
                   subnet_prefix    = "default"
                   pool_name        = "default"
                   machine_type     = "bx2.4x16"
                   workers_per_zone = 2
                   operating_system = "RHCOS"
               }
           ]
           cluster_vpc_subnets = {
               default    = [
                   {
                       id         = "0717-afc29fbb-0dbe-493a-a5b9-f3c5899cb8b9"
                       cidr_block = "192.168.32.0/22"                        
                       zone       = "us-south-1"
                   }
               ]
           }
       }
       module "ocp_base" {
           source               = "terraform-ibm-modules/base-ocp-vpc/ibm"
           version              = "3.81.3"
           region               = "us-south"
           resource_group_id    = "resource-group-id"
           cluster_name         = "test-ocp-cluster"
           force_delete_storage = true
           vpc_id               = "vpc-id"
           vpc_subnets          = local.cluster_vpc_subnets
           worker_pools         = local.worker_pools
       }
   

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