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

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:

Ridimensionamento dei nodi

Quando si ridimensionano i cluster del servizio Azure Kubernetes in punti di scalabilità superiori, tenere a mente le procedure consigliate sul ridimensionamento dei nodi seguenti:

• Durante l'esecuzione di cluster AKS su larga scala, utilizzare il ridimensionamento automatico del cluster o il provisioning automatico dei nodi quando possibile per garantire il ridimensionamento dinamico dei nodi in base alla richiesta di risorse di calcolo.
• 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 di due ai cinque minuti tra le operazioni di scalatura verso l'alto per evitare la limitazione dell'API di Azure. Per altre informazioni, vedere Gestione API: memorizzazione nella cache e limitazione dei criteri.
• 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.

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

In Kubernetes, tutti gli oggetti in esecuzione in un cluster vengono gestiti dal piano di controllo, che è gestito da AKS. 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 e non tutte le risorse sono uguali nel costo. Ad esempio, i Secrets vengono spesso osservati da più controller e pod, ognuno dei quali effettua una chiamata LIST iniziale per sincronizzare lo stato. Poiché i segreti sono in genere di grandi dimensioni e vengono aggiornati di frequente, vengono caricati più sul piano di controllo rispetto alle risorse controllate meno frequentemente.

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.

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.

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.

Per confermare se il piano di controllo è stato ampliato, cercare il file di configurazione denominato configmap large-cluster-control-plane-scaling-status.

kubectl describe configmap large-cluster-control-plane-scaling-status -n kube-system

Considerazioni sul piano di controllo e sul limite di scalabilità di Kubernetes

I client Kubernetes sono componenti dell'applicazione, ad esempio operatori o agenti di monitoraggio, eseguiti nel cluster e comunicano con kube-apiserver per leggere o modificare le risorse. È importante ottimizzare il comportamento di questi client per ridurre il carico sul server kube-api e sul piano di controllo Kubernetes.

Il numero di richieste elaborate attivamente dal server API in un determinato momento è determinato da --max-requests-inflight flag e --max-mutating-requests-inflight . Il servizio Azure Kubernetes (AKS) utilizza i valori predefiniti di 400 e 200 richieste per questi flag, consentendo un totale di 600 richieste da inviare in un dato momento. Man mano che si aumentano le dimensioni del server API, si incrementa proporzionalmente anche il numero di richieste in corso.

Due tipi di oggetto Kubernetes, PriorityLevelConfiguration e FlowSchema (APF), determinano il modo in cui il server API divide la capacità totale delle richieste tra i tipi di richiesta. AKS utilizza la configurazione predefinita.

A ogni PriorityLevelConfiguration viene assegnata una quota delle richieste totali consentite. Per visualizzare gli oggetti PriorityLevelConfiguration nel cluster e le condivisioni di richiesta allocate, eseguire il comando seguente.

kubectl get --raw /metrics | grep apiserver_flowcontrol_nominal_limit_seats

FlowSchema esegue il mapping delle richieste del server API a PriorityLevelConfiguration. Se più oggetti FlowSchema corrispondono a una richiesta, il server API seleziona quello con la precedenza più bassa corrispondente.

Il mapping di FlowSchemas a PriorityLevelConfigurations può essere visualizzato usando questo comando:

kubectl get flowschemas

Per verificare se le richieste vengono eliminate a causa di APF, eseguire il comando seguente:

kubectl get --raw /metrics | grep apiserver_flowcontrol_rejected_requests_total

Procedure consigliate per i client Kubernetes

Le chiamate LIST eseguite dai client non ottimizzati sono spesso uno dei fattori principali che limitano la scalabilità di un cluster. 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 il server API si basa principalmente sulle dimensioni della risposta. Queste indicazioni si applicano se il client invia un numero ridotto di richieste LIST per oggetti di grandi dimensioni o un numero elevato di richieste LIST per oggetti più piccoli.

Usare gli informer

• Se il codice deve mantenere un elenco aggiornato di oggetti in memoria, l'uso di un informatore della libreria client-go offre vantaggi nell'esaminare le modifiche apportate alle risorse in base agli eventi anziché eseguire il polling delle modifiche. Questo è l'approccio migliore per evitare LIST non ottimizzati e ripetuti.

Usare la cache del server API

• Usare resourceVersion=0 per restituire i risultati dalla cache del server API. Ciò può impedire che gli oggetti vengano recuperati da etcd riducendo così il carico etcd, ma non supporta l'impaginazione.

  /api/v1/namespaces/default/pods?resourceVersion=0
  

Utilizzo efficiente dell'API Kubernetes

