Container Service for Kubernetes:Troubleshoot DNS resolution errors

# View the pod's DNS policy
kubectl get pod <pod-name> -o yaml

# Log in to the pod and inspect the DNS configuration
kubectl exec -it <pod-name> -- cat /etc/resolv.conf

# View CoreDNS pod status and placement
kubectl -n kube-system get pod -o wide -l k8s-app=kube-dns

NAME                      READY   STATUS    RESTARTS   AGE   IP            NODE
coredns-xxxxxxxxx-xxxxx   1/1     Running   0          25h   172.20.6.53   cn-hangzhou.192.168.0.198

# View real-time CPU and memory usage
kubectl -n kube-system top pod -l k8s-app=kube-dns

NAME                      CPU(cores)   MEMORY(bytes)
coredns-xxxxxxxxx-xxxxx   3m           18Mi

kubectl -n kube-system logs -f --tail=500 --timestamps <coredns-pod-name>

[INFO] 172.20.2.25:44525 - 36259 "A IN redis-master.default.svc.cluster.local. udp 56 false 512" NOERROR qr,aa,rd 110 0.000116946s

Testar conectividade de rede entre pods de aplicação e CoreDNS

Acesse o namespace de rede do pod de aplicação usando um destes métodos:

• Método 1 (recomendado): Execute kubectl exec -it <pod-name> -- bash para entrar no pod.

• Método 2: Faça login no nó, encontre o ID do processo com ps aux | grep <application-process-name> e entre no namespace de rede com nsenter -t <pid> -n bash.

• Método 3 (para pods que reiniciam frequentemente):

  1. Faça login no nó.

  2. Execute docker ps -a | grep <application-container-name> para encontrar os IDs dos contêineres sandbox (nomes começam com k8s_POD_).

  3. Execute docker inspect <sandboxed-container-ID> | grep netns para encontrar o caminho do namespace de rede em /var/run/docker/netns/xxxx.

  4. Execute nsenter -n bash para entrar no namespace. > Note: Não adicione espaço entre -n e <netns-path>.

A partir do namespace de rede do pod, teste a conectividade:

# Test connectivity to the kube-dns Service
dig <domain> @<kube-dns-svc-ip>

# Test Internet Control Message Protocol (ICMP) connectivity to the CoreDNS pod
ping <coredns-pod-ip>

# Test DNS query directly to the CoreDNS pod
dig <domain> @<coredns-pod-ip>

Substitua <kube-dns-svc-ip> pelo IP do Service kube-dns no namespace kube-system e <coredns-pod-ip> pelo IP de um pod do CoreDNS.

Testar conectividade de rede do CoreDNS

1. Faça login no nó onde o pod do CoreDNS está em execução.

2. Execute ps aux | grep coredns para obter o ID do processo do CoreDNS.

3. Execute nsenter -t <pid> -n bash para entrar no namespace de rede do CoreDNS.

4. Teste a conectividade:

   # Test connectivity to the Kubernetes API server
   telnet <apiserver_clusterip> 6443  # apiserver_clusterip is the ClusterIP of the kubernetes Service in the default namespace.
   
   # Test connectivity to upstream DNS servers
   dig <domain> @100.100.2.136
   dig <domain> @100.100.2.138

Diagnosticar a rede de contêineres

1. Acesse o console ACKconsole ACK.

2. Na página Clusters, clique no nome do cluster ou em Details na coluna Actions.

3. No painel de navegação à esquerda, escolha Operations > Cluster Check.

4. Na página Container Intelligence Service, escolha Cluster Check > Diagnosis.

5. Na página Diagnosis, clique na aba Network Diagnosis.

6. Defina Source address como o IP do pod de aplicação, Destination address como o IP do Service kube-dns e Destination port como 53. Selecione Enable packet tracing e I know and agree e clique em Create diagnosis.

7. Na lista de diagnósticos, clique em Diagnosis details do registro desejado.

Os resultados mostram Diagnosis result, Packet paths e All possible paths, além das causas de erro identificadas. Consulte Usar o recurso de diagnóstico de cluster para solucionar problemas do cluster.

Capturar pacotes

Use a captura de pacotes quando os erros forem intermitentes e difíceis de reproduzir.

