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 de applications conteneurisées avec une intervention manuelle minimale voire nulle. Tous les conteneurs constituant votre microservice sont regroupés dans des pods. Les pods sont des unités logiques facilitant les opérations de gestion et de reconnaissance. Ces pods s'exécutent sur des hôtes de calcul gérés dans un cluster Kubernetes portable, extensible et à réparation spontanée en cas de défaillance.

Pour plus d'informations sur Kubernetes, voir la documentationKubernetes.

Comment créer un cluster Red Hat OpenShift on IBM Cloud ?

Pour créer un cluster Red Hat OpenShift on IBM Cloud, vous devez d'abord décider si vous souhaitez suivre un tutoriel pour une configuration de cluster de base ou concevoir votre propre environnement de cluster.

Je veux suivre un tutoriel

Commencez par consulter la documentation Initiation, puis choisissez l'un des tutoriels disponibles.

Je souhaite concevoir mon propre environnement de cluster

Commencez par consulter la documentation Initiation, puis créez votre stratégie d'environnement de cluster.

Comment Red Hat OpenShift on IBM Cloud fonctionne-t-il ?

Avec Red Hat OpenShift on IBM Cloud, vous pouvez créer votre propre cluster Red Hat OpenShift pour déployer et gérer des applications conteneurisées sur IBM Cloud. Vos applications conteneurisées sont hébergées sur des hôtes de calcul de l'infrastructure IBM Cloud nommés noeuds worker. Vous pouvez choisir de provisionner vos hôtes de calcul sous forme de machines virtuelles avec des ressources partagées ou dédiées, ou sous forme de machines bare metal pouvant être optimisées pour l'utilisation de GPU et de stockage défini par logiciel (SDS). Vos noeuds worker sont contrôlés par un maître Red Hat OpenShift à haute disponibilité configuré, surveillé et géré par IBM. Vous pouvez utiliser l'API ou l'Interface de ligne de commande IBM Cloud Kubernetes Service pour travailler avec les ressources d'infrastructure de votre cluster et utiliser l'API ou l'interface de ligne de commande de Kubernetes pour gérer vos services et vos déploiements.

Pour plus d'informations sur la configuration des ressources de votre cluster, voir Architecture de service. Pour obtenir une liste des fonctionnalités et des avantages, voir Avantages et offres de service.

Pourquoi dois-je utiliser Red Hat OpenShift on IBM Cloud ?

Red Hat OpenShift on IBM Cloud est une offre Red Hat OpenShift gérée qui fournit des outils puissants, une expérience utilisateur intuitive et une sécurité intégrée pour distribuer rapidement des applications que vous pouvez associer à des services de cloud liés à IBM Watson®, l'intelligence artificielle, IoT, DevOps, ainsi qu'à la sécurité et à l'analyse des données. En tant que fournisseur certifié Kubernetes, Red Hat OpenShift on IBM Cloud prend en charge la planification intelligente, l'auto-réparation, la mise à l'échelle horizontale, la découverte de services et l'équilibrage de charge, les déploiements et retours en arrière automatisés, ainsi que la gestion des secrets et des configurations. Le service dispose également de fonctions avancées pour simplifier la gestion d'un cluster, la sécurité des conteneurs et les règles d'isolement, la possibilité de concevoir votre propre cluster et des outils opérationnels intégrés pour garantir une certaine cohérence dans les déploiements.

Pour obtenir une présentation détaillée des fonctionnalités et des avantages, voir Avantages liés à l'utilisation du service.

Quelles sont les plateformes de conteneur disponibles pour mon cluster ?

IBM Cloud, vous permet de créer des clusters pour vos charges de travail conteneurisées à partir de deux plateformes de gestion de conteneurs distinctes : la version IBM de communauté Kubernetes et Red Hat OpenShift on IBM Cloud. La plateforme de conteneur que vous sélectionnez est installée sur le maître et les noeuds worker de votre cluster. Par la suite, vous pouvez Mettre à jour la version, mais vous ne pouvez pas revenir à une version précédente ou passer à une autre plateforme de conteneur. Si vous souhaitez utiliser plusieurs plateformes de conteneur, créez un cluster distinct pour chacune d'elles.

Pour plus d'informations, reportez-vous à la comparaison entre les clusters Red Hat OpenShift et les clusters de communauté Kubernetes.

Kubernetes

Kubernetes est une plateforme open source d'orchestration de conteneurs de niveau production qui vous permet d'automatiser, de faire évoluer et de gérer vos applications conteneurisées s'exécutant sur un système d'exploitation Ubuntu. Grâce à la version IBM Cloud Kubernetes Service, vous avez accès aux fonctions d'API de communauté Kubernetes qui sont considérées comme des fonctions bêta ou de niveau supérieur par la communauté. Par défaut, les fonctions alpha Kubernetes, qui sont susceptibles d'être modifiées, ne sont généralement pas activées. Grâce à Kubernetes, vous pouvez combiner différentes ressources, telles que des secrets, des déploiements et des services afin de créer et gérer en toute sécurité des applications conteneurisées hautement disponibles.