• È consigliabile usare l'argomento 'watch' quando possibile. Senza argomenti il comportamento predefinito consiste nell'elencare gli oggetti. Fare riferimento all'esempio seguente.

  /api/v1/namespaces/default/pods?watch=true
  

  Usare l'argomento watch con resourceVersion configurato per essere il valore noto più recente ricevuto dall'elenco o dall'argomento precedente. Questa operazione viene gestita automaticamente in client-go. Verificare tuttavia se si usa un client Kubernetes in altri linguaggi.

  /api/v1/namespaces/default/pods?watch=true&resourceVersion=<resourceversion>
  

• Se i controller o gli operatori devono usare chiamate LIST, è consigliabile evitare di eseguire il polling di risorse a livello di cluster senza selettori di etichetta o di campo, in particolare in cluster di grandi dimensioni. Gli esempi seguenti mostrano chiamate LIST ottimizzate e non ottimizzate.

  ELENCO ottimizzato:

  /api/v1/namespaces/default/pods?fieldSelector=status.phase=Running
  

  ELENCO non ottimizzato:

  /api/v1/pods
  

• Usare la paginazione per ridurre le dimensioni delle risposte LIST se il client deve recuperare i dati da etcd. Nell'esempio seguente viene utilizzato l'argomento limite per limitare la risposta a 100 oggetti.

  /api/v1/namespaces/default/pods?fieldSelector=status.phase=Running&limit=100
  

  Se si desidera che LIST continui a restituire tutti gli oggetti pod nell'esempio precedente, usare l'argomento CONTINUE con LIMIT.

  /api/v1/namespaces/default/pods?fieldSelector=status.phase=Running&limit=100&continue=<continue_token>
  

  Se si usa kubectl, l'argomento --chunk-size può essere applicato direttamente alle risposte paginate.

  kubectl get pods -n default --chunk-size=100
  

• Se i controller o gli operatori usano gli aggiornamenti del lease per l'elezione del leader, assicurarsi che siano resilienti ai problemi di connettività temporanei ottimizzando leaseDuration, renewDeadline e retryPeriod in modo che siano ottimali per i carichi di lavoro. Per i controller Kubernetes che usano l'elezione del leader client-go, usare la formula seguente:

  lease_duration > renew_deadline > retry_period
  

Daemonsets

• Esiste una differenza significativa tra un singolo controller che elenca gli oggetti e un DaemonSet in esecuzione in ogni nodo eseguono la stessa operazione. Se più istanze dell'applicazione client elencano periodicamente un numero elevato di oggetti, la soluzione non verrà ridimensionata correttamente in cluster di grandi dimensioni.

• Nei cluster con migliaia di nodi, la creazione di un nuovo DaemonSet, l'aggiornamento di un DaemonSet o l'aumento del numero di nodi può comportare un carico elevato sul piano di controllo. Se i pod DaemonSet emettono richieste costose al server API all'avvio del pod, possono causare un uso elevato delle risorse sul piano di controllo da un numero elevato di richieste simultanee.

• Usare una strategia RollingUpdate per implementare gradualmente nuovi pod DaemonSet. Quando il modello DaemonSet viene aggiornato, il controller sostituisce i pod precedenti con quelli nuovi in modo controllato. Quando la strategia di aggiornamento in sequenza non è configurata in modo esplicito, Kubernetes creerà per impostazione predefinita un oggetto RollingUpdate con maxUnavailable come 1, maxSurge come 0 e minReadySeconds come 0s. Fare riferimento all'esempio seguente.

    minReadySeconds: 30
    updateStrategy:
      type: RollingUpdate
      rollingUpdate:
        maxSurge: 0
        maxUnavailable: 1
  

• La strategia RollingUpdate si applica solo ai pod DaemonSet esistenti. Non limita l'impatto dell'aggiunta di nuovi nodi, che crea pod DaemonSet aggiuntivi o porta alla distribuzione di DaemonSet completamente nuovi.

• Per evitare che i DaemonSet emettano richieste LIST simultanee al server API durante l'avvio, in seguito alla scalabilità dei nodi o a nuove distribuzioni di DaemonSet, implementare un jitter di avvio all'entrypoint del container e configurare politiche di backoff esponenziale e di ripetizione dei tentativi appropriate per le risposte 5xx o 429, impedendo così tentativi ripetuti di richieste LIST di grandi dimensioni.

    spec:
      template:
        spec:
          containers:
          - name: my-daemonset-container
            image: <image>
            command: ["/bin/sh", "-c", "sleep $(( (RANDOM % 60) + 1 )); exec /path/to/your/app --args"]
  

Ottimizzazioni etcd

