FAQ per Red Hat® OpenShift® on IBM Cloud®
Consulta le domande frequenti ( Domande frequenti ) relative all'utilizzo di Red Hat® OpenShift® on IBM Cloud®.
Cos'è Kubernetes?
Kubernetes è una piattaforma open source per la gestione di carichi di lavoro e servizi inseriti in un contenitore su più host e offre strumenti di gestione per la distribuzione, l'automazione, il monitoraggio e il ridimensionamento di applicazioni inserite in un contenitore con un intervento manuale minimo o nullo. Tutti i contenitori che costituiscono il tuo microservizio sono raggruppati in pod, un'unità logica per garantire una facile gestione e rilevazione. Questi pod vengono eseguiti su host di calcolo gestiti in un cluster Kubernetes che è portatile, estensibile e con riparazione automatica in caso di guasti.
Per ulteriori informazioni su Kubernetes, consulta la documentazione diKubernetes.
Come posso creare un cluster Red Hat OpenShift on IBM Cloud ?
Per creare un cluster Red Hat OpenShift on IBM Cloud, prima decidi se vuoi seguire un'esercitazione per la configurazione di un cluster di base o progettare il tuo proprio ambiente cluster.
- Voglio seguire un tutorial
- Inizia esaminando la documentazione Introduzione, quindi scegli una delle esercitazioni disponibili.
- Desidero progettare il proprio ambiente cluster
- Inizia esaminando la documentazione Introduzione, quindi crea la strategia dell'ambiente cluster.
Come funziona Red Hat OpenShift on IBM Cloud?
Con Red Hat OpenShift on IBM Cloud, puoi creare il tuo cluster Red Hat OpenShift per distribuire e gestire applicazioni containerizzate su IBM Cloud. Le tue applicazioni inserite in un contenitore sono ospitate su host di calcolo dell'infrastruttura IBM Cloud denominati nodi di lavoro. È possibile scegliere di configurare i propri host di elaborazione come macchine virtuali con risorse condivise o dedicate, oppure come macchine bare metal ottimizzabili per l'utilizzo di GPU e di storage definito dal software (SDS). I nodi di lavoro sono controllati da un master Red Hat OpenShift ad alta disponibilità, configurato, monitorato e gestito da IBM. Puoi utilizzare l'API o la CLI di IBM Cloud Kubernetes Service per lavorare con le risorse dell'infrastruttura del cluster e l'API o la CLI di Kubernetes per gestire le tue distribuzioni e i tuoi servizi.
Per ulteriori informazioni su come vengono configurate le tue risorse del cluster, vedi Architettura del servizio. Per trovare un elenco di funzionalità e vantaggi, vedi Vantaggi e offerte di servizi.
Perché dovrei utilizzare Red Hat OpenShift on IBM Cloud?
Red Hat OpenShift on IBM Cloud è un'offerta di Red Hat OpenShift gestita che offre strumenti potenti, un'esperienza utente intuitiva e funzionalità di sicurezza integrate per la distribuzione rapida di applicazioni che è possibile integrare con servizi cloud relativi a IBM Watson®, IA, IoT,, DevOps,, sicurezza e analisi dei dati. In qualità di fornitore certificato di servizi " Kubernetes ", Red Hat OpenShift on IBM Cloud supporta la pianificazione intelligente, l'autoguarigione, il ridimensionamento orizzontale, il rilevamento dei servizi e il bilanciamento del carico, l'implementazione e il rollback automatizzati, nonché la gestione delle informazioni riservate e delle configurazioni. Il servizio ha anche funzionalità avanzate per la gestione semplificata dei cluster, le politiche di sicurezza e isolamento dei contenitori, la capacità di progettare il tuo proprio cluster e strumenti operativi integrati per la coerenza nella distribuzione.
Per una panoramica dettagliata di funzionalità e vantaggi, vedi Vantaggi e offerte di servizi.
Quali piattaforme del contenitore sono disponibili per il mio cluster?
Con IBM Cloud, è possibile creare cluster per i propri carichi di lavoro containerizzati da due diverse piattaforme di gestione dei container: la versione " IBM " di community Kubernetes e Red Hat OpenShift on IBM Cloud. La piattaforma del contenitore selezionata viene installata sui nodi di lavoro e master del tuo cluster. In seguito, sarà possibile aggiornare la versione, ma non sarà possibile tornare a una versione precedente né passare a una piattaforma container diversa. Se vuoi utilizzare più piattaforme del contenitore, crea un cluster separato per ognuna di esse.
Per ulteriori informazioni, consultare il confronto tra i cluster " Red Hat OpenShift " e quelli " Kubernetes " della community.
- Kubernetes
- Kubernetes è una piattaforma open source di orchestrazione dei container di livello produttivo che consente di automatizzare, scalare e gestire le applicazioni containerizzate in esecuzione su un sistema operativo Ubuntu. Con la versione IBM Cloud Kubernetes Service, ottieni l'accesso alle funzioni dell'API Kubernetes della community che sono considerate beta o superiori dalla community. Le funzioni Kubernetes alfa, che sono soggette a modifiche, sono in genere non abilitate per impostazione predefinita. Con Kubernetes, puoi combinare diverse risorse come segreti, distribuzioni e servizi per creare e gestire in sicurezza applicazioni inserite nel contenitore altamente disponibili.
- Red Hat OpenShift
- Red Hat OpenShift on IBM Cloud è una piattaforma basata su Kubernetes, progettata appositamente per accelerare i processi di distribuzione delle applicazioni containerizzate che girano su un sistema operativo Red Hat Enterprise Linux. È possibile orchestrare e scalare i carichi di lavoro esistenti di Red Hat OpenShift, sia in ambiente on-premise che su cloud esterni, ottenendo una soluzione ibrida e portabile che funziona allo stesso modo in scenari multicloud. Per iniziare, prova l'esercitazione diRed Hat OpenShift on IBM Cloud.
Il servizio include un master e dei nodi worker gestiti Red Hat OpenShift?
Ogni cluster presente su Red Hat OpenShift on IBM Cloud è controllato da un master dedicato di Red Hat OpenShift, gestito da IBM all’interno di un account dell’infrastruttura IBM Cloud di proprietà di IBM. Il master dell' Red Hat OpenShift, comprese tutte le componenti del master, le risorse di elaborazione, di rete e di archiviazione, è monitorato costantemente dagli ingegneri di affidabilità del sito (SRE) dell' IBM. Gli SRE applicano i più recenti standard di sicurezza, rilevano e correggono le attività dannose e operano per garantire l'affidabilità e la disponibilità di Red Hat OpenShift on IBM Cloud.
Periodicamente, Red Hat OpenShift rilascia aggiornamenti principali, secondari o patch. Questi aggiornamenti possono influire sulla versione del server API di Red Hat OpenShift o su altri componenti del master di Red Hat OpenShift. IBM aggiorna automaticamente la versione patch, ma devi aggiornare la versione principale e quella secondaria del master. Per ulteriori informazioni, vedi Aggiornamento del master.
Il provisioning dei nodi di lavoro nei cluster standard viene eseguito nel tuo account dell'infrastruttura IBM Cloud. I nodi di lavoro sono dedicati al tuo account ed è una tua responsabilità richiedere degli aggiornamenti tempestivi ai nodi di lavoro per garantire che i componenti Red Hat OpenShift on IBM Cloud e il sistema operativo dei nodi di lavoro siano applicati con gli aggiornamenti e le patch di sicurezza più recenti. Gli aggiornamenti e le patch di sicurezza sono resi disponibili dagli SRE (Site Reliability Engineer) IBM che monitorano continuamente l'immagine Linux installata sui tuoi nodi di lavoro per rilevare vulnerabilità e problemi di conformità della sicurezza. Per ulteriori informazioni, vedi Aggiornamento dei nodi di lavoro.
Quali tipi di workload posso spostare in Red Hat OpenShift on IBM Cloud?
Per alcuni esempi dei tipi di carichi di lavoro che gli utenti trasferiscono solitamente sui vari tipi di cloud, consultare la guida "Trasferimento dei carichi di lavoro su IBM Cloud ". Puoi anche scegliere un approccio ibrido laddove hai dei cluster che vengono eseguiti in entrambi gli ambienti.
Posso automatizzare le distribuzioni della mia infrastruttura?
Se intendi eseguire la tua applicazione in più cluster, ambienti pubblici e privati e persino in più provider cloud, potresti chiederti come puoi fare in modo che la tua strategia di distribuzione funzioni in tutti questi ambienti.
È possibile utilizzare lo strumento open source Terraform per automatizzare il provisioning dell'infrastruttura IBM Cloud, inclusi i cluster Kubernetes. Segui questa esercitazione per creare cluster Kubernetes e OpenShift a zona singola e multizona. Dopo aver creato un cluster, puoi anche configurare il Red Hat OpenShift on IBM Cloud cluster autoscaler in modo che il tuo pool di nodi di lavoro ampli e ridimensioni i nodi di lavoro in risposta alle richieste di risorse del tuo carico di lavoro.
Che tipo di applicazioni posso eseguire? Posso spostare le applicazioni esistenti o devo sviluppare delle nuove applicazioni?
La tua applicazione inserita nel contenitore deve essere in grado di essere eseguita su uno dei sistemi operativi supportati per la versione del tuo cluster. Vuoi anche valutare la presenza di uno stato nella tua applicazione. Per ulteriori informazioni sui tipi di applicazioni che è possibile eseguire in Red Hat OpenShift on IBM Cloud, vedi Pianificazione delle distribuzioni dell'applicazione.
Se hai già un'applicazione, puoi migrarla su Red Hat OpenShift on IBM Cloud. Se desideri sviluppare una nuova app, consulta le linee guida per lo sviluppo di app cloud-native senza stato.
E le applicazioni senza server?
È possibile eseguire applicazioni e lavori serverless attraverso il servizio IBM Cloud Code EngineCode Engine può anche costruire le immagini per voi.
Quali competenze dovrei avere prima di spostare le mie app in un cluster?
Red Hat OpenShift è progettato per fornire funzionalità a due figure principali: l'amministratore del cluster e lo sviluppatore di applicazioni. Ciascuna di queste figure utilizza competenze tecniche differenti per eseguire e distribuire correttamente le applicazioni a un cluster.
- Quali sono i compiti principali e le competenze tecniche di un amministratore di cluster?
- In qualità di amministratore del cluster, sei responsabile della configurazione, del funzionamento, della protezione e della gestione dell'infrastruttura IBM Cloud del tuo cluster. Le attività tipiche includono quanto segue:
- Dimensionare il cluster per fornire sufficiente capacità per i tuoi carichi di lavoro.
- Progettare un cluster per soddisfare gli standard di alta disponibilità, ripristino di emergenza e conformità della tua azienda.
- Proteggere il cluster configurando le autorizzazioni utente e limitando le azioni all'interno del cluster per proteggere le tue risorse di calcolo, la tua rete e i dati.
- Pianificare e gestire le comunicazioni di rete tra i componenti dell'infrastruttura per garantire la sicurezza, la segmentazione e la conformità della rete.
- Pianificare le opzioni di archiviazione persistente per soddisfare i requisiti di protezione e residenza dei dati.
L'amministratore del cluster deve avere un'ampia conoscenza che includa calcolo, rete, archiviazione, sicurezza e conformità. In un'azienda tipica, questa conoscenza è distribuita tra più specialisti, come ad esempio gli ingegneri di sistema, gli amministratori del sistema, gli ingegneri di rete, gli architetti di rete, il responsabile del settore IT o gli specialisti di sicurezza e conformità. Considera di assegnare il ruolo di amministratore del cluster a più persone nella tua azienda in modo da avere la conoscenza necessaria per gestire correttamente il tuo cluster.
- Quali sono i compiti principali e le competenze tecniche di uno sviluppatore di app?
- In qualità di sviluppatore, ti occupi di progettare, creare, proteggere, distribuire, testare, eseguire e monitorare applicazioni cloud-native e containerizzate in un cluster Red Hat OpenShift. Per creare ed eseguire queste app, è necessario avere familiarità con il concetto di microservizi, le linee guida " App a 12 fattori " ( Docker e i principi della containerizzazione) e il sito Red Hat OpenShift opzioni di implementazione.
Red Hat OpenShift e Red Hat OpenShift on IBM Cloud forniscono più opzioni su come esporre un'applicazione e mantenere un'applicazione privata, aggiungere l'archiviazione persistente, integrare altri servizi e su come puoi proteggere i tuoi carichi di lavoro e proteggere i dati sensibili. Prima di trasferire l'app su un cluster in Red Hat OpenShift on IBM Cloud, verificare di poterla eseguire come app containerizzata sul sistema operativo supportato e che Red Hat OpenShift e Red Hat OpenShift on IBM Cloud offrano le funzionalità necessarie per il proprio carico di lavoro.
- Gli amministratori dei cluster e gli sviluppatori interagiscono tra loro?
- Sì. Gli amministratori e gli sviluppatori del cluster devono interagire frequentemente in modo che gli amministratori del cluster comprendano i requisiti del carico di lavoro per fornire questa capacità nel cluster e in modo che gli sviluppatori conoscano le limitazioni, le integrazioni e i principi di sicurezza disponibili che devono prendere in considerazione nel loro processo di sviluppo delle applicazioni.
Quali opzioni ho per proteggere il mio cluster?
Puoi utilizzare le funzioni di sicurezza integrate in Red Hat OpenShift on IBM Cloud per proteggere i componenti nel tuo cluster, i tuoi dati e le distribuzioni dell'applicazione per garantire la conformità della sicurezza e l'integrità dei dati. Utilizza queste funzionalità per proteggere il tuo server API Red Hat OpenShift, l'archivio dati etcd, il nodo di lavoro, la rete, lo spazio di archiviazione, le immagini e le distribuzioni da attacchi dannosi. Puoi anche avvalerti degli strumenti di registrazione e monitoraggio integrati per rilevare attacchi dolosi e modelli di utilizzo sospetti.
Per ulteriori informazioni sui componenti del tuo cluster e su come puoi soddisfare gli standard di sicurezza per ciascun componente, vedi Sicurezza per Red Hat OpenShift on IBM Cloud.
Quali politiche di accesso assegno agli utenti del mio cluster?
Red Hat OpenShift on IBM Cloud utilizza Cloud Identity and Access Management (IAM) per concedere l'accesso alle risorse del cluster tramite i ruoli di accesso alla piattaforma IAM e Kubernetes le politiche di controllo degli accessi basato sui ruoli (RBAC) tramite i ruoli di accesso al servizio IAM. Per ulteriori informazioni sui tipi di criteri di accesso, consulta la sezione " Scegli il criterio di accesso e il ruolo più adatti ai tuoi utenti ".
Quali autorizzazioni richiede l'utente che imposta la chiave API? Come posso dare all'utente queste autorizzazioni?
Come minimo, i ruoli Amministratori o Gestione della conformità dispongono delle autorizzazioni per creare un cluster. Tuttavia, potresti aver bisogno di ulteriori autorizzazioni per altri servizi e integrazioni che utilizzi nel tuo cluster. Per ulteriori informazioni, vedi Autorizzazioni per creare un cluster.
Per verificare le autorizzazioni di un utente, esamina le politiche di accesso e i gruppi di accesso dell'utente nella consoleIBM Cloudo utilizza il comando ibmcloud iam user-policies <user>.
Se la chiave API si basa su un utente, come sono interessati gli altri utenti cluster nella regione e nel gruppo di risorse?
Altri utenti nella regione e nel gruppo di risorse dell'account condividono la chiave API per accedere all'infrastruttura e ad altri servizi con i cluster Red Hat OpenShift on IBM Cloud. Quando gli utenti accedono all'account IBM Cloud, un token IBM Cloud IAM basato sulla chiave API viene generato per la sessione della CLI e consente di eseguire i comandi relativi all'infrastruttura in un cluster.
Cosa succede se l'utente che ha configurato la chiave API per una regione e un gruppo di risorse lascia l'azienda?
Se l'utente lascia la tua organizzazione, il proprietario dell'account IBM Cloud può rimuovere le autorizzazioni di quell'utente. Tuttavia, prima di rimuovere le autorizzazioni di accesso specifiche di un utente o di rimuovere completamente un utente dal tuo account, devi reimpostare la chiave API con le credenziali dell'infrastruttura di un altro utente. In caso contrario, gli altri utenti nell'account potrebbero perdere l'accesso al portale dell'infrastruttura IBM Cloud e i comandi relativi all'infrastruttura potrebbero non riuscire. Per ulteriori informazioni, vedi Rimozione delle autorizzazioni utente.
Come posso bloccare il mio cluster se la mia chiave API viene compromessa?
Se una chiave API impostata per una regione e per un gruppo di risorse nel tuo cluster viene compromessa, eliminala in modo che non possano essere effettuate ulteriori chiamate utilizzando la chiave API come autenticazione. Per ulteriori informazioni sulla protezione dell'accesso al server API Kubernetes, vedi l'argomento sulla sicurezza del Server API Kubernetes ed etcd.
Come si ruota la chiave API del cluster se c'è una perdita?
Per istruzioni su come ruotare la chiave API, vedere Come ruotare la chiave API del cluster se c'è una perdita?
Dove posso trovare un elenco dei bollettini di sicurezza che interessano il mio cluster?
Se vengono trovate vulnerabilità in Red Hat OpenShift, Red Hat OpenShift rilascia CVE nei bollettini di protezione per informare gli utenti e per descrivere le azioni che gli utenti devono intraprendere per correggere la vulnerabilità. I bollettini di sicurezza Red Hat OpenShift che riguardano gli utenti Red Hat OpenShift on IBM Cloud o la piattaforma IBM Cloud sono pubblicati nel IBM Cloud bollettino di sicurezza.
Alcune CVE richiedono l'aggiornamento patch più recente per una versione che puoi installare come parte del regolare processo di aggiornamento del cluster in Red Hat OpenShift on IBM Cloud. Assicurati di applicare le patch di sicurezza in tempo per proteggere il tuo cluster da attacchi dolosi. Per ulteriori informazioni sui contenuti di una patch di sicurezza, consultare il log delle modifiche della versione.
Il servizio offre supporto per bare metal e GPU?
Alcune caratteristiche del nodo di lavoro VPC offrono il supporto GPU. Per ulteriori informazioni, consultare le configurazioni VPC.
Sì, puoi eseguire il provisioning del tuo nodo di lavoro come server bare metal fisico a singolo tenant. I server bare metal offrono vantaggi ad alte prestazioni per carichi di lavoro come dati, GPU e AI. Inoltre, tutte le risorse hardware sono dedicate ai tuoi carichi di lavoro, quindi non devi preoccuparti degli "elementi di disturbo".
Per ulteriori informazioni sulle opzioni disponibili per le istanze bare metal e sulle differenze tra queste ultime e le macchine virtuali, consultare la guida alla pianificazione.
Qual è la dimensione minima del cluster che posso creare?
Si noti che l'esecuzione di un cluster minimo non soddisfa il service level agreement (SLA) per ricevere assistenza. Inoltre, tieni presente che alcuni servizi, come Ingress, richiedono configurazioni del nodo di lavoro altamente disponibili. Potresti non essere in grado di eseguire questi servizi o le tue applicazioni nei cluster con solo due nodi in un pool di nodi di lavoro. Per ulteriori informazioni, vedi Pianificazione del tuo cluster per l'alta disponibilità.
- Cluster Classic o VPC
- I cluster devono avere sempre almeno 2 nodi di lavoro. Si noti che non è possibile avere un cluster con 0 nodi di lavoro, né è possibile disattivare o sospendere la fatturazione per i nodi di lavoro.
- Cluster Satellite
- I cluster possono essere creati utilizzando la topologia a replica singola, che significa solo un nodo di lavoro. Nota che se crei un cluster Satellite utilizzando la topologia a replica singola, non puoi aggiungere i nodi di lavoro in un secondo momento.
Quali versioni sono supportate dal servizio?
Red Hat OpenShift on IBM Cloud supporta simultaneamente più versioni di Red Hat OpenShift. Quando viene rilasciata una nuova versione (n), sono supportate le versioni precedenti fino a due versioni indietro ( n-2 ). Le versioni che sono più di 2 precedenti rispetto all'ultima (n-3) sono prima dichiarate obsolete e quindi non più supportate.
Per ulteriori informazioni sulle versioni supportate e sulle operazioni di aggiornamento necessarie per passare da una versione all'altra, consultare le informazioni sulla versione di Red Hat OpenShift on IBM Cloud.
Quali sistemi operativi del nodo di lavoro supporta il servizio?
Per un elenco dei sistemi operativi del nodo di lavoro supportati per versione cluster, vedi le informazioni sulla versione diRed Hat OpenShift on IBM Cloud.
Dove è disponibile il servizio?
Red Hat OpenShift on IBM Cloud è disponibile in tutto il mondo. È possibile creare cluster in tutte le regioni supportate da Red Hat OpenShift on IBM Cloud.
Per ulteriori informazioni sulle regioni supportate, vedi Ubicazioni.
Il servizio è altamente disponibile?
Sì. Per impostazione predefinita, Red Hat OpenShift on IBM Cloud configura molti componenti, come il master cluster, con repliche, anti-affinità e altre opzioni per aumentare l'alta disponibilità (HA) del servizio. Puoi aumentare la ridondanza e la tolleranza agli errori dei tuoi nodi di lavoro, dell'archiviazione, della rete e dei carichi di lavoro del cluster configurandoli in un'architettura altamente disponibile. Per una panoramica della configurazione predefinita e delle opzioni disponibili per aumentare l'HA, vedere Creazione di una strategia di cluster ad alta disponibilità.
Per i termini dell'accordo del livello di servizio di alta disponibilità più recenti, fai riferimento a Termini di servizio di IBM Cloud. Generalmente, i termini di disponibilità dell'SLA richiedono che, quando configuri le tue risorse dell'infrastruttura in un'architettura di alta disponibilità, devi distribuirle uniformemente in tre diverse zone di disponibilità. Ad esempio, per beneficiare della copertura HA completa prevista dai termini dello SLA, è necessario configurare un cluster multizona con un totale di almeno 6 nodi di lavoro, due nodi di lavoro per zona, distribuiti in modo uniforme su tre zone.
Come funzionano i cluster multizona?
Come è configurato il mio set master " Red Hat OpenShift on IBM Cloud "?
Quando si crea un cluster in una sede multizona, viene automaticamente distribuito un master ad alta disponibilità e tre repliche vengono distribuite tra le zone dell'area metropolitana. Ad esempio, se il cluster si trova nelle zone dal10,
dal12 o dal13, le repliche del master vengono distribuite su ogni zona nella città metropolitana multizona di Dallas.
Devo fare qualcosa affinché il master possa comunicare con i worker di altre zone?
Se hai creato un cluster multizona VPC, le sottoreti in ogni zona vengono configurate automaticamente con gli ACL (Access Control List) che consentono le comunicazioni tra il master e i nodi di lavoro tra le zone. Nei cluster classici, se
hai più VLAN per il tuo cluster, più sottoreti sulla stessa VLAN o un cluster classico multizona, devi abilitare una VRF (Virtual Router Function) per il tuo
account dell'infrastruttura IBM Cloud in modo che i tuoi nodi di lavoro possano comunicare tra loro sulla rete privata. Per abilitare il VRF, vedere Abilitazione del VRF.
Per controllare se una VRF è già abilitata, utilizza il comando ibmcloud account show. Se non si può o non si vuole abilitare il VRF, abilitare VLAN spanning.
Per eseguire questa operazione, è necessario disporre dell'autorizzazione " Rete > Gestione delle VLAN di rete " oppure è possibile richiedere al proprietario dell'account di abilitarla. Per verificare se lo
spanning VLAN è già abilitato, utilizzare il comando ibmcloud oc vlan spanning get --region
.
Posso convertire il mio cluster a zona singola in un cluster multizona?
Per convertire un cluster a zona singola in un cluster multizona, il cluster deve essere impostato in una posizione che abbia più di una zona di disponibilità.
- I cluster VPC possono essere configurati solo in regioni multizona e, pertanto, è sempre possibile convertirli da cluster a zona singola a cluster multizona. Per ulteriori informazioni, vedere Aggiungimenti di nodi worker ai cluster VPC.
- I cluster classici, installati in data center con una sola zona, non possono essere convertiti in cluster multizona. Per ulteriori informazioni, vedere Aggiungimento di nodi worker ai cluster Classic.
E se volessi configurare più cluster in diverse regioni?
Puoi impostare più cluster in regioni diverse di una geolocalizzazione (ad esempio, Stati Uniti Sud e Stati Uniti Est) o tra geolocalizzazioni (ad esempio, Stati Uniti Sud ed Europa Centrale). Entrambe le configurazioni offrono lo stesso livello di disponibilità per la tua applicazione, ma aggiungono anche complessità quando si tratta di condivisione e di replica dei dati. Per la maggior parte dei casi, trovarsi all'interno della stessa geolocalizzazione si rivela sufficiente. Ma se hai utenti in tutto il mondo, potrebbe essere meglio configurare un cluster nella zona in cui si trovano i tuoi utenti, in modo che questi ultimi non debbano affrontare lunghi tempi di attesa quando inviano una richiesta alla tua app.
Quali opzioni ho a disposizione per distribuire il carico di lavoro tra più cluster?
Per bilanciare i carichi di lavoro tra più cluster, devi rendere disponibili le tue applicazioni sulla rete pubblica utilizzando Ingress, i router o gli NLB (Network Load Balancer). Ai servizi router e agli NLB viene assegnato un indirizzo IP pubblico che puoi utilizzare per accedere alle tue applicazioni.
Per bilanciare i carichi di lavoro tra le tue applicazioni, aggiungi gli indirizzi IP pubblici dei tuoi servizi router e NLB a un programma di bilanciamento del carico globale CIS o al tuo programma di bilanciamento del carico globale.
E se volessi distribuire il carico di lavoro sulla rete privata?
IBM Cloud non offre un servizio di bilanciamento del carico globale sulla rete privata. Tuttavia, puoi connettere il tuo cluster a un programma di bilanciamento del carico privato ospitato sulla tua rete in loco utilizzando una delle opzioni VPN supportate. Assicurati di esporre le tue applicazioni sulla rete privata utilizzando Ingress, i router o gli NLB (Network Load Balancer) e utilizza l'indirizzo IP privato nelle tue impostazioni VPN per connettere la tua applicazione alla rete in loco.
Il master e i nodi di lavoro sono altamente disponibili?
L'architettura e l'infrastruttura di Red Hat OpenShift on IBM Cloud sono progettate per garantire affidabilità, bassa latenza di elaborazione e una massima operatività del servizio. Per impostazione predefinita, ogni cluster in Red Hat OpenShift on IBM Cloud è configurato con più istanze master di Red Hat OpenShift per garantire la disponibilità e l'accessibilità delle risorse del cluster, anche nel caso in cui una o più istanze del master di Red Hat OpenShift risultino non disponibili.
Puoi rendere il tuo cluster ancora più altamente disponibile e proteggere la tua applicazione da tempi di inattività, estendendo i tuoi carichi di lavoro tra più nodi di lavoro in più zone di una regione. Questa configurazione è denominata "cluster multizona" e garantisce che la tua app sia accessibile anche nel caso in cui un nodo di lavoro o un'intera zona non siano disponibili.
Per proteggersi da un’interruzione a livello di intera regione, creare più cluster e distribuirli in diverse regioni di IBM Cloud. Configurando un NLB (network load balancer) per i tuoi cluster, puoi ottenere il bilanciamento del carico tra regioni e la rete inter-regionale per i cluster.
Se hai dei dati che devono essere disponibili, anche se si verifica un'interruzione, assicurati di memorizzare i tuoi dati nell'archiviazione persistente.
Per ulteriori informazioni su come ottenere l'alta disponibilità per il tuo cluster, vedi Alta disponibilità per Red Hat OpenShift on IBM Cloud.
Le mie app si diffondono automaticamente in tutte le zone?
Dipende da come si imposta l'app. Vedere Pianificazione di distribuzioni altamente disponibili e Pianificazione di storage persistente altamente disponibile.
I nodi di lavoro sono crittografati?
Il disco secondario del nodo di lavoro è crittografato. Per ulteriori informazioni, vedi Panoramica della crittografia del cluster. Dopo aver creato un pool di nodi di lavoro, potresti
notare che il profilo del nodo di lavoro presenta .encrypted nel nome, ad esempio b3c.4x16.encrypted.
Quali standard di conformità soddisfa il servizio?
IBM Cloud è sviluppato rispettando molti standard di conformità relativi a dati, settori finanziario, sanitario e assicurativo, privacy, sicurezza, tecnologia e internazionali di altro tipo. Per ulteriori informazioni, vedi Conformità di IBM Cloud.
Per visualizzare i requisiti di sistema dettagliati, è possibile generare un rapporto di compatibilità del prodotto software per Red Hat OpenShift on IBM Cloud. Nota che la conformità dipende dal provider dell'infrastruttura sottostante per i nodi di lavoro, la rete e le risorse di archiviazione del cluster.
Infrastruttura classica: Red Hat OpenShift on IBM Cloud implementa misure di controllo conformi ai seguenti standard di sicurezza:
- Framework Scudo UE-USA per la privacy (EU-US Privacy Shield) e Scudo per la privacy Svizzera-USA (Swiss-US Privacy Shield)
- HIPAA (Health Insurance Portability and Accountability Act)
- Standard Service Organization Control (SOC 1 Type 2, SOC 2 Type 2)
- International Standard on Assurance Engagements 3402 (ISAE 3402), Assurance Reports on Controls at a Service Organization
- International Organization for Standardization (ISO 27001, ISO 27017, ISO 27018)
- Payment Card Industry Data Security Standard (PCI DSS)
Infrastruttura VPC: Red Hat OpenShift on IBM Cloud implementa misure di controllo conformi ai seguenti standard di sicurezza:
- Framework Scudo UE-USA per la privacy (EU-US Privacy Shield) e Scudo per la privacy Svizzera-USA (Swiss-US Privacy Shield)
- HIPAA (Health Insurance Portability and Accountability Act)
- International Standard on Assurance Engagements 3402 (ISAE 3402), Assurance Reports on Controls at a Service Organization
Satellite: vedi la documentazione diIBM Cloud Satellite.
Posso utilizzare altri servizi IBM Cloud con il mio cluster?
Puoi aggiungere i servizi di infrastruttura e piattaforma IBM Cloud e i servizi di fornitori di terze parti al tuo cluster Red Hat OpenShift on IBM Cloud per abilitare l'automazione, aumentare la sicurezza o migliorare le capacità di monitoraggio e registrazione nel cluster.
Per un elenco di servizi supportati, vedi Integrazione dei servizi.
Come posso installare un Cloud Pak nel mio cluster?
I Cloud Pak sono integrati con il catalogo IBM Cloud, in modo da consentire di configurare e installare rapidamente tutti i componenti Cloud Pak in un cluster Red Hat OpenShift esistente o nuovo. Quando si installa l' Cloud Pak, l' Cloud Pak viene configurato con Schematics e viene creato automaticamente un'area di lavoro Schematics. Puoi utilizzare lo spazio di lavoro successivamente per accedere alle informazioni sulla tua installazione del Cloud Pak. Accedi ai tuoi servizi del Cloud Pak dall'URL del Cloud Pak. Per ulteriori informazioni, consultare il 'documentazione Cloud Pak.
Posso utilizzare la licenza “ Red Hat OpenShift ” inclusa nel mio “ Cloud Pak ” per il mio cluster?
Sì, se il tuo Cloud Pak include una titolarità per eseguire determinati profili del nodo di lavoro installati con OpenShift Container Platform. Per visualizzare i tuoi diritti, accedi IBM Passport Advantage. Nota che il tuo ID IBM Cloud deve corrispondere al tuo ID di IBM Passport Advantage.
È possibile creare il cluster o il pool di worker all’interno di un cluster esistente tramite l’autorizzazione “ Cloud Pak ” nella console oppure utilizzando l’opzione “ --entitlement ocp_entitled ” nel ibmcloud oc cluster create classic o ibmcloud oc worker-pool create classic comandi CLI. Assicurati di specificare il numero e il profilo corretti dei nodi di lavoro
che sei autorizzato a utilizzare.
Non superare la tua titolarità. Tieni presente che le tue titolarità OpenShift Container Platform possono essere utilizzate con altri provider cloud o in altri ambienti. Per evitare problemi di fatturazione in un secondo momento, assicurati di utilizzare solo ciò per cui disponi di titolarità. Ad esempio, potresti avere una titolarità per le licenze OCP per due nodi di lavoro di 4 CPU e 16 GB di memoria e crei questo pool di nodi di lavoro con due nodi di lavoro di 4 CPU e 16 GB di memoria. Hai esaurito il tuo diritto e non puoi utilizzare lo stesso diritto per altri gruppi di lavoratori, fornitori di servizi cloud o ambienti.
Posso installare più Cloud Pak nello stesso cluster Red Hat OpenShift on IBM Cloud ?
Sì, ma potresti dover aggiungere più nodi di lavoro in modo che ogni Cloud Pak abbia risorse di calcolo sufficienti per l'esecuzione. Inoltre, potresti installare solo un'istanza dello stesso Cloud Pak per cluster, come ad esempio Cloud Pak for Data; o più istanze per diversi progetti nello stesso cluster, come ad esempio Cloud Pak for Automation. Per informazioni sul dimensionamento, consulta la documentazione diCloud Pak.
Cosa è incluso in un Cloud Pak?
I Cloud Pak sono composti da software in bundle, con licenza e inserito nel contenitore ottimizzato per lavorare insieme per i casi di utilizzo aziendali, inclusi una distribuzione, un controllo dell'accesso e una fatturazione congruenti. È possibile utilizzare in modo flessibile parti dei Cloud Pak quando necessario, scegliendo la combinazione più adatta di core di processore virtuali del software in base ai propri carichi di lavoro. Puoi anche modificare il mix di core di processori virtuali quando i tuoi carichi di lavoro si evolvono.
A seconda del Cloud Pak, ottieni del software open source e con licenza IBM riunito insieme in un'esperienza di gestione unificata con funzionalità di registrazione, monitoraggio, sicurezza e accesso.
- IBM Prodotti: i Cloud Paks ampliano le funzionalità del software e del middleware IBM con licenza disponibili su IBM Marketplace e integrano tali prodotti con il proprio cluster per modernizzare, ottimizzare ed eseguire carichi di lavoro nel cloud ibrido.
- Software open source: i Cloud Pak potrebbero anche includere dei componenti open source per soluzioni cloud ibride portatili e native cloud. Di solito, il software open source non è gestito ed è tua responsabilità mantenere i tuoi componenti aggiornati e sicuri. Tuttavia, i Cloud Pak ti aiutano a gestire in modo congruente l'intero ciclo di vita dei componenti Cloud Pack e i carichi di lavoro che esegui con essi. Poiché il software open source è integrato nell' Cloud Pak, potrai usufruire dei vantaggi offerti dal supporto di IBM e dall'integrazione con alcune funzionalità di IBM Cloud, quali il controllo degli accessi e la fatturazione.
Per conoscere i componenti di ciascun Cloud Pak, consultare la documentazione all'indirizzo Cloud Pak.
Cosa altro devo sapere per utilizzare i Cloud Pak?
Quando si configura l' Cloud Pak, potrebbe essere necessario utilizzare risorse specifiche dell' Red Hat OpenShift, come i vincoli relativi al contesto di sicurezza. Assicurati di utilizzare la CLI oc o la CLI kubectl versione 1.12 per interagire con tali risorse, ad esempio oc get scc. La versione CLI di kubectl, disponibile all'indirizzo 1.11, presenta un bug che genera un errore quando si eseguono comandi relativi a risorse specifiche di
Red Hat OpenShift, come ad esempio kubectl get scc.
IBM supporta gli strumenti di terze parti e open source che utilizzo con il mio cluster?
Si veda la politica di IBM in materia di software open source e prodotti di terze parti.
Che cosa mi viene addebitato? Posso stimare e controllare i costi nel mio cluster?
Posso eseguire il downgrade del cluster a una versione precedente?
No, non è possibile eseguire il downgrade del cluster a una versione precedente.
Posso spostare il mio cluster corrente in un account differente?
No, non puoi spostare il raggruppamento in un account diverso da quello in cui è stato creato.
Come posso far sì che il mio cluster sia sempre supportato?
- Assicurati che il tuo cluster esegua sempre una versione supportata Red Hat OpenShift.
- Quando viene rilasciata una nuova versione minore di Red Hat OpenShift, la versione precedente viene presto dichiarata obsoleta e quindi non più supportata.
Per ulteriori informazioni, vedi Aggiornamento del master e nodi di lavoro.
Quali operazioni sono bloccate se il cluster sta eseguendo un sistema operativo non supportato?
Le seguenti operazioni vengono bloccate quando un sistema operativo non è supportato:
- ricaricamento operatore
- sostituzione operatore senza aggiornare
- sostituzione operatore con aggiornamento
- aggiornamento operatore
- creazione pool di lavoro (con un OS non supportato)
- ribilanciamento del pool di lavoro
- ridimensionamento del pool di lavoro (ridimensionamento incrementale)
- aggiunta zona pool di lavoro
- ridimensionamento gruppo di istanze (patch)
- autoscaler rimuovere il lavoratore ( v2/autoscalerRemoveWorker )
Quanto costano i contenitori riservati?
IBM non applica costi aggiuntivi per i contenitori riservati. Il costo rimane invariato per il servizio e le tariffe standard VSI per ogni pod riservato che inizia come VSI alle tariffe standard IBM Cloud.
Posso costruire il mio CVM (podvm) per i contenitori riservati?
Sì. Il sito ConfigMap può essere configurato per puntare a una macchina virtuale confidenziale (CVM) configurata dall'utente. IBM non fornisce il supporto per costruirne uno proprio. La creazione di un'immagine da parte dell'utente può comportare problemi che l'assistenza di IBM non può risolvere.
Cosa devo usare come fiduciario nei contenitori riservati?
Per lo sviluppo, è sufficiente eseguire un semplice amministratore in Docker / Podman su VM. Questi contenitori possono anche essere configurati direttamente in OpenShift. Poiché il fiduciario è il garante della sicurezza dell'ambiente, non utilizzare un fiduciario all'interno del cluster OpenShift, che non dovrebbe essere attendibile.
Per la produzione, utilizzare l'Autorità fiduciaria Intel e configurare INITDATA per utilizzare l'Autorità fiduciaria Intel. È necessario consentire al cluster di comunicare con Intel, ad esempio con i gruppi di sicurezza, con le autorizzazioni predefinite di OpenShift e così via.
Dove posso trovare assistenza per i contenitori riservati?
OpenShift L'operatore Sandboxed Containers su Red Hat OpenShift on IBM Cloud è supportato sia da Red Hat che da IBM. Utilizzare i canali di assistenza standard per entrambi i servizi. Se il vostro OpenShift è concesso in licenza attraverso IBM Cloud, contattate IBM. Se si portano le proprie licenze OpenShift da Red Hat, si può contattare Red Hat.
Quanti peer pod posso eseguire per ogni nodo worker?
Il numero di pod peer che è possibile eseguire per ogni nodo worker è controllato da diversi limiti:
-
PEERPODS_LIMIT_PER_NODEimpostazione: Questo limite configurabile inpeer-pods-cmConfigMap controlla il numero massimo di pod VSI peer che possono essere pianificati per nodo worker. Il valore predefinito è10. È possibile aumentare questo valore, ma è necessario considerare anche gli altri vincoli indicati di seguito. -
Kubernetes limite pod: Kubernetes limita il numero totale di pod per nodo in base al numero di vCPUs (10 pod per vCPU ). Ad esempio, un nodo worker 16x64 può supportare fino a 110 pod. Poiché ogni pod peer è supportato da un costrutto pod Kubernetes sul nodo worker, questo limite si applica anche se il carico di lavoro effettivo viene eseguito in un VSI separato.
-
CPU e memoria del nodo worker: Ogni pod peer consuma circa 250m CPU e 120Mi memoria sul nodo worker per il costrutto del pod Kubernetes. È necessario assicurarsi che i nodi worker dispongano di CPU e memoria sufficienti per supportare il numero desiderato di pod peer.
Per aumentare il valore di PEERPODS_LIMIT_PER_NODE:
-
Aggiornare il file
peer-pods-cmConfigMap nello spazio dei nomiopenshift-sandboxed-containers-operator. Per ulteriori informazioni, vedere Creazione di contenitori riservati.oc -n openshift-sandboxed-containers-operator patch cm peer-pods-cm \ --type merge \ -p '{"data":{"PEERPODS_LIMIT_PER_NODE":"24"}}' -
Riavviare il daemonset di Cloud API Adapter.
oc -n openshift-sandboxed-containers-operator rollout restart daemonset/osc-caa-ds -
Verificare l'applicazione del nuovo limite.
oc get nodes -o json | jq -r '[.items[] | select (.status.allocatable["kata.peerpods.io/vm"] != null)| .status.allocatable["kata.peerpods.io/vm"] | tonumber] | add'
Quando si calcola il valore ottimale di PEERPODS_LIMIT_PER_NODE, si deve considerare il profilo del nodo lavoratore. Ad esempio, con un nodo worker 16x64 (16 vCPUs ), il massimo teorico basato sulla sola CPU sarebbe di circa 24
peer pod per nodo (assumendo 250m CPU per peer pod e tenendo conto degli altri processi di sistema). Tuttavia, si è anche vincolati dal limite di pod Kubernetes di 110 pod per nodo.
Cosa significa l'errore Insufficiente kata.peerpods.io/vm?
Se viene visualizzato un errore come il seguente durante la pianificazione dei pod peer:
Warning FailedScheduling 0/30 nodes are available: 9 Insufficient kata.peerpods.io/vm. preemption: 0/30 nodes are available: 9 No preemption victims found for incoming pod.
Questo errore indica che è stato raggiunto il limite di PEERPODS_LIMIT_PER_NODE sui nodi worker. La risorsa kata.peerpods.io/vm rappresenta il numero di slot per pod peer disponibili su ogni nodo worker.
Per risolvere questo problema:
-
Controllare il limite di corrente e l'allocazione.
oc get nodes -o json | jq '.items[] | {name: .metadata.name, allocatable: .status.allocatable["kata.peerpods.io/vm"], capacity: .status.capacity["kata.peerpods.io/vm"]}' -
Controlla il numero di pod peer attualmente in esecuzione.
oc get pods -A -o json | jq '.items[] | select(.spec.runtimeClassName == "kata-remote") | "\(.metadata.namespace)/\(.metadata.name)"' | wc -l -
Aumentare il valore di
PEERPODS_LIMIT_PER_NODEcome descritto in Quanti peer pod posso eseguire per nodo worker? -
In alternativa, aggiungere altri nodi worker al cluster per aumentare la capacità totale.
I contenitori riservati possono soddisfare standard di sicurezza specifici, come il NIST 800-53 R5?
Perché ricevo un errore di autenticazione IAM dopo l'aggiornamento all'operatore " OpenShift " per i container in modalità sandbox 1.12.1?
Dopo l'aggiornamento all'operatore Sandboxed Containers di OpenShift alla versione 1.12.1, è possibile che nei log del Cloud API Adapter (CAA) compaia un errore simile al seguente:
cloud-api-adaptor: cluster error with:
Unauthorized
further details:
{
"StatusCode": 401,
"Result": {
"code": "A0007",
"description": "You do not have the correct permissions to perform this action..."
}
}
Questo errore si verifica perché la versione 1.12.1 ha introdotto un nuovo requisito che prevede il recupero automatico del gruppo di sicurezza del cluster tramite l'API del servizio cluster IKS all'indirizzo IBM Cloud. Quando si utilizza "
IBMCLOUD_IAM_PROFILE_ID " per l'autenticazione (identità della risorsa di calcolo), il profilo IAM potrebbe non disporre delle autorizzazioni necessarie per interrogare l'API del servizio del cluster.
Per risolvere questo problema, scegliere una delle seguenti opzioni:
-
Concedere autorizzazioni IAM aggiuntive (consigliato): aggiornare il profilo IAM per includere le autorizzazioni relative all'API del servizio cluster IKS, in particolare la possibilità di richiamare
GetClusterTypeSecurityGroups(). Contatta l'amministratore di IBM Cloud per aggiungere le autorizzazioni necessarie. -
Impostare esplicitamente l'ID del gruppo di sicurezza : configurare la variabile d'ambiente
IBMCLOUD_VPC_SG_IDnel filepeer-pods-cm( ConfigMap ) per bypassare la ricerca automatica del gruppo di sicurezza del cluster:oc -n openshift-sandboxed-containers-operator patch cm peer-pods-cm \ --type merge \ -p '{"data":{"IBMCLOUD_VPC_SG_ID":"<your-security-group-id>"}}'Quindi riavviare il daemonset dell'adattatore API Cloud:
oc -n openshift-sandboxed-containers-operator rollout restart daemonset/osc-caa-ds -
Utilizza l'autenticazione tramite chiave API: passa dall'autenticazione
IBMCLOUD_IAM_PROFILE_IDa quellaIBMCLOUD_API_KEY, che in genere offre autorizzazioni più ampie. Aggiorna il segreto "peer-pods-secret" con la tua chiave API, invece di utilizzare il profilo IAM.
Per ulteriori informazioni sulle modifiche apportate nella versione 1.12.1, consultare il commit del progetto upstream cloud-api-adaptor all'indirizzo dde66055.
Contattate il vostro team IBM per discutere di interessi di sicurezza specifici.
Qual è il fuso orario predefinito per i nodi worker della VPC?
A partire dalla versione della patch 4.16.56_1602, rilasciata il 27 gennaio 2026, tutte le patch future per i cluster VPC impostano l'ora locale
dei nodi worker su UTC.