Configurar o NodeLocal DNSCache

Autopilot Standard

Este documento descreve como usar o NodeLocal DNSCache para reduzir a latência de busca DNS e melhorar o desempenho do aplicativo no cluster do Google Kubernetes Engine (GKE).

O NodeLocal DNSCache é um complemento do GKE que melhora o desempenho do DNS executando um cache DNS diretamente em cada nó do cluster como um DaemonSet. Quando os pods fazem uma solicitação DNS, ela vai primeiro para o cache local no mesmo nó. O processamento de solicitações localmente reduz significativamente os tempos médios de busca DNS e diminui a carga no provedor de DNS central do cluster, como o kube-dns ou Cloud DNS para GKE. Para uma explicação detalhada da arquitetura de DNS e dos benefícios do NodeLocal DNSCache, consulte Sobre a descoberta de serviços.

Nos clusters do GKE Autopilot, o NodeLocal DNSCache está ativado por padrão e não pode ser desativado. Nos clusters GKE Standard que executam a versão 1.34.1-gke.3720000 e mais recentes, o NodeLocal DNSCache está ativado por padrão, mas pode ser desativado.

Este documento é destinado a usuários do GKE, incluindo desenvolvedores, administradores e arquitetos. Para saber mais sobre papéis comuns e tarefas de exemplo em Google Cloud, consulte Papéis e tarefas de usuário comuns do GKE.

Este documento pressupõe que você esteja familiarizado com o seguinte:

• Serviço do Kubernetes.
• Serviços multicluster.
• Sobre a descoberta de serviços.
• Sobre o Cloud DNS.

Arquitetura

O NodeLocal DNSCache é um complemento do GKE que pode ser executado além do kube-dns.

O GKE implementa o NodeLocal DNSCache como um DaemonSet que executa um cache DNS em cada nó do cluster.

Quando um pod faz uma solicitação DNS, ela vai para o cache DNS em execução no mesmo nó que o pod. Se o cache não conseguir resolver a solicitação DNS, ele encaminhará a solicitação para um dos seguintes locais com base no destino da consulta e no provedor de DNS configurado:

• kube-dns: todas as consultas para o domínio DNS do cluster (cluster.local) são encaminhadas para kube-dns. Os pods node-local-dns usam o kube-dns-upstream serviço para acessar os kube-dns pods.
• Domínios de stub personalizados ou servidores de nomes upstream: as consultas são encaminhadas diretamente dos pods do NodeLocal DNSCache.
• Cloud DNS: todas as demais consultas são encaminhadas para o servidor de metadados local, que é executado no mesmo nó em que a consulta foi originada. O servidor de metadados local acessa o Cloud DNS.

Quando você ativa o NodeLocal DNSCache em um cluster atual, o GKE recria todos os nós do cluster que executam a versão 1.15 e mais recentes do GKE conforme o processo de upgrade do nó.

Depois que o GKE recria os nós, ele adiciona automaticamente o identificador addon.gke.io/node-local-dns-ds-ready=true aos nós. Não adicione esse identificador aos nós do cluster manualmente.

Benefícios do NodeLocal DNSCache

O NodeLocal DNSCache oferece as seguintes vantagens:

• Tempo médio da busca DNS reduzido
• As conexões de pods para o cache local não criam conntrack entradas de tabela. Esse comportamento evita conexões descartadas e rejeitadas causadas por esgotamento da tabela de conexões e condições de corrida.
• É possível usar o NodeLocal DNSCache com Cloud DNS para GKE.
• As consultas DNS para URLs externos (URLs que não se referem a recursos de cluster) são encaminhadas diretamente para o servidor de metadados local e ignoram kube-dns.
• Os caches de DNS local selecionam automaticamente os domínios de stub e os servidores de nomes upstream especificados na seção Como adicionar resolvedores personalizados para domínios de stub.

Requisitos e limitações

