Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

SLO Kubernetes Upstream

Amazon EKS esegue lo stesso codice delle versioni upstream di Kubernetes e garantisce che i cluster EKS operino all'interno degli SLO definiti dalla community Kubernetes. Il Kubernetes Scalability Special Interest Group (SIG) definisce gli obiettivi di scalabilità e analizza i punti deboli nelle prestazioni tramite SLI e SLO.

Gli SLI sono il modo in cui misuriamo un sistema, ad esempio metriche o misure che possono essere utilizzate per determinare il «buon» funzionamento del sistema, ad esempio la latenza o il conteggio delle richieste. Gli SLO definiscono i valori previsti per quando il sistema funziona «bene», ad esempio la latenza delle richieste rimane inferiore a 3 secondi. Gli SLO e gli SLI Kubernetes si concentrano sulle prestazioni dei componenti Kubernetes e sono completamente indipendenti dagli SLA del servizio Amazon EKS che si concentrano sulla disponibilità dell'endpoint del cluster EKS.

Kubernetes offre una serie di funzionalità che consentono agli utenti di estendere il sistema con componenti aggiuntivi o driver personalizzati, come driver CSI, webhook di ammissione e scaler automatici. Queste estensioni possono influire drasticamente sulle prestazioni di un cluster Kubernetes in diversi modi, ad esempio un webhook di ammissione che potrebbe aggiungere latenza alle richieste API K8s se la destinazione del webhook non è disponibile. failurePolicy=Ignore Il Kubernetes Scalability SIG definisce la scalabilità utilizzando un framework «you promise, we promise»:

SLO Kubernetes

Gli SLO di Kubernetes non tengono conto di tutti i plugin e le limitazioni esterne che potrebbero influire su un cluster, come la scalabilità dei nodi di lavoro o i webhook di ammissione. Questi SLO si concentrano sui componenti di Kubernetes e garantiscono che le azioni e le risorse di Kubernetes funzionino secondo le aspettative. Gli SLO aiutano gli sviluppatori di Kubernetes a garantire che le modifiche al codice Kubernetes non riducano le prestazioni dell'intero sistema.

Il Kuberntes Scalability SIG definisce quanto segue. SLO/SLIs Il team di Amazon EKS esegue regolarmente test di scalabilità sui cluster EKS per monitorare il degrado delle prestazioni man mano che vengono apportate modifiche e vengono rilasciate nuove versioni. SLOs/SLIs

Latenza delle richieste API

L'kube-apiserverha --request-timeout definita come 1m0s predefinita, il che significa che una richiesta può essere eseguita per un massimo di un minuto (60 secondi) prima di essere scaduta e annullata. Gli SLO definiti per Latency sono suddivisi in base al tipo di richiesta che viene effettuata, che può essere mutante o di sola lettura:

Mutante

Le richieste mutanti in Kubernetes apportano modifiche a una risorsa, ad esempio creazioni, eliminazioni o aggiornamenti. Queste richieste sono costose perché tali modifiche devono essere scritte nel backend etcd prima che venga restituito l'oggetto aggiornato. Etcd è un archivio chiave-valore distribuito che viene utilizzato per tutti i dati del cluster Kubernetes.

Questa latenza viene misurata come 99° percentile su 5 minuti per coppie (risorse, verbi) di risorse Kubernetes, ad esempio misurerebbe la latenza per le richieste Create Pod e le richieste Update Node. La latenza della richiesta deve essere <= 1 secondo per soddisfare lo SLO.

Read-only

Read-only le richieste recuperano una singola risorsa (come Get Pod X) o una raccolta (come «Get all Pods from Namespace X»). kube-apiserverMantiene una cache di oggetti, quindi le risorse richieste possono essere restituite dalla cache o potrebbe essere necessario recuperarle prima da etcd. Queste latenze vengono misurate anche dal 99° percentile nell'arco di 5 minuti, tuttavia le richieste di sola lettura possono avere ambiti separati. Lo SLO definisce due obiettivi diversi:

Lo SLO ha valori di destinazione diversi per diversi ambiti di richiesta perché le richieste effettuate per un elenco di risorse Kubernetes prevedono che i dettagli di tutti gli oggetti della richiesta vengano restituiti all'interno dello SLO. Su cluster di grandi dimensioni o grandi raccolte di risorse, ciò può comportare grandi dimensioni di risposta, la cui restituzione può richiedere del tempo. Ad esempio, in un cluster che esegue decine di migliaia di Pod con ogni Pod di circa 1 KB se codificato in JSON, la restituzione di tutti i Pod nel cluster consisterebbe in almeno 10 MB. I client Kubernetes possono contribuire a ridurre questa dimensione di risposta recuperando grandi raccolte di risorse. APIListChunking

