Disponibilità delle applicazioni nell'ambiente ibrido del servizio Azure Kubernetes

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

servizio Azure Kubernetes opzioni di distribuzione ibrida del servizio Azure Kubernetes offrono una piattaforma contenitore completamente supportata in grado di eseguire applicazioni native del cloud nella piattaforma di orchestrazione dei contenitori Kubernetes. L'architettura supporta l'esecuzione di carichi di lavoro Windows e Linux virtualizzati.

L'architettura del servizio Azure Kubernetes viene compilata con il clustering di failover e la 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à percepiti dell'applicazione. Ciò significa che un cliente aziendale tradizionale, che gestisce un'applicazione legacy come singleton nel servizio Azure Kubernetes in Azure Stack HCI o Windows Server, otterrà un tempo di attività simile (o superiore) a quello attualmente riscontrato in un'applicazione di macchina virtuale legacy.

In questo argomento vengono descritti alcuni concetti fondamentali per gli utenti che vogliono eseguire applicazioni in contenitori nell'ambiente ibrido del servizio Azure Kubernetes con la migrazione in tempo reale 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 un singolo computer host. Ciò consente agli utenti di eseguire azioni come svuotare un host specifico di macchine virtuali prima di rimuovere o aggiornare l'host. Se abbinato a Windows Failover Clustering, la migrazione in tempo reale consente la creazione di sistemi a disponibilità elevata e a tolleranza di errore.

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

Per un cliente che esegue un'applicazione legacy come singleton su 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 negli host fisici disponibili.

Scenari di interruzione delle applicazioni

Uno studio comparativo dei tempi di ripristino per le applicazioni in esecuzione nelle macchine virtuali nel servizio Azure Kubernetes in 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 il riavvio del computer fisico.
• Applicazione di un aggiornamento che comporta 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 le impostazioni di affinità kubernetes e anti-affinità per garantire una corretta pianificazione dei pod tra 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 il riavvio del computer fisico	Nessun impatto	Nessun impatto
Applicazione di un aggiornamento che comporta la ricreazione del nodo di lavoro (o il 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 il 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 verifica che la migrazione di tutte le macchine virtuali venga eseguita prima di applicare l'aggiornamento.

Applicazione di un aggiornamento che comporta 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 rimossi in un nodo di lavoro disponibile prima di applicare gli aggiornamenti. Una volta completato l'aggiornamento, il nodo di lavoro verrà aggiunto nuovamente 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 involontario in un computer fisico che ospita un contenitore o un 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 da 6 a 8 minuti, avvia 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 elaborazione 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 l'uso delle funzionalità di Kubernetes, ad esempio Deployments, , Affinity MappingRelicaSets, per garantire che i pod siano resilienti negli scenari di interruzione.