Kubernetes Upstream SLOs - Amazon EKS
Kubernetes SLOsMétricas SLI de KubernetesSLOs en tu clúster

Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

Kubernetes Upstream SLOs

Amazon EKS ejecuta el mismo código que las versiones anteriores de Kubernetes y garantiza que los clústeres de EKS funcionen dentro de los parámetros SLOs definidos por la comunidad de Kubernetes. El Grupo de interés especial sobre escalabilidad (SIG) de Kubernetes define los objetivos de escalabilidad e investiga los obstáculos en el rendimiento a través de y. SLIs SLOs

SLIs son la forma en que medimos un sistema, como métricas o medidas que se pueden utilizar para determinar qué tan «bien» está funcionando el sistema, por ejemplo, la latencia o el recuento de solicitudes. SLOs definen los valores esperados cuando el sistema funciona «bien», por ejemplo, la latencia de las solicitudes permanece por debajo de 3 segundos. Kubernetes SLOs y Kubernetes SLIs se centran en el rendimiento de los componentes de Kubernetes y son completamente independientes del servicio Amazon EKS, SLAs que se centra en la disponibilidad del punto final del clúster de EKS.

Kubernetes tiene una serie de funciones que permiten a los usuarios ampliar el sistema con complementos o controladores personalizados, como controladores CSI, webhooks de admisión y escaladores automáticos. Estas extensiones pueden afectar drásticamente al rendimiento de un clúster de Kubernetes de diferentes maneras, por ejemplo, un webhook de admisión failurePolicy=Ignore podría añadir latencia a las solicitudes de la API de K8 si el destino del webhook no está disponible. El SIG de escalabilidad de Kubernetes define la escalabilidad utilizando el marco «tú lo prometes, nosotros lo prometemos»:

Kubernetes SLOs

Los Kubernetes SLOs no tienen en cuenta todos los complementos y las limitaciones externas que podrían afectar a un clúster, como el escalado de los nodos de trabajo o los webhooks de admisión. Estos SLOs se centran en los componentes de Kubernetes y garantizan que las acciones y los recursos de Kubernetes funcionen a la altura de las expectativas. SLOs Ayudan a los desarrolladores de Kubernetes a garantizar que los cambios en el código de Kubernetes no degraden el rendimiento de todo el sistema.

El SIG de escalabilidad de Kuberntes define el siguiente SLO/ oficial. SLIs El equipo de Amazon EKS realiza periódicamente pruebas de escalabilidad en los clústeres de EKS SLOs/SLIs para monitorizar la degradación del rendimiento a medida que se realizan cambios y se lanzan nuevas versiones.

Objetivo Definición SLO

Latencia de solicitud de API (mutante)

Latencia del procesamiento de las llamadas a la API mutantes para objetos individuales para cada par (recurso, verbo), medida como el percentil 99 durante los últimos 5 minutos

En la instalación predeterminada de Kubernetes, para cada par (recurso, verbo), excluidos los recursos virtuales y agregados y las definiciones de recursos personalizadas, el percentil 99 por día de clúster es inferior a 1 s

Latencia de solicitud de API (solo lectura)

Latencia del procesamiento de las llamadas a la API de solo lectura que no se transmiten en streaming para cada par (recurso, ámbito), medida como el percentil 99 durante los últimos 5 minutos

En la instalación predeterminada de Kubernetes, para cada par (recurso, ámbito), excluidos los recursos virtuales y agregados y las definiciones de recursos personalizadas, el percentil 99 por día de clúster: (a) <= 1 s si (b) <= 30 en caso contrario (si o) scope=resource scope=namespace scope=cluster

Latencia de inicio del pod

La latencia de inicio de los pods programables y sin estado, excluido el tiempo necesario para extraer imágenes y ejecutar los contenedores de inicio, se mide desde la fecha de creación del pod hasta el momento en que se informa que todos sus contenedores se han iniciado y se observan mediante un reloj, medida como el percentil 99 durante los últimos 5 minutos

En la instalación predeterminada de Kubernetes, el percentil 99 por día de clúster es inferior a 5 segundos

Latencia de solicitud de API

Se kube-apiserver ha --request-timeout definido como 1m0s predeterminada, lo que significa que una solicitud puede ejecutarse hasta un minuto (60 segundos) antes de que se agote el tiempo de espera y se cancele. La latencia SLOs definida se desglosa según el tipo de solicitud que se está realizando, que puede ser mutante o de solo lectura:

