Container Service for Kubernetes:Best practices for DNS in Kubernetes clusters

As práticas recomendadas de DNS abrangem o lado do cliente e o lado do servidor:

• No lado do cliente, reduza a latência de resolução otimizando as requisições de resolução de nomes de domínio. Minimize anomalias de resolução com imagens de container adequadas, sistemas operacionais de nó apropriados e NodeLocal DNSCache.

  • Optimize domain name resolution requests

  • Understand DNS configuration in containers

  • Avoid intermittent DNS resolution timeouts caused by IPVS defects

  • Use NodeLocal DNSCache

  • Use an appropriate CoreDNS version

• No lado do servidor CoreDNS, monitore o status de execução para detectar anomalias de DNS e identificar as causas raiz. Melhore a alta disponibilidade e o throughput de queries por segundo (QPS) do CoreDNS ajustando as configurações de implantação.

  • Monitor CoreDNS runtime status

    • Monitoring metrics

    • Operational logs

    • Kubernetes event delivery

  • Ensure CoreDNS high availability

    • Assess CoreDNS add-on pressure

    • Adjust the number of CoreDNS pods

    • Adjust CoreDNS pod specifications

    • Schedule CoreDNS pods

  • Optimize CoreDNS configuration

    • Disable affinity settings for the kube-dns service

    • Disable the Autopath plugin

    • Configure graceful shutdown for CoreDNS

    • Set the default protocol for the Forward plugin to communicate with upstream VPC DNS servers

    • Configure the Ready readiness probe plugin

A resolução DNS é uma das atividades de rede mais frequentes no Kubernetes. Diversas requisições podem ser otimizadas ou evitadas:

• (Recomendado) Utilize pools de conexão. Quando uma aplicação containerizada acessa outro service com frequência, mantenha as conexões upstream em cache na memória para evitar a resolução DNS e o estabelecimento de conexões TCP a cada acesso.

• Utilize polling assíncrono ou long polling para obter o endereço IP de um nome de domínio DNS.

• Utilize cache de DNS:

  • (Recomendado) Caso sua aplicação não suporte pools de conexão, armazene em cache os resultados da resolução DNS no lado da aplicação ou use NodeLocal DNSCache.

  • Se o NodeLocal DNSCache não estiver disponível, faça cache de consultas DNS dentro do container com o Name Service Cache Daemon (NSCD). Consulte Use NSCD in Kubernetes clusters.

• Otimize o arquivo resolv.conf: os parâmetros ndots e search afetam a eficiência da resolução de acordo com a forma como você escreve os nomes de domínio nas configurações do container. Consulte DNS policy configuration and domain name resolution para mais detalhes sobre ndots e search.

• Otimize a configuração de nomes de domínio para minimizar tentativas de resolução e reduzir o tempo de resolução:

  • Para acessar um Service no mesmo namespace, utilize <service-name>, onde service-name é o nome do Service.

  • Para acessar um Service em outro namespace, utilize <service-name>.<namespace-name>, onde namespace-name é o namespace do Service.

  • Para domínios externos, utilize FQDNs (fully qualified domain names). Adicione um ponto final (.) ao nome para especificar endereços absolutos e evitar concatenações inválidas com o domínio search. Por exemplo, use www.aliyun.com. em vez de www.aliyun.com.

    • Em clusters na versão 1.33 ou posterior, defina o domínio de pesquisa como "." (consulte 125883) para obter um efeito semelhante:

      dnsPolicy: None
      dnsConfig:
        nameservers: ["192.168.0.10"]  ## Replace 192.168.0.10 with the actual CoreDNS service clusterIP
        searches:
        - .
        - default.svc.cluster.local  ## Replace "default" with your namespace name
        - svc.cluster.local
        - cluster.local

      Após aplicar essa configuração, o arquivo /etc/resolv.conf no pod terá o seguinte conteúdo:

      search . default.svc.cluster.local svc.cluster.local cluster.local
      nameserver 192.168.0.10

      O "." como primeiro domínio de pesquisa faz com que todas as requisições de domínio sejam tratadas como FQDNs e resolvidas diretamente, sem tentativas de busca desnecessárias.

      Importante

      Defina dnsPolicy como None para que essa configuração tenha efeito.

      Complete workload example

      apiVersion: apps/v1
      kind: Deployment
      metadata:
        labels:
          app: nginx
        name: nginx
        namespace: default
      spec:
        progressDeadlineSeconds: 600
        replicas: 3
        revisionHistoryLimit: 10
        selector:
          matchLabels:
            app: nginx
        strategy:
          rollingUpdate:
            maxSurge: 25%
            maxUnavailable: 25%
          type: RollingUpdate
        template:
          metadata:
            labels:
              app: nginx
          spec:
            containers:
            - image: registry.openanolis.cn/openanolis/nginx:1.14.1-8.6
              imagePullPolicy: Always
              name: nginx
              resources: {}
              terminationMessagePath: /dev/termination-log
              terminationMessagePolicy: File
            dnsPolicy: None
            dnsConfig:
              nameservers: ["192.168.0.10"]  ## Replace 192.168.0.10 with the actual CoreDNS service clusterIP
              searches:
              - .
              - default.svc.cluster.local
              - svc.cluster.local
              - cluster.local
            hostname: nginx
            restartPolicy: Always
            schedulerName: default-scheduler
            securityContext: {}
            subdomain: subdomain
            terminationGracePeriodSeconds: 30