Red Hat OpenShift

Red Hat OpenShift on IBM Cloud est une plateforme basée sur l' Kubernetes, spécialement conçue pour accélérer vos processus de déploiement d'applications conteneurisées fonctionnant sur un système d'exploitation Red Hat Enterprise Linux. Vous pouvez orchestrer et mettre à l'échelle vos charges de travail Red Hat OpenShift existantes sur des clouds sur site et hors site pour une solution hybride portable qui fonctionne de la même manière dans des scénarios multicloud. Pour commencer, suivez le tutoriel Red Hat OpenShift on IBM Cloud.

Le service est-il fourni avec un maître et des noeuds Red Hat OpenShift gérés ?

Dans Red Hat OpenShift on IBM Cloud, tous les clusters sont contrôlés par un maître Red Hat OpenShift dédié qui est géré par IBM dans un compte d'infrastructure IBM Cloud appartenant à IBM. Le maître Red Hat OpenShift, y compris tous les composants du maître, les opérations de calcul, les réseaux et les ressources de stockage, sont surveillés en permanence par des ingénieurs IBM SRE (Site Reliability Engineers). Ces ingénieurs appliquent les dernières normes en matière de sécurité, détectent et éliminent les activités malveillantes et travaillent pour assurer la fiabilité et la disponibilité de Red Hat OpenShift on IBM Cloud.

Régulièrement, Red Hat OpenShift publie des mises à jour principales, secondaires ou de correctif. Ces mises à jour peuvent affecter la version du serveur d'API Red Hat OpenShift ou d'autres composants dans le maître Red Hat OpenShift. IBM met à jour automatiquement la version de correctif, mais vous devez mettre à jour les versions principales et secondaires. Pour plus d'informations, voir Mise à jour du maître.

Les noeuds worker dans les clusters standard sont provisionnés dans votre compte d'infrastructure IBM Cloud. Les noeuds worker sont dédiés à votre compte et il vous incombe de demander des mises à jour de ces noeuds worker fréquemment pour vous assurer que le système d'exploitation des noeuds worker et les composants Red Hat OpenShift on IBM Cloud appliquent les mises à jour et les correctifs de sécurité les plus récents. Des mises à jour de sécurité et des correctifs sont mis à disposition par les ingénieurs IBM SRE (Site Reliability Engineers) qui surveillent en permanence l'image Linux installée sur vos noeuds worker pour détecter les vulnérabilités et les problèmes de conformité en matière de sécurité. Pour plus d'informations, voir Mise à jour des noeuds worker.

Quels types de charges de travail puis-je déplacer vers Red Hat OpenShift on IBM Cloud?

Pour découvrir des exemples de types de charges de travail que les utilisateurs transfèrent généralement vers les différents types de cloud, consultez la page « Transférer vos charges de travail vers IBM Cloud ». Vous pouvez également choisir une approche hybride où des clusters sont exécutés dans les deux environnements.

Puis-je automatiser mes déploiements d'infrastructure ?

Si vous souhaitez exécuter votre application dans plusieurs clusters, plusieurs environnements privés et publics, ou même dans plusieurs fournisseurs de cloud, vous vous demandez peut-être comment faire pour que votre stratégie de déploiement fonctionnent dans tous ces environnements.

Vous pouvez utiliser l'outil Terraform open source pour automatiser la mise à disposition de l'infrastructure IBM Cloud, y compris les clusters Kubernetes. Suivez ce tutoriel pour créer des clusters Kubernetes et OpenShift à zone unique et à zones multiples. Après avoir créé un cluster, vous pouvez également configurer le programme de mise à l'échelle automatique de cluster Red Hat OpenShift on IBM Cloud de sorte que votre pool de noeuds worker puisse augmenter et réduire le nombre de noeuds worker en fonction des demandes de ressources de votre charge de travail.

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.

Qu'en est-il des applications sans serveur?

Vous pouvez exécuter des applications et des travaux sans serveur via le service IBM Cloud Code Engine. Code Engine peut également générer vos images pour vous.

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 missions et les connaissances techniques requises pour 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.

Quelles sont les principales missions 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 maîtriser le concept des microservices, les principes des applications 12 facteurs, les principes de l' Docker ation et de la conteneurisation, ainsi que les options de déploiement disponibles sur Red Hat OpenShift.

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 migrer votre application vers un cluster dans l' Red Hat OpenShift on IBM Cloud, vérifiez que vous pouvez l'exécuter sous forme d'application conteneurisée sur le système d'exploitation pris en charge et que Red Hat OpenShift et Red Hat OpenShift on IBM Cloud offrent les fonctionnalités requises par votre charge de travail.

Les administrateurs de clusters et les développeurs interagissent-ils entre eux?

