Encontrando a latência escondida no DNS do Kubernetes
Separar o tempo de consulta DNS do tempo de conexão TCP revelou por que uma API saudável continuava disparando alertas de latência.
A melhora de cerca de 9× descreve a consulta DNS medida, não cada requisição de API nem uma garantia sustentada de nível de serviço.
Contribuição em resumo
- Minha responsabilidade
- Diagnóstico camada por camada, uma configuração de DNS compartilhada no Helm e validação de rollout em etapas.
- Escopo
- Medição de DNS em produção e oito verificações de render por aplicação/ambiente.
- Colaboração & limites
- Alterei a configuração de deployment compartilhada depois de separar o overhead de DNS do tempo de conexão com o banco de dados.
- Resultado
- O p50 da consulta DNS passou de ~18.7 ms para 2.06 ms na medição registrada; isso não é uma aceleração de 9× na API.
Um serviço saudável com um sinal de latência instável
A API tinha pods saudáveis, uso de recursos normal e nenhum erro 5xx observado, mas seu alerta de latência P95 abria e fechava repetidamente. Adicionar capacidade teria tratado o sintoma antes de identificar onde o tempo da requisição era gasto.
Minha contribuição
Comparei a resolução de DNS, a consulta totalmente qualificada e a conexão TCP direta de dentro de um pod em produção. A conexão com o banco de dados em si era rápida. O resolver do Kubernetes tentava os domínios de busca locais antes de resolver o hostname de um banco de dados externo.
A decisão
O valor padrão ndots:5 tratava o hostname externo como relativo e o expandia pelos domínios de busca do pod. Adicionei uma configuração ndots:2 ajustável ao template Helm compartilhado, verifiquei o render em oito combinações de aplicação/ambiente e promovi a mudança por development e staging até produção.
| Sinal | Antes | Depois |
|---|---|---|
| p50 da consulta DNS | ~18.7 ms | 2.06 ms |
Resultados e medição
Os dois deployments em produção receberam a nova opção de DNS. Repetir a consulta que abriu a investigação mostrou uma redução de aproximadamente 18.7 ms p50 para 2.06 ms, cerca de nove vezes mais rápido. Os pods permaneceram saudáveis, sem reinicializações relatadas no snapshot de validação.
O encerramento registrou o P95 da API em cerca de 0.12 segundos ao longo dos 20 minutos de observação após o rollout, e o alerta parou de oscilar. A comparação de DNS e a observação da API são medições diferentes; a melhora na consulta não deve ser apresentada como uma melhora de nove vezes no tempo total de resposta da API.
Trade-offs e acompanhamento
Mudar o comportamento de busca do resolver precisa preservar os nomes curtos usados dentro do cluster. A configuração compartilhada continuou ajustável. O cache de DNS em todo o cluster e a capacidade do resolver foram acompanhamentos separados, e não resultados atribuídos a esta correção por aplicação.
A lição
Um sintoma de latência relacionado ao banco de dados pode se originar antes de o banco receber uma query. Decomponha o caminho da requisição e repita a mesma medição após a mudança.
Decisões e próximos passos
Uma visão retrospectiva da abordagem e dos seus limites. A próxima melhoria é uma proposta, não um resultado já entregue.
Alternativa e justificativa
Adicionar réplicas ou capacidade de banco de dados não eliminaria a expansão de busca do resolver. Ajuste a resolução depois de isolar o tempo de consulta do tempo de TCP.
Trade-off
Um valor menor de ndots muda o comportamento da consulta; valide os nomes internos e as dependências externas antes de generalizar a configuração.
O que eu melhoraria em seguida
Próxima melhoria: estender a janela de observação e adicionar verificações de regressão do resolver para nomes internos e externos representativos.