Kubernetes Upstream SLOs - Amazon EKS
Kubernetes SLOsKubernetes SLI-MetrikenSLOs auf Ihrem Cluster

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Kubernetes Upstream SLOs

Amazon EKS führt denselben Code aus wie die Upstream-Versionen von Kubernetes und stellt sicher, dass EKS-Cluster innerhalb der von der SLOs Kubernetes-Community definierten Werte betrieben werden. Die Kubernetes Scalability Special Interest Group (SIG) definiert die Skalierbarkeitsziele und untersucht Leistungsengpässe durch und. SLIs SLOs

SLIs sind die Art und Weise, wie wir ein System messen, wie Metriken oder Kennzahlen, anhand derer festgestellt werden kann, wie „gut“ das System läuft, z. B. die Latenz oder die Anzahl der Anfragen. SLOs definieren die Werte, die erwartet werden, wenn das System „gut“ läuft, z. B. wenn die Anforderungslatenz weniger als 3 Sekunden beträgt. Die Kubernetes-Lösungen SLOs SLIs konzentrieren sich auf die Leistung der Kubernetes-Komponenten und sind völlig unabhängig vom Amazon EKS Service SLAs , der sich auf die Verfügbarkeit des EKS-Cluster-Endpunkts konzentriert.

Kubernetes verfügt über eine Reihe von Funktionen, mit denen Benutzer das System mit benutzerdefinierten Add-Ons oder Treibern wie CSI-Treibern, Admissions-Webhooks und Auto-Scalern erweitern können. Diese Erweiterungen können die Leistung eines Kubernetes-Clusters auf unterschiedliche Weise drastisch beeinflussen, d. h. ein Zugangswebhook failurePolicy=Ignore könnte die Latenz bei K8s-API-Anfragen erhöhen, wenn das Webhook-Ziel nicht verfügbar ist. Die Kubernetes Scalability SIG definiert Skalierbarkeit anhand eines „Sie versprechen, wir versprechen es“ -Framework:

Kubernetes SLOs

Kubernetes berücksichtigt SLOs nicht alle Plugins und externen Einschränkungen, die sich auf einen Cluster auswirken könnten, wie z. B. die Skalierung von Worker-Nodes oder Admissions-Webhooks. Diese SLOs konzentrieren sich auf Kubernetes-Komponenten und stellen sicher, dass die Aktionen und Ressourcen von Kubernetes den Erwartungen entsprechen. Sie SLOs helfen Kubernetes-Entwicklern dabei, sicherzustellen, dass Änderungen am Kubernetes-Code die Leistung des gesamten Systems nicht beeinträchtigen.

Das Kubernetes Scalability SIG definiert den folgenden offiziellen SLO/S. SLIs Das Amazon EKS-Team führt regelmäßig Skalierbarkeitstests an EKS-Clustern durch SLOs/SLIs , um zu überwachen, ob Leistungseinbußen auftreten, wenn Änderungen vorgenommen und neue Versionen veröffentlicht werden.

Ziel Definition SLO

Latenz bei API-Anfragen (mutierend)

Latenz bei der Verarbeitung mutierender API-Aufrufe für einzelne Objekte für jedes Paar (Ressourcen, Verb), gemessen als 99. Perzentil in den letzten 5 Minuten

In der Kubernetes-Standardinstallation gilt für jedes Paar (Ressourcen, Verb), ausgenommen virtuelle und aggregierte Ressourcen und benutzerdefinierte Ressourcendefinitionen, das 99. Perzentil pro Cluster-Tag <= 1s

Latenz bei API-Anfragen (schreibgeschützt)

Latenz bei der Verarbeitung schreibgeschützter API-Aufrufe ohne Streaming für jedes Paar (Ressourcen, Bereich), gemessen als 99. Perzentil in den letzten 5 Minuten

In der Kubernetes-Standardinstallation gilt für jedes Paar (Ressourcen, Bereich), ausgenommen virtuelle und aggregierte Ressourcen und benutzerdefinierte Ressourcendefinitionen, 99. Perzentil pro Cluster-Tag: (a) <= 1s if (b) <= 30s, andernfalls (wenn oder) scope=resource scope=namespace scope=cluster

Latenz beim Starten des Pods

Die Latenz beim Starten planbarer statusloser Pods, ohne die Zeit zum Abrufen von Images und zum Ausführen von Init-Containern, gemessen vom Zeitstempel der Pod-Erstellung bis zu dem Zeitpunkt, zu dem alle zugehörigen Container als gestartet gemeldet und per Watch beobachtet wurden, gemessen als 99. Perzentil in den letzten 5 Minuten

In der Kubernetes-Standardinstallation ist das 99. Perzentil pro Cluster-Tag <= 5s