Oui. Les administrateurs de cluster et les développeurs doivent interagir fréquemment afin que les administrateurs de cluster puissent comprendre les besoins en charge de travail et fournir cette capacité dans le cluster et pour que les développeurs puissent prendre connaissance des limitations, intégrations et principes de sécurité disponibles dont ils doivent tenir compte dans leur processus de développement d'application.

Quelles sont les options à ma disposition pour sécuriser mon cluster ?

Vous pouvez utiliser des fonctions de sécurité intégrées dans Red Hat OpenShift on IBM Cloud pour protéger les composants dans votre cluster, vos données et les déploiements d'application afin d'assurer la conformité en matière de sécurité et l'intégrité des données. Utilisez ces fonctions pour sécuriser votre serveur d'API Red Hat OpenShift, le magasin de données etcd, les noeuds worker, les réseaux, le stockage, les images et les déploiements contre les attaques malveillantes. Vous pouvez également tirer parti des outils de journalisation et de surveillance pour détecter les attaques malveillantes et les signes d'utilisation suspecte.

Pour obtenir plus d'informations sur les composants de votre cluster et savoir comment se conformer aux normes de sécurité pour chacun d'eux, voir Sécurité de Red Hat OpenShift on IBM Cloud.

Quelles politiques d'accès dois-je fournir à mes utilisateurs de cluster ?

Red Hat OpenShift on IBM Cloud utilise Cloud Identity and Access Management (IAM) pour octroyer un accès aux ressources de cluster via des rôles d'accès à la plateforme IAM et des politiques de contrôle d'accès à base de rôles (RBAC) Kubernetes via des rôles d'accès au service IAM. Pour plus d'informations sur les types de politiques d'accès, consultez la section Choisir la politique d'accès et le rôle adaptés à vos utilisateurs.

Comment faire pivoter la clé API du cluster en cas de fuite?

Pour savoir comment renouveler votre clé API, voir Comment renouveler la clé API du cluster en cas de fuite?

Où trouver une liste des bulletins de sécurité concernant mon cluster ?

Si des vulnérabilités se trouvent dans Red Hat OpenShift, Red Hat OpenShift publie des CVE dans les bulletins de sécurité afin d'informer les utilisateurs et de décrire les actions que les utilisateurs doivent prendre pour remédier à la vulnérabilité. Les bulletins de sécurité Red Hat OpenShift qui affectent les utilisateurs Red Hat OpenShift on IBM Cloud ou la plateforme IBM Cloud sont publiés dans Bulletin de sécurité IBM Cloud.

Certaines vulnérabilités (CVE) nécessitent une mise à jour de correctif de dernier niveau pour une version que vous pouvez installer dans le cadre d'un processus de mise à jour de cluster normal dans Red Hat OpenShift on IBM Cloud. Veillez à appliquer les correctifs de sécurité à temps pour protéger votre cluster contre les attaques malveillantes. Pour plus d'informations sur le contenu d'un correctif de sécurité, consultez le journal des modifications de version.

Est-ce que le service propose la prise en charge des processeurs graphiques (GPU) et de la technologie bare metal ?

Certaines versions de noeud worker VPC offrent la prise en charge de GPU. Pour plus d'informations, voir VPC flavors.

Oui, vous pouvez mettre à disposition votre noeud worker sous forme de serveur bare metal physique à service exclusif. Les serveurs bare metal offrent des avantages en termes de hautes performances pour les charges de travail, telles que les données, les processeurs graphiques (GPU) et l'intelligence artificielle. De plus, toutes les ressources matérielles sont dédiées à vos charges de travail, vous n'avez donc pas à vous soucier des "voisins bruyants".

Pour plus d'informations sur les configurations de serveurs bare metal disponibles et sur les différences entre les serveurs bare metal et les machines virtuelles, consultez le guide de planification.

Quelle est la taille minimale de cluster que je peux créer?

Notez que l'exploitation d'une grappe minimale ne répond pas à l'accord de niveau de service (SLA) permettant de bénéficier d'une assistance. Gardez également à l'esprit que certains services, tels qu'Ingress, nécessitent des configurations de noeud worker à haute disponibilité. Il se peut que vous ne puissiez pas exécuter ces services ou vos applications dans des clusters avec seulement deux noeuds dans un pool de noeuds worker. Pour plus d'informations, voir Planification de votre cluster pour la haute disponibilité.

Clusters classiques ou VPC

Les clusters doivent toujours comporter au moins 2 noeuds worker. Notez qu'il n'est pas possible d'avoir un cluster comportant 0 nœuds de travail, et que vous ne pouvez ni mettre hors tension ni suspendre la facturation de vos nœuds de travail.

Clusters Satellite

Les clusters peuvent être créés à l'aide de la topologie de réplique unique, ce qui signifie qu'un seul noeud worker. Notez que si vous créez un cluster Satellite à l'aide d'une topologie à réplique unique, vous ne pouvez pas ajouter de noeuds worker ultérieurement.

Quelles versions le service prend-il en charge?

