Fare lo scale up dei cluster Google Distributed Cloud

Per aumentare la capacità dei cluster Google Distributed Cloud, puoi modificare diversi limiti dei cluster correlati, ad esempio il numero di nodi, pod e servizi. Questo documento spiega come interagiscono queste dimensioni e descrive i requisiti e le best practice che ti aiutano a fare lo scale up senza interrompere i tuoi workload.

Informazioni sui limiti

Google Distributed Cloud è un sistema complesso con un'ampia superficie di integrazione. Esistono molte dimensioni che influiscono sulla scalabilità del cluster. Ad esempio, il numero di nodi è solo una delle tante dimensioni su cui Google Distributed Cloud può scalare. Altre dimensioni includono il numero totale di pod e servizi. Molte di queste dimensioni, come il numero di pod per nodo e il numero di nodi per cluster, sono correlate. Per saperne di più sulle dimensioni che influiscono sulla scalabilità, consulta Soglie di scalabilità di Kubernetes nella sezione Scalability Special Interest Group (SIG) del repository della community di Kubernetes su GitHub.

I limiti di scalabilità sono inoltre sensibili alla configurazione dell'hardware e dei nodi su cui è in esecuzione il cluster. I limiti descritti in questo documento sono verificati in un ambiente che probabilmente è diverso dal tuo. Pertanto, potresti non riprodurre gli stessi numeri quando l'ambiente sottostante è il fattore limitante.

Per saperne di più sui limiti applicabili ai cluster Google Distributed Cloud, consulta Quote e limiti.

Preparati alla scalabilità

Mentre ti prepari a scalare i cluster Google Distributed Cloud, considera i requisiti e le limitazioni descritti nelle sezioni seguenti.

Requisiti di CPU e memoria dei nodi del control plane

La tabella seguente descrive la configurazione di CPU e memoria consigliata per i nodi del control plane per i cluster che eseguono workload di produzione:

Numero di nodi del cluster CPU del control plane consigliate Memoria del control plane consigliata
1-50 8 core 32 GiB
51-100 16 core 64 GiB

Numero di pod e servizi

Il numero di pod e servizi che puoi avere nei cluster è controllato dalle seguenti impostazioni:

CIDR pod e numero massimo di nodi

Il numero totale di indirizzi IP riservati per i pod nel cluster è uno dei fattori limitanti per lo scale up del cluster. Questa impostazione, insieme a quella per il numero massimo di pod per nodo, determina il numero massimo di nodi che puoi avere nel cluster prima di rischiare di esaurire gli indirizzi IP per i pod.

Considera quanto segue:

  • Il numero totale di indirizzi IP riservati per i pod nel cluster è specificato con clusterNetwork.pods.cidrBlocks, che accetta un intervallo di indirizzi IP specificati in notazione CIDR. Ad esempio, il valore precompilato 192.168.0.0/16 specifica un intervallo di 65.536 indirizzi IP da 192.168.0.0 a 192.168.255.255.

  • Il numero massimo di pod che possono essere eseguiti su un singolo nodo è specificato con nodeConfig.podDensity.maxPodsPerNode.

  • In base all'impostazione del numero massimo di pod per nodo, Google Distributed Cloud esegue il provisioning di circa il doppio degli indirizzi IP per il nodo. Gli indirizzi IP aggiuntivi aiutano a evitare il riutilizzo involontario degli IP dei pod in un breve periodo di tempo.

  • Dividendo il numero totale di indirizzi IP dei pod per il numero di indirizzi IP dei pod di cui è stato eseguito il provisioning su ciascun nodo, ottieni il numero totale di nodi che puoi avere nel cluster.

Ad esempio, se il CIDR del pod è 192.168.0.0/17, hai un totale di 32.768 indirizzi IP (2(32-17) = 215 = 32.768). Se imposti il numero massimo di pod per nodo su 250, Google Distributed Cloud esegue il provisioning di un intervallo di circa 500 indirizzi IP, che equivale approssimativamente a un blocco CIDR /23 (2(32-23) = 29 = 512). Quindi, il numero massimo di nodi in questo caso è 64 (215 indirizzi/cluster diviso per 29 indirizzi/nodo = 2(15-9) nodi/cluster = 26 = 64 nodi/cluster).

