Limiti e quote del servizio

Esamina le limitazioni e le quote del servizio applicabili ai cluster e scopri quali limiti possono essere modificati all'occorrenza.

Se prevedi di raggiungere uno dei seguenti limiti di Red Hat OpenShift on IBM Cloud, contatta l'assistenza di IBM e indica nel ticket di assistenza l'ID del cluster, il nuovo limite di quota e la regione.

Limitazioni del servizio e delle quote

Red Hat OpenShift on IBM Cloud include le seguenti limitazioni e quote di servizio che si applicano a tutti i cluster, indipendentemente dal provider dell'infrastruttura che intendi utilizzare. Tieni presente che si applicano anche le limitazioni per il cluster classico e VPC.

Per visualizzare i limiti di quota sulle risorse relative al cluster nel tuo IBM Cloud account, utilizza il ibmcloud oc quota ls comando.

Red Hat OpenShift on IBM Cloud limitazioni
Categoria Descrizione
Limiti di velocità API 200 richieste per ogni 10 secondi all'API Red Hat OpenShift on IBM Cloud da ogni indirizzo IP di origine univoco.
Distribuzione delle applicazioni Le applicazioni a cui esegui la distribuzione e i servizi che integri con il tuo cluster devono poter essere eseguiti sul sistema operativo dei nodi di lavoro.
Calico plug-in di rete La modifica del Calico plug-in, dei componenti o delle Calico impostazioni predefinite non è supportata. Ad esempio, non distribuire una nuova versione Calico del plug-in, né modificare i set di daemon o le distribuzioni per i Calico componenti, le risorse IPPool predefinite o Calico i nodi. È invece possibile seguire la documentazione per creare un CalicoNetworkPolicy o GlobalNetworkPolicy, per modificare Calico l'MTU o per disabilitare il plug-in di mappatura delle porte per il Calico CNI.
Quota cluster Non è possibile superare i 100 cluster per regione e per fornitore di infrastruttura. Tuttavia, a partire dal 1° gennaio 2024, le quote vengono aumentate gradualmente fino a raggiungere il 100%. Se hai bisogno di ulteriori risorse, contatta IBM l'assistenza. Nella richiesta di assistenza, indica il nuovo limite di quota per la regione e il fornitore di infrastrutture desiderati. Per elencare le quote, eseguire ibmcloud quota ls.
Kubernetes Assicurati di prendere visione delle limitazioni del progetto “ Kubernetes ”.
Provider KMS La personalizzazione degli indirizzi IP consentiti per la connessione alla tua istanza IBM® Key Protect for IBM Cloud® non è supportata.
Red Hat OpenShift Assicurati di consultare le limitazioni di OpenShift Container Platform relative alla tua versione.
Log dei pod Kubernetes Per controllare i log dei singoli pod delle app, è possibile utilizzare la riga di comando per eseguire il comando oc logs ``. Non utilizzare il dashboard Kubernetes per trasmettere i log per i tuoi pod poiché ciò potrebbe causare un'interruzione nel tuo accesso al dashboard Kubernetes.
Monitoraggio
  • Poiché il master del cluster viene gestito da IBM, gli avvisi relativi agli eventi per il master sono disabilitati. IBM monitora il tuo master cluster e risolve i problemi non appena vengono rilevati. Per questo motivo, nella prospettiva Amministratore del Red Hat OpenShift, è possibile che venga visualizzato un Not available messaggio relativo allo stato del piano di controllo.
  • Il gestore di avvisi Prometheus integrato include due regole che vengono visualizzate come avvisi attivi in uno FIRING stato: KubeControllerManagerDown e KubeSchedulerDown. Questi componenti fanno parte del master cluster gestito da IBM, quindi puoi ignorare questi avvisi.
