Raccomandazioni sulla resilienza della zona per il servizio Azure Kubernetes

Si applica a: ✔️ Servizio Azure Kubernetes Standard automatico ✔️ Servizio Azure Kubernetes standard

La resilienza della zona è una parte fondamentale dell'esecuzione di cluster Kubernetes di livello di produzione. La scalabilità è alla base di Kubernetes, che in questo modo sfrutta appieno l'infrastruttura indipendente nei data center senza incorrere in costi aggiuntivi effettuando il provisioning di nuovi nodi solo quando è necessario.

In questo articolo vengono illustrate le raccomandazioni per la resilienza di zona in AKS, incluso come:

• Rendere i componenti del cluster AKS resilienti a livello di zona.
• Progettare applicazioni stateless per scenari di errore di una zona.
• Scegliere le opzioni di ridondanza di archiviazione.
• Testare il comportamento dell'applicazione e della piattaforma durante gli errori di zona.

Modalità del cluster AKS e resilienza della zona

AKS supporta due modalità del cluster:

• AKS Automatic, che offre un maggior numero di impostazioni predefinite della piattaforma preconfigurate.
• AKS Standard, che offre un controllo diretto da parte dell'operatore più ampio.

I principi di resilienza della zona in questo articolo si applicano a entrambe le modalità del cluster. La differenza principale è la proprietà delle operazioni della piattaforma.

Per il comportamento completo delle funzionalità in base alla modalità, vedere il confronto tra le funzionalità di AKS Automatic e AKS Standard.

Rendere i componenti del cluster del servizio Azure Kubernetes resilienti a livello di zona

Le sezioni seguenti descrivono i principali punti decisionali per la resilienza tra zone in AKS. Non sono esaustivi. È anche consigliabile convalidare la resilienza della zona per le dipendenze, ad esempio archivi dati, sistemi di identità e servizi esterni.

Creare cluster e pool di nodi con ridondanza della zona

AKS consente di selezionare più zone di disponibilità (AZ) durante la creazione del cluster e del pool di nodi. Nelle aree che supportano più reti AZ, il piano di controllo viene distribuito automaticamente tra le zone. I nodi del pool di nodi vengono distribuiti tra le zone selezionate. Questo approccio garantisce che il piano di controllo e i nodi vengano distribuiti tra più zone di disponibilità, assicurando resilienza in caso di errore in una zona di disponibilità.

Indicazioni sulla modalità cluster:

• AKS Automatic: molte impostazioni predefinite della piattaforma sono già configurate. È comunque necessario verificare che i carichi di lavoro critici per l'azienda vengano intenzionalmente distribuiti tra zone e che il comportamento di errore soddisfi i requisiti.
• AKS Standard: Progetta esplicitamente la topologia del pool di nodi, le impostazioni di ridimensionamento e il comportamento rispetto ai domini di errore.

L'esempio seguente illustra come creare un cluster con tre nodi distribuiti tra tre zone di disponibilità usando l'interfaccia della riga di comando di Azure:

az aks create --resource-group $RESOURCE_GROUP --name $CLUSTER_NAME --generate-ssh-keys --vm-set-type VirtualMachineScaleSets --load-balancer-sku standard --node-count 3 --zones 1 2 3

Una volta creato il cluster, è possibile usare il comando seguente per recuperare l'area geografica e la zona di disponibilità per ogni nodo dell'agente dalle etichette:

kubectl describe nodes | grep -e "Name:" -e "topology.kubernetes.io/zone"

L'output di esempio seguente mostra l'area geografica e la zona di disponibilità per ogni nodo dell'agente:

Name:       aks-nodepool1-28993262-vmss000000
            topology.kubernetes.io/zone=eastus2-1
Name:       aks-nodepool1-28993262-vmss000001
            topology.kubernetes.io/zone=eastus2-2
Name:       aks-nodepool1-28993262-vmss000002
            topology.kubernetes.io/zone=eastus2-3

Per altre informazioni, vedere Usare le zone di disponibilità nel servizio Azure Kubernetes.

