Domande frequenti su Azure Red Hat OpenShift

Questo articolo risponde alle domande frequenti su Microsoft Azure Red Hat OpenShift.

Installazione e aggiornamento

Dove è possibile trovare informazioni sui prezzi e sui contratti di servizio?

Per informazioni sui prezzi, vedere Prezzi di Azure Red Hat OpenShift.

Per informazioni sul contratto di servizio, vedere Contratti di servizio per Servizi online.

Quali aree di Azure sono supportate?

Per un elenco delle aree supportate per Azure Red Hat OpenShift 4.x, vedere Aree disponibili.

Quali dimensioni di macchina virtuale è possibile usare?

Per un elenco delle dimensioni di macchina virtuale supportate per Azure Red Hat OpenShift 4, vedere Risorse supportate per Azure Red Hat OpenShift 4.

Qual è il numero massimo di pod in un cluster Azure Red Hat OpenShift? Qual è il numero massimo di pod per nodo in Azure Red Hat OpenShift?

Il numero effettivo di pod supportati dipende dai requisiti di memoria, CPU e archiviazione di un'applicazione.

Azure Red Hat OpenShift 4.x ha un limite di 250 pod per nodo e un limite di 60 nodi di calcolo. Questi limiti limitano il numero massimo di pod supportati in un cluster a 250×60 = 15.000. Per un cluster privato senza indirizzi IP pubblici (ad esempio, creato usando la route definita dall'utente e la versione 4.11 o successiva), i limiti sono 120 nodi di calcolo e 30.000 pod.

Un cluster può avere nodi di calcolo in più aree di Azure?

No. Tutti i nodi in un cluster Azure Red Hat OpenShift devono avere origine nella stessa area di Azure.

Un cluster può essere distribuito in più zone di disponibilità?

Sì. Un cluster può essere distribuito automaticamente in più zone di disponibilità se il cluster viene distribuito in un'area di Azure che supporta le zone di disponibilità. Per altre informazioni, vedere Zone di disponibilità.

I nodi del piano di controllo vengono astratti così come sono con il servizio Azure Kubernetes?

No. Tutte le risorse, inclusi i nodi del piano di controllo del cluster, vengono eseguite nella sottoscrizione del cliente. Questi tipi di risorse vengono inseriti in un gruppo di risorse di sola lettura.

Il cluster si trova nella sottoscrizione di un cliente?

L'applicazione gestita di Azure si trova in un gruppo di risorse bloccato con la sottoscrizione del cliente. I clienti possono visualizzare gli oggetti in tale gruppo di risorse, ma non modificarli.

In Azure Red Hat OpenShift esistono elementi condivisi con altri clienti? O sono tutti indipendenti?

Ogni cluster Azure Red Hat OpenShift è dedicato a un determinato cliente e si trova all'interno della sottoscrizione del cliente.

I nodi dell'infrastruttura sono disponibili?

Sì, ARO consente di usare i set di computer dell'infrastruttura per creare computer che ospitano solo componenti dell'infrastruttura, ad esempio il router predefinito, il registro contenitori integrato e i componenti per le metriche e il monitoraggio del cluster. Per altre informazioni, vedere Distribuire i nodi dell'infrastruttura in un cluster ARO.

Come si gestiscono gli aggiornamenti dei cluster?

Per informazioni su aggiornamenti, manutenzione e versioni supportate, vedere la guida al ciclo di vita del supporto.

Come verranno aggiornati il sistema operativo host e il software OpenShift?

I sistemi operativi host e il software OpenShift vengono aggiornati man mano che Azure Red Hat OpenShift utilizza le versioni secondarie e le patch di OpenShift Container Platform upstream.

Qual è il processo per riavviare il nodo aggiornato?

I nodi vengono riavviati durante un aggiornamento.

Operazioni del cluster

È possibile usare Prometheus per monitorare le applicazioni?

Prometheus è preinstallato e configurato per i cluster Azure Red Hat OpenShift 4.x. Per altre informazioni, vedere la pagina relativa al monitoraggio dei cluster.

È possibile usare Prometheus per monitorare le metriche correlate all'integrità e alla capacità dei cluster?

In Azure Red Hat OpenShift 4.x: sì.

I log delle macchine virtuali sottostanti possono essere trasmessi al sistema di analisi dei log di un cliente?

I log delle macchine virtuali sottostanti vengono amministrati dal servizio gestito e non vengono esposti ai clienti.

In che modo un cliente può accedere a metriche come CPU/memoria a livello di nodo per intervenire in modo da dimensionare, eseguire il debug dei problemi e così via? Non è possibile eseguire kubectl top in un cluster Azure Red Hat OpenShift.

Per i cluster Azure Red Hat OpenShift 4.x, la console Web OpenShift contiene tutte le metriche a livello di nodo. Per altre informazioni, vedere la documentazione di Red Hat relativa alla visualizzazione delle informazioni sui cluster.

Se si aumenta la distribuzione, in che modo i domini di errore di Azure eseguono il mapping nel posizionamento dei pod per assicurarsi che tutti i pod per un servizio non vengano eliminato da un errore in un singolo dominio di errore?

Esistono per impostazione predefinita cinque domini di errore quando si usa set di scalabilità di macchine virtuali in Azure. Ogni istanza di macchina virtuale in un set di scalabilità verrà inserita in uno di questi domini di errore. In questo modo, si garantisce che le applicazioni distribuite nei nodi di calcolo in un cluster vengano inserite in domini di errore separati.

Per altre informazioni, vedere Scelta del numero corretto di domini di errore per il set di scalabilità di macchine virtuali.

Esiste un modo per gestire la selezione host per pod?

I clienti hanno la possibilità di ottenere i nodi e visualizzare le etichette come customer-admin. In questo modo, sarà possibile impostare come destinazione qualsiasi macchina virtuale del set di scalabilità.

È necessario prestare attenzione quando si usano etichette specifiche:

  • Non deve essere usato il nome host. Il nome host viene spesso ruotato con gli aggiornamenti e cambierà sicuramente.
  • Se il cliente ha una richiesta di etichette specifiche o una strategia di distribuzione, è possibile eseguire questa operazione. Tuttavia, richiederebbe sforzi di progettazione e non è attualmente supportato.

Per altre informazioni, vedere Controlling pod placement (Controllo della selezione host per pod).

Il registro immagini è disponibile esternamente ed è quindi possibile usare strumenti come Jenkins?

Per i cluster 4.x, è necessario esporre un registro sicuro e configurare l'autenticazione. Per altre informazioni, vedere la documentazione seguente di Red Hat:

È possibile spostare o eseguire la migrazione del cluster tra tenant di Azure?

Lo spostamento del cluster ARO tra tenant non è attualmente supportato.

È possibile spostare i cluster ARO dalla sottoscrizione di Azure corrente a un altro?

Lo spostamento del cluster ARO e delle risorse associate tra sottoscrizioni non è supportato.

È possibile spostare i cluster ARO o le risorse dell'infrastruttura ARO in altri gruppi di risorse o rinominarli?

Lo spostamento o la ridenominazione del cluster ARO e delle risorse associate non sono supportati.

Rete

È possibile distribuire un cluster in una rete virtuale esistente?

I cluster 4.x possono essere distribuiti in una rete virtuale esistente.

La rete tra spazi dei nomi è supportata?

I clienti e gli amministratori dei singoli progetti possono personalizzare la rete tra spazi dei nomi (e anche rifiutarla) per ogni progetto usando oggetti NetworkPolicy.

Si sta provando a eseguire il peering in una rete virtuale in una sottoscrizione diversa ma non è stato possibile ottenere l'errore CIDR della rete virtuale.

Nella sottoscrizione che include la rete virtuale assicurarsi di registrare il provider Microsoft.ContainerService con il comando seguente: az provider register -n Microsoft.ContainerService --wait

È possibile specificare intervalli IP per la distribuzione nella rete virtuale privata, evitando conflitti con altre reti virtuali aziendali dopo il peering?

Nei cluster 4.x è possibile specificare i propri intervalli IP.

Il modulo Software Defined Network è configurabile?

La rete definita dal software è openshift-ovs-networkpolicy e non è configurabile.

Quale istanza di Azure Load Balancer viene usata da Azure Red Hat OpenShift? La Standard o la Basic ed è configurabile?

Azure Red Hat OpenShift usa Azure Load Balancer Standard e non è configurabile.

Autorizzazioni

Un amministratore può gestire gli utenti e le quote?

Sì. Un amministratore di Azure Red Hat OpenShift può gestire gli utenti e le quote oltre ad accedere a tutti i progetti creati dagli utenti.

È possibile limitare un cluster solo a determinati utenti di Microsoft Entra?

Sì. È possibile limitare gli utenti di Microsoft Entra che possono accedere a un cluster configurando l'applicazione Microsoft Entra. Per informazioni dettagliate, vedere Procedura: Limitare l'app a un set di utenti.

È possibile impedire agli utenti di creare progetti?

Sì. Accedere al cluster come amministratore ed eseguire questo comando:

oc adm policy \
    remove-cluster-role-from-group self-provisioner \
    system:authenticated:oauth

Per altre informazioni, vedere la documentazione di OpenShift sulla disabilitazione del provisioning automatico per la versione del cluster:

Quali diritti di UNIX (in IaaS) sono disponibili per i nodi Masters/Infra/App?

L'accesso ai nodi è disponibile tramite il ruolo di amministratore del cluster. Per altre informazioni, vedere Kubernetes RBAC overview (Panoramica del controllo degli accessi in base al ruolo di Kubernetes).

Quali diritti OCP sono disponibili? Cluster-admin? Project-admin?

Il ruolo di amministratore del cluster è disponibile. Per altre informazioni, vedere Kubernetes RBAC overview (Panoramica del controllo degli accessi in base al ruolo di Kubernetes).

Quali sono i provider di identità disponibili?

Si configura il proprio provider di identità. Per altre informazioni, vedere la documentazione di Red Hat sulla configurazione dei provider di identità.

Storage

I dati nel cluster vengono crittografati?

Per impostazione predefinita, vengono crittografati i dati inattivi. La piattaforma Archiviazione di Azure crittografa automaticamente i dati prima del salvataggio permanente e li decrittografa prima del recupero. Per altre informazioni, vedere Crittografia del servizio di archiviazione di Azure per i dati inattivi.

Come vengono protetti gli account di archiviazione?

Archiviazione account sono impostati solo su accesso privato.

Archiviazione account vengono crittografati (solo nuovi cluster). I cluster esistenti devono essere ricreati.

Archiviazione vengono creati account con utilizzo generico v2 per i nuovi cluster.

Gli account di archiviazione per utilizzo generico v2 supportano le funzionalità di Archiviazione di Azure più recenti e incorporano tutte le funzionalità degli account di archiviazione BLOB e per utilizzo generico v1.

Archiviazione l'accesso agli account è limitato con regole del firewall tramite gruppi di sicurezza di rete di Azure, che filtrano il traffico di rete da e verso gli account di archiviazione. Per altre informazioni, vedere Panoramica dei gruppi di sicurezza di rete di Azure.

Il protocollo Transport Layer Security (TLS) versione 1.2 fornisce comunicazioni sicure, privacy dei dati e integrità dei dati.

I dati archiviati in etcd vengono crittografati in Azure Red Hat OpenShift?

I dati non vengono crittografati per impostazione predefinita, ma è possibile abilitare la crittografia. Per altre informazioni, vedere la guida sulla crittografia etcd.

È possibile scegliere una soluzione di archiviazione permanente, ad esempio OCS?

Il disco di Azure (Premium_LRS) è configurato come classe di archiviazione predefinita. Per altri provider di archiviazione e per informazioni dettagliate sulla configurazione (incluso File di Azure), vedere la documentazione di Red Hat sull'archiviazione permanente.

ARO archivia i dati dei clienti all'esterno dell'area del cluster?

No. Tutti i dati creati in un cluster ARO vengono conservati all'interno dell'area del cluster.