Condividi tramite

Procedure consigliate per prestazioni e scalabilità per carichi di lavoro di piccole e medie dimensioni nel servizio Azure Kubernetes

  • Articolo

Nota

Questo articolo è incentrato sulle procedure consigliate generali per carichi di lavoro di piccole e medie dimensioni. Per le procedure consigliate specifiche per carichi di lavoro di grandi dimensioni, vedere Procedure consigliate per prestazioni e scalabilità per carichi di lavoro di grandi dimensioni nel servizio Azure Kubernetes.

Durante la distribuzione e la gestione dei cluster nel servizio Azure Kubernetes, è possibile usare le procedure consigliate seguenti per ottimizzare le prestazioni e la scalabilità.

Questo articolo contiene informazioni relative agli argomenti seguenti:

  • Compromessi e raccomandazioni per la scalabilità automatica dei carichi di lavoro.
  • Gestione della scalabilità e dell'efficienza dei nodi in base alle esigenze del carico di lavoro.
  • Considerazioni sulla rete per il traffico in ingresso e in uscita.
  • Monitoraggio e risoluzione dei problemi relativi al piano di controllo e alle prestazioni dei nodi.
  • Pianificazione della capacità, scenari di picco e aggiornamenti del cluster.
  • Considerazioni sull'archiviazione e sulla rete per le prestazioni del piano dati.

Scalabilità automatica delle applicazioni e scalabilità automatica dell'infrastruttura

Scalabilità automatica delle applicazioni

La scalabilità automatica delle applicazioni è utile quando si gestiscono l'ottimizzazione dei costi o le limitazioni dell'infrastruttura. Un'utilità di scalabilità automatica ben configurata mantiene la disponibilità elevata per l'applicazione riducendo al contempo i costi. Si paga solo per le risorse necessarie per mantenere la disponibilità, indipendentemente dalla domanda.

Ad esempio, se un nodo esistente ha spazio ma non abbastanza indirizzi IP nella subnet, potrebbe essere possibile ignorare la creazione di un nuovo nodo e avviare immediatamente l'esecuzione dell'applicazione in un nuovo pod.

Scalabilità automatica orizzontale dei pod

L'implementazione della scalabilità automatica orizzontale dei pod è utile per le applicazioni con una domanda di risorse costante e prevedibile. La scalabilità automatica orizzontale dei pod (HPA) ridimensiona in modo dinamico il numero di repliche pod, che distribuisce efficacemente il carico tra più pod e nodi. Questo meccanismo di ridimensionamento è in genere più vantaggioso per le applicazioni che possono essere scomposte in componenti più piccoli e indipendenti, in grado di essere eseguiti in parallelo.

HPA fornisce le metriche di utilizzo delle risorse per impostazione predefinita. È anche possibile integrare metriche personalizzate o sfruttare strumenti come Scalabilità automatica guidata dagli eventi di Kubernetes (KEDA) (anteprima). Queste estensioni consentono all'HPA di prendere decisioni di scalabilità in base a più prospettive e criteri, offrendo una visualizzazione più olistica delle prestazioni dell'applicazione. Ciò è particolarmente utile per le applicazioni con requisiti di scalabilità complessi diversi.

Nota

Se la disponibilità elevata per l'applicazione è una priorità assoluta, è consigliabile lasciare un buffer leggermente superiore per il numero minimo di pod per l'HPA per tenere conto del tempo di ridimensionamento.

Scalabilità automatica verticale dei pod

L'implementazione della scalabilità automatica verticale dei pod è utile per le applicazioni con esigenze di risorse variabili e imprevedibili. La scalabilità automatica verticale dei pod (VPA) consente di ottimizzare le richieste di risorse, tra cui CPU e memoria, per singoli pod, consentendo un controllo preciso sull'allocazione delle risorse. Questa granularità riduce al minimo gli sprechi di risorse e migliora l'efficienza complessiva dell'utilizzo del cluster. La VPA semplifica anche la gestione delle applicazioni automatizzando l'allocazione delle risorse, liberando le risorse per le attività critiche.

