Description de Red Hat OpenShift on IBM Cloud
Découvrez-en davantage sur Red Hat® OpenShift® on IBM Cloud®, ses fonctionnalités et les options qui s'offrent à vous pour personnaliser le cluster en fonction de vos besoins.
Red Hat OpenShift on IBM Cloud est une offre gérée qui permet de créer votre propre cluster Red Hat OpenShift de serveurs de traitement pour déployer et gérer des applications conteneurisées sous IBM Cloud. Red Hat OpenShift on IBM Cloud fournit une planification intelligente, une réparation spontanée, une mise à l'échelle horizontale, une reconnaissance de service et un équilibrage de charge, des annulations et des annulations automatisées, ainsi que la gestion secrète et la gestion de la configuration de vos applications. Associé à une expérience utilisateur intuitive, une sécurité et un isolement intégrés et des outils avancés, il vous permet de sécuriser, gérer et surveiller vos charges de travail de cluster et de fournir rapidement des applications conteneurisées hautement disponibles et sécurisées dans le cloud public.
Passez en revue les questions fréquemment posées au sujet de Red Hat OpenShift on IBM Cloud et les principales technologies utilisées par ce produit.
Qu'est-ce que Kubernetes ?
Kubernetes est une plateforme open source utilisée pour gérer des charges de travail et des services conteneurisés sur plusieurs hôtes et offrir des outils de gestion pour déployer, automatiser, surveiller et mettre à l'échelle des applications conteneurisées avec une intervention manuelle minimale voire nulle.
Le projet open source Kubernetes combine l'exécution d'une infrastructure conteneurisée avec des charges de travail de production, des contributions open source et des outils de gestion de conteneurs d' Docker. L'infrastructure d' Kubernetes s fournit une plateforme d'applications isolée et sécurisée pour la gestion des conteneurs. Elle est portable, extensible et capable de s'auto-réparer en cas de basculement. Pour plus d'informations, voir Qu'est-ce que Kubernetes?.
Découvrez les principaux concepts de Kubernetes illustrés dans l'image ci-après.
- Compte
-
Les termes "votre compte" font référence à votre compte IBM Cloud.
- Cluster, pool de noeuds worker et noeud worker
-
Un cluster Kubernetes est composé d'un maître et d'un ou de plusieurs hôtes de calcul dénommés noeuds worker. Les noeuds worker sont organisés en pools de noeuds worker de même version ou profil d'UC, mémoire, système d'exploitation, disques connectés et autres propriétés. Les noeuds worker correspondent à la ressource Kubernetes
Nodeet sont gérés par un maître Kubernetes qui centralise le contrôle et la surveillance de toutes les ressources Kubernetes dans le cluster. Par conséquent, lorsque vous déployez les ressources pour une application conteneurisée, la maître Kubernetes décide sur quel noeud worker déployer ces ressources, en prenant en compte les exigences de déploiement et la capacité disponible dans le cluster. Les ressources Kubernetes incluent des services, des déploiements et des pods. - Espace de nom
-
Les espaces de noms Kubernetes sont un moyen de diviser vos ressources de cluster en zones distinctes pour lesquelles vous pouvez déployer des applications et restreindre l'accès, par exemple si vous voulez partager le cluster avec plusieurs équipes. Ainsi, les ressources système configurées pour vous sont conservées dans des espaces de noms distincts, tels que
kube-systemoribm-system. Si vous ne désigez pas un espace de nom lorsque vous créez une ressource Kubernetes, la ressource est automatiquement créée dans l'espace de nomdefault. - Service
-
Un service est une ressource Kubernetes qui regroupe un ensemble de pods et fournit la connectivité réseau à ces pods sans exposer l'adresse IP privée réelle de chaque pod. Vous pouvez utiliser un service pour rendre votre application accessible dans votre cluster ou sur l'Internet public.
- Déploiement
-
Un déploiement est une ressource Kubernetes où vous pouvez spécifier des informations sur d'autres ressources ou capacités requises pour exécuter votre application, telles que services, stockage persistant ou annotations. Vous documentez un déploiement dans un fichier de configuration YAML que vous appliquez au cluster. Le maître Kubernetes configure les ressources et déploie des conteneurs dans des pods sur les noeuds worker avec la capacité disponible.
-
Définissez des stratégies de mise à jour de votre application, notamment le nombre de pods que vous voulez ajouter lors d'une mise à jour en continu et le nombre de pods pouvant être indisponibles à un moment donné. Lorsque vous effectuez une mise à jour en continu, le déploiement vérifie si la mise à jour fonctionne et l'arrête si des échecs sont détectés.
-
Un déploiement est simplement un type de contrôleur de charge de travail que vous pouvez utiliser pour gérer des pods. Pour vous aider à choisir vos options, voir Quel type d'objets Kubernetes puis-je créer pour mon application ?. Pour plus d'informations sur les déploiements, consultez la documentation Kubernetes.
- Pod
-
Chaque application conteneurisée qui est déployée dans un cluster est déployée, exécutée et gérée par une ressource Kubernetes appelée pod. Les pods sont de petites unités déployables dans un cluster Kubernetes et servent à regrouper des conteneurs devant être traités comme une seule unité. Normalement, chaque conteneur est déployé dans son propre pod. Toutefois, une application peut nécessiter qu'un conteneur et d'autres conteneurs auxiliaires soient déployés dans un même pod afin qu'ils soient accessibles via la même adresse IP privée.
- Appli
-
Une application peut se référer à une application complète ou à un composant d'une application. Vous pourriez déployer des composants d'une application dans des composants distincts ou des noeuds worker distincts. Pour plus d'informations, voir Planification de déploiements d'application et Développement d'applications natives Kubernetes.
Pour approfondir le sujet Kubernetes, consultez la Kubernetes documentation.
Que sont les conteneurs ?
Les conteneurs constituent un moyen standard de conditionner le code, les configurations et les dépendances de votre application dans une seule unité qui peut s'exécuter en tant que processus isolé des ressources sur un serveur de calcul. Pour exécuter votre application sur IBM Cloud, vous devez d'abord la conteneuriser en créant une image de conteneur que vous stockez dans un registre de conteneurs.
Passez en revue les termes suivants pour vous familiariser avec les concepts.
- Conteneur
- Un conteneur est une application qui est packagée avec toutes ses dépendances afin que l'application puisse être déplacée d'un environnement à l'autre et exécutée sans modification. Contrairement aux machines virtuelles, les conteneurs ne virtualisent pas un périphérique, son système d'exploitation et le matériel sous-jacent. Seuls le code d'application, l'environnement d'exécution, les outils système, les bibliothèques et les paramètres sont inclus dans le conteneur. Les conteneurs opèrent sous forme de processus isolés sur des hôtes de traitement et partagent le système d'exploitation hôte et ses ressources matérielles. Cette approche rend le conteneur encore plus léger, portable et efficace qu'une machine virtuelle.
- Image
- Une image de conteneur est un paquet qui comprend les fichiers, les paramètres de configuration et les bibliothèques nécessaires à l'exécution d'un conteneur. Une image est construite à partir d'un fichier texte appelé Dockerfile. Les Dockerfiles définissent comment construire l'image et quels artefacts y inclure. Les artefacts inclus dans un conteneur comprennent le code de l'application, les paramètres de configuration et toutes les dépendances.
- Registry
- Un registre d'images est un endroit où stocker, extraire et partager des images de conteneur. Les registres peuvent être accessibles au public ou à un petit groupe d'utilisateurs. En ce qui concerne les applications d'entreprise, utilisez un registre privé tel que IBM Cloud pour protéger vos images contre toute utilisation par des utilisateurs non autorisés.
Qu'est-ce qu'Red Hat OpenShift ?
Red Hat OpenShift est une plateforme de conteneur Kubernetes qui offre un environnement sécurisé pour l'exécution des charges de travail d'entreprise. Il étend la plateforme Kubernetes avec des logiciels intégrés pour améliorer le développement du cycle de vie, les opérations et la sécurité des applications. Avec Red Hat OpenShift, vous pouvez déployer de façon cohérente vos charges de travail sur des environnements et des fournisseurs de cloud hybrides.
Quelle infrastructure hôte de calcul propose Red Hat OpenShift on IBM Cloud?
Avec Red Hat® OpenShift® on IBM Cloud®, vous pouvez créer un cluster à l'aide de l'infrastructure des fournisseurs suivants. Tous les noeuds worker d'un cluster doivent provenir du même fournisseur.
| Composant | Description |
|---|---|
| Présentation | Créez des clusters sur des serveurs virtuels dans votre propre cloud privé virtuel (VPC). |
| Plateformes de conteneur prises en charge | Red Hat OpenShift ou Kubernetes |
| Ressources de calcul et de noeud worker | Les nœuds de travail sont créés sous forme de machines virtuelles à l'aide d'une infrastructure partagée ou d'hôtes dédiés. Contrairement aux clusters classiques, les nœuds worker de cluster VPC sur le matériel partagé n'apparaissent pas dans votre portail d'infrastructure ou dans une facture d'infrastructure distincte. Au lieu de cela, vous gérez toutes les activités de maintenance et de facturation des nœuds worker via Red Hat OpenShift on IBM Cloud. Vos instances de noeud worker sont connectées à certaines instances VPC qui résident dans votre compte d'infrastructure, telles que le sous-réseau ou les volumes de stockage VPC. Pour les hôtes dédiés, le prix de l'hôte dédié couvre l' vCPU,, la mémoire et tout stockage d'instance utilisé par les travailleurs placés sur l'hôte. Notez que tous les serveurs Intel® x86-64 ont la technologie Hyper-Threading activée par défaut. Pour plus d'informations, voir Intel Hyper-Threading Technology. |
| Sécurité | Les clusters sur le matériel partagé s'exécutent dans un environnement isolé dans le cloud public. Les clusters sur des hôtes dédiés ne s'exécutent pas dans un environnement partagé, mais uniquement vos clusters qui sont présents sur vos hôtes. Les listes de contrôle d'accès réseau protègent les sous-réseaux qui fournissent les adresses IP flottantes de vos noeuds worker. |
| Haute disponibilité | Le maître inclut trois répliques pour la haute disponibilité. De plus, si vous créez votre cluster dans une métropole multizone, les répliques de maître sont réparties entre les différentes zones et vous pouvez également répartir vos pools de noeuds worker entre les zones. |
| Réservations | Les réservations ne sont pas disponibles pour VPC. |
| Administration du cluster | Les clusters VPC ne peuvent pas être rechargés ou mis à jour. Utilisez plutôt ou fonctionnement de l'API pour remplacer worker replace --update CLI les nœuds de travail obsolètes ou en difficulté. |
| Mise en réseau de cluster | Contrairement à l'infrastructure classique, les noeuds worker de votre cluster de VPC sont connectés à des sous-réseaux VPC et des adresses IP privées leur sont affectées. Les noeuds worker ne sont pas connectés au réseau public, qui est accessible via une passerelle publique, une adresse IP flottante ou une passerelle VPN. Pour plus d'informations, voir Présentation de la mise en réseau VPC dans Red Hat OpenShift on IBM Cloud. |
| Applications et plateforme de conteneur | Vous pouvez choisir de créer des clusters d' Kubernetes s ou d' Red Hat OpenShift s communautaires pour gérer vos applications conteneurisées. Vos processus de génération d'application ne diffèrent pas en raison du fournisseur d'infrastructure, mais de la manière dont vous exposez l'application. |
| Mise en réseau d'application | Tous les pods qui sont déployés sur un noeud worker se voient affecter une adresse IP privée issue de la plage 172.30.0.0/16 et sont routés entre les noeuds worker sur l'adresse IP privée de noeud worker du sous-réseau VPC privé. Pour
exposer l'application sur le réseau public, vous pouvez créer un service Kubernetes LoadBalancer, qui met à disposition un équilibreur de charge VPC et une adresse de nom d'hôte publique pour vos noeuds worker. Pour plus
d'informations, voir Exposition d'applications avec des équilibreurs de charge VPC. |
| Stockage | Vous avez le choix entre des solutions de stockage non persistant et des solutions de stockage persistant, telles que le stockage de fichiers, le stockage par blocs, le stockage d'objets et le stockage SDS. Pour plus d'informations, voir Planification de stockage persistant à haute disponibilité. |
| Accès utilisateur | Vous pouvez utiliser des règles d'accès IAMIBM Cloud pour autoriser les utilisateurs à créer une infrastructure, à gérer votre cluster et à accéder aux ressources du cluster. Le cluster peut se trouver dans un groupe de ressources différent de celui du VPC. |
| Intégrations | VPC prend en charge une liste spécifique de services, modules complémentaires et intégrations tierces IBM Cloud pris en charge. Pour obtenir une liste, voir Intégrations IBM Cloud et tierces prises en charge. |
| Emplacements et versions | Les clusters de VPC sont disponibles dans le monde entier, dans les emplacements multizone. |
| interface de service | Les clusters de VPC sont pris en charge par la version suivante (v2) de l'API IBM Cloud Kubernetes Service, et vous pouvez gérer vos clusters de VPC via la même
interface de ligne de commande et la même console que les clusters classiques. |
| Conformité au service | Voir la section sur les clusters de VPC dans la rubrique Quelles sont les normes auxquelles le service est conforme ?. |
| Limitations de service | Voir Limitations de service. Pour les limitations spécifiques aux VPC dans Red Hat OpenShift on IBM Cloud, voir Limitations de cluster de VPC. Pour les limitations générales des fournisseurs d'infrastructure VPC, voir Limitations. |
| Composant | Description |
|---|---|
| Présentation | Créez des clusters sur votre propre matériel, IBM Cloud Classic ou VPC, ou sur des serveurs virtuels dans un autre fournisseur de cloud tel que AWS ou Azure. |
| Plateformes de conteneur prises en charge | Red Hat OpenShift |
| Ressources de calcul et de noeud worker | Les noeuds worker peuvent être des machines virtuelles utilisant une infrastructure partagée ou des hôtes dédiés, ou même des serveurs bare metal. Vous gérez l'activité de maintenance et de facturation pour les noeuds worker via votre fournisseur d'infrastructure hôte, qu'il s'agisse de IBM Cloud, de votre propre matériel sur site ou d'un autre fournisseur de cloud. Vous gérez également la facturation via IBM Cloud. Pour plus d'informations sur les tarifs, consultez la section « Quels sont les frais facturés lorsque j'utilise IBM Cloud Satellite? ». |
| Sécurité | Voir Sécurité et conformité. |
| Haute disponibilité | Voir A propos de la haute disponibilité et de la reprise. |
| Réservations | Les réservations ne sont pas disponibles pour l' Satellite. |
| Administration du cluster | Voir Mise à jour des hôtes affectés en tant que noeuds worker. |
| Mise en réseau de cluster | Si vous connectez des hôtes IBM Cloud classiques ou VPC à votre emplacement, reportez-vous à ces descriptions. |
| Applications et plateforme de conteneur | Vous pouvez créer des clustersRed Hat OpenShift pour gérer vos applications conteneurisées. Vos processus de génération d'application ne diffèrent pas en raison du fournisseur d'infrastructure, mais de la manière dont vous exposez l'application. Pour plus d'informations, voir Choix d'un service d'exposition d'application. |
| Mise en réseau d'application | 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. Vous pouvez éviter les conflits de sous-réseau avec le réseau que vous utilisez pour vous connecter à votre emplacement en spécifiant un routage CIDR de sous-réseau personnalisé qui fournit les adresses IP privées pour les pods. Pour exposer une application, voir Exposition d'applications dans des clusters Satellite. |
| Stockage | Apportez vos propres pilotes de stockage ou déployez l'un des modèles de stockage pris en charge. Pour plus d'informations, voir Présentation du stockage Satellite. |
| Accès utilisateur | Vous pouvez utiliser des règles d'accès IAM IBM Cloud pour autoriser les utilisateurs à créer l'infrastructure IBM Cloud, à gérer votre cluster et à accéder aux ressources du cluster. Pour plus d'informations, consultez la section Présentation de la gestion des accès. Vous pouvez également contrôler davantage l'accès à votre infrastructure hôte dans les règles fournies par votre fournisseur d'infrastructure. |
| Intégrations | Pour les intégrations de cluster, voir Supported IBM Cloud and third-party integrations. Pour les intégrations de service Satellite prises en charge, voir Services Satellite IBM Cloud pris en charge. |
| Emplacements et versions | Les clusters sont gérés à partir de l'un des emplacements IBM Cloud pris en charge. Toutefois, vous pouvez déployer des noeuds worker dans votre propre emplacement, dans un centre de données IBM Cloud ou dans un autre fournisseur de cloud. Pour plus d'informations, voir Description des emplacements et des hôtes. |
| interface de service | Satellite sont pris en charge par l'API globale [IBM Cloud Kubernetes Service, l'interface de ligne de commande Red Hat OpenShift on IBM Cloud et l'interface de ligne de commande Satellite . Vous pouvez également gérer vos clusters à partir de la console. |
| Conformité au service | Pour les clusters, voir Quelles sont les normes auxquelles le service est conforme?. Pour Satellite, voir Sécurité et conformité. |
| Limitations de service | Voir Limitations, paramètres par défaut et exigences d'utilisation. |
| Composant | Description |
|---|---|
| Présentation | Créez des clusters dans un environnement classique de calcul, de mise en réseau et de stockage dans une infrastructur IBM Cloud. |
| Plateformes de conteneur prises en charge | Red Hat OpenShift ou Kubernetes |
| Ressources de calcul et de noeud worker | Des machines de stockage virtuelles, bare metal et définies par logiciel sont disponibles pour vos nœuds de travail. Vos instances de noeud worker résident dans votre compte d'infrastructure IBM Cloud, mais vous pouvez les gérer via Red Hat OpenShift on IBM Cloud. Vous êtes propriétaire des instances de noeud worker. |
| Sécurité | Fonctions de sécurité intégrées qui vous aident à protéger votre infrastructure de cluster, à isoler les ressources et à garantir la conformité en matière de sécurité. Pour plus d'informations, voir la documentation sur l'infrastructure réseau classique. |
| Haute disponibilité | Pour les clusters classiques et VPC, le maître inclut trois répliques pour garantir la haute disponibilité. De plus, si vous créez votre cluster dans une métropole multizone, les répliques de maître sont réparties entre les différentes zones et vous pouvez également répartir vos pools de noeuds worker entre les zones. Pour plus d'informations, voir Haute disponibilité pour Red Hat OpenShift on IBM Cloud. |
| Réservations | Créez une réservation avec des contrats de 1 ou 3 ans pour les noeuds worker classiques afin de geler un coût réduit pour la durée de vie du contrat. Les économies réalisées sont généralement comprises entre 30 et 50 % par rapport aux coûts habituels des nœuds de travail. |
| Administration du cluster | Les clusters classiques prennent en charge l'ensemble des opérations v1 API, telles que le redimensionnement des pools de travailleurs, le rechargement des nœuds de travail et la mise à jour des nœuds maîtres et de travail
dans les versions majeures, mineures et correctives. Lorsque vous supprimez un cluster, vous pouvez choisir de retirer les éventuelles instances de stockage ou de sous-réseau connectées. |
| Mise en réseau de cluster | Vos noeuds worker sont mis à disposition sur des VLAN privés qui fournissent des adresses IP privées pour communiquer sur le réseau d'infrastructure IBM Cloud privé. Pour la communication sur le réseau public, vous pouvez également mettre à disposition les noeuds worker sur un VLAN public. La communication avec le maître cluster peut s'effectuer sur le noeud final de service cloud public ou privé. Pour plus d'informations, voir Présentation des concepts de base du réseau de cluster de VPC ou Présentation des concepts de base du réseau de cluster classique. |
| Applications et plateforme de conteneur | Vous pouvez choisir de créer des clusters de communauté Kubernetes ou Red Hat OpenShift pour gérer vos applications conteneurisées. Vos processus de génération d'application ne diffèrent pas en raison du fournisseur d'infrastructure, mais de la manière dont vous exposez l'application. Pour plus d'informations, voir Choix d'un service d'exposition d'application. |
| Mise en réseau d'application | Tous les pods qui sont déployés sur un noeud worker se voient affecter une adresse IP privée issue de la plage 172.30.0.0/16 et sont routés entre les noeuds worker sur l'adresse IP privée de noeud worker du VLAN privé. Pour exposer l'application sur le réseau public, votre cluster doit disposer de noeuds worker sur le VLAN public. Vous pouvez ensuite créer un service NodePort, LoadBalancer (NLB) ou Ingress (ALB). Pour plus d'informations, voir Planification de la mise en réseau au sein du cluster et en externe pour des applications. |
| Stockage | Vous avez le choix entre des solutions de stockage non persistant et des solutions de stockage persistant, telles que le stockage de fichiers, le stockage par blocs, le stockage d'objets et le stockage SDS. Pour plus d'informations, voir Planification de stockage persistant à haute disponibilité. |
| Accès utilisateur | Pour créer des clusters d'infrastructure classique, vous devez configurer des données d'identification d'infrastructure pour chaque région et groupe de ressources. Pour permettre aux utilisateurs de gérer le cluster, utilisez des rôles d'accès à la plateforme IBM Cloud IAM. Pour accorder aux utilisateurs l'accès aux ressources de cluster, utilisez les rôles d'accès au service IAMIBM Cloud, qui correspondent aux rôles RBAC Kubernetes. |
| Intégrations | Vous pouvez étendre vos fonctions de cluster et d'application avec une grande variété de services, modules complémentaires et intégrations tiers IBM Cloud. Pour obtenir une liste, voir Intégrations IBM Cloud et tierces prises en charge. |
| Emplacements et versions | Les grappes classiques sont disponibles dans le monde entier. |
| interface de service | Les clusters classiques sont entièrement pris en charge dans l' Kubernetes Service v1 API, l'interface de ligne de commande et la console
. |
| Conformité au service | Voir la section sur les clusters classiques dans la rubrique Quelles sont les normes auxquelles le service est conforme ?. |
| Limitations de service | Voir Limitations de service. Les limitations spécifiques aux fonctions sont documentées par section. |
Quels sont les avantages de ce service?
Avec Red Hat OpenShift on IBM Cloud, vos développeurs ont un moyen rapide et sécurisé de conteneuriser et déployer des charges de travail d'entreprise dans les clusters de Kubernetes. Les clusters Red Hat OpenShift s'appuient sur l'orchestration de conteneur Kubernetes qui offre une cohérence et une flexibilité pour vos opérations de cycle de vie de développement.
Vos charges de travail Red Hat OpenShift peuvent être mises à l'échelle de l'encombrement de centres de données et de régions multizone d'IBM à l'échelle mondiale. Vous pouvez surveiller, journaliser et sécuriser simultanément et uniformément des applications. Etant donné qu'IBM gère le service, vous pouvez vous concentrer sur des innovations à l'aide de services et de logiciels intermédiaires IBM Cloud de grande valeur, tels que l'intelligence artificielle et les analyses. Vous avez également accès aux outils open source Red Hat, notamment vos environnements d'exécution d'application, infrastructures, bases de données favoris, etc.
Vous êtes prêts ? Suivez le tutoriel de création d'un cluster Red Hat OpenShift on IBM Cloud.
Choix du fournisseur de plateforme de conteneur
- Déployez des clusters avec Red Hat OpenShift ou la communauté Kubernetes installé en tant qu'orchestrateur de plateforme de conteneur.
- Choisissez l'expérience de développeur qui correspond à votre entreprise ou exécutez des charges de travail sur les clusters Red Hat OpenShift ou de communauté Kubernetes.
- Intégrations intégrées à partir de la console IBM Cloud vers le tableau de bord Kubernetes ou la console Web Red Hat OpenShift.
- Affichage et gestion centralisée de l'ensemble des clusters Red Hat OpenShift ou des clusters de communauté Kubernetes à partir d'IBM Cloud.
Clusters Kubernetes à service exclusif avec isolement de l'infrastructure de traitement, de réseau et de stockage
- Créez votre propre infrastructure personnalisée afin de répondre aux besoins de votre organisation.
- Choisir parmi les fournisseurs d'infrastructure.
- Mettez à disposition un maître Red Hat OpenShift dédié et sécurisé, des noeuds worker, des réseaux virtuels et un espace de stockage à l'aide des ressources fournies par l'infrastructure IBM Cloud.
- Le maître Kubernetes entièrement géré est constamment surveillé et mis à jour par IBM pour que votre cluster soit toujours disponible.
- Option permettant de mettre à disposition des noeuds worker en tant que serveurs bare metal pour les charges de travail de calcul intensif, telles que des données, des processeurs graphiques et l'intelligence artificielle.
- Stockez les données persistantes, partagez les données entre les pods Kubernetes et restaurez les données en cas de besoin avec le service de volumes intégré et sécurisé.
- Tirez parti de la prise en charge complète de toutes les API Kubernetes natives.
Clusters multizone pour une haute disponibilité accrue
- Gérez facilement les noeuds worker de la même version (UC, mémoire, virtuelle ou physique) avec des pools de noeuds worker.
- Protégez-vous en cas de défaillance d'une zone en répartissant les noeuds uniformément entre les différentes zones et en utilisant des déploiements de pod anti-affinité pour vos applications.
- Réduisez les coûts en utilisant des clusters multizones au lieu de dupliquer les ressources dans un cluster distinct.
- Bénéficiez de l'équilibrage de charge automatique entre vos applications avec l'équilibreur de charge multizone (MZLB) configuré automatiquement pour vous dans chaque zone du cluster.
Maîtres hautement disponibles
- Réduisez la durée d'indisponibilité du cluster, notamment lors de mise à jour du maître avec les maîtres à haute disponibilité mis à disposition automatiquement lorsque vous créez un cluster.
- Répartissez vos masters dans les zones d'un cluster multizone afin de protéger votre cluster contre les défaillances de zones.
Conformité de la sécurité de l'image par Vulnerability Advisor
- Créez votre propre répertoire dans un registre d'images privé et sécurisé Docker où les images sont stockées et partagées par tous les utilisateurs de l'organisation.
- Tirez parti de l'analyse automatique des images dans votre registre IBM Cloud privé.
- Examinez les recommandations spécifiques au système d'exploitation utilisé dans l'image pour corriger les vulnérabilités potentielles.
Surveillance en continu de l'état de santé du cluster
- Utilisez le tableau de bord du cluster pour déterminer rapidement et gérer l'état de santé de votre cluster, des noeuds worker et des déploiements de conteneurs.
- Accédez à des métriques de consommation détaillées en utilisant IBM Cloud® Monitoring et élargissez rapidement votre cluster pour répondre aux charges de travail.
- Examinez les informations de journalisation à l'aide d'IBM Cloud Logs pour voir les activités détaillées du cluster.
Exposition sécurisée des applications au public
- Sélectionnez une adresse IP publique, une route fournie par IBM ou votre propre domaine personnalisé pour accéder à des services dans votre cluster depuis Internet.
Intégration de services IBM Cloud
- Vous pouvez ajouter des fonctionnalités supplémentaires à votre application via l'intégration de services IBM Cloud, tels que les API Watson, Blockchain, des services de données ou Internet of Things (IoT).
Comparaison entre Red Hat OpenShift et les clusters Kubernetes
Les clusters Red Hat OpenShift on IBM Cloud et IBM Cloud Kubernetes Service sont des plateformes de conteneur prêtes à la production qui sont adaptées aux charges de travail d'entreprise. Le tableau suivant compare et oppose certaines caractéristiques courantes qui peuvent vous aider à choisir la plateforme de conteneurs la mieux adaptée à votre cas d'utilisation.
| Caractéristiques | Clusters Kubernetes | Clusters Red Hat OpenShift |
|---|---|---|
| Expérience de gestion de cluster complète via les outils d'automatisation IBM Cloud Kubernetes Service (API, interface de ligne de commande, console) | Oui | Oui |
| Disponibilité mondiale dans des clusters à zone unique ou multizone | Oui | Oui |
| Orchestration cohérente de conteneurs via des fournisseurs de cloud hybrides | Oui | Oui |
| Accès aux services IBM Cloud tels que l'intelligence artificielle | Oui | Oui |
| Solution de stockage SDS Portworx disponible pour des cas d'utilisation multizone | Oui | Oui |
| Création d'un cluster dans un cloud privé virtuel (VPC) IBM | Oui | Oui |
| Dernière distribution d' Kubernetes | Oui | |
| Définition de la portée des règles d'accès IBM Cloud IAM concernant l'accès aux groupes d'accès pour les rôles d'accès au service qui sont synchronisés avec les règles RBAC de cluster | Oui | |
| Cluster d'infrastructure classique sur le réseau privé uniquement | Oui | |
| Noeuds worker de bare metal GPU | Oui | Oui |
| Packages IBM Cloud Pak et logiciels intermédiaires intégrés | Oui | |
| Images de conteneurs intégrées, flux, compilations et outils ( en savoir plus ) | Oui | |
| CI/CD intégré à Jenkins | Oui | |
| Contexte de sécurité d'application plus strict configuré par défaut | Oui | |
| Expérience de développeur Kubernetes simplifiée, avec une console d'application adaptée aux débutants | Oui | |
| Système d'exploitation pris en charge | Informations sur la version de Kubernetes | Red Hat OpenShift informations sur la version |
| Mise en réseau de trafic externe préférée | Ingress | Routeur |
| Routes sécurisées chiffrées avec Hyper Protect Crypto Services | Oui |
Comparaison entre les clusters qui s'exécutent dans IBM Cloud et dans une installation OCP standard
Etant donné que Red Hat OpenShift on IBM Cloud est un service géré, bon nombre des paramètres globaux et des composants Red Hat® OpenShift® on IBM Cloud® que vous configurez manuellement dans OpenShift Container Platform sont configurés pour vous par défaut dans Red Hat OpenShift on IBM Cloud. Passez en revue les différences ci-après entre les clusters Red Hat OpenShift on IBM Cloud et une installation standard d'OpenShift Container Platform sur votre propre infrastructure. Vous pouvez également consulter le fichier architecture de service pour obtenir une présentation de la manière dont les composants Red Hat OpenShift sont configurés dans les nœuds maître et de travail du cluster, ou lesparamètres globaux que vous pouvez ou ne pouvez pas configurer.
| Caractéristiques | Installation OCP standard | Red Hat OpenShift on IBM Cloud |
|---|---|---|
| Maître cluster (plan de contrôle) | Vous configurez des composants de plan de contrôle tels que le serveur d'API et etcd sur les machines qui obtiennent le rôle master. Vous pouvez modifier les composants de plan de contrôle, mais n'oubliez pas qu'il vous incombe
de sauvegarder, restaurer et créer des données de plan de contrôle hautement disponibles. |
IBM configure le maître, gère les composants de plan de contrôle et applique automatiquement les mises à jour de correctif de maître. Les maîtres sont hautement disponibles et automatiquement sauvegardés. |
| Machines de calcul (noeuds worker) | Vous créez vos propres machines de calcul compatibles, configurez une connectivité réseau compatible, ouvrez une session SSH dans les machines, installez OCP et enregistrez les machines en tant que noeuds worker dans le cluster. Vos machines peuvent correspondre à une infrastructure IPI (mise à disposition par le programme d'installation) pour une configuration guidée, ou à une infrastructure UPI (mise à disposition par l'utilisateur) pour un contrôle renforcé et une administration ultérieure de votre côté. Il vous incombe de gérer et mettre à jour les noeuds worker. Vous pouvez installer des mises à jour à partir de la console Web Red Hat OpenShift. | Vous sélectionnez la version des noeuds worker que vous souhaitez ajouter à votre cluster, et IBM connecte automatiquement les noeuds worker au cluster et installe OCP. En ce sens, l'installation est similaire à l'IPI pour vous, car vous n'avez pas à gérer toutes les infrastructures et tous les paramètres réseau. IBM fournit également des mises à jour de correctif que vous pouvez choisir d'appliquer à vos noeuds worker, à partir de l'interface IBM Cloud (et non la console Web Red Hat OpenShift). SSH est désactivé pour plus de sécurité. |
| Mises à jour de correctif et des versions OCP | Il vous incombe de mettre à jour l'infrastructure sous-jacente des noeuds maître et worker. Vous pouvez utiliser la console Web Red Hat OpenShift pour mettre à jour les versions OCP. | IBM applique automatiquement des mises à jour au maître et fournit des mises à jour de version et des mises à jour de correctif de sécurité pour les noeuds worker. Vous choisissez quand appliquer ces mises à jour aux noeuds worker, à partir de l'interface IBM Cloud (et non la console Web Red Hat OpenShift). Les versions prises en charge peuvent varier à partir d'OpenShift Container Platform standard. |
| Mise à l'échelle automatique des machines de calcul | Vous pouvez configurer une ressource ClusterAutoscaler. |
Vous pouvez configurer le plug-in de programme de mise à l'échelle automatique de cluster. |
| Système d'exploitation de noeud worker | CoreOS ou RHEL | 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. |
| Support | Fourni conformément aux conditions de votre abonnement Red Hat ou de votre fournisseur de cloud. Vous pouvez utiliser l'outil oc adm must-gather pour collecter des informations. |
Fourni par le service d'assistance d' IBM Cloud. |
| Console Web Red Hat OpenShift | Vous configurez et pouvez installer et configurer ou désactiver la console Web Red Hat OpenShift. | La console Web Red Hat OpenShift est configurée pour vous. Vous ne pouvez pas configurer ou désactiver la console Web. IBM fournit également la console permettant de gérer votre infrastructure de cluster. |
| Authentification | Un serveur OAuth est fourni, mais vous pouvez configurer les paramètres de jeton et le fournisseur d'identité pour contrôler l'accès au cluster. Vous gérez également le contrôle d'accès à base de rôles pour contrôler l'accès utilisateur dans le cluster. | IBM configure automatiquement le serveur OAuth pour qu'il utilise IBM Cloud IAM. Vous ne pouvez pas changer le fournisseur d'identité. IBM Cloud IAM est également configuré sur la synchronisation automatique avec le contrôle d'accès basé sur les rôles (RBAC) pour que vous puissiez utiliser IAM pour gérer l'accès vers et au sein du cluster. |
| Réseau de conteneurs pour les clusters | L'opérateur de réseau de cluster configure le plug-in d'interface réseau de conteneurs (CNI) SDN. Vous pouvez modifier le plug-in CNI, configurer plusieurs réseaux ou connecter un réseau matériel tel qu'une virtualisation d'E-S racine unique (SR-IOV). | Calico est configuré pour vous. Vous ne pouvez pas modifier le plug-in CNI, configurer plusieurs réseaux ou connecter un réseau matériel. |
| Ingress | Vous pouvez utiliser l'opérateur Ingress pour configurer un ou plusieurs contrôleurs Ingress basés sur HAProxy. Vous pouvez acheminer le trafic vers vos applications en spécifiant des ressources Route ou Ingress. |
Lorsque vous créez un cluster, un sous-domaine Ingress par défaut est configuré pour vous. Un routeur basé sur HAProxy est configuré pour chaque contrôleur Ingress et un service de routeur est automatiquement créé dans chaque zone comportant
des noeuds worker. Vous pouvez acheminer le trafic vers vos applications en spécifiant des ressources Route ou Ingress. Pour plus d'informations, voir A propos d'Ingress dans Red Hat OpenShift version 4. |
| Stockage | Vous devez configurer des volumes persistants qui seront sauvegardés par un fournisseur de stockage. OpenShift Data Foundation est disponible. | IBM configure automatiquement des fournisseurs de stockage, tels que IBM Cloud File et Block. OpenShift Data Foundation est disponible. Pour connaître les options de stockage prises en charge, voir Planification de stockage persistant à haute disponibilité. |
| Registre d'images | Le cluster est configuré avec un registre interne pour extraire des images. Si votre cluster dispose d'un accès réseau public, vous pouvez extraire des images automatiquement à partir de Docker Hub. Pour extraire des images à partir d'autres registres, vous devez configurer des secrets d'extraction d'image. Vous configurez le registre interne pour sauvegarder des images sur un fournisseur de stockage en cloud. Les images stockées ne sont pas disponibles sur les différents clusters. | Le registre interne est configuré pour sauvegarder des images automatiquement dans un compartiment dans votre instance IBM Cloud Object Storage. Votre cluster comporte des secrets d'extraction d'image qui sont automatiquement configurés pour extraire des images à partir des registres par défaut, y compris IBM Cloud Container Registry. Vous pouvez également configurer le registre interne pour utiliser IBM Cloud Container Registry à partir duquel votre cluster peut extraire des images au moyen d'une configuration automatique. Pour plus d'informations, voir Configuration d'un registre d'images. |
| Opérateurs et OperatorHub | OpenShift Container Platform configure un grand nombre d'opérateurs afin de gérer les composants par défaut pour le cluster. Vous pouvez également utiliser OperatorHub pour installer d'autres opérateurs, tels que des fournisseurs tiers. | IBM configure bon nombre des mêmes opérateurs qu'OCP afin de gérer le composant par défaut pour le cluster. Toutefois, étant donné qu'IBM gère le maître et vous fournit les API IBM Cloud qui vous permettent de gérer votre infrastructure de cloud, certains opérateurs, tels que l'opérateur ensembliste de machine et d'autres composants, comme ceux indiqués dans ce tableau, ne sont pas configurés ou configurables. Vous pouvez également utiliser OperatorHub pour installer d'autres opérateurs, tels que des fournisseurs tiers. Notez que les opérateurs que vous installez ou créez ne sont pas pris en charge par IBM et peuvent être fournis avec leurs propres conditions de support et leur propre tarification. |
| Projets, générations et applications | OpenShift Container Platform fournit des outils tels que des projets, des configurations de compilation et le registre interne que vous pouvez utiliser pour déployer vos applications tout en suivant une méthodologie cloud native, d'intégration continue et de livraison continue (CI/CD). | Les clusters Red Hat OpenShift on IBM Cloud sont fournis avec les mêmes composants de projet et de génération configurables que les clusters OCP. Vous pouvez également choisir d'intégrer votre cluster à des services IBM Cloud tels que Continuous Delivery. |
| État de santé du cluster | Vous pouvez également configurer les outils de journalisation, de surveillance et de décompte en installant et en configurant différents opérateurs. Ces solutions sont spécifiques aux clusters et ne sont pas hautement disponibles sauf si vous les sauvegardez. | Vos clusters proposent des intégrations en un seul clic avec IBM Cloud Logs et IBM Cloud Monitoring pour les solutions de niveau entreprise de journalisation et de surveillance persistante sur les clusters. Vous pouvez également installer les opérateurs de journalisation et de surveillance comme avec une installation OCP standard, mais vous devrez peut-être ajuster les paramètres de configuration. Pour plus d'informations, voir Journalisation et surveillance de l'état de santé du cluster. |
| Migration de clusters | Vous pouvez utiliser l'opérateur de migration de cluster pour faire migrer des clusters d'une version principale vers une autre. La migration requiert des clusters distincts ; vous ne pouvez pas mettre à jour un cluster d'une version principale vers une autre. Divers outils open source peuvent être utilisés, mais ne bénéficient pas d'une prise en charge officielle. | Comme avec la plateforme de conteneur OpenShift standard, vous ne pouvez pas mettre à jour un cluster d'une version principale vers une autre. Si vous utilisez un outil open source tiers tel que l 'opérateur de migration de cluster, cet outil n'est pas pris en charge par IBM et peut présenter certaines limitations, telles que l'indisponibilité de l'interface utilisateur de migration. |
| Container-native virtualization | Vous pouvez configurer le module complémentaire de virtualisation native des conteneurs sur des machines physiques, mais pas sur des machines virtuelles. Container-native virtualization n'est pas pris en charge par IBM. Si vous avez des problèmes, vous êtes responsable de résoudre les problèmes et tout impact sur vos charges de travail. | |
| Charges de travail sans serveur | Vous pouvez configurer Red Hat OpenShift Serverless. | Vous pouvez également configurer Red Hat OpenShift sans serveur. |
| Maillage de service | Vous pouvez configurer le maillage de serviceRed Hat OpenShift. | Vous pouvez également configurer le maillage de services d' Red Hat OpenShift, mais vous devez appliquer une stratégie réseau pour que l'entrée du maillage de services fonctionne. |
| Outils d'API et d'interface de ligne de commande | Les clusters OpenShift Container Platform sont configurés avec un accès aux ressources d'API Kubernetes et Red Hat OpenShift. Vous pouvez également installer des outils de ligne de commande, tels que oc et odo. |
Les clusters Red Hat OpenShift on IBM Cloud sont fournis avec les mêmes fonctionnalités pour utiliser les outils d'API et d'interface de ligne de commande Kubernetes et Red Hat OpenShift. De plus, vous pouvez utiliser l 'API et les outils CLI d' IBM Cloud pour gérer votre infrastructure de cluster et intégrer d'autres services cloud à votre cluster. |
Transfert de vos charges de travail vers IBM Cloud
Vous avez beaucoup de raisons de déplacer vos charges de travail vers IBM Cloud : réduire le coût total de possession, augmenter la haute disponibilité de vos applications dans un environnement sécurisé et conforme, augmenter et réduire les réponses à votre demande utilisateur, et bien d'autres encore. Red Hat OpenShift on IBM Cloud combine la technologie de conteneur avec des outils open source, tels que Kubernetes, pour que vous puissiez générer une application cloud-native qui peut migrer dans différents environnements de cloud, en évitant le verrouillage du fournisseur.
Mais comment faire pour accéder au cloud ? Quelles sont vos options ? Et comment gérer vos charges de travail lorsque vous y parvenez ?
Utilisez cette page pour découvrir certaines stratégies pour vos déploiements Kubernetes sur Red Hat OpenShift on IBM Cloud. Et interagissez avec l'équipe sur Slack.
Pas encore sur Slack ? Demandez une invitation !
Le tableau ci-après fournit quelques exemples de types de charge de travail généralement déplacés par les utilisateurs vers les divers types de cloud. Vous pouvez également choisir une approche hybride où des clusters sont exécutés dans les deux environnements.
| Charge de travail | Red Hat OpenShift on IBM Cloud hors site | sur site |
|---|---|---|
| Outils d'activation DevOps | Oui | |
| Développement et test d'applications | Oui | |
| Des applications qui évoluent de manière spectaculaire dans la demande et qui doivent évoluer rapidement | Oui | |
| Applications métier, telles que CRM, HCM, ERP et E-commerce | Oui | |
| Outils de collaboration et de réseau social, tels que la messagerie électronique | Oui | |
| Charges de travail RHEL | Oui | |
| bare metal | Oui | Oui |
| Ressources de calcul GPU | Oui | Oui |
| Charges de travail compatibles PCI et HIPAA | Oui | Oui |
| Applications existantes avec des contraintes et des dépendances de plateforme et d'infrastructure | Oui | |
| Applications de propriété avec des conceptions strictes, des règles d'octroi de licence ou des réglementations sévères | Oui |
- Prêt à exécuter des charges de travail hors site dans l' Red Hat OpenShift on IBM Cloud?
- Parfait ! Vous êtes déjà dans la documentation du cloud public. Poursuivez votre lecture afin de découvrir d'autres idées de stratégies ou prenez une longueur d'avance en créant un cluster dès maintenant.
- Vous souhaitez exécuter des charges de travail à la fois dans des clouds sur site et hors site?
- Explorez IBM Cloud Satellite pour étendre la flexibilité et l'évolutivité d'IBM Cloud dans vos environnements de fournisseur sur site, de périphérie ou de cloud.
Quel type d'application puis-je exécuter ? Puis-je déplacer des applications existantes ou dois-je développer de nouvelles applications ?
Votre application conteneurisée doit pouvoir s'exécuter sur l'un des systèmes d'exploitation pris en charge pour votre version de cluster. Vous souhaitez également prendre en compte le caractère avec état de votre application. Pour plus d'informations sur les types d'application qui peuvent s'exécuter dans Red Hat OpenShift on IBM Cloud, voir Planification des déploiements d'application.
Si vous possédez déjà une application, vous pouvez la faire migrer vers Red Hat OpenShift on IBM Cloud. Si vous souhaitez développer une nouvelle application, consultez le fichier Instructions pour le développement d'applications sans état, cloud-natives.
Quelles compétences devrais-je avoir avant de déplacer mes applications vers un cluster?
Red Hat OpenShift est conçu pour fournir des fonctions à deux personnes, l'administrateur de cluster et le développeur d'applications. Chaque personne utilise différentes compétences techniques pour exécuter et développer des applications sur un cluster.
- Quelles sont les principales tâches et connaissances techniques d'un administrateur de cluster?
- En tant qu'administrateur de cluster, vous êtes chargé de configurer, faire fonctionner, sécuriser et gérer l'infrastructure IBM Cloud de votre cluster. En général, les tâches sont les suivantes :
- Dimensionner le cluster afin de fournir suffisamment de capacité pour vos charges de travail.
- Concevoir un cluster afin d'atteindre les normes de haute disponibilité, de reprise après incident et de conformité de votre entreprise.
- Sécuriser le cluster en configurant des droits utilisateur et en limitant les actions au sein du cluster afin de protéger vos ressources de calcul, votre réseau et vos données.
- Planifier et gérer la communication réseau entre les composants d'infrastructure afin de garantir la sécurité, la segmentation et la conformité du réseau.
- Planifier des options de stockage permanent afin de répondre aux exigences en matière d'hébergement de données et de protection des données.
La personne chargée de l'administration de cluster doit avoir des connaissances approfondies en matière de réseau, de stockage, de sécurité et de conformité. En général, dans une entreprise, ces connaissances sont réparties entre plusieurs spécialistes, tels que les ingénieurs système, les administrateurs système, les ingénieurs réseau, les architectes réseau, les responsables informatiques ou les spécialistes sécurité et conformité. Pensez à affecter le rôle d'administration de cluster à plusieurs personnes de votre entreprise de sorte que celle-ci possède les connaissances requises pour faire fonctionner correctement le cluster. Pour plus d'informations, voir Chemin d'apprentissage pour les administrateurs.
- Quelles sont les principales tâches et compétences techniques d'un développeur d'applications?
- En tant que développeur, vous concevez, créez, sécurisez, déployez, testez, exécutez et surveillez des applications conteneurisées natives pour le cloud dans un cluster Red Hat OpenShift. Pour créer et exécuter ces applications, vous devez être familiarisé avec le concept des microservices, les directives relatives aux applications 12-factor, l' Docker, les principes de conteneurisation et les options de déploiement d' Red Hat OpenShift s disponibles. Pour plus d'informations, voir Chemin d'apprentissage pour les développeurs.
Red Hat OpenShift et Red Hat OpenShift on IBM Cloud fournissent plusieurs options pour exposer une application et maintenir une application privée, ajouter du stockage persistant, intégrer d'autres services et sécuriser vos charges de travail et protéger des données sensibles. Avant de déplacer votre application vers un cluster dans Red Hat OpenShift on IBM Cloud, vérifiez que vous pouvez exécuter votre application en tant qu'application conteneurisée sur le système d'exploitation pris en charge et que Red Hat OpenShift et Red Hat OpenShift on IBM Cloud fournissent les fonctionnalités dont votre charge de travail a besoin.
Ressources connexes
Découvrez comment vous familiariser avec les concepts et la terminologie de Kubernetes.
- Familiarisez-vous avec le produit en suivant le tutoriel sur la création de clusters.
- Découvrez comment Kubernetes et Red Hat OpenShift on IBM Cloud fonctionnent ensemble en suivant cette formation.