1. Faça login nos nós onde os pods de aplicação e o pod do CoreDNS estão em execução.

2. Capture o tráfego DNS em cada instância ECS:

   tcpdump -i any port 53 -C 20 -W 200 -w /tmp/client_dns.pcap

   Esse comando captura todo o tráfego na porta 53, alternando entre até 200 arquivos de 20 MB cada.

3. Reproduza o erro e analise os pacotes da janela de tempo da falha. Verifique os logs da aplicação para obter os carimbos de data/hora exatos.

A captura de pacotes tem impacto insignificante no serviço — apenas um leve aumento na utilização da CPU e na E/S de disco.

Nome de domínio externo não pode ser resolvido

Verifique o código de resposta no log de consultas do CoreDNS. Ative o plugin de log se ainda não estiver ativado (consulte Configurar resolução de DNS) e pesquise pelo domínio com falha. NXDOMAIN significa que o domínio não existe no upstream — frequentemente porque um sufixo de busca foi anexado, criando um FQDN inválido. SERVFAIL ou REFUSED indica problema no servidor upstream; verifique a configuração do CoreDNS e a conectividade com 100.100.2.136 e 100.100.2.138.

Nomes de domínio de Services headless não podem ser resolvidos

Em versões do CoreDNS anteriores a 1.7.0, instabilidades na rede do servidor de API podem fazer o CoreDNS encerrar, interrompendo as atualizações de registros de Services headless. Atualize para a versão 1.7.0 ou posterior. Consulte [\[Atualizações de Componentes\] Atualizar CoreDNS](t1964489.dita#task_1964489).

Nomes de domínio de pods StatefulSet não podem ser resolvidos

O modelo de pod do StatefulSet deve definir serviceName como o nome do Service headless. Sem isso, nomes DNS por pod (por exemplo, pod.headless-svc.ns.svc.cluster.local) não podem ser resolvidos, mesmo que o nome no nível do Service (por exemplo, headless-svc.ns.svc.cluster.local) funcione. Defina serviceName na especificação do StatefulSet.

Consultas DNS bloqueadas por regras de grupo de segurança ou ACLs de rede

Regras de grupo de segurança ou listas de controle de acesso (ACLs) de rede estão bloqueando a porta UDP 53, causando falhas de DNS nos nós afetados. Permita o tráfego de entrada e saída na porta UDP 53.

Erros de conectividade na rede de contêineres causam falhas de DNS

Erros na rede de contêineres bloqueiam a porta UDP 53. Use o recurso Network Diagnosis para identificar o caminho quebrado e a causa raiz.

Pods do CoreDNS sobrecarregados

Quando o volume de consultas excede a capacidade das réplicas do CoreDNS, a latência aumenta e ocorrem falhas. Verifique se o uso de CPU e memória está próximo do limite (kubectl -n kube-system top pod -l k8s-app=kube-dns).

Duas soluções:

• Implante o NodeLocal DNSCache para absorver consultas localmente e reduzir a carga no CoreDNS. Consulte Configurar NodeLocal DNSCache.

• Escale horizontalmente as réplicas do CoreDNS para que a utilização máxima de CPU por pod permaneça bem abaixo da CPU disponível no nó.

Consultas DNS não distribuídas uniformemente entre os pods do CoreDNS

Agendamento desequilibrado de pods ou uma configuração sessionAffinity no kube-dns pode causar distribuição desigual de consultas. Sintoma: utilização de CPU visivelmente diferente entre os pods do CoreDNS.

Duas soluções:

• Escale horizontalmente os pods do CoreDNS e distribua-os por diferentes nós.

• Remova a configuração sessionAffinity do Service kube-dns. Consulte Configurar o Service kube-dns.

Pods do CoreDNS não executam normalmente

YAML ou ConfigMap mal configurados podem impedir o início do CoreDNS ou causar falhas. Sintomas: pods não estão em estado Running, contagem de reinicializações aumentando ou erros nos logs.

Verifique o log do CoreDNS para estes erros comuns:

Falhas na resolução de DNS devido a cliente sobrecarregado

Quando a instância ECS está totalmente carregada, pacotes UDP podem ser descartados antes de chegar ao CoreDNS. Procure por taxa anormal de retransmissão da controladora de interface de rede (NIC) e alta utilização de CPU nos dados de monitoramento.

Duas opções:

• Abra um ticketAbra um ticketAbra um ticketAbra um ticketAbra um ticketAbra um ticketAbra um ticketAbra um ticketAbra um ticketAbra um ticket para investigação detalhada.

• Implante o NodeLocal DNSCache para reduzir o tráfego DNS entre nós. Consulte Configurar NodeLocal DNSCache.

Tabela conntrack cheia

Quando a tabela conntrack está cheia, novas conexões UDP e TCP são descartadas. Isso geralmente causa falhas de DNS em horários de pico que se recuperam fora do pico. Para confirmar, execute dmesg -H no nó afetado e procure por conntrack full durante a janela da falha.

Aumente o número máximo de entradas na tabela conntrack. Consulte Como aumento o número máximo de conexões rastreadas na tabela conntrack do kernel Linux?

Plugin autopath não funciona normalmente

Um defeito conhecido no plugin autopath causa falhas ocasionais na resolução ou IPs incorretos para domínios externos. Domínios internos resolvem corretamente. O problema piora em clusters com altas taxas de criação de contêineres.

Desative o plugin autopath:

1. Edite o ConfigMap do CoreDNS com kubectl -n kube-system edit configmap coredns.

2. Exclua a linha autopath @kubernetes. Salve e saia.

3. Verifique se a configuração foi carregada checando os logs do CoreDNS para reload.

Falhas na resolução de DNS devido a consultas simultâneas de registros A e AAAA

Algumas distribuições Linux enviam consultas A e AAAA simultaneamente pela mesma porta, acionando conflitos no conntrack que descartam pacotes UDP.

Sintomas: falhas intermitentes na resolução; a captura de pacotes mostra consultas A e AAAA simultâneas da mesma porta de origem.

As correções dependem da base da sua imagem:

• CentOS ou Ubuntu: Adicione options timeout:2 attempts:3 rotate single-request-reopen à configuração do resolvedor DNS.

• Alpine Linux: Substitua a imagem baseada em Alpine por uma baseada em outro SO. Consulte Ressalvas do Alpine.

• PHP com cURL: Adicione CURL_IPRESOLVE_V4 para forçar resolução apenas IPv4. Consulte Funções cURL.

• Todos os ambientes: Implante o NodeLocal DNSCache, que mitiga a condição de corrida. Consulte Configurar NodeLocal DNSCache.

Falhas na resolução de DNS devido a erros no IPVS

No modo IPVS com CentOS ou Alibaba Cloud Linux 2 (kernel anterior a 4.19.91-25.1.al7.x86_64), a remoção de pods de backend UDP causa conflitos de porta de origem que descartam pacotes. Falhas de DNS duram cerca de 5 minutos durante eventos de dimensionamento de nós ou do CoreDNS.

Duas soluções:

• Implante o NodeLocal DNSCache para ignorar o caminho IPVS nas consultas DNS. Consulte Configurar NodeLocal DNSCache.

• Reduza o tempo limite de sessão UDP no modo IPVS. Consulte Alterar o período de tempo limite UDP no modo IPVS.

NodeLocal DNSCache não funciona

As consultas DNS ignoram o NodeLocal DNSCache quando uma das condições se aplica:

• O dnsConfig não foi injetado nos pods de aplicação, então eles ainda apontam para o IP do Service kube-dns.

• Os pods usam uma imagem base Alpine Linux, que consulta todos os nameservers simultaneamente, incluindo o CoreDNS diretamente.

Para o primeiro caso, ative a injeção automática de dnsConfig. Consulte Configurar NodeLocal DNSCache. Para imagens Alpine, use uma imagem construída sobre outro SO. Consulte Ressalvas do Alpine.

Nomes do Alibaba Cloud DNS PrivateZone não podem ser resolvidos

O Alibaba Cloud DNS PrivateZone requer UDP, não TCP. Com o NodeLocal DNSCache, domínios do PrivateZone, endpoints de API vpc-proxy ou outros nomes de domínio podem falhar na resolução ou resolver para IPs incorretos.

Adicione prefer_udp à configuração do CoreDNS para forçar UDP nas consultas upstream. Consulte Configurar CoreDNS.