O Google usa tecnologia de IA na tradução de conteúdos para seu idioma de preferência. As traduções com IA podem ter erros.

Sobre o kube-dns para GKE

Standard

Se você estiver executando aplicativos em clusters Standard, o kube-dns será o provedor de DNS padrão que ajuda a ativar a descoberta e a comunicação de serviços. Neste documento, descrevemos como gerenciar o DNS com o kube-dns, incluindo a arquitetura, a configuração e as práticas recomendadas para otimizar a resolução de DNS no ambiente do GKE.

Este documento é destinado a desenvolvedores, administradores e arquitetos responsáveis por gerenciar o DNS no GKE. Para saber mais sobre papéis e tarefas comuns no Google Cloud, consulte Tarefas e papéis de usuário comuns do GKE.

Antes de começar, confira se você conhece os serviços do Kubernetes e os conceitos gerais de DNS.

Entender a arquitetura do `kube-dns`

O kube-dns opera no cluster do GKE para ativar a resolução de DNS entre pods e serviços.

O diagrama a seguir mostra como os pods interagem com o serviço kube-dns:

Figura 1: diagrama mostrando como os pods enviam consultas DNS ao serviço "kube-dns", que é apoiado por pods "kube-dns". Os pods "kube-dns" processam a resolução de DNS interna e encaminham consultas externas para servidores DNS upstream.

Principais componentes

O kube-dns inclui os seguintes componentes principais:

kube-dns Pods: executam o software servidor kube-dns. Várias réplicas desses pods são executadas no namespace kube-system e oferecem alta disponibilidade e redundância.

Serviço kube-dns:a tabela a seguir compara a escalonabilidade e os limites de configuração das versões legada e baseada em CoreDNS do kube-dns:

Recurso	Legado (kube-dns 1.35 e versões anteriores)	kube-dns no CoreDNS (1.36 e posterior)
Reconhecimento de endpoints	Conheça até 1.000 endpoints por serviço. Se um serviço tiver mais de 1.000 pods, o kube-dns não vai reconhecer os endpoints adicionais.	Conhecer todos os endpoints. Esta versão usa EndpointSlices para garantir a correção e melhorar a eficiência de serviços grandes.
Servidores de nomes upstream	Limitado a 3	Suporta até 15
Conexões TCP simultâneas de saída	Limitado a 200	Até 1.500

kube-dns-autoscaler:esse pod ajusta o número de réplicas do kube-dns com base no tamanho do cluster, que inclui o número de nós e núcleos de CPU. Essa abordagem ajuda a garantir que o kube-dns possa lidar com cargas de consultas de DNS variáveis.

Resolução de DNS interno

Quando um pod precisa resolver um nome DNS no domínio do cluster, como myservice.my-namespace.svc.cluster.local, o seguinte processo ocorre:

Configuração de DNS do pod:o kubelet em cada nó configura o arquivo /etc/resolv.conf do pod. Esse arquivo usa o ClusterIP do serviço kube-dns como o servidor de nomes.
Consulta DNS:o pod envia uma consulta DNS ao serviço kube-dns.
Resolução de nome:
- GKE versão 1.36 ou posterior:a implementação baseada em CoreDNS usa EndpointSlices para que o kube-dns esteja ciente de todos os pods em um serviço. Isso melhora a correção e a eficiência para serviços em grande escala.
- GKE versão 1.35 ou anterior:o kube-dns resolve nomes com base na API Cloud Endpoints mais antiga, que é limitada a 1.000 endpoints. Se um serviço tiver mais de 1.000 pods de suporte, kube-dns não vai reconhecer os endpoints adicionais.
Comunicação:o pod usa o endereço IP resolvido para se comunicar com o serviço de destino.

Resolução de DNS externa

Quando um pod precisa resolver um nome DNS externo ou um nome que está fora do domínio do cluster, o kube-dns atua como um resolvedor recursivo. Ele encaminha a consulta para servidores DNS upstream configurados no arquivo ConfigMap. Você também pode configurar resolvedores personalizados para domínios específicos, também conhecidos como domínios stub. Essa configuração direciona o kube-dns para encaminhar solicitações desses domínios a servidores DNS upstream específicos.

