Kubernetes Upstream SLOs

Amazon EKS exécute le même code que les versions en amont de Kubernetes et garantit que les clusters EKS fonctionnent conformément aux directives SLOs définies par la communauté Kubernetes. Le Kubernetes Scalability Special Interest Group (SIG) définit les objectifs d'évolutivité et étudie les obstacles aux performances par le biais de et. SLIs SLOs

SLIs sont la façon dont nous mesurons un système, comme les métriques ou les mesures qui peuvent être utilisées pour déterminer le « bon » fonctionnement du système, par exemple la latence ou le nombre de demandes. SLOs définissez les valeurs attendues lorsque le système fonctionne « bien », par exemple lorsque la latence des demandes reste inférieure à 3 secondes. Les Kubernetes SLOs SLIs se concentrent sur les performances des composants Kubernetes et sont totalement indépendants du service Amazon EKS SLAs qui se concentre sur la disponibilité du point de terminaison du cluster EKS.

Kubernetes possède un certain nombre de fonctionnalités qui permettent aux utilisateurs d'étendre le système avec des modules complémentaires ou des pilotes personnalisés, tels que des pilotes CSI, des webhooks d'admission et des scalers automatiques. Ces extensions peuvent avoir un impact considérable sur les performances d'un cluster Kubernetes de différentes manières. Par exemple, un webhook d'admission failurePolicy=Ignore peut ajouter de la latence aux requêtes d'API K8s si la cible du webhook n'est pas disponible. Le SIG de scalabilité de Kubernetes définit l'évolutivité à l'aide d'un framework « vous promettez, nous le promettons » :

Kubernetes SLOs

Les Kubernetes SLOs ne tiennent pas compte de tous les plugins et limitations externes susceptibles d'avoir un impact sur un cluster, tels que le dimensionnement des nœuds de travail ou les webhooks d'admission. Ils SLOs se concentrent sur les composants de Kubernetes et garantissent que les actions et les ressources de Kubernetes fonctionnent conformément aux attentes. Ils SLOs aident les développeurs de Kubernetes à s'assurer que les modifications apportées au code Kubernetes ne dégradent pas les performances de l'ensemble du système.

Le SIG de scalabilité de Kuberntes définit le SLO/ officiel suivant. SLIs L'équipe Amazon EKS effectue régulièrement des tests d'évolutivité sur les clusters EKS SLOs/SLIs afin de surveiller la dégradation des performances à mesure que des modifications sont apportées et que de nouvelles versions sont publiées.

Objectif	Définition	SLO
Latence des demandes d'API (mutation)	Latence du traitement des appels d'API mutants pour des objets uniques pour chaque paire (ressource, verbe), mesurée au 99e percentile au cours des 5 dernières minutes	Dans l'installation par défaut de Kubernetes, pour chaque paire (ressource, verbe), à l'exception des ressources virtuelles et agrégées et des définitions de ressources personnalisées, 99e percentile par jour de cluster <= 1 s
Latence des demandes d'API (lecture seule)	Latence du traitement des appels d'API en lecture seule non diffusés pour chaque paire (ressource, étendue), mesurée au 99e percentile au cours des 5 dernières minutes	Dans l'installation par défaut de Kubernetes, pour chaque paire (ressource, étendue), à l'exception des ressources virtuelles et agrégées et des définitions de ressources personnalisées, 99e centile par jour de cluster : (a) <= 1s si (b) <= 30s sinon (si ou) scope=resource scope=namespace scope=cluster
Latence de démarrage du pod	Latence de démarrage des pods apatrides programmables, à l'exclusion du temps nécessaire pour extraire des images et exécuter des conteneurs d'initialisation, mesurée depuis l'horodatage de création des pods jusqu'au moment où tous leurs conteneurs sont signalés comme démarrés et observés par surveillance, mesurée au 99e centile au cours des 5 dernières minutes	Dans l'installation par défaut de Kubernetes, 99e percentile par jour de cluster <= 5s

Latence des demandes d'API

Le kube-apiserver a été --request-timeout défini comme 1m0s par défaut, ce qui signifie qu'une demande peut être exécutée pendant une minute (60 secondes) au maximum avant d'être expirée et annulée. Les SLOs valeurs définies pour la latence sont ventilées selon le type de demande effectuée, qui peut être mutante ou en lecture seule :

