Limitations et quotas des services

Passez en revue les limitations et les quotas du service qui s'appliquent aux clusters, et découvrez quelles limites peuvent être ajustées si nécessaire.

Si vous prévoyez d'atteindre l'une des limitations suivantes pour Red Hat OpenShift on IBM Cloud, contactez le support IBM et fournissez l'ID de cluster, la nouvelle limite de quota et la région dans votre ticket de demande de service.

Limitations et quotas de service

Red Hat OpenShift on IBM Cloud est fourni avec les limitations et quotas de service ci-après qui s'appliquent à tous les clusters, quel que soit le fournisseur d'infrastructure que vous prévoyez d'utiliser. N'oubliez pas que les limitations propres aux clusters classiques et VPC s'appliquent également.

Pour afficher les limites de quota appliquées aux ressources liées aux clusters dans votre compte IBM Cloud, utilisez la commande ibmcloud oc quota ls.

Limitations deRed Hat OpenShift on IBM Cloud
Catégorie Description
Limites de débit d'API 200 demandes par 10 secondes vers l'API Red Hat OpenShift on IBM Cloud à partir de chaque adresse IP source unique.
Déploiement d"application Les applications que vous déployez et les services que vous intégrez dans votre cluster doivent être en mesure de s'exécuter sur le système d'exploitation des noeuds worker.
Plug-in réseau Calico La modification du plug-in, des composants ou des paramètres Calico par défaut n'est pas prise en charge. Par exemple, ne déployez pas de nouvelle version de plug-in Calico ou modifiez les ensembles de démons ou les déploiements pour les composants Calico, les ressources IPPool par défaut ou les nœuds Calico. A la place, vous pouvez suivre la documentation pour créer une règle Calico NetworkPolicy ou GlobalNetworkPolicy, pour modifier la MTU Calico ou pour désactiver le plug-in de mappage de port pour l'interface CNI Calico.
Quota de cluster Vous ne pouvez pas dépasser 100 clusters par région et par fournisseur d'infrastructure. Toutefois, à partir du 1er janvier 2024, les quotas sont augmentés progressivement avant d'atteindre 100. Si vous avez besoin de plus de ressources, contactez le support IBM. Dans la demande d'assistance, indiquez la nouvelle limite de quota pour la région et le fournisseur d'infrastructure de votre choix. Pour répertorier les quotas, exécutez ibmcloud quota ls.
Kubernetes Veillez à prendre connaissance des limitations du projet Kubernetes.
Fournisseur KMS La personnalisation des adresses IP autorisées à se connecter à votre instance IBM® Key Protect for IBM Cloud® n'est pas prise en charge.
Red Hat OpenShift Veillez à consulter les limitations d' OpenShift Container Platform s pour votre version.
Journaux de pod Kubernetes Pour vérifier les pods d'applications individuelles, vous pouvez utiliser la ligne de commande pour exécuter oc logs <pod name>. N'utilisez pas le tableau de bord Kubernetes pour diffuser les journaux de vos pods, car cela pourrait entraîner une interruption de l'accès au tableau de bord de Kubernetes.
Monitoring
  • Étant donné que IBM gère votre maître de cluster, l'alerte d'événement pour le maître est désactivée. IBM surveille votre maître cluster et corrige les problèmes à mesure qu'ils sont détectés. Pour cette raison, dans la perspective Administrateur de Red Hat OpenShift, vous pouvez voir un message Not available pour le statut du plan de contrôle.
  • Le gestionnaire d'alertes Prometheus intégré inclut deux règles qui s'affichent en tant qu'alertes actives dans un état FIRING : KubeControllerManagerDown et KubeSchedulerDown. Ces composants font partie du maître cluster géré par IBM, par conséquent, vous pouvez ignorer ces alertes.
Système d'exploitation Les noeuds worker doivent exécuter l'un des systèmes d'exploitation pris en charge. Vous ne pouvez pas créer de cluster avec des noeuds worker qui exécutent différents types de systèmes d'exploitation. Pour plus d'informations, voir les informations de version deRed Hat OpenShift on IBM Cloud.
Catalogue OperatorHub Pour utiliser le catalogue OperatorHub dans des clusters privés, voir Désactivation d' OperatorHub et mise en miroir des images source du catalogue dans icr.io.
Instances de pod Vous pouvez exécuter 110 pods par noeud worker. Si vous avez des noeuds worker dotés d'au moins 11 coeurs d'UC, vous pouvez prendre en charge 10 pods par coeur, dans la limite de 250 pods par noeud worker. Le nombre de pods inclut des pods kube-system et ibm-system qui s'exécutent sur le noeud worker. Pour améliorer les performances, pensez à limiter le nombre de pods que vous exécutez par coeur de traitement de sorte que vous ne sur-utilisiez pas le nœud worker. Par exemple, sur un noeud worker avec une version b3c.4x16, vous pouvez exécuter 10 pods par coeur qui n'utilisent pas plus de 75 % de la capacité totale du noeud worker.
Obsolète Code d'accès à utilisation unique limitée dans le temps (TOTP) Pour utiliser TOTP, prenez soin d'activer l'authentification multi-facteur (MFA) pour l'ensemble de votre compte IBM Cloud. Si l'AMF n'est activée que pour certains utilisateurs mais pas au niveau du compte, des erreurs d'authentification peuvent se produire.
Quota de noeud worker Un maximum de 500 nœuds de travail pour tous les comptes créés avant le 1er janvier 2024. Pour les comptes créés à partir de cette date, le quota maximum est de 200 après une période de baisse des quotas. Les quotas s'appliquent par fournisseur d'infrastructure de cluster. Si vous avez besoin de plus de ressources, contactez le support IBM. Dans la demande d'assistance, indiquez la nouvelle limite de quota pour la région et le fournisseur d'infrastructure de votre choix. Pour afficher la liste des quotas, exécutez la commande ibmcloud ks quota ls.
Taille de pool de noeuds worker Votre cluster doit toujours comporter au moins 2 nœuds. En raison du quota de noeud worker, vous êtes limité quant au nombre de pools de noeuds worker par cluster et quant au nombre de noeuds worker par pool de noeuds worker. Par exemple, avec le quota de noeuds worker par défaut fixé à 500 par région, vous pouvez disposer d'un maximum de 500 pools de noeuds worker comportant chacun 1 noeud worker dans une région avec un seul cluster. Ou, vous pouvez disposer d'un pool de noeuds worker comportant un maximum de 500 noeuds worker dans une région avec un seul cluster.
Red Hat Enterprise Linux CoreOS Le nombre maximum de zones ajoutées à un cluster est de 12. Par exemple, 3 pools de travailleurs RHCOS avec 3 zones chacun représenteront 9/12 du quota pour ce cluster.
Nombre de noeuds worker Les grappes peuvent avoir un maximum de 500 nœuds de travail.
Désignation de cluster Pour que le sous-domaine Ingress et le certificat soient correctement enregistrés, les 24 premiers caractères du nom des clusters doivent être différents. Si vous créez et supprimez des clusters portant le même nom ou des noms ayant les mêmes 24 premiers caractères 5 fois ou plus en l'espace de 7 jours, par exemple à des fins d'automatisation ou de test, vous risquez d'atteindre la limite de taux Let's Encrypt Duplicate Certificate.
Groupes de ressources Un cluster peut être créé dans un seul groupe de ressources que vous ne pouvez plus modifier par la suite. Si vous créez un cluster dans le mauvais groupe de ressources, vous devez supprimer le cluster et le créer à nouveau dans le groupe de ressources approprié. En outre, si vous devez utiliser la commande ibmcloud oc cluster service bind pour intégrer un service IBM Cloud, ce dernier doit se trouver dans le même groupe de ressources que le cluster. Les services qui n'utilisent pas de groupes de ressources, comme IBM Cloud Container Registry, ou qui ne nécessitent pas de liaison de service, comme IBM Cloud Logs, fonctionnent même si le cluster se trouve dans un groupe de ressources différent.

Limitations associées aux clusters Red Hat OpenShift on IBM Cloud

Passez en revue les contraintes spécifiques aux clusters d' Red Hat OpenShift. N'oubliez pas que les limitations de service, de cluster classique ou de cluster de VPC s'appliquent également.

