Procedure consigliate per prestazioni e scalabilità per carichi di lavoro di grandi dimensioni in servizio Azure Kubernetes (servizio Azure Kubernetes)

Articolo
11/08/2023

Nota

Questo articolo è incentrato sulle procedure consigliate generali per carichi di lavoro di grandi dimensioni. Per le procedure consigliate specifiche per carichi di lavoro di piccole e medie dimensioni, vedere Procedure consigliate per prestazioni e scalabilità per carichi di lavoro di piccole e medie dimensioni in servizio Azure Kubernetes (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 il ridimensionamento.

Tenere presente che large è un termine relativo. Kubernetes ha una busta a scalabilità multidimensionale e la busta di scala per il carico di lavoro dipende dalle risorse usate. Ad esempio, un cluster con 100 nodi e migliaia di pod o CRL possono essere considerati di grandi dimensioni. Un cluster a 1.000 nodi con 1.000 pod e varie altre risorse potrebbe essere considerato piccolo dal punto di vista del piano di controllo. Il segnale migliore per la scalabilità di un piano di controllo Kubernetes è la frequenza di riuscita e la latenza delle richieste HTTP del server API, in quanto si tratta di un proxy per la quantità di carico sul piano di controllo.

Questo articolo contiene informazioni relative agli argomenti seguenti:

Scalabilità del piano di controllo del servizio Azure Kubernetes e del servizio Azure Kubernetes.
Procedure consigliate per il client Kubernetes, inclusi backoff, espressioni di controllo e paginazione.
Limiti di limitazione delle richieste dell'API e della piattaforma di Azure.
Limitazioni delle funzionalità.
Procedure consigliate per il ridimensionamento della rete e del pool di nodi.

Scalabilità del piano di controllo del servizio Azure Kubernetes e del servizio Azure Kubernetes

Nel servizio Azure Kubernetes un cluster è costituito da un set di nodi (macchine virtuali o fisiche) che eseguono agenti Kubernetes e vengono gestiti dal piano di controllo Kubernetes ospitato dal servizio Azure Kubernetes. Anche se il servizio Azure Kubernetes ottimizza il piano di controllo Kubernetes e i relativi componenti per scalabilità e prestazioni, è comunque vincolato dai limiti del progetto upstream.

Kubernetes ha una busta a scala multidimensionale con ogni tipo di risorsa che rappresenta una dimensione. Non tutte le risorse sono uguali. Ad esempio, le espressioni di controllo vengono comunemente impostate sui segreti, il che comporta chiamate di elenco al server kube-api che aggiungono costi e un carico sproporzionatamente superiore sul piano di controllo rispetto alle risorse senza espressioni di controllo.

Il piano di controllo gestisce tutto il ridimensionamento delle risorse nel cluster, quindi maggiore è la scalabilità del cluster all'interno di una determinata dimensione, minore è la scalabilità all'interno di altre dimensioni. Ad esempio, l'esecuzione di centinaia di migliaia di pod in un cluster del servizio Azure Kubernetes influisce sulla quantità di varianza dei pod (mutazioni dei pod al secondo) che il piano di controllo può supportare.

Le dimensioni della busta sono proporzionali alle dimensioni del piano di controllo Kubernetes. Il servizio Azure Kubernetes supporta due livelli del piano di controllo come parte dello SKU di base: il livello gratuito e il livello Standard. Per altre informazioni, vedere Piani tariffari gratuito e Standard per la gestione dei cluster del servizio Azure Kubernetes.

Importante

È consigliabile usare il livello Standard per i carichi di lavoro di produzione o su larga scala. Il servizio Azure Kubernetes aumenta automaticamente il piano di controllo kubernetes per supportare i limiti di scalabilità seguenti:

Fino a 5.000 nodi per ogni cluster del servizio Azure Kubernetes
200.000 pod per ogni cluster del servizio Azure Kubernetes (con overlay CNI di Azure)

Nella maggior parte dei casi, l'superamento della soglia del limite di scalabilità comporta prestazioni ridotte, ma non causa il failover immediato del cluster. Per gestire il carico sul piano di controllo Kubernetes, valutare la possibilità di ridimensionare i batch fino al 10-20% della scala corrente. Ad esempio, per un cluster di 5.000 nodi, ridimensionare in incrementi di 500-1.000 nodi. Anche se il servizio Azure Kubernetes esegue la scalabilità automatica del piano di controllo, non si verifica istantaneamente.

È possibile sfruttare priorità API e equità (APF) per limitare i client specifici e i tipi di richiesta per proteggere il piano di controllo durante una varianza e un carico elevati.

Client Kubernetes

I client Kubernetes sono i client applicazioni, ad esempio operatori o agenti di monitoraggio, distribuiti nel cluster Kubernetes che devono comunicare con il server kube-api per eseguire operazioni di lettura o modifica. È importante ottimizzare il comportamento di questi client per ridurre al minimo il carico aggiunto al server kube-api e al piano di controllo Kubernetes.

Il servizio Azure Kubernetes non espone le metriche del piano di controllo e del server API tramite Prometheus o tramite metriche della piattaforma. Tuttavia, è possibile analizzare il traffico del server API e il comportamento del client tramite i log di controllo di Kube. Per altre informazioni, vedere Risolvere i problemi del piano di controllo Kubernetes.

Le richieste LIST possono essere costose. Quando si lavora con elenchi che potrebbero avere più di poche migliaia di oggetti di piccole dimensioni o più di poche centinaia di oggetti di grandi dimensioni, è consigliabile considerare le linee guida seguenti:

Prendere in considerazione il numero di oggetti (CR) che si prevede di esistere quando si definisce un nuovo tipo di risorsa (CRD).
Il carico su etcd e server API si basa principalmente sul numero di oggetti esistenti, non sul numero di oggetti restituiti. Anche se si usa un selettore di campo per filtrare l'elenco e recuperare solo un numero ridotto di risultati, queste linee guida sono ancora valide. L'unica eccezione è il recupero di un singolo oggetto da metadata.name.
Evitare chiamate LIST ripetute, se possibile , se il codice deve mantenere un elenco aggiornato di oggetti in memoria. Prendere invece in considerazione l'uso delle classi Informer fornite nella maggior parte delle librerie Kubernetes. Gli informer combinano automaticamente le funzionalità LIST e WATCH per mantenere in modo efficiente una raccolta in memoria.
Valutare se è necessaria una coerenza assoluta se gli informer non soddisfano le proprie esigenze. È necessario visualizzare i dati più recenti, fino al momento esatto in cui è stata eseguita la query? In caso contrario, impostare ResourceVersion=0. Ciò fa sì che la cache del server API gestisca la richiesta invece di etcd.
Se non è possibile usare Informers o la cache del server API, leggere elenchi di grandi dimensioni in blocchi.
Evitare di elencare più spesso del necessario. Se non è possibile usare Informers, considerare la frequenza con cui l'applicazione elenca le risorse. Dopo aver letto l'ultimo oggetto in un elenco di grandi dimensioni, non eseguire immediatamente una nuova query sullo stesso elenco. Dovresti aspettare un po' di tempo.
Prendere in considerazione il numero di istanze in esecuzione dell'applicazione client. C'è una grande differenza tra la presenza di un singolo controller che elenca gli oggetti rispetto alla presenza di pod in ogni nodo che eseguono la stessa operazione. Se si prevede di avere più istanze dell'applicazione client che elenca periodicamente un numero elevato di oggetti, la soluzione non verrà ridimensionata in cluster di grandi dimensioni.

Limitazione delle richieste dell'API e della piattaforma di Azure

Il carico in un'applicazione cloud può variare nel tempo in base a fattori quali il numero di utenti attivi o i tipi di azioni che gli utenti eseguono. Se i requisiti di elaborazione del sistema superano la capacità delle risorse disponibili, il sistema può diventare sovraccarico e soffrire di prestazioni e errori scarsi.

Per gestire dimensioni di carico variabili in un'applicazione cloud, è possibile consentire all'applicazione di usare le risorse fino a un limite specificato e quindi limitarle quando viene raggiunto il limite. In Azure la limitazione avviene a due livelli. Azure Resource Manager limita le richieste per la sottoscrizione e il tenant. Se la richiesta è inferiore ai limiti di limitazione per la sottoscrizione e il tenant, ARM instrada la richiesta al provider di risorse. Il provider di risorse applica quindi limiti di limitazione personalizzati alle relative operazioni. Per altre informazioni, vedere Richieste di limitazione arm.

Gestire la limitazione delle richieste nel servizio Azure Kubernetes

I limiti delle API di Azure vengono in genere definiti a livello di combinazione di un'area di sottoscrizione. Ad esempio, tutti i client all'interno di una sottoscrizione in una determinata area condividono i limiti dell'API di Azure per una determinata API di Azure, ad esempio set di scalabilità di macchine virtuali API PUT. Ogni cluster del servizio Azure Kubernetes ha diversi client di proprietà del servizio Azure Kubernetes, ad esempio il provider di servizi cloud o il ridimensionamento automatico del cluster o client di proprietà del cliente, ad esempio Datadog o Prometheus self-hosted, che chiamano le API di Azure. Quando si eseguono più cluster del servizio Azure Kubernetes in una sottoscrizione all'interno di una determinata area, tutti i client di proprietà del servizio Azure Kubernetes e di proprietà del cliente all'interno dei cluster condividono un set comune di limiti api. Di conseguenza, il numero di cluster che è possibile distribuire in un'area di sottoscrizione è una funzione del numero di client distribuiti, dei relativi modelli di chiamata e della scalabilità complessiva e dell'elasticità dei cluster.

Tenendo presenti le considerazioni precedenti, i clienti sono in genere in grado di distribuire tra 20-40 cluster di piccole e medie dimensioni per ogni area di sottoscrizione. È possibile ottimizzare la scalabilità delle sottoscrizioni usando le procedure consigliate seguenti:

Aggiornare sempre i cluster Kubernetes alla versione più recente. Le versioni più recenti contengono molti miglioramenti che risondono problemi di prestazioni e limitazioni. Se si usa una versione aggiornata di Kubernetes e viene comunque visualizzata la limitazione a causa del carico effettivo o del numero di client nella sottoscrizione, è possibile provare le opzioni seguenti:

Analizzare gli errori usando il servizio Azure Kubernetes Diagnosticare e risolvere i problemi: è possibile usare diagnostica e risoluzione del servizio Azure Kubernetes per analizzare gli errori, identificare la causa radice e ottenere raccomandazioni sulla risoluzione.
- Aumentare l'intervallo di analisi del ridimensionamento automatico del cluster: se i report di diagnostica indicano che è stata rilevata la limitazione della scalabilità automatica del cluster, è possibile aumentare l'intervallo di analisi per ridurre il numero di chiamate a set di scalabilità di macchine virtuali dal ridimensionamento automatico del cluster.
- Riconfigurare le applicazioni di terze parti per effettuare meno chiamate: se si filtrano in base agli agenti utente nella diagnostica View request rate and throttle details (Visualizzare la frequenza delle richieste e limitare i dettagli ) e si noterà che un'applicazione di terze parti, ad esempio un'applicazione di monitoraggio, effettua un numero elevato di richieste GET, è possibile modificare le impostazioni di queste applicazioni per ridurre la frequenza delle chiamate GET. Assicurarsi che i client dell'applicazione usino il backoff esponenziale quando si chiamano le API di Azure.
Suddividere i cluster in sottoscrizioni o aree diverse: se si dispone di un numero elevato di cluster e pool di nodi che usano set di scalabilità di macchine virtuali, è possibile suddividerli in sottoscrizioni o aree diverse all'interno della stessa sottoscrizione. La maggior parte dei limiti dell'API di Azure viene condivisa a livello di area della sottoscrizione, in modo da poter spostare o ridimensionare i cluster in sottoscrizioni o aree diverse per sbloccare la limitazione delle richieste dell'API di Azure. Questa opzione è particolarmente utile se si prevede che i cluster abbiano un'attività elevata. Non esistono linee guida generiche per questi limiti. Per indicazioni specifiche, è possibile creare un ticket di supporto.

Limitazioni delle funzionalità

Quando si ridimensionano i cluster del servizio Azure Kubernetes in punti di scalabilità più grandi, tenere presenti le limitazioni di funzionalità seguenti:

Il servizio Azure Kubernetes supporta fino a una scalabilità di 1.000 nodi in un cluster del servizio Azure Kubernetes per impostazione predefinita. Anche se il servizio Azure Kubernetes non impedisce l'aumento del numero di istanze, questa operazione potrebbe comportare una riduzione delle prestazioni. Se si vuole ridimensionare oltre 1.000 nodi, è possibile richiedere un aumento del limite. Per altre informazioni, vedere Procedure consigliate per la creazione e l'esecuzione di cluster del servizio Azure Kubernetes su larga scala.
Azure Network Policy Manager (Azure npm) supporta solo fino a 250 nodi.
Non è possibile usare la funzionalità Arresta e Avvia con cluster con più di 100 nodi. Per altre informazioni, vedere Arrestare e avviare un cluster del servizio Azure Kubernetes.

Rete

Quando si ridimensionano i cluster del servizio Azure Kubernetes in punti di scalabilità più grandi, tenere presenti le procedure consigliate di rete seguenti:

Usare NAT gestito per l'uscita del cluster con almeno due indirizzi IP pubblici nel gateway NAT. Per altre informazioni, vedere Creare un gateway NAT gestito per il cluster del servizio Azure Kubernetes.
Usare la sovrimpressione CNI di Azure per aumentare fino a 200.000 pod e 5.000 nodi per cluster. Per altre informazioni, vedere Configurare la rete overlay CNI di Azure nel servizio Azure Kubernetes.
Se l'applicazione richiede la comunicazione diretta da pod a pod tra cluster, usare Azure CNI con allocazione IP dinamica e aumentare fino a 50.000 pod dell'applicazione per cluster con un IP instradabile per pod. Per altre informazioni, vedere Configurare la rete CNI di Azure per l'allocazione ip dinamica nel servizio Azure Kubernetes.
Quando si usano i servizi Kubernetes interni dietro un servizio di bilanciamento del carico interno, è consigliabile creare un servizio o un servizio di bilanciamento del carico interno al di sotto di una scalabilità di 750 nodi per ottimizzare le prestazioni di ridimensionamento e l'elasticità del servizio di bilanciamento del carico.
Azure npm supporta solo fino a 250 nodi. Se si vogliono applicare i criteri di rete per cluster di dimensioni maggiori, è consigliabile usare Azure CNI basato su Cilium, che combina il solido piano di controllo di Azure CNI con il piano dati Cilium per offrire funzionalità di rete e sicurezza ad alte prestazioni.

Ridimensionamento del pool di nodi

Quando si ridimensionano i cluster del servizio Azure Kubernetes in punti di scalabilità più grandi, tenere presenti le procedure consigliate per il ridimensionamento del pool di nodi seguenti:

Per i pool di nodi di sistema, usare lo SKU di Standard_D16ds_v5 o uno SKU di macchina virtuale core/memoria equivalente con dischi temporanei del sistema operativo per fornire risorse di calcolo sufficienti per i pod kube-system.
Poiché il servizio Azure Kubernetes ha un limite di 1.000 nodi per pool di nodi, è consigliabile creare almeno cinque pool di nodi utente per aumentare fino a 5.000 nodi.
Quando si eseguono cluster del servizio Azure Kubernetes su larga scala, usare il ridimensionamento automatico del cluster quando possibile per garantire il ridimensionamento dinamico dei pool di nodi in base alla richiesta di risorse di calcolo. Per altre informazioni, vedere Ridimensionare automaticamente un cluster del servizio Azure Kubernetes per soddisfare le esigenze dell'applicazione.
Se si stanno ridimensionando oltre 1.000 nodi e non si usa il ridimensionamento automatico del cluster, è consigliabile ridimensionare in batch di 500-700 nodi alla volta. Le operazioni di ridimensionamento devono avere un tempo di attesa di due minuti a cinque minuti tra le operazioni di aumento delle prestazioni per impedire la limitazione delle richieste dell'API di Azure. Per altre informazioni, vedere Gestione API: Memorizzazione nella cache e limitazione dei criteri.