Mutant

Les demandes mutantes dans Kubernetes apportent des modifications à une ressource, telles que des créations, des suppressions ou des mises à jour. Ces demandes sont coûteuses car ces modifications doivent être écrites dans le backend etcd avant que l'objet mis à jour ne soit renvoyé. Etcd est un magasin clé-valeur distribué utilisé pour toutes les données du cluster Kubernetes.

Cette latence est mesurée comme le 99e percentile sur 5 minutes pour les paires (ressource, verbe) de ressources Kubernetes. Par exemple, cela permettrait de mesurer la latence pour les requêtes Create Pod et Update Node. La latence de la demande doit être inférieure ou égale à 1 seconde pour satisfaire le SLO.

Lecture seule

Les requêtes en lecture seule récupèrent une seule ressource (telle que Get Pod X) ou une collection (telle que « Get all Pods from Namespace X »). Il kube-apiserver maintient un cache d'objets, de sorte que les ressources demandées peuvent être renvoyées depuis le cache ou qu'il peut être nécessaire de les récupérer d'abord depuis etcd. Ces latences sont également mesurées par le 99e percentile sur 5 minutes, mais les demandes en lecture seule peuvent avoir des portées distinctes. Le SLO définit deux objectifs différents :

• Pour les demandes effectuées pour une seule ressource (c'est-à-direkubectl get pod -n mynamespace my-controller-xxx), la latence de la demande doit rester inférieure ou égale à 1 seconde.

• Pour les demandes adressées à plusieurs ressources dans un espace de noms ou un cluster (par exemple,kubectl get pods -A), la latence doit rester inférieure ou égale à 30 secondes

Le SLO a des valeurs cibles différentes pour différentes portées de demandes, car les demandes effectuées pour une liste de ressources Kubernetes s'attendent à ce que les détails de tous les objets de la demande soient renvoyés dans le SLO. Dans le cas de grands clusters ou de grands ensembles de ressources, cela peut entraîner des réponses de grande taille dont le retour peut prendre un certain temps. Par exemple, dans un cluster exécutant des dizaines de milliers de pods, chaque pod pesant environ 1 KiB lorsqu'il est codé en JSON, le renvoi de tous les pods du cluster comporterait 10 Mo ou plus. Les clients Kubernetes peuvent aider à réduire cette taille de réponse en utilisant le découpage pour APIList récupérer de grandes collections de ressources.

Latence de démarrage du pod

Ce SLO concerne principalement le temps qui s'écoule entre la création du pod et le moment où les conteneurs de ce pod commencent réellement à être exécutés. Pour mesurer cela, la différence par rapport à l'horodatage de création enregistré sur le Pod et lorsqu'un WATCH sur ce Pod indique que les conteneurs ont démarré est calculée (à l'exception du temps nécessaire pour extraire les images du conteneur et exécuter le conteneur d'initialisation). Pour satisfaire le SLO, le 99e centile par jour de cluster de la latence de démarrage de ce pod doit rester inférieur à 5 secondes.

Notez que ce SLO suppose que les nœuds de travail existent déjà dans ce cluster dans un état prêt pour la planification du Pod. Ce SLO ne prend pas en compte les extractions d'images ni les exécutions de conteneurs d'initialisation, et limite également le test aux « pods apatrides » qui n'exploitent pas les plugins de stockage persistants.

Métriques SLI de Kubernetes

Kubernetes améliore également l'observabilité en SLIs ajoutant des métriques Prometheus aux composants Kubernetes qui les suivent au fil du temps. SLIs À l'aide du langage de requête Prometheus (ProMQL), nous pouvons créer des requêtes qui affichent les performances du SLI au fil du temps dans des outils tels que les tableaux de bord Prometheus ou Grafana. Vous trouverez ci-dessous quelques exemples de ce qui précède. SLOs

Latence des demandes du serveur API

Métrique	Définition
apiserver_request_sli_duration_seconds	Distribution de la latence de réponse (sans compter la durée du webhook et les temps d'attente dans les files d'attente pour les priorités et l'équité) en secondes pour chaque verbe, groupe, version, ressource, sous-ressource, portée et composant.
apiserver_request_duration_seconds	Distribution de la latence de réponse en secondes pour chaque verbe, valeur d'essai, groupe, version, ressource, sous-ressource, portée et composant.

Note

La apiserver_request_sli_duration_seconds métrique est disponible à partir de Kubernetes 1.27.

Vous pouvez utiliser ces mesures pour étudier les temps de réponse du serveur d'API et déterminer s'il existe des goulots d'étranglement dans les composants Kubernetes ou dans d'autres plugins/composants. Les requêtes ci-dessous sont basées sur le tableau de bord SLO de la communauté.

Latence des demandes d'API SLI (mutante) : cette fois-ci n'inclut pas l'exécution du webhook ni le temps d'attente dans la file d'attente. 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

Latence totale de la demande d'API (mutante) : il s'agit du temps total que la demande a pris sur le serveur d'API. Ce temps peut être plus long que le temps SLI car il inclut l'exécution du webhook et les temps d'attente relatifs à la priorité et à l'équité de l'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

Dans ces requêtes, nous excluons les requêtes d'API de streaming qui ne sont pas renvoyées immédiatement, telles que kubectl port-forward or kubectl exec requests (subresource!~"proxy|attach|log|exec|portforward"), et nous filtrons uniquement les verbes Kubernetes qui modifient les objets (). verb=~"CREATE|DELETE|PATCH|POST|PUT" Nous calculons ensuite le 99e percentile de cette latence au cours des 5 dernières minutes.

Nous pouvons utiliser une requête similaire pour les demandes d'API en lecture seule, nous modifions simplement les verbes que nous filtrons pour inclure les actions en lecture seule LIST etGET. Il existe également différents seuils de SLO en fonction de l'étendue de la demande, par exemple pour obtenir une seule ressource ou répertorier un certain nombre de ressources.

Latence des demandes d'API SLI (lecture seule) : cette fois n'inclut pas l'exécution du webhook ni le temps d'attente dans la file d'attente. Pour une seule ressource (scope=resource, seuil=1s) histogram_quantile(0.99, sum(rate(apiserver_request_sli_duration_seconds_bucket{verb=~"GET", scope=~"resource"}[5m])) by (resource, subresource, verb, scope, le))

Pour un ensemble de ressources dans le même espace de noms (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))

Pour un ensemble de ressources sur l'ensemble du cluster (scope=cluster, seuild=30s) histogram_quantile(0.99, sum(rate(apiserver_request_sli_duration_seconds_bucket{verb=~"LIST", scope=~"cluster"}[5m])) by (resource, subresource, verb, scope, le))

Latence totale des demandes d'API (lecture seule) : il s'agit du temps total que la demande a pris sur le serveur d'API. Ce temps peut être plus long que le temps SLI car il inclut l'exécution du webhook et les temps d'attente. Pour une seule ressource (scope=resource, seuil=1s) histogram_quantile(0.99, sum(rate(apiserver_request_duration_seconds_bucket{verb=~"GET", scope=~"resource"}[5m])) by (resource, subresource, verb, scope, le))

Pour un ensemble de ressources dans le même espace de noms (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))

