Esta página foi traduzida pela API Cloud Translation.

Acerca do Cloud DNS para GKE

Padrão

Este documento ajuda a decidir se o Cloud DNS para GKE é a solução de DNS certa para o seu cluster. Pode usar o Cloud DNS para processar a resolução de DNS de pods e serviços como alternativa a fornecedores de DNS alojados no cluster, como o kube-dns.

Para clusters do Autopilot, o Cloud DNS já é o fornecedor de DNS predefinido. Para clusters padrão, pode mudar de kube-dns para o Cloud DNS.

Este documento destina-se a utilizadores do GKE, incluindo programadores, administradores e arquitetos. Para saber mais sobre as funções comuns e exemplos de tarefas no Google Cloud, consulte o artigo Funções de utilizador e tarefas comuns do GKE Enterprise.

Este documento pressupõe que conhece os seguintes conceitos:

Como funciona o Cloud DNS para GKE

Quando usa o Cloud DNS como fornecedor de DNS para o GKE, o Cloud DNS fornece resolução de DNS de pods e serviços sem precisar de um fornecedor de DNS alojado no cluster. Os registos DNS para pods e serviços são automaticamente aprovisionados no Cloud DNS para o endereço IP do cluster, sem cabeçalho e serviços de nomes externos.

O Cloud DNS suporta a especificação completa de DNS do Kubernetes e fornece resolução para registos A, AAAA, SRV e PTR para serviços num cluster do GKE. Os registos PTR são implementados através de regras de políticas de resposta. A utilização do Cloud DNS como fornecedor de DNS para o GKE oferece as seguintes vantagens em relação ao DNS alojado no cluster:

Sobrecarga reduzida: elimina a necessidade de gerir servidores DNS alojados no cluster. O Cloud DNS não requer dimensionamento, monitorização nem gestão manual de instâncias de DNS, uma vez que é um serviço totalmente gerido.
Elevada escalabilidade e desempenho: resolve as consultas localmente para cada nó do GKE para fornecer uma resolução de DNS de baixa latência e altamente escalável. Para um desempenho ideal, especialmente em clusters de grande escala, considere ativar o NodeLocal DNSCache, que oferece uma camada de cache adicional no nó.
Integração com o Google Cloud Observability: ativa a monitorização e o registo de DNS. Para mais informações, consulte o artigo Ativar e desativar o registo para zonas geridas privadas.

Arquitetura

Quando o Cloud DNS é o fornecedor de DNS para o GKE, um controlador é executado como um pod gerido pelo GKE. Este pod é executado nos nós do plano de controlo do cluster e sincroniza os registos DNS do cluster numa zona DNS privada gerida.

O diagrama seguinte mostra como o plano de controlo e o plano de dados do Cloud DNS resolvem os nomes dos clusters:

Um pod pede o endereço IP de um serviço através do Cloud DNS. — Resolver nomes de clusters com 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 registo DNS para o back-end do serviço.

O frontend do pod envia um pedido DNS para resolver o endereço IP do serviço denominado backend para o servidor de metadados local do Compute Engine em 169.254.169.254. O servidor de metadados é executado localmente no nó, enviando falhas de 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 os ClusterIPServiços, o Cloud DNS resolve o nome do serviço para o respetivo endereço IP virtual; para os Serviços sem cabeça, resolve o nome do serviço para a lista de endereços IP dos pontos finais.

Depois de o front-end do Pod resolver o endereço IP, o Pod pode enviar tráfego para o back-end do serviço e quaisquer Pods atrás do serviço.

kube-dns

Âmbitos de DNS

O Cloud DNS tem os seguintes âmbitos de DNS. Um cluster não pode funcionar em vários modos em simultâneo.

Âmbito do cluster do GKE: os registos de DNS só são resolvidos no cluster, que é o mesmo comportamento que kube-dns. Apenas os nós executados no cluster do GKE podem resolver nomes de serviços. Por predefinição, os clusters têm nomes DNS que terminam em *.cluster.local. Estes nomes DNS são visíveis apenas no cluster e não se sobrepõem nem entram em conflito com os nomes DNS *.cluster.local para outros clusters do GKE no mesmo projeto. Este modo é o modo predefinido.
- Âmbito da VPC aditivo do Cloud DNS: o âmbito da VPC aditivo do Cloud DNS é uma funcionalidade opcional que estende o âmbito do cluster do GKE para tornar os serviços sem cabeça resolvíveis a partir de outros recursos na VPC, como VMs do Compute Engine ou clientes no local que estão ligados através do Cloud VPN ou do Cloud Interconnect. Este modo é um modo adicional que é ativado juntamente com o âmbito do cluster. Pode ativar ou desativar este modo no cluster sem afetar o tempo de atividade do DNS nem as capacidades do âmbito do cluster.
Âmbito da VPC: os registos DNS são resolvidos em toda a VPC. As VMs do Compute Engine e os clientes nas instalações podem estabelecer ligação através do Cloud Interconnect ou da Cloud VPN e podem resolver diretamente os nomes dos serviços do GKE. Tem de definir um domínio personalizado único para cada cluster, o que significa que todos os registos DNS de serviços e pods são únicos na VPC. Este modo reduz o atrito de comunicação entre o GKE e os recursos não pertencentes ao GKE.

