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 dimensioni chiave che puoi regolare per fare lo scale up dei tuoi cluster senza interrompere per i carichi di lavoro.

Comprendere i limiti

Google Distributed Cloud è un sistema complesso con un'ampia superficie di integrazione. Là sono molte dimensioni che influiscono sulla scalabilità del cluster. Ad esempio, il numero nodi è solo una delle numerose dimensioni su cui Google Distributed Cloud può scalare. Altre dimensioni includono il numero totale di pod e servizi. Molti di questi come il numero di pod per nodo e il numero di nodi per sono interconnessi. Per ulteriori informazioni sulle dimensioni con un effetto sulla scalabilità, vedi Scalabilità di Kubernetes soglie nella sezione Scalability Special Interest Group (SIG) del modulo Kubernetes il repository della community su GitHub.

I limiti di scalabilità sono sensibili anche alla configurazione hardware e dei nodi presenti in esecuzione dal cluster. I limiti descritti in questo documento sono verificati in un ambiente probabilmente diverso dal tuo. Pertanto, potrebbero non riprodurre gli stessi numeri quando l'ambiente sottostante fattore limitante.

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

Preparati alla scalabilità

Quando ti prepari a scalare i tuoi cluster Google Distributed Cloud, prendi in considerazione le ai requisiti e alle limitazioni descritti nelle sezioni che seguono.

Requisiti di CPU e memoria del nodo del piano di controllo

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

Numero di nodi del cluster CPU consigliate per il piano di controllo 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 pod e numero massimo di nodi

Il numero totale di indirizzi IP prenotati per i pod nel cluster è uno dei fattori che limitano lo scale up del cluster. Questa impostazione, insieme per il numero massimo di pod per nodo determina il numero massimo di nodi che possono 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 circa il doppio degli indirizzi IP al nodo. Gli indirizzi IP aggiuntivi per impedire il riutilizzo involontario degli IP dei pod in un breve arco di tempo.

  • Dividere il numero totale di indirizzi IP dei pod per il numero di IP di pod di indirizzi IP sottoposti a provisioning su ciascun nodo fornisce il numero totale di nodi di cui che possono avere nel tuo cluster.

Ad esempio, se il CIDR del tuo pod è 192.168.0.0/17, il totale è 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). 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 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 fai lo scale up in un cluster Kubernetes. 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. Nota che l'unità CPU mCPU rappresenta il millesimo di core, quindi 80/1000 o 8% di core su ciascun nodo sono riservati ai daemon di sistema. L'importo delle prenotazioni è di dimensioni ridotte e non ha un impatto significativo sulle prestazioni dei pod. Tuttavia, il kubelet su un nodo può rimuovere i pod se il relativo utilizzo di CPU o memoria superi gli importi assegnati loro.

Networking con MetalLB

Può essere utile aumentare il numero di altoparlanti MetalLB per risolvere i seguenti problemi: 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. Nella In questo caso, potresti essere limitato dal numero di nodi con connettività di livello 2 su cui puoi mettere gli altoparlanti 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.

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

Esecuzione di molti nodi, pod e servizi

L'aggiunta di nodi, pod e servizi consente di fare lo scale up del cluster. La le seguenti sezioni trattano alcune impostazioni e configurazioni aggiuntive considerare quando aumenti il numero di nodi, pod e servizi in un cluster Kubernetes. Per informazioni sui limiti di queste dimensioni e su come sono correlate tra loro, vedi Limiti.

Crea un cluster senza kube-proxy

Creare un cluster ad alte prestazioni con possibilità di scale up per utilizzare un numero elevato Per i servizi e gli 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 disabilitare l'utilizzo di kube-proxy per un cluster esistente. Questo al momento della creazione del cluster. Per istruzioni e Per ulteriori informazioni, consulta Creare un cluster senza kube-proxy.

Configurazione CoreDNS

Questa sezione descrive gli aspetti di CoreDNS che influenzano la scalabilità 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 significa che i nomi host con meno di 5 punti non sono considerato un nome di dominio completo (FQDN). Il server DNS aggiunge tutte le 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

Ciascuna ricerca viene eseguita per IPv4 (record A) e IPv6 (record AAAA), generando 12 richieste DNS per ogni query non FQDN, che significativamente amplifica 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 maggiori informazioni informazioni, vedi l'uomo resolv.conf alla pagina di destinazione.

IPv6

Se il cluster non utilizza IPv6, è possibile ridurre le richieste DNS eliminando la ricerca del record AAAA nel server DNS upstream. 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 Il deployment rientra in un dominio in 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 del rilascio della versione 1.28.0 di Google Distributed Cloud, su larga scala, MetalLB potrebbe richiedere molto tempo e presentare un rischio di affidabilità in un cluster Kubernetes.

Limiti di connessione

Se è presente un VIP LoadBalancer specifico, ad esempio un servizio Ingress, prevede circa 30.000 connessioni simultanee, o più di 30.000, è probabile che il nodo dello speaker che gestisce il VIP potrebbe esaurire lo scarico disponibile diverse. A causa di una limitazione dell'architettura, non esiste alcuna mitigazione del problema da parte di MetalLB. Valuta la possibilità di passare a il bilanciamento del carico in bundle con BGP prima creazione del cluster o utilizzare una classe in entrata diversa. Per ulteriori informazioni, vedi Configurazione in entrata.

Speaker con bilanciatore del carico

Per impostazione predefinita, Google Distributed Cloud utilizza lo stesso pool di nodi del bilanciatore del carico per tra il piano di controllo e il piano dati. Se non specifichi un nodo del bilanciatore del carico piscina (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 di produzione, consigliamo di utilizzare tre nodi del piano di controllo 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 che circa 30.000 connessioni simultanee arrivano in un singolo LoadBalancer Service VIP, MetalLB potrebbe non essere in grado di supportarlo.

Puoi prendere in considerazione l'esposizione del VIP tramite altri meccanismi, ad esempio 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 sull'ottimizzazione richieste e limiti di risorse per i componenti di osservabilità, consulta Configurazione del componente Stackdriver Google Cloud.

In particolare, kube-state-metrics nei cluster con un numero elevato di servizi ed endpoint potrebbero causare un utilizzo eccessivo di memoria sia kube-state-metrics e gke-metrics-agent sullo stesso nodo. La l'utilizzo delle risorse di Metrics-server può anche fare lo scale in termini di nodi, pod Servizi. Se riscontri problemi relativi alle risorse su questi componenti, contatta Assistenza clienti Google Cloud.

Utilizza sysctl per configurare il sistema operativo

Ti consigliamo di ottimizzare la configurazione del sistema operativo per i tuoi nodi in modo da adattarsi al meglio 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 notifiche 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 carichi di lavoro e alla configurazione hardware. Puoi consultare il fornitore del sistema operativo in merito alle best practice specifiche per il sistema operativo.

Best practice

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

Scalare una dimensione alla volta

Per ridurre al minimo i problemi e semplificare il rollback delle modifiche, non modificare ulteriormente più di una dimensione alla volta. Fare lo scale up di più dimensioni contemporaneamente può causare problemi anche in cluster più piccoli. Ad esempio, se provi ad aumentare di pod pianificati per nodo 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.

Scala i cluster in più fasi

Lo scale up di un cluster può richiedere molte risorse. per ridurre il rischio di cluster se le operazioni non funzionano o i carichi di lavoro del cluster subiscono interruzioni, consigliamo di 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 un cluster ad alta disponibilità dei nodi del piano di controllo, per poi fare lo scale up graduale. 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 utilizzare fare lo scale up a più nodi.

Aumentare il numero di nodi worker in batch

Se stai espandendo un cluster a più nodi worker, è meglio espanderlo in fasi iniziali. Ti consigliamo di aggiungere non più di 20 nodi alla volta. Questo è in particolare per i cluster che eseguono carichi di lavoro critici.

Abilita il pull di immagini parallele

Per impostazione predefinita, kubelet estrae le immagini in modo seriale, 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, vedi Configura le impostazioni pull 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 ad alta densità, i carichi di lavoro delle applicazioni potrebbero essere rimossi. Kubernetes utilizza il meccanismo di riferimento per classificare i pod in caso di eliminazione.

Una buona pratica per impostare le risorse container è utilizzare la stessa quantità di memoria per richieste e limiti e un limite di CPU maggiore 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 confermare le seguenti informazioni con lo spazio di archiviazione specifico partner:

  • I deployment di archiviazione seguono le best practice per gli aspetti di archiviazione, come disponibilità elevata, impostazione della priorità, affinità dei nodi e richieste di risorse e limiti.
  • La versione di archiviazione è qualificata con lo specifico Google Distributed Cloud completamente gestita.
  • Il fornitore dell'archiviazione può supportare l'alta scalabilità di cui vuoi eseguire il deployment.

Configura 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 cluster di configurazione dei deployment ad alta disponibilità, Esempi di configurazione dei cluster.

È importante anche 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 su larga scala cluster.

Monitora attentamente le metriche di utilizzo

È fondamentale monitorare l'utilizzo sia dei nodi che del singolo sistema componenti e assicurarsi che abbiano un margine sicuro. Per vedere cosa le funzionalità di monitoraggio standard sono disponibili per impostazione predefinita; consulta Utilizzo dashboard.

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à etcd. Un disco lento aumenta latenza di richiesta etcd, che può portare a problemi di stabilità del cluster. A migliorare le prestazioni dei cluster, Google Distributed Cloud archivia gli oggetti Event in un un'istanza etcd dedicata separata. 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 archivi etcd. Per per ottenere prestazioni ottimali, montare 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 etcd fornisce ulteriori consigli hardware per garantire le migliori prestazioni etcd durante l'esecuzione dei cluster in produzione.

Per controllare le prestazioni etcd e del disco, utilizza la seguente latenza di I/O etcd in Esplora metriche:

  • 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 etcd, consulta Che cosa comporta l'avviso etcd "applicazione voci ha richiesto troppo tempo" significa? e Che cosa indica l'avviso etcd "non ha inviato l'heartbeat in tempo?" media?.

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

Passaggi successivi