Limitations du clusterOpenShift Container Platform
Catégorie Description
Mise à l'échelle automatique de cluster L'outil d'ajustement automatique de la taille des clusters d' Red Hat OpenShift, accessible depuis la console Red Hat OpenShift Administration > Paramètres du cluster ou via l'API ClusterAutoscaler``autoscaling.openshift.io/v1, n'est pas pris en charge. Utilisez à la place le plug-in Helm ibm-iks-cluster-autoscaler.
Mises à jour de cluster Vous devez mettre à jour votre cluster à l'aide de l'API, de l'interface de ligne de commande ou de la console Red Hat OpenShift on IBM Cloud. Vous ne pouvez pas mettre à jour votre version de cluster à partir d'outils de plateforme de conteneur OpenShift tels que la console Web Red Hat OpenShift.
Journaux de conteneur Si vous utilisez un opérateur de journalisation de conteneur, tel que Fluentd pour envoyer des journaux à une pile ElasticSearch, vous devez mettre à jour le déploiement de journalisation de cluster pour utiliser la classe de stockage ibmc-block-gold.
Clusters privés

Selon le fournisseur d'infrastructure, vos options pour les clusters privés sont limitées.

  • VPC: Lorsque vous créez votre cluster VPC dans la console IBM Cloud, votre cluster possède un noeud final de service de cloud public et privé. Si vous souhaitez uniquement un point de terminaison de service de cloud privé, vous devez créer le cluster via l'interface de ligne de commande(CLI) et inclure l'option --disable-public-service-endpoint. Si vous activez cette option, votre cluster est créé avec des routeurs et des contrôleurs Ingress qui, par défaut, exposent vos applications uniquement sur le réseau privé. Si vous souhaitez ultérieurement exposer des applications à un réseau public, vous devez créer manuellement des routeurs publics et des contrôleurs d'entrée.
  • Classic : Vous pouvez activer le noeud final de service de cloud public et privé ou le noeud final de service de cloud public uniquement, mais vous ne pouvez pas activer le noeud final de service de cloud privé uniquement. Après la création du cluster, vous ne pouvez plus modifier les nœuds finaux de service.
Journalisation Pour configurer une pile composée d’ OpenShift Container Platform, d’ Elasticsearch, d’ Fluentd et de Kibana(EFK), consultez la section consacrée à l’installation de l’opérateur de journalisation du cluster.
Catalogue de services Le catalogue de services n'est pas pris en charge. Utilisez des opérateurs à la place. N'utilisez pas OperatorHub pour installer le catalogue de services.
Maillage de service Le module complémentaire géré Istio n'est pas pris en charge. Utilisez plutôt l'opérateur de maillage de services Red Hat. Remarque : la configuration IBM Cloud par défaut des routeurs active la mise en réseau d'hôte, qui n'est pas compatible avec la règle de réseau de maillage de service. Pour que l'ingress du service mesh fonctionne, appliquez une politique réseau.

Limitations associées aux clusters classique

Les clusters d'infrastructure classique dans Red Hat OpenShift on IBM Cloud sont commercialisés avec les limitations suivantes :

Calcul

N'oubliez pas que les limitations de service s'appliquent également.

Limitations de calcul liées aux clusters classiques
Catégorie Description
Instances réservées La capacité réservée et les instances réservées ne sont pas prises en charge.
Versions de noeud worker Les nœuds de travail sont disponibles dans certaines variantes de ressources de calcul.
Accès à l'hôte de noeud worker Pour la sécurité, vous ne pouvez pas utiliser SSH dans l'hôte de traitement du noeud worker.

Mise en réseau

N'oubliez pas que les limitations de service s'appliquent également.

Limitations liées à la mise en réseau des clusters classiques
Catégorie Description
ALB Ingress
Equilibreurs de charge de réseau (NLB)
  • Vous ne pouvez pas créer des équilibreurs de charge réseau de la version 2.0 (NLB 2.0) pour exposer vos applications.
  • Vous ne pouvez pas créer de sous-domaines pour les NLB privés.
  • Vous pouvez enregistrer jusqu'à 128 sous-domaines. Cette limite peut être levée sur demande en ouvrant un cas de support.
