Comece pelo CoreDNS: reinícios de pod, throttling de CPU, taxa de erro e número de réplicas contra o volume de consultas. Depois cheque o ndots, já que o padrão de 5 faz toda consulta externa tentar vários domínios de busca antes e multiplica a carga de consultas. Culpados clássicos são esgotamento da tabela conntrack nos nós, perda de pacotes UDP sob carga e resolvers de thread única. Cache de DNS local no nó mais nomes totalmente qualificados normalmente resolvem isso.
Por que os entrevistadores perguntam isso
Problemas de DNS no Kubernetes são comuns, mal compreendidos, e revelam o quão fundo vai o seu conhecimento de plataforma de verdade. O entrevistador quer especificidades: ndots e domínios de busca, conntrack, escala e cache do CoreDNS. Respostas vagas sobre checar o DNS mostram que você leu sobre o problema, enquanto nomear a amplificação do ndots mostra que você já depurou isso.
Como estruturar sua resposta
- Quantifique o sintoma: quais pods, quais nomes, qual erro, qual taxa.
- Cheque a saúde, o throttling e a capacidade de réplicas do CoreDNS primeiro.
- Explique ndots e a amplificação por domínio de busca em consultas externas.
- Cubra causas no nível do nó: limites de conntrack e perda de UDP.
- Dê as correções duráveis: cache local no nó, ndots ajustado, FQDNs.
Exemplo de resposta
Eu começaria medindo em vez de chutando: quais nomes falham, internos ou externos, e se está correlacionado com carga. Depois o próprio CoreDNS, porque se aqueles pods estão com throttling de CPU ou só existem dois deles para um cluster grande, tudo abaixo parece intermitente. O que surpreende as pessoas é o ndots. O resolv.conf padrão do pod define ndots como 5, então buscar um hostname externo tenta contra todo domínio de busca antes do real, o que transforma uma consulta em cinco e coloca bastante pressão extra no CoreDNS. A correção é ou um ponto no fim do nome para torná-lo totalmente qualificado, ou um dnsConfig customizado com ndots em 2. Do lado do nó, eu checo o uso da tabela conntrack, porque uma tabela cheia descarta respostas UDP em silêncio e parece exatamente DNS instável. Na prática, publicar o NodeLocal DNSCache resolveu isso para a gente em definitivo, já que ele move as consultas para um cache local sobre TCP.
Vai encarar essa entrevista em breve? O GhostPilot escuta a sua chamada ao vivo, identifica a pergunta no instante em que ela é feita e coloca uma resposta estruturada na sua tela em tempo real. Teste na sua próxima entrevista simulada ou pegue um Session Pass de $29, sem assinatura, para a hora da verdade.
Veja como funcionaPerguntas de acompanhamento que você pode esperar
- O que o NodeLocal DNSCache muda no caminho da consulta?
- Como você confirmaria esgotamento de conntrack num nó?
- Por que baixar o ndots pode quebrar a descoberta de serviços com nomes curtos?
Mais perguntas para Engenheiro de Confiabilidade de Sites
Seu entrevistador vai fazer a própria versão desta. Cole a descrição real da vaga no Question Predictor gratuito e receba as 20 perguntas que essa vaga tem mais chance de fazer, com o que cada uma está de fato sondando.
Prever minhas perguntas