Avviso

Non è consigliabile usare la VPA insieme all'HPA nelle stesse metriche della CPU o della memoria. Tale combinazione può causare conflitti, poiché entrambi i tipi di scalabilità automatica tentano di rispondere alle variazioni della domanda usando le stesse metriche. Tuttavia, è possibile usare la VPA per CPU o memoria in combinazione con HPA per le metriche personalizzate, per evitare sovrapposizioni e assicurarsi che ogni ridimensionamento automatico si concentri su aspetti distinti della scalabilità del carico di lavoro.

Nota

La VPA funziona in base ai dati cronologici. È consigliabile attendere almeno 24 ore dopo la distribuzione della VPA prima di applicare le modifiche, per darle il tempo di raccogliere i dati delle raccomandazioni.

Scalabilità automatica dell'infrastruttura

La scalabilità automatica del cluster

L'implementazione della scalabilità automatica del cluster è utile se i nodi esistenti non dispongono di capacità sufficiente, in quanto consente di aumentare ed effettuare il provisioning di nuovi nodi.

Quando si valuta la scalabilità automatica del cluster, la decisione di quando rimuovere un nodo comporta un compromesso tra l'ottimizzazione dell'utilizzo delle risorse e la garanzia della disponibilità delle risorse. L'eliminazione di nodi sottoutilizzati migliora l'utilizzo del cluster, ma potrebbe comportare la necessità di attendere il provisioning delle risorse prima di poter essere distribuite. È importante trovare un equilibrio tra questi due fattori che si allineano ai requisiti del cluster e del carico di lavoro e configurare di conseguenza le impostazioni del profilo di scalabilità automatica del cluster.

Le impostazioni del profilo di scalabilità automatica del cluster si applicano universalmente a tutti i pool di nodi abilitati per la scalabilità automatica nel cluster. Ciò significa che tutte le azioni di ridimensionamento eseguite in un pool di nodi abilitato per la scalabilità automatica potrebbero influire sul comportamento di scalabilità automatica in un altro pool di nodi. È importante applicare impostazioni del profilo coerenti e sincronizzate in tutti i pool di nodi pertinenti per garantire che il ridimensionamento automatico si comporti come previsto.

Provisioning eccessivo

Il provisioning eccessivo è una strategia che consente di ridurre il rischio di pressione dell'applicazione assicurandosi la presenza di un eccesso di risorse facilmente disponibili. Questo approccio è particolarmente utile per le applicazioni che riscontrano carichi altamente variabili e modelli di scalabilità del cluster che mostrano aumento e riduzione delle prestazioni frequenti.

Per determinare la quantità ottimale di provisioning eccessivo, è possibile usare la formula seguente:

1-buffer/1+traffic

Si supponga, ad esempio, di voler evitare di raggiungere l'utilizzo della CPU al 100% nel cluster. È possibile scegliere un buffer del 30% per mantenere un margine di sicurezza. Se si prevede un tasso medio di crescita del traffico del 40%, è possibile prendere in considerazione il provisioning eccessivo del 50%, come calcolato dalla formula:

1-30%/1+40%=50%

Un metodo di provisioning eccessivo efficace prevede l'uso di pod di sospensione. I pod di sospensione sono distribuzioni con priorità bassa che possono essere facilmente sostituite da distribuzioni ad alta priorità. Si creano pod con priorità bassa che servono esclusivamente allo scopo di riservare lo spazio di buffer. Quando un pod con priorità alta richiede spazio, i pod di sospensione vengono rimossi e riprogrammati in un altro nodo o in un nuovo nodo per supportare il pod con priorità alta.

Il codice YAML seguente mostra un esempio di manifesto del pod di pausa:

apiVersion: scheduling.k8s.io/v1 
kind: PriorityClass 
metadata: 
  name: overprovisioning 