Latenza di avvio del Pod

Questo SLO riguarda principalmente il tempo impiegato dalla creazione del Pod a quando i contenitori in quel Pod iniziano effettivamente l'esecuzione. Per misurarlo, viene calcolata la differenza tra il timestamp di creazione registrato sul Pod e il momento in cui un WATCH su quel Pod riporta che i contenitori sono stati avviati (escluso il tempo di estrazione dell'immagine del contenitore e l'inizio dell'esecuzione del contenitore). Per soddisfare lo SLO, il 99° percentile per giorno di cluster di questo Pod Startup Latency deve rimanere <=5 secondi.

Nota che questo SLO presuppone che i nodi di lavoro esistano già in questo cluster in uno stato pronto per la pianificazione del Pod. Questo SLO non tiene conto degli image pull o delle esecuzioni di init container e limita inoltre il test ai «pod stateless» che non sfruttano i plug-in di archiviazione persistenti.

Metriche SLI di Kubernetes

Kubernetes sta inoltre migliorando l'osservabilità degli SLI aggiungendo le metriche Prometheus ai componenti Kubernetes che tracciano questi SLI nel tempo. Utilizzando Prometheus Query Language (PromQL) possiamo creare query che mostrano le prestazioni SLI nel tempo in strumenti come le dashboard Prometheus o Grafana, di seguito sono riportati alcuni esempi degli SLO sopra riportati.

Latenza delle richieste del server API

Puoi utilizzare queste metriche per analizzare i tempi di risposta del server API e verificare se ci sono colli di bottiglia nei componenti di Kubernetes o altro. plugins/components Le domande seguenti si basano sulla dashboard SLO della community.

API Request latency SLI (variabile): questa volta non include l'esecuzione dei webhook o il tempo di attesa in coda. histogram_quantile(0.99, sum(rate(apiserver_request_sli_duration_seconds_bucket{verb=~"CREATE|DELETE|PATCH|POST|PUT", subresource!~"proxy|attach|log|exec|portforward"}[5m])) by (resource, subresource, verb, scope, le)) > 0

Latenza totale della richiesta API (variabile): questo è il tempo totale impiegato dalla richiesta sul server API, questo tempo può essere più lungo del tempo SLI perché include l'esecuzione dei webhook e i tempi di attesa per priorità e correttezza delle API. histogram_quantile(0.99, sum(rate(apiserver_request_duration_seconds_bucket{verb=~"CREATE|DELETE|PATCH|POST|PUT", subresource!~"proxy|attach|log|exec|portforward"}[5m])) by (resource, subresource, verb, scope, le)) > 0

In queste query escludiamo le richieste API di streaming che non vengono restituite immediatamente, come kubectl port-forward o kubectl exec requests (subresource!~"proxy|attach|log|exec|portforward"), e stiamo filtrando solo i verbi Kubernetes che modificano gli oggetti (). verb=~"CREATE|DELETE|PATCH|POST|PUT" Stiamo quindi calcolando il 99° percentile di tale latenza negli ultimi 5 minuti.

Possiamo usare una query simile per le richieste API di sola lettura, modifichiamo semplicemente i verbi che stiamo filtrando per includere le azioni di sola lettura e. LIST GET Esistono anche diverse soglie SLO a seconda dell'ambito della richiesta, ad esempio ottenere una singola risorsa o elencare più risorse.

API Request latency SLI (sola lettura): questo periodo non include l'esecuzione dei webhook o il tempo di attesa in coda. Per una singola risorsa (scope=resource, threshold = 1s) histogram_quantile(0.99, sum(rate(apiserver_request_sli_duration_seconds_bucket{verb=~"GET", scope=~"resource"}[5m])) by (resource, subresource, verb, scope, le))

Per una raccolta di risorse nello stesso spazio dei nomi (scope=namespace, threshold = 5s) histogram_quantile(0.99, sum(rate(apiserver_request_sli_duration_seconds_bucket{verb=~"LIST", scope=~"namespace"}[5m])) by (resource, subresource, verb, scope, le))

Per una raccolta di risorse nell'intero cluster (scope=cluster, threshold = 30s) histogram_quantile(0.99, sum(rate(apiserver_request_sli_duration_seconds_bucket{verb=~"LIST", scope=~"cluster"}[5m])) by (resource, subresource, verb, scope, le))