Sistema operativo I nodi worker devono eseguire uno dei sistemi operativi supportati. Non è possibile creare un cluster con nodi worker che eseguono tipi diversi di sistemi operativi. Per ulteriori informazioni, consultare le Red Hat OpenShift on IBM Cloud informazioni sulla versione.
OperatorHub catalogo Per utilizzare il OperatorHub catalogo nei cluster privati, vedere Disabilitazione OperatorHub e mirroring delle immagini sorgente del catalogo su icr.io.
Istanze pod Puoi eseguire 110 pod per ogni nodo di lavoro. Se hai dei nodi di lavoro con 11 o più core di CPU, puoi supportare 10 pod per ogni core, fino a un limite di 250 pod per ogni nodo di lavoro. Il numero di pod include i pod kube-system e ibm-system che vengono eseguiti sul nodo di lavoro. Per migliorare le prestazioni, si consiglia di limitare il numero di pod in esecuzione per ogni core di calcolo, in modo da evitare un utilizzo eccessivo del nodo di lavoro. Ad esempio, su un nodo di lavoro con un profilo b3c.4x16 potresti eseguire 10 pod per ogni core che utilizzano non più del 75% della capacità totale del nodo di lavoro.
Codice di accesso monouso basato sul tempo ({: tag-red} TOTP) [deprecato] Per utilizzare TOTP, assicurati di abilitare l'autenticazione a più fattori(MFA) per l'intero IBM Cloud account. Se l'autenticazione a più fattori (MFA) è abilitata solo per alcuni utenti ma non a livello di account, potrebbero verificarsi errori di autenticazione.
Quota nodo di lavoro Un massimo di 500 nodi di lavoro per tutti gli account creati prima del 1° gennaio 2024. Per gli account creati a partire da tale data, la quota massima è di 200 dopo un periodo di quote inferiori. Le quote si applicano per ciascun fornitore di infrastrutture cluster. Se hai bisogno di ulteriori risorse, contatta IBM l'assistenza. Nella richiesta di assistenza, indica il nuovo limite di quota per la regione e il fornitore di infrastrutture desiderati. Per visualizzare le quote attualmente in uso, eseguire il comando ibmcloud ks quota ls``.
Dimensione pool di nodi di lavoro Il cluster deve sempre avere almeno 2 nodi. A causa della quota del nodo di lavoro, esiste un limite sul numero di pool di nodi di lavoro per ogni cluster e sul numero di nodi di lavoro per pool di nodi di lavoro di cui puoi disporre. Ad esempio, con la quota predefinita del nodo di lavoro pari a 500 per ogni regione, puoi avere fino a 500 pool di nodi lavoro di 1 nodo di lavoro ciascuno in una regione con un solo cluster. Oppure, potresti avere 1 pool di nodi di lavoro con un massimo di 500 nodi di lavoro in una regione con un solo cluster.
CoreOSRed Hat Enterprise Linux nodi di lavoro Il numero massimo di zone aggiunte a un cluster è 12. Ad esempio, 3 pool di lavoratori RHCOS con 3 zone ciascuno rappresenteranno 9/12 della quota per quel cluster.
Numero di nodi di lavoro I cluster possono avere un massimo di 500 nodi di lavoro.
Denominazione del cluster Per garantire che il sottodominio Ingress e il certificato siano registrati correttamente, i primi 24 caratteri dei nomi dei cluster devono essere diversi. Se crei ed elimini cluster con lo stesso nome o nomi che hanno le stesse prime 24 caratteri 5 volte o più entro 7 giorni, ad esempio per scopi di automazione o test, potresti raggiungere il limite di certificati duplicati di Let's Encrypt.
Gruppi di risorse Un cluster può essere creato in un solo gruppo di risorse che non puoi modificare in seguito. Se crei un cluster nel gruppo di risorse non corretto, devi eliminare il cluster e crearlo nuovamente nel gruppo di risorse corretto. Inoltre, se hai bisogno di utilizzare il comando ibmcloud oc cluster service bind per l'integrazione con un servizio IBM Cloud, tale servizio deve trovarsi nello stesso gruppo di risorse del cluster. I servizi che non utilizzano gruppi di risorse, come IBM Cloud Container Registry, o che non richiedono un binding di servizio, come IBM Cloud Logs, funzionano anche se il cluster si trova in un gruppo di risorse diverso.

Red Hat OpenShift on IBM Cloud limiti del cluster

Esamina i limiti specifici dei Red Hat OpenShift cluster. Tieni presente che si applicano anche le limitazioni per il servizio e per il cluster classico o cluster VPC.