value: -1 
globalDefault: false 
description: "Priority class used by overprovisioning." 
--- 
apiVersion: apps/v1 
kind: Deployment 
metadata: 
  name: overprovisioning 
  namespace: kube-system 
spec: 
  replicas: 1 
  selector: 
    matchLabels: 
      run: overprovisioning 
  template: 
    metadata: 
      labels: 
        run: overprovisioning 
    spec: 
      priorityClassName: overprovisioning 
      containers: 
      - name: reserve-resources 
        image: your-custome-pause-image 
        resources: 
          requests: 
            cpu: 1 
            memory: 4Gi

Scalabilità ed efficienza dei nodi

Materiale sussidiario sulle procedure consigliate:

Monitorare attentamente l'utilizzo delle risorse e i criteri di pianificazione per garantire che i nodi vengano usati in modo efficiente.

La scalabilità dei nodi consente di regolare dinamicamente il numero di nodi nel cluster in base alle esigenze del carico di lavoro. È importante comprendere che l'aggiunta di altri nodi a un cluster non è sempre la soluzione ottimale per migliorare le prestazioni. Per ottenere prestazioni ottimali, occorre monitorare attentamente l'utilizzo delle risorse e i criteri di pianificazione per garantire che i nodi vengano usati in modo efficiente.

Immagini del nodo

Materiale sussidiario sulle procedure consigliate:

Usare la versione più recente dell'immagine del nodo per assicurarsi di avere le patch di sicurezza e le correzioni di bug più recenti.

L'uso della versione più recente dell'immagine del nodo offre un'esperienza di prestazioni ottimale. Il servizio Azure Kubernetes offre miglioramenti delle prestazioni nelle versioni delle immagini settimanali. Le ultime immagini daemonset vengono memorizzate nella cache nell'immagine del disco rigido virtuale più recente e offrono vantaggi di latenza inferiore per il provisioning e il Bootstrap dei nodi. La riduzione degli aggiornamenti potrebbe avere un impatto negativo sulle prestazioni, quindi è importante evitare grandi lacune tra le versioni.

Azure Linux

L'host contenitore Linux di Azure nel servizio Azure Kubernetes usa un'immagine del servizio Azure Kubernetes nativa e fornisce un'unica posizione per lo sviluppo di Linux. Ogni pacchetto viene creato dall'origine e convalidato, assicurando che i servizi vengano eseguiti su componenti collaudati.

Linux di Azure è leggero, in quanto include solo il set di pacchetti per eseguire i carichi di lavoro dei contenitori. Fornisce una superficie di attacco ridotta ed elimina l'applicazione di patch e la manutenzione di pacchetti non necessari. A livello di base, dispone di un kernel con protezione avanzata Microsoft ottimizzato per Azure. Questa immagine è ideale per carichi di lavoro sensibili alle prestazioni e tecnici o operatori della piattaforma che gestiscono la flotta di cluster del servizio Azure Kubernetes.

Ubuntu 2204

L'immagine Ubuntu 2204 è l'immagine del nodo predefinita per il servizio Azure Kubernetes. È un sistema operativo leggero ed efficiente ottimizzato per l'esecuzione di carichi di lavoro in contenitori. Ciò significa che può contribuire a ridurre l'utilizzo delle risorse e migliorare le prestazioni complessive. L'immagine include le patch e gli aggiornamenti di sicurezza più recenti, che consentono di garantire che i carichi di lavoro siano protetti da vulnerabilità.

L'immagine Ubuntu 2204 è completamente supportata da Microsoft, Canonical e dalla community Ubuntu e consente di ottenere prestazioni e sicurezza migliori per i carichi di lavoro in contenitori.

Macchine virtuali (VM)

Materiale sussidiario sulle procedure consigliate:

Quando si seleziona una macchina virtuale, assicurarsi che le dimensioni e le prestazioni del disco del sistema operativo e dello SKU della macchina virtuale non abbiano una grande discrepanza. Una discrepanza nelle dimensioni o nelle prestazioni può causare problemi di prestazioni e contesa delle risorse.

