Disponibilità dell'applicazione in servizio Azure Kubernetes in Azure Stack HCI e Windows Server

servizio Azure Kubernetes (servizio Azure Kubernetes) in Azure Stack HCI e Windows Server è 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 di Windows e Linux virtualizzati sopra Azure Stack HCI e Windows Server.

L'architettura del servizio Azure Kubernetes in Azure Stack HCI e Windows Server 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 i 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 e Windows Server, otterrà un tempo di attività simile (o migliore) rispetto a quello attualmente riscontrato in un'applicazione vm legacy.

Questo argomento descrive alcuni concetti fondamentali per gli utenti che vogliono eseguire applicazioni in contenitori nel servizio Azure Stack HCI e Windows Server 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 ai tempi 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. Quando si associa Windows clustering di failover, 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.

Diagram showing AKS on Azure Stack HCI and Windows Server with Failover Clustering enabled

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.

Diagram showing an example legacy application running as a 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 vm nel servizio Azure Kubernetes in Azure Stack HCI e 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 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

Il servizio Azure Kubernetes in Azure Stack HCI e Windows le tecnologie di clustering del server e del failover sono entrambi progettati per garantire che gli ambienti di calcolo 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.