OpenShift Container Platform limiti del cluster
Categoria Descrizione
Ridimensionamento automatico del cluster L'autoscaler del cluster " Red Hat OpenShift " accessibile dalla console Red Hat OpenShift ( Amministrazione > Impostazioni cluster ) o l'oggetto " ClusterAutoscaler " dell'API autoscaling.openshift.io/v1 non sono supportati. Utilizza invece il ibm-iks-cluster-autoscalerHelm plug-in.
Aggiornamenti cluster È necessario aggiornare il cluster utilizzando Red Hat OpenShift on IBM Cloud l'API, la CLI o gli strumenti della console. Non è possibile aggiornare la versione del cluster tramite gli strumenti di OpenShift Container Platform, come la console web Red Hat OpenShift.
Log del contenitore Se si utilizza un operatore di registrazione dei log per container, come Fluentd, per inviare i log a uno stack ElasticSearch, è necessario aggiornare la distribuzione della registrazione del cluster in modo che utilizzi la classe di archiviazione ibmc-block-gold.
Cluster privati

A seconda del fornitore dell'infrastruttura, le opzioni disponibili per i cluster privati sono limitate.

  • VPC: quando si crea un cluster VPC nella IBM Cloud console, il cluster dispone sia di un endpoint di servizio cloud pubblico che privato. Se si desidera solo un endpoint del servizio cloud privato, è necessario creare il cluster tramite la CLI, specificando l'opzione --disable-public-service-endpoint. Se si seleziona questa opzione, il cluster verrà creato con router e controller Ingress che, per impostazione predefinita, rendono accessibili le applicazioni solo sulla rete privata. Se in seguito desideri esporre le app a una rete pubblica, devi creare manualmente router pubblici e controller Ingress.
  • Classico: puoi abilitare l'endpoint del servizio cloud pubblico e privato o solo l'endpoint del servizio cloud pubblico, ma non puoi abilitare solo l'endpoint del servizio cloud privato. Dopo la creazione del cluster, non è possibile modificare successivamente gli endpoint del servizio.
Registrazione Per configurare uno stack composto da OpenShift Container Platform Elasticsearch, Fluentd e Kibana(EFK), consultare la guida all'installazione dell'operatore di logging del cluster.
Catalogo dei servizi Il catalogo dei servizi non è supportato. Utilizza invece gli operatori. Non utilizzare OperatorHub per installare il catalogo dei servizi.
Rete di servizi Il componente aggiuntivo gestito da Istio non è supportato. Utilizzare invece l'operatore di rete di servizi Red Hat. Nota: la configurazione IBM Cloud predefinita dei router abilita la rete host, che non è compatibile con la politica di rete delle reti di servizi. Affinché l'Ingress del service mesh funzioni, è necessario applicare una politica di rete.

Limitazioni per i cluster classici

I cluster dell'infrastruttura classica in Red Hat OpenShift on IBM Cloud vengono rilasciati con le seguenti limitazioni.

Calcolo

Tieni presente che si applicano anche le limitazioni del servizio.

Limitazioni di calcolo del cluster classico
Categoria Descrizione
Istanze riservate La capacità riservata e le istanze riservate non sono supportate.
Profili del nodo di lavoro I nodi di lavoro sono disponibili in determinate varianti di risorse di calcolo.
Accesso host dei nodi di lavoro Per motivi di sicurezza, non è possibile connettersi via SSH all'host di calcolo del nodo di lavoro.

Rete

Tieni presente che si applicano anche le limitazioni del servizio.

Limitazioni di rete del cluster classico
Categoria Descrizione
ALB Ingress
  • Il bilanciatore di carico (ALB) dell'applicazione Ingress è in grado di elaborare 32.768 connessioni al secondo. Se il traffico Ingress supera questo numero, aumenta il numero di repliche ALB nel cluster per gestire l'aumento del carico di lavoro.
  • ALB che eseguono solo l 'immagine Ingress Red Hat OpenShift on IBM Cloud personalizzata: HTTP/2 non supportato.
  • ALB che eseguono solo [l] 'immagine Ingress Red Hat OpenShift on IBM Cloud personalizzata (/docs/containers?topic=containers-managed-ingress-about): i nomi dei ClusterIP servizi che espongono le app devono essere univoci in tutti gli spazi dei nomi del cluster.
