Kubernetes Upstream SLOs - Amazon EKS
Kubernetes SLOsMétricas de SLI do KubernetesSLOs em seu cluster

As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.

Kubernetes Upstream SLOs

O Amazon EKS executa o mesmo código das versões upstream do Kubernetes e garante que os clusters EKS operem dentro do SLOs definido pela comunidade do Kubernetes. O Kubernetes Scalability Special Interest Group (SIG) define as metas de escalabilidade e investiga gargalos no desempenho por meio de e. SLIs SLOs

SLIs são como medimos um sistema, como métricas ou medidas que podem ser usadas para determinar o quão “bem” o sistema está funcionando, por exemplo, latência ou contagem de solicitações. SLOs defina os valores que são esperados para quando o sistema está funcionando “bem”, por exemplo, a latência da solicitação permanece em menos de 3 segundos. O Kubernetes SLOs e o Kubernetes SLIs se concentram no desempenho dos componentes do Kubernetes e são completamente independentes do Amazon EKS Service, SLAs que se concentra na disponibilidade do endpoint do cluster EKS.

O Kubernetes tem vários recursos que permitem aos usuários ampliar o sistema com complementos ou drivers personalizados, como drivers CSI, webhooks de admissão e escalonadores automáticos. Essas extensões podem impactar drasticamente o desempenho de um cluster Kubernetes de maneiras diferentes, ou seja, um webhook de admissão failurePolicy=Ignore pode adicionar latência às solicitações de API K8s se o destino do webhook não estiver disponível. O Kubernetes Scalability SIG define escalabilidade usando uma estrutura do tipo “você promete, nós prometemos”:

Kubernetes SLOs

O Kubernetes SLOs não leva em conta todos os plug-ins e limitações externas que podem afetar um cluster, como escalabilidade de nós de trabalho ou webhooks de admissão. Eles SLOs se concentram nos componentes do Kubernetes e garantem que as ações e os recursos do Kubernetes estejam operando dentro das expectativas. Isso SLOs ajuda os desenvolvedores do Kubernetes a garantir que as alterações no código do Kubernetes não prejudiquem o desempenho de todo o sistema.

O Kubernetes Scalability SIG define o seguinte SLO/ oficial. SLIs A equipe do Amazon EKS executa regularmente testes de escalabilidade em clusters EKS SLOs/SLIs para monitorar a degradação do desempenho à medida que mudanças são feitas e novas versões são lançadas.

Objetivo Definição SLO

Latência da solicitação de API (mutação)

Latência de processamento de chamadas de API mutantes para objetos únicos para cada par (recurso, verbo), medida como 99º percentil nos últimos 5 minutos

Na instalação padrão do Kubernetes, para cada par (recurso, verbo), excluindo recursos virtuais e agregados e definições de recursos personalizadas, 99º percentil por dia de cluster <= 1s

Latência da solicitação de API (somente leitura)

Latência de processamento de chamadas de API sem streaming (somente leitura) para cada par (recurso, escopo), medida como 99º percentil nos últimos 5 minutos

Na instalação padrão do Kubernetes, para cada par (recurso, escopo), excluindo recursos virtuais e agregados e definições de recursos personalizadas, 99º percentil por dia de cluster: (a) <= 1s se (b) <= 30s caso contrário (se ou) scope=resource scope=namespace scope=cluster

Latência de inicialização do pod

Latência de inicialização de pods sem estado programáveis, excluindo o tempo para extrair imagens e executar contêineres de inicialização, medido desde o registro de data e hora de criação do pod até o momento em que todos os contêineres são relatados como iniciados e observados por meio do watch, medido como 99º percentil nos últimos 5 minutos

Na instalação padrão do Kubernetes, 99º percentil por dia de cluster <= 5s

Latência da solicitação de API

O kube-apiserver foi --request-timeout definido como 1m0s por padrão, o que significa que uma solicitação pode ser executada por até um minuto (60 segundos) antes de atingir o tempo limite e ser cancelada. Os SLOs definidos para latência são divididos pelo tipo de solicitação que está sendo feita, que pode ser mutante ou somente para leitura:

Mutante

Solicitações mutantes no Kubernetes fazem alterações em um recurso, como criações, exclusões ou atualizações. Essas solicitações são caras porque essas alterações devem ser gravadas no back-end do etcd antes que o objeto atualizado seja retornado. O Etcd é um armazenamento distribuído de valores-chave usado para todos os dados do cluster Kubernetes.

Essa latência é medida como o 99º percentil em 5 minutos para pares (recurso, verbo) de recursos do Kubernetes. Por exemplo, isso mediria a latência das solicitações Create Pod e Update Node. A latência da solicitação deve ser <= 1 segundo para satisfazer o SLO.

Somente leitura

