Procedure consigliate per le funzionalità di base dell'utilità di pianificazione nel servizio Azure Kubernetes (AKS)

Quando si gestiscono i cluster nel servizio Azure Kubernetes (AKS), spesso è necessario isolare i team e i carichi di lavoro. L'utilità di pianificazione Kubernetes consente di controllare la distribuzione delle risorse di calcolo e limitare l'impatto degli eventi di manutenzione.

Questo articolo sulle procedure consigliate è incentrato sulle funzionalità di pianificazione di base di Kubernetes per gli operatori del cluster. In questo articolo vengono illustrate le operazioni seguenti:

Applicare le quote di risorse

Linee guida sulle pratiche ottimali

Pianificare e applicare quote di risorse a livello di spazio dei nomi. Usare quote e intervalli di limiti per richiedere o fornire richieste di risorse e limiti predefiniti per i pod. Monitorare l'utilizzo delle risorse e modificare le quote in base alle esigenze.

Impostare le richieste di risorse e i limiti delle risorse nella specifica del pod. Una richiesta di risorsa è la quantità di CPU o memoria usata dall'utilità di pianificazione Kubernetes per inserire un pod. Un limite di risorse vincola la quantità di tale risorsa che può essere usata da un contenitore. Il sistema applica i limiti della CPU tramite la limitazione, mentre applica limiti di memoria in modo reattivo attraverso la terminazione OOM (Out-of-Memory). Per altre informazioni, vedere Definire le richieste e i limiti delle risorse dei pod.

Usare le quote di risorse per limitare l'utilizzo aggregato delle risorse per un team di sviluppo o un progetto. Definire le quote a livello di spazio dei nomi per:

• Risorse di calcolo, come CPU e memoria o le GPU.
• Risorse di archiviazione, che includono il numero totale di volumi o la quantità di spazio su disco per una classe di archiviazione specificata.
• Numero di oggetti, ad esempio il numero massimo di segreti, servizi o processi che è possibile creare.

L'utilità di pianificazione Kubernetes usa le richieste di risorse per inserire i pod. I contenitori possono usare più CPU o memoria di quanto richiesto quando la capacità è disponibile e i limiti delle risorse possono superare le richieste. Una quota di risorse limita separatamente l'utilizzo dello spazio dei nomi aggregato. Se la creazione o l'aggiornamento di una risorsa supera una quota rigida, il server API rifiuta la richiesta con una risposta HTTP 403 Forbidden . È comunque possibile creare un oggetto carico di lavoro, ad esempio una distribuzione, anche quando la quota impedisce al controller di creare tutti i pod richiesti.

Se una quota di risorse tiene traccia della CPU o della memoria, ogni nuovo pod deve specificare una richiesta o un limite per tale risorsa. In caso contrario, il server API potrebbe rifiutare il pod. È possibile configurare richieste e limiti predefiniti per uno spazio dei nomi usando un oggetto LimitRange.

L'esempio di manifesto YAML seguente denominato dev-app-team-quotas.yaml imposta un limite rigido di un totale di 10 CPU, 20Gi di memoria e 10 pod:

apiVersion: v1
kind: ResourceQuota
metadata:
  name: dev-app-team
spec:
  hard:
    cpu: "10"
    memory: 20Gi
    pods: "10"

Questa quota consente di aggregare le richieste CPU a 10 CPU, aggregare le richieste di memoria a 20Gi e il numero di pod non determiniali a 10 nello spazio dei nomi.

Applicare questa quota di risorse a uno spazio dei nomi, ad esempio dev-apps:

kubectl apply -f dev-app-team-quotas.yaml --namespace dev-apps

Contattare gli sviluppatori e i proprietari delle applicazioni per comprenderne le esigenze e applicare le quote di risorse appropriate.

Per altre informazioni sugli oggetti risorsa disponibili, gli ambiti e le priorità, vedere Resource quotas in Kubernetes (Quote di risorse in Kubernetes).

Limitare l'impatto sulle interruzioni usando i budget di interruzione dei pod (PDB)

Linee guida sulle pratiche ottimali

Definire i budget di interruzione dei pod (PDB) per le applicazioni replicate per limitare le eliminazioni volontarie simultanee durante eventi come lo svuotamento dei nodi del servizio Azure Kubernetes. Mantenere repliche integre sufficienti e consentire almeno un'interruzione quando il carico di lavoro consente di continuare la manutenzione del cluster.

Gli eventi di interruzione che rimuovono i pod rientrano in due categorie:

Interruzioni involontarie

Le interruzioni involontarie sono eventi che esulano dal controllo dell'operatore del cluster o del proprietario dell'applicazione. Ecco alcuni esempi:

• Errore hardware nel computer fisico
• Kernel panic
• Eliminazione di una macchina virtuale del nodo

È possibile ridurre le interruzioni involontarie in base a:

• Utilizzo di più repliche dei pod in una distribuzione.
• Esecuzione di più nodi nel cluster AKS.