Latenza totale delle richieste API (sola lettura): questo è il tempo totale impiegato dalla richiesta sul server API, questo periodo può essere più lungo del tempo SLI perché include i tempi di esecuzione e attesa dei webhook. Per una singola risorsa (scope=resource, threshold = 1s) histogram_quantile(0.99, sum(rate(apiserver_request_duration_seconds_bucket{verb=~"GET", scope=~"resource"}[5m])) by (resource, subresource, verb, scope, le))

Per una raccolta di risorse nello stesso spazio dei nomi (scope=namespace, threshold = 5s) histogram_quantile(0.99, sum(rate(apiserver_request_duration_seconds_bucket{verb=~"LIST", scope=~"namespace"}[5m])) by (resource, subresource, verb, scope, le))

Per una raccolta di risorse nell'intero cluster (scope=cluster, threshold = 30s) histogram_quantile(0.99, sum(rate(apiserver_request_duration_seconds_bucket{verb=~"LIST", scope=~"cluster"}[5m])) by (resource, subresource, verb, scope, le))

Le metriche SLI forniscono informazioni dettagliate sulle prestazioni dei componenti di Kubernetes, escludendo il tempo impiegato dalle richieste in attesa nelle code API Priority e Fairness, utilizzando i webhook di ammissione o altre estensioni Kubernetes. Le metriche totali forniscono una visione più olistica in quanto riflettono il tempo che le applicazioni aspetterebbero per ricevere una risposta dal server API. Il confronto di queste metriche può fornire informazioni su dove vengono introdotti i ritardi nell'elaborazione delle richieste.

Latenza di avvio del pod

Analogamente alle domande precedenti, puoi utilizzare queste metriche per ottenere informazioni dettagliate su quanto tempo il ridimensionamento dei nodi, l'image pull e gli init container ritardino il lancio del pod rispetto alle azioni di Kubelet.

Pod startup latency SLI: questo è il periodo che intercorre tra la creazione del pod e il momento in cui i contenitori dell'applicazione sono stati segnalati come in esecuzione. Ciò include il tempo necessario alla disponibilità della capacità del nodo di lavoro e alla pianificazione del pod, ma non include il tempo necessario per estrarre le immagini o per l'esecuzione dei contenitori init. histogram_quantile(0.99, sum(rate(kubelet_pod_start_sli_duration_seconds_bucket[5m])) by (le))

Latenza totale di avvio del pod: questo è il tempo impiegato dal kubelet per avviare il pod per la prima volta. Viene misurato a partire dal momento in cui il kubelet riceve il pod tramite WATCH, il che non include il tempo necessario per la scalabilità o la pianificazione del nodo di lavoro. Ciò include il tempo necessario per estrarre le immagini e avviare i contenitori per l'esecuzione. histogram_quantile(0.99, sum(rate(kubelet_pod_start_duration_seconds_bucket[5m])) by (le))

SLO sul tuo cluster

Se stai raccogliendo le metriche di Prometheus dalle risorse Kubernetes nel tuo cluster EKS, puoi ottenere informazioni più approfondite sulle prestazioni dei componenti del piano di controllo Kubernetes.

Il repository perf-tests include dashboard Grafana che mostrano le latenze e le metriche critiche delle prestazioni per il cluster durante i test. La configurazione perf-tests sfrutta kube-prometheus-stack, un progetto open source configurato per raccogliere i parametri di Kubernetes, ma puoi anche usare Amazon Managed Prometheus e Amazon Managed Grafana.

Se utilizzi la soluzione Prometheus kube-prometheus-stack o una soluzione simile, puoi installare la stessa dashboard per osservare gli SLO sul tuo cluster in tempo reale.

Tieni presente che gli SLO si concentrano sulle prestazioni dei componenti Kubernetes nei tuoi cluster, ma ci sono metriche aggiuntive che puoi esaminare che forniscono diverse prospettive o approfondimenti sul tuo cluster. I progetti della community Kubernetes, ad esempio, possono aiutarti ad analizzare rapidamente le tendenze nel tuo cluster. Kube-state-metrics I plugin e i driver più comuni della community Kubernetes emettono anche le metriche di Prometheus, che ti consentono di esaminare aspetti come scaler automatici o pianificatori personalizzati.

La Observability Best Practices Guide contiene esempi di altre metriche di Kubernetes che puoi utilizzare per ottenere ulteriori informazioni.