• O NodeLocal DNSCache consome recursos de computação em cada nó do cluster.
• O NodeLocal DNSCache não é compatível com os pools de nós do Windows Server.
• O NodeLocal DNSCache requer a versão 1.15 ou posterior do GKE.
• O NodeLocal DNSCache acessa pods kube-dns usando TCP.
• O NodeLocal DNSCache acessa upstreamServers e stubDomains usando TCP e UDP na versão 1.18 ou posterior do GKE. O servidor DNS precisa ser acessível usando TCP e UDP.
• Os registros DNS são armazenados em cache pelos seguintes períodos:
  • O time to live (TTL) do registro ou então 30 segundos, se o TTL tiver mais de 30 segundos.
  • Cinco segundos se a resposta DNS for NXDOMAIN.
• Os pods NodeLocal DNSCache monitoram as portas 53, 9253, 9353 e 8080 dos nós. Se você executar qualquer outro pod hostNetwork ou configurar um hostPorts com essas portas, o NodeLocal DNSCache falhará e ocorrerão erros no DNS. Os pods NodeLocal DNSCache não usam o modo hostNetwork quando usam GKE Dataplane V2 e não usam Cloud DNS para GKE.
• O cache DNS local é executado apenas em pools de nós que executam versões 1.15 e posteriores do GKE. Se você ativar o NodeLocal DNSCache em um cluster com nós executando versões anteriores, os pods desses nós usarão o kube-dns.

Antes de começar

Antes de começar, verifique se você realizou as tarefas a seguir:

• Ativar a API Google Kubernetes Engine.
Ativar a API Google Kubernetes Engine
• Se você quiser usar a Google Cloud CLI para essa tarefa, instale e, em seguida, inicialize a CLI gcloud. Se você instalou a CLI gcloud anteriormente, instale a versão mais recente executando o comando gcloud components update. Talvez as versões anteriores da CLI gcloud não sejam compatíveis com a execução dos comandos neste documento.
  Observação: Para instalações prévias da CLI gcloud, defina a compute/region propriedade. Se você usa principalmente clusters zonais, defina compute/zone. Ao definir um local padrão, é possível evitar erros na CLI gcloud como: One of [--zone, --region] must be supplied: Please specify location. Talvez seja necessário especificar o local em determinados comandos se o local do cluster for diferente do padrão definido.

• Verifique se você tem um cluster do Autopilot ou Standard. Se precisar, crie um cluster do Autopilot. Em clusters do Autopilot, o NodeLocal DNSCache é ativado por padrão e não pode ser substituído.

Ativar NodeLocal DNSCache

Para clusters padrão, o NodeLocal DNSCache é ativado por padrão na versão 1.34.1-gke.3720000 e mais recentes. Se o cluster estiver em uma versão anterior à 1.34.1-gke.3720000, use a Google Cloud CLI para ativar o NodeLocal DNSCache em clusters novos ou atuais. Também é possível usar o Google Cloud console para ativar o NodeLocal DNSCache apenas em novos clusters.

gcloud

Para ativar o NodeLocal DNSCache em um cluster atual, use a flag --update-addons com o argumento NodeLocalDNS=ENABLED:

gcloud container clusters update CLUSTER_NAME \
    --location=COMPUTE_LOCATION \
    --update-addons=NodeLocalDNS=ENABLED

Substitua:

• CLUSTER_NAME: o nome do cluster.
• COMPUTE_LOCATION: a região do Compute Engine para o cluster.

Console

Para ativar o NodeLocal DNSCache em um novo cluster, siga estas etapas:

1. Acesse a página do Google Kubernetes Engine no Google Cloud console do.

   Acessar os clusters do Kubernetes

2. Clique no nome do cluster que você quer modificar.

3. Em Rede, no campo Provedor de DNS, clique em Editar provedor de DNS.

4. Marque a caixa de seleção Ativar NodeLocal DNSCache.

5. Clique em Salvar alterações.