Configurar o DNS do pod

No GKE, o agente kubelet em cada nó configura as definições de DNS para os pods executados nesse nó.

Configurar o arquivo `/etc/resolv.conf`

Quando o GKE cria um pod, o agente kubelet modifica o arquivo /etc/resolv.conf do pod. Esse arquivo configura o servidor DNS para resolução de nomes e especifica domínios de pesquisa. Por padrão, o kubelet configura o pod para usar o serviço DNS interno do cluster, kube-dns, como servidor de nomes. Ele também preenche os domínios de pesquisa no arquivo. Esses domínios de pesquisa permitem usar nomes não qualificados em consultas DNS. Por exemplo, se um pod consultar myservice, o Kubernetes primeiro tentará resolver myservice.default.svc.cluster.local, depois myservice.svc.cluster.local e, em seguida, outros domínios da lista search.

O exemplo a seguir mostra uma configuração padrão de /etc/resolv.conf:

nameserver 10.0.0.10
search default.svc.cluster.local svc.cluster.local cluster.local c.my-project-id.internal google.internal
options ndots:5

Esse arquivo tem as seguintes entradas:

nameserver: define o ClusterIP do serviço kube-dns.
search: define os domínios de pesquisa que são anexados a nomes não qualificados durante as buscas DNS.
options ndots:5: define o limite para quando o GKE considera um nome totalmente qualificado. Um nome é considerado totalmente qualificado se tiver cinco ou mais pontos.

Os pods configurados com hostNetwork: true herdam a configuração de DNS do host e não consultam kube-dns diretamente, a menos que usem o ClusterFirstWithHostNet dnsPolicy.

Personalizar `kube-dns`

O kube-dns oferece uma resolução de DNS padrão robusta. Você pode personalizar o comportamento dele para necessidades específicas, como melhorar a eficiência da resolução ou usar resolvedores de DNS preferidos. Para configurar domínios de stub e servidores de nomes upstream, modifique o ConfigMap kube-dns no namespace kube-system.

Modificar o ConfigMap `kube-dns`

Para modificar o ConfigMap kube-dns, faça o seguinte:

Abra o ConfigMap para edição:

kubectl edit configmap kube-dns -n kube-system

Na seção data, adicione os campos stubDomains e upstreamNameservers da seguinte forma:

apiVersion: v1
kind: ConfigMap
metadata:
  labels:
    addonmanager.kubernetes.io/mode: EnsureExists
  name: kube-dns
  namespace: kube-system
data:
  stubDomains: |
    {
      "example.com": [
        "8.8.8.8",
        "8.8.4.4"
      ],
      "internal": [ # Required if your upstream nameservers can't resolve GKE internal domains
        "169.254.169.254" # IP of the metadata server
      ]
    }
  upstreamNameservers: |
    [
      "8.8.8.8", # Google Public DNS
      "8.8.4.4" # Google Public DNS Backup
    ]

Salve o ConfigMap. O kube-dns recarrega automaticamente a configuração.

Domínios stub

Com os domínios de stub, é possível definir resolvedores de DNS personalizados para domínios específicos. Quando um pod consulta um nome nesse domínio stub, o kube-dns encaminha a consulta para o resolvedor especificado em vez de usar o mecanismo de resolução padrão.

Inclua uma seção stubDomains no kube-dns ConfigMap.

Esta seção especifica o domínio e os servidores de nomes upstream correspondentes. Em seguida, o kube-dns encaminha consultas de nomes nesse domínio para os servidores designados. Por exemplo, é possível encaminhar todas as consultas DNS de internal.mycompany.com para 192.168.0.10 e adicionar "internal.mycompany.com": ["192.168.0.10"] a stubDomains.

