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 IBM Cloud Kubernetes Service ?

Pour créer un cluster IBM Cloud Kubernetes Service, déterminez d'abord 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 IBM Cloud Kubernetes Service fonctionne-t-il ?

Avec IBM Cloud Kubernetes Service, vous pouvez créer votre propre cluster Kubernetes 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 Kubernetes à 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 IBM Cloud Kubernetes Service ?

IBM Cloud Kubernetes Service est une offre Kubernetes 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, IBM Cloud Kubernetes Service 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 Kubernetes gérés ?

Tous les clusters dans IBM Cloud Kubernetes Service sont contrôlés par un maître Kubernetes dédié qui est géré par IBM dans un compte d'infrastructure IBM Cloud appartenant à IBM. Le maître Kubernetes, 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é d'IBM Cloud Kubernetes Service. Des modules complémentaires, tels que Fluentd pour la journalisation, qui sont installés automatiquement lorsque vous mettez à disposition le cluster sont automatiquement mis à jour par IBM. Cependant, vous pouvez envisager de désactiver ces mises à jour automatiques pour certains modules complémentaires et les mettre à jour manuellement indépendamment du maître et des noeuds worker. Pour plus d'informations, voir Mise à jour de modules complémentaires de cluster.

Régulièrement, Kubernetes publie des mises à jour principales, secondaires ou des correctifs. Ces mises à jour peuvent affecter la version du serveur d'API Kubernetes ou d'autres composants dans le maître Kubernetes. 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 IBM Cloud Kubernetes Service 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 IBM Cloud Kubernetes Service?

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 IBM Cloud Kubernetes Service 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 IBM Cloud Kubernetes Service, voir Planification des déploiements d'application.

Si vous possédez déjà une application, vous pouvez la faire migrer vers IBM Cloud Kubernetes Service. 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. Code Engine est conçu de sorte que vous n'avez pas besoin d'interagir avec la technologie sous-jacente sur laquelle il est généré. Toutefois, si vous disposez d'outils existants basés sur Kubernetes ou Knative, vous pouvez toujours les utiliser avec Code Engine. Pour plus d'informations, voir Utilisation de Kubernetes pour interagir avec votre application.

Quelles compétences devrais-je avoir avant de déplacer mes applications vers un cluster?

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

Kubernetes et IBM Cloud Kubernetes Service 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' IBM Cloud Kubernetes Service, 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 Kubernetes et IBM Cloud Kubernetes Service 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 IBM Cloud Kubernetes Service 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 Kubernetes, 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é d'IBM Cloud Kubernetes Service.

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

IBM Cloud Kubernetes Service 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 ?

En cas de vulnérabilités détectées dans Kubernetes, Kubernetes publie des CVE dans des bulletins de sécurité pour informer les utilisateurs et indiquer les actions que doivent effectuer les utilisateurs pour résoudre ces vulnérabilités. Les bulletins de sécurité qui concernent les utilisateurs IBM Cloud Kubernetes Service ou la plateforme IBM Cloud sont publiés dans les bulletins 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 IBM Cloud Kubernetes Service. 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 avoir au moins 1 noeud 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?

IBM Cloud Kubernetes Service prend en charge plusieurs versions de Kubernetes simultanément. 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 d’ Kubernetes.

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

Pour obtenir la liste des systèmes gérés par noeud worker pris en charge par version de cluster, voir les informations de version deKubernetes.

Où est disponible ce service ?

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

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

Le service est-il à haute disponibilité ?

Oui. Par défaut, IBM Cloud Kubernetes Service 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 des équilibreurs de charge d'application (ALB) ou des équilibreurs de charge de réseau (NLB). Les équilibreurs de charge d'application 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 équilibreurs de charge d'application 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é à l'aide d'équilibreurs de charge d'application (ALB) ou d'é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 d'IBM Cloud Kubernetes Service 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 IBM Cloud Kubernetes Service sont configurés avec plusieurs instances du maître Kubernetes pour assurer la disponibilité et l'accessibilité de vos ressources de cluster, même si une ou plusieurs instances de votre maître Kubernetes 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 entre 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 IBM Cloud Kubernetes Service.

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 IBM Cloud Kubernetes Service. 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: IBM Cloud Kubernetes Service 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: IBM Cloud Kubernetes Service 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

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 IBM Cloud Kubernetes Service 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 ks worker-pool create classic ibmcloud ks 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 un Version de Kubernetes prise en charge.
• Lorsqu'une nouvelle version mineure de Kubernetes 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 )

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

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