Latenz bei API-Anfragen

Die kube-apiserver wurde als 1m0s Standard --request-timeout definiert, was bedeutet, dass eine Anfrage bis zu einer Minute (60 Sekunden) lang ausgeführt werden kann, bevor ein Timeout eintritt und storniert wird. Die für die Latenz SLOs definierten Werte sind nach der Art der Anfrage aufgeteilt, die mutierend oder schreibgeschützt sein kann:

Mutation

Durch mutierende Anfragen in Kubernetes werden Änderungen an einer Ressource vorgenommen, wie z. B. Erstellungen, Löschungen oder Aktualisierungen. Diese Anfragen sind teuer, da diese Änderungen in das etcd-Backend geschrieben werden müssen, bevor das aktualisierte Objekt zurückgegeben wird. Etcd ist ein verteilter Schlüsselwertspeicher, der für alle Kubernetes-Clusterdaten verwendet wird.

Diese Latenz wird als 99. Perzentil über 5 Minuten für (Ressourcen-, Verb-) Paare von Kubernetes-Ressourcen gemessen. Dies würde beispielsweise die Latenz für Create-Pod-Anfragen und Update-Node-Anfragen messen. Die Latenz der Anfrage muss <= 1 Sekunde betragen, um den SLO zu erfüllen.

Read-only

Schreibgeschützte Anfragen rufen eine einzelne Ressource (wie Get Pod X) oder eine Sammlung (wie „Get all Pods from Namespace X“) ab. Der kube-apiserver verwaltet einen Cache mit Objekten, sodass die angeforderten Ressourcen möglicherweise aus dem Cache zurückgegeben werden oder sie müssen möglicherweise zuerst von etcd abgerufen werden. Diese Latenzen werden ebenfalls anhand des 99. Perzentils über einen Zeitraum von 5 Minuten gemessen, allerdings können nur lesbare Anfragen unterschiedliche Bereiche haben. Das SLO definiert zwei verschiedene Ziele:

  • Bei Anfragen für eine einzelne Ressource (d. h.kubectl get pod -n mynamespace my-controller-xxx) sollte die Anforderungslatenz bei <= 1 Sekunde bleiben.

  • Bei Anfragen, die für mehrere Ressourcen in einem Namespace oder einem Cluster gestellt werden (z. B.kubectl get pods -A), sollte die Latenz bei <= 30 Sekunden bleiben

Das SLO hat unterschiedliche Zielwerte für verschiedene Anforderungsbereiche, da bei Anfragen für eine Liste von Kubernetes-Ressourcen erwartet wird, dass die Details aller Objekte in der Anfrage innerhalb des SLO zurückgegeben werden. Bei großen Clustern oder großen Ressourcensammlungen kann dies zu großen Antwortgrößen führen, deren Rückgabe einige Zeit in Anspruch nehmen kann. In einem Cluster mit Zehntausenden von Pods, wobei jeder Pod bei JSON-Kodierung etwa 1 KiB groß ist, würde die Rückgabe aller Pods im Cluster aus 10 MB oder mehr bestehen. Kubernetes-Clients können helfen, diese Antwortgröße zu reduzieren, indem sie APIListChunking verwenden, um große Ressourcensammlungen abzurufen.

Latenz beim Pod-Start

Bei diesem SLO geht es hauptsächlich um die Zeit, die von der Pod-Erstellung bis zum tatsächlichen Beginn der Ausführung der Container in diesem Pod vergeht. Um dies zu messen, wird der Unterschied zwischen dem auf dem Pod aufgezeichneten Erstellungszeitstempel und dem Zeitpunkt berechnet, zu dem eine WATCH auf diesem Pod meldet, dass die Container gestartet wurden (ohne die Zeit für das Abrufen von Container-Images und die Initialisierung der Containerausführung). Um den SLO zu erfüllen, muss das 99. Perzentil pro Cluster-Tag dieser Pod-Startlatenz bei <=5 Sekunden bleiben.

Beachten Sie, dass bei diesem SLO davon ausgegangen wird, dass die Worker-Knoten in diesem Cluster bereits vorhanden und bereit sind, für den Pod geplant zu werden. Dieses SLO berücksichtigt keine Image-Pulls oder Init-Container-Ausführungen und beschränkt den Test auch auf „statusfreie Pods“, die keine persistenten Speicher-Plug-ins nutzen.

Kubernetes SLI-Metriken

