Ottimizzare i costi e l'utilizzo del servizio Azure Kubernetes

Questo articolo descrive i modi pratici per ottimizzare l'utilizzo e i costi di Servizio Azure Kubernetes (AKS) in termini di scalabilità, dimensionamento dell'infrastruttura, utilizzo della GPU, multi-tenancy e sconti Azure.

Per la maggior parte dei carichi di lavoro di produzione, AKS Automatic è il punto di partenza consigliato perché applica configurazioni predefinite adatte agli ambienti di produzione, automatizza le operazioni fondamentali e contribuisce a ridurre la sovraallocazione delle risorse. AKS Standard resta la scelta giusta quando serve una personalizzazione più avanzata della piattaforma.

Questo articolo tratta:

Scegliere la baseline di ottimizzazione

Inizia selezionando la modalità del cluster AKS più adatta al tuo modello di costi e operativo.

Scenario Modalità cluster consigliata Perché
La maggior parte dei carichi di lavoro di produzione in cui si vuole una forte efficienza dei costi con un sovraccarico operativo inferiore AKS Automatico Le impostazioni predefinite preconfigurate per l'ambiente di produzione, le operazioni gestite e l'allocazione efficiente delle risorse consentono di ridurre gli sprechi e il tempo impiegato per ottimizzare la piattaforma.
Carichi di lavoro che richiedono una configurazione estesa del cluster personalizzato, componenti aggiuntivi specializzati o controlli rigidi della piattaforma Servizio Azure Kubernetes Standard Controllo completo sulla configurazione del cluster e sul modello operativo.
Team agli inizi del percorso di maturità operativa in Kubernetes e incentrati su rilasci rapidi e prevedibili AKS Automatico Riduce la complessità della gestione della piattaforma in modo che i team possano concentrarsi sulle applicazioni.
Team con processi di progettazione della piattaforma stabiliti e standard architetturali specifici Servizio Azure Kubernetes Standard Supporta la personalizzazione avanzata e i modelli operativi personalizzati.

Per ulteriori informazioni, vedi Che cos'è Servizio Azure Kubernetes (AKS) Automatic?

Vantaggi automatici in termini di costi di AKS

AKS Automatic riduce i costi in due modi: riduce al minimo gli sprechi di risorse di calcolo tramite l'automazione e riduce il sovraccarico operativo della gestione di Kubernetes. La tabella seguente riepiloga le funzionalità che hanno un impatto diretto sui costi e il modo in cui vengono confrontate con il servizio Azure Kubernetes Standard.

Le funzionalità preconfigurate sono sempre abilitate e non possono essere modificate. Le funzionalità predefinite sono configurate automaticamente, ma possono essere modificate. Le funzionalità facoltative sono disponibili per la configurazione e non sono abilitate per impostazione predefinita.

Feature AKS Automatico Servizio Azure Kubernetes Standard Impatto sui costi
Provisioning automatico dei nodi Preconfigurato Facoltativo Effettuare automaticamente il provisioning di nodi dimensionati correttamente per i pod in sospeso, riducendo la capacità inattiva e con provisioning eccessivo.
Controller di scalabilità automatica orizzontale dei pod (HPA) Preconfigurato Facoltativo Ridimensiona i pod in modo che corrispondano alla domanda senza intervento manuale, impedendo lo spreco di risorse a basso traffico.
Scalabilità automatica guidata dagli eventi di Kubernetes (KEDA) Preconfigurato Facoltativo Il ridimensionamento guidato dagli eventi elimina le repliche inattive in attesa di lavoro.
Vertical Pod Autoscaler (VPA) - Scalabilità automatica verticale dei pod Preconfigurato Facoltativo Ridimensiona automaticamente le richieste e i limiti delle risorse dei pod in base all'utilizzo effettivo nel tempo.
Efficienza di compressione nei contenitori dei pod Preconfigurato Regolazione manuale I pod sono compressi nei contenitori in modo efficiente per ottimizzare l'utilizzo dei nodi, riducendo il numero totale di nodi necessario.
Prometheus gestito + Informazioni dettagliate sui contenitori Predefinita Facoltativo Offre visibilità immediata dei costi dal primo giorno senza richiedere la configurazione dell'osservabilità.
Aggiornamenti automatici del sistema operativo del cluster e del nodo Preconfigurato Manuale o facoltativo Elimina il sovraccarico di progettazione correlato all'aggiornamento e riduce il rischio di incidenti di sicurezza costosi da nodi senza patch.
Ripristino automatico dei nodi Preconfigurato Preconfigurato Riduce i costi dovuti ai tempi di inattività causati da nodi malfunzionanti senza intervento manuale.
Gruppo di risorse del nodo completamente gestito Preconfigurato Blocco facoltativo Impedisce modifiche accidentali o non autorizzate alle risorse che possono generare costi imprevisti.
SLA di disponibilità (server API al 99,95%) Incluso Pagato (passaggio al piano Standard) Senza costi aggiuntivi per ottenere una garanzia di operatività supportata da impegni economici.
Contratto di servizio per la preparazione dei pod (99,9% entro 5 minuti) Incluso Non disponibile Comportamento prevedibile della scalabilità senza investimenti personalizzati per l'affidabilità.