Mutante

Las solicitudes mutantes en Kubernetes realizan cambios en un recurso, como creaciones, eliminaciones o actualizaciones. Estas solicitudes son caras porque esos cambios deben escribirse en el backend etcd antes de que se devuelva el objeto actualizado. Etcd es un almacén de valores clave distribuido que se utiliza para todos los datos del clúster de Kubernetes.

Esta latencia se mide como el percentil 99 a lo largo de 5 minutos para pares (recurso, verbo) de recursos de Kubernetes. Por ejemplo, esto mediría la latencia de las solicitudes de creación de pods y de actualización de nodos. La latencia de la solicitud debe ser inferior a 1 segundo para cumplir con el SLO.

Solo lectura

Las solicitudes de solo lectura recuperan un único recurso (como Get Pod X) o una colección (como «Obtener todos los pods del espacio de nombres X»). kube-apiserverMantiene una caché de objetos, por lo que es posible que los recursos solicitados se devuelvan de la caché o que sea necesario recuperarlos primero de etcd. Estas latencias también se miden con el percentil 99 a lo largo de 5 minutos; sin embargo, las solicitudes de solo lectura pueden tener ámbitos distintos. El SLO define dos objetivos diferentes:

  • Para las solicitudes realizadas para un solo recurso (es decir,kubectl get pod -n mynamespace my-controller-xxx), la latencia de la solicitud debe permanecer <= 1 segundo.

  • Para las solicitudes que se realizan para varios recursos en un espacio de nombres o un clúster (por ejemplokubectl get pods -A), la latencia debe permanecer <= 30 segundos

El SLO tiene valores objetivo diferentes para los distintos ámbitos de solicitud, ya que las solicitudes realizadas para una lista de recursos de Kubernetes esperan que los detalles de todos los objetos de la solicitud se devuelvan en el SLO. En clústeres grandes o colecciones de recursos de gran tamaño, esto puede generar respuestas de gran tamaño, que pueden tardar algún tiempo en recuperarse. Por ejemplo, en un clúster que ejecute decenas de miles de pods y cada pod tenga aproximadamente 1 KiB cuando esté codificado en JSON, la devolución de todos los pods del clúster consistiría en 10 MB o más. Los clientes de Kubernetes pueden ayudar a reducir este tamaño de respuesta mediante el uso de APIList Chunking para recuperar grandes colecciones de recursos.

Latencia de inicio del pod

Este SLO se refiere principalmente al tiempo que pasa desde la creación del pod hasta que los contenedores de ese pod comienzan a ejecutarse. Para medirlo, se calcula la diferencia entre la marca temporal de creación registrada en el pod y el momento en que un WATCH informa que los contenedores han comenzado a funcionar (sin incluir el tiempo que se tarda en extraer la imagen del contenedor y en el que se inicia la ejecución del contenedor). Para cumplir con el SLO, el percentil 99 por día de clúster de la latencia de inicio de este pod debe ser inferior a 5 segundos.

Ten en cuenta que este SLO supone que los nodos de trabajo ya existen en este clúster y están preparados para que se programe el Pod. Este SLO no tiene en cuenta las extracciones de imágenes ni las ejecuciones de contenedores de inicio, y también limita la prueba a los «pods sin estado» que no utilizan complementos de almacenamiento persistente.

Métricas SLI de Kubernetes

Kubernetes también está mejorando la observabilidad en torno al SLIs añadir métricas de Prometheus a los componentes de Kubernetes que las rastrean a lo largo del tiempo. SLIs Con el lenguaje de consultas Prometheus (ProMQL), podemos crear consultas que muestren el rendimiento del SLI a lo largo del tiempo en herramientas como los paneles de Prometheus o Grafana. A continuación, se muestran algunos ejemplos de lo anterior. SLOs

Latencia de solicitudes del servidor API

Métrica Definición

apiserver_request_sli_duration_seconds

Distribución de la latencia de respuesta (sin contar la duración de los webhooks ni los tiempos de espera de las colas de prioridad y equidad) en segundos para cada verbo, grupo, versión, recurso, subrecurso, ámbito y componente.

apiserver_request_duration_seconds

