Container Service for Kubernetes:Troubleshoot DNS resolution issues

Observações importantes

A solução de problemas de DNS no Kubernetes é complexa devido à natureza multicamada e dinâmica das arquiteturas de rede. Além de erros nos componentes CoreDNS e NodeLocal DNSCache, os seguintes fatores também podem causar falhas na resolução de DNS.

• Carga da arquitetura de rede

  O caminho de resolução de DNS envolve vários componentes, incluindo CoreDNS/kube-dns, kube-proxy e plug-ins CNI. Uma falha em qualquer camada pode causar problemas. Portanto, solucione problemas de cada componente passo a passo para identificar a causa raiz. Para obter o caminho completo de solução de problemas, consulte Solucionar problemas de outros componentes no caminho de DNS.

• Mecanismo de descoberta de serviços e obscuridade de namespace

  • Dependência de FQDN: O acesso a serviços entre namespaces exige o uso do nome de domínio completo (por exemplo, service.namespace.svc.cluster.local). Se o namespace não for especificado no nome de domínio, o DNS pesquisará apenas dentro do namespace atual. O acesso entre namespaces falha sem mensagens de erro claras.

  • Comportamento de Headless Services: Os Headless Services retornam IPs de pods diretamente. Uma configuração inadequada pode resultar em registros DNS incompletos ou ausentes.

• Restrições de política de rede

  • Bloqueio implícito: Se a NetworkPolicy do Pod não permitir tráfego nas portas DNS (porta UDP e TCP padrão 53), o pod não poderá se comunicar com o CoreDNS.

  • Interferência de grupo de segurança da VPC: O firewall interno ou as regras de grupo de segurança podem descartar o tráfego DNS, especialmente em configurações de grupo de segurança da VPC.

  • Abordagem de solução de problemas: Verifique a conectividade de rede dos pods do CoreDNS no namespace kube-system e confirme se as políticas permitem tráfego de entrada e saída.

• Limitações de ferramentas de depuração e logs

  • Ferramentas ausentes: As imagens de contêiner não incluem dig ou nslookup por padrão. Instale-as manualmente ou use um contêiner de depuração temporário.

  • Logs dispersos: Ative o modo Debug manualmente no CoreDNS (adicionando o plug-in log) para visualizar os logs, distribuídos por várias instâncias de réplica.

  • Dica de depuração: Execute testes rápidos de DNS a partir de um pod temporário:

    kubectl run -it --rm debug --image=nicolaka/netshoot -- dig

    ou use:

    nslookup  <target-domain>

Termos

• Nomes de domínio internos ao cluster: O CoreDNS expõe serviços no cluster como nomes de domínio internos, que terminam com .cluster.local por padrão. O CoreDNS resolve esses nomes de domínio usando seu cache interno e não consulta servidores DNS upstream.

• Nomes de domínio externos ao cluster: Resolução de DNS autoritativa registrada com provedores de DNS de terceiros, Alibaba Cloud DNS (Cloud DNS), PrivateZone e produtos similares. Servidores DNS upstream lidam com a resolução desses nomes de domínio, e o CoreDNS apenas encaminha as solicitações de resolução.

• Pod de aplicação: Um pod de contêiner implantado em um cluster Kubernetes, excluindo contêineres de componentes do sistema Kubernetes.

• Pod de aplicação conectado ao CoreDNS: Um pod de aplicação cujo servidor DNS aponta para o CoreDNS.

• Pod de aplicação conectado ao NodeLocal DNSCache: Após instalar o plug-in NodeLocal DNSCache no cluster, os pods de aplicação injetam automaticamente ou manualmente o DNSConfig. Esses pods priorizam o acesso ao componente de cache local para resolução de nomes de domínio. Se o componente de cache local estiver inacessível, eles retornam ao serviço kube-dns fornecido pelo CoreDNS.

Fluxo de trabalho de solução de problemas do CoreDNS e NodeLocal DNSCache

