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 aos 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 Funções e tarefas de usuário comuns do GKE Enterprise.
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 serviços de endereço IP de cluster, 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. O uso do Cloud DNS como provedor de DNS para o GKE oferece os seguintes benefícios em comparação com o DNS hospedado no cluster:
- Redução da sobrecarga: elimina a necessidade de gerenciar servidores DNS hospedados no 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 oferece 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:
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 do 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 do serviço.
Escopos do DNS
O Cloud DNS tem os escopos de DNS a seguir. Um cluster não pode operar em vários 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 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.localde 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 da VPC: os registros DNS podem ser resolvidos em 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 serviços 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 | Apenas 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 |
| Configuração da instalaçã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 os 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 o 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 mais informações 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 o 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 na 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 seu 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$$ |
| Headless | $$2+P+2E$$ |
|
| Pilha dupla | ClusterIP | $$3+P$$ |
| Headless | $$3+P+3E$$ |
|
| Consulte Serviços de pilha única e dupla para mais informações. | ||
Outros registros DNS criados pelo Cloud DNS
O Cloud DNS pode criar outros registros DNS 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 geralmente não são diretamente 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 sem comando: têm uma configuração de DNS distinta. Cada pod recebe um registro DNS próprio, permitindo que os clientes se conectem diretamente aos pods. É por isso que o número da porta não é multiplicado no cálculo do registro do serviço headless.
Exemplo: considere um serviço chamado my-http-server 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$$ |
| Headless | $$2+2+2*3$$ |
|
| Pilha dupla | ClusterIP | $$3+2$$ |
| 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 do 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 você pode encontrar 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 de 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 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 escutar
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 for atualizado para o Cloud DNS, a configuração do NodeLocal DNSCache será alterada. Para verificar a configuração do NodeLocal DNSCache, execute o comando a seguir:
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
bind 169.254.20.10
O fluxo de trabalho a seguir explica as entradas no arquivo resolv.conf antes e depois da migração e da recriação do nó:
Antes da migração
- Os pods têm o arquivo
resolv.confconfigurado para o endereço IPkube-dns(por exemplo,x.x.x.10). - Os pods NodeLocal DNSCache interceptam solicitações de DNS de pods e monitoram o seguinte:
- (DPv1) ambos os endereços (vincular 169.254.20.10 x.x.x.10).
- (DPv2) todos os endereços IP do pod (vincular 0.0.0.0).
- O NodeLocal DNSCache funciona como um cache, e uma carga mínima é colocada nos pods
kube-dns.
Depois da migração
- Depois que o plano de controle é atualizado para usar o Cloud DNS, os pods ainda têm
o arquivo
resolv.confconfigurado para o endereço IPkube-dns(por exemplo,x.x.x.10). Os pods mantêm essa configuraçãoresolv.confaté que o nó deles seja recriado. Quando o Cloud DNS com NodeLocal DNSCache está ativado, os pods precisam ser configurados para usar169.254.20.10como o servidor de nomes, mas essa mudança se aplica apenas a pods em nós criados ou recriados após a migração para o Cloud DNS. - Os pods NodeLocal DNSCache monitoram apenas o endereço do NodeLocal DNSCache (bind 169.254.20.10). As solicitações não vão para os pods do NodeLocal DNSCache.
- Todas as solicitações dos pods são enviadas diretamente para os pods
kube-dns. Essa configuração gera muito tráfego nos pods.
Após a recriação do nó ou o upgrade do pool de nós
- Os pods têm o arquivo
resolv.confconfigurado para usar o endereço IP do NodeLocal DNSCache (169.254.20.10). - Os pods NodeLocal DNSCache monitoram apenas o endereço NodeLocal DNSCache (bind 169.254.20.10) e recebem solicitações de DNS de pods nesse endereço IP.
Quando os pools de nós usam o endereço IP kube-dns no arquivo resolv.conf antes da recriação do pool de nós, um aumento no tráfego de consultas DNS também aumenta o tráfego nos pods kube-dns. Esse aumento pode causar falhas intermitentes de
solicitações de DNS. Para minimizar erros, planeje essa migração durante os períodos de inatividade.