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 Cloud DNS para GKE

Standard

Este documento ajuda você a decidir se o Cloud DNS para GKE é a solução de DNS certa para seu cluster. É possível usar o Cloud DNS para processar a resolução de DNS de pod e serviço como uma alternativa a provedores de DNS hospedados em cluster, como kube-dns.

Em clusters do Autopilot, o Cloud DNS já é o provedor de DNS padrão. Para clusters padrão, é possível mudar de kube-dns para o Cloud DNS.

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

Este documento pressupõe que você esteja familiarizado com os seguintes conceitos:

Como funciona o Cloud DNS para GKE

Quando você usa o Cloud DNS como provedor de DNS para o GKE, ele fornece resolução de DNS de pod e serviço sem exigir um provedor de DNS hospedado no cluster. Os registros DNS para pods e Serviços são provisionados automaticamente no Cloud DNS para endereço IP de cluster, serviços headless e de nome externo.

O Cloud DNS é compatível com a especificação DNS completa do Kubernetes e fornece resolução para registros A, AAAA, SRV e PTR para serviços em um cluster do GKE. Os registros PTR são implementados usando regras de política de resposta. Usar o Cloud DNS como provedor de DNS para o GKE oferece os seguintes benefícios em relação ao DNS hospedado em cluster:

Sobrecarga reduzida: elimina a necessidade de gerenciar servidores DNS hospedados em cluster. O Cloud DNS não requer escalonamento, monitoramento ou gerenciamento manual de instâncias de DNS, porque é um serviço totalmente gerenciado.
Alta escalonabilidade e desempenho: resolve consultas localmente para cada nó do GKE, oferecendo resolução de DNS de baixa latência e altamente escalonável. Para ter um desempenho ideal, principalmente em clusters de grande escala, considere ativar o NodeLocal DNSCache, que fornece uma camada adicional de armazenamento em cache no nó.
Integração com o Google Cloud Observability: permite o monitoramento e a geração de registros de DNS. Para mais informações, consulte Como ativar e desativar a geração de registros para zonas gerenciadas particulares.

Arquitetura

Quando o Cloud DNS é o provedor de DNS para o GKE, um controlador é executado como um pod gerenciado pelo GKE. Esse pod é executado nos nós do plano de controle do seu cluster e sincroniza os registros DNS do cluster em uma zona de DNS particular gerenciada.

O diagrama a seguir mostra como o plano de controle e o plano de dados do Cloud DNS resolvem nomes de cluster:

Um pod solicita o endereço IP de um serviço usando o Cloud DNS. — Como resolver nomes de cluster usando o Cloud DNS

No diagrama, o back-end do Serviço seleciona os pods de back-end em execução. O clouddns-controller cria um registro DNS para o back-end do Serviço.

O front-end do pod envia uma solicitação DNS para resolver o endereço IP do serviço chamado "backend" ao servidor de metadados local do Compute Engine em 169.254.169.254. O servidor de metadados é executado localmente no nó, enviando ausências no cache para o Cloud DNS.

O Cloud DNS resolve o nome do serviço para diferentes endereços IP com base no tipo de serviço do Kubernetes. Para Serviços ClusterIP, o Cloud DNS resolve o nome do Serviço para o endereço IP virtual dele. Para Serviços headless, ele resolve o nome do Serviço para a lista de endereços IP do endpoint.

Depois que o pod de front-end resolve o endereço IP, ele pode enviar tráfego para o back-end do serviço e quaisquer pods atrás dele.

Escopos do DNS

O Cloud DNS tem os escopos de DNS a seguir. Um cluster não pode operar em ambos os modos simultaneamente.

Escopo do cluster do GKE: os registros DNS só podem ser resolvidos no cluster, que é o mesmo comportamento do kube-dns. Apenas os nós em execução no cluster do GKE podem resolver nomes de objetos Serviço. Por padrão, os clusters têm nomes de DNS que terminam em *.cluster.local. Esses nomes de DNS são visíveis apenas no cluster e não se sobrepõem nem entram em conflito com os nomes de DNS *.cluster.local de outros clusters do GKE no mesmo projeto. Esse é o modo padrão.
- Escopo aditivo da VPC do Cloud DNS: o escopo aditivo da VPC do Cloud DNS é um recurso opcional que estende o escopo do cluster do GKE para tornar serviços headless resolvíveis a partir de outros recursos na VPC, como VMs do Compute Engine ou clientes locais conectados usando o Cloud VPN ou o Cloud Interconnect. Esse modo é um modo adicional que é ativado com o escopo do cluster. É possível ativar ou desativar esse modo no cluster sem afetar o tempo de atividade do DNS ou os recursos do escopo do cluster.
Escopo de VPC: os registros DNS podem ser resolvidos dentro de toda a VPC. As VMs do Compute Engine e os clientes locais podem se conectar usando o Cloud Interconnect ou o Cloud VPN e resolver diretamente os nomes dos objetos Serviço do GKE. É necessário definir um domínio personalizado exclusivo para cada cluster, o que significa que todos os registros DNS de serviço e pod são exclusivos na VPC. Esse modo reduz o atrito de comunicação entre os recursos do GKE e os que não são do GKE.