1. Identifique a causa atual do problema. Para obter detalhes, consulte Erros comuns de cliente.

   • Se a causa do erro for a inexistência do nome de domínio, consulte Solução de problemas Por tipo de nome de domínio envolvido em erros de análise.

   • Se a causa do erro for a impossibilidade de conexão com o servidor DNS, consulte a seção “Por frequência de erros de análise” em Solução de problemas.

2. Se as etapas anteriores não produzirem resultados, siga estas instruções.

   • Verifique se a configuração de DNS do pod de aplicação está conectada ao CoreDNS. Para obter detalhes, consulte Verificar a configuração de DNS dos pods de aplicação.

     • Se o pod não estiver conectado ao CoreDNS, o problema pode ser causado por carga no lado do cliente ou uma tabela Conntrack cheia. Para obter detalhes, consulte Falhas de resolução causadas por carga no lado do cliente e Tabela Conntrack cheia.

     • Se você integrou o CoreDNS, siga as etapas abaixo para solucionar o problema.

       1. Faça o diagnóstico verificando o status do pod do CoreDNS. Para obter detalhes, consulte Verificar o status do pod do CoreDNS e Status anormal do pod do CoreDNS.

       2. Faça o diagnóstico verificando os logs operacionais do CoreDNS. Para obter detalhes, consulte Verificar logs operacionais do CoreDNS e Problemas de resolução de nomes de domínio externos ao cluster.

       3. Determine se o problema pode ser reproduzido consistentemente.

          1. Se o problema for reproduzido consistentemente, consulte Verificar logs de solicitação de consulta DNS do CoreDNS e Verificar a conectividade de rede entre pods de aplicação e CoreDNS.

          2. Se o problema não for reproduzido consistentemente, consulte Capturar pacotes.

   • Se você usar o NodeLocal DNSCache, consulte NodeLocal DNSCache não está funcionando e Problemas de resolução de nomes de domínio do PrivateZone.

Erros comuns de cliente

Solucionar problemas de outros componentes no caminho de DNS

O diagrama a seguir mostra o caminho geral de resolução de DNS. Componentes além do CoreDNS e NodeLocal DNSCache também podem causar falhas na resolução de DNS:

• Resolvedor DNS: Linguagens de programação como Go e bibliotecas como glibc e musl podem conter defeitos em suas implementações de resolução de DNS, levando a falhas ocasionais na resolução.

• Arquivo /etc/resolv.conf: O arquivo de configuração de DNS nos contêineres contém IPs de servidores DNS e domínios de pesquisa DNS. A configuração incorreta deste arquivo causa falhas na resolução de DNS.

• kube-proxy: O kube-proxy usa IPVS/Iptables para encaminhar solicitações. Se o kube-proxy não for atualizado prontamente quando a configuração do CoreDNS mudar, o CoreDNS torna-se inacessível, causando falhas intermitentes na resolução de DNS.

• Servidores DNS Upstream: O CoreDNS resolve apenas nomes de domínio internos ao cluster. Para nomes de domínio que não correspondem ao clusterDomain, o CoreDNS consulta servidores DNS de nível superior, como o DNS interno da VPC. A configuração incorreta dos servidores DNS upstream faz com que os pods falhem ao acessar nomes de domínio fora do cluster.

Verificar a configuração de DNS dos pods de aplicação

• Comando

  # View the YAML configuration of the foo container and confirm that the DNSPolicy field meets expectations.
  kubectl get pod foo -o yaml
  # If DNSPolicy meets expectations, enter the pod container to check the effective DNS configuration.
  # Enter the foo container using bash. If bash is unavailable, use sh instead.
  kubectl exec -it foo bash
  # After entering the container, view the DNS configuration. The nameserver entry shows the DNS server address.
  cat /etc/resolv.conf