Le prestazioni dell'applicazione sono strettamente legate agli SKU di macchina virtuale usati nei carichi di lavoro. Le macchine virtuali più grandi e potenti offrono in genere prestazioni migliori. Per carichi di lavoro cruciali o di prodotto, è consigliabile usare macchine virtuali con almeno una CPU a 8 core. Le macchine virtuali con generazioni di hardware più recenti, ad esempio v4 e v5, possono anche contribuire a migliorare le prestazioni. Tenere presente che la latenza di creazione e scalabilità può variare a seconda degli SKU di macchina virtuale usati.

Usare pool di nodi di sistema dedicati

Per la scalabilità delle prestazioni e dell'affidabilità, è consigliabile usare un pool di nodi di sistema dedicato. Con questa configurazione, il pool di nodi di sistema dedicato riserva spazio per le risorse di sistema critiche, ad esempio i daemon del sistema operativo. Il carico di lavoro dell'applicazione può quindi essere eseguito in un pool di nodi utente per aumentare la disponibilità di risorse allocabili per l'applicazione. Questa configurazione consente anche di ridurre il rischio di concorrenza delle risorse tra il sistema e l'applicazione.

Creare operazioni

Esaminare le estensioni e i componenti aggiuntivi abilitati durante il provisioning di creazione. Le estensioni e i componenti aggiuntivi possono aggiungere latenza alla durata complessiva delle operazioni di creazione. Se non sono necessari un'estensione o un componente aggiuntivo, è consigliabile rimuoverla per migliorare la latenza di creazione.

È anche possibile usare le zone di disponibilità per offrire un livello di disponibilità superiore e proteggere da potenziali errori hardware o eventi di manutenzione pianificata. I cluster del servizio Azure Kubernetes distribuiscono le risorse tra sezioni logiche dell'infrastruttura di Azure sottostante. Le zone di disponibilità separano fisicamente i nodi da altri nodi per garantire che un singolo errore non influisca sulla disponibilità dell'applicazione. Le zone di disponibilità sono disponibili solo in determinate aree. Per altre informazioni, vedere Zone di disponibilità di Azure.

Server API Kubernetes

Operazioni LIST e WATCH

Kubernetes usa le operazioni LIST e WATCH per interagire con il server API Kubernetes e monitorare le informazioni sulle risorse del cluster. Queste operazioni sono fondamentali per il modo in cui Kubernetes esegue la gestione delle risorse.

L'operazione LIST recupera un elenco di risorse che rientrano in determinati criteri, ad esempio tutti i pod in uno spazio dei nomi specifico o tutti i servizi nel cluster. Questa operazione è utile quando si vuole ottenere una panoramica delle risorse del cluster oppure è necessario operare su più risorse contemporaneamente.

L'operazione LIST può recuperare grandi quantità di dati, in particolare in cluster di grandi dimensioni con più risorse. Tenere presente che l'esecuzione di chiamate LIST non associate o frequenti comporta un carico significativo sul server API e può chiudere i tempi di risposta.

L'operazione WATCH esegue il monitoraggio delle risorse in tempo reale. Quando si configura un WATCH su una risorsa, il server API invia gli aggiornamenti ogni volta che vengono apportate modifiche a tale risorsa. Questo aspetto è importante per i controller, ad esempio il controller ReplicaSet, che si basano su WATCH per mantenere lo stato desiderato delle risorse.

Tenere presente che controllare troppe risorse modificabili o effettuare troppe richieste WATCH simultanee possono sovraccaricare il server API e causare un consumo eccessivo di risorse.

Per evitare potenziali problemi e garantire la stabilità del piano di controllo Kubernetes, è possibile usare le strategie seguenti:

Quote di risorse

Implementare quote di risorse per limitare il numero di risorse che possono essere elencate o osservate da un determinato utente o spazio dei nomi per evitare chiamate eccessive.

Priorità ed equità dell’API

