Container Compute Service:Políticas de resolução DNS e políticas de cache

Pipelines de resolução DNS

Os diagramas a seguir ilustram o pipeline de resolução DNS para dois cenários.

Aplicações não containerizadas em instâncias do Elastic Compute Service (ecs)

Por exemplo, uma aplicação chamada App executa em uma instância ecs, conforme mostra a figura abaixo.

Aplicações containerizadas em pods com a política DNS ClusterFirst

Neste cenário, uma aplicação chamada App roda dentro de um pod em um cluster Kubernetes, como apresentado na imagem seguinte.

Políticas de resolução

Lado do cliente

As interfaces fornecidas pela glibc processam as consultas DNS originadas dos pods. O arquivo /etc/resolv.conf controla a forma como a glibc realiza a resolução DNS. A tabela a seguir lista os parâmetros configuráveis e seus valores padrão em diferentes ambientes.

A tabela abaixo detalha o comportamento de roteamento de consultas para cada política DNS.

① O parâmetro attempts aplica-se apenas quando o servidor retorna SERVFAIL, NOTIMP ou REFUSED, ou quando retorna NOERROR sem resultados de resolução. Para mais detalhes, consulte Introdução ao parâmetro attempts.

② Os servidores DNS da VPC atuam como nameservers padrão para instâncias ecs na virtual private cloud (VPC). Seus endereços IP são 100.100.2.136 e 100.100.2.138. Eles resolvem nomes de domínio autoritativos e domínios adicionados ao Alibaba Cloud DNS PrivateZone.

③ O IP do cluster CoreDNS corresponde ao endereço IP do Serviço kube-dns no namespace kube-system. O Serviço kube-dns encaminha consultas DNS ao CoreDNS para nomes de domínio internos, domínios autoritativos e domínios registrados no Alibaba Cloud DNS PrivateZone.

Ambientes não padronizados

A configuração DNS do lado do cliente descrita acima vale para ambientes que utilizam glibc. Os ambientes listados a seguir apresentam comportamentos distintos.

Alpine Linux (musl libc)

O Alpine Linux substitui a glibc pela musl libc, o que introduz diversas diferenças na resolução DNS:

• O /etc/resolv.conf não suporta single-request nem single-request-reopen.

• Versões até o Alpine 3.3 não aceitam o parâmetro search para domínios de busca, causando falhas na descoberta de serviços.

• A musl libc envia consultas paralelamente a todos os nameservers definidos no /etc/resolv.conf, impedindo que o NodeLocal DNSCache otimize a resolução DNS.

• Consultas A e AAAA são enviadas simultaneamente pela musl libc através do mesmo socket. Em versões mais antigas do kernel, isso resulta em perda de pacotes na porta conntrack.

Para mais informações, acesse Diferenças funcionais da musl libc em relação à glibc.

Golang e Node.js

Aplicações desenvolvidas em Golang ou Node.js podem utilizar um resolvedor DNS nativo em vez da glibc. Isso pode gerar um comportamento de resolução DNS significativamente diferente. Verifique a implementação de resolução DNS da sua aplicação caso observe comportamentos inesperados.

Servidores DNS internos no cluster

Por padrão, o CoreDNS herda o arquivo /etc/resolv.conf da instância ecs que o hospeda. Em seguida, o CoreDNS utiliza o plugin nativo forward para encaminhar consultas DNS upstream.

A tabela a seguir apresenta os parâmetros do plugin forward e seus valores padrão. Para a referência completa, consulte forward.

Políticas de cache

Lado do cliente

A política de cache DNS no lado do cliente varia conforme a configuração do container e da aplicação. Configure o cache do lado do cliente de acordo com suas necessidades.

Servidores DNS internos no cluster

O CoreDNS emprega o plugin cache para armazenar resultados de resolução DNS. A tabela abaixo relaciona os parâmetros do plugin de cache e seus valores padrão no ACS.

Otimizar a resolução DNS

Modifique o arquivo YAML do pod ou o ConfigMap do CoreDNS para ajustar o comportamento da resolução DNS.

Usar servidores DNS da VPC diretamente

Defina dnsPolicy: Default para ignorar o CoreDNS e resolver nomes de domínio diretamente pelos servidores DNS da VPC. O pod herdará as configurações DNS da instância ecs que o hospeda.

apiVersion: v1
kind: Pod
metadata:
  name: example
  namespace: default
spec:
  containers:
  - image: registry.cn-hangzhou.aliyuncs.com/example-ns/example:v1
    name: example
  # Set the dnsPolicy parameter to Default.
  dnsPolicy: Default

# The /etc/resolv.conf file in the pod.
# cat /etc/resolv.conf
nameserver 100.100.2.136
nameserver 100.100.2.138

Melhorar a tolerância a falhas para pods Default

Ao definir dnsPolicy: Default, o arquivo /etc/resolv.conf do pod omite as opções rotate, single-request-reopen, timeout:2 e attempts:3, presentes por padrão nas instâncias ecs. Sem essas opções, aumenta a probabilidade de falha na resolução DNS durante instabilidades de rede.

Adicione essas opções via dnsConfig para igualar o comportamento da instância ecs:

apiVersion: v1
kind: Pod
metadata:
  name: example
  namespace: default
spec:
  containers:
  - image: registry.cn-hangzhou.aliyuncs.com/example-ns/example:v1
    name: example
  # Set the dnsPolicy parameter to Default.
  dnsPolicy: Default
  # Add the following options.
  dnsConfig:
    options:
    - name: timeout
      value: "2"
    - name: attempts
      value: "3"
    - name: rotate
    - name: single-request-reopen

# After adding the options, redeploy the pod to apply the changes.
# cat /etc/resolv.conf
nameserver 100.100.2.136
nameserver 100.100.2.138
options rotate single-request-reopen timeout:2 attempts:3