Distribución de la latencia de respuesta en segundos para cada verbo, valor de ensayo, grupo, versión, recurso, subrecurso, ámbito y componente.

Nota: La métrica está disponible a partir de la versión 1.27 de Kubernetes. apiserver_request_sli_duration_seconds

Puedes usar estas métricas para investigar los tiempos de respuesta del servidor API y si hay cuellos de botella en los componentes de Kubernetes o en otros complementos o componentes. Las consultas que aparecen a continuación se basan en el panel de control de SLO de la comunidad.

Latencia de solicitud de API SLI (mutante): este tiempo no incluye la ejecución del webhook ni el tiempo de espera en la cola. 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

Latencia total de solicitudes de API (mutante): es el tiempo total que tardó la solicitud en el servidor de API. Este tiempo puede ser superior al tiempo de SLI, ya que incluye la ejecución de webhooks y los tiempos de espera de prioridad y equidad de la 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

En estas consultas, excluimos las solicitudes de la API de streaming que no se devuelven inmediatamente, como kubectl port-forward o kubectl exec requests (subresource!~"proxy|attach|log|exec|portforward"), y filtramos solo los verbos de Kubernetes que modifican objetos (). verb=~"CREATE|DELETE|PATCH|POST|PUT" A continuación, calculamos el percentil 99 de esa latencia durante los últimos 5 minutos.

Podemos usar una consulta similar para las solicitudes de API de solo lectura, simplemente modificamos los verbos por los que estamos filtrando para incluir las acciones de solo lectura y. LIST GET También hay diferentes umbrales de SLO según el alcance de la solicitud, es decir, obtener un único recurso o enumerar varios recursos.

Latencia de solicitud de API SLI (solo lectura): este tiempo no incluye la ejecución del webhook ni el tiempo de espera en la cola. Para un único recurso (alcance = recurso, umbral = 1 s) histogram_quantile(0.99, sum(rate(apiserver_request_sli_duration_seconds_bucket{verb=~"GET", scope=~"resource"}[5m])) by (resource, subresource, verb, scope, le))

Para un conjunto de recursos en el mismo espacio de nombres (scope=namespace, umbral=5s) histogram_quantile(0.99, sum(rate(apiserver_request_sli_duration_seconds_bucket{verb=~"LIST", scope=~"namespace"}[5m])) by (resource, subresource, verb, scope, le))

Para un conjunto de recursos de todo el clúster (alcance=clúster, umbral=30s) histogram_quantile(0.99, sum(rate(apiserver_request_sli_duration_seconds_bucket{verb=~"LIST", scope=~"cluster"}[5m])) by (resource, subresource, verb, scope, le))

Latencia total de la solicitud de la API (solo lectura): es el tiempo total que tardó la solicitud en el servidor de la API. Este tiempo puede ser superior al de la SLI, ya que incluye los tiempos de espera y de ejecución de los webhooks. Para un único recurso (scope=resource, umbral=1s) histogram_quantile(0.99, sum(rate(apiserver_request_duration_seconds_bucket{verb=~"GET", scope=~"resource"}[5m])) by (resource, subresource, verb, scope, le))

Para un conjunto de recursos en el mismo espacio de nombres (scope=namespace, umbral=5s) histogram_quantile(0.99, sum(rate(apiserver_request_duration_seconds_bucket{verb=~"LIST", scope=~"namespace"}[5m])) by (resource, subresource, verb, scope, le))

Para un conjunto de recursos de todo el clúster (alcance=clúster, umbral=30s) histogram_quantile(0.99, sum(rate(apiserver_request_duration_seconds_bucket{verb=~"LIST", scope=~"cluster"}[5m])) by (resource, subresource, verb, scope, le))

Las métricas del SLI proporcionan información sobre el rendimiento de los componentes de Kubernetes, ya que excluyen el tiempo que las solicitudes pasan esperando en las colas de prioridad y equidad de las API, pasando por webhooks de admisión u otras extensiones de Kubernetes. Las métricas totales proporcionan una visión más holística, ya que reflejan el tiempo que sus aplicaciones estarían esperando una respuesta del servidor de API. La comparación de estas métricas puede proporcionar información sobre dónde se están produciendo los retrasos en el procesamiento de las solicitudes.

Latencia de inicio del pod

Métrica Definición

kubelet_pod_start_sli_duration_seconds