Console Web Red Hat OpenShift La console Web ne peut pas être exposée sur le réseau privé sur des clusters ayant des noeuds finaux publics et privés. Si vous souhaitez rendre la console Web accessible depuis le réseau privé, votre cluster ne doit pas disposer d'un point de terminaison public activé.
VLAN privés uniquement Les équilibreurs de charge du réseau privé (NLBs) ne peuvent pas être enregistrés avec le serveur de noms de domaine (DNS), de sorte que le cluster ne peut pas être créé avec une interface réseau privée. Les noeuds worker doivent être connectés aux VLAN publics et privés. Vous pouvez toujours créer un service privé pour exposer vos applications sur le réseau privé uniquement.
Noeuds finaux de service Lorsque vous créez un cluster, vous pouvez activer le noeud final de service de cloud public et privé ou le noeud final de service de cloud public uniquement, mais vous ne pouvez pas activer le noeud final de service de cloud privé uniquement. Après la création du cluster, vous ne pouvez plus modifier les nœuds finaux de service.
Sous-réseaux par VLAN Chaque réseau local virtuel (VLAN) est limité à 40 sous-réseaux.

Stockage

N'oubliez pas que les limitations de service s'appliquent également.

Limitations de stockage des clusters classiques
Catégorie Description
Instances de volume Vous pouvez avoir un total de 250 volumes de stockage par blocs et de fichier d'infrastructure IBM Cloud par compte. Si vous montez plus que cette quantité, un message out of capacity peut s'afficher lors de la création de volumes persistants. Pour plus de FAQ, voir la documentation sur le stockage de fichiers et de blocs. Si vous souhaitez monter plus de volumes, contactez le IBM. Dans votre ticket de demande de service, incluez votre ID de compte et le nouveau quota de volume de stockage de fichiers ou de stockage par blocs que vous souhaitez.
Portworx Passez en revue les limitations Portworx.
Stockage des fichiers En raison de la manière dont le stockage de fichiers NFS IBM Cloud configure les droits utilisateur Linux, il se peut que vous rencontriez des erreurs lorsque vous utilisez le stockage de fichiers. Si c'est le cas, vous devrez peut-être configurer Red Hat OpenShift Security Context Constraints ou utiliser un autre type de stockage.

Accès des utilisateurs classiques

N'oubliez pas que les limitations de service s'appliquent également.

Limitations classiques de l'accès des utilisateurs aux clusters
Catégorie Description
Accès aux adresses IP Red Hat OpenShift on IBM Cloud ne prend pas en charge la restriction de l'accès à des utilisateurs spécifiques en activant l'accès par adresse IP. Si vous souhaitez restreindre l'accès des utilisateurs ou limiter les services et les VPC auxquels un utilisateur peut accéder, envisagez une restriction basée sur le contexte.

Limitations de cluster de VPC

Les clusters VPC dans Red Hat OpenShift on IBM Cloud sont libérés avec les limitations suivantes. En outre, l'ensemble des quotas de VPC, limites de VPC, limitations de service VPC et limitations de service standard s'applique.

Calcul

N'oubliez pas que les limitations de service s'appliquent également.

Limitations de calcul liées aux clusters de VPC
Catégorie Description
Clusters par VPC Les VPC sont limités à 25 clusters chacun.
Chiffrement Par défaut, les disques secondaires de vos noeuds worker sont chiffrés au repos par le fournisseur d'infrastructure VPC sous-jacent. Cependant, vous ne pouvez pas apporter votre propre chiffrement aux instances de serveur virtuel sous-jacentes.
Emplacement Les clusters VPC ne sont disponibles que dans certaines régions multizones.
Virtual Private Cloud Voir Limitations et Quotas.
Quotas de ressources VPC VPC gère des quotas pour la mémoire vCPU,, le GPU, le stockage d'instance et les ressources de stockage d'instance optimisées par compte. Lorsque vous provisionnez des nœuds de travail d'instance de serveur virtuel (VSI) sur une infrastructure publique, ces ressources sont comptabilisées dans les quotas de votre compte VPC. Si vous atteignez une limite de quota, le provisionnement des nœuds de travailleur échoue. Pour afficher vos quotas actuels et leur utilisation, voir Affichage des métriques de ressources VPC. Pour demander une augmentation de quota, ouvrez un dossier d'assistance auprès du VPC. Pour plus d'informations, consultez la section « Quotas VPC ».

