Upnetix Labs · protocolo de experimento
Protocolo: Qual o impacto do número de réplicas de um Deployment no tempo de recuperação após falha de pod em Kubernetes?
Este protocolo mede como o tempo de recuperação de um serviço varia conforme o número de réplicas em um Deployment Kubernetes. O objetivo é quantificar o tempo entre a falha proposital de um pod e a restauração total da capacidade do serviço.
Como o tempo de recuperação de um serviço em Kubernetes varia com o número de réplicas de um Deployment após a falha de um pod?
Hipótese
Aumentar o número de réplicas reduz o tempo de recuperação percebido pelo usuário após a falha de um pod.
Variáveis
| Independentes (o que varia) | Número de réplicas no Deployment (ex: 1, 2, 4, 8) |
|---|---|
| Dependentes (o que se mede) | Tempo de recuperação do serviço (em segundos) |
| Controladas (o que fica fixo) | Imagem do container; Configuração do Deployment (exceto número de réplicas); Cluster Kubernetes (versão, recursos de nó, rede); Tipo e frequência de requisições de teste |
Ambiente
Cluster Kubernetes funcional (mínimo 2 nós), aplicação de teste HTTP simples (ex: nginx), ferramenta de teste de carga como k6 para simular requisições, Prometheus para coleta de métricas de disponibilidade.
Procedimento
- Preparar ambiente
Implante um Deployment com a aplicação de teste e configure o Service para expor a aplicação.
- Configurar Prometheus
Garanta que Prometheus está coletando métricas de disponibilidade do serviço.
- Configurar k6
Prepare um script k6 para enviar requisições HTTP contínuas ao serviço.
k6 run script.js - Definir número de réplicas
Ajuste o número de réplicas no Deployment para o valor de teste.
kubectl scale deployment <nome> --replicas=<N> - Iniciar teste de carga
Inicie o teste de carga com k6.
- Induzir falha
Delete um pod do Deployment manualmente.
kubectl delete pod <nome-do-pod> - Medir tempo de recuperação
Registre o tempo entre a falha e a restauração da taxa de sucesso das requisições (HTTP 200) ao nível anterior à falha, usando logs do k6 e métricas do Prometheus.
- Repetir
Repita o teste para cada configuração de réplicas, pelo número de repetições definido.
Planilha de coleta
| numero_replicas (unidade) | tempo_recuperacao_s (segundos) | timestamp_falha (ISO 8601) | timestamp_recuperacao (ISO 8601) |
|---|---|---|---|
| EXEMPLO: 4, 3.2, 2024-06-10T15:01:23Z, 2024-06-10T15:01:26Z | |||
Repetições recomendadas: 5. Baixe a planilha vazia em CSV: colunas prontas.
Análise
Calcule média, mediana e desvio padrão do tempo de recuperação para cada configuração de réplicas. Compare os resultados entre diferentes números de réplicas para identificar tendências e pontos de melhoria.
Critérios de decisão
- Tempo de recuperação aceitável deve ser menor que o tempo de timeout do cliente.
- Resultados só são válidos se a taxa de sucesso retornar ao patamar anterior à falha.
- Descarte execuções com falhas externas (ex: queda do cluster).
Fontes de erro e mitigação
- Variação de carga no cluster pode afetar o tempo de recuperação; execute testes em horários de baixa utilização.
- Caches de rede ou DNS podem mascarar falhas; limpe caches antes de cada repetição.
- A latência de rede entre k6 e o cluster deve ser estável; execute k6 dentro do mesmo cluster se possível.
Referências
- Kubernetes Deployments · Kubernetes (CNCF) (kubernetes.io)
- Prometheus Monitoring · Prometheus (CNCF) (prometheus.io)
- Publicado
- 09/09/2026
- Última revisão
- 09/09/2026
- Versão do conteúdo
- 1.0
- Referências
- 2 oficiais
- Revisão técnica
- redação e revisão por IA, URLs conferidas na publicação
- Status
- Atual