Annotazioni

Poiché gli strumenti di scalabilità come HPA, KEDA e VPA sono preconfigurati in AKS Automatic, i team non devono sostenere i costi di configurazione, test e manutenzione necessari per configurare autonomamente queste funzionalità. In AKS Standard, ognuna di queste funzionalità richiede la configurazione manuale e l'ottimizzazione continua.

Scalabilità automatica

Scalabilità automatica orizzontale dei pod

Horizontal Pod Autoscaler (HPA) monitora la domanda di risorse e aggiorna automaticamente una risorsa del carico di lavoro per ridimensionare il numero di pod in base alla domanda. La risposta al maggiore carico consiste nel distribuire più pod. Se il carico diminuisce e il numero di pod è superiore al valore minimo configurato, il componente per il ridimensionamento automatico indica alla risorsa del carico di lavoro di ridurre il numero di pod.

L'API Metriche ottiene i dati dal kubelet ogni 60 secondi e HPA controlla l'API delle metriche ogni 15 secondi per eventuali modifiche necessarie per impostazione predefinita. Ciò significa che l'HPA viene aggiornato ogni 60 secondi. Quando si configura HPA per una distribuzione, si definisce il numero minimo e massimo di repliche che possono essere eseguite e le metriche usate dall'HPA per determinare quando ridimensionare.

Tip

In AKS Automatic, HPA è preconfigurato e pronto per l'uso senza alcuna configurazione aggiuntiva. In AKS Standard, si configura manualmente HPA per ogni carico di lavoro.

Per ulteriori informazioni, vedere Scalabilità automatica orizzontale dei pod e Scalabilità automatica dei pod in AKS.

Scalabilità automatica guidata dagli eventi Kubernetes

Kubernetes Event-driven Autoscaler (KEDA) applica la scalabilità automatica guidata dagli eventi ai carichi di lavoro. KEDA funziona con HPA e può estendere le funzionalità senza sovrascrivere o duplicazione.

Tip

In AKS Automatic, KEDA è preconfigurato e abilitato nel cluster. In AKS Standard, il componente aggiuntivo KEDA viene installato e configurato manualmente.

È possibile usare il componente aggiuntivo KEDA per il servizio Azure Kubernetes (AKS) per ridimensionare le applicazioni e sfruttare un ricco catalogo di scaler KEDA di Azure. Per ulteriori informazioni, vedere Scalabilità automatica delle applicazioni con il componente aggiuntivo KEDA e Installare il componente aggiuntivo KEDA per AKS.

Scalabilità automatica verticale dei pod

Vertical Pod Autoscaler (VPA) imposta automaticamente le richieste di risorse e i limiti per i contenitori per carico di lavoro in base all'utilizzo passato. La VPA libera CPU e memoria per i pod in modo da garantire un utilizzo efficace dei cluster del servizio Azure Kubernetes. Nel corso del tempo, la vpa fornisce raccomandazioni per l'utilizzo delle risorse.

Tip

In AKS Automatic, VPA è preconfigurata e abilitata nel cluster. In AKS Standard è possibile abilitare e configurare manualmente VPA.

Per altre informazioni, vedere Scalabilità automatica verticale dei pod nel servizio Azure Kubernetes e Usare il Vertical Pod Autoscaler (VPA) nel servizio Azure Kubernetes.

Ridimensionamento corretto del cluster

Dimensiona correttamente il tuo cluster