Red Hat OpenShift on IBM Cloud prend en charge simultanément plusieurs versions de Red Hat OpenShift. Lorsqu'une nouvelle version (n) est publiée, les versions antérieures jusqu'à deux versions en arrière ( n-2 ) sont prises en charge. Les versions au-delà de deux versions avant la version la plus récente (n-3) sont d'abord obsolètes, puis finissent par ne plus être prises en charge.

Pour plus d’informations sur les versions prises en charge et les opérations de mise à jour à effectuer pour passer d’une version à une autre, consultez les informations sur les versions de l’ Red Hat OpenShift on IBM Cloud.

Quels sont les systèmes d'exploitation de noeud worker pris en charge par le service?

Pour la liste des systèmes gérés par noeud worker pris en charge par version de cluster, voir les informations de version deRed Hat OpenShift on IBM Cloud.

Où est disponible ce service ?

Red Hat OpenShift on IBM Cloud est disponible dans le monde entier. Vous pouvez créer des clusters dans toutes les régions prises en charge par l' Red Hat OpenShift on IBM Cloud.

Pour plus d'informations sur les régions prises en charge, voir Emplacements.

Le service est-il à haute disponibilité ?

Oui. Par défaut, Red Hat OpenShift on IBM Cloud configure de nombreux composants, tels que le maître cluster avec des répliques, l'anti-affinité, et d'autres options pour augmenter la haute disponibilité du service. Vous pouvez accroître la redondance et la tolérance aux pannes de vos noeuds worker de cluster, de votre stockage, de vos réseaux et de vos charges de travail en les configurant dans une architecture à haute disponibilité. Pour une vue d'ensemble de la configuration par défaut et des options permettant d'accroître l'accessibilité, voir Création d'une stratégie de cluster hautement disponible.

Pour connaître les dernières dispositions de l'accord sur les niveaux de service à haute disponibilité, voir Conditions d'utilisation d'IBM Cloud. En général, les dispositions des accords sur les niveaux de service nécessitent que, lorsque vous les configurez dans une architecture à haute disponibilité, vous répartissiez vos ressources d'infrastructure uniformément sur trois zones de disponibilité différentes. Par exemple, pour recevoir une couverture haute disponibilité selon les termes du contrat de service, vous devez configurer un cluster multizone avec un total d'au moins 6 nœuds de travail, deux nœuds de travail par zone qui sont répartis également sur trois zones.

Comment fonctionnent les groupements multizones ?

Que faire si je souhaite configurer plusieurs clusters dans différentes régions?

Vous pouvez configurer plusieurs clusters dans différentes régions d'une géolocalisation (par exemple Sud des Etats-Unis et Est des Etats-Unis) ou entre plusieurs géolocalisations (par exemple Sud des Etats-Unis et Europe centrale). Ces deux types de configuration offrent le même niveau de disponibilité pour votre application, mais ajoutent également une certaine complexité quand il s'agit de partage et de réplication de données. Dans la plupart des cas, rester dans la même géolocalisation est largement suffisant. Mais si vous avez des utilisateurs à travers le monde, il peut être préférable de configurer un cluster où se trouvent vos utilisateurs afin que vos utilisateurs ne connaissent pas de temps d'attente lorsqu'ils envoient une demande à votre application.

Quelles options s'offrent à moi pour répartir la charge de travail entre plusieurs clusters?

Pour équilibrer vos charges de travail sur plusieurs clusters, vous devez rendre vos applications disponibles sur le réseau public en utilisant Ingress, des routeurs ou des équilibreurs de charge de réseau (NLB). Les services de routeur et les équilibreurs de charge de réseau se voient affecter une adresse IP publique que vous pouvez utiliser pour accéder à vos applications.

Pour équilibrer les charges de travail entre vos applications, ajoutez les adresses IP publiques de vos services de routeur et de vos équilibreurs de charge de réseau à un équilibreur de charge global CIS ou à votre propre équilibreur de charge global.

Que faire si je souhaite équilibrer la charge des tâches sur le réseau privé?

IBM Cloud n'offre pas de service d'équilibrage de charge global sur le réseau privé. Toutefois, vous pouvez connecter votre cluster à un équilibreur de charge privé que vous hébergez dans votre réseau sur site à l'aide de l'une des options VPN prises en charge. Prenez soin d'exposer vos applications sur le réseau privé en utilisant Ingress, des routeurs ou des équilibreurs de charge de réseau (NLB) et d'utiliser l'adresse IP privée dans vos paramètres VPN pour connecter votre application à votre réseau sur site.

Le maître et les noeuds worker sont-ils à haute disponibilité ?

L'architecture et l'infrastructure de Red Hat OpenShift on IBM Cloud est conçue pour assurer la fiabilité, réduire les temps d'attente de traitement et favoriser la disponibilité maximale du service. Par défaut, tous les clusters dans Red Hat OpenShift on IBM Cloud sont configurés avec plusieurs instances du maître Red Hat OpenShift pour assurer la disponibilité et l'accessibilité de vos ressources de cluster, même si une ou plusieurs instances de votre maître Red Hat OpenShift sont indisponibles.