NLB (Network Load Balancer)
  • Non è possibile creare bilanciatori di carico di 2.0 rete (NLB 2.0 ) per esporre le app.
  • Non è possibile creare sottodomini per NLB privati.
  • È possibile registrare fino a 128 sottodomini. Questo limite può essere innalzato su richiesta, aprendo un [caso
di supporto](/docs/openshift?topic=openshift-get-help).
Console web Red Hat OpenShift La console web non può essere esposta sulla rete privata nei cluster che dispongono sia di endpoint pubblici che privati. Se desideri esporre la console web sulla rete privata, il tuo cluster non può avere un endpoint pubblico abilitato.
Solo VLAN private I bilanciatori di carico (NLB) della rete privata non possono essere registrati sul server dei nomi di dominio (DNS), pertanto non è possibile creare il cluster utilizzando esclusivamente un'interfaccia di rete privata. I nodi di lavoro devono essere connessi a VLAN sia pubbliche che private. Puoi comunque creare un servizio privato per esporre le tue applicazioni solo sulla rete privata.
Endpoint di servizio Quando si crea un cluster, è possibile abilitare l'endpoint del servizio cloud pubblico e privato o solo l'endpoint del servizio cloud pubblico, ma non è possibile abilitare solo l'endpoint del servizio cloud privato. Dopo la creazione del cluster, non è possibile modificare successivamente gli endpoint del servizio.
Sottoreti per ogni VLAN Ogni VLAN ha un limite di 40 sottoreti.

Archiviazione

Tieni presente che si applicano anche le limitazioni del servizio.

Limitazioni di archiviazione del cluster classico
Categoria Descrizione
Istanze del volume Puoi avere un totale di 250 volumi di archiviazione file e blocchi dell'infrastruttura IBM Cloud per ogni account. Se si montano più volumi di questa quantità, potrebbe comparire un messaggio di errore del tipo “ out of capacity ” durante il provisioning dei volumi persistenti. Per ulteriori domande frequenti, consulta la documentazione relativa all'archiviazione di file e blocchi. Se desideri montare più volumi, contatta IBM l'assistenza. Nel ticket di supporto, includi il tuo ID account e la nuova quota del volume di archiviazione file o blocchi desiderata.
Portworx Esamina le Portworx limitazioni.
Storage file A causa del modo in cui l'archiviazione file NFS IBM Cloud configura le autorizzazioni utente di Linux, potresti riscontrare degli errori quando utilizzi l'archiviazione file. In tal caso, potrebbe essere necessario configurare i vincoli di Red Hat OpenShift contesto di sicurezza o utilizzare un tipo di archiviazione diverso.

Accesso utente classico

Tieni presente che si applicano anche le limitazioni del servizio.

Limitazioni classiche dell'accesso degli utenti al cluster
Categoria Descrizione
Accesso indirizzo IP La limitazione dell'accesso per utenti specifici tramite l'abilitazione dell'accesso tramite indirizzo IP non è supportata da Red Hat OpenShift on IBM Cloud. Se desideri limitare l'accesso degli utenti o restringere i servizi e le VPC a cui un utente può accedere, prendi in considerazione le restrizioni basate sul contesto.

Limitazioni del cluster VPC

I cluster VPC in Red Hat OpenShift on IBM Cloud sono rilasciati con le seguenti limitazioni. Inoltre si applicano tutte le quote e limiti VPC, limitazioni del servizio VPC e limitazioni del servizio regolari sottostanti.

Calcolo

Tieni presente che si applicano anche le limitazioni del servizio.

Limitazioni di calcolo per i cluster VPC
Categoria Descrizione
Cluster per VPC I VPC sono limitati a 25 cluster ciascuno.
Crittografia I dischi secondari dei tuoi nodi di lavoro vengono crittografati quando inattivi per impostazione predefinita dal provider dell'infrastruttura VPC sottostante. Tuttavia, non è possibile applicare la propria crittografia alle istanze del server virtuale sottostante.
Posizione I cluster VPC sono disponibili solo in alcune regioni multizona.
VPC (Virtual Private Cloud) Vedi Limitazioni e quote.
Quote di risorse VPC VPC gestisce le quote per la memoria vCPU,, la GPU, lo storage dell'istanza e le risorse di storage ottimizzate dell'istanza su base individuale. Quando si forniscono nodi worker di istanze di server virtuale (VSI) su infrastrutture pubbliche, queste risorse vengono conteggiate nelle quote dell'account VPC. Se si raggiunge un limite di quota, il provisioning dei nodi worker non riesce. Per visualizzare le quote e l'uso corrente, vedere Visualizzazione delle metriche delle risorse VPC. Per richiedere un aumento della quota, aprire un caso di assistenza con VPC. Per ulteriori informazioni, consultare la sezione " Quote VPC ".