Reduza o impacto dos defeitos do IPVS utilizando um dos métodos a seguir:

• Use NodeLocal DNSCache.

• Modifique o timeout de persistência de sessão UDP do IPVS no kube-proxy. Consulte How do I modify the IPVS UDP session persistence timeout in kube-proxy?.

O CoreDNS mantém boa compatibilidade com versões anteriores do Kubernetes. Mantenha o CoreDNS em uma versão recente e estável. A página Component Management no console ACK oferece recursos de instalação, atualização e configuração. Monitore o status dos componentes e atualize o CoreDNS durante períodos de baixo tráfego quando uma atualização estiver disponível.

• Consulte Automatic upgrade for non-managed CoreDNS para obter instruções de atualização.

• Consulte as notas de versão em CoreDNS.

Versões do CoreDNS anteriores à v1.7.0 apresentam riscos conhecidos, incluindo, mas não se limitando a:

• Se a conectividade entre o CoreDNS e o API server for interrompida durante uma reinicialização, migração ou instabilidade de rede, o CoreDNS poderá reiniciar por falha ao gravar logs de erro. Consulte Set klog's logtostderr flag.

• O CoreDNS consome memória adicional durante a inicialização. O limite de memória padrão pode disparar problemas de out-of-memory (OOM) em clusters de grande porte, fazendo com que os pods do CoreDNS reiniciem repetidamente sem recuperação. Consulte CoreDNS uses a lot of memory during initialization phase.

• O CoreDNS apresenta problemas conhecidos que afetam domínios de Headless Service e a resolução de domínios externos. Consulte plugin/kubernetes: handle tombstones in default processor e Data is not synced when CoreDNS reconnects to kubernetes api server after protracted disconnection.

• Quando um nó está com problemas, versões desatualizadas do CoreDNS podem implantar pods nesse nó em razão das políticas de tolerância padrão. Esses pods podem não ser removidos automaticamente, ocasionando falhas na resolução de domínios.

A versão mínima recomendada do CoreDNS depende da versão do cluster Kubernetes:

Métricas de monitoramento

O CoreDNS expõe métricas de integridade, como resultados de resolução, por meio de uma interface Prometheus padrão para ajudar a detectar anomalias no CoreDNS ou nos servidores DNS upstream.

Prometheus for ACK inclui métricas de monitoramento e regras de alerta integradas para o CoreDNS. Ative o Prometheus e o Dashboard no Container Service for Kubernetes console. Consulte CoreDNS component monitoring.

Com uma instância Prometheus autogerenciada, observe as métricas relevantes e configure alertas para as críticas. Consulte a documentação oficial do CoreDNS para Prometheus.

Logs operacionais

Utilize os logs do CoreDNS para diagnosticar causas raiz quando ocorrerem anomalias de DNS. Ative os logs de resolução de domínio e a coleta de logs do SLS. Consulte Analyze and monitor CoreDNS logs.

Entrega de eventos do Kubernetes

No CoreDNS v1.9.3.6-32932850-aliyun e versões posteriores, ative o plugin k8s_event para entregar logs críticos do CoreDNS como eventos do Kubernetes ao Event Hub. Consulte a documentação do plugin k8s_event.

Instâncias do CoreDNS recém-implantadas têm esse recurso ativado por padrão. Ao atualizar a partir de uma versão anterior, modifique manualmente o arquivo de configuração para ativá-lo.

1. Abra o arquivo de configuração do CoreDNS:

   kubectl -n kube-system edit configmap/coredns

2. Adicione os plugins kubeAPI e k8s_event.

   apiVersion: v1
   data:
     Corefile: |
       .:53 {
           errors
           health {
               lameduck 15s
           }
           // Begin addition (ignore other differences).
           kubeapi
           k8s_event {
             level info error warning // Deliver critical logs with info, error, or warning levels.
           }
           // End addition.
           kubernetes cluster.local in-addr.arpa ip6.arpa {
               pods verified
               fallthrough in-addr.arpa ip6.arpa
           }
           // Omitted below.
       }