• Descrição da configuração de DNS Policy

  Os exemplos a seguir mostram configurações de DNS Policy. Escolha a configuração apropriada com base no seu cenário:

  Exemplo 1: Configuração de DNS Policy para cenários padrão

  apiVersion: v1
  kind: Pod
  metadata:
    name: <pod-name>
    namespace: <pod-namespace>
  spec:
    containers:
    - image: <container-image>
      name: <container-name>
    dnsPolicy: ClusterFirst
    securityContext: {}
    serviceAccount: default
    serviceAccountName: default
    terminationGracePeriodSeconds: 30

  Exemplo 2: Configuração de DNS Policy ao usar NodeLocal DNSCache

  apiVersion: v1
  kind: Pod
  metadata:
    name: <pod-name>
    namespace: <pod-namespace>
  spec:
    containers:
    - image: <container-image>
      name: <container-name>
    dnsPolicy: None
    dnsConfig:
      nameservers:
      - 169.254.20.10
      - 172.21.0.10
      options:
      - name: ndots
        value: "3"
      - name: timeout
        value: "1"
      - name: attempts
        value: "2"
      searches:
      - default.svc.cluster.local
      - svc.cluster.local
      - cluster.local
    securityContext: {}
    serviceAccount: default
    serviceAccountName: default
    terminationGracePeriodSeconds: 30

  Valor de DNSPolicy	Servidor DNS usado
  Default	Aplica-se apenas a cenários onde serviços internos ao cluster não são acessados. Ao criar um pod, ele herda a lista de servidores DNS do arquivo /etc/resolv.conf do nó ECS.
  ClusterFirst	Este é o valor padrão de DNSPolicy. O pod usa o IP do serviço kube-dns fornecido pelo CoreDNS como servidor DNS. Pods com HostNetwork habilitado comportam-se como no modo Default ao usar ClusterFirst.
  ClusterFirstWithHostNet	Pods com HostNetwork habilitado comportam-se como ClusterFirst ao usar ClusterFirstWithHostNet.
  None	Use com DNSConfig para personalizar servidores DNS e parâmetros. Quando a injeção do NodeLocal DNSCache está ativada, o DNSConfig aponta o servidor DNS para o IP do cache local e o IP do serviço kube-dns fornecido pelo CoreDNS.

Verificar o status do pod do CoreDNS

Verificar logs operacionais do CoreDNS

Comando

kubectl -n kube-system logs -f --tail=500 --timestamps coredns-xxxxxxxxx-xxxxx

Verificar logs de solicitação de consulta DNS do CoreDNS

Comando

Os logs de solicitação de consulta DNS aparecem nos logs do contêiner somente após ativar o plug-in Log no CoreDNS. Para obter instruções sobre como ativar o plug-in Log, consulte Configuração não gerenciada do CoreDNS.

O comando é o mesmo usado para verificar os logs operacionais do CoreDNS. Consulte Verificar logs operacionais do CoreDNS.

Verificar a conectividade de rede do pod do CoreDNS

Use o console ou a linha de comando para verificar a conectividade de rede do pod do CoreDNS.

Problemas comuns

Verificar a conectividade de rede entre pods de aplicação e CoreDNS

Use o console ou a linha de comando para verificar a conectividade de rede entre pods de aplicação e CoreDNS.

Problemas comuns

Capturar pacotes

Quando não for possível localizar o problema, capture pacotes para auxiliar no diagnóstico.

1. Faça login no nó onde o pod de aplicação problemático ou o pod do CoreDNS reside.

2. Na instância ECS (fora do contêiner), execute o seguinte comando para capturar todo o tráfego da porta 53 em um arquivo.

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

3. Localize as informações exatas do pacote correspondentes ao horário do erro nos logs da aplicação.

   Nota

   • Em condições normais, a captura de pacotes não impacta as operações comerciais e aumenta apenas ligeiramente a carga da CPU e as gravações em disco.

   • O comando acima rotaciona os pacotes capturados, gravando até 200 arquivos de 20 MB cada (arquivos .pcap).

Descrição do problema

Os pods de aplicação conseguem resolver nomes de domínio internos ao cluster normalmente, mas não conseguem resolver certos nomes de domínio externos ao cluster.

Causa raiz