Nota: questa gestione delle quote si applica attualmente solo ai nodi di lavoro VSI presenti sull'infrastruttura pubblica. Red Hat OpenShift on IBM Cloud continua a gestire le quote per i nodi di lavoro su host dedicati e bare metal.
Profili del nodo di lavoro Per le macchine virtuali dei nodi di lavoro e per i nodi di lavoro bare metal sono disponibili solo determinati formati.
Accesso host dei nodi di lavoro Per motivi di sicurezza, non è possibile connettersi via SSH all'host di calcolo del nodo di lavoro.
Aggiornamenti del nodo di lavoro Le operazioni di aggiornamento dei worker VPC dipendono dal tipo di worker. Per chi lavora con i server bare metal VPC, è possibile utilizzare il comando ibmcloud oc worker reload per applicare un reload. Per i worker delle istanze di server virtuali VPC, utilizzare il comando ibmcloud oc worker replace . Se si sostituiscono più nodi di lavoro contemporaneamente, questi vengono eliminati e sostituiti in modo simultaneo, non uno alla volta. Assicurati di avere una capacità sufficiente nel tuo cluster per riprogrammare i carichi di lavoro prima di sostituire i nodi di lavoro.

Rete

Tieni presente che si applicano anche le limitazioni del servizio.

Limitazioni di rete per i cluster VPC
Categoria Descrizione
Lunghezza URL dell'app La risoluzione DNS è gestita dall'endpoint privato virtuale(VPE) del cluster, che può risolvere URL fino a 130 caratteri. Se esponi le app nel tuo cluster con URL, come il sottodominio Ingress o Red Hat OpenShift le route, assicurati che gli URL abbiano una lunghezza massima di 130 caratteri.
Velocità di rete Le velocità di rete del profilo VPC si riferiscono alle velocità delle interfacce dei nodi di lavoro. La larghezza di banda disponibile per le istanze VPC è condivisa tra lo storage e il traffico di rete. Per impostazione predefinita, l'allocazione dello spazio di archiviazione è pari al 25% della larghezza di banda massima. La velocità di rete, come mostrato nelle tabelle sottostanti, è la larghezza di banda di rete disponibile per un lavoratore con una singola interfaccia di rete dopo aver dedotto l'allocazione predefinita del 25% della larghezza di banda di archiviazione.
NodePort Puoi accedere a un'applicazione tramite una NodePort solo se sei connesso alla tua rete VPC privata, ad esempio tramite una connessione VPN. Per accedere a un'applicazione da internet, devi utilizzare invece un programma di bilanciamento del carico VPC o un servizio Ingress.
Rete pod Gli elenchi di controllo degli accessi (ACL) VPC filtrano il traffico in entrata e in uscita per il cluster a livello di sottorete, mentre i gruppi di sicurezza filtrano il traffico in entrata e in uscita per il cluster a livello dei nodi di lavoro. Per controllare il traffico all'interno del cluster a livello di pod-to-pod, non è possibile utilizzare i gruppi di sicurezza VPC né le ACL. Utilizza invece le politiche di rete Calico e Kubernetes, che possono controllare il traffico di rete a livello di pod che utilizza l'incapsulamento IP-in-IP.
Gateway pubblico Se l'endpoint del servizio pubblico è abilitato, è necessario collegare un gateway pubblico a ciascuna sottorete VPC in modo che i nodi di lavoro possano comunicare sulla rete pubblica. I componenti predefiniti di Red Hat OpenShift, come la console web e OperatorHub,, richiedono l'accesso alla rete pubblica.
Endpoint di servizio Quando si crea un cluster VPC nella console di IBM Cloud, il cluster dispone sia di un endpoint di servizio cloud pubblico che di uno privato. Se si desidera solo un endpoint del servizio cloud privato, è necessario creare il cluster tramite la CLI, specificando l'opzione --disable-public-service-endpoint. Se si seleziona questa opzione, il cluster verrà creato con router e controller Ingress che, per impostazione predefinita, rendono accessibili le applicazioni solo sulla rete privata. Se in seguito vuoi esporre le tue applicazioni su una rete pubblica, devi creare manualmente dei router e controller Ingress pubblici.
Sottoreti
  • Vedere Limiti di rete VPC.
  • Non eliminare le sottoreti collegate al cluster durante la creazione del cluster o quando si aggiungono nodi di lavoro in una zona. Se elimini una sottorete VPC utilizzata dal tuo cluster, qualsiasi programma di bilanciamento del carico che utilizza gli indirizzi IP dalla sottorete potrebbe presentare dei problemi e potresti non essere in grado di creare nuovi programmi di bilanciamento del carico.