Pour un ensemble de ressources sur l'ensemble du cluster (scope=cluster, seuild=30s) histogram_quantile(0.99, sum(rate(apiserver_request_duration_seconds_bucket{verb=~"LIST", scope=~"cluster"}[5m])) by (resource, subresource, verb, scope, le))

Les métriques SLI fournissent un aperçu des performances des composants Kubernetes en excluant le temps que les demandes passent à attendre dans les files d'attente des API Priority et Fairness, à travailler via des webhooks d'admission ou d'autres extensions Kubernetes. Les statistiques totales fournissent une vue plus globale car elles reflètent le temps que vos applications attendraient une réponse du serveur d'API. La comparaison de ces indicateurs peut donner un aperçu de l'origine des retards dans le traitement des demandes.

Latence de démarrage du pod

Métrique	Définition
kubelet_pod_start_sli_duration_seconds	Durée en secondes nécessaire au démarrage d'un pod, à l'exclusion du temps nécessaire pour extraire des images et exécuter des conteneurs d'initialisation, mesurée entre l'horodatage de création du pod et le moment où tous ses conteneurs sont signalés comme démarrés et observés par surveillance
kubelet_pod_start_duration_seconds	Durée en secondes entre le moment où kubelet voit un pod pour la première fois et celui où le pod commence à fonctionner. Cela n'inclut pas le temps nécessaire pour planifier le module ou augmenter la capacité du nœud de travail.