Vous pouvez accentuer la haute disponibilité de votre cluster et protéger votre application des interruptions en répartissant vos charges de travail sur plusieurs noeuds worker dans plusieurs zones d'une région. Cette configuration, appelée cluster multizone, garantit l'accessibilité de votre application, même en cas d'indisponibilité d'un nœud de travail ou d'une zone entière.

Pour vous prémunir contre une panne touchant l'ensemble d'une région, créez plusieurs clusters et répartissez-les dans différentes régions d' IBM Cloud. En configurant un équilibreur de charge de réseau (NLB) pour vos clusters, vous pouvez obtenir un équilibrage de charge interrégional et une mise en réseau interrégionale de vos clusters.

Si vous avez des données qui doivent être disponibles, même en cas de panne, veillez à stocker vos données dans un stockage persistant.

Pour plus d'informations sur les moyens d'obtenir la haute disponibilité pour votre cluster, voir Haute disponibilité pour Red Hat OpenShift on IBM Cloud.

Mes applications se répartissent-elles automatiquement entre les zones?

Cela dépend de la manière dont vous avez configuré l'application. Voir Planification de déploiements à haute disponibilité et Planification de stockage persistant à haute disponibilité.

Les nœuds de travail sont-ils chiffrés?

Le disque secondaire du noeud worker est chiffré. Pour plus d'informations, voir Présentation du chiffrement de cluster. Après avoir créé un pool de noeuds worker, vous constaterez peut-être que le nom de la version de noeud worker contient .encrypted, par exemple, b3c.4x16.encrypted.

Quelles sont les normes de conformité auxquelles le service est conforme ?

IBM Cloud repose sur de nombreuses normes en matières de données, de finance, de santé, d'assurance, de confidentialité, de sécurité, de technologie et de conformité internationale. Pour plus d'informations, voir Conformité IBM Cloud.

Pour consulter la configuration système requise en détail, vous pouvez générer un rapport de compatibilité des produits logiciels pour Red Hat OpenShift on IBM Cloud. Notez que la conformité dépend du fournisseur d'infrastructure sous-jacent pour les noeuds worker, les réseaux et les ressources de cluster.

Infrastructure classique: Red Hat OpenShift on IBM Cloud met en œuvre des contrôles conformes aux normes de sécurité suivantes :

• Cadre Privacy Shield Suisse/Etats-Unis et Privacy Shield UE-EU
• Health Insurance Portability and Accountability Act (HIPAA)
• Normes Service Organization Control (SOC 1 Type 2, SOC 2 Type 2)
• International Standard on Assurance Engagements 3402 (ISAE 3402), rapports d'assurance quant à la fiabilité des contrôles au niveau de l'organisation des services
• International Organization for Standardization (ISO 27001, ISO 27017, ISO 27018)
• Payment Card Industry Data Security Standard (PCI DSS)

Infrastructure VPC: Red Hat OpenShift on IBM Cloud met en œuvre des contrôles conformes aux normes de sécurité suivantes :

• Cadre Privacy Shield Suisse/Etats-Unis et Privacy Shield UE-EU
• Health Insurance Portability and Accountability Act (HIPAA)
• International Standard on Assurance Engagements 3402 (ISAE 3402), rapports d'assurance quant à la fiabilité des contrôles au niveau de l'organisation des services

Satellite: consultez la documentation IBM Cloud Satellite.

Puis-je utiliser d'autres services IBM Cloud avec mon cluster?

Vous pouvez ajouter des services d'infrastructure et de plateforme IBM Cloud, ainsi que des services de fournisseurs tiers à votre cluster Red Hat OpenShift on IBM Cloud pour activer l'automatisation, renforcer la sécurité ou améliorer vos fonctions de surveillance et de journalisation dans le cluster.

Pour obtenir la liste des services pris en charge, voir Intégration de services.

Comment installer un Cloud Pak dans mon cluster?

Les packages Cloud Pak sont intégrés dans le catalogue IBM Cloud pour que vous puissiez installer et configurer rapidement tous les composants Cloud Pak dans un cluster Red Hat OpenShift, nouveau ou existant. Lorsque vous installez l’ Cloud Pak, l’ Cloud Pak est provisionnée avec Schematics et un espace de travail Schematics est créé pour vous. Vous pouvez utiliser cet espace de travail par la suite pour accéder aux informations d'installation de votre package Cloud Pak. L'accès à vos services Cloud Pak s'effectue à partir de l'URL du package Cloud Pak. Pour plus d'informations, consultez la documentation deCloud Pak

Puis-je utiliser l'autorisation d'utilisation d'Red Hat OpenShift fournie avec mon package Cloud Pak pour mon cluster ?

