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

  • Articolo

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 ridimensionamento per carichi di lavoro di piccole e medie 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 il ridimensionamento.

Tenere presente che grande è un termine relativo. Kubernetes ha una busta a scalabilità multidimensionale e la busta di scalabilità 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. I segnali migliori per la scalabilità di un piano di controllo Kubernetes sono il tasso 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 di Kubernetes.
  • Procedure consigliate per il client Kubernetes, inclusi backoff, espressioni di controllo e paginazione.
  • Limitazione della larghezza di banda della rete nelle 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 di 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 kube-apiserver che aggiungono costi e un carico sproporzionatamente superiore sul piano di controllo rispetto alle risorse senza espressioni di controllo.

Il piano di controllo gestisce tutta la scalabilità 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 sul tasso di abbandono 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 tre livelli del piano di controllo come parte dello SKU di base: Gratuito, Standard e Premium. Per altre informazioni, vedere Piani tariffari Gratuito, Standard e Premium per la gestione dei cluster del servizio Azure Kubernetes.

Importante

È consigliabile usare il livello Standard o Premium per 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 Azure CNI Overlay)

Nella maggior parte dei casi, il 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, questa non si verifica istantaneamente.

È possibile sfruttare API di priorità ed equità (APF) per limitare i client specifici e i tipi di richiesta per proteggere il piano di controllo durante tassi di abbandono e carichi elevati.

Client Kubernetes

I client Kubernetes sono i client delle 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.

È 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 qualche migliaio di oggetti di piccole dimensioni o più di qualche centinaio di oggetti di grandi dimensioni, è consigliabile considerare le linee guida seguenti:

  • Prendere in considerazione il numero di oggetti (CR) di cui si prevede l’esistenza 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 oggetto singolo 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 effettuare la manutenzione in modo efficiente di 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? Se la risposta è no, impostare ResourceVersion=0. Ciò fa sì che la cache del server API gestisca la richiesta invece di etcd.
  • Se non è possibile usare Informer o la cache del server API, leggere elenchi di grandi dimensioni in blocchi.
  • Evitare di ricorrere agli elenchi più del necessario. Se non è possibile usare Informer, 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. Si dovrebbe attendere per 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 elencano periodicamente un numero elevato di oggetti, la soluzione non verrà ridimensionata in cluster di grandi dimensioni.

Limitazione della larghezza di banda della rete nelle richieste dell'API e della piattaforma di Azure

Il carico su un'applicazione cloud può variare nel tempo in base a fattori come il numero di utenti attivi o i tipi di azioni eseguite dagli utenti. Se i requisiti di elaborazione del sistema superano la capacità delle risorse disponibili, il sistema può sovraccaricarsi e le prestazioni potrebbero non essere soddisfacenti, con possibilità che si verifichino errori.

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. Su Azure, la limitazione avviene su due livelli. Azure Resource Manager limita le richieste per la sottoscrizione e il tenant. Se la richiesta è sotto i limiti per la sottoscrizione e il tenant, Azure Resource Manager instrada la richiesta al provider di risorse. Il provider di risorse applica quindi limiti personalizzati alle relative operazioni. Per altre informazioni, vedere Limitazione delle richieste da parte di Azure Resource Manager.

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 le API PUT dei set di scalabilità di macchine virtuali. 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, della scalabilità complessiva e dell'elasticità dei cluster.

Tenendo presenti le considerazioni precedenti, i clienti sono in genere in grado di distribuire tra 20 e 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 risolvono 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 Diagnostica e risoluzione dei problemi di Azure Kubernetes: è possibile usare Diagnostica e risoluzione dei problemi del servizio Azure Kubernetes per analizzare gli errori, identificare la causa radice e ottenere raccomandazioni sulla risoluzione.
  • 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:

Nota

Durante l'operazione per ridimensionare il piano di controllo, è possibile che si verifichino timeout o latenza del server API elevati per un massimo di 15 minuti. Se si continuano a verificarsi problemi di ridimensionamento fino al limite supportato, aprire un ticket di supporto.

  • Azure Network Policy Manager (Azure npm) supporta solo fino a 250 nodi.
  • Alcune metriche dei nodi del servizio Azure Kubernetes, tra cui l'utilizzo del disco del nodo, l'utilizzo della CPU/memoria del nodo e la rete in/out, non saranno accessibili nelle metriche della piattaforma di Monitoraggio di Azure dopo che il piano di controllo è stato ridimensionato. Per verificare se il piano di controllo è stato aumentato, cercare la mappa di configurazione 'control-plane-scaling-status'
kubectl describe configmap control-plane-scaling-status -n kube-system

Rete

Quando si ridimensionano i cluster del servizio Azure Kubernetes in punti di scalabilità più grandi, tenere presenti le procedure consigliate sulla 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 Azure CNI Overlay per aumentare fino a 200.000 pod e 5.000 nodi per cluster. Per altre informazioni, vedere Configurare la rete Azure CNI Overlay nel servizio Azure Kubernetes.
  • Se l'applicazione richiede la comunicazione diretta da pod a pod tra cluster, usare Azure CNI con allocazione dinamica dell’IP 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 dinamica di indirizzi IP nel servizio Azure Kubernetes.
  • Quando si usano i servizi Kubernetes interni dietro un servizio di bilanciamento del carico interno, è consigliabile creare un servizio di bilanciamento del carico interno o un servizio inferiore a 750 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 con tecnologia Cilium, che combina il solido piano di controllo di Azure CNI con il piano dati di 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 sulla scalabilità dei pool di nodi seguenti:

  • Per i pool di nodi di sistema, usare lo SKU di Standard_D16ds_v5 o uno SKU di VM core/memory 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 i batch con un massimo di 500-700 nodi alla volta. Le operazioni di ridimensionamento devono avere un tempo di attesa da due minuti a cinque minuti tra operazioni di scalabilità per impedire la limitazione delle richieste dell'API di Azure. Per altre informazioni, vedere Gestione API: memorizzazione nella cache e limitazione dei criteri.

Considerazioni e procedure consigliate per l'aggiornamento del cluster

  • Quando un cluster raggiunge il limite di 5.000 nodi, gli aggiornamenti del cluster vengono bloccati. Questo limite impedisce un aggiornamento perché non è disponibile capacità del nodo per eseguire aggiornamenti in sequenza entro il limite massimo di proprietà di picco. Se si dispone di un cluster a questo limite, è consigliabile ridurre il cluster in meno di 3.000 nodi prima di tentare un aggiornamento del cluster. Ciò fornirà capacità aggiuntiva per la varianza dei nodi e ridurre al minimo il carico sul piano di controllo.
  • Quando si aggiornano i cluster con più di 500 nodi, è consigliabile usare una configurazione max surge del 10-20% della capacità del pool di nodi. Il servizio Azure Kubernetes configura gli aggiornamenti con un valore predefinito pari al 10% per l'aumento massimo. È possibile personalizzare le impostazioni di max surge per ogni pool di nodi per consentire un compromesso tra velocità di aggiornamento e interruzione del carico di lavoro. Quando si aumentano le impostazioni di sovratensione massima, il processo di aggiornamento viene completato più velocemente, ma durante il processo di aggiornamento potrebbero verificarsi delle interruzioni. Per altre informazioni, vedere Personalizzare l'aggiornamento della sovratensione del numero di nodi.
  • Per altre informazioni sull'aggiornamento del cluster, vedere Aggiornare un cluster del servizio Azure Kubernetes.