• Mantenere le dimensioni complessive etcd ridotte e non usare etcd come database per utilizzo generico. AKS fornisce 8 GB di spazio di archiviazione etcd di default, ma database etcd più grandi aumentano il tempo di deframmentazione, il che può causare problemi di prestazioni in lettura e scrittura. I database etcd di dimensioni maggiori possono anche aumentare la probabilità di problemi di affidabilità del server API e etcd se un client non ottimizzato recupera spesso un numero elevato di oggetti da etcd. Se le dimensioni del database etcd superano i 2 GB, è consigliabile usare le tecniche di riduzione delle dimensioni degli oggetti elencate di seguito.
• Per ridurre le dimensioni delle specifiche dei pod, spostare le variabili di ambiente dalle specifiche dei pod a ConfigMaps.
• Suddividere segreti di grandi dimensioni o ConfigMap in parti più piccole e gestibili.
• Archiviare i segreti in Azure Key Vault invece dei segreti Kubernetes, quando possibile, per ridurre il numero di segreti archiviati in etcd.
• Pulire gli oggetti inutilizzati
  • Eliminare i processi datati e i pod completati. Usare ttlSecondsAfterFinished nei Jobs in modo che gli oggetti completati vengano rimossi automaticamente.
  • Assicurarsi che i controller impostino ownerReferences. In questo modo, Kubernetes Garbage Collection rimuove automaticamente gli oggetti dipendenti quando viene eliminata la risorsa padre.
  • Limitare la cronologia di CronJob impostando successfulJobsHistoryLimit e failedJobsHistoryLimit per mantenere solo un numero ridotto di record di processo completati.
  • Ridurre la cronologia di implementazione della distribuzione. Anche i set di repliche precedenti vengono archiviati come oggetti API. Il valore predefinito è 10.
• Ridurre la cronologia delle revisioni Helm con l'argomento --history-max. Nei cluster di grandi dimensioni, mantenerlo al di sotto di 5.

Monitorare le metriche e i log del piano di controllo di AKS (Azure Kubernetes Service)

Il monitoraggio delle metriche del piano di controllo in cluster del servizio Azure Kubernetes di grandi dimensioni è fondamentale per garantire la stabilità e le prestazioni dei carichi di lavoro Kubernetes. Queste metriche offrono visibilità sull'integrità e sul comportamento dei componenti critici, ad esempio il server API, etcd, il gestore controller e l'utilità di pianificazione. Negli ambienti su larga scala, in cui la contesa delle risorse e i volumi di chiamate API elevati sono comuni, il monitoraggio delle metriche del piano di controllo consente di identificare i colli di bottiglia, rilevare le anomalie e ottimizzare l'utilizzo delle risorse. Analizzando queste metriche, gli operatori possono risolvere in modo proattivo problemi quali latenza del server API, oggetti etcd elevati o un consumo eccessivo delle risorse del piano di controllo, garantendo un efficiente funzionamento del cluster e riducendo al minimo i tempi di inattività.

Monitoraggio di Azure offre metriche e log completi sull'integrità del piano di controllo tramite Azure Managed Prometheus e Impostazioni diagnostiche.

• Per l'elenco degli avvisi da configurare per la salute del piano di controllo, vedere Procedure consigliate per il monitoraggio del piano di controllo di AKS
• Per ottenere l'elenco degli agenti utente con la latenza più elevata, è possibile usare i log del piano di controllo/Impostazioni di diagnostica

Metriche chiave della piattaforma del piano di controllo

AKS (Azure Kubernetes Service) espone le seguenti metriche della piattaforma in Monitoraggio di Azure per il monitoraggio dello stato di salute del server API e di etcd. Queste metriche sono disponibili senza abilitare Managed Prometheus e possono essere visualizzate direttamente nel portale di Azure in Metrics per il tuo cluster AKS.

Metriche del server API:

Metriche etcd:

Monitorare costantemente apiserver_cpu_usage_percentage e apiserver_memory_usage_percentage per rilevare la pressione delle risorse sul server API. Se etcd_database_usage_percentage è costantemente superiore a 50%, esaminare la sezione Ottimizzazioni etcd per ridurre le dimensioni del database. Per l'elenco completo delle metriche disponibili, vedere il riferimento sui dati di monitoraggio di AKS.

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 il ridimensionamento fino a 5.000 nodi per impostazione predefinita per tutti i cluster di livello Standard/LTS. Il servizio Azure Kubernetes ridimensiona il piano di controllo del cluster in fase di esecuzione, in base alle dimensioni del cluster e all'utilizzo delle risorse del server API. Se non è possibile passare al limite supportato, abilita le metriche del piano di controllo (anteprima) con il servizio gestito Monitoraggio di Azure per Prometheus per monitorare il piano di controllo. Per risolvere i problemi di scalabilità delle prestazioni o dell'affidabilità, vedere le risorse seguenti:

  • Guida alla risoluzione dei problemi del servizio Azure Kubernetes su larga scala
  • Risolvere i problemi del piano di controllo Kubernetes

  Note

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

• Azure Network Policy Manager (Azure npm) supporta solo fino a 250 nodi.