Oui, si votre package Cloud Pak comprend une autorisation d'utilisation permettant d'exécuter certaines versions de noeud worker installées avec OpenShift Container Platform. Pour consulter vos droits d'accès, rendez-vous sur IBM Passport Advantage. Notez que votre ID IBM Cloud doit correspondre à votre ID IBM Passport Advantage.

Vous pouvez créer le cluster ou le pool de travailleurs au sein d’un cluster existant à l’aide du droit d’accès Cloud Pak dans la console ou en utilisant l’option --entitlement ocp_entitled dans les commandes CLI ibmcloud oc worker-pool create classic ibmcloud oc cluster create classic ou. Veillez à spécifier le nombre et la version appropriés des noeuds worker que vous êtes autorisé à utiliser.

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.

Puis-je installer plusieurs Cloud Paks dans le même cluster Red Hat OpenShift on IBM Cloud ?

Oui, mais vous devrez peut-être ajouter des noeuds worker supplémentaires pour que chaque Cloud Pak dispose de suffisamment de ressources de calcul pour s'exécuter. En outre, vous pouvez installer une seule instance du même Cloud Pak par cluster, par exemple Cloud Pak for Data; ou plusieurs instances dans différents projets du même cluster, par exemple Cloud Pak for Automation. Pour plus d'informations sur le dimensionnement, consultez la documentationCloud Pak.

Que contient un package Cloud Pak ?

Les packages Cloud Pak sont des logiciels intégrés sous licence et conteneurisés qui sont optimisés pour fonctionner ensemble dans les cas d'utilisation d'entreprise, en assurant la cohérence en termes de déploiement, contrôle d'accès et facturation. Vous pouvez utiliser de manière flexible certaines parties des Cloud Paks lorsque vous en avez besoin, en choisissant la combinaison de cœurs de processeurs virtuels du logiciel la mieux adaptée à vos charges de travail. Vous pouvez également modifier la combinaison de coeurs de processeurs virtuels avec l'évolution de vos charges de travail.

En fonction du package Cloud Pak, vous obtenez des logiciels IBM sous licence et des logiciels open source regroupés pour une expérience de gestion unifiée comprenant des fonctions de journalisation, de surveillance, de sécurité et d'accès.

• IBM Produits: les Cloud Paks étendent les logiciels et middlewares sous licence d' IBM, disponibles sur IBM Marketplace, et intègrent ces produits à votre cluster afin de moderniser, d'optimiser et d'exécuter des charges de travail en cloud hybride.
• Logiciels open source : les packages Cloud Pak peuvent également inclure des composants open source pour les solutions natives de cloud et les solutions de cloud hybride portables. En principe, les logiciels open source ne sont pas gérés et vous êtes chargé de conserver vos composants à jour et sécurisés. Cependant, les packages Cloud Pak vous aident à gérer de manière cohérente l'intégralité du cycle de vie des composants Cloud Pak et des charges de travail que vous effectuez avec eux. Comme le logiciel open source est fourni avec l’ Cloud Pak, vous bénéficiez de l’assistance d’ IBM et de l’intégration avec certaines fonctionnalités d’ IBM Cloud, telles que le contrôle d’accès et la facturation.

Pour connaître les composants de chaque Cloud Pak, consultez la documentation Cloud Pak.

Que dois-je savoir de plus pour utiliser des packages Cloud Pak ?

Lorsque vous configurez votre package Cloud Pak, il peut être nécessaire de gérer des ressources spécifiques à Red Hat OpenShift, telles que des contraintes de contexte de sécurité. Prenez soin d'utiliser l'interface de ligne de commande oc ou l'interface de ligne de commande kubectl version 1.12 pour interagir avec ces ressources, par exemple, oc get scc. La version de l'interface de ligne de commande kubectl 1.11 comporte un bogue qui génère une erreur lorsque vous exécutez des commandes sur des ressources propres à Red Hat OpenShift, telles que kubectl get scc.

Les outils tiers et open source que j'utilise avec mon cluster sont-ils pris en charge par IBM ?

Consultez la politique d' IBM relative à l'open source et aux tiers.

Comment suis-je facturé ? Puis-je estimer et contrôler les coûts dans mon cluster ?

Voir Gestion des coûts de vos clusters.

Puis-je rétromigrer mon cluster vers une version précédente?

Non, vous ne pouvez pas rétromigrer votre cluster vers une version précédente.

Puis-je déplacer mon cluster actuel vers un autre compte?

Non, vous ne pouvez pas déplacer le cluster vers un autre compte que celui dans lequel il a été créé.

Comment puis-je maintenir mon cluster dans un état pris en charge ?

• Assurez-vous que votre cluster exécute toujours une version Red Hat OpenShift prise en charge.
• Lorsqu'une nouvelle version mineure d'Red Hat OpenShift est publiée, une version plus ancienne est rapidement obsolète et n'est plus prise en charge.

Pour plus d'informations, voir Mise à jour du maître et des noeuds worker.

Quelles opérations sont bloquées si mon cluster exécute un système d'exploitation non pris en charge?