Remarque: cette gestion des quotas ne s'applique actuellement qu'aux nœuds de travail VSI hébergés sur une infrastructure publique. Le service « Red Hat OpenShift on IBM Cloud » continue de gérer les quotas pour les nœuds de travail sur hôtes dédiés et les nœuds de travail « bare metal ».
Versions de noeud worker Seules certaines versions sont disponibles pour les machines virtuelles des nœuds de travail et les nœuds de travail « bare metal ».
Accès à l'hôte de noeud worker Pour la sécurité, vous ne pouvez pas utiliser SSH dans l'hôte de traitement du noeud worker.
Mises à jour de noeud worker Les actions de mise à jour des workers VPC dépendent du type de worker. Pour les machines « bare metal » VPC, vous pouvez utiliser la commande « ibmcloud oc worker reload » pour effectuer un rechargement. Pour les instances de serveur virtuel VPC, utilisez la commande « ibmcloud oc worker replace ». Si vous remplacez plusieurs noeuds worker en même temps, ils sont supprimés et remplacés simultanément, et non un par un. Vérifiez que vous disposez de suffisamment de capacité dans votre cluster pour replanifier vos charges de travail avant de remplacer des noeuds worker.

Mise en réseau

N'oubliez pas que les limitations de service s'appliquent également.

Limitations liées à la mise en réseau des clusters de VPC
Catégorie Description
Longueur d'URL d'application La résolution DNS est gérée par le noeud final privé virtuel (VPE) du cluster, qui peut résoudre des URL comportant jusqu'à 130 caractères. Si vous exposez des applications dans votre cluster avec des URL, par exemple, le sous-domaine Ingress ou des routes Red Hat OpenShift, assurez-vous que les URL ne dépassent pas 130 caractères.
Vitesses réseau Les vitesses réseau de profil VPC font référence aux vitesses des interfaces de noeud worker. La bande passante disponible pour les instances VPC est partagée entre le stockage et le trafic réseau. Par défaut, l'allocation de stockage est de 25% de la bande passante maximale. La vitesse du réseau, telle qu'indiquée dans les tableaux ci-dessous, correspond à la bande passante disponible pour un travailleur disposant d'une seule interface réseau, après déduction de l'allocation par défaut de 25 % de la bande passante de stockage.
NodePort Vous pouvez accéder à une application via un port de noeud (NodePort) uniquement si vous êtes connecté à votre réseau VPC privé, par exemple, via une connexion VPN. Pour accéder à une application via Internet, vous devez utiliser à la place un équilibreur de charge VPC ou un service Ingress.
Réseau de pods Les listes de contrôle d'accès VPC filtrent le trafic entrant et sortant pour votre cluster au niveau du sous-réseau et les groupes de sécurité filtrent le trafic entrant et sortant pour votre cluster au niveau des noeuds worker. Pour contrôler le trafic dans le cluster au niveau pod à pod, vous ne pouvez pas utiliser les groupes de sécurité VPC ou les listes de contrôle d'accès. A la place, utilisez des règles réseau Kubernetes et Calico, qui peuvent contrôler le trafic réseau de niveau pod qui utilise l'encapsulation IP-in-IP.
Passerelle publique Si le noeud final de service public est activé, vous devez connecter une passerelle publique à chaque sous-réseau VPC afin de permettre à vos noeuds worker de communiquer sur le réseau public. Les composants Red Hat OpenShift par défaut, tels que la console Web et OperatorHub, nécessitent un accès via un réseau public.
Noeuds finaux de service Lorsque vous créez votre cluster de VPC dans la console IBM Cloud, votre cluster possède un noeud final de service cloud public et un noeud final de service cloud privé. Si vous souhaitez uniquement un point de terminaison de service de cloud privé, vous devez créer le cluster via l'interface de ligne de commande(CLI) et inclure l'option --disable-public-service-endpoint. Si vous activez cette option, votre cluster est créé avec des routeurs et des contrôleurs Ingress qui, par défaut, exposent vos applications uniquement sur le réseau privé. Si vous souhaitez ultérieurement exposer des applications sur un réseau public, vous devez créer manuellement des routeurs publics et des contrôleurs Ingress.
Sous-réseaux
  • Consultez les restrictions relatives à la mise en réseau VPC.
  • Ne supprimez pas les sous-réseaux que vous associez à votre cluster lors de la création de celui-ci ou lorsque vous ajoutez des nœuds de travail dans une zone. Si vous supprimez un sous-réseau VPC que votre cluster a utilisé, des problèmes peuvent se produire au niveau des équilibreurs de charge qui utilisent des adresses IP à partir du sous-réseau et il se peut que vous ne puissiez pas créer de nouveaux équilibreurs de charge.