Quando você define um resolvedor personalizado para um domínio de stub, como example.com, o kube-dns encaminha todas as solicitações de resolução de nome para esse domínio, incluindo subdomínios como *.example.com, para os servidores especificados.

Servidores de nomes upstream

É possível configurar o kube-dns para usar servidores de nomes upstream personalizados para resolver nomes de domínio externos. Essa configuração instrui o kube-dns a encaminhar todas as solicitações DNS, exceto as do domínio interno do cluster (*.cluster.local), para os servidores upstream designados. Domínios internos, como metadata.internal e *.google.internal, podem não ser resolvidos pelos seus servidores upstream personalizados. Se você ativar a Federação de Identidade da Carga de Trabalho para GKE ou tiver cargas de trabalho que dependem desses domínios, adicione um domínio de stub para internal no ConfigMap. Use 169.254.169.254, o endereço IP do servidor de metadados, como o resolvedor para esse domínio de stub.

Gerenciar uma implantação personalizada do `kube-dns`

Em um cluster padrão, kube-dns é executado como uma implantação. Uma implantação kube-dns personalizada significa que você, como administrador do cluster, pode controlar a implantação e personalizá-la de acordo com suas necessidades, em vez de usar a implantação padrão fornecida pelo GKE.

Motivos para uma implantação personalizada

Considere uma implantação personalizada do kube-dns pelos seguintes motivos:

Alocação de recursos:ajuste os recursos de CPU e memória para pods kube-dns e otimize a performance em clusters com alto tráfego de DNS.
Versão da imagem:use uma versão específica da imagem kube-dns ou mude para um provedor de DNS alternativo, como o CoreDNS.
Configuração avançada:personalize níveis de geração de registros, políticas de segurança e comportamento de cache de DNS.

Escalonamento automático para implantações personalizadas

O kube-dns-autoscaler integrado funciona com a implantação padrão do kube-dns. Se você criar uma implantação personalizada do kube-dns, o escalonador automático integrado não vai gerenciá-la. Portanto, é necessário configurar um escalonador automático separado que seja especificamente configurado para monitorar e ajustar a contagem de réplicas da implantação personalizada. Essa abordagem envolve a criação e a implantação da sua própria configuração de escalonador automático no cluster.

Ao gerenciar uma implantação personalizada, você é responsável por todos os componentes dela, como manter a imagem do escalonador automático atualizada. O uso de componentes desatualizados pode levar à degradação da performance ou falhas de DNS.

Para instruções detalhadas sobre como configurar e gerenciar sua própria implantação do kube-dns, consulte Como configurar uma implantação personalizada do kube-dns.

Resolver problemas

Para informações sobre a solução de problemas de kube-dns, consulte as seguintes páginas:

Para conselhos sobre kube-dns no GKE, consulte Resolver problemas de kube-dns no GKE.
Para orientações gerais sobre como diagnosticar problemas de DNS do Kubernetes, consulte Como depurar a resolução de DNS.

Otimizar a resolução de DNS

Nesta seção, descrevemos problemas comuns e práticas recomendadas para gerenciar o DNS no GKE.

Limite de domínios de pesquisa `dnsConfig` de um pod

O Kubernetes limita o número de domínios de pesquisa DNS a 32. Se você tentar definir mais de 32 domínios de pesquisa no dnsConfig de um pod, o kube-apiserver não criará o pod, com um erro semelhante ao seguinte:

The Pod "dns-example" is invalid: spec.dnsConfig.searches: Invalid value: []string{"ns1.svc.cluster-domain.example", "my.dns.search.suffix1", "ns2.svc.cluster-domain.example", "my.dns.search.suffix2", "ns3.svc.cluster-domain.example", "my.dns.search.suffix3", "ns4.svc.cluster-domain.example", "my.dns.search.suffix4", "ns5.svc.cluster-domain.example", "my.dns.search.suffix5", "ns6.svc.cluster-domain.example", "my.dns.search.suffix6", "ns7.svc.cluster-domain.example", "my.dns.search.suffix7", "ns8.svc.cluster-domain.example", "my.dns.search.suffix8", "ns9.svc.cluster-domain.example", "my.dns.search.suffix9", "ns10.svc.cluster-domain.example", "my.dns.search.suffix10", "ns11.svc.cluster-domain.example", "my.dns.search.suffix11", "ns12.svc.cluster-domain.example", "my.dns.search.suffix12", "ns13.svc.cluster-domain.example", "my.dns.search.suffix13", "ns14.svc.cluster-domain.example", "my.dns.search.suffix14", "ns15.svc.cluster-domain.example", "my.dns.search.suffix15", "ns16.svc.cluster-domain.example", "my.dns.search.suffix16", "my.dns.search.suffix17"}: must not have more than 32 search paths.