3. Verifique o status e os logs do pod do CoreDNS. Se os logs contiverem a palavra reload, a modificação foi realizada com sucesso.

Avaliar a pressão sobre o componente CoreDNS

Execute testes de carga de DNS para avaliar a pressão sobre o add-on CoreDNS. Ferramentas open-source como DNSPerf podem ajudar. Se não for possível avaliar com precisão a pressão de DNS, siga estas recomendações:

• Implante pelo menos dois pods do CoreDNS, cada um com limites de recursos de no mínimo 1 núcleo de CPU e 1 GB de memória.

• A capacidade de QPS do CoreDNS está correlacionada ao uso de CPU. Com o NodeLocal DNSCache, cada núcleo de CPU suporta mais de 10.000 QPS. O QPS de DNS das cargas de trabalho de negócios varia significativamente. Monitore o pico de uso de CPU por pod do CoreDNS e adicione réplicas quando o uso ultrapassar um núcleo nos períodos de pico. Se o pico de uso for desconhecido, implante um pod do CoreDNS para cada oito nós do cluster como medida conservadora.

Ajustar o número de pods do CoreDNS

O número de pods do CoreDNS determina diretamente os recursos de computação disponíveis. Ajuste conforme sua avaliação.

• Ajuste automático do número de pods com base em políticas recomendadas

  Implante o dns-autoscaler a seguir. Ele ajusta o número de pods do CoreDNS em tempo real na proporção de um pod para cada oito nós do cluster. Contagem de réplicas: replicas = max(ceil(cores × 1/coresPerReplica), ceil(nodes × 1/nodesPerReplica)), restrita pelos limites max e min.

  dns-autoscaler

  apiVersion: apps/v1
  kind: Deployment
  metadata:
    name: dns-autoscaler
    namespace: kube-system
    labels:
      k8s-app: dns-autoscaler
  spec:
    selector:
      matchLabels:
        k8s-app: dns-autoscaler
    template:
      metadata:
        labels:
          k8s-app: dns-autoscaler
      spec:
        serviceAccountName: admin
        containers:
        - name: autoscaler
          image: registry.cn-hangzhou.aliyuncs.com/acs/cluster-proportional-autoscaler:1.8.4
          resources:
            requests:
              cpu: "200m"
              memory: "150Mi"
          command:
          - /cluster-proportional-autoscaler
          - --namespace=kube-system
          - --configmap=dns-autoscaler
          - --nodelabels=type!=virtual-kubelet
          - --target=Deployment/coredns
          - --default-params={"linear":{"coresPerReplica":64,"nodesPerReplica":8,"min":2,"max":100,"preventSinglePointFailure":true}}
          - --logtostderr=true
          - --v=9

• Ajustes manuais

  Ajuste manualmente o número de pods do CoreDNS:

  kubectl scale --replicas={target} deployment/coredns -n kube-system # Replace {target} with the desired pod count

• Não use autoscaling de workload

  Mecanismos de autoscaling de workload como horizontal pod autoscaling (HPA) ou CronHPA provocam operações frequentes de dimensionamento. Devido a anomalias de resolução durante a redução de escala de pods, não use autoscaling de workload para pods do CoreDNS.

Ajustar as especificações dos pods do CoreDNS

Modifique as especificações dos pods para ajustar os recursos do CoreDNS. Em clusters gerenciados ACK Pro, os pods do CoreDNS têm um limite de memória padrão de 2Gi e sem limite de CPU. Defina o limite de CPU como 4096m, com mínimo de 1024m. Ajuste a configuração dos pods do CoreDNS no console.

Agendar pods do CoreDNS

Implante pods do CoreDNS em múltiplas zonas e nós para evitar falhas de nó único ou zona única. Versões do CoreDNS anteriores à v1.8.4.3 usam anti-afinidade fraca de nó por padrão, o que pode concentrar todos os pods no mesmo nó quando os recursos são insuficientes. Exclua os pods para acionar o reagendamento ou atualize para a versão mais recente do componente. Versões do CoreDNS anteriores à v1.8 não recebem mais manutenção. Faça a atualização o quanto antes.

Evite implantar o CoreDNS em nós com utilização total de CPU ou memória, pois isso afeta o QPS de DNS e a latência de resposta. Use parâmetros personalizados para agendar o CoreDNS em nós dedicados e garantir resolução de nomes de domínio estável.

As configurações padrão do CoreDNS em versões mais antigas do Kubernetes podem apresentar riscos. Verifique e otimize-as conforme descrito a seguir:

• Disable affinity settings for the kube-dns service

• Disable the Autopath plugin

• Configure graceful shutdown for CoreDNS

• Set the default protocol for the Forward plugin to communicate with upstream VPC DNS servers

• Configure the Ready readiness probe plugin

Desative as configurações de afinidade do service kube-dns

Desative o plugin Autopath

Algumas versões mais antigas do CoreDNS têm o plugin Autopath ativado, o que pode produzir resultados de resolução incorretos em cenários extremos. Verifique se o plugin está ativado e desative-o editando o arquivo de configuração. Consulte Autopath.

1. Abra o arquivo de configuração do CoreDNS com kubectl -n kube-system edit configmap coredns.

2. Exclua a linha autopath @kubernetes e salve a alteração.

3. Verifique o status e os logs do pod do CoreDNS. Se os logs contiverem a palavra reload, a modificação foi bem-sucedida.

Configure o desligamento gracioso do CoreDNS

O mecanismo lameduck do CoreDNS permite o desligamento gracioso. Quando o CoreDNS é interrompido ou reiniciado, as requisições em andamento são concluídas normalmente, em vez de serem abruptamente interrompidas. O mecanismo lameduck funciona da seguinte forma:

• Quando o CoreDNS é encerrado, ele entra no modo Lameduck.

• No modo lameduck, o CoreDNS para de aceitar novas requisições, mas continua processando as requisições existentes até que sejam concluídas ou o tempo limite do lameduck expire.

Defina o protocolo padrão do plugin Forward para comunicação com os servidores DNS upstream do VPC

O NodeLocal DNSCache se comunica com o CoreDNS via TCP. O CoreDNS utiliza o mesmo protocolo das requisições recebidas ao se comunicar com servidores DNS upstream. Por padrão, as requisições de resolução de domínios externos originadas dos containers de aplicação passam pelo NodeLocal DNSCache e pelo CoreDNS, chegando aos servidores DNS do VPC (100.100.2.136 e 100.100.2.138) via TCP.

# Before modification
forward . /etc/resolv.conf
# After modification
forward . /etc/resolv.conf {
  prefer_udp
}

Configure o plugin de readiness probe Ready

As versões do CoreDNS posteriores à 1.5.0 exigem o plugin ready para ativar as readiness probes.

1. Abra o arquivo de configuração do CoreDNS:

   kubectl -n kube-system edit configmap/coredns

2. Verifique se a linha ready está presente. Se estiver ausente, adicione ready. Pressione Esc, digite :wq! e pressione Enter para salvar e sair.

   apiVersion: v1
   data:
    Corefile: |
     .:53 {
       errors
       health {
         lameduck 15s
       }
       ready # Add this line if missing, ensuring consistent indentation with Kubernetes.
       kubernetes cluster.local in-addr.arpa ip6.arpa {
         pods verified
         fallthrough in-addr.arpa ip6.arpa
       }
       prometheus :9153
       forward . /etc/resolv.conf {
         max_concurrent 1000
               prefer_udp
       }
       cache 30
       loop
       log
       reload
       loadbalance
     }

3. Verifique o status e os logs do pod do CoreDNS. Se os logs contiverem a palavra reload, a modificação foi bem-sucedida.

Configure o plugin multisocket para aprimorar o desempenho de resolução do CoreDNS

O CoreDNS v1.12.1 introduziu o plugin multisocket. Quando ativado, o CoreDNS utiliza múltiplos sockets para escutar na mesma porta, aprimorando o desempenho em cenários de alto uso de CPU. Consulte a documentação da comunidade.

Ative o multisocket no ConfigMap coredns:

.:53 {
        ...
        prometheus :9153
        multisocket [NUM_SOCKETS]
        forward . /etc/resolv.conf
        ...
}

NUM_SOCKETS especifica o número de sockets que escutam na mesma porta.

Alinhe NUM_SOCKETS com o uso estimado de CPU, os limites de recursos de CPU e os recursos disponíveis no cluster. Por exemplo:

• Se o CoreDNS consome 4 núcleos no pico e há 8 núcleos disponíveis, defina NUM_SOCKETS como 2.

• Se o CoreDNS consome 8 núcleos no pico e há 64 núcleos disponíveis, defina NUM_SOCKETS como 8.

Teste diferentes configurações e mensure o QPS e a carga para determinar a configuração ideal.

Se você não especificar NUM_SOCKETS, o CoreDNS utilizará GOMAXPROCS por padrão, que equivale ao limite de CPU do pod do CoreDNS ou à contagem de núcleos de CPU do nó quando nenhum limite estiver definido.