Dimensioni corrette dei cluster per ottimizzare i costi e le prestazioni. Ridimensionare manualmente un cluster aggiungendo o rimuovendo nodi per soddisfare le esigenze delle applicazioni. È anche possibile ridimensionare automaticamente il cluster per regolare automaticamente il numero di nodi in risposta alle esigenze mutevoli.

Tip

AKS Automatic abilita Managed Prometheus e Container Insights per impostazione predefinita, offrendoti visibilità immediata sull'utilizzo delle risorse fin dal primo giorno. In AKS Standard è possibile configurare separatamente l'osservabilità. Una visibilità tempestiva consente di intervenire sui segnali di sovradimensionamento prima che si accumulino in sprechi continui.

Per altre informazioni, vedere Ridimensionare i cluster del servizio Azure Kubernetes.

La scalabilità automatica del cluster

Usando il ridimensionamento automatico del cluster, è possibile ridimensionare automaticamente i pool di nodi in base all'utilizzo e ai vincoli delle risorse. Ad esempio, aumentare per programmare i pod in sospeso o ridurre per diminuire i costi dei nodi inutilizzati. Il profilo di scalabilità automatica del cluster è un set di parametri che è possibile ottimizzare per controllare il comportamento del ridimensionamento automatico del cluster.

Per altre informazioni, vedere Panoramica della scalabilità automatica del cluster nel servizio Azure Kubernetes e Usare il ridimensionamento automatico del cluster nel servizio Azure Kubernetes.

Provisioning automatico dei nodi

Il provisioning automatico dei nodi basato su Karpenter effettua il provisioning dell'infrastruttura di dimensioni corrette per i pod in sospeso e migliora l'efficienza di compressione dei contenitori.

  • Nel servizio Azure Kubernetes automatico, il provisioning automatico dei nodi fa parte dell'esperienza gestita.
  • In AKS Standard, il provisioning automatico dei nodi è disponibile quando serve questa funzionalità con un modello di cluster personalizzato.

Per altre informazioni, vedere Provisioning automatico dei nodi in Servizio Azure Kubernetes (AKS).

Ottimizzazioni GPU

Partizionamento e condivisione GPU

Il partizionamento GPU consente di combattere la sottoutilizzazione suddividendo o condividendo GPU tra più carichi di lavoro. Le sezioni seguenti illustrano diversi modi per partizionare e condividere GPU nel servizio Azure Kubernetes.

Time-slicing

L'operatore GPU NVIDIA abilita il time-slicing delle GPU nei cluster Kubernetes. Usando il time-slicing, un amministratore di sistema può definire un set di repliche per una GPU, ognuna delle quali l'amministratore può distribuire in modo indipendente a un pod per eseguire i carichi di lavoro. È possibile applicare configurazioni predefinite per il timelicing a livello di cluster e configurazioni specifiche del nodo.

Screenshot di un esempio di grafico visivo che mostra il time-slicing della GPU.

Per altre informazioni vedere Time-slicing di GPU in Kubernetes.

Servizio multiprocessore (MPS)

Un singolo processo potrebbe non usare tutta la capacità di memoria e larghezza di banda di calcolo disponibile in una GPU. Il servizio Multi-Process (MPS) consente il partizionamento logico delle risorse di memoria e di calcolo tra carichi di lavoro. Consente anche alle operazioni kernel e memcopy di processi diversi di sovrapporsi alla GPU. MPS consente di ottenere un utilizzo più elevato della GPU e tempi di esecuzione più brevi.

Screenshot di un esempio di grafico visivo che mostra il servizio multiprocessore GPU (MPS).

Per altre informazioni, vedere Multi-Process Service (MPS).

GPU multi-istanza (MIG)

Le GPU a più istanze consentono di partizionare GPU in base alle architetture NVIDIA Ampere e successive in istanze GPU separate e sicure per le applicazioni CUDA.

Screenshot di un esempio di grafico visivo che mostra GPU a istanze multiple (MIGs).

Per altre informazioni, vedere Operatore GPU con MIG e Creare un pool di nodi GPU a istanze multipla nel servizio Azure Kubernetes.

Multi-tenancy

La multi-tenancy si riferisce alla condivisione dell'infrastruttura tra tenant, team e business unit. La tabella seguente illustra diversi modi per implementare il multi-tenant in AKS.

