Kubernetes Upstream SLOs - Amazon EKS
Kubernetes SLOsMetriche SLI di KubernetesSLOs sul tuo cluster

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à.

Kubernetes Upstream SLOs

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

SLIs 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. SLOs definiamo i valori previsti per quando il sistema funziona «bene», ad esempio la latenza delle richieste rimane inferiore a 3 secondi. I Kubernetes si SLOs SLIs concentrano sulle prestazioni dei componenti Kubernetes e sono completamente indipendenti dal servizio Amazon EKS, SLAs che si concentra 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»:

Kubernetes SLOs

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

Il Kuberntes Scalability SIG definisce il seguente SLO/ ufficiale. 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

Obiettivo Definizione SLO

Latenza della richiesta API (mutante)

Latenza di elaborazione delle chiamate API mutanti per singoli oggetti per ogni coppia (risorsa, verbo), misurata come 99° percentile negli ultimi 5 minuti

Nell'installazione predefinita di Kubernetes, per ogni coppia (risorsa, verbo), escluse le risorse virtuali e aggregate e le definizioni di risorse personalizzate, 99° percentile per giorno del cluster <= 1s

Latenza delle richieste API (sola lettura)

Latenza di elaborazione delle chiamate API di sola lettura non in streaming per ogni coppia (risorsa, ambito), misurata come 99° percentile negli ultimi 5 minuti

Nell'installazione predefinita di Kubernetes, per ogni coppia (risorsa, ambito), escluse le risorse virtuali e aggregate e le definizioni di risorse personalizzate, 99° percentile per giorno del cluster: (a) <= 1s se (b) <= 30s altrimenti (if o) scope=resource scope=namespace scope=cluster

Latenza di avvio del pod

Latenza di avvio dei pod stateless pianificabili, escluso il tempo necessario per estrarre le immagini ed eseguire contenitori init, misurata dal timestamp di creazione del pod al momento in cui tutti i contenitori vengono segnalati come avviati e osservati tramite watch, misurata come 99° percentile negli ultimi 5 minuti

Nell'installazione predefinita di Kubernetes, 99° percentile per giorno di cluster <= 5s

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. I SLOs valori 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 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.

Sola lettura

Le richieste di sola lettura 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:

  • Per le richieste effettuate per una singola risorsa (ad esempiokubectl get pod -n mynamespace my-controller-xxx), la latenza della richiesta deve rimanere <= 1 secondo.

  • Per le richieste effettuate per più risorse in un namespace o in un cluster (ad esempio,kubectl get pods -A) la latenza deve rimanere <= 30 secondi

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 utilizzando APIList Chunking per recuperare grandi raccolte di risorse.

Latenza di avvio del Pod

Questo SLO riguarda principalmente il tempo impiegato dalla creazione del Pod al momento in cui 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à in tutto il mondo SLIs aggiungendo le metriche di Prometheus ai componenti Kubernetes che ne tengono traccia nel tempo. SLIs 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 di quanto sopra. SLOs

Latenza delle richieste del server API

Parametro Definizione

apiserver_request_sli_duration_seconds

Distribuzione della latenza di risposta (senza contare la durata dei webhook e i tempi di attesa nella coda di priorità e equità) in secondi per ogni verbo, gruppo, versione, risorsa, sottorisorsa, ambito e componente.

apiserver_request_duration_seconds

Distribuzione della latenza di risposta in secondi per ogni verbo, valore di dry run, gruppo, versione, risorsa, sottorisorsa, ambito e componente.

Nota: la apiserver_request_sli_duration_seconds metrica è disponibile a partire da Kubernetes 1.27.

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 in altri plugin/componenti. 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

Parametro Definizione

kubelet_pod_start_sli_duration_seconds

Durata in secondi per avviare un pod, escluso il tempo necessario per estrarre le immagini ed eseguire init containers, misurata dal timestamp di creazione del pod al momento in cui tutti i contenitori vengono segnalati come avviati e osservati tramite watch

kubelet_pod_start_duration_seconds

Durata in secondi dal momento in cui Kubelet vede un pod per la prima volta all'avvio del pod. Ciò non include il tempo necessario per pianificare il pod o aumentare la capacità del nodo di lavoro.

Nota: kubelet_pod_start_sli_duration_seconds è disponibile a partire da Kubernetes 1.27.

Analogamente alle domande precedenti, puoi utilizzare queste metriche per ottenere informazioni dettagliate su quanto tempo il ridimensionamento dei nodi, l'acquisizione di immagini e i contenitori init 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))

SLOs 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 il 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 osservarli sul tuo cluster in tempo SLOs reale.

  1. Dovrai prima installare le Prometheus Rules utilizzate nelle dashboard con. kubectl apply -f prometheus-rules.yaml Puoi scaricare una copia delle regole qui: perf- -rules.yaml https://github.com/kubernetes/ tests/blob/master/clusterloader2/pkg/prometheus/manifests/prometheus

    1. Assicurati di controllare che lo spazio dei nomi nel file corrisponda al tuo ambiente

    2. Verifica che le etichette corrispondano al valore di prometheus.prometheusSpec.ruleSelector helm se stai utilizzando kube-prometheus-stack

  2. È quindi possibile installare i dashboard in Grafana. I dashboard json e gli script python per generarli sono disponibili qui: perf- https://github.com/kubernetes/ tests/tree/master/clusterloader2/pkg/prometheus/manifests/dashboards

    1. la slo.json dashboard mostra le prestazioni del cluster in relazione a Kubernetes SLOs

Tieni presente che si SLOs 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 come K ube-state-metrics possono aiutarti ad analizzare rapidamente le tendenze nel tuo cluster. 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.