O kube-apiserver retorna essa mensagem de erro em resposta a uma tentativa de criação de pod. Para resolver esse problema, remova os caminhos de pesquisa extras da configuração.

Limite de `nameservers` upstream para `kube-dns`

As versões legadas do kube-dns (versão 1.35 e anteriores) limitam o número de upstreamNameservers a três. Se você definir mais de três, o Cloud Logging vai mostrar um erro semelhante a este:

Invalid configuration: upstreamNameserver cannot have more than three entries (value was &TypeMeta{Kind:,APIVersion:,}), ignoring update

Nesse cenário, o kube-dns ignora a configuração upstreamNameservers e continua usando a configuração válida anterior. Para resolver esse problema, remova o upstreamNameservers extra do kube-dns ConfigMap.

Aumentar `kube-dns`

Em clusters Standard, é possível usar um valor menor para nodesPerReplica para que mais pods kube-dns sejam criados quando os nós do cluster escalonar verticalmente. Recomendamos definir um valor explícito para o campo max para garantir que a máquina virtual (VM) do plano de controle do GKE não seja sobrecarregada devido ao grande número de pods kube-dns que estão monitorando a API Kubernetes.

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

É possível modificar o número de réplicas de kube-dns editando o kube-dns-autoscaler ConfigMap.

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

O resultado será o seguinte:

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

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

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

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}'

Essa 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 ultrapassar 120 nós, o número de réplicas de kube-dns não ultrapassará 15, que é o valor do campo max.

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

A saída do kube-dns-autoscaler ConfigMap com o campo min configurado é semelhante a esta:

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

Melhorar os tempos de busca DNS

Vários fatores podem causar alta latência com buscas DNS ou falhas de resolução de DNS com o provedor kube-dns padrão. Os aplicativos podem apresentar esses problemas como erros getaddrinfo EAI_AGAIN, que indicam uma falha temporária na resolução de nomes. As causas incluem:

Buscas DNS frequentes na sua carga de trabalho.
Alta densidade de pods por nó.
Executar kube-dns em VMs spot ou VMs preemptivas, o que pode levar a exclusões inesperadas de nós.
Limites de conexão:as versões legadas do kube-dns (GKE versão 1.35 e anteriores) são limitadas a 200 conexões TCP simultâneas. kube-dns no CoreDNS (GKE versão 1.36 e mais recente) remove esses limites fixos para conexões de entrada e oferece uma capacidade significativamente maior para conexões de saída.

Para melhorar os tempos de busca DNS, faça o seguinte:

Evite executar componentes críticos do sistema, como kube-dns em VMs spot ou VMs preemptivas. Crie pelo menos um pool de nós com VMs padrão e sem VMs spot ou VMs preemptivas. Use taints e tolerâncias para garantir que as cargas de trabalho críticas sejam programadas nesses nós confiáveis.
Ative o NodeLocal DNSCache. O NodeLocal DNSCache armazena em cache as respostas de DNS diretamente em cada nó, o que reduz a latência e a carga no serviço kube-dns. Se você ativar o NodeLocal DNSCache e usar políticas de rede com regras de negação padrão, adicione uma política para permitir que cargas de trabalho enviem consultas DNS aos pods node-local-dns.
Escalone verticalmente kube-dns.
Verifique se o aplicativo usa funções baseadas em dns.resolve* em vez de dns.lookup, porque dns.lookup é síncrono.
Use nomes de domínio totalmente qualificados (FQDNs), por exemplo, https://google.com./ em vez de https://google.com/.