A tabela seguinte indica as diferenças entre os âmbitos de DNS:

Funcionalidade	Âmbito do cluster do GKE	Âmbito da VPC aditivo do Cloud DNS	Âmbito da VPC
Âmbito da visibilidade do DNS	Apenas no cluster do GKE	Apenas cluster, com serviços sem interface gráfica resolvidos na rede VPC	Toda a rede da VPC
Resolução do serviço sem interface	Resolvível no cluster	Resolvível no cluster através do domínio `cluster.local` e na VPC através do sufixo do cluster	Resolvível no cluster e na VPC através do uso do sufixo do cluster
Requisito de domínio único	Não; usa o domínio `*.cluster.local` predefinido	Sim, tem de definir um domínio personalizado único	Sim, tem de definir um domínio personalizado único
Configuração da configuração	Predefinição, sem passos adicionais	Opcional na criação do cluster Pode ser ativado ou desativado em qualquer altura	Tem de ser configurado durante a criação do cluster

Recursos do Cloud DNS

Quando usa o Cloud DNS como fornecedor de DNS para o cluster do GKE, o controlador do Cloud DNS cria recursos no Cloud DNS para o seu projeto. Os recursos que o GKE cria dependem do âmbito do Cloud DNS.

Âmbito	Zona forward lookup	Zona de procura inversa
Âmbito do cluster	1 zona privada por cluster por zona do Compute Engine (na região)	1 zona de política de resposta por cluster por zona do Compute Engine (na região)
Âmbito da VPC aditivo do Cloud DNS	1 zona privada por cluster por zona do Compute Engine (na região) por cluster (zona global) 1 zona privada com âmbito 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 âmbito da VPC por cluster (zona global)
Âmbito da VPC	1 zona privada por cluster (zona global)	1 zona de política de resposta por cluster (zona global)

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

Âmbito	Zona forward lookup	Zona de procura inversa
Âmbito do cluster	`gke-CLUSTER_NAME-CLUSTER_HASH-dns`	`gke-CLUSTER_NAME-CLUSTER_HASH-rp`
Âmbito da VPC aditivo do Cloud DNS	`gke-CLUSTER_NAME-CLUSTER_HASH-dns` para zonas ao nível do cluster `gke-CLUSTER_NAME-CLUSTER_HASH-dns-vpc` para zonas ao nível da VPC	`gke-CLUSTER_NAME-CLUSTER_HASH-rp` para zonas com âmbito de cluster `gke-NETWORK_NAME_HASH-rp` para zonas com âmbito de VPC
Âmbito 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 seu projeto, consoante a sua configuração:

Configuração de DNS personalizada	Tipo de zona	Convenção de nomenclatura de zonas
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 mais informações sobre como criar domínios de stub personalizados ou servidores de nomes upstream personalizados, consulte o artigo Adicionar resolvedores personalizados para domínios de stub.

Zonas geridas e zonas de encaminhamento

Para clusters que usam o âmbito do cluster para publicar tráfego DNS interno, o controlador do Cloud DNS cria uma zona DNS gerida em cada zona do Compute Engine da região à qual o cluster pertence.

Por exemplo, se implementar um cluster na zona us-central1-c, o controlador do Cloud DNS cria uma zona gerida 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 a montante através de uma zona gerida com o nome DNS..

Quotas

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

As seguintes quotas predefinidas são aplicadas a cada zona gerida no seu projeto quando usa o Cloud DNS para o GKE:

Recurso de DNS do Kubernetes	Recurso do Cloud DNS correspondente	Quota
Número de registos de DNS	Máximo de bytes por zona gerida	2 000 000 (máximo de 50 MB para uma zona gerida)
Número de pods por serviço sem interface (IPv4 ou IPv6)	Número de registos por conjunto de registos de recursos	GKE 1.24 a 1.25: 1000 (IPv4 ou IPv6) GKE 1.26 e posterior: 3500 para IPv4; 2000 para IPv6
Número de clusters do GKE num projeto	Número de políticas de resposta por projeto	100
Número de registos PTR por cluster	Número de regras por política de resposta	100 000

Limites de recursos

Os recursos do Kubernetes que cria por cluster contribuem para os limites de recursos do Cloud DNS, conforme descrito na tabela seguinte:

Limite	Contribuição para o limite
Conjuntos de registos de recursos por zona gerida	Número de serviços mais número de pontos finais de serviço sem cabeçalho com nomes de anfitrião válidos, por cluster.
Registos por conjunto de registos de recursos	Número de pontos finais por serviço sem interface. Não afeta outros tipos de serviços.
Número de regras por política de resposta	Para o âmbito do cluster, número de serviços mais número de pontos finais de serviço sem cabeça com nomes de anfitrião válidos por cluster. Para o âmbito da VPC, número de serviços mais número de pontos finais sem cabeçalho com nomes de anfitriões de todos os clusters na VPC.