Assicurarsi che i pod siano distribuiti tra le zone di disponibilità

La strategia di posizionamento dei pod è un aspetto relativo al carico di lavoro sia in AKS Automatic che in AKS Standard. Le impostazioni predefinite della piattaforma non sostituiscono i requisiti della topologia a livello di carico di lavoro.

A partire da Kubernetes versione 1.33, il Kube-Scheduler predefinito di AKS è configurato per usare un valore di MaxSkew pari a 1 per topology.kubernetes.io/zone:

topologySpreadConstraints:
- maxSkew: 1
  topologyKey: "topology.kubernetes.io/zone"
  whenUnsatisfiable: ScheduleAnyway

Questa configurazione è destinata a non più di una singola differenza di pod tra le zone, riducendo la probabilità che un errore di zona causi un'interruzione della distribuzione.

Se la distribuzione ha esigenze topologiche specifiche, è possibile sovrascrivere questi valori predefiniti nella specifica del pod. È possibile usare i vincoli di distribuzione topologica dei pod basati sulle etichette zone e hostname per distribuire i pod tra le zone di disponibilità all'interno di un'area e tra gli host all'interno delle zone di disponibilità.

Si supponga, ad esempio, di avere un cluster a quattro nodi in cui tre pod con etichetta app: mypod-app si trovano rispettivamente in node1, node2 e node3. Se si vuole che la distribuzione in ingresso sia ospitata in nodi distinti il più possibile, è possibile usare un manifesto simile all'esempio seguente:

apiVersion: v1
kind: Deployment
metadata:
  name: mypod-deployment
  labels:
    app: mypod-app
spec:
  replicas: 3
  selector:
    matchLabels:
      app: mypod-app
  template:
    metadata:
      labels:
        app: mypod-app
    spec:
      topologySpreadConstraints:
      - maxSkew: 1
        topologyKey: "kubernetes.io/hostname"
        whenUnsatisfiable: ScheduleAnyway
      containers:
      - name: pause
        image: registry.k8s.io/pause

Per altre informazioni sulla configurazione della distribuzione dei pod e sulla comprensione delle implicazioni di MaxSkew, vedere la documentazione sulla topologia dei pod Kubernetes. Ad esempio, come nodeTaintsPolicy: Honor influisce sulla distribuzione dei pod.

Configurare una rete compatibile con le zone di disponibilità

Se si hanno pod che gestiscono il traffico di rete, è consigliabile bilanciare il carico del traffico tra più zone di disponibilità per assicurarsi che l'applicazione sia a disponibilità elevata e resiliente agli errori. È possibile usare Azure Load Balancer per distribuire il traffico in ingresso tra i nodi del cluster del servizio Azure Kubernetes.

Azure Load Balancer supporta il bilanciamento del carico sia interno che esterno ed è possibile configurarlo per l'uso di uno SKU Standard per il bilanciamento del carico con ridondanza della zona. Lo SKU Standard è quello predefinito nel servizio Azure Kubernetes e supporta la resilienza a livello di area geografica con le zone di disponibilità per garantire che l'applicazione non sia interessata da un errore dell'area geografica. Se si verifica un errore in una zona, un servizio di bilanciamento del carico dello SKU Standard con ridondanza della zona non è interessato dall'errore e consente alle distribuzioni di continuare a gestire il traffico dalle zone rimanenti. È possibile usare un servizio di bilanciamento del carico globale, ad esempio Frontdoor o Gestione traffico oppure è possibile usare servizi di bilanciamento del carico tra più aree davanti ai cluster del servizio Azure Kubernetes a livello di area geografica per assicurarsi che l'applicazione non sia interessata da errori a livello di area geografica. Per creare un servizio di bilanciamento del carico dello SKU Standard nel servizio Azure Kubernetes, vedere Usare un'istanza di Load Balancer Standard nel servizio Azure Kubernetes.

