Set di disponibilità nel servizio Azure Kubernetes abilitati da Azure Arc
I set di disponibilità sono gruppi logici di macchine virtuali con relazioni di anti-affinità deboli tra loro, per assicurarsi che vengano distribuiti uniformemente tra i domini di errore disponibili in un cluster fisico. Un dominio di errore in questo contesto è un host fisico o un gruppo di host fisici. Usando i set di disponibilità, Arc del servizio Azure Kubernetes può migliorare la disponibilità e la distribuzione dei carichi di lavoro Kubernetes. I set di disponibilità possono evitare scenari in cui un singolo errore del nodo può causare la riduzione o la mancata ribilanciamento di più macchine virtuali.
Panoramica
Se si usa il servizio Azure Kubernetes in Azure Stack HCI e Windows Server per eseguire carichi di lavoro Kubernetes in locale, potrebbero verificarsi alcuni problemi con l'architettura corrente. Ad esempio, è possibile notare che più macchine virtuali (VM) all'interno dello stesso pool di nodi possono esistere nello stesso host fisico, che non è ideale per la disponibilità elevata. In alternativa, è possibile notare che le macchine virtuali non ribilanciano tra gli host fisici quando un host viene ripristinato da un problema, causando una distribuzione non uniforme dei carichi di lavoro. Questi problemi possono influire sulle prestazioni e sull'affidabilità delle applicazioni, causando interruzioni non necessarie nelle operazioni aziendali.
I set di disponibilità offrono diversi vantaggi per il servizio Azure Kubernetes in Azure Stack HCI e gli utenti di Windows Server, ad esempio:
- Migliora la disponibilità e la resilienza delle applicazioni evitando scenari in cui più macchine virtuali all'interno dello stesso pool di nodi o piano di controllo si arrestino o diventano sbilanciate a causa di un errore a nodo singolo.
- Ottimizza l'utilizzo delle risorse e le prestazioni del cluster assicurando che le macchine virtuali vengano distribuite uniformemente tra i nodi disponibili e non si concentrino su un singolo nodo o su un subset di nodi.
- È in linea con le procedure consigliate e le aspettative dei clienti e dei partner che cercano un'esperienza Kubernetes affidabile e coerente.
Abilitare i set di disponibilità
Con il servizio Azure Kubernetes in Azure Stack HCI 23H2, la funzionalità dei set di disponibilità è abilitata per impostazione predefinita quando si crea un nuovo pool di nodi.
Con il servizio Azure Kubernetes in Azure Stack HCI 22H2, la funzionalità dei set di disponibilità è disabilitata per impostazione predefinita. Per abilitarla, aggiungere il -enableAvailabilitySet parametro quando si crea un cluster del carico di lavoro. Ad esempio:
New-AksHciCluster -Name <name> -controlPlaneNodeCount 3 -osType Linux -kubernetesVersion $kubernetesVersion -enableAvailabilitySet
Funzionamento dei set di disponibilità nel servizio Azure Kubernetes abilitato da Azure Arc
Quando si crea un nuovo cluster Azure Kubernetes Arc, Arc crea automaticamente set di disponibilità, uno per le macchine virtuali del piano di controllo e un altro per ognuno dei pool di nodi nel cluster. Ogni pool di nodi ha un proprio set di disponibilità. Con questo layout, AKS Arc garantisce che le macchine virtuali dello stesso ruolo (piano di controllo o pool di nodi) non si trovino mai nello stesso host fisico e che vengano distribuite tra i nodi disponibili in un cluster.
Dopo aver creato i set di disponibilità e aver assegnato le macchine virtuali, il sistema li inserisce automaticamente nei nodi fisici appropriati. Se un nodo ha esito negativo, anche il sistema esegue automaticamente il failover delle macchine virtuali in altri nodi e li ribilancia quando il nodo viene ripristinato. In questo modo, è possibile ottenere disponibilità elevata e distribuzione ottimale dei carichi di lavoro Kubernetes senza intervento manuale.
Si consideri un servizio Azure Kubernetes nel cluster Azure Stack HCI 23H2 con due computer host fisici, Host A e Host B, tre macchine virtuali del piano di controllo e due macchine virtuali del nodo di lavoro, Nodepool1VM1 e Nodepool1VM2. Per garantire la disponibilità elevata delle applicazioni Kubernetes, le macchine virtuali del pool di nodi non devono mai condividere lo stesso host, a meno che uno degli host non sia temporaneamente disponibile per la manutenzione pianificata o il problema di capacità, che può causare l'inserimento temporaneo della macchina virtuale in un host alternativo.
Nel diagramma seguente ogni colore rappresenta un gruppo di anti-affinità:
Se l'host B è inattivo a causa di un riavvio, il piano di controllo VM2, il piano di controllo VM3 e Nodepool1VM2 esegue il failover nell'host A , come illustrato nella figura seguente. Supponendo che l'applicazione esegua pod in NodePoolVM1, questo riavvio non ha alcun impatto sull'applicazione:
Nell'architettura precedente, se l'host B è tornato online dopo un riavvio, non c'era alcuna garanzia che le macchine virtuali tornassero dall'host A all'host B (ribilanciamento), forzando così i carichi di lavoro a rimanere nello stesso host e creare un singolo punto di errore, come illustrato nel diagramma seguente:
I set di disponibilità per Il servizio Azure Kubernetes Arc consentono di ribilanciare le macchine virtuali dopo che un host viene ripristinato da interruzioni temporanee. In questo esempio, ControlPlaneVM2, ControlPlaneVM3 e Nodepool1VM2 passano automaticamente all'host B, come illustrato di seguito:
Importante
I set di disponibilità in AKS Arc sono una nuova funzionalità ancora in continua evoluzione e miglioramento. Non è ancora supportata la configurazione manuale dei domini di errore o dei set di disponibilità. Non è possibile modificare i domini di errore di un set di disponibilità dopo la creazione. Le macchine virtuali vengono assegnate a un set di disponibilità durante la creazione del cluster e non possono essere migrate a un set di disponibilità diverso.
Aggiungere o eliminare computer
In uno scenario di eliminazione host, l'host non viene più considerato una parte del cluster. Questa eliminazione si verifica in genere quando si sostituisce un computer a causa di problemi hardware o si ridurre il cluster HCI per altri motivi. Durante un'interruzione del nodo, il nodo rimane parte del cluster HCI, ma viene visualizzato come Inattivo.
Se un computer fisico (dominio di errore) viene eliminato definitivamente dal cluster, la configurazione del set di disponibilità non viene modificata per ridurre il numero di domini di errore. In questo scenario, il set di disponibilità entra in uno stato non integro. È consigliabile ridistribuire i cluster del carico di lavoro in modo che il set di disponibilità venga aggiornato con il numero corretto di domini di errore.
Quando un nuovo computer fisico (dominio di errore) viene aggiunto al cluster, la configurazione del set di disponibilità viene espansa automaticamente per includere il nuovo computer. Tuttavia, le macchine virtuali esistenti non ribilanciano per applicare questa nuova configurazione, poiché sono già assegnate ai set di disponibilità. È consigliabile ridistribuire i cluster del carico di lavoro in modo che il set di disponibilità venga aggiornato con il numero corretto di domini di errore.