Essa mudança exige a recriação dos nós, o que pode causar interrupção nas cargas de trabalho em execução. Para mais detalhes sobre essa mudança específica, encontre a linha correspondente na tabela de mudanças manuais que recriam os nós usando uma estratégia de upgrade de nós e respeitando as políticas de manutenção. Para saber mais sobre as atualizações de nós, consulte Planejar interrupções de atualização de nós.

Importante: o GKE respeita as políticas de manutenção ao recriar os nós para essa mudança usando a estratégia de upgrade de nós e depende da disponibilidade de recursos. Desativar os upgrades automáticos de nós não impede essa mudança. Para aplicar manualmente as mudanças aos nós, use a CLI gcloud para chamar o gcloud container clusters upgrade comando, transmitindo a --cluster-version flag com a mesma versão do GKE que o pool de nós já está em execução.

Verificar se o NodeLocal DNSCache está ativado

Para verificar se o NodeLocal DNSCache está em execução, liste os pods node-local-dns:

kubectl get pods -n kube-system -o wide | grep node-local-dns

O resultado será assim:

node-local-dns-869mt    1/1   Running   0   6m24s   10.128.0.35   gke-test-pool-69efb6b8-5d7m   <none>   <none>
node-local-dns-htx4w    1/1   Running   0   6m24s   10.128.0.36   gke-test-pool-69efb6b8-wssk   <none>   <none>
node-local-dns-v5njk    1/1   Running   0   6m24s   10.128.0.33   gke-test-pool-69efb6b8-bhz3   <none>   <none>

A saída mostra um pod node-local-dns para cada nó que executa a versão 1.15 ou mais recente do GKE.

Desativar o NodeLocal DNSCache

Para clusters do GKE Autopilot, o NodeLocal DNSCache está ativado por padrão e não pode ser desativado.

Desativar o NodeLocal DNSCache em um novo cluster

É possível desativar o NodeLocal DNSCache ao criar um novo cluster padrão do GKE na versão 1.34.1-gke.3720000 ou mais recente executando o seguinte comando:

gcloud container clusters create CLUSTER_NAME  \
    --location=COMPUTE_LOCATION \
    --addons=NodeLocalDNS=DISABLED

Substitua:

• CLUSTER_NAME: o nome do novo cluster;
• COMPUTE_LOCATION: a região do Compute Engine para o cluster.

Como desativar o NodeLocal DNSCache em um cluster atual

É possível desativar o NodeLocal DNSCache no cluster do GKE atual executando o seguinte comando:

gcloud container clusters update CLUSTER_NAME \
    --location=COMPUTE_LOCATION \
    --update-addons=NodeLocalDNS=DISABLED

Substitua:

• CLUSTER_NAME: o nome do cluster a ser desativado.
• COMPUTE_LOCATION: a região do Compute Engine para o cluster.

Essa mudança exige a recriação dos nós, o que pode causar interrupção nas cargas de trabalho em execução. Para mais detalhes sobre essa mudança específica, encontre a linha correspondente na tabela de mudanças manuais que recriam os nós usando uma estratégia de upgrade de nós e respeitando as políticas de manutenção. Para saber mais sobre as atualizações de nós, consulte Planejar interrupções de atualização de nós.

Importante: o GKE respeita as políticas de manutenção ao recriar os nós para essa mudança usando a estratégia de upgrade de nós e depende da disponibilidade de recursos. Desativar os upgrades automáticos de nós não impede essa mudança. Para aplicar manualmente as mudanças aos nós, use a CLI gcloud para chamar o gcloud container clusters upgrade comando, transmitindo a --cluster-version flag com a mesma versão do GKE que o pool de nós já está em execução.

Solução de problemas do NodeLocal DNSCache

Veja informações gerais sobre como diagnosticar problemas de DNS do Kubernetes em Como depurar a resolução de DNS.

O NodeLocal DNSCache não é ativado imediatamente

Quando você ativa o NodeLocal DNSCache em um cluster atual, o GKE pode não atualizar os nós imediatamente se o cluster tiver uma janela ou exclusão de manutenção configurada. Para mais informações, consulte Atenção para janelas de recriação e manutenção de nós.

Se você preferir não esperar, aplique manualmente as alterações aos nós chamando o comando gcloud container clusters upgrade e transmitindo a sinalização --cluster-version com a mesma versão do GKE que o pool de nós já está em execução. Use a Google Cloud CLI para essa solução alternativa.

NodeLocal DNSCache com o Cloud DNS

Se você usar o NodeLocal DNSCache com o Cloud DNS, o cluster usará o endereço IP 169.254.20.10 do servidor de nomes, conforme mostrado no diagrama a seguir:

Como resultado, o endereço IP do serviço kube-dns pode ser diferente do endereço IP do servidor de nomes usado pelos pods. Essa diferença nos endereços IP é esperado, porque o endereço IP do servidor de nomes 169.254.20.10 é obrigatório para que o Cloud DNS funcione corretamente.

Para verificar os endereços IP, execute os seguintes comandos:

1. Veja o endereço IP do serviço kube-dns:

   kubectl get svc -n kube-system kube-dns -o jsonpath="{.spec.clusterIP}"
   

   A saída é o endereço IP de kube-dns, como 10.0.0.10

2. Abra uma sessão do shell no pod:

   kubectl exec -it POD_NAME -- /bin/bash
   

3. Na sessão do shell do pod, leia o conteúdo do arquivo /etc/resolv.conf:

   cat /etc/resolv.conf
   

   O resultado é 169.254.20.10

Política de rede com NodeLocal DNSCache

Se você usar política de rede com o NodeLocal DNSCache e não estiver usando Cloud DNS ou GKE Dataplane V2, é preciso configurar regras para permitir que suas cargas de trabalho e os node-local-dns pods enviem consultas DNS.

Use uma regra ipBlock no manifesto para permitir a comunicação entre pods e kube-dns.

O manifesto a seguir descreve uma política de rede que usa uma regra ipBlock:

spec:
  egress:
  - ports:
    - port: 53
      protocol: TCP
    - port: 53
      protocol: UDP
    to:
    - ipBlock:
        cidr: KUBE_DNS_SVC_CLUSTER_IP/32
  podSelector: {}
  policyTypes:
    - Egress

Substitua KUBE_DNS_SVC_CLUSTER_IP pelo endereço IP do serviço kube-dns. É possível acessar o endereço IP do serviço kube-dns usando o seguinte comando:

kubectl get svc -n kube-system kube-dns -o jsonpath="{.spec.clusterIP}"

Problemas conhecidos

Esta seção lista problemas conhecidos com o NodeLocal DNSCache.

Tempo limite do DNS em ClusterFirstWithHostNet dnsPolicy ao usar o NodeLocal DNSCache e o GKE Dataplane V2

Em clusters que usam o GKE Dataplane V2 e o NodeLocal DNSCache, os pods com o campo hostNetwork definido como true e o campo dnsPolicy definido como ClusterFirstWithHostNet não podem alcançar back-ends de DNS do cluster. Os registros DNS podem conter entradas semelhantes a estas:

dnslookup: write to 'a.b.c.d': Operation not permitted

;; connection timed out; no servers could be reached

A saída indica que as solicitações DNS não conseguem alcançar os servidores de back-end.

Uma alternativa é definir os campos dnsPolicy e dnsConfig para pods hostNetwork:

spec:
 dnsPolicy: "None"
 dnsConfig:
   nameservers:
     - KUBE_DNS_UPSTREAM
   searches:
     - NAMESPACE.svc.cluster.local
     - svc.cluster.local
     - cluster.local
     - c.PROJECT_ID.internal
     - google.internal
   options:
     - name: ndots
       value: "5"

Substitua:

• NAMESPACE: o namespace do pod hostNetwork.
• PROJECT_ID: o ID do Google Cloud projeto.

• KUBE_DNS_UPSTREAM: o ClusterIP do serviço kube-dns upstream. É possível acessar esse valor usando o seguinte comando:

  kubectl get svc -n kube-system kube-dns-upstream -o jsonpath="{.spec.clusterIP}"
  

As solicitações de DNS do pod agora podem acessar o kube-dns e ignorar o NodeLocal DNSCache.

Erros de tempo limite do NodeLocal DNSCache

Em clusters com o NodeLocal DNSCache ativado, os registros podem conter entradas semelhantes a estas:

[ERROR] plugin/errors: 2 <hostname> A: read tcp <node IP: port>-><kubedns IP>:53: i/o timeout

Observação: se a saída contiver 169.254.169.254:53 i/o timeout, os tempos limite estão vindo do servidor de metadados, e as soluções alternativas a seguir não se aplicam.

A saída inclui o endereço IP do serviço de IP do cluster kube-dns-upstream. Neste exemplo, a resposta a uma solicitação DNS não foi recebida do kube-dns em dois segundos. Esse problema pode ocorrer por um dos seguintes motivos:

• Um problema de conectividade de rede subjacente.
• Aumento significativo nas consultas DNS da carga de trabalho ou do aumento do pool de nós.

Como resultado, os pods kube-dns atuais não podem processar todas as solicitações a tempo. A alternativa é aumentar o número de réplicas kube-dns escalonando okube-dns.

Escalonar o kube-dns

Use um valor menor para o campo nodesPerReplica para garantir que mais pods kube-dns sejam criados à medida que os nós do cluster escalonar verticalmente. É altamente recomendável definir um valor max explícito para garantir que a máquina virtual (VM) do plano de controle do GKE não fique sobrecarregada devido ao grande número de pods kube-dns que assistem à API Kubernetes.

É possível definir o campo max como o número de nós no cluster. Se o cluster tiver mais de 500 nós, defina o campo max como 500.

Observação: definir o campo max como 500 não cria 500 réplicas. Em vez disso, ele ajuda a garantir que as réplicas kube-dns não sejam escalonar verticalmente verticalmente além do valor da configuração max. Na maioria dos casos, defina o campo max como um valor muito menor que 500.

Para clusters padrão, modifique o número de kube-dns réplicas editando o kube-dns-autoscaler ConfigMap. Essa configuração não é compatível com clusters do Autopilot.

kubectl edit configmap kube-dns-autoscaler --namespace=kube-system

O resultado será assim:

linear: '{"coresPerReplica":256, "nodesPerReplica":16,"preventSinglePointFailure":true}'

O número de réplicas kube-dns é calculado usando a seguinte fórmula:

replicas = max(ceil(cores * 1/coresPerReplica), ceil(nodes * 1/nodesPerReplica))

Se você definir os campos min e max no ConfigMap, as réplicas serão limitadas por esses valores. Para escalonar verticalmente, mude o valor do campo nodesPerReplica para um valor menor e inclua um valor para o campo max:

linear: '{"coresPerReplica":256, "nodesPerReplica":8,"max": 15,"preventSinglePointFailure":true}'

A configuração cria um pod kube-dns para cada oito nós no cluster. Um cluster de 24 nós tem três réplicas, e um cluster de 40 nós tem cinco réplicas. Se o cluster crescer além de 120 nós, o número de réplicas kube-dns não vai crescer além de 15, que é o valor max.

Para garantir um nível básico de disponibilidade de DNS no cluster, defina uma contagem mínima de réplicas para o kube-dns.

A saída do ConfigMap kube-dns-autoscaler que tem um campo min definido seria semelhante a esta:

linear: '{"coresPerReplica":256, "nodesPerReplica":8,"max": 15,"min": 5,"preventSinglePointFailure":true}'

A seguir

• Leia uma visão geral de como o GKE fornece DNS gerenciado.
• Leia DNS para serviços e pods para uma visão geral de como o DNS é usado nos clusters do Kubernetes.
• Saiba como usar Cloud DNS para GKE.