Per assicurarsi che il traffico di rete dell'applicazione sia resiliente agli errori, è consigliabile configurare una rete compatibile con le zone di disponibilità per i carichi di lavoro del servizio Azure Kubernetes. Azure offre diversi servizi di rete che supportano le zone di disponibilità:

• Gateway VPN di Azure: è possibile distribuire i gateway VPN ed ExpressRoute nelle zone di disponibilità di Azure per consentire una migliore resilienza, scalabilità e disponibilità dei gateway di rete virtuale. Per altre informazioni, vedere Creare un gateway di rete virtuale con ridondanza della zona in zone di disponibilità.
• Gateway applicazione di Azure v2: il gateway applicazione di Azure fornisce un servizio di bilanciamento del carico L7 a livello di area geografica con supporto delle zone di disponibilità. Per altre informazioni, vedere Indirizzare il traffico Web con il gateway applicazione di Azure.
• Frontdoor di Azure: Frontdoor di Azure fornisce un servizio di bilanciamento del carico L7 globale e sfrutta le località POP (Point Of Presence) o la rete CDN di Azure. Per altre informazioni, vedere Località POP di Frontdoor di Azure.

Configurare un registro contenitori con ridondanza della zona e replica geografica

Per assicurarsi che le immagini del contenitore siano a disponibilità elevata e resilienti agli errori, è consigliabile configurare un registro contenitori con ridondanza della zona. Lo SKU Premium Registro Azure Container supporta la replica geografica e la ridondanza della zona facoltativa. Queste funzionalità offrono disponibilità e riducono la latenza per le operazioni a livello di area geografica.

Assicurare la disponibilità e la ridondanza per chiavi e segreti

Azure Key Vault offre più livelli di ridondanza, per garantire che le chiavi e i segreti rimangano disponibili per l'applicazione anche quando si verificano errori di singoli componenti del servizio o quando le aree o le zone di disponibilità di Azure non sono disponibili. Per altre informazioni, vedere Disponibilità e ridondanza in Azure Key Vault.

Usare le funzionalità di scalabilità automatica

È possibile migliorare la disponibilità e la resilienza dell'applicazione nel servizio Azure Kubernetes usando le funzionalità di scalabilità automatica, che consentono di raggiungere gli obiettivi seguenti:

• Ottimizzare l'utilizzo delle risorse e l'efficienza dei costi aumentando o riducendo le prestazioni in base all'utilizzo della CPU e della memoria da parte dei pod.
• Migliorare la tolleranza di errore e il ripristino aggiungendo altri nodi o pod quando si verifica un errore a livello di zona.

È possibile usare HPA (Horizontal Pod Autoscaler) e il componente di scalabilità automatica del cluster per implementare la scalabilità automatica nel servizio Azure Kubernetes. HPA ridimensiona automaticamente il numero di pod in una distribuzione in base alle metriche personalizzate e di altri servizi e all'utilizzo della CPU e della memoria osservati. Cluster Autoscaler regola il numero di nodi in un pool di nodi in base ai pod in sospeso e alle richieste di risorse sui pod in sospeso.

Indicazioni sulla modalità cluster:

• AKS Automatic: concentrarsi su richieste e limiti dei carichi di lavoro, criteri di distribuzione dei pod e controlli delle interruzioni, in modo che il ridimensionamento preconfigurato della piattaforma possa ripristinare il servizio durante condizioni di stress a livello di zona.
• AKS Standard: progettare esplicitamente i confini dei pool di nodi, i criteri di scalabilità e le impostazioni dell'autoscaler in modo che siano allineati ai vincoli di pianificazione consapevole delle zone.

La funzionalità del provider Karpenter del servizio Azure Kubernetes consente il provisioning automatico dei nodi usando Karpenter nel cluster del servizio Azure Kubernetes. Per altre informazioni, vedere la panoramica della funzionalità AKS Karpenter Provider.

Il componente aggiuntivo KEDA (Kubernetes Event-Driven Autoscaling) per il servizio Azure Kubernetes applica la scalabilità automatica basata sugli eventi per dimensionare l'applicazione in base alle metriche dei servizi esterni per soddisfare la domanda. Per altre informazioni, vedere Installare il componente aggiuntivo KEDA nel servizio Azure Kubernetes.

