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

  • Articolo

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 o di 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:

  • Usare le quote di risorse per fornire una quantità fissa di risorse ai team o ai carichi di lavoro
  • Limitare l'impatto della manutenzione pianificata mediante i budget di interruzione dei pod

Applicare le quote di risorse

Materiale sussidiario sulle procedure consigliate

Pianificare e applicare quote di risorse a livello di spazio dei nomi. Se i pod non definiscono le richieste di risorse e i limiti, rifiutare la distribuzione. Monitorare l'utilizzo delle risorse e modificare le quote in base alle esigenze.

Le richieste di risorse e i limiti vengono inseriti nella specifica del pod. Le richieste vengono usate dall'utilità di pianificazione Kubernetes in fase di distribuzione per trovare un nodo disponibile nel cluster. I limiti e le richieste funzionano a livello di singolo pod. Per altre informazioni su come definire questi valori, vedere Definire le richieste di risorse e i limiti del pod.

Per riservare e limitare le risorse in un progetto o in un team di sviluppo, è consigliabile usare le quote di risorse. Queste quote sono definite in uno spazio dei nomi e possono essere usate per impostare le quote in base agli elementi seguenti:

  • 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.
  • Conteggio oggetti, come il numero massimo di segreti, servizi o processi che è possibile creare.

Kubernetes non esegue l'overcommit delle risorse. Quando il totale della richiesta di risorse cumulativa supera la quota assegnata, tutte le altre distribuzioni avranno esito negativo.

Quando si definiscono le quote di risorse, tutti i pod creati nello spazio dei nomi devono fornire limiti o richieste nelle relative specifiche dei pod. Se questi valori non vengono forniti, è possibile rifiutare la distribuzione. In alternativa, è possibile configurare richieste e limiti predefiniti per uno spazio dei nomi.

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 di risorse può essere applicata specificando lo 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).

Pianificare la disponibilità tramite i budget di interruzione dei pod

Materiale sussidiario sulle procedure consigliate

Per mantenere la disponibilità delle applicazioni, definire i budget di interruzione dei pod per assicurarsi che nel cluster siano disponibili un numero minimo di pod.

Esistono due eventi che comportano interruzioni che causano la rimozione dei pod:

Interruzioni involontarie

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

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

Le interruzioni involontarie possono essere attenuate da:

  • Uso di più repliche dei pod in una distribuzione.
  • Esecuzione di più nodi nel cluster del servizio Azure Kubernetes.

Interruzioni volontarie

Le interruzioni volontarie sono eventi richiesti dall'operatore del cluster o dal proprietario dell'applicazione. Includere:

  • Aggiornamenti del cluster
  • Modello di distribuzione aggiornato
  • Eliminazione accidentale di un pod

Kubernetes fornisce budget di interruzione dei pod per interruzioni volontarie, consentendo di pianificare la risposta delle distribuzioni o dei set di repliche quando si verifica un evento di interruzione volontaria. Usando i budget di interruzione dei pod, gli operatori del cluster possono definire un numero minimo di risorse disponibile o massimo non disponibile.

Se si aggiorna un cluster o si aggiorna un modello di distribuzione, l'utilità di pianificazione kubernetes pianifica i pod aggiuntivi in altri nodi prima di consentire la continuazione degli eventi di interruzione volontaria. L'utilità di pianificazione attende il riavvio di un nodo fino a quando il numero definito di pod non viene pianificato correttamente in altri nodi del cluster.

Verrà ora preso in esame un set di repliche con cinque pod che eseguono NGINX. Ai pod nel set di repliche viene assegnata l'etichetta app: nginx-frontend. Durante un evento di interruzione volontaria, ad esempio un aggiornamento del cluster, ci si vuole assicurare che almeno tre pod continuino a essere eseguiti. Il manifesto YAML seguente per un oggetto PodDisruptionBudget definisce questi requisiti:

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

È anche possibile definire una percentuale, ad esempio 60%, che consente di compensare automaticamente il ridimensionamento del numero di pod nel set di repliche.

È possibile definire un numero massimo di istanze non disponibili in un set di repliche. Anche in questo caso, può essere definita una percentuale per il numero massimo di pod non disponibili. Il manifesto YAML seguente per il budget di interruzione dei pod definisce che non più di due pod nel set di repliche possono essere non disponibili:

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

Dopo che il budget di interruzione dei pod è stato definito, viene creato nel cluster servizio Azure Kubernetes come qualsiasi altro oggetto di Kubernetes:

kubectl apply -f nginx-pdb.yaml

Contattare gli sviluppatori e i proprietari delle applicazioni per comprenderne le esigenze e applicare i budget di interruzione dei pod appropriati.

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).

Passaggi successivi

Questo articolo ha illustrato le funzionalità di base dell'utilità di pianificazione di Kubernetes. Per altre informazioni sulle operazioni cluster in servizio Azure Kubernetes, vedere le procedure consigliate seguenti: