Container Service for Kubernetes:DNS best practices

As melhores práticas de DNS abrangem otimizações tanto no lado do cliente quanto no servidor:

• No lado do cliente, otimize as solicitações de resolução de nomes de domínio para reduzir a latência e minimizar falhas de resolução utilizando imagens de contêiner adequadas, sistemas operacionais de nó apropriados e o NodeLocal DNSCache.

  • Optimize domain name resolution requests

  • Understand DNS configurations in containers

  • Avoid intermittent DNS resolution timeouts caused by IPVS defects

  • Use NodeLocal DNSCache

  • Use a suitable CoreDNS version

• No servidor CoreDNS, identifique exceções de DNS e localize rapidamente suas causas raiz monitorando o status operacional do CoreDNS. Também é possível ajustar a implantação do CoreDNS para melhorar a alta disponibilidade e o throughput de consultas por segundo (QPS).

  • Monitor the operational status of CoreDNS

    • Metrics

    • Logs

    • Kubernetes event delivery

  • Ensure CoreDNS high availability

    • Assess CoreDNS component pressure

    • Adjust the number of CoreDNS pods

    • Adjust CoreDNS pod specifications

    • Schedule CoreDNS pods

  • Optimize CoreDNS configurations

    • Disable session affinity for the kube-dns Service

    • Disable the autopath plugin

    • Configure graceful shutdown for CoreDNS

    • Configure the default protocol for the forward plugin and upstream VPC DNS servers

    • Configure the ready plugin for readiness probes

A resolução de DNS é uma das operações de rede mais frequentes em um cluster Kubernetes. Muitas dessas solicitações podem ser otimizadas ou evitadas para reduzir a latência e a carga na infraestrutura de DNS. Otimize as solicitações de resolução de nomes de domínio das seguintes formas:

• (Recomendado) Utilize pools de conexões: quando uma aplicação conteinerizada solicita frequentemente outro service, use um pool de conexões para armazenar em cache as conexões ativas com os services upstream na memória. Isso elimina a sobrecarga de resolução de DNS e handshakes TCP para cada solicitação.

• Adote um modo assíncrono ou de long-polling para obter os endereços IP de um nome de domínio.

• Utilize cache de DNS:

  • (Recomendado) Se não for possível modifique sua aplicação para usar um pool de conexões, considere armazenar em cache os resultados da resolução de DNS no lado da aplicação. Para mais informações, consulte Use NodeLocal DNSCache.

  • Caso não seja viável utilizar o NodeLocal DNSCache, utilize o cache nativo Name Service Cache Daemon (NSCD) nos seus contêineres. Para mais informações, consulte Usar NSCD em clusters Kubernetes.

• Otimize o arquivo resolv.conf: devido aos mecanismos dos parâmetros ndots e search no arquivo resolv.conf, a forma como você escreve os nomes de domínio em um contêiner determina a eficiência da resolução. Para mais detalhes sobre os mecanismos dos parâmetros ndots e search, consulte DNS Policy Configuration and Domain Name Resolution.

• Otimize as configurações de nomes de domínio: quando uma aplicação em um contêiner acessa um nome de domínio, configure-o da seguinte forma para minimizar tentativas de resolução e reduzir a latência.

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

  • Para acessar um Service em um namespace diferente a partir de um pod, utilize <service-name>.<namespace-name>, onde namespace-name é o namespace onde o Service reside.

  • Quando um pod acessa um nome de domínio externo, utilize um Fully Qualified Domain Name (FQDN), que termina com um ponto final (.), para evitar múltiplas buscas de DNS inválidas causadas pela anexação de domínios da lista search. Por exemplo, para acessar www.aliyun.com, utilize seu FQDN www.aliyun.com..

    • Em clusters que executam Kubernetes 1.22 ou posterior, configure o domínio de busca como um único ponto (.) para obter um efeito similar (consulte Issue 125883):

      dnsPolicy: None
      dnsConfig:
        nameservers: ["192.168.0.10"]  ## Replace with the actual ClusterIP of your CoreDNS Service.
        searches:
        - .
        - default.svc.cluster.local  ## Note: Replace default with the actual namespace.
        - svc.cluster.local
        - cluster.local

      Após aplicar a configuração anterior, o arquivo /etc/resolv.conf no pod fica configurado da seguinte maneira:

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

      O primeiro domínio de busca é ".", o que faz o resolvedor tratar o domínio de destino como um FQDN. O resolvedor tenta primeiro resolver o nome de domínio exatamente como foi fornecido, ignorando expansões desnecessárias de domínios de busca.

      Importante

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

      Exemplo completo de workload

      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 with the actual ClusterIP of your CoreDNS Service.
              searches:
              - .
              - default.svc.cluster.local
              - svc.cluster.local
              - cluster.local
            hostname: nginx
            restartPolicy: Always
            schedulerName: default-scheduler
            securityContext: {}
            subdomain: subdomain
            terminationGracePeriodSeconds: 30

Utilize um dos métodos a seguir para mitigar o impacto do defeito no IPVS:

• Utilize o NodeLocal DNSCache. Para mais informações, consulte Use NodeLocal DNSCache.

• Modifique o período de timeout para persistência de sessão UDP do IPVS no kube-proxy. Para mais informações, consulte How do I modify the timeout period for IPVS UDP session persistence in kube-proxy?.

O CoreDNS oferece boa compatibilidade retroativa com versões do Kubernetes. Mantenha o CoreDNS atualizado para a versão estável mais recente. A página Add-ons no console ACK permite instale, atualize e configure o CoreDNS. Verifique o status do componente CoreDNS na página Add-ons. Se houver uma atualização disponível, agende-a para horários de baixa demanda.

• Para mais informações sobre como atualize o CoreDNS, consulte Automatic upgrade for unmanaged CoreDNS.

• Para consultar as notas de versão do CoreDNS, visualize CoreDNS.

Versões do CoreDNS anteriores à v1.7.0 apresentam diversos riscos potenciais, incluindo:

• Quando a conectividade entre o CoreDNS e o servidor de API estiver anormal, por exemplo, devido a reinícios do servidor de API, migrações ou instabilidade de rede, o CoreDNS pode reiniciar por falhar ao gravar logs de erro. Para mais informações, consulte Set klog's logtostderr flag.

• O CoreDNS consome memória extra durante a inicialização. O limite padrão de memória pode desencadear problemas de out-of-memory (OOM) em clusters de grande escala. Em casos graves, isso pode fazer com que os pods do CoreDNS entrem em um loop de reinício e não consigam se recuperar. Para mais informações, consulte CoreDNS uses a lot memory during initialization phase.

• O CoreDNS possui vários problemas que podem afetar a resolução de nomes de domínio de Services headless e de nomes de domínio externos ao cluster. Para mais informações, consulte plugin/kubernetes: handle tombstones in default processor e Data is not synced when CoreDNS reconnects to kubernetes api server after protracted disconnection.

• Se um nó do cluster apresentar anomalias, a política de tolerância padrão em algumas versões anteriores do CoreDNS pode fazer com que os pods do CoreDNS sejam agendados nesse nó anômalo. Esses pods não podem ser evacuados automaticamente, causando falhas na resolução de DNS.

A versão mínima recomendada do CoreDNS varia conforme a versão do Kubernetes do cluster.

Métricas

O CoreDNS expõe métricas de integridade, incluindo resultados de resolução, por meio de uma interface Prometheus padrão. Isso ajuda a detectar anomalias no servidor CoreDNS e até mesmo em servidores DNS upstream.

O Managed Service for Prometheus fornece painéis de monitoramento de métricas e regras de alerta integrados para o CoreDNS. Ative o Prometheus e seus recursos de painel no console ACK. Para mais informações, consulte Monitor the CoreDNS component.

Se você utiliza uma instância Prometheus autogerenciada para monitorar seu cluster Kubernetes, observe as métricas relevantes no Prometheus e configure alertas para indicadores-chave. Para mais informações, consulte a documentação oficial do CoreDNS para Prometheus.

Logs

Em caso de anomalia de DNS, os logs do CoreDNS ajudam a diagnosticar rapidamente a causa raiz. Recomendamos ativar o log de resolução de nomes de domínio do CoreDNS e coletar seus logs com o Log Service. Para mais informações, consulte Analyze and monitor CoreDNS logs.

Entrega de eventos do Kubernetes

No CoreDNS v1.9.3.6-32932850-aliyun e posteriores, ative o plugin k8s_event para entregar logs críticos do CoreDNS como eventos do Kubernetes no Event Center. Para mais informações sobre o plugin k8s_event, consulte k8s_event.

Esse recurso vem ativado por padrão em novas implantações do CoreDNS. Se você atualize de uma versão anterior para o CoreDNS v1.9.3.6-32932850-aliyun ou posterior, modifique manualmente o arquivo de configuração para ativá-lo.

1. Execute o comando a seguir para abrir 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
           }
           // Start of addition (ignore other differences).
           kubeapi
           k8s_event {
             level info error warning // Deliver critical logs with info, error, and warning statuses.
           }
           // End of addition.
           kubernetes cluster.local in-addr.arpa ip6.arpa {
               pods verified
               fallthrough in-addr.arpa ip6.arpa
           }
           // ... (remaining content omitted)
       }

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

