Condividi tramite


Scenari di disponibilità per servizio Azure Kubernetes (servizio Azure Kubernetes) abilitati da Azure Arc in locale di Azure a due nodi

Si applica a: Azure Stack HCI, versione 22H2

Questo articolo descrive l'architettura per la distribuzione di un cluster Kubernetes in un cluster locale di Azure a due nodi. L'articolo descrive diversi scenari di errore che possono verificarsi, il loro impatto sul cluster e la recuperabilità da questi scenari di errore.

Architettura

Le distribuzioni di Kubernetes tradizionali richiedono tre computer fisici per attenuare un singolo errore. Questo requisito indica in genere un costo totale di proprietà (TCO) superiore. Per le distribuzioni sensibili ai costi, il servizio Azure Kubernetes abilitato da Arc può essere distribuito in un sistema locale di Azure a due nodi, come illustrato di seguito, con alcuni compromessi nella disponibilità. Questi compromessi sono descritti in Scenari di disponibilità e il relativo impatto sul cluster del servizio Azure Kubernetes a due nodi.

Figura che mostra l'architettura di un cluster del servizio Azure Kubernetes eseguito in un cluster locale di Azure a due nodi.

Per altre informazioni sull'architettura, sulle strategie di distribuzione del cluster, sulle considerazioni sull'affidabilità e sull'ottimizzazione dei costi per il servizio Azure Kubernetes, vedere architettura di base servizio Azure Kubernetes del servizio Azure Kubernetes .

Terminologia

In questo articolo viene usata la terminologia seguente:

Termine Definizione
Host locale di Azure fisico Nodo del cluster locale di Azure fisico che ospita le macchine virtuali necessarie per eseguire il servizio Azure Kubernetes abilitato da Arc.
Sistema operativo guest Sistema operativo in esecuzione all'interno della macchina virtuale del piano di controllo, della macchina virtuale del servizio di bilanciamento del carico o delle macchine virtuali del pool di nodi.
Clustering di failover Il clustering di failover per Azure local e Windows Server offre funzionalità di infrastruttura che supportano la disponibilità elevata di macchine virtuali e applicazioni. Se un nodo o un servizio del cluster ha esito negativo, le macchine virtuali o le applicazioni ospitate in tale nodo possono essere trasferite automaticamente o manualmente a un altro nodo disponibile in un processo noto come failover.
Cluster del carico di lavoro Un cluster Kubernetes distribuito da servizio Azure Kubernetes (AKS) per ospitare l'applicazione o il carico di lavoro dell'utente finale in contenitori, noto anche come cluster di destinazione.
Cluster di gestione (host servizio Azure Kubernetes) Fornisce il meccanismo di orchestrazione principale e l'interfaccia per la distribuzione e la gestione di uno o più cluster del carico di lavoro. Il cluster di gestione contiene una singola macchina virtuale del piano di controllo.
Bilanciamento del carico Una singola macchina virtuale Linux dedicata con una regola di bilanciamento del carico per il server API.
Server API Abilita l'interazione con il cluster Kubernetes, fornendo l'interazione per strumenti di gestione come Windows Admin Center, moduli di PowerShell e kubectl.
CRUD Operazioni di creazione, lettura, aggiornamento ed eliminazione.

Scenari di disponibilità e impatto sul cluster servizio Azure Kubernetes a due nodi

L'architettura ridotta in una distribuzione locale di Azure con due nodi fisici comporta alcuni compromessi di disponibilità. Questa sezione descrive il comportamento del nodo durante le modalità di errore seguenti e durante gli aggiornamenti:

Aggiornamenti

Usare la tabella seguente per determinare il potenziale impatto degli aggiornamenti del servizio Azure Locale e del servizio Azure Kubernetes nei carichi di lavoro:

Carichi di lavoro esistenti CRUD nei cluster del carico di lavoro Nuovo ciclo di vita del cluster del carico di lavoro Disponibilità server API
Nessuna interruzione Nessuna interruzione Nessuna interruzione Nessuna interruzione
L'aggiornamento compatibile con il cluster in Azure locale esegue la migrazione dei nodi di lavoro all'altro nodo prima del riavvio. Le applicazioni non vengono interrotte durante questa migrazione. L'aggiornamento compatibile con cluster in Azure locale esegue la migrazione della macchina virtuale del piano di controllo del cluster del carico di lavoro all'altro nodo prima del riavvio. I carichi di lavoro esistenti possono essere ridimensionati senza interruzioni durante un aggiornamento. L'aggiornamento compatibile con cluster in Azure locale esegue la migrazione della macchina virtuale del piano di controllo del cluster di gestione all'altro nodo prima del riavvio. È possibile creare nuovi carichi di lavoro senza interruzioni durante un aggiornamento. L'aggiornamento compatibile con cluster in Azure locale esegue la migrazione della macchina virtuale del piano di controllo del cluster del carico di lavoro all'altro nodo prima del riavvio. Il cluster del server API rimane disponibile durante un aggiornamento.