Para mais informações sobre como os registos de DNS são criados para o Kubernetes, consulte o artigo Descoberta de serviços baseada em DNS do Kubernetes.

Mais do que 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, pode criar clusters em vários projetos de serviço que referenciam uma VPC no mesmo projeto anfitrião.

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

O Cloud DNS para GKE suporta domínios stub personalizados e servidores de nomes a montante que são configurados através do ConfigMap kube-dns. Este suporte está disponível apenas para clusters padrão do GKE.

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

Extensões de especificações

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

Portas com nome

Esta secção explica como as portas com nome afetam os registos de DNS criados pelo Cloud DNS para o seu cluster do Kubernetes. O Kubernetes define um conjunto mínimo de registos DNS obrigatórios, mas o Cloud DNS pode criar registos adicionais para o seu próprio funcionamento e para suportar várias funcionalidades do Kubernetes. As tabelas seguintes ilustram o número mínimo de conjuntos de registos que pode esperar, onde "E" representa o número de pontos finais e "P" representa o número de portas. O Cloud DNS pode criar registos adicionais.

Tipo de coleção de IP	Tipo de serviço	Conjuntos de registos
Pilha única	ClusterIP	$$2+P$$
Pilha única	Sem interface	$$2+P+2E$$
Duplo	ClusterIP	$$3+P$$
Duplo	Sem interface	$$3+P+3E$$
Consulte o artigo Serviços de pilha única e dupla para mais informações sobre serviços de pilha única e dupla.

Registos de DNS adicionais criados pelo Cloud DNS

O Cloud DNS pode criar registos DNS adicionais além do número mínimo de conjuntos de registos. Estes registos servem vários propósitos, incluindo o seguinte:

Registos SRV: para a deteção de serviços, o Cloud DNS cria frequentemente registos SRV. Estes registos fornecem informações sobre a porta e o protocolo do serviço.
Registos AAAA (para pilha dupla): em configurações de pilha dupla que usam IPv4 e IPv6, o Cloud DNS cria registos A (para IPv4) e registos AAAA (para IPv6) para cada ponto final.
Registos internos: o Cloud DNS pode criar registos internos para a sua própria gestão e otimização. Normalmente, estes registos não são diretamente relevantes para os utilizadores.
Serviços LoadBalancer: para serviços do tipo LoadBalancer, o Cloud DNS cria registos associados ao endereço IP do balanceador de carga externo.
Serviços sem interface: os serviços sem interface têm uma configuração de DNS distinta. Cada Pod tem o seu próprio registo de DNS, o que permite aos clientes estabelecer ligação diretamente aos Pods. É por este motivo que o número da porta não é multiplicado no cálculo do registo do serviço sem interface.

Exemplo: considere um serviço denominado my-http-server que se encontra no espaço de nomes backend. Este serviço expõe duas portas, 80 e 8080, para uma implementação com três pods. Portanto, E = 3 e P = 2.

Tipo de coleção de IP	Tipo de serviço	Conjuntos de registos
Pilha única	ClusterIP	$$2+2$$
Pilha única	Sem interface	$$2+2+2*3$$
Duplo	ClusterIP	$$3+2$$
Duplo	Sem interface	$$3+2+3*3$$

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

Problemas conhecidos

Esta secção descreve os problemas comuns que pode encontrar quando usa o Cloud DNS com o GKE, juntamente com potenciais soluções alternativas.

O Terraform tenta recriar o cluster do Autopilot devido a uma alteração `dns_config`

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

Este problema foi resolvido na versão 4.80.0 do fornecedor Terraform de Google Cloud.

Se não conseguir atualizar a versão do terraform-provider-google ou do terraform-provider-google-beta, pode adicionar a definição lifecycle.ignore_changes ao recurso para ajudar a garantir que o google_container_cluster ignora as alterações ao 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

Esta secção descreve um problema conhecido para clusters do GKE que estão no Cloud DNS e que ativaram o NodeLocal DNSCache no âmbito do cluster.

Quando a NodeLocal DNSCache está ativada no cluster e migra de kube-dns para o Cloud DNS, o cluster pode ter erros de resolução intermitentes.

Se usar kube-dns com a NodeLocal DNSCache ativada no cluster, a NodeLocal DNSCache é configurada para escutar em ambos os endereços: o endereço da NodeLocal DNSCache e o endereço kube-dns.

Para verificar o estado 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 é semelhante ao 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 o cluster usar kube-dns, o NodeLocal DNSCache é executado numa rede isolada e está configurado para ouvir todos os endereços IP dos pods (0.0.0.0). O resultado é semelhante ao seguinte:

    bind 0.0.0.0
    bind 0.0.0.0

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

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