Kubernetes verbessert auch die Observability rund um die, SLIs indem es Prometheus-Metriken zu Kubernetes-Komponenten hinzufügt, die diese im Laufe der Zeit verfolgen. SLIs Mit der Prometheus Query Language (PromQL) können wir Abfragen erstellen, die die SLI-Leistung im Laufe der Zeit in Tools wie Prometheus- oder Grafana-Dashboards anzeigen. Im Folgenden finden Sie einige Beispiele dafür. SLOs

Latenz bei API-Serveranfragen

Metrik Definition

apiserver_request_sli_duration_seconds

Verteilung der Antwortlatenz (ohne Webhook-Dauer und Wartezeiten für Priority & Fairness) in Sekunden für jedes Verb, jede Gruppe, Version, Ressource, Unterressource, Geltungsbereich und Komponente.

apiserver_request_duration_seconds

Verteilung der Antwortlatenz in Sekunden für jedes Verb, jeden Probelauf, jede Gruppe, Version, Ressource, Unterressource, jeden Bereich und jede Komponente.

Hinweis: Die apiserver_request_sli_duration_seconds Metrik ist ab Kubernetes 1.27 verfügbar.

Sie können diese Metriken verwenden, um die Antwortzeiten des API-Servers zu untersuchen und festzustellen, ob es Engpässe bei den Kubernetes-Komponenten oder anderen Plugins/Komponenten gibt. Die folgenden Abfragen basieren auf dem SLO-Dashboard der Community.

API-Anforderungslatenz SLI (mutierend) — dieses Mal sind die Ausführung von Webhooks oder die Wartezeit in der Warteschlange nicht enthalten. 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

API-Anforderungslatenz insgesamt (mutierend) — Dies ist die Gesamtzeit, die die Anfrage auf dem API-Server benötigt hat. Diese Zeit kann länger sein als die SLI-Zeit, da sie die Webhook-Ausführung sowie die Wartezeiten für API-Priorität und Fairness beinhaltet. 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 diesen Abfragen schließen wir die Streaming-API-Anfragen aus, die nicht sofort zurückgegeben werden, wie z. B. kubectl port-forward or kubectl exec requests (subresource!~"proxy|attach|log|exec|portforward"), und wir filtern nur nach den Kubernetes-Verben, die objects () ändern. verb=~"CREATE|DELETE|PATCH|POST|PUT" Anschließend berechnen wir das 99. Perzentil dieser Latenz in den letzten 5 Minuten.

Wir können eine ähnliche Abfrage für die schreibgeschützten API-Anfragen verwenden. Wir ändern einfach die Verben, nach denen wir filtern, sodass sie die schreibgeschützten Aktionen und enthalten. LIST GET Je nach Umfang der Anfrage, d. h. beim Abrufen einer einzelnen Ressource oder beim Auflisten mehrerer Ressourcen, gibt es auch unterschiedliche SLO-Schwellenwerte.

SLI für API-Anforderungslatenz (schreibgeschützt) — diesmal sind die Ausführung von Webhooks oder die Wartezeit in der Warteschlange nicht enthalten. Für eine einzelne Ressource (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))

Für eine Sammlung von Ressourcen im selben Namespace (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))

Für eine Sammlung von Ressourcen im gesamten 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))

API-Anforderungslatenz insgesamt (schreibgeschützt) — Dies ist die Gesamtzeit, die die Anfrage auf dem API-Server in Anspruch genommen hat. Diese Zeit kann länger sein als die SLI-Zeit, da sie die Ausführung und Wartezeiten von Webhooks beinhaltet. Für eine einzelne Ressource (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))

Für eine Sammlung von Ressourcen im selben Namespace (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))

Für eine Sammlung von Ressourcen im gesamten 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))

Die SLI-Metriken geben Aufschluss über die Leistung von Kubernetes-Komponenten, indem sie die Zeit ausklammern, die Anfragen in API-Prioritäts- und Fairness-Warteschlangen warten, Zulassungs-Webhooks oder andere Kubernetes-Erweiterungen bearbeiten. Die Gesamtmetriken bieten einen ganzheitlicheren Überblick, da sie die Zeit widerspiegeln, die Ihre Anwendungen auf eine Antwort vom API-Server warten würden. Ein Vergleich dieser Kennzahlen kann Aufschluss darüber geben, wo die Verzögerungen bei der Bearbeitung von Anfragen entstehen.

Latenz beim Starten des Pods

Metrik Definition

kubelet_pod_start_sli_duration_seconds

Dauer in Sekunden bis zum Start eines Pods, ohne die Zeit zum Abrufen von Bildern und zum Ausführen von Init-Containern, gemessen vom Zeitpunkt der Pod-Erstellung bis zu dem Zeitpunkt, zu dem alle seine Container als gestartet gemeldet und per Watch beobachtet gemeldet wurden

kubelet_pod_start_duration_seconds

