Gestione automatica del Budget di interruzione dei pod in AKS (anteprima)

Durante gli aggiornamenti del cluster AKS, il processo di aggiornamento drena i nodi espellendo i pod, in modo da poter reimpostare l'immagine dei nodi o sostituirli. I Pod Disruption Budgets (PDB) proteggono la disponibilità delle applicazioni durante questo processo limitando il numero di pod che possono essere contemporaneamente non disponibili. Tuttavia, i PDB configurati in modo errato possono anche bloccare completamente lo sfratto oppure i deployment potrebbero non avere repliche sufficienti per rispettare il budget. I deployment del tutto privi di PDB presentano il problema opposto: nulla protegge i pod dall'essere sfrattati contemporaneamente, con il rischio di tempi di inattività durante gli aggiornamenti.

La gestione automatica del database PDB è un'estensione del servizio Azure Kubernetes, basata sul progetto open source, che automatizza la gestione PDB durante gli aggiornamenti. IT:

• Crea automaticamente i PDB per le distribuzioni che non ne hanno una, in modo che i carichi di lavoro siano protetti durante interruzioni volontarie.
• Aumenta temporaneamente le repliche quando un PDB blocca la rimozione di pod in un nodo bloccato, in modo che il budget di interruzione sia soddisfatto e che lo svuotamento possa continuare.
• Riduce nuovamente il numero di repliche una volta completate le eliminazioni, così non paghi maggiore capacità oltre a quella richiesta dall'aggiornamento.

Il risultato è che gli aggiornamenti vengono completati in modo affidabile senza dover forzare le protezioni PDB o risolvere manualmente i nodi in quarantena. Per informazioni di base su come gli aggiornamenti di AKS drenano i nodi e su come i PDB influiscono su tale processo, vedi Come funzionano gli aggiornamenti del cluster AKS.

Quando usare la gestione automatica del database PDB

È consigliabile abilitare la gestione PDB automatica quando:

• Le distribuzioni non dispongono di PDB. I pod vengono rimossi senza garanzie di disponibilità durante gli aggiornamenti, causando potenziali tempi di inattività.
• I PDB bloccano lo svuotamento dei nodi. Un PDB con minAvailable uguale al numero di repliche (o maxUnavailable: 0) impedisce che qualsiasi pod venga sfrattato, causando il fallimento dell'aggiornamento con un errore come Cannot evict pod as it would violate the pod's disruption budget.
• Le repliche non sono sufficienti per il budget di interruzione. Il PDB esiste ed è configurato correttamente, ma la distribuzione non ha un numero sufficiente di repliche per assorbire anche un'eliminazione.
• Si verificano frequenti errori di drain durante l'aggiornamento e si desidera una risoluzione automatica e proattiva anziché una pulizia manuale.

Identificare gli errori di svuotamento correlati a PDB

Prima di abilitare la gestione automatica del PDB, verificare se il cluster riscontra errori di svuotamento correlati al database PDB:

• Log attività di Azure Nel portale di Azure, apri la risorsa del cluster AKS e seleziona Log attività. Individuare le operazioni di aggiornamento non riuscite con stato Failed e i messaggi che fanno riferimento ai budget di interruzione dei pod o a errori di eliminazione.

• Eventi Kubernetes. Eseguire il comando seguente per trovare eventi recenti di rimozione e svuotamento:

  kubectl get events --sort-by='.lastTimestamp' -A | grep -i "disruption\|evict\|drain"
  

  Per una guida completa per lavorare con gli eventi di Kubernetes, consulta eventi di Kubernetes.

Confronto con altre opzioni

Come funziona

La gestione automatica del PDB ha due comportamenti complementari: la creazione automatica del PDB (proattiva) e la scalabilità delle repliche durante lo svuotamento (reattivo).

Creazione automatica PDB