Note

kubelet_pod_start_sli_duration_secondsest disponible à partir de Kubernetes 1.27.

Comme pour les requêtes ci-dessus, vous pouvez utiliser ces métriques pour savoir combien de temps la mise à l'échelle des nœuds, les extractions d'images et les conteneurs d'initialisation retardent le lancement du pod par rapport aux actions Kubelet.

Latence de démarrage du pod SLI : il s'agit du temps écoulé entre la création du pod et le moment où les conteneurs d'applications ont été signalés comme étant en cours d'exécution. Cela inclut le temps nécessaire pour que la capacité du nœud de travail soit disponible et que le pod soit planifié, mais cela n'inclut pas le temps nécessaire pour extraire les images ou pour exécuter les conteneurs d'initialisation. histogram_quantile(0.99, sum(rate(kubelet_pod_start_sli_duration_seconds_bucket[5m])) by (le))

Latence totale au démarrage du pod : c'est le temps nécessaire au kubelet pour démarrer le pod pour la première fois. Cela est mesuré à partir du moment où le kubelet reçoit le pod via WATCH, ce qui n'inclut pas le temps nécessaire au dimensionnement ou à la planification du nœud de travail. Cela inclut le temps nécessaire pour extraire les images et initier les conteneurs à exécuter. histogram_quantile(0.99, sum(rate(kubelet_pod_start_duration_seconds_bucket[5m])) by (le))

SLOs sur votre cluster

Si vous collectez les métriques Prometheus à partir des ressources Kubernetes de votre cluster EKS, vous pouvez obtenir des informations plus approfondies sur les performances des composants du plan de contrôle Kubernetes.

Le référentiel perf-tests inclut des tableaux de bord Grafana qui affichent les latences et les indicateurs de performance critiques du cluster pendant les tests. La configuration des tests de performance s'appuie sur un projet open source configuré pour collecter des métriques Kubernetes, mais vous pouvez également utiliser Amazon Managed Prometheus et Amazon Managed Grafana. kube-prometheus-stack

Si vous utilisez la solution Prometheus kube-prometheus-stack ou une solution similaire, vous pouvez installer le même tableau de bord pour SLOs l'observer sur votre cluster en temps réel.

1. Vous devez d'abord installer les règles Prometheus utilisées dans les tableaux de bord avec. kubectl apply -f prometheus-rules.yaml Vous pouvez télécharger une copie des règles ici : https://github.com/kubernetes/perf- tests/blob/master/clusterloader2/pkg/prometheus/manifests/prometheus -rules.yaml

   1. Assurez-vous de vérifier que l'espace de noms du fichier correspond à votre environnement

   2. Vérifiez que les libellés correspondent à la valeur du prometheus.prometheusSpec.ruleSelector casque si vous utilisez kube-prometheus-stack

2. Vous pouvez ensuite installer les tableaux de bord dans Grafana. Les tableaux de bord json et les scripts python permettant de les générer sont disponibles ici : https://github.com/kubernetes/perf- tests/tree/master/clusterloader2/pkg/prometheus/manifests/dashboards

   1. le slo.json tableau de bord affiche les performances du cluster par rapport aux Kubernetes SLOs

Sachez qu' SLOs ils se concentrent sur les performances des composants Kubernetes de vos clusters, mais qu'il existe des indicateurs supplémentaires que vous pouvez consulter et qui fournissent différentes perspectives ou informations sur votre cluster. Les projets communautaires Kubernetes tels que K ube-state-metrics peuvent vous aider à analyser rapidement les tendances de votre cluster. Les plugins et pilotes les plus courants de la communauté Kubernetes émettent également des métriques Prometheus, ce qui vous permet d'étudier des éléments tels que les autoscalers ou les planificateurs personnalisés.

Le guide des meilleures pratiques d'observabilité contient des exemples d'autres indicateurs Kubernetes que vous pouvez utiliser pour mieux comprendre.