Équilibreur de charge de VPC Voir les limitations d'équilibreur de charge VPC.

Stockage

N'oubliez pas que les limitations de service s'appliquent également.

Limitations de stockage des clusters de VPC
Catégorie Description
Classe de stockage pour les tailles de profil Pour plus d'informations, voir Profils de volume disponibles.
Types pris en charge Vous pouvez uniquement configurer IBM Cloud Object Storage et Cloud Databases.
Connexions de volume Voir Limites de connexion de volume.
Portworx Passez en revue les limitations Portworx.
Block Storage for VPC La classe de stockage par défaut dans les clusters VPC ne peut pas être modifiée. Toutefois, vous pouvez créer votre propre classe de stockage.

Accès des utilisateurs VPC

N'oubliez pas que les limitations de service s'appliquent également.

Limitations d'accès des utilisateurs du cluster VPC
Catégorie Description
Accès aux adresses IP Red Hat OpenShift on IBM Cloud ne prend pas en charge la restriction de l'accès à des utilisateurs spécifiques en activant l'accès par adresse IP. Si vous souhaitez restreindre l'accès des utilisateurs ou limiter les services et les VPC auxquels un utilisateur peut accéder, envisagez une restriction basée sur le contexte.

Limitations associées aux clusters Satellite

Passez en revue les limitations suivantes pour les clusters Red Hat OpenShift on IBM Cloud que vous créez dans un emplacement Satellite. N'oubliez pas que les limitations de service s'appliquent également.

Satellite limites des clusters
Catégorie Description
Modules complémentaires de cluster Passez en revue les modules complémentaires gérés non pris en charge pour les clusters Red Hat OpenShift dans un emplacement Satellite. Par exemple, le programme de mise à l'échelle automatique de cluster et Istio ne sont pas pris en charge.
Réseau
  • Par défaut, aucun contrôleur d'équilibrage de charge n'est déployé avec les clusters Satellite. Par conséquent, les services Kubernetes et LoadBalancer ne sont pas fournis par défaut. Vous pouvez intégrer votre propre solution d'équilibreur de charge dans les clusters, comme par exemple MetalLB.
  • Les hôtes qui exécutent les nœuds de travail de votre cluster doivent répondre aux exigences de réseau de l'hôte et aux exigences spécifiques du fournisseur, telles que pour AWS, Azure, GCP, et IBM Cloud (à des fins de test et de démonstration uniquement).
  • L'encapsulation VXLAN étant requise pour le trafic entre les pods situés sur différents nœuds de travail, les vitesses de transfert des données entre les pods situés sur différents nœuds de travail peuvent être inférieures à la capacité réseau des hôtes.