Errore hardware nell'host

L'host fisico che esegue le macchine virtuali che ospitano i nodi Kubernetes potrebbe smettere di funzionare a causa di problemi hardware o potrebbe diventare partizionato dalla rete.

Usare la tabella seguente per determinare il potenziale impatto degli errori hardware dell'host nei carichi di lavoro.

Carichi di lavoro esistenti CRUD nei cluster del carico di lavoro Nuovo ciclo di vita del cluster del carico di lavoro Disponibilità server API
Potenziale interruzione
+
Recupero automatico
Potenziale interruzione
+
Recupero automatico
Potenziale interruzione
+
Recupero automatico
Potenziale interruzione
+
Recupero automatico
I carichi di lavoro esistenti continuano a essere eseguiti senza interruzioni, purché:
- I nodi di lavoro si trovano in host separati.
- L'applicazione ha definito almeno due repliche con podAntiAffinity specificato.

Se un'applicazione ha una dipendenza da un indirizzo IP virtuale esterno (VIP) del server API, si verifica un'interruzione.
Se la macchina virtuale del piano di controllo del cluster del carico di lavoro risiede nell'host che è stata ridotta, i carichi di lavoro non verranno ridimensionati. L'aggiunta di nuovi nodi di lavoro e il ridimensionamento dei pod non funzioneranno. Se la macchina virtuale del piano di controllo del cluster di gestione si trova nell'host inattivo, non è possibile creare nuovi cluster. Il ridimensionamento dei cluster esistenti non funzionerà. Se la macchina virtuale del piano di controllo del cluster del carico di lavoro o la macchina virtuale del servizio di bilanciamento del carico si trova nell'host inattivo, il server API non è disponibile.
Se i nodi di lavoro si trovano nello stesso host fisico, Clustering di failover esegue il failover dei nodi di lavoro nell'host sopravvissuto.

Se l'applicazione non è stata creata con anti-affinità, Kubernetes sposta il pod nel nodo di lavoro esistente.

Se l'applicazione dipende dal server API e la macchina virtuale del piano di controllo o la macchina virtuale del servizio di bilanciamento del carico del cluster del carico di lavoro diventa inattiva, Clustering di failover sposta tali macchine virtuali nell'host sopravvissuto e l'applicazione riprende a funzionare. A seconda del modo in cui l'applicazione gestisce la perdita del server API, i pod potrebbero essere riavviati nel nuovo host.
Il clustering di failover esegue il failover della macchina virtuale del piano di controllo del cluster del carico di lavoro nell'host integro. Dopo il failover, i carichi di lavoro possono essere ridimensionati. Il clustering di failover esegue il failover della macchina virtuale del piano di controllo del cluster di gestione nell'host integro. Dopo il failover, le operazioni CRUD sui nuovi cluster di destinazione funzionano. Il clustering di failover esegue il failover della macchina virtuale del piano di controllo del cluster del carico di lavoro nell'host integro. Dopo il failover, il server API è disponibile.

Errore del sistema operativo host

L'host fisico che esegue le macchine virtuali che ospitano i nodi Kubernetes potrebbe avere un problema software nel sistema operativo e causare un errore.

Usare la tabella seguente per determinare il potenziale impatto degli errori del sistema operativo host nei carichi di lavoro.

Carichi di lavoro esistenti CRUD nei cluster del carico di lavoro Nuovo ciclo di vita del cluster del carico di lavoro Disponibilità server API
Potenziale interruzione
+
Recupero automatico
Potenziale interruzione
+
Recupero automatico
Potenziale interruzione
+
Recupero automatico
Potenziale interruzione
+
Recupero automatico
I carichi di lavoro esistenti continuano a essere eseguiti senza interruzioni, purché:
- I nodi di lavoro si trovano in host separati.
- L'applicazione ha definito almeno due repliche con podAntiAffinity specificato.

Se l'applicazione ha una dipendenza da un indirizzo VIP esterno del server API, si verifica un'interruzione.
Se la macchina virtuale del piano di controllo nel cluster di destinazione si trova nell'host con errori del sistema operativo, l'aggiunta di nuovi nodi di lavoro e il ridimensionamento dei pod non funzioneranno. Se la macchina virtuale del piano di controllo del cluster di gestione si trova nell'host con errori del sistema operativo, i nuovi cluster non verranno creati e i cluster esistenti non possono essere ridimensionati. Se la macchina virtuale del piano di controllo si trova nell'host con errori del sistema operativo, il server API non sarà disponibile.
Se i nodi di lavoro si trovano nello stesso host fisico, Clustering di failover esegue il failover dei nodi di lavoro nell'host sopravvissuto.