Esta tabela mostra as diferenças entre os escopos do DNS:

Recurso	Escopo do cluster do GKE	Escopo aditivo da VPC do Cloud DNS	Escopo da VPC
Escopo da visibilidade de DNS	Somente no cluster do GKE	Somente cluster, com serviços headless que podem ser resolvidos na rede VPC	Toda a rede VPC
Resolução de serviço headless	Resolvível no cluster	Resolvível no cluster usando o domínio "cluster.local" e na VPC usando o sufixo do cluster	Resolvível no cluster e na VPC usando o sufixo do cluster
Requisito de domínio exclusivo	Não. Usa o domínio padrão "*.cluster.local"	Sim, você precisa definir um domínio personalizado exclusivo	Sim, você precisa definir um domínio personalizado exclusivo
Instalação e configuração	Padrão, sem etapas extras	Opcional após a criação do cluster Pode ser ativado ou desativado a qualquer momento	Precisa ser configurado durante a criação do cluster

Recursos do Cloud DNS

Quando você usa o Cloud DNS como provedor de DNS para seu cluster do GKE, o controlador do Cloud DNS cria recursos no Cloud DNS para seu projeto. Os recursos criados pelo GKE dependem do escopo do Cloud DNS.

Escopo	Zona de pesquisa de encaminhamento	Zona de pesquisa inversa
Escopo do cluster	1 zona particular por cluster por zona do Compute Engine (na região)	1 zona de política de resposta por cluster a cada zona do Compute Engine (na região)
Escopo aditivo da VPC do Cloud DNS	1 zona particular por cluster por zona do Compute Engine (na região) por cluster (zona global) 1 zona particular com escopo da VPC por cluster (zona global)	1 zona de política de resposta por cluster por zona do Compute Engine (na região) por cluster (zona global) 1 zona de política de resposta com escopo da VPC por cluster (zona global)
Escopo da VPC	1 zona particular por cluster (zona global)	1 zona de política de resposta por cluster (zona global)

A convenção de nomenclatura usada para esses recursos do Cloud DNS é a seguinte:

Escopo	Zona de pesquisa de encaminhamento	Zona de pesquisa inversa
Escopo do cluster	`gke-CLUSTER_NAME-CLUSTER_HASH-dns`	`gke-CLUSTER_NAME-CLUSTER_HASH-rp`
Escopo aditivo da VPC do Cloud DNS	`gke-CLUSTER_NAME-CLUSTER_HASH-dns` para zonas com escopo do cluster `gke-CLUSTER_NAME-CLUSTER_HASH-dns-vpc` para zonas com escopo da VPC	`gke-CLUSTER_NAME-CLUSTER_HASH-rp` para zonas com escopo do cluster `gke-NETWORK_NAME_HASH-rp` para zonas com escopo da VPC
Escopo da VPC	`gke-CLUSTER_NAME-CLUSTER_HASH-dns`	`gke-NETWORK_NAME_HASH-rp`

Além das zonas mencionadas na tabela anterior, o controlador do Cloud DNS cria as seguintes zonas no projeto, dependendo da sua configuração:

Configuração de DNS personalizada	Tipo de zona	Convenção de nomenclatura de zona
Domínio stub	Encaminhamento (zona global)	`gke-CLUSTER_NAME-CLUSTER_HASH-DOMAIN_NAME_HASH`
Servidores de nomes upstream personalizados	Encaminhamento (zona global)	`gke-CLUSTER_NAME-CLUSTER_HASH-upstream`

Para saber mais sobre como criar domínios de stub personalizados ou servidores de nomes upstream personalizados, consulte Como adicionar resolvedores personalizados para domínios de stub.

Zonas gerenciadas e zonas de encaminhamento