Quando si abilita la creazione automatica PDB (controllerConfig.pdb.create=true), l'estensione controlla continuamente le distribuzioni che non hanno un PDB. L'estensione determina una corrispondenza confrontando il selettore etichette del PDB con le etichette del modello del pod di distribuzione. Questo confronto garantisce che ogni distribuzione sia protetta una sola volta ed eviti pdb duplicati. Quando trova una distribuzione non protetta in uno spazio dei nomi abilitato, crea un PDB. Per le distribuzioni senza HPA o KEDA, minAvailable è impostato sul numero di repliche correnti della distribuzione. Per le distribuzioni che utilizzano HPA o KEDA, minAvailable tiene traccia del numero minimo di repliche dell'autoscaler, così che il comportamento del PDB rimanga allineato ai vincoli dell'autoscaler. L'estensione riconcilia continuamente i PDB creati automaticamente, quindi se il numero di repliche della distribuzione cambia (ad esempio, tramite un aggiornamento manuale o un scaler esterno), il valore del minAvailable database PDB viene aggiornato in modo che corrisponda. Questa protezione garantisce che i pod non vengano eliminati contemporaneamente in caso di interruzioni volontarie.

I PDB creati automaticamente vengono gestiti dall'estensione per tutto il ciclo di vita. Per informazioni dettagliate sulla proprietà, la pulizia e su come assumere il controllo manuale, vedere Proprietà e pulizia PDB.

Ridimensionamento delle repliche durante lo svuotamento

L'estensione monitora il cluster per rilevare situazioni in cui i pod protetti da PDB non possono essere sfrattati durante le operazioni di svuotamento dei nodi. Ecco cosa accade durante un aggiornamento tipico:

1. AKS contrassegna un nodo come non schedulabile nell'ambito del processo di aggiornamento.
2. L'estensione rileva il cordone e verifica se i pod protetti da PDB in tale nodo hanno zero interruzioni consentite.
3. Se il PDB blocca l'eliminazione, l'estensione aumenta temporaneamente il numero di repliche della distribuzione in base al numero di pod protetti da PDB nei nodi delimitati (fino al limite configurato maxSurge della distribuzione), assicurandosi che il picco sia di dimensioni corrette e non si esegue il provisioning eccessivo. Le repliche aggiuntive vengono allocate su altri nodi disponibili.
4. Le interruzioni consentite del PDB diventano maggiori di zero, perché il numero totale di pod integri supera ora la soglia del minAvailable del PDB.
5. Il drenaggio del nodo procede normalmente. L'API di rimozione può ora rimuovere i pod dal nodo bloccato senza violare il PDB.
6. Quando cessano i segnali di eliminazione e il numero di interruzioni consentite supera lo zero, l'estensione riporta la distribuzione al numero originale di repliche. Il ridimensionamento non procederà se sono ancora presenti più nodi o se lo svuotamento è in corso. Questa condizione impedisce un'instabilità non necessaria durante i drenaggi di più nodi. La riduzione delle prestazioni viene eseguita automaticamente dopo un periodo di raffreddamento (60 secondi predefinito) senza interventi manuali necessari.

Coordinamento con i ridimensionatori automatici (HPA e KEDA)

Le distribuzioni sono spesso gestite da un ridimensionamento automatico. Per evitare race condition in cui il ridimensionamento automatico riduce nuovamente la distribuzione prima che le eliminazioni siano completate, l'estensione regola il minimo del ridimensionamento automatico (non solo il numero di repliche) e ripristina la modifica quando lo svuotamento è completato.

Per controllare la vista dell'estensione di una distribuzione, compreso qualsiasi stato Degraded derivante da una configurazione di ridimensionamento automatico non supportata:

kubectl get evictionautoscalers -A -o yaml

Prerequisiti

Prima di installare l'estensione di gestione PDB automatica, assicurarsi di disporre dei seguenti elementi:

