Criteri di supporto di Azure Red Hat OpenShift 4.0

Alcune configurazioni per i cluster di Azure Red Hat OpenShift 4 possono influenzare l'idoneità al supporto del cluster. Azure Red Hat OpenShift 4 consente agli amministratori del cluster di apportare modifiche ai componenti interni al cluster, ma non tutte le modifiche sono supportate. Il criterio di supporto riportato di seguito condivide le modifiche che violano i criteri e rendono nullo il supporto Microsoft e Red Hat.

Requisiti di configurazione del cluster

Calcolo

• Il cluster deve avere almeno tre nodi di lavoro e tre nodi master.
• Non ridimensionare i ruoli di lavoro del cluster a zero o tentare l'arresto del cluster. La deallocazione o l'accensione di qualsiasi macchina virtuale nel gruppo di risorse cluster non è supportata.
• Non creare più di 250 nodi ruoli di lavoro in un cluster. Il numero massimo di nodi che è possibile creare in un cluster è 250. Per altre informazioni, vedere Configurare più indirizzi IP per ogni servizio di bilanciamento del carico del cluster ARO.
• Se si usano nodi dell'infrastruttura, non eseguire carichi di lavoro non definiti su di essi, in quanto ciò può influire sul Contratto di servizio e sulla stabilità del cluster. È anche consigliabile avere tre nodi dell'infrastruttura; uno in ogni zona di disponibilità. Per altre informazioni, vedere Distribuire i nodi dell'infrastruttura in un cluster Azure Red Hat OpenShift (ARO).
• I nodi di calcolo non RHCOS non sono supportati. Ad esempio, non è possibile usare un nodo di calcolo RHEL.
• Non tentare di rimuovere, sostituire, aggiungere o modificare un nodo master. Si tratta di un'operazione ad alto rischio che può causare problemi con etcd, perdita di rete permanente e perdita di accesso e gestibilità da parte di ARO SRE. Se si ritiene che un nodo master debba essere sostituito o rimosso, contattare il supporto tecnico prima di apportare modifiche.
• Assicurarsi che sia disponibile un'ampia quota di macchine virtuali nel caso in cui i nodi del piano di controllo debbano essere ridimensionati mantenendo disponibile almeno il doppio del numero di vCPU del piano di controllo corrente.

Operatori

• Tutti gli operatori del cluster OpenShift devono rimanere in uno stato gestito. È possibile restituire l'elenco degli operatori del cluster eseguendo oc get clusteroperators.

Gestione dei carichi di lavoro

• Non aggiungere taint che impediscono la pianificazione di tutti i componenti OpenShift predefiniti.
• Per evitare interruzioni derivanti dalla manutenzione del cluster, i carichi di lavoro in cluster devono essere configurati con procedure di disponibilità elevata, tra cui, a titolo esemplificativo, l'affinità dei pod e l'anti-affinità, i budget di interruzione dei pod e un ridimensionamento adeguato.
• Non eseguire carichi di lavoro aggiuntivi nei nodi del piano di controllo. Anche se possono essere pianificati nei nodi del piano di controllo, causa problemi aggiuntivi di utilizzo e stabilità delle risorse che possono influire sull'intero cluster.
• L'esecuzione di carichi di lavoro personalizzati (inclusi gli operatori installati dall'hub operatore o da altri operatori forniti da Red Hat) nei nodi dell'infrastruttura non è supportata.

Registrazione e monitoraggio

• Non rimuovere o modificare il servizio Prometheus predefinito del cluster, tranne per modificare la pianificazione dell'istanza predefinita di Prometheus.
• Non rimuovere o modificare il cluster svc predefinito Alertmanager, il ricevitore predefinito o le regole di avviso predefinite, ad eccezione dell'aggiunta di altri ricevitori per inviare notifiche ai sistemi esterni.
• Non rimuovere o modificare la registrazione del servizio Azure Red Hat OpenShift (pod MDSD).

Rete e sicurezza

