Container Service for Kubernetes:Políticas de resolução e cache de DNS

Aplicações baseadas em host (não containerizadas)

Aplicações executadas diretamente em instâncias do Elastic Compute Service (ECS) usam o arquivo /etc/resolv.conf do host, que aponta para os servidores DNS da Virtual Private Cloud (VPC).

Pods containerizados padrão (dnsPolicy: ClusterFirst)

Por padrão, os pods usam a política ClusterFirst. Todas as consultas de DNS são enviadas ao serviço CoreDNS no cluster.

Pods com NodeLocal DNSCache ativado

Quando o NodeLocal DNSCache está ativo, os pods enviam consultas a um agente de cache local no mesmo nó. Isso oferece dois benefícios:

• Latência reduzida: As consultas de DNS são resolvidas localmente, evitando o salto de rede até o CoreDNS.

• Proteção da tabela conntrack: As consultas usam o agente local sem criar entradas conntrack. Isso reduz condições de corrida e impede que o DNS via UDP esgote a tabela conntrack.

Lado do cliente

O resolvedor glibc interpreta estes parâmetros do arquivo /etc/resolv.conf. Configuração representativa para um pod com política ClusterFirst:

nameserver 10.x.x.x          # CoreDNS ClusterIP
search default.svc.cluster.local svc.cluster.local cluster.local
options ndots:5 timeout:5 attempts:2

Valores padrão nos diferentes ambientes de implantação:

^①^ O parâmetro attempts aplica-se apenas quando o servidor retorna SERVFAIL, NOTIMP ou REFUSED, ou quando retorna NOERROR sem resultado. Consulte Detalhes da solicitação do parâmetro attempts.

^②^ Os servidores DNS da VPC (100.100.2.136 e 100.100.2.138) são os servidores DNS padrão nas instâncias ECS. Eles resolvem nomes de domínio do PrivateZone e autoritativos.

^③^ O ClusterIP do CoreDNS é o IP do serviço kube-dns no namespace kube-system. Ele resolve nomes de serviços internos e encaminha consultas do PrivateZone e autoritativas.

^④^ O NodeLocal DNSCache escuta no endereço 169.254.20.10 em cada nó quando o add-on é implantado.

Consulte resolv.conf para obter opções adicionais do arquivo /etc/resolv.conf .

Resolvedores não padrão

Os padrões glibc acima aplicam-se apenas quando o container usa glibc. Duas exceções comuns:

• Alpine (musl libc): A biblioteca musl nativa do Alpine substitui o glibc e tem comportamento diferente (consulte musl libc):

  • Não respeita as opções single-request e single-request-reopen no arquivo /etc/resolv.conf.

  • O Alpine 3.3 e versões anteriores não suportam o parâmetro search nem domínios de busca, o que interrompe a descoberta de serviços.

  • Solicitações simultâneas para vários servidores DNS tornam as otimizações do NodeLocal DNSCache ineficazes.

  • Solicitações A e AAAA simultâneas no mesmo socket provocam condições de corrida no conntrack em kernels mais antigos, causando perda intermitente de pacotes.

• Linguagens com resolvedores integrados (Go, Node.js): Esses runtimes frequentemente ignoram o arquivo /etc/resolv.conf e resolvem nomes de forma diferente do resolvedor do sistema.

Servidores DNS no cluster

Por padrão, o CoreDNS lê seu upstream do arquivo /etc/resolv.conf do ECS e encaminha solicitações de DNS com o plugin forward integrado. O NodeLocal DNSCache executa uma instância incorporada do CoreDNS com a mesma configuração de encaminhamento.

Parâmetros do plugin forward (referência completa):

Lado do cliente

O cache no lado do cliente varia conforme a imagem do container e a aplicação.

Servidores DNS no cluster

Parâmetros de cache para CoreDNS e NodeLocal DNSCache no ACK:

Aumentar a tolerância a falhas

Com dnsPolicy: Default, o container herda as configurações dos servidores DNS da VPC do arquivo /etc/resolv.conf do ECS, mas não herda as opções rotate, single-request-reopen, timeout:2 e attempts:3. Sem essas opções, a instabilidade da rede pode causar falhas intermitentes de DNS.

Configuração herdada:

apiVersion: v1
kind: Pod
metadata:
  name: example
  namespace: default
spec:
  containers:
  - image: registry.cn-hangzhou.aliyuncs.com/example-ns/example:v1
    name: example
  # The dnsPolicy value in the Pod YAML is Default.
  dnsPolicy: Default

# The /etc/resolv.conf file in the container at this time.
# cat /etc/resolv.conf
nameserver 100.100.2.136
nameserver 100.100.2.138

Adicione dnsConfig para restaurar as opções de tolerância a falhas ausentes:

apiVersion: v1
kind: Pod
metadata:
  name: example
  namespace: default
spec:
  containers:
  - image: registry.cn-hangzhou.aliyuncs.com/example-ns/example:v1
    name: example
  # The dnsPolicy value in the pod YAML is Default.
  dnsPolicy: Default
  # Add the following fault tolerance configuration.
  dnsConfig:
    options:
    - name: timeout
      value: "2"
    - name: attempts
      value: "3"
    - name: rotate
    - name: single-request-reopen

# After modification, redeploy the pod. The options parameter is added to /etc/resolv.conf in the container.
# cat /etc/resolv.conf
nameserver 100.100.2.136
nameserver 100.100.2.138
options rotate single-request-reopen timeout:2 attempts:3

Alta disponibilidade com serve_stale

A opção serve_stale permite que o CoreDNS retorne entradas de cache expiradas quando os servidores DNS upstream estiverem inacessíveis, evitando falhas de resolução causadas por interrupções transitórias.

A opção serve_stale está ativada por padrão na edição não gerenciada do CoreDNS v1.12.1 e posteriores. Consulte a RFC-8767 .

Formato de configuração

serve_stale [DURATION] [REFRESH_MODE]

• DURATION: Tempo durante o qual as entradas expiradas permanecem disponíveis após a expiração. Padrão: 1h. Entradas expiradas há mais tempo do que esse valor sem uma atualização bem-sucedida deixam de ser servidas.

• REFRESH_MODE: Controla como o CoreDNS lida com entradas expiradas:

  • verify: Verifique primeiro a acessibilidade do upstream; retorna a entrada atualizada se disponível ou recorre à entrada expirada. Gera maior latência em respostas obsoletas, mas evita servir dados desatualizados quando existem dados recentes.

  • immediate: Retorna a entrada expirada imediatamente e atualize a partir do upstream em segundo plano. Mais rápido, mas pode servir dados obsoletos.

Exemplo

Configuração padrão na edição não gerenciada do CoreDNS v1.12.1.2 e posteriores:

cache 30 {
  ...
  serve_stale 30s verify
}

cache 30 {
  ...
  serve_stale 1h immediate
}