Programma di bilanciamento del carico VPC Vedi Limitazioni del programma di bilanciamento del carico VPC.

Archiviazione

Tieni presente che si applicano anche le limitazioni del servizio.

Limitazioni di archiviazione per i cluster VPC
Categoria Descrizione
Classe di archiviazione per le dimensioni dei profili Per ulteriori informazioni, consultare i profili di volume disponibili.
Tipi supportati Puoi configurare solo IBM Cloud Object Storage e Cloud Databases.
Collegamenti volume Vedi Limiti di allegati di volume.
Portworx Esamina le Portworx limitazioni.
Block Storage for VPC La classe di archiviazione predefinita nei cluster VPC non può essere modificata. Tuttavia, è possibile creare una propria classe di archiviazione.

Accesso utente VPC

Tieni presente che si applicano anche le limitazioni del servizio.

Limitazioni di accesso degli utenti al cluster VPC
Categoria Descrizione
Accesso indirizzo IP La limitazione dell'accesso per utenti specifici tramite l'abilitazione dell'accesso tramite indirizzo IP non è supportata da Red Hat OpenShift on IBM Cloud. Se desideri limitare l'accesso degli utenti o restringere i servizi e le VPC a cui un utente può accedere, prendi in considerazione le restrizioni basate sul contesto.

Satellite limiti del cluster

Esamina le seguenti limitazioni per Red Hat OpenShift on IBM Cloud i cluster creati in una Satellite posizione. Tieni presente che si applicano anche le limitazioni del servizio.

Satellite limiti del cluster
Categoria Descrizione
Componenti aggiuntivi per cluster Esamina i componenti aggiuntivi gestiti non supportati per Red Hat OpenShift i cluster in una Satellite posizione. Ad esempio, l'autoscaler del cluster e Istio non sono supportati.
Rete
  • Per impostazione predefinita, non è presente alcun controller di bilanciamento del carico distribuito con Satellite i cluster e, pertanto, KubernetesLoadBalancer i servizi non sono forniti per impostazione predefinita. È possibile integrare la propria soluzione di bilanciamento del carico nei cluster, come ad esempio MetalLB.
  • Gli host che gestiscono i nodi worker per il cluster devono soddisfare i requisiti di rete dell'host e i requisiti specifici del provider, come ad esempio per AWS, Azure, GCP, e IBM Cloud (solo a scopo di test e dimostrazione).
  • Poiché l'incapsulamento VXLAN è richiesto per il traffico tra pod che si trovano su nodi worker diversi, la velocità di trasferimento dei dati tra pod su nodi worker diversi potrebbe essere inferiore alla capacità di rete degli host.
