Disponibilità dell'applicazione nel servizio Azure Kubernetes abilitata da Azure Arc

Si applica a: Servizio Azure Kubernetes in Azure Stack HCI 22H2, servizio Azure Kubernetes in Windows Server

servizio Azure Kubernetes abilitata da Azure Arc offre una piattaforma contenitore completamente supportata che può eseguire applicazioni native del cloud nella piattaforma di orchestrazione del contenitore Kubernetes. L'architettura supporta l'esecuzione di carichi di lavoro Windows e Linux virtualizzati.

L'architettura del servizio Azure Kubernetes viene compilata con clustering di failover e migrazione in tempo reale abilitata automaticamente per i cluster di destinazione (carico di lavoro). Durante vari eventi di interruzione, le macchine virtuali che ospitano carichi di lavoro dei clienti vengono spostate liberamente senza tempi di inattività dell'applicazione percepiti. Ciò significa che un cliente aziendale tradizionale, che gestisce un'applicazione legacy come singleton al servizio Azure Stack HCI o Windows Server, otterrà un tempo di attività simile (o migliore) rispetto a quello attualmente riscontrato in un'applicazione vm legacy.

Questo articolo descrive alcuni concetti fondamentali per gli utenti che vogliono eseguire applicazioni in contenitori in AKS Arc con migrazione dinamica abilitata per garantire che le applicazioni siano disponibili durante un'interruzione. La terminologia di Kubernetes, ad esempio interruzioni volontarie e interruzioni involontarie, viene usata per fare riferimento al tempo di inattività di un'applicazione in esecuzione in un pod.

Che cos'è Live Migration?

La migrazione in tempo reale è una funzionalità Hyper-V che consente di spostare in modo trasparente le macchine virtuali in esecuzione da un host Hyper-V a un altro senza tempi di inattività percepiti. Il vantaggio principale della migrazione in tempo reale è la flessibilità; le macchine virtuali in esecuzione non sono associate a una singola macchina host. Ciò consente agli utenti di eseguire azioni, ad esempio svuotare un host specifico di macchine virtuali prima di rimuovere o aggiornare l'host. Se abbinato al clustering di failover di Windows, la migrazione in tempo reale consente la creazione di sistemi a tolleranza di errore e a disponibilità elevata.

L'architettura corrente del servizio Azure Kubernetes in Azure Stack HCI e Windows Server presuppone che i clienti abbiano abilitato la migrazione in tempo reale nell'ambiente cluster azure Stack HCI. Pertanto, tutte le macchine virtuali del nodo di lavoro Kubernetes verranno create con la migrazione in tempo reale configurata. Questi nodi possono essere spostati intorno agli host fisici in caso di interruzione per garantire che la piattaforma sia a disponibilità elevata.

Diagramma che mostra il servizio Azure Kubernetes in Azure Stack HCI e Windows Server con clustering di failover abilitato

Per un cliente che esegue un'applicazione legacy come singleton sopra Kubernetes, questa architettura soddisfa le esigenze di disponibilità elevata. Kubernetes gestirà la pianificazione dei pod nei nodi di lavoro disponibili mentre la migrazione in tempo reale gestirà la pianificazione delle macchine virtuali del nodo di lavoro in host fisici disponibili.

Diagramma che mostra un'applicazione legacy di esempio in esecuzione come singleton

Scenari di interruzione dell'applicazione

Uno studio comparativo dei tempi di ripristino per le applicazioni in esecuzione nelle macchine virtuali nel servizio Azure Stack HCI e Windows Server mostra chiaramente che si verifica un impatto minimo sull'applicazione quando si verificano eventi di interruzione comuni. Tre scenari di interruzione di esempio includono:

  • Applicazione di un aggiornamento che comporta un riavvio del computer fisico.
  • Applicazione di un aggiornamento che implica la ricreazione del nodo di lavoro.
  • Errore hardware non pianificato di un computer fisico.

Nota

Questi scenari presuppongono che il proprietario dell'applicazione usi ancora affinità Kubernetes e impostazioni anti-affinità per garantire una corretta pianificazione dei pod nei nodi di lavoro.

Evento di interruzione Esecuzione di applicazioni nelle macchine virtuali in Azure Stack HCI Esecuzione di applicazioni nelle macchine virtuali nel servizio Azure Kubernetes in Azure Stack HCI o Windows Server
Applicazione di un aggiornamento che comporta un riavvio del computer fisico Nessun impatto Nessun impatto
Applicazione di un aggiornamento che implica la ricreazione del nodo di lavoro (o riavvio della macchina virtuale) Nessun impatto Varia
Errore hardware non pianificato di un computer fisico 6-8 minuti 6-8 minuti

Applicazione di un aggiornamento che comporta un riavvio del computer fisico

Durante un evento di manutenzione host fisico, ad esempio l'applicazione di un aggiornamento che comporta il riavvio di un computer host, non è previsto alcun impatto per le applicazioni in esecuzione nel cluster. L'amministratore del cluster svuota l'host e garantisce che tutte le macchine virtuali siano in tempo reale prima di applicare l'aggiornamento.

Applicazione di un aggiornamento che implica la ricreazione del nodo di lavoro

Questo scenario comporta l'arresto di una macchina virtuale del nodo di lavoro per eseguire la manutenzione di routine. Per preparare l'aggiornamento, l'amministratore del cluster svuota e isola il nodo, quindi tutti i pod vengono eliminati in un nodo di lavoro disponibile prima di applicare gli aggiornamenti. Al termine dell'aggiornamento, il nodo di lavoro verrà ricongiurato e reso disponibile per la pianificazione.

Nota

La disponibilità di un'applicazione varia in base al tempo necessario per scaricare l'immagine del contenitore di base, in particolare per le immagini più grandi archiviate nel cloud pubblico. È quindi consigliabile usare immagini di contenitori di base di piccole dimensioni e per i contenitori di Windows, è consigliabile usare l'immagine nano server di base.

Errore hardware non pianificato di un computer fisico

In questo scenario si verifica un evento di interruzione involontaria in un computer fisico che ospita un contenitore/pod dell'applicazione legacy in una delle macchine virtuali del nodo di lavoro. Il clustering di failover inserisce l'host in uno stato isolato e quindi dopo un periodo di 6-8 minuti, avviare il processo di migrazione in tempo reale di queste macchine virtuali agli host sopravvissuti. In questo caso, il tempo di inattività dell'applicazione equivale al tempo necessario per riavviare le macchine virtuali del nodo host e del nodo di lavoro.

Conclusione

Le tecnologie di clustering di failover del servizio Azure Kubernetes sono progettate per garantire che gli ambienti di calcolo in Azure Stack HCI e Windows Server siano a disponibilità elevata e a tolleranza di errore. Tuttavia, il proprietario dell'applicazione deve comunque configurare le distribuzioni per usare le funzionalità di Kubernetes, ad esempio Deployments, Affinity MappingRelicaSets, , per assicurarsi che i pod siano resilienti negli scenari di interruzione.