Strategia di scalabilità di zona per modalità del cluster AKS

Per un comportamento di scalabilità verticale basato sulla zona, allinea il modello del pool di nodi ai vincoli dello scheduler e alla modalità del cluster.

Servizio Azure Kubernetes Standard

Quando si usa la scalabilità automatica del cluster con le zone di disponibilità, una procedura consigliata comune è un pool di nodi per zona. È possibile impostare --balance-similar-node-groups su True per mantenere la distribuzione bilanciata dei nodi tra le zone durante l'aumento delle prestazioni.

Perché questo è importante:

• Il componente di scalabilità automatica del cluster simula la pianificazione in base al pool di nodi, non in base alla posizione specifica della zona.
• In un pool di nodi a più zone, la scalabilità orizzontale può posizionare un nuovo nodo in una zona che viola ancora vincoli rigorosi di distribuzione della topologia, lasciando i pod in sospeso.
• Set di scalabilità di macchine virtuali usa il bilanciamento della zona best-effort. Durante vincoli di capacità della zona o eventi di indisponibilità della zona, l'allocazione può avere esito negativo e mandare il pool di nodi in stato di backoff.
• L'uso di un pool di nodi per zona migliora il controllo del comportamento di ridimensionamento specifico della zona.

Il Cluster Autoscaler non tiene conto delle zone e l'allocazione tra zone viene gestita dai set di scalabilità di macchine virtuali sottostanti e non da AKS. La procedura consigliata precedente diventa ancora più rilevante quando si usano vincoli di distribuzione della topologia dei pod basati su zona in un singolo pool di nodi con più zone poiché i vincoli restrittivi possono lasciare i pod in sospeso, soprattutto nelle aree a capacità limitata o in scenari di mancata disponibilità della zona.

AKS Automatico

AKS Automatic usa il comportamento preconfigurato dei nodi gestiti e le impostazioni predefinite per il provisioning automatico dei nodi. Non è possibile presupporre che i carichi di lavoro critici siano resilienti alla zona senza criteri a livello di carico di lavoro.

Per i servizi critici, convalidare:

• Comportamento di distribuzione della topologia dei pod tra le zone.
• Comportamento di ripristino durante la pressione di zona.
• Pianificazione dei risultati quando vengono usati vincoli rigorosi.
• Comportamento dell'applicazione quando una zona diventa non disponibile.

Progettare un'applicazione senza stato

Quando un'applicazione è senza stato, la logica e i dati dell'applicazione vengono separati e i pod non archiviano i dati persistenti o di sessione nei dischi locali. Questa progettazione consente di aumentare o ridurre facilmente le prestazioni dell'applicazione senza preoccuparsi della perdita dei dati. Le applicazioni senza stato sono più resilienti perché, in caso di errore in un nodo, possono essere facilmente sostituite o riprogrammate in un altro nodo.

Quando si progetta un'applicazione senza stato con AKS, è consigliabile usare servizi di Azure gestiti, ad esempio Database di Azure, Redis gestito da Azure o Archiviazione di Azure per archiviare i dati dell'applicazione. L'uso di questi servizi garantisce che il traffico possa essere spostato tra i nodi e le zone senza rischiare di perdere i dati o di compromettere l'esperienza utente. È possibile usare distribuzioni, servizi e probe di integrità di Kubernetes per gestire i pod senza stato e garantire una distribuzione uniforme tra le zone.

Decidere il disco di archiviazione

Scegliere il tipo giusto di disco in base alle esigenze dell'applicazione

Azure offre due tipi di dischi per l'archiviazione permanente: archiviazione con ridondanza locale e archiviazione con ridondanza a livello di zona. L'archiviazione con ridondanza locale replica i dati all'interno di una singola zona di disponibilità. L'archiviazione con ridondanza a livello di zona replica i dati in più zone di disponibilità all'interno di un'area geografica. A partire dalla versione 1.29 del servizio Azure Kubernetes, la classe di archiviazione predefinita usa i dischi di archiviazione con ridondanza a livello di zona per l'archiviazione permanente. Per altre informazioni, vedere Classi di archiviazione predefinite del servizio Azure Kubernetes.