Archiviazione per host dei nodi di lavoro Vedere Memoria host e dispositivi collegati.
Archiviazione per le applicazioni Nessun provider di archiviazione è installato nei Satellite cluster per impostazione predefinita. Pertanto, nei cluster non sono configurate di default classi di archiviazione Kubernetes preconfigurate per archiviare i dati delle applicazioni in un volume Kubernetes persistente supportato da un dispositivo di archiviazione. Per le opzioni relative alla configurazione di un provider di archiviazione, vedere Informazioni sui modelli Satellite di archiviazione.
Nodi di lavoro I nodi worker vengono eseguiti su host nei propri ambienti infrastrutturali. Gli host devono soddisfare i requisiti specifici dell 'host e del provider, come per esempio AWS, Azure, GCP, e IBM Cloud (solo a scopo di test e dimostrazione). Sei responsabile della gestione del ciclo di vita dell'infrastruttura dei tuoi host, inclusi l'aggiunta e l'aggiornamento dei nodi di lavoro. Pertanto, le operazioni dei nodi worker come ibmcloud oc worker add, update, replace, reload i comandi non sono supportate.
Pool di lavoro Per utilizzare operazioni come resize, il pool di worker utilizza etichette host che devono corrispondere agli host disponibili (non assegnati) nella Satellite posizione.
Cluster a nodo singolo Qualsiasi cluster con meno di tre nodi di lavoro non garantisce un'elevata disponibilità. Provisionando un cluster a nodo singolo, accetti che ci sia una maggiore probabilità di downtime e interruzioni nel tuo carico di lavoro e che gli aggiornamenti regolari dei nodi di lavoro comportino la disconnessione del tuo carico di lavoro. Inoltre, se un cluster viene fornito come cluster a nodo singolo, non può essere successivamente convertito in un cluster standard ad alta disponibilità. È possibile aggiungere altri nodi, ma le distribuzioni standard non aumentano le dimensioni della replica e il cluster non diventa altamente disponibile. I cluster a nodo singolo devono essere eseguiti in una Satellite posizione con Red HatCoreOS(RHCOS)abilitato. Gli host del piano di controllo nella tua posizione e l'host assegnato al cluster a nodo singolo devono eseguire i sistemi operativi RHEL 8 o RHCOS. Supportato solo per Satellite i cluster che eseguono la versione 4.11 o successive. OpenShift Data Foundation non è supportato su cluster a nodo singolo. Portworx non è supportato sui cluster a nodo singolo.

Funzionalità e operatori non supportati in Red Hat OpenShift on IBM Cloud

Le seguenti funzioni e operatori non sono supportati in Red Hat OpenShift on IBM Cloud.

Invece di ottimizzare le prestazioni dei nodi worker con MachineConfig i file in Red Hat OpenShift, è possibile modificare l'host con un daemonset file. Per ulteriori informazioni, vedere Modifica Calico dell'MTU o Ottimizzazione delle prestazioni per i nodi Red HatCoreOS di lavoro.

  • Broker AMQ
  • Broker AMQ LTS
  • Interconnessione AMQ
  • AMQ Online
  • Flussi AMQ
  • Ansible Operatore di risorse della piattaforma di automazione
  • API Designer
  • Operatore di automazione aziendale
  • Cammello K
  • Gestione dei costi Operatore
  • Operatore griglia dati
  • Gestore dispositivi
  • Operatore di integrità dei file
  • Console Fuse
  • Fusibile online
  • Operatore Gatekeeper
  • JBoss EAP
  • Server web JBoss
  • Gestione dello spazio di archiviazione con Logical Volume Manager (LVM)
  • MachineConfigs
  • Servizio di misurazione SaaS e gestione dei costi
  • OpenShift Servizio Cloud Manager SaaS (OCM)
  • OpenShift Proxy a livello di cluster
  • OpenShift Data Foundation: supportato tramite l 'add-on cluster per cluster Classic e VPC o tramite il Satellite modello per Satellite cluster.
  • OpenShift SDN e la maggior parte degli altri plugin di rete non sono supportati
    • Calico è supportato su tutte le versioni del cluster.
    • OVN è supportato per i cluster VPC Red Hat OpenShift a partire dalla versione 4.20 e successive, esclusivamente con nodi di lavoro RHCOS.
    • Non aggiornare né rimuovere questi plugin di rete al di fuori del normale processo di aggiornamento del master del cluster.
  • Operatore aggiuntivo per prestazioni
  • Operatore PTP
  • Operatore di banchina
  • OpenStackRed Hat Integrazione Kuryr della piattaforma
  • Red Hat Operatore di integrazione
  • Operatore del registro dei servizi
  • Operatore gateway intelligente
  • Operatore di rete SR-IOV: supportato solo nei Satellite cluster.
  • Telemetria e approfondimenti Esperienza connessa
  • Configurazione macchina Windows: i nodi worker con sistemi operativi Windows non sono supportati.
  • ImageContentSourcePolicy, ImageDigestMirrorSet, e non ImageTagMirrorSet sono supportati.