Interruzioni volontarie

_ I disruptions_ volontari sono eventi che l'operatore del cluster o il proprietario dell'applicazione richiede. Ecco alcuni esempi:

• Svuotamento di un nodo durante un aggiornamento del cluster
• Aggiornamento di un modello di distribuzione
• Eliminazione diretta di un pod

Non tutte le interruzioni volontarie sono vincolate dai PDB. L'eliminazione diretta di un oggetto pod o carico di lavoro ignora i PDB e i controller del carico di lavoro, ad esempio distribuzioni e set di stato, non sono limitati dai PDB durante gli aggiornamenti in sequenza. Configurare separatamente la strategia di implementazione del carico di lavoro per mantenere la disponibilità durante gli aggiornamenti dell'applicazione. Per altre informazioni, vedere Interruzioni in Kubernetes.

I PDB limitano le eliminazioni volontarie simultanee per i pod selezionati tramite l'API di rimozione di Kubernetes. Durante un aggiornamento in sequenza del servizio Azure Kubernetes, il servizio Azure Kubernetes aggiunge capacità di aumento in base alle impostazioni del pool di nodi, ai cordoni e svuota un nodo e quindi ricrea o sostituisce il nodo svuotato. L'API di rimozione valuta il PDB durante lo svuotamento. Dopo una rimozione, il controller del carico di lavoro crea un pod sostitutivo e l'utilità di pianificazione la inserisce in un nodo con capacità disponibile. Un PDB restrittivo, repliche integre insufficienti o capacità del cluster insufficiente può ritardare o bloccare lo svuotamento.

Impostare un numero minimo di pod disponibili

Si consideri un oggetto ReplicaSet con cinque pod NGINX etichettati.app: nginx-frontend Durante un evento di interruzione volontaria, ad esempio un aggiornamento del cluster, almeno tre pod devono rimanere disponibili. Il manifesto seguente PodDisruptionBudget definisce questo requisito:

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: nginx-pdb
spec:
  minAvailable: 3
  unhealthyPodEvictionPolicy: AlwaysAllow
  selector:
    matchLabels:
      app: nginx-frontend

Questo budget richiede almeno tre pod con etichetta app: nginx-frontend per rimanere integri durante una rimozione volontaria.

È possibile specificare una percentuale, ad esempio 60%, in modo che il budget venga modificato quando il set di repliche viene ridimensionato.

Impostare un numero massimo di pod non disponibili

Un PDB può definire o minAvailablemaxUnavailable, ma non entrambi. Per vincolare le eliminazioni volontarie in base a pod non disponibili, specificare maxUnavailable come numero intero o percentuale. Il manifesto seguente consente una rimozione volontaria solo quando non più di due pod in ReplicaSet non saranno disponibili dopo la rimozione:

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: nginx-pdb
spec:
  maxUnavailable: 2
  unhealthyPodEvictionPolicy: AlwaysAllow
  selector:
    matchLabels:
      app: nginx-frontend

Questo bilancio consente una rimozione volontaria solo quando non più di due pod con l'etichetta app: nginx-frontend non sarebbe disponibile dopo la rimozione. Le interruzioni involontarie possono comunque causare un calo della disponibilità al di sotto di questa soglia.

Il AlwaysAllow criterio di rimozione dei pod non integri consente di rimuovere i pod in esecuzione che non sono integri. Senza questa impostazione, i criteri predefiniti IfHealthyBudget possono bloccare uno svuotamento durante l'attesa che i pod non integri diventino integri. Usare AlwaysAllow quando la svuotabilità è più importante rispetto a un pod non integro più tempo per il ripristino.

Salvare il manifesto PDB che si vuole usare come nginx-pdb.yaml e quindi applicarlo al cluster del servizio Azure Kubernetes:

kubectl apply -f nginx-pdb.yaml

Prima della manutenzione del cluster, verificare che ogni PDB consenta la rimozione prevista:

kubectl get poddisruptionbudgets --namespace <namespace>

Un ALLOWED DISRUPTIONS valore di 0 può bloccare lo svuotamento di un nodo del servizio Azure Kubernetes. Collaborare con gli sviluppatori e i proprietari dell'applicazione per mantenere repliche sufficienti e scegliere un budget che bilancia la disponibilità delle applicazioni con i requisiti di manutenzione.

Per altre informazioni sull'uso dei budget di interruzione dei pod, vedere Specify a disruption budget for your application (Specificare un budget di interruzione per l'applicazione).

Contenuti correlati

Questo articolo è incentrato sulle funzionalità di base dell'utilità di pianificazione kubernetes. Per altre informazioni sulle operazioni del cluster nel servizio Azure Kubernetes, vedere gli articoli sulle procedure consigliate seguenti:

• Isolamento cluster e multi-tenant
• Funzionalità avanzate dell'utilità di pianificazione di Kubernetes
• Autenticazione e autorizzazione