Dauer in Sekunden zwischen dem Zeitpunkt, an dem Kubelet einen Pod zum ersten Mal sieht, bis zum Start des Pods. Dies beinhaltet nicht die Zeit für die Planung des Pods oder die Skalierung der Kapazität des Worker-Knotens.

Hinweis: kubelet_pod_start_sli_duration_seconds ist ab Kubernetes 1.27 verfügbar.

Ähnlich wie bei den obigen Abfragen können Sie diese Metriken verwenden, um zu erfahren, wie lange Node-Skalierung, Image-Pulls und Init-Container den Pod-Start im Vergleich zu Kubelet-Aktionen verzögern.

Latenz beim Pod-Start (SLI) — das ist die Zeit von der Erstellung des Pods bis zu dem Zeitpunkt, zu dem die Anwendungscontainer als aktiv gemeldet wurden. Dies beinhaltet die Zeit, die benötigt wird, bis die Kapazität des Worker-Nodes verfügbar ist und der Pod geplant ist, aber nicht die Zeit, die zum Abrufen von Images oder zum Ausführen der Init-Container benötigt wird. histogram_quantile(0.99, sum(rate(kubelet_pod_start_sli_duration_seconds_bucket[5m])) by (le))

Latenz beim Pod-Start insgesamt — das ist die Zeit, die das Kubelet benötigt, um den Pod zum ersten Mal zu starten. Dies wird ab dem Zeitpunkt gemessen, zu dem das Kubelet den Pod über WATCH empfängt. Die Zeit für die Skalierung oder Planung des Worker-Nodes ist nicht enthalten. Dazu gehört auch die Zeit, die benötigt wird, um Images abzurufen und Container für die Ausführung zu initialisieren. histogram_quantile(0.99, sum(rate(kubelet_pod_start_duration_seconds_bucket[5m])) by (le))

SLOs auf Ihrem Cluster

Wenn Sie die Prometheus-Metriken aus den Kubernetes-Ressourcen in Ihrem EKS-Cluster sammeln, können Sie tiefere Einblicke in die Leistung der Komponenten der Kubernetes-Steuerebene gewinnen.

Das Perf-Tests-Repo enthält Grafana-Dashboards, in denen die Latenzen und kritischen Leistungskennzahlen für den Cluster während der Tests angezeigt werden. Die Perf-Tests-Konfiguration nutzt das kube-prometheus-stack, ein Open-Source-Projekt, das für die Erfassung von Kubernetes-Metriken konfiguriert ist. Sie können aber auch Amazon Managed Prometheus und Amazon Managed Grafana verwenden.

Wenn Sie die kube-prometheus-stack oder eine ähnliche Prometheus-Lösung verwenden, können Sie dasselbe Dashboard installieren, um die SLOs auf Ihrem Cluster in Echtzeit zu beobachten.

  1. Sie müssen zuerst die Prometheus-Regeln installieren, die in den Dashboards mit verwendet werden. kubectl apply -f prometheus-rules.yaml Sie können eine Kopie der Regeln hier herunterladen: https://github.com/kubernetes/ perf- -rules.yaml tests/blob/master/clusterloader2/pkg/prometheus/manifests/prometheus

    1. Stellen Sie sicher, dass der Namespace in der Datei zu Ihrer Umgebung passt

    2. Stellen Sie sicher, dass die Labels mit dem prometheus.prometheusSpec.ruleSelector Helm-Wert übereinstimmen, wenn Sie kube-prometheus-stack

  2. Anschließend können Sie die Dashboards in Grafana installieren. Die JSON-Dashboards und Python-Skripte zu ihrer Generierung sind hier verfügbar: perf- https://github.com/kubernetes/ tests/tree/master/clusterloader2/pkg/prometheus/manifests/dashboards

    1. Das slo.json Dashboard zeigt die Leistung des Clusters im Verhältnis zu Kubernetes SLOs

Bedenken Sie, dass SLOs sie sich auf die Leistung der Kubernetes-Komponenten in Ihren Clustern konzentrieren, aber es gibt zusätzliche Metriken, die Sie überprüfen können und die unterschiedliche Perspektiven oder Einblicke in Ihren Cluster bieten. Kubernetes-Community-Projekte wie K ube-state-metrics können Ihnen helfen, Trends in Ihrem Cluster schnell zu analysieren. Die meisten gängigen Plugins und Treiber aus der Kubernetes-Community geben auch Prometheus-Metriken aus, sodass Sie Dinge wie Autoscaler oder benutzerdefinierte Scheduler untersuchen können.

Der Observability Best Practices Guide enthält Beispiele für andere Kubernetes-Metriken, anhand derer Sie weitere Einblicke gewinnen können.