Kubernetes ha introdotto il concetto di priorità ed equità dell’API (APF) per assegnare priorità e gestire le richieste API. È possibile usare APF in Kubernetes per proteggere il server API del cluster e ridurre il numero di risposte HTTP 429 Too Many Requests visualizzate dalle applicazioni client.

Risorsa personalizzata Funzionalità chiave
PriorityLevelConfigurations • Definire livelli di priorità diversi per le richieste API.
• Specifica un nome univoco e assegna un valore intero che rappresenta il livello di priorità. I livelli di priorità più elevati hanno valori interi inferiori, a indicare che sono più critici.
• Può usare più valori per classificare le richieste in livelli di priorità diversi in base alla loro importanza.
• Consente di specificare se le richieste a un determinato livello di priorità devono essere soggette a limiti di frequenza.
FlowSchemas • Definire il modo in cui le richieste API devono essere indirizzate a diversi livelli di priorità in base agli attributi della richiesta.
• Specificare regole che corrispondono alle richieste in base a criteri come gruppi di API, versioni e risorse.
• Quando una richiesta corrisponde a una determinata regola, la richiesta viene indirizzata al livello di priorità specificato nell'oggetto PriorityLevelConfiguration associato.
• Può impostare l'ordine di valutazione quando più flowSchemas corrispondono a una richiesta per garantire che determinate regole hanno la precedenza.

La configurazione dell'API con PriorityLevelConfigurations e FlowSchemas consente l’assegnazione di priorità alle richieste API critiche rispetto alle richieste meno importanti. In questo modo, le operazioni essenziali non rallentano o riscontrano ritardi a causa di richieste con priorità inferiore.

Ottimizzare l'etichettatura e i selettori

Quando si usano le operazioni LIST, ottimizzare i selettori di etichetta per limitare l'ambito delle risorse su cui si vuole eseguire una query per ridurre la quantità di dati restituiti e il carico nel server API.

Nelle operazioni CREATE e UPDATE di Kubernetes, fare riferimento alle azioni che gestiscono e modificano le risorse del cluster.

Operazioni CREATE e UPDATE

L'operazione CREATE crea nuove risorse nel cluster Kubernetes, ad esempio pod, servizi, distribuzioni, mappe di configurazione e segreti. Durante un'operazione CREATE, un client, ad esempio kubectl o un controller, invia una richiesta al server API Kubernetes per creare la nuova risorsa. Il server API convalida la richiesta, garantisce la conformità ai criteri del controller di ammissione e quindi crea la risorsa nello stato desiderato del cluster.

L'operazione UPDATE modifica le risorse esistenti nel cluster Kubernetes, incluse le modifiche alle specifiche delle risorse, ad esempio il numero di repliche, immagini del contenitore, variabili di ambiente o etichette. Durante un'operazione UPDATE, un client invia una richiesta al server API per aggiornare una risorsa esistente. Il server API convalida la richiesta, applica le modifiche alla definizione della risorsa e aggiorna la risorsa cluster.

Le operazioni CREATE e UPDATE possono influire sulle prestazioni del server API Kubernetes nelle condizioni seguenti:

  • Concorrenza elevata: quando più utenti o applicazioni effettuano richieste CREATE o UPDATE simultanee, ciò può causare un aumento delle richieste API che arrivano al server contemporaneamente. Questo può mettere alla prova la capacità di elaborazione del server API e causare problemi di prestazioni.
  • Definizioni di risorse complesse: le definizioni di risorse eccessivamente complesse o che coinvolgono più oggetti annidati possono aumentare il tempo necessario al server API per convalidare ed elaborare le richieste CREATE e UPDATE, che possono causare una riduzione delle prestazioni.
  • Convalida delle risorse e controllo di ammissione: Kubernetes applica vari criteri di controllo di ammissione e controlli di convalida nelle richieste CREATE e UPDATE in ingresso. Le definizioni di risorse di grandi dimensioni, ad esempio quelle con annotazioni o configurazioni estese, potrebbero richiedere più tempo di elaborazione.
  • Controller personalizzati: i controller personalizzati che controllano le modifiche apportate alle risorse, ad esempio distribuzioni o controller StatefulSet, possono generare un numero significativo di aggiornamenti durante il ridimensionamento o l'implementazione delle modifiche. Questi aggiornamenti possono filtrare le risorse del server API.