Se l'applicazione non è stata creata con anti-affinità, Kubernetes sposta il pod nel nodo di lavoro esistente.

Se l'applicazione ha dipendenza dal server API e la macchina virtuale del piano di controllo o la macchina virtuale del servizio di bilanciamento del carico di lavoro del cluster del carico di lavoro si arresta, Clustering di failover sposta tali macchine virtuali nell'host sopravvissuto e l'applicazione riprende. A seconda del modo in cui l'applicazione gestisce la perdita del server API, i pod potrebbero essere riavviati nel nuovo host.
Il clustering di failover esegue il failover della macchina virtuale del piano di controllo del cluster del carico di lavoro nell'host integro. Dopo il failover, i carichi di lavoro possono essere ridimensionati. Il clustering di failover esegue il failover della macchina virtuale del piano di controllo del cluster di gestione nell'host integro. Dopo il failover, le operazioni CRUD sui nuovi cluster di destinazione funzioneranno. Clustering di failover riavvia la macchina virtuale del piano di controllo del cluster del carico di lavoro nell'host integro. Successivamente, il server API è disponibile.

Errore della macchina virtuale del piano di gestione

La macchina virtuale del piano di controllo del cluster di gestione potrebbe essere eliminata in modo imprevisto, il disco di avvio potrebbe essere danneggiato o la macchina virtuale del piano di controllo del cluster di gestione potrebbe non essere avviata a causa di problemi del sistema operativo.

Usare la tabella seguente per determinare il potenziale impatto dell'errore della macchina virtuale del piano di controllo del cluster di gestione nei carichi di lavoro.

Carichi di lavoro esistenti CRUD nei cluster del carico di lavoro Nuovo ciclo di vita del cluster del carico di lavoro Disponibilità server API
Nessuna interruzione Rottura
+
Recupero manuale
Rottura
+
Recupero manuale
Nessuna interruzione
I carichi di lavoro esistenti continuano a essere eseguiti se la macchina virtuale del cluster di gestione non riesce. Non è possibile aggiungere nodi di lavoro per ridimensionare l'applicazione. La creazione di un nuovo carico di lavoro non riesce mentre il cluster di gestione è inattivo. Il server API deve rimanere disponibile in caso di errore della macchina virtuale del cluster di gestione.
Non applicabile Se clustering di failover può eseguire il ripristino dall'errore, tenta di riavviare la macchina virtuale del piano di gestione in un host diverso. Se il clustering di failover non riesce a ripristinare la macchina virtuale, il cluster di gestione deve essere ricompilato manualmente. Per altre informazioni, vedere Eseguire il backup e il ripristino dei cluster del carico di lavoro. Se clustering di failover può eseguire il ripristino dall'errore, tenta di riavviare la macchina virtuale del piano di gestione in un host diverso. Se il clustering di failover non riesce a ripristinare la macchina virtuale, il cluster di gestione deve essere ricompilato manualmente. Per istruzioni, vedere Eseguire il backup e il ripristino dei cluster del carico di lavoro. Non applicabile

Errore della macchina virtuale del piano di controllo

La macchina virtuale del piano di controllo del cluster del carico di lavoro potrebbe essere eliminata in modo imprevisto, il disco di avvio potrebbe essere danneggiato o la macchina virtuale potrebbe non essere avviata a causa di problemi del sistema operativo.

Usare la tabella seguente per determinare il potenziale impatto dell'errore della macchina virtuale del piano di controllo di un cluster del carico di lavoro nei carichi di lavoro.

Carichi di lavoro esistenti CRUD nei cluster del carico di lavoro Nuovo ciclo di vita del cluster del carico di lavoro Disponibilità server API
Nessuna interruzione Rottura
+
Recupero manuale
Nessuna interruzione Rottura
+
Recupero manuale
I carichi di lavoro esistenti continuano a essere eseguiti senza interruzioni, purché:
- I nodi di lavoro si trovano in host separati.
- L'applicazione ha definito almeno due repliche con podAntiAffinity specificato.

Se l'applicazione ha una dipendenza da un indirizzo VIP esterno del server API, si verifica un'interruzione.
I carichi di lavoro non possono essere ridimensionati mentre la macchina virtuale del piano di controllo si trova in uno stato di errore. L'aggiunta di nuovi nodi di lavoro e il ridimensionamento dei pod non funzioneranno. La creazione di un nuovo carico di lavoro ha esito positivo. Il server API non è disponibile quando la macchina virtuale del piano di controllo si trova in uno stato di errore.
Non applicabile Se clustering di failover può eseguire il ripristino dall'errore, tenta di riavviare la macchina virtuale del piano di controllo in un host diverso. Se il clustering di failover non riesce a ripristinare la macchina virtuale, la macchina virtuale del piano di controllo deve essere ricompilata manualmente. Per istruzioni, vedere Eseguire il backup e il ripristino dei cluster del carico di lavoro. Non applicabile Se clustering di failover può eseguire il ripristino dall'errore, tenta di riavviare la macchina virtuale del piano di controllo in un host diverso. Se il clustering di failover non riesce a ripristinare la macchina virtuale, la macchina virtuale del piano di controllo deve essere ricompilata manualmente. Per istruzioni, vedere Eseguire il backup e il ripristino dei cluster del carico di lavoro.