Sia clusterNetwork.pods.cidrBlocks che nodeConfig.podDensity.maxPodsPerNode sono immutabili, quindi pianifica attentamente la crescita futura del cluster per evitare di esaurire la capacità dei nodi. Per i numeri massimi consigliati di pod per cluster, pod per nodo e nodi per cluster in base ai test, consulta Limiti.

CIDR servizio

Il CIDR dei servizi può essere aggiornato per aggiungere altri servizi man mano che fai lo scale up del cluster. Tuttavia, non puoi ridurre l'intervallo CIDR del servizio. Per saperne di più, consulta Aumenta l'intervallo della rete di servizi.

Risorse riservate per i daemon di sistema

Per impostazione predefinita, Google Distributed Cloud prenota automaticamente le risorse su un nodo per i daemon di sistema, come sshd o udev. Le risorse di CPU e memoria sono prenotate su un nodo per i daemon di sistema, in modo che questi ultimi dispongano delle risorse di cui hanno bisogno. Senza questa funzionalità, i pod possono potenzialmente consumare la maggior parte delle risorse di un nodo, rendendo impossibile per i daemon di sistema completare le proprie attività.

In particolare, Google Distributed Cloud riserva 80 millicore di CPU (80 mCPU) e 280 mebibyte (280 MiB) di memoria su ogni nodo per i daemon di sistema. Tieni presente che l'unità CPU mCPU indica un millesimo di un core, quindi 80/1000 o l'8% di un core su ogni nodo è riservato ai daemon di sistema. La quantità di risorse riservate è ridotta e non ha un impatto significativo sulle prestazioni dei pod. Tuttavia, il kubelet su un nodo può espellere i pod se il loro utilizzo della CPU o della memoria supera le quantità allocate.

Networking con MetalLB

Potresti voler aumentare il numero di speaker MetalLB per risolvere i seguenti aspetti:

  • Larghezza di banda: la larghezza di banda dell'intero cluster per i servizi di bilanciamento del carico dipende dal numero di speaker e dalla larghezza di banda di ciascun nodo speaker. L'aumento del traffico di rete richiede più speaker.

  • Tolleranza ai guasti: un numero maggiore di speaker riduce l'impatto complessivo del guasto di un singolo speaker.

MetalLB richiede connettività di livello 2 tra i nodi di bilanciamento del carico. In questo caso, potresti essere limitato dal numero di nodi con connettività di livello 2 su cui puoi inserire gli speaker MetalLB.

Pianifica attentamente il numero di speaker MetalLB che vuoi avere nel cluster e determina il numero di nodi di livello 2 di cui hai bisogno. Per saperne di più, consulta i problemi di scalabilità di MetalLB.

Inoltre, quando utilizzi la modalità di bilanciamento del carico integrato, anche i nodi del control plane devono trovarsi nella stessa rete di livello 2. Il bilanciamento manuale del carico non ha questa limitazione. Per saperne di più, consulta Modalità di bilanciamento manuale del carico.

Esecuzione di molti nodi, pod e servizi

L'aggiunta di nodi, pod e servizi è un modo per fare lo scale up del cluster. Le sezioni seguenti illustrano alcune impostazioni e configurazioni aggiuntive da considerare quando aumenti il numero di nodi, pod e servizi nel tuo cluster. Per informazioni sui limiti di queste dimensioni e su come sono correlate tra loro, consulta Limiti.

Crea un cluster senza kube-proxy

Per creare un cluster ad alte prestazioni che possa scalare per utilizzare un numero elevato di servizi ed endpoint, ti consigliamo di creare il cluster senza kube-proxy. Senza kube-proxy, il cluster utilizza GKE Dataplane V2 in modalità kube-proxy-replacement. Questa modalità evita il consumo di risorse necessario per mantenere un ampio insieme di regole iptables.

Non puoi disattivare l'utilizzo di kube-proxy per un cluster esistente. Questa configurazione deve essere impostata al momento della creazione del cluster. Per istruzioni e ulteriori informazioni, consulta Crea un cluster senza kube-proxy.

Configurazione di CoreDNS

Questa sezione descrive gli aspetti di CoreDNS che influiscono sulla scalabilità dei tuoi cluster.

DNS dei pod

Per impostazione predefinita, i cluster Google Distributed Cloud inseriscono nei pod un resolv.conf simile al seguente:

nameserver KUBEDNS_CLUSTER_IP
search <NAMESPACE>.svc.cluster.local svc.cluster.local cluster.local c.PROJECT_ID.internal google.internal
options ndots:5

L'opzione ndots:5 indica che i nomi host con meno di 5 punti non sono considerati un nome di dominio completo (FQDN). Il server DNS aggiunge tutti i domini di ricerca specificati prima di cercare il nome host richiesto originariamente, il che ordina le ricerche come segue durante la risoluzione di google.com:

  1. google.com.NAMESPACE.svc.cluster.local
  2. google.com.svc.cluster.local
  3. google.com.cluster.local
  4. google.com.c.PROJECT_ID.internal
  5. google.com.google.internal
  6. google.com

Ogni ricerca viene eseguita per IPv4 (record A) e IPv6 (record AAAA), il che genera 12 richieste DNS per ogni query non FQDN, amplificando in modo significativo il traffico DNS. Per mitigare questo problema, ti consigliamo di dichiarare il nome host da cercare come FQDN aggiungendo un punto finale (google.com.). Questa dichiarazione deve essere eseguita a livello di workload dell'applicazione. Per ulteriori informazioni, consulta la pagina del manuale di resolv.conf.

IPv6

Se il cluster non utilizza IPv6, è possibile dimezzare le richieste DNS eliminando la ricerca del record AAAA nel server DNS upstream. Se hai bisogno di aiuto per disattivare le ricerche AAAA, contatta l'assistenza clienti Google Cloud.

Pool di nodi dedicato

A causa della natura critica delle query DNS nei cicli di vita delle applicazioni, ti consigliamo di utilizzare nodi dedicati per il deployment coredns. Questo deployment rientra in un dominio in errore diverso rispetto alle normali applicazioni. Se hai bisogno di assistenza per la configurazione di nodi dedicati per il deployment di coredns, contatta l'assistenza clienti Google Cloud.

Problemi di scalabilità di MetalLB

MetalLB viene eseguito in modalità attiva-passiva, il che significa che in qualsiasi momento esiste un solo speaker MetalLB che gestisce un determinato VIP LoadBalancer.

Failover

Prima della release 1.28.0 di Google Distributed Cloud, su larga scala, il failover di MetalLB poteva richiedere molto tempo e presentare un rischio di affidabilità per il cluster.

Limiti di connessione

Se esiste un VIP LoadBalancer specifico, ad esempio un servizio Ingress, che prevede un numero di connessioni simultanee pari o superiore a 30.000, è probabile che il nodo speaker che gestisce il VIP esaurisca le porte disponibili. A causa di una limitazione dell'architettura, non esiste una mitigazione per questo problema da parte di MetalLB. Valuta la possibilità di passare al bilanciamento del carico in bundle con BGP prima della creazione del cluster o utilizza una classe Ingress diversa. Per saperne di più, consulta la sezione Configurazione di Ingress.

Speaker del bilanciatore del carico

Per impostazione predefinita, Google Distributed Cloud utilizza lo stesso pool di nodi del bilanciatore del carico sia per il control plane sia per il data plane. Se non specifichi un pool di nodi del bilanciatore del carico (loadBalancer.nodePoolSpec), viene utilizzato il pool di nodi del control plane (controlPlane.nodePoolSpec).

Per aumentare il numero di speaker quando utilizzi il pool di nodi del control plane per il bilanciamento del carico, devi aumentare il numero di macchine del control plane. Per i deployment in produzione, ti consigliamo di utilizzare tre nodi del control plane per l'alta affidabilità. Aumentare il numero di nodi del control plane oltre tre per supportare speaker aggiuntivi potrebbe non essere un buon utilizzo delle risorse.

Configurazione Ingress

Se prevedi quasi 30.000 connessioni simultanee in un unico VIP del servizio LoadBalancer, MetalLB potrebbe non essere in grado di supportarle.

Puoi valutare la possibilità di esporre il VIP tramite altri meccanismi, come F5 BIG-IP. In alternativa, puoi creare un nuovo cluster utilizzando il bilanciamento del carico integrato con BGP, che non ha la stessa limitazione.

Ottimizza i componenti di Cloud Logging e Cloud Monitoring

Nei cluster di grandi dimensioni, a seconda dei profili dell'applicazione e del pattern di traffico, le configurazioni delle risorse predefinite per i componenti Cloud Logging e Cloud Monitoring potrebbero non essere sufficienti. Per istruzioni su come ottimizzare le richieste e i limiti di risorse per i componenti di osservabilità, consulta Configurazione delle risorse dei componenti Stackdriver.

In particolare, kube-state-metrics nei cluster con un numero elevato di servizi ed endpoint potrebbe causare un utilizzo eccessivo della memoria utilizzata sia su kube-state-metrics stesso sia su gke-metrics-agent nello stesso nodo. L'utilizzo delle risorse di metrics-server può anche fare lo scale in termini di nodi, pod e servizi. Se riscontri problemi di risorse su questi componenti, contatta l'assistenza clienti Google Cloud.

Utilizza sysctl per configurare il sistema operativo

Ti consigliamo di ottimizzare la configurazione del sistema operativo per i nodi in modo che si adatti al meglio al caso d'uso del tuo workload. I parametri fs.inotify.max_user_watches e fs.inotify.max_user_instances che controllano il numero di risorse inotify spesso devono essere ottimizzati. Ad esempio, se visualizzi messaggi di errore come i seguenti, potresti provare a verificare se questi parametri devono essere ottimizzati:

The configured user limit (128) on the number of inotify instances has been reached

ENOSPC: System limit for number of file watchers reached...

L'ottimizzazione di solito varia in base ai tipi di workload e alla configurazione hardware. Puoi consultare il tuo fornitore del sistema operativo per informazioni sulle best practice specifiche per il sistema operativo.

Best practice

Questa sezione descrive le best practice per lo scale up del cluster.

Scala una dimensione alla volta

Per ridurre al minimo i problemi e semplificare il rollback delle modifiche, non modificare più di una dimensione alla volta. Lo scale up di più dimensioni contemporaneamente può causare problemi anche nei cluster più piccoli. Ad esempio, il tentativo di aumentare il numero di pod pianificati per nodo a 110 e contemporaneamente il numero di nodi nel cluster a 250 probabilmente non andrà a buon fine perché il numero di pod, il numero di pod per nodo e il numero di nodi sono troppo elevati.

Scala i cluster in più fasi

Lo scale up di un cluster può richiedere un utilizzo intensivo delle risorse. Per ridurre il rischio di errori delle operazioni del cluster o di interruzioni dei workload del cluster, sconsigliamo di tentare di creare cluster di grandi dimensioni con molti nodi in un'unica operazione.

Crea cluster ibridi o autonomi senza nodi worker

Se stai creando un cluster ibrido o autonomo di grandi dimensioni con più di 50 nodi worker, è meglio creare prima un cluster ad alta affidabilità (HA) con nodi del control plane e poi fare lo scale up gradualmente. L'operazione di creazione del cluster utilizza un cluster di bootstrap, che non è ad alta affidabilità e quindi è meno affidabile. Una volta creato il cluster autonomo o ibrido ad alta affidabilità, puoi utilizzarlo per fare lo scale up di altri nodi.

Aumenta il numero di nodi worker in batch

Se stai espandendo un cluster per aggiungere altri nodi worker, è meglio farlo in più fasi. Ti consigliamo di non aggiungere più di 20 nodi alla volta. Questo è particolarmente vero per i cluster che eseguono workload critici.

Abilita i pull di immagini paralleli

Per impostazione predefinita, kubelet esegue il pull delle immagini in serie, una dopo l'altra. Se la connessione upstream al server del registry delle immagini è scadente, un pull di immagini non riuscito può bloccare l'intera coda per un determinato pool di nodi.

Per mitigare questo problema, ti consigliamo di impostare serializeImagePulls su false nella configurazione kubelet personalizzata. Per istruzioni e ulteriori informazioni, consulta Configura le impostazioni di pull delle immagini kubelet. L'abilitazione dei pull di immagini in parallelo può introdurre picchi nel consumo della larghezza di banda della rete o dell'I/O del disco.

Ottimizza le richieste e i limiti delle risorse dell'applicazione

In ambienti densamente popolati, i workload delle applicazioni potrebbero essere rimossi. Kubernetes utilizza il meccanismo di riferimento per classificare i pod in caso di espulsione.