O servidor upstream retorna respostas anormais de resolução de DNS.

Solução

Verifique os logs de solicitação de consulta DNS do CoreDNS.

Logs de solicitação comuns

# The status code RCODE NOERROR indicates successful resolution.
[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

Códigos de retorno RCODE comuns

Descrição do problema

Pods de aplicação conectados ao CoreDNS não conseguem resolver novos nomes de domínio Headless.

Causa raiz

Versões do CoreDNS anteriores à 1.7.0 saem anormalmente durante oscilações do API Server, fazendo com que os nomes de domínio Headless parem de ser atualizados.

Solução

Atualize o CoreDNS para a versão 1.7.0 ou posterior. Para obter detalhes, consulte [[Atualização de componente] Aviso de atualização do CoreDNS](t1964489.dita#task_1964489).

Descrição do problema

Pods de aplicação conectados ao CoreDNS não conseguem resolver nomes de domínio Headless. Ao usar dig para resolução, a resposta mostra a flag tc, indicando que a mensagem de resposta é muito grande.

Causa raiz

Quando um nome de domínio Headless corresponde a muitas entradas de IP, as solicitações DNS enviadas via UDP podem exceder o limite de tamanho da mensagem DNS UDP, causando falhas na resolução.

Solução

Para evitar falhas na resolução, ajuste sua aplicação cliente para usar TCP nas consultas DNS. O CoreDNS suporta consultas TCP e UDP. Modifique sua aplicação com base nos seguintes cenários:

• Resolvers baseados em glibc

  Se sua aplicação cliente usa um resolver baseado em glibc, adicione a configuração use-vc no dnsConfig para usar TCP nas consultas DNS. Essas configurações mapeiam para a configuração correspondente de options no /etc/resolv.conf. Para obter detalhes sobre a configuração de options, consulte as páginas man do Linux.

  dnsConfig:
    options:
    - name: use-vc

• Lógica de aplicação Golang

  Se você desenvolve com Golang, consulte o código a seguir para usar TCP nas consultas DNS.

  package main
  import (
  	"fmt"
  	"net"
  	"context"
  )
  func main() {
  	resolver := &net.Resolver{
  		PreferGo: true,
  		Dial: func(ctx context.Context, network, address string) (net.Conn, error) {
  			return net.Dial("tcp", address)
  		},
  	}
  	addrs, err := resolver.LookupHost(context.TODO(), "example.com")
  	if err != nil {
  		fmt.Println("Error:", err)
  		return
  	}
  	fmt.Println("Addresses:", addrs)
  }

Descrição do problema

Alguns componentes open-source mais antigos (como versões antigas do etcd, Nacos e Kafka) não funcionam corretamente em ambientes com Kubernetes 1.20 ou posterior e CoreDNS 1.8.4 ou posterior.

Causa raiz

O CoreDNS 1.8.4 e posteriores priorizam a API EndpointSlice para sincronizar informações de IP de serviços do Kubernetes. Alguns componentes open-source usam a anotação service.alpha.kubernetes.io/tolerate-unready-endpoints da API Endpoint para publicar serviços que não estão prontos durante a inicialização. Esta anotação foi descontinuada na API EndpointSlice e substituída por publishNotReadyAddresses. Após atualizar o CoreDNS, serviços não prontos não são publicados, fazendo com que esses componentes falhem na descoberta de serviços.

Solução

Verifique se o YAML ou Helm Chart do componente open-source contém a anotação service.alpha.kubernetes.io/tolerate-unready-endpoints. Se contiver, o componente pode não funcionar corretamente. Atualize o componente open-source ou consulte sua comunidade.

Descrição do problema

Headless services não conseguem resolver nomes de domínio de pods.

Causa raiz

No YAML do pod StatefulSets, o ServiceName deve corresponder ao nome do serviço exposto. Caso contrário, os nomes de domínio dos pods (por exemplo, pod.headless-svc.ns.svc.cluster.local) não poderão ser acessados, e apenas os nomes de domínio dos serviços (por exemplo, headless-svc.ns.svc.cluster.local) estarão acessíveis.

Solução

Modifique o ServiceName no YAML do pod StatefulSets.

Descrição do problema

Pods de aplicação conectados ao CoreDNS em alguns ou todos os nós falham consistentemente na resolução de nomes de domínio.

Causa raiz

A modificação do grupo de segurança (ou ACL de vSwitch) usado por ECS ou contêineres bloqueia a comunicação na porta UDP 53.

Solução

Restaure as configurações do grupo de segurança e da ACL de vSwitch para permitir a comunicação UDP na porta 53.

Descrição do problema

Pods de aplicação conectados ao CoreDNS em alguns ou todos os nós falham consistentemente na resolução de nomes de domínio.

Causa raiz

Problemas na rede do contêiner ou outras causas levam à indisponibilidade persistente da porta UDP 53.

Solução

Use diagnósticos de rede para diagnosticar a conectividade de rede entre pods de aplicação e endereços do CoreDNS.

Descrição do problema

• Pods de aplicação conectados ao CoreDNS em alguns ou todos os nós apresentam aumento na latência de resolução e falhas probabilísticas ou consistentes.

• A verificação do status do pod do CoreDNS mostra que o uso de CPU e memória das réplicas está se aproximando de seus limites de recursos.

Causa raiz

Réplicas insuficientes do CoreDNS ou alto volume de solicitações de negócios causam alta carga no CoreDNS.

Solução

• Considere usar o NodeLocal DNSCache para melhorar o desempenho da resolução de DNS e reduzir a carga do CoreDNS. Para obter detalhes, consulte Usar NodeLocal DNSCache.

• Dimensione horizontalmente as réplicas do CoreDNS adequadamente para que o uso máximo de CPU por pod permaneça abaixo da capacidade ociosa de CPU do nó.

Descrição do problema

• Alguns pods de aplicação conectados ao CoreDNS apresentam aumento na latência de resolução e falhas probabilísticas ou consistentes.

• A verificação do status do pod do CoreDNS mostra uso desigual de CPU entre as réplicas.

• Existem menos de duas réplicas do CoreDNS, ou várias réplicas residem no mesmo nó.

Causa raiz

Agendamento desigual de réplicas do CoreDNS ou configurações de afinidade de Serviço causam desequilíbrio de carga nos pods do CoreDNS.

Solução

• Dimensione horizontalmente e distribua as réplicas do CoreDNS em diferentes nós.

• Quando ocorrer desequilíbrio de carga, desative a propriedade de afinidade do serviço kube-dns. Para obter detalhes, consulte Atualização automática não gerenciada do CoreDNS.

Descrição do problema

• Alguns pods de aplicação conectados ao CoreDNS apresentam aumento na latência de resolução e falhas probabilísticas ou consistentes.

• O status da réplica do CoreDNS não é Running, ou a contagem de RESTARTS continua aumentando.

• Os logs operacionais do CoreDNS mostram anomalias.

Causa raiz

Modelos YAML ou arquivos de configuração do CoreDNS fazem com que o CoreDNS seja executado anormalmente.

Solução

Verifique o status do pod do CoreDNS e os logs operacionais.

Logs anormais comuns e soluções

Descrição do problema

Falhas de resolução ocorrem esporadicamente durante horários de pico de negócios ou subitamente. O monitoramento do ECS mostra taxas anormais de retransmissão da NIC e carga da CPU.

Causa raiz

A instância ECS que hospeda o pod de aplicação conectado ao CoreDNS atinge 100% de carga, causando perda de pacotes UDP.

Solução

Recomendamos usar o NodeLocal DNSCache para melhorar o desempenho da resolução de DNS e reduzir a carga do CoreDNS. Para obter detalhes, consulte Usar NodeLocal DNSCache.

Descrição do problema

• Pods de aplicação conectados ao CoreDNS em alguns ou todos os nós apresentam falhas massivas na resolução de domínios durante horários de pico de negócios, que desaparecem após o pico.

• Ao executar dmesg -H e rolar até o período do problema, são mostradas entradas de log contendo conntrack full.

Causa raiz

A tabela Conntrack do Linux tem entradas limitadas, impedindo novas solicitações UDP ou TCP.

Solução

Aumente o limite da tabela Conntrack. Para obter detalhes, consulte Como aumentar o limite de rastreamento de conexões (Conntrack) do Linux?.

Descrição do problema

• A resolução de nomes de domínio externos ao cluster falha probabilisticamente ou resolve para endereços IP incorretos. A resolução de nomes de domínio internos ao cluster funciona normalmente.

• Durante a criação de contêineres em alta frequência, nomes de domínio de serviços internos ao cluster resolvem para endereços IP incorretos.

Causa raiz

Um defeito de processamento do CoreDNS causa mau funcionamento do AutoPath.

Solução

Descrição do problema

• Pods de aplicação conectados ao CoreDNS falham probabilisticamente na resolução de nomes de domínio.

• A captura de pacotes ou os logs de solicitação de consulta DNS do CoreDNS mostram solicitações A e AAAA ocorrendo simultaneamente com portas de origem idênticas.

Causa raiz

• Solicitações DNS A e AAAA simultâneas acionam um defeito no módulo Conntrack do kernel Linux, causando perda de pacotes UDP.

• Versões mais antigas da libc (<2,33) em arquiteturas ARM têm problemas de concorrência ao iniciar solicitações A e AAAA simultâneas, causando tempos limite de solicitação e retransmissões. Consulte GLIBC#26600.

Solução

• Considere usar o NodeLocal DNSCache para melhorar o desempenho da resolução de DNS e reduzir a carga do CoreDNS. Para obter detalhes, consulte Usar NodeLocal DNSCache.

• Para imagens base que usam libc (como CentOS e Ubuntu), atualize a libc para a versão 2,33 ou posterior para evitar problemas de resolução simultânea de A e AAAA.

• Para imagens base como CentOS e Ubuntu, otimize usando parâmetros como options timeout:2 attempts:3 rotate single-request-reopen.

• Se sua imagem de contêiner for baseada em Alpine, considere mudar para uma imagem base diferente. Para obter mais informações, consulte Alpine.

• Aplicações PHP frequentemente enfrentam problemas de resolução de conexão curta. Se usar PHP Curl, utilize o parâmetro CURL_IPRESOLVE_V4 para enviar solicitações de resolução apenas IPv4. Para obter mais informações, consulte a Referência de funções.

Descrição do problema

No modo IPVS, os pods do CoreDNS podem apresentar falhas probabilísticas na resolução de DNS sob condições específicas, geralmente durando cerca de cinco minutos.

Causa raiz

Sob condições específicas, as solicitações de resolução de DNS são enviadas para pods do CoreDNS em estado anormal, causando falhas na resolução.

Por exemplo, quando um nó que hospeda um pod do CoreDNS é removido, os recursos do nó são liberados imediatamente e o pod para de funcionar. No entanto, o cluster leva cerca de um minuto para detectar a atualização de status do nó e marcá-lo como NotReady. Antes da atualização do status do nó, o pod ainda é considerado saudável e aceita solicitações de resolução de DNS, causando falhas probabilísticas na resolução de DNS no cluster.

Depois que o nó é marcado como NotReady, seus pods do CoreDNS são imediatamente removidos do backend do Serviço CoreDNS e param de aceitar novas conexões. No entanto, se o modo de balanceamento de carga kube-proxy do cluster for IPVS, a política de persistência de sessão UDP do IPVS faz com que algumas solicitações DNS continuem sendo enviadas para o pod até que o período de tempo limite UDP termine, levando a falhas prolongadas na resolução de DNS no cluster.

Solução

• Considere usar o NodeLocal DNSCache, que tolera perda de pacotes IPVS. Para obter detalhes, consulte Usar NodeLocal DNSCache.

• Otimize a duração do tempo limite UDP do IPVS. Para obter detalhes, consulte Configurar tempo limite UDP para clusters IPVS.

Descrição do problema

Nenhum tráfego entra no NodeLocal DNSCache e todas as solicitações ainda vão para o CoreDNS.

Causa raiz

• A injeção de DNSConfig não está configurada, então os pods de aplicação ainda usam o IP do serviço kube-dns do CoreDNS como endereço do servidor DNS.

• Os pods de aplicação usam Alpine como imagem base. O Alpine solicita concorrentemente todos os nameservers, incluindo o cache local e o CoreDNS.

Solução

• Configure a injeção automática de DNSConfig. Para obter detalhes, consulte Usar NodeLocal DNSCache.

• Se sua imagem de contêiner for baseada em Alpine, considere mudar para uma imagem base diferente. Para obter mais informações, consulte Alpine.

Descrição do problema

Para aplicações conectadas ao NodeLocal DNSCache, os pods não conseguem resolver nomes de domínio registrados no PrivateZone, não conseguem resolver nomes de domínio de API de produtos Alibaba Cloud contendo vpc-proxy, ou os resolvem incorretamente.

Causa raiz

O PrivateZone não suporta protocolo TCP e requer acesso UDP.

Solução

Configure prefer_udp no CoreDNS. Para obter detalhes, consulte Configuração não gerenciada do CoreDNS.

Descrição do problema

Após um aumento repentino de tráfego, algumas solicitações DNS falham na resolução.

Causa raiz

Picos repentinos de tráfego causam um aumento nas solicitações DNS, levando a tráfego excessivo de entrada e saída para o CoreDNS. Isso pode limitar o uso da CPU do CoreDNS e causar anomalias na resolução. Verifique este cenário da seguinte forma:

1. Verifique no nó onde os pods do CoreDNS residem.

   Execute o seguinte comando no nó.

   nsenter -t <coredns-pid> -n -- netstat -su

   Verifique se há mensagens de send ou recv buffer error. Se presentes, existe perda de pacotes UDP. Exemplo:

   Udp:
       1090421 packets received
       850 packets to unknown port received
       15662 packet receive errors
       5607627 packets sent
       15662 receive buffer errors
       0 send buffer errors

2. Verifique as métricas de limitação de CPU do pod do CoreDNS.

   Se a CPU do CoreDNS estiver limitada, podem ocorrer falhas intermitentes na resolução de DNS ou aumento na latência de resposta DNS. Combine isso com o primeiro ponto para confirmar a perda de pacotes.

   Nota

   Devido aos ciclos de amostragem e cálculo do uso da CPU (15 segundos), a limitação da CPU pode ocorrer mesmo quando o uso da CPU parece baixo. Para obter mais informações, consulte Ativar otimização de desempenho CPU Burst.

   Na página de monitoramento do Prometheus, escolha Application Monitoring > Cluster Pod Monitoring. Filtre pelo Namespace kube-system, selecione o pod correspondente do CoreDNS e verifique o gráfico de linhas CPU Throttled Percent na seção CPU Resource. Se esta métrica estiver próxima de 0%, não ocorre limitação de CPU.

3. Independentemente de usar o ARMS Prometheus ou uma solução Prometheus autogerenciada, sempre colete métricas do CoreDNS e use o painel do CoreDNS para verificar anomalias e identificar o período do problema. Faça login no console do Container Service for Kubernetes, depois acesse Operations > Prometheus Monitoring e selecione a aba Network Monitoring para encontrar o CoreDNS.

   

Solução

• Configure o NodeSelector para agendar pods do CoreDNS em um pool de nós dedicado, permitindo a implantação em nó dedicado sem limites de recursos de CPU.

• Se os pods do CoreDNS tiverem limites de recursos de CPU configurados, recomendamos também ativar a otimização de desempenho CPU Burst.

• Instale o componente NodeLocal DNSCache e configure os pods para ativar o cache DNS. Para obter detalhes, consulte Usar NodeLocal DNSCache.