Para clusters que usam o escopo do cluster para veicular tráfego DNS interno, o controlador do Cloud DNS cria uma zona de DNS gerenciada em cada zona do Compute Engine da região a que o cluster pertence.

Por exemplo, se você implantar um cluster na zona us-central1-c, o controlador do Cloud DNS vai criar uma zona gerenciada em us-central1-a, us-central1-b, us-central1-c e us-central1-f.

Para cada DNS stubDomain, o controlador do Cloud DNS cria uma zona de encaminhamento.

O Cloud DNS processa cada DNS upstream usando uma zona gerenciada com o nome DNS ..

Cotas

O Cloud DNS usa cotas para limitar o número de recursos que o GKE pode criar para entradas DNS. As cotas e limites do Cloud DNS podem ser diferentes das limitações do kube-dns para seu projeto.

As cotas padrão a seguir são aplicadas a cada zona gerenciada no projeto ao usar o Cloud DNS para GKE:

Recurso DNS do Kubernetes	Recurso correspondente do Cloud DNS	Cota
Número de registros DNS	Máximo de bytes por zona gerenciada	2.000.000 (máximo de 50 MB para uma zona gerenciada)
Número de pods por serviço headless (IPv4 ou IPv6)	Número de registros por conjunto de registros de recursos	GKE 1.24 a 1.25: 1.000 (IPv4 ou IPv6) GKE 1.26 e posterior: 3.500 para IPv4; 2.000 para IPv6
Número de clusters do GKE em um projeto	Número de políticas de resposta por projeto	100
Número de registros PTR por cluster	Número de regras por política de resposta	100.000

Limites de recurso

Os recursos do Kubernetes criados por cluster contribuem para os limites de recursos do Cloud DNS, conforme descrito na tabela a seguir:

Limite	Contribuição do limite
Conjuntos de registros de recursos por zona gerenciada	Número de serviços mais número de endpoints de serviço headless com nomes do host válidos, por cluster.
Registros por conjunto de registros de recursos	Número de endpoints por serviço headless. Não afeta outros tipos de serviço.
Número de regras por política de resposta	Para o escopo do cluster, o número de serviços mais o número de endpoints de serviço headless com nomes do host válidos por cluster. Para o escopo da VPC, o número de serviços mais o número de endpoints headless com nomes do host de todos os clusters na VPC.

Para saber mais sobre como os registros DNS são criados para o Kubernetes, consulte Descoberta de serviço baseada em DNS do Kubernetes (em inglês).

Mais de um cluster por projeto de serviço

A partir das versões 1.22.3-gke.700 e 1.21.6-gke.1500 do GKE, é possível criar clusters em vários projetos de serviço que fazem referência a uma VPC no mesmo projeto host.

Suporte a domínios de stub personalizados e servidores de nomes upstream

O Cloud DNS para GKE é compatível com domínios de stub personalizados e servidores de nomes upstream configurados usando kube-dns ConfigMap. Esse suporte está disponível apenas para clusters do GKE Standard.

O Cloud DNS converte valores stubDomains e upstreamNameservers em zonas de encaminhamento do Cloud DNS.

Extensões de especificação

Para melhorar a descoberta de serviços e a compatibilidade com vários clientes e sistemas, use adições além da especificação geral de DNS do Kubernetes.

Portas nomeadas

Nesta seção, explicamos como as portas nomeadas afetam os registros DNS criados pelo Cloud DNS para o cluster do Kubernetes. O Kubernetes define um conjunto mínimo de registros DNS obrigatórios, mas o Cloud DNS pode criar outros registros para a própria operação e para oferecer suporte a vários recursos do Kubernetes. As tabelas a seguir ilustram o número mínimo de conjuntos de registros que você pode esperar, em que "E" representa o número de endpoints e "P" representa o número de portas. O Cloud DNS pode criar outros registros.

Tipo de pilha de IP	Tipo de serviço	Conjuntos de registros
Pilha única	ClusterIP	$$2+P$$
Pilha única	Headless	$$2+P+2E$$
Pilha dupla	ClusterIP	$$3+P$$
Pilha dupla	Headless	$$3+P+3E$$
Consulte Serviços de pilha única e dupla para mais informações sobre esses serviços.

Registros DNS adicionais criados pelo Cloud DNS

O Cloud DNS pode criar registros DNS extras além do número mínimo de conjuntos de registros. Esses registros têm várias finalidades, incluindo:

Registros SRV: para descoberta de serviços, o Cloud DNS geralmente cria registros SRV. Esses registros fornecem informações sobre a porta e o protocolo do serviço.
Registros AAAA (para pilha dupla): em configurações de pilha dupla que usam IPv4 e IPv6, o Cloud DNS cria registros A (para IPv4) e AAAA (para IPv6) para cada endpoint.
Registros internos: o Cloud DNS pode criar registros internos para gerenciamento e otimização próprios. Esses registros normalmente não são relevantes para os usuários.
Serviços LoadBalancer: para serviços do tipo LoadBalancer, o Cloud DNS cria registros associados ao endereço IP do balanceador de carga externo.
Serviços headless: têm uma configuração de DNS distinta. Cada pod recebe o próprio registro DNS, o que permite que os clientes se conectem diretamente aos pods. Essa abordagem é o motivo pelo qual o número da porta não é multiplicado no cálculo do registro de serviço headless.

Exemplo: considere um serviço chamado my-http-server que está no namespace backend. Esse serviço expõe duas portas, 80 e 8080, para uma implantação com três pods. Portanto, E = 3 e P = 2.

Tipo de pilha de IP	Tipo de serviço	Conjuntos de registros
Pilha única	ClusterIP	$$2+2$$
Pilha única	Headless	$$2+2+2*3$$
Pilha dupla	ClusterIP	$$3+2$$
Pilha dupla	Headless	$$3+2+3*3$$

Além desses registros mínimos, o Cloud DNS pode criar registros SRV e, no caso de redes de pilha dupla, registros AAAA. Se my-http-server for um serviço do tipo LoadBalancer, outros registros para o IP do balanceador de carga serão criados. Observação: o Cloud DNS adiciona registros DNS complementares conforme necessário. Os registros específicos criados dependem de fatores como o tipo e a configuração do serviço.

Problemas conhecidos

Nesta seção, descrevemos problemas comuns que podem ocorrer ao usar o Cloud DNS com o GKE, além de possíveis soluções alternativas.

O Terraform tenta recriar o cluster do Autopilot devido a uma mudança no `dns_config`

Se você usar terraform-provider-google ou terraform-provider-google-beta, poderá ter um problema em que o Terraform tenta recriar um cluster do Autopilot. Esse erro ocorre porque os clusters recém-criados do Autopilot que executam as versões 1.25.9-gke.400, 1.26.4-gke.500 ou 1.27.1-gke.400 ou posterior usam o Cloud DNS como um provedor de DNS em vez de kube-dns.

Esse problema foi resolvido na versão 4.80.0 do provedor do Terraform do Google Cloud.

Se não for possível atualizar a versão de terraform-provider-google ou terraform-provider-google-beta, adicione a configuração lifecycle.ignore_changes ao recurso para garantir que google_container_cluster ignore as mudanças em dns_config:

  lifecycle {
    ignore_changes = [
      dns_config,
    ]
  }

A resolução de DNS falha após a migração do `kube-dns` para o Cloud DNS com o NodeLocal DNSCache ativado

Nesta seção, descrevemos um problema conhecido para clusters do GKE que estão no Cloud DNS e que ativaram o NodeLocal DNSCache no escopo do cluster.

Quando o NodeLocal DNSCache está ativado no cluster e você migra de kube-dns para o Cloud DNS, o cluster pode apresentar erros de resolução intermitentes.

Se você usar kube-dns com o NodeLocal DNSCache ativado no cluster, o NodeLocal DNSCache será configurado para detectar os dois endereços: o endereço do NodeLocal DNSCache e o endereço de kube-dns.

Para verificar o status do NodeLocal DNSCache, execute o seguinte comando:

kubectl get cm -n kube-system node-local-dns -o json | jq .data.Corefile -r | grep bind

O resultado será o seguinte:

    bind 169.254.20.10 x.x.x.10
    bind 169.254.20.10 x.x.x.10

Se o GKE Dataplane V2 estiver ativado no cluster e ele usar kube-dns, o NodeLocal DNSCache será executado em uma rede isolada e será configurado para monitorar todos os endereços IP do pod (0.0.0.0). O resultado será o seguinte:

    bind 0.0.0.0
    bind 0.0.0.0

Depois que o cluster é atualizado para o Cloud DNS, a configuração do NodeLocal DNSCache é alterada. Para verificar a configuração do NodeLocal DNSCache, execute o seguinte comando:

kubectl get cm -n kube-system node-local-dns -o json | jq .data.Corefile -r | grep bind