Falhas de resolução de DNS podem ocorrer durante upgrades cluster do GKE devido a upgrades simultâneos de componentes do plano de controle, incluindo kube-dns. Essas falhas geralmente afetam uma pequena porcentagem de nós. Teste completamente os upgrades de cluster em um ambiente que não seja de produção antes de aplicá-los aos clusters de produção.

Garantir a capacidade de descoberta de serviços

O kube-dns só cria registros DNS para serviços que têm endpoints. Se um serviço não tiver endpoints, o kube-dns não vai criar registros DNS para ele.

Gerenciar discrepâncias de TTL do DNS

Se o kube-dns receber uma resposta DNS de um resolvedor de DNS upstream com um TTL grande ou infinito, ele vai manter esse valor de TTL. Esse comportamento pode criar uma discrepância entre a entrada em cache e o endereço IP real.

O GKE resolve esse problema em versões específicas do plano de controle, como 1.21.14-gke.9100 e posteriores ou 1.22.15-gke.2100 e posteriores. Essas versões definem um valor máximo de TTL como 30 segundos para qualquer resposta DNS que tenha um TTL maior. Esse comportamento é semelhante ao NodeLocal DNSCache.

Ver métricas de `kube-dns`

É possível recuperar métricas sobre consultas DNS diretamente dos pods kube-dns. A forma de recuperar essas métricas depende da sua versão do GKE.

GKE versão 1.36 e mais recente

Se o cluster executar a versão 1.36 ou mais recente do GKE (kube-dns no CoreDNS), será possível monitorar o desempenho do DNS usando painéis predefinidos no Cloud Monitoring ou recuperar métricas manualmente dos pods.

Ver métricas no console do Google Cloud

No console Google Cloud , acesse a página Painéis.
Selecione o painel Observabilidade de DNS do GKE - visualização do cluster.

Também é possível consultar essas métricas diretamente no console do Google Cloud . Para isso, acesse Monitoring > Metrics Explorer e pesquise os nomes específicos das métricas.

Recuperar métricas manualmente

Para recuperar métricas do pod manualmente, faça o seguinte:

Encontre os pods kube-dns.

kubectl get pods -n kube-system --selector=k8s-app=kube-dns

Encaminhe a porta 9153 para um dos pods.
```
kubectl port-forward pod/POD_NAME -n kube-system 9153:9153
```
Substitua POD_NAME pelo nome de um dos pods kube-dns da saída anterior.
Acesse as métricas.
```
curl http://127.0.0.1:9153/metrics
```

GKE versão 1.35 e anteriores

Esta versão do kube-dns usa pods de vários contêineres. Para recuperar métricas, faça o seguinte:

Encontre os pods kube-dns no namespace kube-system.

kubectl get pods -n kube-system --selector=k8s-app=kube-dns

Encaminhe as portas para as portas 10055 (para o contêiner kube-dns) e 10054 (para o contêiner dnsmasq):
```
#For the kube-dns container
kubectl port-forward pod/POD_NAME -n kube-system 10055:10055
#For the dnsmasq container
kubectl port-forward pod/POD_NAME -n kube-system 10054:10054
```
Substitua POD_NAME pelo nome de um dos pods kube-dns da saída anterior. Execute esses comandos de encaminhamento de porta em sessões de terminal separadas.

Acesse as métricas.

#Metrics from the kube-dns container
curl http://127.0.0.1:10055/metrics

#Metrics from the dnsmasq container
curl http://127.0.0.1:10054/metrics

A seguir

Leia uma visão geral do DNS do cluster no GKE.
Leia DNS para serviços e pods para conferir uma visão geral de como o DNS é usado nos clusters do Kubernetes.
Saiba como configurar o NodeLocal DNSCache.
Saiba como configurar uma implantação personalizada do kube-dns.