Una buona pratica per impostare le risorse dei container è utilizzare la stessa quantità di memoria per richieste e limiti e un limite di CPU più elevato o illimitato. Per saperne di più, consulta Prepara le applicazioni Kubernetes basate su cloud nel Cloud Architecture Center.

Utilizza un partner di archiviazione

Ti consigliamo di utilizzare uno dei partner di archiviazione GDC Ready per i deployment su larga scala. È importante verificare le seguenti informazioni con il partner di archiviazione specifico:

  • I deployment di archiviazione seguono le best practice per gli aspetti di archiviazione, come alta affidabilità, impostazione della priorità, affinità dei nodi e richieste e limiti delle risorse.
  • La versione di archiviazione è qualificata con la versione specifica di Google Distributed Cloud.
  • Il fornitore di spazio di archiviazione può supportare l'alta scalabilità che vuoi implementare.

Configura i cluster per l'alta affidabilità

È importante controllare il deployment su larga scala e assicurarsi che i componenti critici siano configurati per l'alta affidabilità, ove possibile. Google Distributed Cloud supporta opzioni di deployment ad alta affidabilità per tutti i tipi di cluster. Per saperne di più, consulta Scegli un modello di deployment. Per esempi di file di configurazione del cluster di deployment ad alta affidabilità, consulta Esempi di configurazione del cluster.

È anche importante controllare altri componenti, tra cui:

  • Fornitore di spazio di archiviazione
  • Webhook del cluster

Monitoraggio dell'utilizzo delle risorse

Questa sezione fornisce alcuni suggerimenti di base per il monitoraggio di cluster su larga scala.

Monitora attentamente le metriche di utilizzo

È fondamentale monitorare l'utilizzo sia dei nodi che dei singoli componenti del sistema e assicurarsi che abbiano un margine di sicurezza confortevole. Per scoprire quali funzionalità di monitoraggio standard sono disponibili per impostazione predefinita, consulta Utilizza le dashboard predefinite.

Monitora il consumo della larghezza di banda

Monitora attentamente il consumo di larghezza di banda per assicurarti che la rete non sia satura, il che comporta un peggioramento delle prestazioni del cluster.

Migliora le prestazioni di etcd

La velocità del disco è fondamentale per le prestazioni e la stabilità di etcd. Un disco lento aumenta la latenza delle richieste etcd, il che può causare problemi di stabilità del cluster. Per migliorare le prestazioni del cluster, Google Distributed Cloud archivia gli oggetti Event in un'istanza etcd separata e dedicata. L'istanza etcd standard utilizza /var/lib/etcd come directory di dati e la porta 2379 per le richieste dei client. L'istanza etcd-events utilizza /var/lib/etcd-events come directory di dati e la porta 2382 per le richieste dei client.

Ti consigliamo di utilizzare un disco a stato solido (SSD) per gli archivi etcd. Per prestazioni ottimali, monta dischi separati su /var/lib/etcd e /var/lib/etcd-events. L'utilizzo di dischi dedicati garantisce che le due istanze etcd non condividano l'I/O del disco.

La documentazione di etcd fornisce ulteriori consigli sull'hardware per garantire le migliori prestazioni di etcd durante l'esecuzione dei cluster in produzione.

Per controllare le prestazioni di etcd e del disco, utilizza le seguenti metriche di latenza di I/O di etcd in Metrics Explorer:

  • etcd_disk_backend_commit_duration_seconds: la durata deve essere inferiore a 25 millisecondi per il 99° percentile (p99).
  • etcd_disk_wal_fsync_duration_seconds: la durata deve essere inferiore a 10 millisecondi per il 99° percentile (p99).

Per ulteriori informazioni sulle prestazioni di etcd, consulta Cosa significa l'avviso etcd "apply entries took too long"? e Cosa significa l'avviso etcd "failed to send out heartbeat on time"?.

Se hai bisogno di ulteriore assistenza, contatta l'assistenza clienti Google Cloud. Puoi anche consultare Assistenza per ulteriori informazioni sulle risorse di assistenza, tra cui:

  • Requisiti per l'apertura di una richiesta di assistenza.
  • Strumenti per aiutarti a risolvere i problemi, ad esempio la configurazione dell'ambiente, i log e le metriche.
  • Componenti supportati.

Passaggi successivi