Per altre informazioni, vedere Risolvere i problemi del server API ed etcd nel servizio Azure Kubernetes.

Prestazioni del piano dati

Il piano dati Kubernetes è responsabile della gestione del traffico di rete tra contenitori e servizi. I problemi relativi al piano dati possono causare tempi di risposta lenti, prestazioni ridotte e tempi di inattività dell'applicazione. È importante monitorare e ottimizzare attentamente le configurazioni del piano dati, ad esempio latenza di rete, allocazione delle risorse, densità dei contenitori e criteri di rete, per garantire che le applicazioni in contenitori vengano eseguite in modo uniforme ed efficiente.

Tipi di archiviazione

Il servizio Azure Kubernetes consiglia e usa per impostazione predefinita i dischi temporanei del sistema operativo. I dischi temporanei del sistema operativo vengono creati nell'archiviazione di macchine virtuali locali e non vengono salvati in archiviazione remota di Azure come i dischi del sistema operativo gestiti. Hanno tempi di ricreazione e avvio più rapidi, consentendo operazioni cluster più veloci, e offrono una latenza di lettura/scrittura inferiore sul disco del sistema operativo dei nodi dell'agente del servizio Azure Kubernetes. I dischi del sistema operativo temporanei funzionano bene per i carichi di lavoro senza stato, in cui le applicazioni sono tolleranti ai singoli errori delle macchine virtuali, ma non al tempo di distribuzione delle macchine virtuali o alle istanze singole di ricreazione dell'immagine di queste ultime. Solo determinati SKU di macchina virtuale supportano dischi temporanei del sistema operativo, quindi è necessario assicurarsi che la generazione e le dimensioni dello SKU desiderate siano compatibili. Per altre informazioni, vedere Dischi temporanei del sistema operativo nel servizio Azure Kubernetes.

Se il carico di lavoro non è in grado di usare dischi temporanei del sistema operativo, per impostazione predefinita il servizio Azure Kubernetes usa dischi del sistema operativo SSD Premium. Se i dischi del sistema operativo SSD Premium non sono compatibili con il carico di lavoro, per impostazione predefinita il servizio Azure Kubernetes usa i dischi SSD Standard. Attualmente, l'unico tipo di disco del sistema operativo disponibile è HDD Standard. Per altre informazioni, vedere Opzioni di archiviazione nel servizio Azure Kubernetes.

La tabella seguente fornisce una suddivisione dei casi d'uso suggeriti per i dischi del sistema operativo supportati nel servizio Azure Kubernetes:

Tipo di disco del sistema operativo Funzionalità chiave Casi d'uso suggeriti
Dischi del sistema operativo temporanei • Tempi di ripetizione e avvio più rapidi.
• Latenza di lettura/scrittura inferiore nel disco del sistema operativo dei nodi dell'agente del servizio Azure Kubernetes.
• Prestazioni e disponibilità elevate.		 • Carichi di lavoro aziendali impegnativi, ad esempio SQL Server, Oracle, Dynamics, Exchange Server, MySQL, Cassandra, MongoDB, SAP Business Suite e così via.
• Carichi di lavoro di produzione senza stato che richiedono disponibilità elevata e bassa latenza.
Dischi del sistema operativo SSD Premium • Prestazioni coerenti e bassa latenza.
• Disponibilità elevata.		 • Carichi di lavoro aziendali impegnativi, ad esempio SQL Server, Oracle, Dynamics, Exchange Server, MySQL, Cassandra, MongoDB, SAP Business Suite e così via.
• Carichi di lavoro aziendali con utilizzo intensivo di input/output (I/O).
Dischi del sistema operativo SSD Standard • Prestazioni coerenti.
• Migliori disponibilità e latenza rispetto ai dischi HDD Standard.		 • Server Web.
• Server applicazioni con operazioni di input/output al secondo (IOPS) basse.
• Applicazioni aziendali poco usate.
• Carichi di lavoro di sviluppo/test.
Dischi HDD Standard • Basso costo.
• Presenta variabilità nelle prestazioni e nella latenza.		 • Archiviazione di backup.
• Archiviazione di massa con accesso poco frequente.

