• Home
  • Guide
  • Picchi di traffico senza pod in attesa: come Kubernetes scala da solo

Picchi Di Traffico Senza Pod in Attesa: Come Kubernetes Scala Da Solo

Un autotest di due minuti e un piano in quattro passi perché il cluster aggiunga capacità da solo nei picchi: dimensionare le request, aggiungere il Cluster Autoscaler, mescolare i pool di nodi e osservare i pod in attesa.

  • Kubernetes
  • Autoscaling
  • Operatività

Un cluster sereno durante un picco di traffico è una scelta di progetto, non fortuna. Lo schema è semplice: i pod scalano in base alla domanda e il cluster aggiunge in pochi minuti i nodi che servono. Questa guida vi offre un autotest di due minuti e i quattro passi che usiamo. Si basa su un progetto reale con una piattaforma di dati in tempo reale il cui traffico salta di milioni di richieste in pochi minuti.

Autotest di due minuti

Rispondete con sincerità:

  1. Quando il traffico raddoppia, i nuovi pod trovano un nodo o restano in Pending?
  2. Le request dei pod si basano su un uso misurato, per esempio il 95° percentile, o su una stima?
  3. Il cluster aggiunge nodi da solo e in quanto tempo girano i nuovi pod?
  4. Ricevete un allarme quando dei pod restano in Pending?
  5. Quale parte della capacità può girare su istanze spot in caso di interruzione?

Se sapete rispondere a quattro o più domande, siete a buon punto. Ogni risposta mancante è un punto in cui un picco può ancora sorprendervi.

Lo schema che funziona

Scalare i pod è solo metà dell’autoscaling. Se i nodi sono pieni, i nuovi pod aspettano e il traffico si accumula. Il cluster deve reagire a ciò che è davvero in attesa, non a una previsione.

Il piano in quattro passi

  1. Dimensionare le request. Impostate request di CPU e memoria in base all’uso osservato, al 95° percentile. Nel progetto ha eliminato un sovradimensionamento che occupava circa il 60% della capacità e l’autoscaler ottiene un quadro fedele.
  2. Aggiungere il Cluster Autoscaler. Osserva i pod in attesa, aggiunge nodi quando non possono essere schedulati e rimuove i nodi inattivi. Con i Pod Disruption Budget la riduzione resta graduale.
  3. Mescolare i pool di nodi. Capacità riservata per il carico di base stabile, istanze spot per i picchi, distribuite su più tipi di istanza per ridurre il rischio di interruzione.
  4. Osservare e provare. Allarme sui pod in attesa, tempi di scale-up e scale-down sotto controllo e un test di interruzione di un nodo spot.

Come è andata nella pratica

Dopo il cambiamento i pod giravano 2-3 minuti dopo l’inizio di un picco e il cluster scalava indietro circa 10 minuti dopo la sua fine. Le richieste non vanno più in timeout per mancanza di capacità, nessuno scala i nodi a mano e la configurazione è semplice YAML. Dettagli: lo studio di caso.

Prossimo passo

Fate l’autotest oggi. Se emergono lacune, prenotate una chiamata e guardiamo insieme il vostro cluster.

Pronti a semplificare la vostra piattaforma?

Lavoriamo con pochi clienti alla volta. Se avete problemi di affidabilità, troppa complessità o una piattaforma difficile da gestire, parliamone.

Contattateci →