Stockage pour les hôtes de noeud worker Voir Host storage and attached devices.
Stockage pour les applications Aucun fournisseur de stockage n'est installé par défaut dans vos clusters Satellite. Par conséquent, aucune classe de stockage Kubernetes préconfigurée n'est configurée par défaut dans vos clusters pour stocker vos données d'application dans un volume persistant Kubernetes sauvegardé par une unité de stockage. Pour connaître les options permettant de configurer un fournisseur de stockage, voir Description des modèles de stockage Satellite.
Noeuds worker Les noeuds worker s'exécutent sur des hôtes dans vos propres environnements d'infrastructure. Les hôtes doivent répondre aux exigences propres aux hôtes et aux fournisseurs, comme par exemple pour AWS, Azure, GCP et IBM Cloud (à des fins de test et de démonstration uniquement). Vous êtes chargé de gérer le cycle de vie de l'infrastructure de vos hôtes, notamment l'ajout et la mise à jour des nœuds de travail. Par conséquent, les opérations sur les noeuds worker, telles que les commandes ibmcloud oc worker add, update, replace, reload, ne sont pas prises en charge.
Pools de noeuds worker Pour utiliser des opérations telles que resize, votre pool de noeuds worker utilise des libellés d'hôte qui doivent correspondre à des hôtes disponibles (non affectés) dans l'emplacement Satellite.
Clusters à noeud unique Tout cluster comportant moins de trois noeuds worker manque de haute disponibilité. En mettant à disposition un cluster à noeud unique, vous acceptez que vous soyez plus susceptible de subir des temps d'indisponibilité et des interruptions de votre charge de travail et que les mises à niveau de noeud worker régulières entraînent la mise hors ligne de votre charge de travail. De plus, si un cluster est mis à disposition en tant que cluster à noeud unique, il ne peut pas être converti ultérieurement en cluster standard à haute disponibilité. Vous pouvez ajouter d'autres noeuds, mais les déploiements standard n'augmentent pas la taille des répliques et le cluster ne devient pas hautement disponible. Les clusters à noeud unique doivent s'exécuter sur un emplacement Satellite avec Red Hat CoreOS(RHCOS)activé. Les hôtes de plan de contrôle sur votre emplacement et l'hôte que vous affectez à votre cluster à noeud unique doivent exécuter les systèmes d'exploitation RHEL 8 ou RHCOS. Pris en charge uniquement pour les clusters Satellite qui exécutent la version 4.11 ou ultérieure. OpenShift Data Foundation n'est pas pris en charge sur les clusters à noeud unique. Portworx n'est pas pris en charge sur les clusters à noeud unique.

Fonctions et opérateurs non pris en charge dans Red Hat OpenShift on IBM Cloud

Les fonctions et opérateurs suivants ne sont pas pris en charge dans Red Hat OpenShift on IBM Cloud.

Au lieu d'ajuster les performances des nœuds de travail à l'aide MachineConfig des fichiers dans Red Hat OpenShift, vous pouvez modifier l'hôte à l'aide d'un daemonset fichier. Pour plus d'informations, consultez Modifier la Calico MTU ou Optimiser les performances pour les Red HatCoreOS nœuds de travail.

  • courtier AMQ
  • courtier AMQ LTS
  • Interconnexion AMQ
  • AMQ en ligne
  • Streams AMQ
  • Opérateur de ressource de plateforme d'automatisation Ansible
  • Concepteur d'API
  • Opérateur d'automatisation métier
  • Camel K
  • Opérateur de gestion des coûts
  • Opérateur de grille de données
  • Gestionnaire d'unités
  • Opérateur d'intégrité de fichier
  • Console de fusion
  • Utilisation de fusion
  • Opérateur de contrôleur d'accès
  • JBoss EAP
  • JBoss Web Server
  • Stockage du gestionnaire de volume logique (LVM)
  • MachineConfigs
  • Service SaaS de gestion des compteurs et des coûts
  • Service OpenShift Cloud Manager (OCM) SaaS
  • OpenShift Proxy à l'échelle du cluster
  • OpenShift Data Foundation: prise en charge via le module complémentaire de cluster pour les clusters Classic et VPC ou via le modèle Satellite pour les clusters Satellite.
  • OpenShift SDN et la plupart des autres plugins réseau ne sont pas pris en charge
    • Calico est pris en charge sur toutes les versions de cluster.
    • La prise en charge d'OVN est disponible pour les clusters VPC Red Hat OpenShift à partir de la version 4.20, uniquement avec des nœuds de travail RHCOS.
    • Ne mettez pas à jour et ne supprimez pas ces plugins réseau en dehors du processus normal de mise à jour du maître du cluster.
  • Opérateur de module complémentaire de performances
  • Opérateur PTP
  • Opérateur Quay
  • Red Hat OpenStack Intégration Kuryr de plateformes
  • Opérateur d'intégration Red Hat
  • Opérateur de registre de services
  • Opérateur Smart Gateway
  • Opérateur réseau SR-IOV: pris en charge dans les clusters Satellite uniquement.
  • Télémétrie et aperçus connectés avec l'expérience
  • Configuration de machine Windows: les noeuds worker avec des systèmes d'exploitation Windows ne sont pas pris en charge.
  • ImageContentSourcePolicy, ImageDigestMirrorSet et ImageTagMirrorSet ne sont pas pris en charge.