Fai lo scale up dei cluster Google Distributed Cloud

Come per qualsiasi cluster Kubernetes, la scalabilità dei cluster Google Distributed Cloud ha molti dimensioni correlate. Lo scopo di questo documento è aiutarti a comprendere le dimensioni chiave che puoi modificare per eseguire lo scaling dei tuoi cluster senza interrompere i carichi di lavoro.

Comprendere i limiti

Google Distributed Cloud è un sistema complesso con una vasta superficie di integrazione. Là esistono molte dimensioni che influiscono sulla scalabilità del cluster. Ad esempio, il numero di nodi è solo una delle molte 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 ulteriori informazioni sulle dimensioni che influiscono sulla scalabilità, consulta le soglie di scalabilità di Kubernetes nella sezione del gruppo di interesse speciale (SIG) sulla scalabilità del repository della community Kubernetes su GitHub.

I limiti di scalabilità sono sensibili anche all'hardware e alla configurazione dei nodi su cui è in esecuzione il cluster. I limiti descritti in questo documento vengono verificati in un ambiente probabilmente diverso dal tuo. Di conseguenza, potresti non riprodurre gli stessi numeri quando l'ambiente di base è il fattore limitante.

Per ulteriori informazioni sui limiti che si applicano ai tuoi cluster Google Distributed Cloud, consulta Quote e limiti.

Prepararsi alla scalabilità

Quando ti prepari a scalare i tuoi cluster Google Distributed Cloud, considera la ai requisiti e alle limitazioni descritti nelle sezioni che seguono.

Requisiti di CPU e memoria del nodo del control plane

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

Numero di nodi del cluster CPU del control plane consigliate Memoria consigliata per il piano di controllo
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 tuoi cluster è controllato le seguenti impostazioni:

CIDR del pod e numero massimo di nodi

Il numero totale di indirizzi IP prenotati per i pod nel tuo cluster è uno dei fattori che limitano lo scale up del cluster. Questa impostazione, insieme all'impostazione 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 prenotati per i pod nel cluster è specificato con clusterNetwork.pods.cidrBlocks, che accetta un intervallo di indirizzi IP specificati in CIDR non standard. Ad esempio, il valore precompilato 192.168.0.0/16 specifica un intervallo di 65.536 IP indirizzi 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 per impedire il riutilizzo involontario degli IP dei pod in un breve arco di tempo.

  • Se dividi 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 parametro di pod per nodo fino a 250, esegue il provisioning di un intervallo di circa 500 indirizzi IP, ovvero equivalente a un blocco CIDR /23 (2(32-23) = 29 = 512). Pertanto, 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 con attenzione la crescita futura del tuo cluster evitare di esaurire la capacità del nodo. Per i valori massimi consigliati per i pod per cluster, pod per nodo e nodi per cluster in base ai test, consulta Limiti.

CIDR servizio

Il CIDR del servizio può essere aggiornato per aggiungere altri servizi man mano che esegui l'upgrade del cluster. Tuttavia, non puoi ridurre l'intervallo CIDR del servizio. Per maggiori informazioni informazioni, consulta Aumentare la rete di servizi intervallo.

Risorse riservate per i daemon di sistema

Per impostazione predefinita, Google Distributed Cloud prenota automaticamente risorse su un nodo per daemon di sistema, come sshd o udev. Le risorse di CPU e memoria sono riservate su un nodo per i daemon di sistema in modo che questi daemon abbiano le risorse che ti servono. Senza questa funzionalità, i pod possono potenzialmente consumare la maggior parte risorse su un nodo, rendendo impossibile per i daemon di sistema attività di machine learning.

Nello specifico, Google Distributed Cloud riserva 80 millicore di CPU (80 mCPU) e 280 mebibyte (280 MiB) di memoria su ciascun nodo per i daemon di sistema. Tieni conto che l'unità CPU mCPU indica un millesimo di core, quindi 80/1000 o l'8% di un core su ogni nodo è riservato ai demoni di sistema. L'importo delle prenotazioni è di dimensioni ridotte e non ha un impatto significativo sulle prestazioni dei pod. Tuttavia, kubelet su un nodo potrebbe espellere i pod se il loro utilizzo di CPU o memoria supera le quantità che sono state loro allocate.

Networking con MetalLB

Ti consigliamo di aumentare il numero di speaker MetalLB per gestire i seguenti aspetti:

  • Larghezza di banda: l'intera larghezza di banda del cluster per i servizi di bilanciamento del carico dipende in base al numero di speaker e alla larghezza di banda di ciascun nodo. Aumentata per il traffico di rete sono necessari più altoparlanti.

  • Tolleranza di errore: più altoparlanti riducono l'impatto complessivo di un singolo guasto dell'altoparlante.

MetalLB richiede connessioni 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 installare gli speaker MetalLB.

Pianifica con attenzione il numero di speaker MetalLB che vuoi avere nel tuo cluster e determinare quanti nodi di livello 2 ti servono. Per ulteriori informazioni, vedi Problemi di scalabilità di MetalLB.

Inoltre, quando utilizzi la modalità di bilanciamento del carico in bundle, i nodi del piano di controllo devono trovarsi anche nella stessa rete di livello 2. Il bilanciamento del carico manuale non questa restrizione. Per maggiori informazioni, vedi Modalità del bilanciatore del carico manuale.

Eseguire molti nodi, pod e servizi

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

Crea un cluster senza kube-proxy

Per creare un cluster ad alte prestazioni che può essere scalato 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 gestire un ampio set di regole iptables.

Non puoi disattivare l'utilizzo di kube-proxy per un cluster esistente. Questo al momento della creazione del cluster. Per istruzioni e maggiori informazioni, vedi Creare 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 valore resolv.conf ha il seguente aspetto:

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 gli host name con meno di 5 punti non sono considerati un nome di dominio completo (FQDN). Il server DNS aggiunge tutti i parametri domini di ricerca specificati prima di cercare il nome host richiesto in origine, quali ordini vengono cercati nel seguente modo per risolvere 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), con un risultato di 12 richieste DNS per ogni query non FQDN, il che amplifica notevolmente il traffico DNS. Per limitare il problema, ti consigliamo di dichiarare per cercare come nome di dominio completo aggiungendo un punto finale (google.com.). Questo la dichiarazione deve essere eseguita a livello del carico di lavoro 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 a monte. Se hai bisogno di aiuto per disabilitare le ricerche di AAAA, contatta l'assistenza clienti Google Cloud.

Pool di nodi dedicato

Data la 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 di errore diverso rispetto alle normali applicazioni. Se hai bisogno di aiuto per configurare nodi dedicati per il deployment coredns, contatta all'assistenza clienti Google Cloud.

Problemi di scalabilità MetalLB

MetalLB funziona in modalità attivo-passivo, il che significa che in qualsiasi momento un solo altoparlante MetalLB che serve un particolare 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 poteva rappresentare un rischio di affidabilità per il cluster.

Limiti di connessione

Se esiste un determinato LoadBalancer VIP, ad esempio un servizio di ingresso, che si aspetta quasi o più di 30.000 connessioni simultanee, è probabile che il nodo speaker che gestisce il VIP possa esaurire le porte disponibili. A causa di una limitazione dell'architettura, non esiste alcuna 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 di ingresso diversa. Per ulteriori informazioni, vedi Configurazione in entrata.

Altoparlanti con bilanciatore del carico

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

Aumenta il numero di speaker quando utilizzi il pool di nodi del piano di controllo per il carico devi aumentare il numero di macchine del piano di controllo. Per le implementazioni di produzione, ti consigliamo di utilizzare tre nodi del piano di controllo per l'alta disponibilità. Aumentare il numero di nodi del piano di controllo oltre tre per altri relatori potrebbero non rappresentare un buon uso delle tue risorse.

Configurazione in entrata

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

Puoi prendere in considerazione l'esposizione dell'IP virtuale tramite altri meccanismi, come F5 BIG-IP. In alternativa, puoi creare un nuovo cluster utilizzando il bilanciamento del carico in bundle con BGP. che non ha lo stesso limitazione.

Ottimizza i componenti di Cloud Logging e Cloud Monitoring

In cluster di grandi dimensioni, a seconda dei profili delle applicazioni e del modello di traffico, le configurazioni predefinite delle risorse per Cloud Logging e I componenti di Cloud Monitoring potrebbero non essere sufficienti. Per istruzioni su come ottimizzare le richieste e i limiti delle risorse per i componenti di osservabilità, consulta Configurare le risorse dei componenti di Stackdriver.

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

Utilizzare sysctl per configurare il sistema operativo

Ti consigliamo di ottimizzare la configurazione del sistema operativo per i tuoi nodi più adatti al caso d'uso del carico di lavoro. Le fs.inotify.max_user_watches e fs.inotify.max_user_instances parametri che controllano il numero di e risorse spesso devono essere perfezionate. Ad esempio, se ricevi messaggi di errore come seguenti, puoi provare a vedere se questi parametri devono essere ottimizzato:

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 in genere varia in base ai tipi di carico di lavoro e alla configurazione hardware. Puoi rivolgerti al fornitore del sistema operativo per consultare le best practice specifiche per il sistema operativo.

Best practice

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

Scalare una dimensione alla volta

Per ridurre al minimo i problemi e semplificare il rollback delle modifiche, non modificare più di una dimensione alla volta. L'aumento di più dimensioni contemporaneamente può causare problemi anche in cluster più piccoli. Ad esempio, se provi ad aumentare di pod pianificati per nodo fino a 110, aumentando al contempo il numero di nodi probabilmente il cluster a 250 non avrà esito positivo perché il numero di pod, il numero di pod per nodo e il numero di nodi è troppo esteso.

Eseguire la scalabilità dei cluster in più fasi

L'aumento di un cluster può richiedere molte risorse. Per ridurre il rischio di fallimento delle operazioni del cluster o di interruzione dei carichi di lavoro del cluster, sconsigliamo di tentare di creare cluster di grandi dimensioni con molti nodi in un'unica operazione.

Creare 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 disponibilità (HA) con nodi del piano di controllo e poi eseguire gradualmente l'upgrade. La creazione del cluster utilizza un cluster di bootstrap, che non è ad alta disponibilità e pertanto è affidabile. Una volta creato il cluster ibrido o autonomo ad alta disponibilità, puoi utilizzarlo per eseguire lo scale up a più nodi.

Aumentare il numero di nodi worker in batch

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

Attivare i recuperi di immagini paralleli

Per impostazione predefinita, kubelet estrae le immagini in sequenza, una dopo l'altra. Se disponi di un connessione upstream al server del registro di immagini, un pull delle immagini non valido può blocca l'intera coda per un determinato pool di nodi.

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

Ottimizza le richieste e i limiti delle risorse delle applicazioni

In ambienti con un numero elevato di risorse, i carichi di lavoro delle applicazioni potrebbero essere espulsi. Kubernetes utilizza il meccanismo a cui si fa riferimento per classificare i pod in caso di espulsione.

Una buona pratica per impostare le risorse del container è utilizzare la stessa quantità di memoria per richieste e limiti e un limite della CPU più grande o illimitato. Per maggiori informazioni per informazioni, consulta Preparare i cluster Kubernetes applicazioni nel Cloud Architecture Center.

Utilizzare un partner di archiviazione

Ti consigliamo di utilizzare una delle risorse di archiviazione partner per implementazioni su larga scala. È importante verificare le seguenti informazioni con il partner di archiviazione specifico:

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

Configurare i cluster per l'alta disponibilità

È importante verificare il deployment su larga scala e assicurarti che sono configurati per l'alta disponibilità, ove possibile. Google Distributed Cloud supporta Opzioni di deployment ad alta disponibilità per tutti i tipi di cluster. Per ulteriori informazioni, consulta la sezione Scegliere un di deployment. Ad esempio, i file di configurazione dei cluster dei deployment HA, consulta Esempi di configurazione dei cluster.

È importante anche eseguire la revisione di altri componenti, tra cui:

  • Fornitore di servizi di archiviazione
  • Webhook del cluster

Monitoraggio dell'utilizzo delle risorse

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

Monitora attentamente le metriche di utilizzo

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

Monitorare il consumo della larghezza di banda

Monitorare attentamente il consumo di larghezza di banda per garantire che la rete saturato, con un conseguente 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 distinta e dedicata. L'istanza etcd standard utilizza /var/lib/etcd come directory dei dati e porta 2379 per le richieste del client. La L'istanza etcd-events utilizza /var/lib/etcd-events come directory e porta dei dati 2382 per le richieste del client.

Ti consigliamo di utilizzare un disco a stato solido (SSD) per gli store etcd. Per prestazioni ottimali, monta dischi separati su /var/lib/etcd e /var/lib/etcd-events. L'uso di dischi dedicati assicura che i due etcd non condividono l'I/O del disco.

La documentazione di etcd fornisce ulteriori consigli 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 sulla latenza 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 sul rendimento di etcd, consulta Che cosa significa l'avviso etcd "L'applicazione delle voci ha richiesto troppo tempo"? e Che cosa significa l'avviso etcd "Impossibile inviare il messaggio heartbeat in tempo"?.

Se hai bisogno di ulteriore assistenza, contatta l'assistenza clienti Google Cloud.

Passaggi successivi