Tipo di multi-tenancy Livello di multi-tenancy Densità dei pod del cluster Allocazione costi Caso d'uso ideale Potenziali rischi
Cluster dedicato Multi-tenancy hard inferiore Il più facile Completi limiti di isolamento della sicurezza e una semplice allocazione dei costi • La proliferazione del cluster su larga scala aggiunge ai costi di gestione generali
• Densità dei pod inferiore e più risorse con provisioning eccessivo
Pool di nodi dedicato Multi-tenancy soft Medium Medium Densità media dei pod • Richiede l'attendibilità tra tenant
• Richiede configurazioni cluster aggiuntive, ad esempio criteri di rete, gestione delle quote, controllo degli accessi in base al ruolo e così via.
Spazio dei nomi dedicato Multi-tenancy soft Maggiore Più difficile Condivisione dell'infrastruttura per ottimizzare l'utilizzo delle risorse • Non sicuro per gli ambienti ostili per impostazione predefinita
• Richiede configurazioni cluster aggiuntive, ad esempio criteri di rete, gestione delle quote, controllo degli accessi in base al ruolo e così via.

Cluster dedicato

Con l'architettura multi-tenancy di cluster dedicati, i cluster sono dedicati a un singolo carico di lavoro o team.

Screenshot di un esempio di grafico che mostra l'architettura multi-tenancy di cluster dedicati.

La tabella seguente illustra vantaggi e svantaggi dell'uso di un cluster dedicato:

Pros Svantaggi
• Metodo di isolamento più semplice
• Semplice allocazione dei costi e addebiti
• Ottimo per i casi in cui i tenant non si fidano tra loro (spesso dalle prospettive di sicurezza e condivisione delle risorse)
• Gestione elevata e sovraccarico finanziario
• Generalmente bassa densità di pod e risorse sovrapprovisionate

Pool di nodi dedicato

Con l'architettura multi-tenancy di pool di nodi dedicati, i cluster vengono condivisi da molti tenant.

Screenshot di un esempio di grafico che mostra l'architettura multi-tenancy di pool di nodi dedicati.

La tabella seguente illustra vantaggi e svantaggi dell'uso di un pool di nodi dedicato:

Pros Svantaggi
• Densità media dei pod
• Alcune infrastrutture condivise
• Applicare tag di Azure ai pool di nodi dedicati a un singolo tenant (i tag vengono propagati ai nodi e resi persistenti tramite gli aggiornamenti)
• Richiede l'attendibilità tra i tenant
• Richiede configurazioni cluster aggiuntive, ad esempio criteri di rete, gestione delle quote, controllo degli accessi in base al ruolo e così via.

Spazio dei nomi dedicato

Con l'architettura multi-tenancy di spazi dei nomi dedicati, i cluster vengono condivisi da molti tenant, con gli spazi dei nomi che fungono da limite di isolamento.

Screenshot di un esempio di grafico che mostra l'architettura multi-tenancy di spazi dei nomi dedicati.

La tabella seguente illustra vantaggi e svantaggi dell'uso di uno spazio dei nomi dedicato:

Pros Svantaggi
• Maggiore densità di pod
• Bin packing migliore
• Condivisione dell'infrastruttura per ottimizzare l'utilizzo delle risorse
• Non sicuro per gli ambienti ostili per impostazione predefinita
• Richiede misure di sicurezza aggiuntive se non è possibile considerare attendibili tutti i tenant

Sconti di Azure

Per risparmiare ulteriormente, sfruttare gli sconti di Azure, ad esempio Piani di risparmio di Azure, Istanze riservate e Vantaggi di Azure Hybrid.

Tipo di sconto di Azure dettagli
Piani di risparmio di Azure • Impegno iniziale di 1-3 anni
• Risparmiare fino a 65% rispetto al pagamento in base al consumo
• Flessibile, senza restrizioni relative alla famiglia di SKU o all'area geografica
• Ideale per i carichi di lavoro con costi coerenti e risorse in vari SKU e regioni.
Istanze riservate • Impegno iniziale di 1-3 anni
• Risparmiare fino a 72% rispetto al pagamento in base al consumo
• Limitato a specifiche famiglie di SKU e aree geografiche
• Ideale per carichi di lavoro stabili in esecuzione in modo continuo (senza modifiche impreviste di SKU o area)
Vantaggi di Azure Hybrid • Usare licenze di Windows Server e SQL Server locali in Azure
• Usare tutte le licenze locali idonee che dispongono di una sottoscrizione software assurance (SA) attiva o idonea

Per altre informazioni sui costi di AKS e su AKS Automatic, vedere gli articoli seguenti: