Fai lo scale up di GKE su cluster Bare Metal

Come qualsiasi cluster Kubernetes, la scalabilità dei cluster GKE su Bare Metal ha molte dimensioni correlate. Questo documento ha lo scopo di aiutarti a comprendere le dimensioni chiave che puoi modificare per fare lo scale up dei cluster senza interrompere i carichi di lavoro.

Comprendere i limiti

GKE su Bare Metal è un sistema complesso con un'ampia superficie di integrazione. Sono molte le dimensioni che influiscono sulla scalabilità del cluster. Ad esempio, il numero di nodi è solo una delle numerose dimensioni su cui è possibile scalare GKE su Bare Metal. 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 hanno effetto sulla scalabilità, consulta Soglie di scalabilità di Kubernetes nella sezione Scalability Special Interest Group (SIG) del repository della community Kubernetes su GitHub.

I limiti di scalabilità sono sensibili anche 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 che si applicano ai tuoi cluster GKE su Bare Metal, consulta Quote e limiti.

Preparati alla scalabilità

Mentre ti prepari a scalare GKE sui cluster Bare Metal, considera i requisiti e le limitazioni descritti nelle sezioni seguenti.

Requisiti di CPU e memoria del nodo del piano di controllo

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

Numero di nodi del cluster CPU del piano di controllo 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 dalle seguenti impostazioni:

CIDR pod e numero massimo di nodi

Il numero totale di indirizzi IP riservati ai pod nel cluster è uno dei fattori limitati per lo scale up del cluster. Questa impostazione, insieme all'impostazione relativa al 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 ai pod nel cluster è specificato con clusterNetwork.pods.cidrBlocks, che prende un intervallo di indirizzi IP specificati nella notazione CIDR. Ad esempio, il valore precompilato 192.168.0.0/16 specifica un intervallo di 65.536 indirizzi IP dal giorno 192.168.0.0 al giorno 192.168.255.255.

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

  • In base all'impostazione del numero massimo di pod per nodo, GKE su Bare Metal esegue il provisioning di circa il doppio degli indirizzi IP per il nodo. Gli indirizzi IP aggiuntivi aiutano a prevenire il riutilizzo involontario degli IP dei pod in un breve lasso 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 tuo cluster.

Ad esempio, se il CIDR del pod è 192.168.0.0/17, avrai un totale di 32.768 indirizzi IP (2(32-17) = 215 = 32.768). Se imposti il numero massimo di pod per nodo su 250, GKE su Bare Metal esegue il provisioning di un intervallo di circa 500 indirizzi IP, che equivale all'incirca 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 tuo cluster per evitare di esaurire la capacità dei nodi. Per i valori massimi consigliati per 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 allo scale up del cluster. Tuttavia, non puoi ridurre l'intervallo CIDR del servizio. Per saperne di più, consulta Aumentare l'intervallo di rete dei servizi.

Risorse riservate per i daemon di sistema

Per impostazione predefinita, GKE su Bare Metal prenota automaticamente le risorse su un nodo per i 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 abbiano le risorse necessarie. Senza questa funzionalità, i pod possono consumare la maggior parte delle risorse su un nodo, rendendo impossibile il completamento delle attività dei daemon di sistema.

Nello specifico, GKE su Bare Metal riserva 80 millicore di CPU (80 mCPU) e 280 mebibyte (280 MiB) di memoria su ciascun nodo per i daemon di sistema. Tieni presente che l'unità CPU mCPU è un millesimo di core, quindi l'80/1000 o l'8% di un core su ciascun nodo è riservato ai daemon di sistema. La quantità di risorse prenotate è ridotta e non ha un impatto significativo sulle prestazioni dei pod. Tuttavia, il kubelet su un nodo può rimuovere i pod se l'utilizzo di CPU o memoria supera le quantità allocate.

Networking con MetalLB

Ti consigliamo di aumentare il numero di speaker MetalLB per tenere conto dei seguenti aspetti:

  • Larghezza di banda: l'intera larghezza di banda del cluster per i servizi di bilanciamento del carico dipende dal numero di speaker e dalla larghezza di banda di ciascun nodo speaker. Un maggiore traffico di rete richiede più altoparlanti.

  • Tolleranza di errore: un numero maggiore di altoparlanti riduce l'impatto complessivo di un guasto di un singolo altoparlante.

MetalLB richiede la connettività di livello 2 tra i nodi di bilanciamento del carico. In questo caso, potresti essere vincolato dal numero di nodi con connettività di livello 2 in cui puoi attivare gli speaker MetalLB.

Pianifica attentamente il numero di speaker MetalLB che vuoi avere nel cluster e determina il numero di nodi di livello 2 necessario. Per maggiori informazioni, consulta la pagina relativa ai problemi di scalabilità di MetalLB.

Separatamente, quando utilizzi la modalità di bilanciamento del carico in bundle, anche i nodi del piano di controllo devono trovarsi nella stessa rete di livello 2. Il bilanciamento del carico manuale non ha questa limitazione. Per saperne di più, consulta la sezione Modalità bilanciatore del carico manuale.

Esecuzione di molti nodi, pod e servizi

L'aggiunta di nodi, pod e servizi è un modo per fare lo scale up del tuo cluster. Le sezioni seguenti illustrano alcune impostazioni e configurazioni aggiuntive che devi prendere in considerazione quando aumenti il numero di nodi, pod e servizi nel cluster. Per informazioni sui limiti di queste dimensioni e sulla loro relazione tra loro, consulta Limiti.

Crea un cluster senza kube-proxy

Per creare un cluster ad alte prestazioni con possibilità di scale up 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 numero elevato di regole iptables.

Non puoi disabilitare 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 Creare un cluster senza kube-proxy.

Configurazione CoreDNS

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

DNS pod

Per impostazione predefinita, i cluster GKE su Bare Metal inseriscono pod con un valore 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 vengono considerati un nome di dominio completo (FQDN). Il server DNS aggiunge tutti i domini di ricerca specificati prima di cercare il nome host richiesto in origine, ordinando le ricerche come la seguente 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), generando 12 richieste DNS per ogni query non FQDN, il che amplifica in modo significativo il traffico DNS. Per limitare questo problema, ti consigliamo di dichiarare il nome host da cercare come nome di dominio completo aggiungendo un punto finale (google.com.). Questa dichiarazione deve essere eseguita a livello di carico di lavoro dell'applicazione. Per ulteriori informazioni, consulta la pagina manuale di resolv.conf.

IPv6

Se il cluster non utilizza IPv6, puoi dimezzare le richieste DNS eliminando la ricerca di record AAAA verso il 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

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 aiuto per configurare nodi dedicati per il deployment di coredns, contatta l'assistenza clienti Google Cloud.

Problemi di scalabilità MetalLB

MetalLB funziona in modalità attiva-passiva, il che significa che in qualsiasi momento esiste un solo altoparlante MetalLB che gestisce un particolare VIP LoadBalancer.

Failover

Prima della release 1.28.0 di GKE su Bare Metal 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 più di 30.000 connessioni simultanee o più di 30.000, è probabile che il nodo altoparlante che gestisce il VIP possa escludere le porte disponibili. A causa di una limitazione dell'architettura, MetalLB non consente di mitigare questo problema. Valuta la possibilità di passare al bilanciamento del carico in bundle con BGP prima della creazione del cluster o di utilizzare una classe in entrata diversa. Per ulteriori informazioni, consulta la pagina relativa alla configurazione in entrata.

Speaker bilanciatore del carico

Per impostazione predefinita, GKE su Bare Metal 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).

Per aumentare il numero di speaker quando utilizzi il pool di nodi del piano di controllo per il bilanciamento del carico, devi aumentare il numero di macchine del piano di controllo. Per i deployment di produzione, consigliamo di utilizzare tre nodi del piano di controllo per garantire l'alta disponibilità. Aumentare il numero di nodi del piano di controllo oltre i tre per ospitare altri speaker potrebbe non essere un buon uso delle tue risorse.

Configurazione in entrata

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

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 in bundle 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 modello 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 di risorse e i limiti per i componenti di osservabilità, consulta Configurazione delle risorse del componente Stackdriver.

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

Utilizza sysctl per configurare il tuo sistema operativo

Ti consigliamo di perfezionare la configurazione del sistema operativo per i nodi in modo da soddisfare al meglio il caso d'uso del tuo carico di lavoro. I parametri fs.inotify.max_user_watches e fs.inotify.max_user_instances che controllano il numero di risorse inotify spesso richiedono l'ottimizzazione. Ad esempio, se vengono visualizzati messaggi di errore come il seguente, prova a verificare se questi parametri devono essere corretti:

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 solitamente varia in base ai tipi di carichi di lavoro e alla configurazione hardware. Puoi consultare le best practice specifiche del sistema operativo con il tuo fornitore.

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 in cluster più piccoli. Ad esempio, è probabile che il tentativo di aumentare il numero di pod pianificati per nodo a 110, aumentando al contempo il numero di nodi nel cluster a 250 non vada a buon fine perché il numero di pod, il numero di pod per nodo e il numero di nodi sono troppo estesi.

Scala i cluster in più fasi

Lo scale up di un cluster può richiedere molte risorse. Per ridurre il rischio che le operazioni dei cluster non vadano a buon fine o che i relativi carichi di lavoro vengano interrotti, consigliamo di non tentare di creare cluster di grandi dimensioni con molti nodi in una singola 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, è preferibile creare prima un cluster ad alta disponibilità con nodi del piano di controllo e poi scale up graduale. L'operazione di creazione del cluster utilizza un cluster di bootstrap, che non è ad alta disponibilità e quindi è meno affidabile. Dopo aver creato il cluster ibrido o autonomo ad alta disponibilità, puoi utilizzarlo per fare lo scale up fino a più nodi.

Aumenta il numero di nodi worker in batch

Se stai espandendo un cluster a più nodi worker, è meglio farlo per fasi. Ti consigliamo di aggiungere non più di 20 nodi alla volta. Ciò è particolarmente vero 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 hai una connessione upstream non corretta al server del registro di immagini, un pull non valido può bloccare l'intera coda per un determinato pool di nodi.

Per limitare questo problema, ti consigliamo di impostare serializeImagePulls su false nella configurazione kubelet personalizzata. Per istruzioni e ulteriori informazioni, consulta Configurare le impostazioni di pull delle immagini kubelet. L'abilitazione dei pull delle immagini parallele 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 compressi, i carichi di lavoro delle applicazioni potrebbero essere rimossi. Kubernetes utilizza il meccanismo di riferimento per classificare i pod in caso di rimozione.

Una buona norma per impostare le risorse del container consiste nell'utilizzare la stessa quantità di memoria per richieste e limiti e un limite di CPU maggiore o illimitato. Per ulteriori informazioni, consulta Preparare le applicazioni Kubernetes basate su cloud nel Cloud Architecture Center.

Utilizzare un partner di archiviazione

Ti consigliamo di utilizzare uno dei partner per l'archiviazione GDCV Ready per le implementazioni 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 dell'archiviazione, come alta disponibilità, impostazione della priorità, affinità dei nodi e richieste e limiti di risorse.
  • La versione di archiviazione è qualificata con la particolare versione GKE su Bare Metal.
  • Il fornitore dello spazio di 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 assicurarsi che i componenti critici siano configurati per l'alta disponibilità ove possibile. GKE su Bare Metal supporta opzioni di deployment ad alta disponibilità per tutti i tipi di cluster. Per ulteriori informazioni, consulta Scegliere un modello di deployment. Ad esempio, i file di configurazione dei cluster dei deployment ad alta disponibilità, consulta Esempi di configurazione dei cluster.

È importante anche controllare altri componenti, tra cui:

  • Fornitore di archiviazione
  • Webhook del cluster

Monitoraggio dell'utilizzo delle risorse

Questa sezione fornisce alcuni suggerimenti di monitoraggio di base per i 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 visualizzare le funzionalità di monitoraggio standard disponibili per impostazione predefinita, consulta Utilizzare dashboard predefinite.

Monitora il consumo della larghezza di banda

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

Miglioramento delle prestazioni etcd

La velocità del disco è fondamentale per le prestazioni e la stabilità etcd. Un disco lento aumenta la latenza di richiesta etcd, il che può portare a problemi di stabilità del cluster. Per migliorare le prestazioni del cluster, GKE su Bare Metal archivia gli oggetti Evento in un'istanza etcd dedicata e separata. L'istanza etcd standard utilizza /var/lib/etcd come directory dei dati e porta 2379 per le richieste del client. L'istanza etcd-events utilizza /var/lib/etcd-events come directory dei dati e porta 2382 per le richieste del client.

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

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

Per verificare le prestazioni etcd e del disco, utilizza le seguenti metriche della latenza etcd in Metrics Explorer:

  • etcd_disk_backend_commit_duration_seconds: la durata dovrebbe 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 significa l'avviso etcd "applicare le voci hanno richiesto troppo tempo" e Che cosa significa l'avviso etcd "non è stato possibile inviare l'heartbeat in tempo".

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

Che cosa succede dopo?