Container Service for Kubernetes:FAQ sobre DNS

Por que não consigo executar exec em um Pod do CoreDNS?

A imagem de contêiner do CoreDNS usa scratch como base, que não possui shell. O comando kubectl -n kube-system exec -it {coredns-pod-name} bash falha porque a imagem não contém shell.

Para inspecionar o ambiente de rede de um Pod do CoreDNS, use nsenter. Consulte Verificar a conectividade de rede de um Pod do CoreDNS para obter instruções. Para visualizar os logs do CoreDNS, ative o recurso de análise e monitoramento de logs. Consulte Analisar e monitorar logs do CoreDNS.

Por que o CoreDNS usa uma API obsoleta?

Durante a verificação prévia de atualização do cluster, um cliente com o user agent coredns acessa a API obsoleta discovery.k8s.io/v1beta1 no endpoint /apis/discovery.k8s.io/v1beta1.

Isso ocorre por um dos dois motivos:

• Versão desatualizada do CoreDNS: A versão instalada não oferece suporte a discovery.k8s.io/v1 e recorre a v1beta1.

• Seleção de API antiga: O CoreDNS iniciou em uma versão anterior do Kubernetes (por exemplo, v1.20) e fixou o uso de v1beta1 na inicialização. Após a atualização do cluster tornar essa API obsoleta, o CoreDNS continuou a usá-la.

Em ambos os casos, atualize o CoreDNS primeiro. Se não houver atualização disponível, reinicie-o para forçar uma nova seleção de API.

Para atualizar ou reiniciar o CoreDNS:

1. Faça login no console do ACK e clique em Clusters no painel de navegação à esquerda.

2. Clique no nome do cluster. No painel de navegação à esquerda, clique em Add-ons.

3. Na página Add-ons, atualize o componente CoreDNS. Se a página indicar que a atualização não é possível, prossiga para a etapa 4. Para mais informações, consulte Gerenciar componentes.

4. Reinicie o CoreDNS:

   kubectl -n kube-system rollout restart deployment coredns

   Importante

   Erros de resolução de DNS podem ocorrer ocasionalmente durante a reinicialização. Consulte Mitigar timeouts intermitentes de DNS causados por defeitos no IPVS para reduzir o impacto.

5. Verifique se os Pods do CoreDNS estão em execução:

   kubectl -n kube-system get pod -l k8s-app=kube-dns

   A saída esperada mostra Pods recém-criados no estado Running:

   NAME                       READY   STATUS    RESTARTS   AGE
   coredns-xxxxxxxxxx-xxxxx   1/1     Running   0          30s
   coredns-xxxxxxxxxx-yyyyy   1/1     Running   0          28s

   Quando ambos os Pods estiverem no estado Running, ignore os registros de chamadas de API obsoletas na página de verificação prévia e prossiga com a atualização do cluster.

Erro de log do CoreDNS: dns: buffer size too small

O CoreDNS define o tamanho padrão do buffer UDP (bufsize) como 1232 bytes. Quando uma resposta DNS excede esse limite, a resolução falha e o erro dns: buffer size too small aparece nos logs. Isso geralmente afeta consultas DNS que retornam respostas grandes. Para mais contexto, consulte esta issue no GitHub.

Atualize o CoreDNS para a versão v1.7.1 ou posterior, que resolve esse problema automaticamente. Para versões anteriores à v1.7.1, defina manualmente o parâmetro bufsize no ConfigMap do CoreDNS:

kubectl edit cm -n kube-system coredns

Adicione bufsize com um valor no intervalo \[512, 4096\] (inclusivo):

. {
    bufsize 1220
    log
}

Para mais informações, consulte a documentação do plugin bufsize do CoreDNS.

Por que as solicitações retornam NXDOMAIN e NOERROR de forma inconsistente após a criação de um Service?

O CoreDNS executa como múltiplas réplicas de Pods. Logo após a criação de um novo Service, um Pod pode ainda não ter obtido as informações mais recentes do Service no servidor de API, enquanto outro já as possui. Solicitações roteadas para o Pod dessincronizado retornam NXDOMAIN; já as solicitações roteadas para o Pod atualizado retornam NOERROR. A inconsistência se resolve automaticamente assim que todos os Pods do CoreDNS sincronizam com o servidor de API. Nenhuma ação manual é necessária.

Resolução de DNS em nós Windows

Os Pods em nós Windows apresentam vários comportamentos de DNS diferentes do Linux:

• **Não há suporte para ClusterFirstWithHostNet.** O Windows não oferece suporte a essa política de DNS para Pods.

• **Todos os nomes contendo um ponto (.) são tratados como FQDNs.** Ao contrário do Linux, que percorre uma lista de sufixos de busca, o Windows não anexa sufixos de busca DNS para nomes com ponto.

• Apenas um sufixo DNS é usado por Pod. O sufixo deriva do namespace do Pod. Por exemplo, um Pod no namespace default recebe o sufixo default.svc.cluster.local. Isso significa que kubernetes.default.svc.cluster.local e kubernetes resolvem corretamente, mas nomes parcialmente qualificados, como kubernetes.default ou kubernetes.default.svc, não resolvem.

• **Use Resolve-DnsName para consultas DNS.** O Windows oferece suporte a múltiplos resolvedores DNS com pequenas diferenças comportamentais. O cmdlet do powershell Resolve-DnsName fornece os resultados mais consistentes.

Para mais informações, consulte DNS para Services e Pods.