Il modo in cui l'applicazione replica i dati può influenzare la scelta del disco. Se l'applicazione si trova in più zone e replica i dati dall'interno dell'applicazione, è possibile ottenere la resilienza con un disco di archiviazione con ridondanza locale in ogni zona di disponibilità perché, se una zona di disponibilità diventa inattiva, le altre avranno a disposizione i dati più recenti. Se il livello dell'applicazione non gestisce tale replica, i dischi di archiviazione con ridondanza della zona sono una scelta migliore perché Azure gestisce la replica nel livello della risorsa di archiviazione.

La tabella seguente illustra vantaggi e svantaggi di ogni tipo di disco:

Per altre informazioni sui tipi di disco di archiviazione con ridondanza locale e della zona, vedere Ridondanza di Archiviazione di Azure. Per effettuare il provisioning dei dischi di archiviazione nel servizio Azure Kubernetes, vedere Effettuare il provisioning di Archiviazione dischi di Azure nel servizio Azure Kubernetes.

Monitorare le prestazioni dei dischi

Per garantire prestazioni e disponibilità ottimali dei dischi di archiviazione nel servizio Azure Kubernetes, è consigliabile monitorare le metriche chiave, come operazioni di I/O al secondo, velocità effettiva e latenza. Queste metriche consentono di identificare eventuali problemi o colli di bottiglia che potrebbero influire sulle prestazioni dell'applicazione. Se si notano problemi di prestazioni costanti, potrebbe essere necessario riconsiderare il tipo o la dimensione del disco di archiviazione. È possibile usare Monitoraggio di Azure per raccogliere e visualizzare queste metriche e configurare avvisi per ricevere notifiche relative a eventuali problemi di prestazioni.

Per altre informazioni, vedere Monitorare il servizio Azure Kubernetes con Monitoraggio di Azure.

Eseguire test per la resilienza delle zone di disponibilità

Metodo 1: Bloccare e svuotare i nodi in una singola zona di disponibilità

Un modo per testare la resilienza delle zone di disponibilità nel cluster del servizio Azure Kubernetes è quello di svuotare un nodo in una zona e vedere gli effetti sul traffico fino a quando non si verifica un errore in un'altra zona. Questo metodo simula uno scenario reale in cui un'intera zona non è disponibile a causa di un'emergenza o di un'interruzione. Per testare questo scenario, è possibile usare il comando kubectl drain per rimuovere gradualmente tutti i pod da un nodo e contrassegnarlo come non pianificabile. È quindi possibile monitorare il traffico e le prestazioni del cluster usando strumenti come Monitoraggio di Azure o Prometheus.

La tabella seguente illustra vantaggi e svantaggi di questo metodo:

Metodo 2: Simulare un errore della zona di disponibilità con Azure Chaos Studio

Un altro modo per testare la resilienza delle zone di disponibilità nel cluster del servizio Azure Kubernetes è quello di inserire errori nel cluster e osservare l'impatto sull'applicazione usando Azure Chaos Studio. Azure Chaos Studio è un servizio che consente di creare e gestire esperimenti Chaos su risorse e servizi di Azure. È possibile usare Chaos Studio per simulare un errore in una zona di disponibilità creando un esperimento di fault injection per una zona specifica, che arresta o riavvia le macchine virtuali in tale zona. È quindi possibile misurare la disponibilità, la latenza e il tasso di errore dell'applicazione usando metriche e log.

La tabella seguente illustra vantaggi e svantaggi di questo metodo:

Per altre informazioni, vedere Che cos'è Azure Chaos Studio?

Contenuti correlati

• Che cos'è AKS Automatic?
• Guida ai cluster AKS e all'archiviazione con ridondanza della zona