• Un cluster AKS che esegue una versione supportata di Kubernetes.
• Carichi di lavoro che utilizzano Deployments. Gli oggetti StatefulSet non sono supportati e l'uso della gestione PDB automatica con StatefulSets non è consigliato.
• interfaccia della riga di comando di Azure versione 2.64.0 o successiva. Eseguire az --version per verificare. Per installare o aggiornare, vedere Installare interfaccia della riga di comando di Azure.
• Il provider Microsoft.KubernetesConfiguration registrato nella tua sottoscrizione.
• Il cluster AKS deve usare una identità gestita (non un'entità servizio). Le estensioni del cluster non funzionano con i cluster basati su service principal. Per altre informazioni, vedi estensioni del cluster AKS.

Autorizzazioni di estensione

L'estensione per la gestione automatica dei PDB richiede autorizzazioni di lettura e scrittura per Deployments, Pod Disruption Budgets ed Events nei namespace che gestisce. L'estensione installa il proprio account di servizio e i ruoli RBAC durante la configurazione. Per l'elenco completo dei ruoli e delle autorizzazioni, vedere il repository di progetti in GitHub.

Registrare il provider di configurazione

Se non hai mai usato prima d'ora le estensioni di Azure Kubernetes, registra il provider richiesto:

az feature register --namespace Microsoft.KubernetesConfiguration --name Extensions

# Verify registration status
az feature show --namespace Microsoft.KubernetesConfiguration --name Extensions

# After the feature shows "Registered", refresh the provider
az provider register -n Microsoft.KubernetesConfiguration

Installare la gestione PDB automatica

La gestione automatica dei PDB è installata come estensione sul cluster AKS. Scegliere un'opzione di installazione in base alle esigenze.

Installazione di base

Installare l'estensione con le impostazioni predefinite. In questa modalità, l'estensione monitora le eliminazioni bloccate dai PDB nello spazio dei nomi kube-system, ma non crea automaticamente PDB per le distribuzione non protette. Il namespace kube-system è incluso per impostazione predefinita perché anche i componenti di sistema gestiti da AKS usano i PDB che possono bloccare lo svuotamento dei nodi durante gli aggiornamenti:

az k8s-extension create \
    --cluster-name <cluster-name> \
    --cluster-type managedClusters \
    --extension-type microsoft.evictionautoscaler \
    --name eviction-autoscaler \
    --resource-group <resource-group-name> \
    --release-train stable \
    --auto-upgrade-minor-version true

Installa con la creazione automatica di PDB per namespace specifici

Attivare la creazione automatica del PDB e specificare quali namespace deve proteggere l'estensione. Questa è la configurazione consigliata per la maggior parte dei cluster:

az k8s-extension create \
    --cluster-name <cluster-name> \
    --cluster-type managedClusters \
    --extension-type microsoft.evictionautoscaler \
    --name eviction-autoscaler \
    --resource-group <resource-group-name> \
    --release-train stable \
    --configuration-settings controllerConfig.pdb.create=true controllerConfig.namespaces.actionedNamespaces="{kube-system,production}" \
    --auto-upgrade-minor-version true

Installa con protezione a livello di cluster

Abilita la creazione automatica di PDB in tutti i namespace:

az k8s-extension create \
    --cluster-name <cluster-name> \
    --cluster-type managedClusters \
    --extension-type microsoft.evictionautoscaler \
    --name eviction-autoscaler \
    --resource-group <resource-group-name> \
    --release-train stable \
    --configuration-settings controllerConfig.pdb.create=true controllerConfig.namespaces.enabledByDefault=true \
    --auto-upgrade-minor-version true

Opzioni di configurazione

Le impostazioni seguenti controllano il comportamento automatico della gestione PDB:

Modelli di configurazione comuni

Controllo del namespace

L'estensione opera in una delle due modalità a seconda dell'impostazione enabledByDefault .

Due controlli complementari regolano i namespace su cui opera l'estensione:

• controllerConfig.namespaces.actionedNamespaces imposta l'elenco di riferimento in fase di installazione ed è il modo più semplice per abilitare un insieme noto di spazi dei nomi.
• L'annotazione del namespace eviction-autoscaler.azure.com/enable (o disable) consente agli operatori del cluster di includere o escludere i namespace in fase di esecuzione senza reinstallare l'estensione.

Modalità di consenso esplicito (impostazione predefinita)

Quando enabledByDefault è false, sono abilitati solo gli spazi dei nomi elencati in actionedNamespaces. È possibile abilitare spazi dei nomi aggiuntivi singolarmente aggiungendo un'annotazione:

apiVersion: v1
kind: Namespace
metadata:
  name: my-namespace
  annotations:
    eviction-autoscaler.azure.com/enable: "true"

Modalità di disattivazione

Quando enabledByDefault è true, tutti i namespace sono abilitati. È possibile escludere namespace specifici aggiungendo un'annotazione:

apiVersion: v1
kind: Namespace
metadata:
  name: my-excluded-namespace
  annotations:
    eviction-autoscaler.azure.com/enable: "false"

Escludere distribuzioni specifiche

Per evitare che l'estensione crei un PDB per una distribuzione specifica, aggiungere l'annotazione seguente alla distribuzione:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-deployment
  annotations:
    eviction-autoscaler.azure.com/pdb-create: "false"

Creazione automatica PDB

Quando controllerConfig.pdb.create è impostato su true, l'estensione crea IDB per le distribuzioni che soddisfano tutti i criteri seguenti:

• La distribuzione non dispone già di un PDB corrispondente.
• La distribuzione è in un namespace abilitato.
• La distribuzione non viene esclusa tramite l'annotazione eviction-autoscaler.azure.com/pdb-create: "false" .

I PDB creati automaticamente vengono impostati minAvailable in base alla fonte di scalabilità del carico di lavoro. Per le distribuzioni senza HPA o KEDA, minAvailable corrisponde al numero di repliche correnti della distribuzione (escluse le repliche di picco aggiunte dall'estensione). Per le distribuzioni con HPA o KEDA, minAvailable corrisponde al numero minimo di repliche configurato nell'autoscaler. Ciò significa che la rimozione viene bloccata fino a quando l'estensione aumenta la distribuzione, a quel punto le repliche aggiuntive soddisfano il budget e consentono lo svuotamento per continuare.

Proprietà del PDB e pulizia

I PDB creati dall'estensione sono contrassegnati con un'annotazione ownedBy: EvictionAutoScaler . Questi PDB di proprietà del controller vengono eliminati automaticamente quando:

• La distribuzione padre viene eliminata.
• Lo spazio dei nomi viene rimosso dall'ambito dell'estensione.
• L'estensione viene rimossa dal cluster. I PDB con l'annotazione ownedBy: EvictionAutoScaler vengono puliti tramite Garbage Collection di Kubernetes.

I PDB creati manualmente non vengono mai modificati o eliminati dall'estensione.

Per assumere il controllo manuale di un PDB creato dall'estensione, rimuovere l'annotazione di proprietà. Dopo aver rimosso questa annotazione, l'estensione non gestisce più il PDB e l'utente è responsabile dell'aggiornamento o dell'eliminazione:

kubectl annotate pdb <pdb-name> -n <namespace> ownedBy-

Verificare l'installazione

Dopo aver installato l'estensione, verificare che la gestione PDB automatica funzioni correttamente.

1. Verifica che i PDB siano stati creati per i deployment nei namespace abilitati. Filtrare per i PDB creati dall'estensione:

   kubectl get pdb -A -o custom-columns=NAME:.metadata.name,NAMESPACE:.metadata.namespace,MIN-AVAILABLE:.spec.minAvailable,OWNER:.metadata.annotations.ownedBy | grep EvictionAutoScaler
   

2. Controllare le risorse personalizzate di gestione PDB automatiche:

   kubectl get evictionautoscalers --all-namespaces
   

3. Eseguire il test con un blocco del nodo (facoltativo). In un ambiente di test o di gestione temporanea, disabilitare un nodo e verificare che l'estensione aumenti le prestazioni della distribuzione e che le interruzioni consentite del PDB aumentino al di sopra dello zero:

   # Cordon a node
   NODE=$(kubectl get pods -n <namespace> -l app=<app-label> -o=jsonpath='{.items[0].spec.nodeName}')
   kubectl cordon $NODE
   
   # Watch for automatic PDB management events
   kubectl get events -n <namespace> --sort-by='.lastTimestamp'
   
   # Check that the deployment scaled up
   kubectl get pods -n <namespace>
   
   # Verify PDB allowed disruptions
   kubectl get poddisruptionbudget <pdb-name> -n <namespace> -o yaml
   
   # After verification, uncordon the node
   kubectl uncordon $NODE
   

Aggiornare o rimuovere l'estensione

Aggiornare la configurazione

Per modificare le impostazioni di configurazione, eliminare e ricreare l'estensione con le nuove impostazioni:

# Delete the existing extension
az k8s-extension delete \
    --resource-group <resource-group-name> \
    --cluster-name <cluster-name> \
    --cluster-type managedClusters \
    --name eviction-autoscaler \
    --yes

# Recreate with new configuration
az k8s-extension create \
    --cluster-name <cluster-name> \
    --cluster-type managedClusters \
    --extension-type microsoft.evictionautoscaler \
    --name eviction-autoscaler \
    --resource-group <resource-group-name> \
    --release-train stable \
    --configuration-settings controllerConfig.pdb.create=true controllerConfig.namespaces.enabledByDefault=true \
    --auto-upgrade-minor-version true

Rimuovere l'estensione

Per disinstallare la gestione automatica del database PDB:

az k8s-extension delete \
    --resource-group <resource-group-name> \
    --cluster-name <cluster-name> \
    --cluster-type managedClusters \
    --name eviction-autoscaler \
    --yes

Limitazioni e considerazioni

• Gli aggiornamenti della configurazione richiedono l'eliminazione e la ricreazione dell'estensione.
• La gestione automatica del database PDB funziona solo con le distribuzioni . Gli statefulSet non sono supportati e l'uso di questa estensione con StatefulSets non è consigliato.
• La gestione automatica dei PDB non sovrascrive né modifica i PDB esistenti. Funziona insieme a loro regolando il numero di repliche.
• La gestione PDB automatica si coordina con un singolo ridimensionamento automatico per distribuzione (HPA o KEDA). Una distribuzione gestita da KEDA e un HPA separato non è supportata; l'estensione contrassegna se stessa Degraded e ignora l'aumento. Vedere Coordinamento con i ridimensionatori automatici (HPA e KEDA).
• La gestione automatica del database PDB è indipendente da impostazioni di aggiornamento del pool di nodi. Non è necessario modificare impostazioni come max-surge, il timeout di svuotamento dei nodi, il tempo di stabilizzazione dei nodi e la strategia di aggiornamento (rolling o blue-green) affinché questa estensione funzioni, e l’estensione non modifica il comportamento di tali impostazioni.
• La scalabilità orizzontale della replica temporanea richiede capacità disponibile nel cluster. Se nessun nodo ha spazio per i pod aggiuntivi, valuta di abilitare il ridimensionamento automatico del cluster o il provisioning automatico dei nodi (NAP) in modo da poter eseguire il provisioning di nuovi nodi.

Troubleshooting

Per i sintomi, le cause e le risoluzioni, vedere l'hub di risoluzione dei problemi del servizio Azure Kubernetes: Risolvere i problemi servizio Azure Kubernetes.

Per esaminare l'attività dell'estensione direttamente nel cluster, eseguire:

kubectl get evictionautoscalers -A -o yaml
kubectl get events -A --sort-by='.lastTimestamp'

Contenuti correlati

• Opzioni di aggiornamento e raccomandazioni : include scenario 2: errori di svuotamento dei nodi e PDB, con più opzioni di risoluzione.
• Come funzionano gli aggiornamenti del cluster AKS: illustra il processo di aggiornamento progressivo, fase per fase, e cosa accade quando un PDB blocca il drain di un nodo.
• Procedure consigliate per i budget di interruzione dei pod : indicazioni sulla configurazione dei PDB per la disponibilità elevata.
• Documentazione di Kubernetes: Pod Disruption Budget — riferimento upstream del PDB.
• Progetto di gestione PDB automatico su GitHub: codice sorgente e riferimento tecnico dettagliato.