Solicitações somente para leitura recuperam um único recurso (como Get Pod X) ou uma coleção (como “Get all Pods from Namespace X”). O kube-apiserver mantém um cache de objetos, portanto, os recursos solicitados podem ser retornados do cache ou talvez precisem ser recuperados primeiro do etcd. Essas latências também são medidas pelo 99º percentil em 5 minutos, no entanto, as solicitações somente para leitura podem ter escopos separados. O SLO define dois objetivos diferentes:

  • Para solicitações feitas para um único recurso (ou seja,kubectl get pod -n mynamespace my-controller-xxx), a latência da solicitação deve permanecer <= 1 segundo.

  • Para solicitações feitas para vários recursos em um namespace ou cluster (por exemplo,kubectl get pods -A), a latência deve permanecer <= 30 segundos

O SLO tem valores-alvo diferentes para diferentes escopos de solicitação porque as solicitações feitas para uma lista de recursos do Kubernetes esperam que os detalhes de todos os objetos na solicitação sejam retornados dentro do SLO. Em grandes clusters ou grandes coleções de recursos, isso pode resultar em grandes tamanhos de resposta que podem levar algum tempo para retornar. Por exemplo, em um cluster executando dezenas de milhares de pods, com cada pod custando aproximadamente 1 KiB quando codificado em JSON, o retorno de todos os pods no cluster consistiria em 10 MB ou mais. Os clientes do Kubernetes podem ajudar a reduzir esse tamanho de resposta usando o APIList Chunking para recuperar grandes coleções de recursos.

Latência de inicialização do pod

Esse SLO se preocupa principalmente com o tempo que leva desde a criação do pod até o momento em que os contêineres desse pod realmente começam a ser executados. Para medir isso, calcula-se a diferença entre o timestamp de criação registrado no pod e quando um WATCH nesse pod relata que os contêineres foram iniciados (excluindo o tempo de extração da imagem do contêiner e da execução inicial do contêiner). Para satisfazer o SLO, o 99º percentil por dia de cluster dessa latência de inicialização do pod deve permanecer <=5 segundos.

Observe que esse SLO pressupõe que os nós de trabalho já existam nesse cluster em um estado pronto para o agendamento do pod. Esse SLO não leva em conta a extração de imagens ou a execução de contêineres de inicialização e também limita o teste a “pods sem estado” que não utilizam plug-ins de armazenamento persistente.

Métricas de SLI do Kubernetes

O Kubernetes também está melhorando a observabilidade ao SLIs adicionar métricas do Prometheus aos componentes do Kubernetes que as monitoram ao longo do tempo. SLIs Usando a Prometheus Query Language (PromQL), podemos criar consultas que exibem o desempenho do SLI ao longo do tempo em ferramentas como os painéis Prometheus ou Grafana. Abaixo estão alguns exemplos acima. SLOs

Latência da solicitação do servidor de API

Métrica Definição

apiserver_request_sli_duration_seconds

Distribuição da latência de resposta (sem contar a duração do webhook e os tempos de espera da fila de prioridade e imparcialidade) em segundos para cada verbo, grupo, versão, recurso, sub-recurso, escopo e componente.

apiserver_request_duration_seconds

Distribuição da latência de resposta em segundos para cada verbo, valor de simulação, grupo, versão, recurso, sub-recurso, escopo e componente.

Observação: a apiserver_request_sli_duration_seconds métrica está disponível a partir do Kubernetes 1.27.

Você pode usar essas métricas para investigar os tempos de resposta do API Server e se há gargalos nos componentes do Kubernetes ou em outros plugins/componentes. As consultas abaixo são baseadas no painel do SLO da comunidade.

Latência de solicitação de API SLI (mutante) - dessa vez, não inclui a execução do webhook ou o tempo de espera na fila. 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

Total da latência da solicitação de API (mutante) - esse é o tempo total que a solicitação levou no servidor da API. Esse tempo pode ser maior que o tempo de SLI, pois inclui a execução do webhook e os tempos de espera de prioridade e justiça da 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

Nessas consultas, estamos excluindo as solicitações da API de streaming que não retornam imediatamente, como kubectl port-forward or kubectl exec requests (subresource!~"proxy|attach|log|exec|portforward"), e estamos filtrando apenas os verbos do Kubernetes que modificam objects (). verb=~"CREATE|DELETE|PATCH|POST|PUT" Em seguida, calculamos o 99º percentil dessa latência nos últimos 5 minutos.

Podemos usar uma consulta semelhante para as solicitações de API somente para leitura. Basta modificar os verbos que estamos filtrando para incluir as ações LIST somente leitura e. GET Também há limites de SLO diferentes, dependendo do escopo da solicitação, ou seja, obter um único recurso ou listar vários recursos.

Latência de solicitação de API SLI (somente leitura) - dessa vez não inclui a execução do webhook ou o tempo de espera na fila. Para um único recurso (escopo=recurso, limite=1s) histogram_quantile(0.99, sum(rate(apiserver_request_sli_duration_seconds_bucket{verb=~"GET", scope=~"resource"}[5m])) by (resource, subresource, verb, scope, le))

Para uma coleção de recursos no mesmo 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))

Para uma coleção de recursos em todo o cluster (escope=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))