Duración en segundos que se tarda en iniciar un pod, excluido el tiempo necesario para extraer imágenes y ejecutar los contenedores de inicio, que se mide desde la fecha de creación del pod hasta el momento en que se indica que todos sus contenedores están iniciados y se observan mediante un reloj

kubelet_pod_start_duration_seconds

Duración en segundos desde que Kubelet ve un pod por primera vez hasta que el pod empieza a funcionar. Esto no incluye el tiempo necesario para programar el pod ni ampliar la capacidad del nodo de trabajo.

Nota: kubelet_pod_start_sli_duration_seconds está disponible a partir de la versión 1.27 de Kubernetes.

Al igual que en las consultas anteriores, puedes usar estas métricas para saber cuánto tiempo demoran el lanzamiento del pod el escalado de nodos, la extracción de imágenes y los contenedores de inicio, en comparación con las acciones de Kubelet.

Latencia de inicio del pod (SLI): es el tiempo transcurrido desde la creación del pod hasta el momento en que los contenedores de aplicaciones indican que están en ejecución. Esto incluye el tiempo que tarda la capacidad del nodo de trabajo en estar disponible y el pod en programarse, pero no incluye el tiempo que se tarda en extraer imágenes o en ejecutar los contenedores de inicio. histogram_quantile(0.99, sum(rate(kubelet_pod_start_sli_duration_seconds_bucket[5m])) by (le))

Latencia total de inicio del pod: es el tiempo que tarda el kubelet en iniciar el pod por primera vez. Se mide a partir del momento en que el kubelet recibe el pod mediante WATCH, sin incluir el tiempo necesario para escalar o programar el nodo de trabajo. Esto incluye el tiempo necesario para extraer imágenes e iniciar los contenedores para que se ejecuten. histogram_quantile(0.99, sum(rate(kubelet_pod_start_duration_seconds_bucket[5m])) by (le))

SLOs en tu clúster

Si recopila las métricas de Prometheus de los recursos de Kubernetes de su clúster de EKS, puede obtener información más profunda sobre el rendimiento de los componentes del plano de control de Kubernetes.

El repositorio de pruebas de rendimiento incluye paneles de Grafana que muestran las latencias y las métricas de rendimiento críticas del clúster durante las pruebas. La configuración de pruebas de rendimiento aprovecha el kube-prometheus-stack, un proyecto de código abierto que viene configurado para recopilar métricas de Kubernetes, pero también puedes usar Prometheus gestionado por Amazon y Grafana gestionado por Amazon.

Si utiliza la solución Prometheus kube-prometheus-stack o una similar, puede instalar el mismo panel de control para SLOs observarlo en su clúster en tiempo real.

  1. Primero tendrá que instalar las reglas de Prometheus que se utilizan en los paneles de control con. kubectl apply -f prometheus-rules.yaml Puede descargar una copia de las reglas aquí: https://github.com/kubernetes/ perf- -rules.yaml tests/blob/master/clusterloader2/pkg/prometheus/manifests/prometheus

    1. Asegúrese de comprobar que el espacio de nombres del archivo coincida con su entorno

    2. Compruebe que las etiquetas coincidan con el valor de prometheus.prometheusSpec.ruleSelector helm si está utilizando kube-prometheus-stack

  2. A continuación, puede instalar los cuadros de mando en Grafana. Los cuadros de mando de json y los scripts de Python para generarlos están disponibles aquí: perf- https://github.com/kubernetes/ tests/tree/master/clusterloader2/pkg/prometheus/manifests/dashboards

    1. el slo.json panel muestra el rendimiento del clúster en relación con Kubernetes SLOs

Tenga en cuenta que SLOs se centran en el rendimiento de los componentes de Kubernetes en sus clústeres, pero hay métricas adicionales que puede revisar y que proporcionan diferentes perspectivas o conocimientos sobre su clúster. Los proyectos comunitarios de Kubernetes, como K, ube-state-metrics pueden ayudarte a analizar rápidamente las tendencias de tu clúster. Los complementos y controladores más comunes de la comunidad de Kubernetes también emiten métricas de Prometheus, lo que te permite investigar cosas como escaladores automáticos o programadores personalizados.

La guía de prácticas recomendadas de observabilidad incluye ejemplos de otras métricas de Kubernetes que puede utilizar para obtener más información.