Errore della macchina virtuale del pool di nodi (nodi di lavoro)

Le macchine virtuali che ospitano i nodi Kubernetes potrebbero essere eliminate in modo imprevisto, il disco di avvio potrebbe essere danneggiato o le macchine virtuali potrebbero non avviarsi a causa di problemi del sistema operativo.

Usare la tabella seguente per determinare il potenziale impatto dell'errore di una macchina virtuale all'interno di un pool di nodi Kubernetes nei carichi di lavoro.

Carichi di lavoro esistenti CRUD nei cluster del carico di lavoro Nuovo ciclo di vita del cluster del carico di lavoro Disponibilità server API
Potenziale interruzione
+
Recupero manuale
Nessuna interruzione Nessuna interruzione Nessuna interruzione
I carichi di lavoro esistenti continuano a essere eseguiti senza interruzioni, purché:
- I nodi di lavoro si trovano in host separati.
- L'applicazione ha definito almeno due repliche con podAntiAffinity specificato.
È possibile aggiungere nodi di lavoro.
La pianificazione dei pod ha esito positivo se i nodi rimanenti hanno una capacità sufficiente.
La creazione di un nuovo carico di lavoro ha esito positivo. Il server API rimane disponibile in caso di errore di una singola macchina virtuale del ruolo di lavoro.
Se clustering di failover può eseguire il ripristino dall'errore, tenta di riavviare la macchina virtuale del piano di controllo in un host diverso. Se il clustering di failover non riesce a ripristinare la macchina virtuale, è necessario ricreare manualmente i nodi di lavoro. Non applicabile Non applicabile Non applicabile

Errore della macchina virtuale del servizio di bilanciamento del carico

La macchina virtuale del servizio di bilanciamento del carico potrebbe essere eliminata in modo imprevisto, il disco di avvio potrebbe essere danneggiato o la macchina virtuale potrebbe non essere avviata a causa di problemi del sistema operativo.

Usare la tabella seguente per determinare il potenziale impatto di un errore della macchina virtuale del servizio di bilanciamento del carico nei carichi di lavoro.

Carichi di lavoro esistenti CRUD nei cluster del carico di lavoro Nuovo ciclo di vita del cluster del carico di lavoro Disponibilità server API
Potenziale interruzione
+
Recupero automatico
Rottura
+
Recupero manuale
Nessuna interruzione Rottura
+
Recupero manuale
I carichi di lavoro esistenti continuano a essere eseguiti senza interruzioni, purché:
- I nodi di lavoro si trovano in host separati.
- L'applicazione ha definito almeno due repliche con podAntiAffinity specificato.

Se un'applicazione ha una dipendenza da un indirizzo VIP esterno del server API, si verifica un'interruzione.
I carichi di lavoro non possono essere ridimensionati mentre la macchina virtuale del servizio di bilanciamento del carico si trova in uno stato di errore. L'aggiunta di nuovi nodi di lavoro e il ridimensionamento dei pod non funzioneranno. La creazione del carico di lavoro ha esito positivo. Il server API rimane non disponibile mentre la macchina virtuale del servizio di bilanciamento del carico è inattiva.
Se clustering di failover può eseguire il ripristino dall'errore, tenta di riavviare la macchina virtuale del servizio di bilanciamento del carico in un host diverso. Se il clustering di failover non riesce a ripristinare la macchina virtuale, è necessario ricompilare manualmente la macchina virtuale del piano di controllo. Per istruzioni, vedere Eseguire il backup e il ripristino dei cluster del carico di lavoro. Se clustering di failover può eseguire il ripristino dall'errore, tenta di riavviare la macchina virtuale del servizio di bilanciamento del carico in un host diverso. Se il clustering di failover non riesce a ripristinare la macchina virtuale, è necessario ricompilare manualmente la macchina virtuale del piano di controllo. Per istruzioni, vedere Eseguire il backup e il ripristino dei cluster del carico di lavoro. Non applicabile Se clustering di failover può eseguire il ripristino dall'errore, tenta di riavviare la macchina virtuale del servizio di bilanciamento del carico in un host diverso. Se il clustering di failover non riesce a ripristinare la macchina virtuale, è necessario ricompilare manualmente la macchina virtuale del piano di controllo. Per istruzioni, vedere Eseguire il backup e il ripristino dei cluster del carico di lavoro.

Passaggi successivi