Latência total da solicitação de API (somente leitura) - esse é o tempo total que a solicitação levou no servidor da API. Esse tempo pode ser maior que o tempo de SLI, pois inclui a execução do webhook e os tempos de espera. Para um único recurso (escopo=recurso, limite=1s) histogram_quantile(0.99, sum(rate(apiserver_request_duration_seconds_bucket{verb=~"GET", scope=~"resource"}[5m])) by (resource, subresource, verb, scope, le))

Para uma coleção de recursos no mesmo 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))

Para uma coleção de recursos em todo o cluster (escope=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))

As métricas do SLI fornecem informações sobre o desempenho dos componentes do Kubernetes, excluindo o tempo que as solicitações passam esperando nas filas de prioridade e justiça da API, trabalhando por meio de webhooks de admissão ou outras extensões do Kubernetes. As métricas totais fornecem uma visão mais holística, pois refletem o tempo que seus aplicativos esperariam por uma resposta do servidor da API. A comparação dessas métricas pode fornecer informações sobre onde os atrasos no processamento da solicitação estão sendo introduzidos.

Latência de inicialização do pod

Métrica Definição

kubelet_pod_start_sli_duration_seconds

Duração em segundos para iniciar um pod, excluindo o tempo para extrair imagens e executar contêineres de inicialização, medido desde o registro de data e hora de criação do pod até o momento em que todos os contêineres são relatados como iniciados e observados por meio do watch

kubelet_pod_start_duration_seconds

Duração em segundos, desde o kubelet ver um pod pela primeira vez até o pod começar a funcionar. Isso não inclui o tempo para programar o pod ou expandir a capacidade do nó de trabalho.

Observação: kubelet_pod_start_sli_duration_seconds está disponível a partir do Kubernetes 1.27.

Semelhante às consultas acima, você pode usar essas métricas para obter informações sobre por quanto tempo o escalonamento de nós, as extraições de imagens e os contêineres de inicialização estão atrasando o lançamento do pod em comparação com as ações do Kubelet.

Latência de inicialização do pod SLI - esse é o tempo desde a criação do pod até o momento em que os contêineres do aplicativo são relatados como em execução. Isso inclui o tempo necessário para que a capacidade do nó de trabalho esteja disponível e o pod seja programado, mas não inclui o tempo necessário para extrair imagens ou para que os contêineres de inicialização sejam executados. histogram_quantile(0.99, sum(rate(kubelet_pod_start_sli_duration_seconds_bucket[5m])) by (le))

Latência total de inicialização do pod - esse é o tempo que o kubelet leva para iniciar o pod pela primeira vez. Isso é medido a partir do momento em que o kubelet recebe o pod via WATCH, o que não inclui o tempo de escalonamento ou agendamento do nó de trabalho. Isso inclui o tempo para extrair imagens e iniciar contêineres para execução. histogram_quantile(0.99, sum(rate(kubelet_pod_start_duration_seconds_bucket[5m])) by (le))

SLOs em seu cluster

Se você estiver coletando as métricas do Prometheus dos recursos do Kubernetes em seu cluster EKS, poderá obter informações mais detalhadas sobre o desempenho dos componentes do plano de controle do Kubernetes.

O repositório perf-tests inclui painéis Grafana que exibem as latências e as métricas críticas de desempenho do cluster durante os testes. A configuração de testes de desempenho aproveita o kube-prometheus-stack, um projeto de código aberto que vem configurado para coletar métricas do Kubernetes, mas você também pode usar o Amazon Managed Prometheus e o Amazon Managed Grafana.

Se você estiver usando a solução Prometheus kube-prometheus-stack ou uma solução similar, poderá instalar o mesmo painel para observar SLOs o seu cluster em tempo real.

  1. Primeiro, você precisará instalar as Regras do Prometheus que são usadas nos painéis com. kubectl apply -f prometheus-rules.yaml Você pode baixar uma cópia das regras aqui: https://github.com/kubernetes/perf- tests/blob/master/clusterloader2/pkg/prometheus/manifests/prometheus -rules.yaml

    1. Certifique-se de verificar se o namespace no arquivo corresponde ao seu ambiente

    2. Verifique se os rótulos correspondem ao valor do prometheus.prometheusSpec.ruleSelector leme se você estiver usando kube-prometheus-stack

  2. Em seguida, você pode instalar os painéis no Grafana. Os painéis json e os scripts python para gerá-los estão disponíveis aqui: perf- https://github.com/kubernetes/ tests/tree/master/clusterloader2/pkg/prometheus/manifests/dashboards

    1. o slo.json painel exibe o desempenho do cluster em relação ao Kubernetes SLOs

Considere que SLOs eles estão focados no desempenho dos componentes do Kubernetes em seus clusters, mas há métricas adicionais que você pode analisar que fornecem diferentes perspectivas ou insights sobre seu cluster. Projetos comunitários do Kubernetes, como o K, ube-state-metrics podem ajudar você a analisar rapidamente as tendências em seu cluster. Os plug-ins e drivers mais comuns da comunidade Kubernetes também emitem métricas do Prometheus, permitindo que você investigue coisas como escaladores automáticos ou agendadores personalizados.

O Guia de Melhores Práticas de Observabilidade tem exemplos de outras métricas do Kubernetes que você pode usar para obter mais informações.