• Il gruppo di sicurezza di rete fornito da ARO non può essere modificato o sostituito. Qualsiasi tentativo di modifica o sostituzione verrà ripristinato.
• Tutte le macchine virtuali del cluster devono avere accesso diretto a Internet in uscita, almeno agli endpoint di Azure Resource Manager (ARM) e di registrazione dei servizi (Geneva). Non è supportata alcuna forma d'uso di proxy HTTPS.
• Il servizio Azure Red Hat OpenShift accede al cluster tramite il servizio di collegamento privato. Non rimuovere o modificare l'accesso al servizio.
• La migrazione da OpenShift SDN a OVN non è supportata.

Gestione dei cluster

• Non rimuovere o modificare il segreto pull del cluster "arosvc.azurecr.io".
• Non creare nuovi oggetti MachineConfig né modificare quelli esistenti, a meno che non siano supportati in modo esplicito nella documentazione di Azure Red Hat OpenShift.
• Non creare nuovi oggetti KubeletConfig né modificare quelli esistenti, a meno che non siano supportati in modo esplicito nella documentazione di Azure Red Hat OpenShift.
• Non impostare opzioni non supportateConfigOverrides. L'impostazione di queste opzioni impedisce gli aggiornamenti delle versioni secondarie.
• Non inserire criteri all'interno della sottoscrizione o del gruppo di gestione che impediscono alle istanze SRE di eseguire la manutenzione normale nel cluster Azure Red Hat OpenShift. Ad esempio, non richiedere tag nel gruppo di risorse del cluster gestito da RP di Azure Red Hat OpenShift.
• Non aggirare l'assegnazione di rifiuto configurata come parte del servizio o eseguire attività amministrative normalmente vietate dall'assegnazione di rifiuto.
• OpenShift si basa sulla possibilità di contrassegnare automaticamente le risorse di Azure. Se è stato configurato un criterio di assegnazione di tag, non applicare più di 10 tag definiti dall'utente alle risorse nel gruppo di risorse gestite.

Gestione incidenti

Un evento imprevisto è un evento che comporta una riduzione o un'interruzione dei servizi Di Azure Red Hat OpenShift. Gli eventi imprevisti vengono generati da un cliente o da un membro di Customer Experience and Engagement (CEE) tramite un caso di supporto, direttamente dal sistema di monitoraggio e avviso centralizzato o direttamente da un membro del team ARO Site Reliability Engineer (SRE).

A seconda dell'impatto sul servizio e sul cliente, l'evento imprevisto viene categorizzato in termini di gravità.

Il flusso di lavoro generale di come viene gestito un nuovo evento imprevisto è descritto di seguito:

1. Un primo risponditore SRE viene avvisato di un nuovo evento imprevisto e inizia un'indagine iniziale.

2. Dopo l'indagine iniziale, all'evento imprevisto viene assegnato un responsabile dell'evento imprevisto, che coordina le attività di ripristino.

3. Il responsabile dell'evento imprevisto gestisce tutte le comunicazioni e il coordinamento per il ripristino, incluse eventuali notifiche rilevanti o aggiornamenti dei casi di supporto.

4. L'evento imprevisto viene recuperato.

5. L'evento imprevisto è documentato e un'analisi della causa radice viene eseguita entro 5 giorni lavorativi dall'evento imprevisto.

6. Un documento di bozza RCA viene condiviso con il cliente entro 7 giorni lavorativi dall'evento imprevisto.

Dimensioni delle macchine virtuali supportate

Azure Red Hat OpenShift 4 supporta le istanze del nodo in macchine virtuali con le dimensioni seguenti:

Nodi del piano di controllo

*Standard_M128ms' non supporta la crittografia nell'host

Nodi del ruolo di lavoro

Utilizzo generico

Ottimizzato per la memoria

Con ottimizzazione per il calcolo

Memoria con ottimizzazione per il calcolo

*Standard_M128ms' non supporta la crittografia nell'host

Con ottimizzazione per l'archiviazione

Carico di lavoro GPU

*Solo giorno-2 (ad esempio, non supportato come opzione di installazione)