Les opérations suivantes sont bloquées lorsqu'un système d'exploitation n'est pas pris en charge:

• rechargement de l'agent
• remplacement d'agent sans mise à jour
• remplacement d'agent par mise à jour
• mise à jour de
• création de pool de noeuds worker (avec un système d'exploitation non pris en charge)
• rééquilibrage du pool de noeuds worker
• redimensionnement du pool de noeuds worker (mise à l'échelle)
• ajout de zone de pool de noeuds worker
• redimensionner le groupe d'instances (correctif)
• autoscaler remove worker ( v2/autoscalerRemoveWorker )

Combien coûtent les conteneurs confidentiels?

IBM ne facture pas de frais supplémentaires pour les conteneurs confidentiels. Le coût reste le même pour les frais de service et les frais standard de l'ISV pour chaque module confidentiel qui commence en tant qu'ISV aux taux standard de IBM Cloud.

Puis-je construire mon propre CVM (podvm) pour les conteneurs confidentiels?

Oui. Le site ConfigMap peut être configuré pour pointer vers une machine virtuelle confidentielle (CVM) que vous avez configurée. IBM ne fournit pas d'aide pour construire son propre système. La création d'une image par vous-même peut entraîner des problèmes que le service d'assistance IBM ne peut pas résoudre.

Que dois-je utiliser comme fiduciaire dans les conteneurs confidentiels?

Pour le développement, l'exécution d'un simple trustee dans Docker / Podman sur VM est suffisante. Ces conteneurs peuvent également être configurés directement sur OpenShift. Étant donné que l'administrateur est le garant de la sécurité de l'environnement, n'utilisez pas d'administrateur au sein du cluster OpenShift, qui est censé ne pas être fiable.

Pour la production, utilisez l'autorité de confiance Intel et configurez INITDATA pour qu'il utilise l'autorité de confiance Intel. Vous devez permettre à votre cluster de communiquer avec Intel, comme les groupes de sécurité, les permissions sécurisées par défaut OpenShift, etc.

Où puis-je obtenir de l'aide pour les contenants confidentiels?

OpenShift L'opérateur Sandboxed Containers sur Red Hat OpenShift on IBM Cloud est pris en charge par Red Hat et IBM. Utiliser les canaux d'assistance standard pour les deux services. Si votre OpenShift est licencié par l'intermédiaire de IBM Cloud, contactez IBM. Si vous apportez vos propres licences OpenShift à partir de Red Hat, vous pouvez contacter Red Hat.

Combien de pods de pairs puis-je exécuter par nœud de travail?

Le nombre de pods pairs que vous pouvez exécuter par nœud de travailleur est contrôlé par plusieurs limites :

1. PEERPODS_LIMIT_PER_NODE (paramètre): Cette limite configurable sur le site peer-pods-cm ConfigMap contrôle le nombre maximum de VSI de pods homologues qui peuvent être planifiés par nœud de travail. La valeur par défaut est 10. Vous pouvez augmenter cette valeur, mais vous devez également tenir compte des autres contraintes ci-dessous.

2. Kubernetes limite de pods : Kubernetes limite le nombre total de pods par nœud en fonction du nombre de vCPUs (10 pods par vCPU ). Par exemple, un nœud de travailleur 16x64 peut prendre en charge jusqu'à 110 pods. Étant donné que chaque pod pair est soutenu par une construction de pod Kubernetes sur le nœud de travail, cette limite s'applique même si la charge de travail réelle s'exécute dans un VSI distinct.

3. CPU et mémoire du nœud de travail : Chaque pod pair consomme environ 250m de CPU et 120Mi de mémoire sur le nœud de travail pour la construction du pod Kubernetes. Vous devez vous assurer que vos nœuds de travail disposent de suffisamment de CPU et de mémoire pour prendre en charge le nombre souhaité de pods pairs.

Pour augmenter la valeur de PEERPODS_LIMIT_PER_NODE:

1. Mettre à jour le site peer-pods-cm ConfigMap dans l'espace de noms openshift-sandboxed-containers-operator. Pour plus d'informations, voir Création de conteneurs confidentiels.

   oc -n openshift-sandboxed-containers-operator patch cm peer-pods-cm \
     --type merge \
     -p '{"data":{"PEERPODS_LIMIT_PER_NODE":"24"}}'
   

2. Redémarrez le daemonset de l'adaptateur API Cloud.

   oc -n openshift-sandboxed-containers-operator rollout restart daemonset/osc-caa-ds
   

3. Vérifier que la nouvelle limite est appliquée.

   oc get nodes -o json | jq -r '[.items[] | select (.status.allocatable["kata.peerpods.io/vm"] != null)| .status.allocatable["kata.peerpods.io/vm"] | tonumber] | add'
   

Lorsque vous calculez la valeur optimale de PEERPODS_LIMIT_PER_NODE, tenez compte du profil de votre nœud de travail. Par exemple, avec un nœud de travail 16x64 (16 vCPUs ), le maximum théorique basé sur le seul CPU serait d'environ 24 peer pods par nœud (en supposant que 250m CPU par peer pod et en tenant compte des autres processus du système). Cependant, vous êtes également limité par la limite de 110 pods par nœud de Kubernetes.

Que signifie l'erreur Insufficient kata.peerpods.io/vm?

Si vous rencontrez une erreur du type suivant lors de la planification des pods pairs :

Warning FailedScheduling 0/30 nodes are available: 9 Insufficient kata.peerpods.io/vm. preemption: 0/30 nodes are available: 9 No preemption victims found for incoming pod.

Cette erreur indique que vous avez atteint la limite de PEERPODS_LIMIT_PER_NODE sur vos nœuds de travail. La ressource kata.peerpods.io/vm représente le nombre d'emplacements de pods pairs disponibles sur chaque nœud de travailleur.

Pour résoudre cet incident, procédez comme suit :

1. Vérifier la limite de courant et l'allocation.

   oc get nodes -o json | jq '.items[] | {name: .metadata.name, allocatable: .status.allocatable["kata.peerpods.io/vm"], capacity: .status.capacity["kata.peerpods.io/vm"]}'
   

2. Vérifier combien de pods pairs sont actuellement en cours d'exécution.

   oc get pods -A -o json | jq '.items[] | select(.spec.runtimeClassName == "kata-remote") | "\(.metadata.namespace)/\(.metadata.name)"' | wc -l
   

3. Augmentez la valeur de PEERPODS_LIMIT_PER_NODE comme décrit dans la section Combien de pods pairs puis-je exécuter par nœud de travail?

4. Vous pouvez également ajouter des nœuds de travail à votre cluster pour augmenter la capacité totale.

Les conteneurs confidentiels peuvent-ils répondre à des normes de sécurité spécifiques, telles que NIST 800-53 R5?

Pourquoi est-ce que j'obtiens une erreur d'authentification IAM après avoir effectué la mise à niveau vers l'opérateur « OpenShift Sandboxed Containers » 1.12.1?

Après avoir effectué la mise à jour vers la version 1.12.1 de l'opérateur « Sandboxed Containers » d' OpenShift, il se peut que vous constatiez une erreur similaire à celle-ci dans les journaux de l'adaptateur d'API cloud (CAA):

cloud-api-adaptor: cluster error with:
 Unauthorized
further details:
 {
    "StatusCode": 401,
    "Result": {
        "code": "A0007",
        "description": "You do not have the correct permissions to perform this action..."
    }
}

Cette erreur se produit car la version 1.12.1 a introduit une nouvelle exigence consistant à récupérer automatiquement le groupe de sécurité du cluster via l'API du service de cluster IKS ( IBM Cloud ). Lorsque vous utilisez « IBMCLOUD_IAM_PROFILE_ID » pour l'authentification (identité de la ressource de calcul), il se peut que le profil IAM ne dispose pas des autorisations nécessaires pour interroger l'API du service de cluster.

Pour résoudre ce problème, choisissez l'une des options suivantes :

1. Accorder des autorisations IAM supplémentaires (recommandé): mettez à jour le profil IAM afin d'y inclure les autorisations relatives à l'API du service de cluster IKS, notamment la possibilité d'appeler GetClusterTypeSecurityGroups(). Contactez votre administrateur d' IBM Cloud pour qu'il vous attribue les autorisations nécessaires.

2. Définissez explicitement l'ID du groupe de sécurité : configurez la variable d'environnement IBMCLOUD_VPC_SG_ID dans le fichier peer-pods-cm ( ConfigMap ) afin de contourner la recherche automatique du groupe de sécurité du cluster :

   oc -n openshift-sandboxed-containers-operator patch cm peer-pods-cm \
     --type merge \
     -p '{"data":{"IBMCLOUD_VPC_SG_ID":"<your-security-group-id>"}}'
   

   Redémarrez ensuite le daemonset de l'adaptateur API Cloud :

   oc -n openshift-sandboxed-containers-operator rollout restart daemonset/osc-caa-ds
   

3. Utiliser l'authentification par clé API: passez de l'authentification via IBMCLOUD_IAM_PROFILE_ID à celle via IBMCLOUD_API_KEY, qui offre généralement des autorisations plus étendues. Mettez à jour le secret « peer-pods-secret » en utilisant votre clé API à la place du profil IAM.

Pour plus d'informations sur les modifications apportées à la version 1.12.1, consultez le commit correspondant du projet en amont « cloud-api-adaptor » à l'adresse dde66055.

Contactez votre équipe IBM pour discuter de vos intérêts spécifiques en matière de sécurité.

Quel est le fuseau horaire par défaut des nœuds de travail de mon VPC?

À partir de la version de correctif 4.16.56_1602, publiée le 27 janvier 2026, tous les futurs correctifs pour les clusters VPC fixent l'heure locale du nœud de travail à UTC.