Avalie a pressão sobre o componente CoreDNS

Realize um teste de estresse de DNS no cluster para avaliar a pressão sobre o componente. Diversas ferramentas open source, incluindo DNSPerf, podem auxiliar nessa tarefa. Caso não seja possível avaliar com precisão a pressão de DNS no seu cluster, siga estas recomendações.

• Sempre defina o número de pods do CoreDNS como pelo menos 2, com um limite de recursos de no mínimo 1 núcleo e 1 GiB para um único pod.

• O QPS de resolução de nomes de domínio do CoreDNS tem correlação positiva com seu consumo de CPU. Com o NodeLocal DNSCache ativado, cada núcleo de CPU suporta mais de 10.000 QPS. A demanda de QPS para solicitações de nomes de domínio varia significativamente entre diferentes tipos de services. Observe o pico de uso de CPU de cada pod do CoreDNS. Se um pod utilizar mais de um núcleo de CPU durante os horários de pico, recomendamos aumentar o número de réplicas do CoreDNS. Caso não consiga determinar o pico de uso de CPU, utilize conservadoramente uma proporção de 1:8 entre pods e nós do cluster. Ou seja, para cada 8 nós adicionados ao cluster, adicione um pod do CoreDNS.

Ajuste a quantidade de pods do CoreDNS

A quantidade de pods do CoreDNS determina diretamente os recursos de computação disponíveis para ele. Ajuste o número de pods do CoreDNS com base na sua avaliação.

• Ajuste automaticamente com base na política recomendada

  Implante o seguinte dns-autoscaler. Ele ajusta automaticamente o número de pods do CoreDNS em tempo real com base na política recomendada (proporção de 1:8 entre pods e nós do cluster). O número de pods é calculado pela fórmula: replicas = max(ceil(cores × 1/coresPerReplica), ceil(nodes × 1/nodesPerReplica)), e é limitado pelos parâmetros 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

• Ajuste manualmente

  Execute o comando a seguir para ajustar manualmente o número de pods do CoreDNS.

  kubectl scale --replicas={target} deployment/coredns -n kube-system # Replace {target} with the desired number of pods.

• Não utilize dimensionamento automático de workload

  Embora recursos de dimensionamento automático de workload, como Horizontal Pod Autoscaler (HPA) e CronHPA, também possam ajustar automaticamente o número de pods, eles realizam operações de dimensionamento frequentes. Devido às exceções de resolução que ocorrem durante a redução de pods, não utilize o dimensionamento automático de workload para controlar o número de pods do CoreDNS.

Ajuste as especificações dos pods do CoreDNS

Outra forma de ajustar os recursos do CoreDNS é modifique as especificações dos pods. Em um ACK managed Pro cluster, o limite padrão de memória para pods do CoreDNS é 2Gi, sem limite de CPU. Defina o limite de CPU como 4096m, com um mínimo de 1024m. Ajuste a configuração dos pods do CoreDNS no console.

Agende pods do CoreDNS

Recomendamos implantar os pods do CoreDNS em diferentes zonas de disponibilidade e nós do cluster para evitar falhas de nó único ou de zona única. Versões do componente CoreDNS anteriores à v1.8.4.3 possuem uma política padrão de anti-afinidade suave no nível de nó, o que pode fazer com que alguns ou todos os pods sejam implantados no mesmo nó se os recursos forem insuficientes. Se isso ocorrer, exclua os pods para acionar o reagendamento ou atualize o componente para a versão mais recente. As versões do componente CoreDNS anteriores à v1.8 não recebem mais manutenção e devem ser atualizadas o mais breve possível.

Os nós do cluster onde o CoreDNS é executado não devem ter sua CPU ou memória totalmente utilizadas, pois isso afeta o QPS e a latência de resposta da resolução de nomes de domínio. Quando as condições dos nós permitirem, considere utilizar parâmetros personalizados para agendar o CoreDNS em nós dedicados, garantindo um service de resolução de nomes de domínio estável.

As configurações padrão do CoreDNS implantadas com versões anteriores de clusters Kubernetes podem apresentar alguns riscos. Verifique e otimize-as conforme descrito abaixo:

• Disable session affinity for the kube-dns Service

• Disable the autopath plugin

• Configure graceful shutdown for CoreDNS

• Configure the default protocol for the forward plugin and upstream VPC DNS servers

• Configure the ready plugin for readiness probes

Desative a afinidade de sessão para o kube-dns