• Alcune metriche dei nodi dell'Azure Kubernetes Service, tra cui l'utilizzo del disco del nodo, l'utilizzo di CPU e memoria e la rete in/out, non saranno accessibili nelle metriche della piattaforma Azure Monitor dopo l'aumento del Control Plane.

• Non è possibile usare la funzionalità Arresta e Avvia con i cluster che hanno più di 100 nodi. Per altre informazioni, vedere Arrestare e avviare un cluster del servizio Azure Kubernetes.

Azure API e limitazione delle risorse della piattaforma

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. In Azure, il throttling avviene a due livelli. Azure Resource Manager (ARM) 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 sono di solito definiti a livello di combinazione di sottoscrizione e area geografica. Ad esempio, tutti i client all'interno di una sottoscrizione in una determinata area condividono i limiti dell'API per una determinata API Azure, ad esempio set di scalabilità di macchine virtuali API PUT. Ogni cluster AKS ha diversi client di proprietà di AKS, come il cloud provider o l'autoscaler del cluster, o client di proprietà del cliente, come 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 diagnostica e risoluzione dei problemi del servizio Azure Kubernetes: è possibile usare diagnostica e risoluzione dei problemi del servizio Azure Kubernetes per analizzare gli errori, identificare la causa radice e ottenere raccomandazioni per la risoluzione.
  • Aumenta l'intervallo di analisi del Cluster Autoscaler: se i report di diagnostica indicano che è stata rilevata una limitazione del Cluster Autoscaler, è possibile aumentare l'intervallo di analisi per ridurre il numero di chiamate a set di scalabilità di macchine virtuali da Cluster Autoscaler.
  • Riconfigurare le applicazioni di terze parti per effettuare meno chiamate: se si applica un filtro per agenti utente nella diagnostica Visualizzare la frequenza delle richieste e limitare i dettagli e si nota 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.
• Split 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 delle API Azure viene condivisa a livello di sottoscrizione-regionale, in modo da poter spostare o ridimensionare i cluster in sottoscrizioni o regioni diverse per superare la limitazione delle API 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.

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.

• Se si usa Azure Load Balancer Standard, usare almeno 2 Indirizzi IP pubblici in uscita. Prendere in considerazione anche i limiti delle regole back-end del servizio LoadBalancer durante la pianificazione di cluster di grandi dimensioni. Azure Load Balancer Standard supporta fino a 10.000 configurazioni IP back-end per ip front-end. Ogni tipo: il servizio LoadBalancer crea una regola di bilanciamento del carico per ogni porta esposta e associa tutti i nodi del cluster al pool back-end del servizio di bilanciamento del carico. Ad esempio, l'esposizione di 5 porte per un singolo servizio raggiungerà questo limite a 2000 nodi.

  1 service * 5 ports * 2000 nodes = 10000 backend IP configurations
  

• Usare Azure CNI Overlay per aumentare fino a 200.000 pod e 5.000 nodi per cluster. Per ulteriori informazioni, vedere Configurare una rete Overlay CNI in Azure AKS.

• 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 ogni cluster con un IP instradabile per pod. Per ulteriori informazioni, vedere Configurare Azure CNI di rete per l'assegnazione dinamica di IP in AKS.

• 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 Network Policy Manager (NPM) supporta solo fino a 250 nodi. Se si vogliono applicare criteri di rete per cluster di grandi dimensioni, è consigliabile usare Azure CNI con tecnologia 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.

• Abilitare LocalDNS nei pool di nodi per ridurre la latenza di risoluzione DNS ed eseguire l'offload di pod CoreDNS centralizzati. In cluster di grandi dimensioni con volumi di query DNS elevati, la risoluzione DNS centralizzata può diventare un collo di bottiglia. LocalDNS distribuisce un proxy DNS come servizio systemd in ogni nodo, risolvendo le query in locale, eliminando la pressione delle tabelle conntrack e aggiornando le connessioni a TCP per evitare race condition conntrack. LocalDNS supporta anche la gestione delle risposte memorizzate nella cache non aggiornate quando il DNS upstream non è disponibile, migliorando la resilienza del carico di lavoro durante gli errori temporanei. Per ulteriori informazioni, vedere Risoluzione DNS in AKS.

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 che ha raggiunto questo limite, è consigliabile ridurlo a meno di 3.000 nodi, prima di tentare di eseguirne l'aggiornamento. Ciò fornirà capacità aggiuntiva per la varianza dei nodi, riducendo al minimo il carico sul piano di controllo.
• Quando si aggiornano i cluster con più di 500 nodi, è consigliabile usare una configurazione massima di incremento del 10-20% della capacità del pool di nodi. Il servizio Azure Kubernetes configura gli aggiornamenti con un valore predefinito pari al 10% per il valore massimo di picco. È possibile personalizzare le impostazioni di sovratensione massima per pool di nodi, in modo da trovare 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.