Operazioni di I/O al secondo e velocità effettiva

Le operazioni di input/output al secondo (IOPS) si riferiscono al numero di operazioni di lettura e scrittura che un disco può eseguire in un secondo. La velocità effettiva si riferisce alla quantità di dati che possono essere trasferiti in un determinato periodo di tempo.

I dischi del sistema operativo sono responsabili dell'archiviazione del sistema operativo e dei relativi file associati, mentre le macchine virtuali sono responsabili dell'esecuzione delle applicazioni. Quando si seleziona una macchina virtuale, assicurarsi che le dimensioni e le prestazioni del disco del sistema operativo e dello SKU della macchina virtuale non abbiano una grande discrepanza. Una discrepanza nelle dimensioni o nelle prestazioni può causare problemi di prestazioni e contesa delle risorse. Ad esempio, se il disco del sistema operativo è notevolmente inferiore rispetto alle macchine virtuali, può limitare la quantità di spazio disponibile per i dati dell'applicazione e comportare che il sistema esaurisca lo spazio su disco. Se il disco del sistema operativo ha prestazioni inferiori rispetto alle macchine virtuali, può diventare un collo di bottiglia e limitare le prestazioni complessive del sistema. Assicurarsi che le dimensioni e le prestazioni siano bilanciate per garantire prestazioni ottimali in Kubernetes.

È possibile usare la procedura seguente per monitorare i contatori delle operazioni di I/O al secondo e della larghezza di banda nei dischi del sistema operativo nel portale di Azure:

  1. Passare al portale di Azure.
  2. Cercare Set di scalabilità di macchine virtuali e selezionare il proprio set di scalabilità di macchine virtuali.
  3. In Monitoraggio selezionare Metrica.

I dischi temporanei del sistema operativo possono fornire operazioni di I/O al secondo dinamiche e velocità effettiva per l'applicazione, mentre i dischi gestiti hanno operazioni di I/O al secondo e velocità effettiva limitate Per altre informazioni, vedere Dischi temporanei del sistema operativo per le macchine virtuali di Azure.

L'unità SSD Premium di Azure v2 è progettata per carichi di lavoro aziendali con intensa attività di I/O che richiedono latenze del disco inferiori al millisecondo e operazioni di I/O al secondo e velocità effettiva elevate a un costo basso. È adatta per un'ampia gamma di carichi di lavoro, ad esempio SQL Server, Oracle, MariaDB, SAP, Cassandra, MongoDB, Big Data/Analytics, giochi e altro ancora. Questo tipo di disco è l'opzione con prestazioni più elevate attualmente disponibile per i volumi persistenti.

Pianificazione dei pod

Le risorse di memoria e CPU allocate a una macchina virtuale hanno un impatto diretto sulle prestazioni dei pod in esecuzione nella macchina virtuale. Quando viene creato un pod, vengono assegnate una determinata quantità di memoria e risorse CPU, che vengono usate per eseguire l'applicazione. Se la macchina virtuale non dispone di risorse di memoria o CPU sufficienti, può causare un rallentamento o un arresto anomalo dei pod. Se la macchina virtuale dispone di una quantità eccessiva di memoria o di risorse della CPU, può causare l'esecuzione inefficiente dei pod, la perdita di risorse e l'aumento dei costi. È consigliabile monitorare le richieste totali dei pod tra i carichi di lavoro rispetto alle risorse totali allocabili per ottimizzare la pianificazione della prevedibilità e delle prestazioni. È anche possibile impostare il numero massimo di pod per nodo in base alla pianificazione della capacità usando --max-pods.