Como usar o Cloud DNS para GKE

Autopilot Standard

Nesta página, explicamos como usar o Cloud DNS como um provedor de DNS do Kubernetes para o Google Kubernetes Engine (GKE).

Usar o Cloud DNS como um provedor de DNS não permite que clientes fora de um cluster resolvam e acessem os serviços do Kubernetes diretamente. Você ainda precisa expor os serviços externamente usando um balanceador de carga e registrar os endereços IP externos de clusters na infraestrutura de DNS.

Para mais informações sobre como usar o kube-dns como um provedor de DNS, consulte Descoberta de serviços e DNS. Para saber como usar uma versão personalizada do kube-dns ou um provedor de DNS personalizado, consulte Como configurar uma implantação personalizada do kube-dns.

Como funciona o Cloud DNS para GKE

O Cloud DNS pode ser usado como o provedor de DNS para o GKE, fornecendo a resolução de DNS de pod e Serviço com DNS gerenciado que não requer um provedor de DNS hospedado em 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 muitos benefícios em comparação com o DNS hospedado no cluster:

Remoção de sobrecarga de gerenciamento do servidor DNS hospedado no cluster. O Cloud DNS não requer escalonamento, monitoramento ou gerenciamento de instâncias de DNS porque é um serviço totalmente gerenciado hospedado na infraestrutura altamente escalonável do Google.
Resolução local de consultas DNS em cada nó do GKE. Semelhante ao NodeLocal DNSCache, o Cloud DNS armazena em cache localmente as respostas de DNS, fornecendo baixa latência e alta resolução de DNS.
Integração com Observabilidade do Google Cloud para monitoramento e 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. — **Diagrama:** como resolver nomes de cluster

No diagrama, o serviço backend seleciona os pods backend em execução. O clouddns-controller cria um registro DNS para o Serviço backend.

O podfrontend envia uma solicitação DNS para resolver o endereço IP do serviço chamadobackend à Servidor de metadados local do Compute Engine em 169.254.169.254 (em inglês). O servidor de metadados é executado localmente no nó, enviando ausências do cache para o Cloud DNS.

O plano de dados do Cloud DNS é executado localmente em cada nó do GKE ou instância da máquina virtual (VM) do Compute Engine. Dependendo do tipo de Serviço do Kubernetes, o Cloud DNS resolve o nome do Serviço para o endereço IP virtual dele, para Serviços de IP do cluster, ou a lista de endereços IP do endpoint, para Serviços headless.

Depois que o pod frontend resolve o endereço IP, ele pode enviar o tráfego para o serviço backend e quaisquer pods atrás do serviço.

Escopos do DNS

O Cloud DNS tem dois tipos de escopos de DNS, o escopo do cluster do GKE e o escopo da nuvem privada virtual (VPC). 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 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:
  
  Observação: o escopo aditivo da VPC do Cloud DNS está em Pré-lançamento.
  
  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. O escopo aditivo da VPC é um modo adicional que é ativado com o escopo do cluster, que pode ser ativado ou desativado no cluster sem afetar o tempo de atividade ou a capacidade de DNS (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 de 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.

A tabela a seguir lista as diferenças entre o escopo do cluster do GKE, o escopo aditivo da VPC do Cloud DNS e o escopo da VPC:

Engenharia de	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	Estende-se para toda a rede VPC	Toda a rede VPC
Resolução de serviço headless	Resolvível no cluster	Resolvível no cluster usando "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 "*.cluster.local" padrão	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/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.

Scope	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:

Scope	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 do cluster
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 exibir o 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 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 ..

Preços

Quando o Cloud DNS é o provedor de DNS para clusters do GKE Standard, as consultas DNS de pods dentro do cluster do GKE são faturadas de acordo com os preços do Cloud DNS.

As consultas a uma zona de DNS com escopo da VPC gerenciadas pelo GKE são faturadas usando o preço padrão do Cloud DNS.

Requisitos

A API Cloud DNS precisa estar ativada no projeto.

O Cloud DNS para GKE tem os seguintes requisitos para o escopo do cluster:

Para o GKE padrão, versão 1.24.7-gke.800, 1.25.3-gke.700 ou posterior.
Para o Autopilot, o GKE versão 1.25.9-gke.400, 1.26.4-gke.500 ou posterior.
Google Cloud CLI versão 411.0.0 ou mais recente.

O Cloud DNS para GKE tem os seguintes requisitos para o escopo aditivo da VPC:

Para o GKE padrão, versão 1.24.7-gke.800, 1.25.3-gke.700 ou posterior.
Para o Autopilot, o GKE versão 1.28 ou posterior.
CLI do Google Cloud versão 471.0.0.
O cluster do GKE precisa usar o escopo do cluster do Cloud DNS como o provedor de DNS padrão.

O Cloud DNS para GKE tem os seguintes requisitos para o escopo do VPC:

Para o Standard, o GKE versão 1.19 ou posterior.
Google Cloud CLI versão 364.0.0 ou mais recente.
A API Cloud DNS precisa estar ativada no projeto.

Restrições e limitações

Considere as seguintes limitações:

O escopo da VPC não é compatível com clusters do Autopilot. Apenas o escopo do cluster é aceito. Se você precisar resolver nomes de serviços headless em execução nos clusters do GKE Autopilot, use o escopo aditivo da VPC.
O Cloud DNS não está em compatível com um regime de conformidade de nível 4 (IL4). O Cloud DNS para GKE não pode ser usado em um Assured Workload com um regime de conformidade IL4. Você precisa usar o kube-dns nesse ambiente regulamentado. Para clusters do GKE Autopilot, a seleção do kube-dns ou do Cloud DNS é feita automaticamente com base no regime de compliance.
As alterações manuais nas zonas DNS particulares gerenciadas não são compatíveis e são substituídas pelo controlador do Cloud DNS. As modificações nos registros DNS nessas zonas não são mantidas quando o controlador é reiniciado.
Depois de ativar o Cloud DNS para o GKE em um cluster, o kube-dns continua sendo executado no cluster. Desative o kube-dns escalonando a implantação do kube-dns e o escalonador automático a zero.
Não é possível alterar o escopo do DNS em um cluster depois de defini-lo com a sinalização --cluster-dns-scope. Se você precisar alterar o escopo do DNS, recrie o cluster com um escopo de DNS diferente.
Os domínios de stub personalizados e as configurações do servidor DNS upstream se aplicam às configurações de DNS de pods e nós. Os pods que usam a rede de host ou processos executados diretamente no host também usam o domínio de stub e as configurações upstream do servidor de nomes. Isso só é compatível com o Standard.
Os domínios de stub personalizados e os servidores de nomes upstream configurados por meio do ConfigMap do kube-dns são aplicados automaticamente ao Cloud DNS para DNS de escopo do cluster. O DNS do escopo da VPC ignora o ConfigMap do kube-dns e você precisa aplicar essas configurações diretamente no Cloud DNS. Isso só é compatível com o Standard.
Não há caminho de migração do kube-dns para o escopo da VPC. A operação é disruptiva. Recrie o cluster ao alternar do kube-dns para o escopo da VPC ou vice-versa.
Para o escopo da VPC, o intervalo de endereços IP secundário para serviços não pode ser compartilhado com nenhum outro cluster dessa sub-rede.
No escopo da VPC, a política de resposta associada a um registro PTR é anexada à rede VPC. Se houver outras políticas de resposta vinculadas à rede do cluster, a resolução de registro do PTR falhará para os endereços IP do serviço do Kubernetes.
Se você tentar criar um serviço headless com um número de pods excedendo a cota permitida, o Cloud DNS não criará conjuntos de registros ou registros para o serviço.

Cotas

O Cloud DNS usa cotas para limitar o número de recursos que o GKE pode criar para entradas DNS. Aplicam-se cotas e limites do Cloud DNS e 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/IPv6)	Número de registros por conjunto de registros de recursos	GKE 1.24 a 1.25: 1.000 (IPv4/IPv6) GKE 1.26 e posterior: 3.500/2.000 (IPv4/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 recursos

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).

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 gcloud components update.
Observação: para instalações atuais da CLI gcloud, defina as propriedades compute/region e compute/zone. Ao definir locais padrão, é possível evitar erros na CLI gcloud, como: One of [--zone, --region] must be supplied: Please specify location.

Ative a API do Cloud DNS no projeto:

Ativar a API Cloud DNS.

Ativar o DNS do escopo do cluster

No DNS do escopo do cluster, apenas os nós em execução no cluster do GKE podem resolver nomes de serviço, e os nomes de serviço não entram em conflito entre os clusters. Esse comportamento é igual ao do kube-dns nos clusters do GKE. Isso significa que é possível migrar os clusters do kube-dns para o escopo do cluster do Cloud DNS sem inatividade ou alterações nos seus aplicativos.

O diagrama a seguir mostra como o Cloud DNS cria uma zona de DNS particular para um cluster do GKE. Somente processos e pods em execução nos nós do cluster podem resolver os registros DNS do cluster, porque apenas os nós estão no escopo do DNS.

Pods em nós diferentes que resolvem Serviços no cluster do GKE. — **Diagrama:** DNS do escopo do cluster

Ativar o DNS do escopo do cluster em um novo cluster

Cluster do Autopilot do GKE

Os novos clusters do Autopilot na versão 1.25.9-gke.400, 1.26.4-gke.500 ou posterior têm como padrão o escopo de cluster do Cloud DNS.

Cluster do GKE Standard

É possível criar um cluster do GKE Standard com o escopo de cluster do Cloud DNS ativado usando a CLI gcloud ou o console do Google Cloud:

gcloud

Crie um cluster usando a sinalização --cluster-dns:

gcloud container clusters create CLUSTER_NAME \
    --cluster-dns=clouddns \
    --cluster-dns-scope=cluster \
    --location=COMPUTE_LOCATION

Substitua:

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

A sinalização --cluster-dns-scope=cluster é opcional no comando porque cluster é o valor padrão.

Console

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

Acessar o Google Kubernetes Engine
Clique em Criar.
No painel de navegação, em Cluster, clique em Rede.
Na seção Provedor de DNS, clique em Cloud DNS.
Selecione Escopo do cluster.
Configure o cluster conforme necessário.
Clique em Criar.

Ativar o DNS do escopo do cluster em um cluster existente

Cluster do Autopilot do GKE

Não é possível migrar um cluster atual do Autopilot do GKE do escopo de cluster do kube-dns para o do Cloud DNS. Para ativar o escopo de cluster do Cloud DNS, recrie os clusters do Autopilot na versão 1.25.9-gke.400, 1.26.4-gke.500 ou posterior.

Cluster do GKE Standard

É possível migrar um cluster atual do GKE Standard do escopo de cluster do kube-dns para o do Cloud DNS usando a CLI gcloud ou o console do Google Cloud em um cluster do GKE Standard.

Ao migrar um cluster existente, os nós nele não usam o Cloud DNS como provedor de DNS até que você os recrie.

Depois de ativar o Cloud DNS para um cluster, as configurações só serão aplicadas se você fizer upgrade dos pools de nós atuais ou adicionar novos pools de nós ao cluster. Quando você faz upgrade de um pool de nós, eles são recriados.

Também é possível migrar clusters que têm aplicativos em execução sem interromper a comunicação do cluster ativando o Cloud DNS como um provedor de DNS em cada pool de nós separadamente. Um subconjunto de nós está operacional o tempo todo porque alguns pools de nós usam o kube-dns e outros usam o Cloud DNS.

Nas etapas a seguir, você ativa o Cloud DNS para um cluster e, em seguida, faz upgrade dos pools de nós. O upgrade dos pools de nós recria os nós. Os nós usam o Cloud DNS para resolução de DNS em vez de kube-dns.

gcloud

Atualize o cluster atual:
```
gcloud container clusters update CLUSTER_NAME \
    --cluster-dns=clouddns \
    --cluster-dns-scope=cluster \
    --location=COMPUTE_LOCATION
```
Substitua:
- CLUSTER_NAME: o nome do cluster.
- COMPUTE_LOCATION: a região do Compute Engine para o cluster.
A resposta é semelhante a:
```
All the node-pools in the cluster need to be re-created by the user to start using Cloud DNS for DNS lookups. It is highly recommended to complete this step
shortly after enabling Cloud DNS.
Do you want to continue (Y/n)?
```
Após a confirmação, o controlador do Cloud DNS é executado no plano de controle do GKE, mas seus pods não usam o Cloud DNS para resolução de DNS até que você faça upgrade do pool de nós ou adicione novos pools de nós ao cluster.
Faça upgrade dos pools de nós no cluster para usar o Cloud DNS:
```
gcloud container clusters upgrade CLUSTER_NAME \
    --node-pool=POOL_NAME \
    --location=COMPUTE_LOCATION
```
Observação: para versões da CLI do Google Cloud anteriores à 411.0.0, use gcloud beta container em vez de gcloud container.

Substitua:
- CLUSTER_NAME: o nome do cluster.
- POOL_NAME: o nome do pool de nós a ser atualizado.
Se o pool de nós e o plano de controle estiverem executando a mesma versão, primeiro atualize o plano de controle, conforme descrito em Como fazer upgrade manual do plano de controle. Em seguida, realize o upgrade do pool de nós.

Observação: fazer upgrade para a mesma versão em que o pool de nós está em execução não afeta o pod. Para esses pools de nós, os pods em execução neles ainda usam o kube-dns. Reduzir a implantação do kube-dns e o escalonador automático para zero causará falhas de DNS nesses pods. Para que os pods usem o Cloud DNS, você precisa fazer upgrade do pool de nós para uma nova versão. Como alternativa, crie um novo pool de nós na mesma versão.

Confirme a resposta e repita esse comando para cada pool de nós no cluster. Se o cluster tiver um pool de nós, omita a sinalização --node-pool.

Console

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

Acessar o Google Kubernetes Engine
Clique no nome do cluster que você quer modificar.
Em Rede, no campo Provedor de DNS, clique em Editar provedor de DNS.
Clique em Cloud DNS.
Clique em Escopo do cluster.
Clique em Salvar alterações.

Ativar o escopo aditivo da VPC do Cloud DNS

Nesta seção, descrevemos as etapas para ativar ou desativar o escopo aditivo da VPC do Cloud DNS, como um complemento para o escopo do cluster do Cloud DNS.

Ativar o escopo aditivo da VPC do Cloud DNS em um novo cluster

É possível ativar o DNS do escopo da VPC em um novo cluster do GKE usando a gcloud CLI ou o console do Google Cloud.

Para o Autopilot

gcloud container clusters create-auto CLUSTER_NAME \
    --additive-vpc-scope-dns-domain=UNIQUE_CLUSTER_DOMAIN

Substitua:

CLUSTER_NAME: o nome do cluster.
UNIQUE_CLUSTER_DOMAIN: o nome de um domínio. É preciso garantir que esse nome seja exclusivo na VPC porque o GKE não confirma esse valor. Não é possível alterar esse valor depois de defini-lo. Você não pode usar um domínio que termine em ".local" ou pode ter falhas de resolução de DNS.

Para o Standard

gcloud container clusters create CLUSTER_NAME \
    --cluster-dns-scope=cluster \
    --additive-vpc-scope-dns-domain=UNIQUE_CLUSTER_DOMAIN

Substitua:

CLUSTER_NAME: o nome do cluster.
UNIQUE_CLUSTER_DOMAIN: o nome de um domínio. É preciso garantir que esse nome seja exclusivo na VPC porque o GKE não confirma esse valor. Não é possível alterar esse valor depois de defini-lo. Você não pode usar um domínio que termine em ".local" ou pode ter falhas de resolução de DNS.

Ativar o escopo aditivo da VPC do Cloud DNS em um cluster já existente

Para ativar o escopo aditivo da VPC do Cloud DNS em um cluster já existente, primeiro ative o Cloud DNS em um cluster e, em seguida, faça upgrade dos pools de nós. O upgrade dos pools de nós recria os nós. Os nós usam o Cloud DNS para resolução de DNS no lugar do kube-dns.

Para ativar o escopo aditivo da VPC do Cloud DNS em um cluster já existente:

gcloud container clusters update CLUSTER_NAME \
    --enable-additive-vpc-scope \
    --additive-vpc-scope-dns-domain=UNIQUE_CLUSTER_DOMAIN

Substitua:

CLUSTER_NAME: o nome do cluster.
UNIQUE_CLUSTER_DOMAIN: o nome de um domínio. É preciso garantir que esse nome seja exclusivo na VPC porque o GKE não confirma esse valor. Não é possível alterar esse valor depois de defini-lo. Você não pode usar um domínio que termine em ".local" ou pode ter falhas de resolução de DNS.

Ativar DNS do escopo da VPC

No DNS de escopo da VPC, os nomes DNS de um cluster são resolvíveis em toda a VPC. Qualquer cliente na VPC pode resolver registros DNS de cluster.

O DNS de escopo da VPC ativa os seguintes casos de uso:

Descoberta de serviço sem comando para clientes que não são do GKE na mesma VPC.
Resolução de serviço do GKE a partir de clientes na nuvem locais ou de terceiros. Para mais informações, consulte Política do servidor de entrada.
Resolução de serviço em que um cliente pode decidir com qual cluster quer se comunicar usando o domínio DNS de cluster personalizado.

No diagrama a seguir, dois clusters do GKE usam DNS de escopo da VPC na mesma VPC. Os dois clusters têm um domínio DNS personalizado, .cluster1 e .cluster2, em vez do domínio .cluster.local padrão. Uma VM se comunica com o serviço de back-end headless ao resolver backend.default.svc.cluster1. O Cloud DNS resolve o serviço headless para os IPs de pod individuais no serviço e a VM se comunica diretamente com os IPs de pod.

Clientes que resolvem Serviços headless de fora do cluster do GKE. — **Diagrama:** DNS do escopo da VPC

Também é possível executar esse tipo de resolução de outras redes quando conectadas à VPC por meio do Cloud Interconnect ou do Cloud VPN. As políticas de servidor DNS permitem que os clientes das redes conectadas à VPC resolvam nomes no Cloud DNS, incluindo o GKE Services, se o cluster estiver usando o DNS do escopo da VPC.

Ativar o DNS do escopo da VPC em um cluster existente

A migração é permitida apenas no GKE Standard, e não no GKE Autopilot.

Cluster do Autopilot do GKE

Não é possível migrar um cluster do GKE Autopilot do kube-dns para o escopo da VPC do Cloud DNS.

Cluster do GKE Standard

É possível migrar um cluster do GKE do kube-dns para o escopo da VPC do Cloud DNS usando a CLI gcloud ou o console do Google Cloud.

gcloud

Atualize o cluster atual:
```
gcloud container clusters update CLUSTER_NAME \
    --cluster-dns=clouddns \
    --cluster-dns-scope=vpc \
    --cluster-dns-domain=CUSTOM_DOMAIN \
    --location=COMPUTE_LOCATION
```
Substitua:
- CLUSTER_NAME: o nome do cluster.
- COMPUTE_LOCATION: a região do Compute Engine para o cluster.
- CUSTOM_DOMAIN: o nome de um domínio. É preciso garantir que esse nome seja exclusivo na VPC porque o GKE não confirma esse valor. Não é possível alterar esse valor depois de defini-lo. Você não pode usar um domínio que termine em ".local" ou pode ter falhas de resolução de DNS.
A resposta é semelhante a:
```
All the node-pools in the cluster need to be re-created by the user to start using Cloud DNS for DNS lookups. It is highly recommended to complete this step
shortly after enabling Cloud DNS.
Do you want to continue (Y/n)?
```
Depois de confirmar, o controlador do Cloud DNS será executado no plano de controle do GKE. Os pods não usarão o Cloud DNS para resolução de DNS até que você faça upgrade do pool de nós ou adicione novos pools ao cluster.
Faça upgrade dos pools de nós no cluster para usar o Cloud DNS:
```
gcloud container clusters upgrade CLUSTER_NAME \
    --node-pool=POOL_NAME
```
Substitua:
- CLUSTER_NAME: o nome do cluster.
- POOL_NAME: o nome do pool de nós a ser atualizado.
Se o pool de nós e o plano de controle estiverem executando a mesma versão, primeiro atualize o plano de controle, conforme descrito em Como fazer upgrade manual do plano de controle. Em seguida, realize o upgrade do pool de nós.

Observação: fazer upgrade para a mesma versão em que o pool de nós está em execução não afeta o pod. Para esses pools de nós, os pods em execução nesses nós ainda usam o kube-dns. O escalonamento da implantação do kube-dns e do escalonador automático como zero causará falhas de DNS nesses pods. Para que os pods usem o Cloud DNS, você precisa fazer upgrade do pool de nós para uma nova versão. Como alternativa, crie um novo pool de nós na mesma versão.

Confirme a resposta e repita esse comando para cada pool de nós no cluster. Se o cluster tiver um pool de nós, omita a sinalização --node-pool.

Console

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

Acessar o Google Kubernetes Engine
Clique no nome do cluster que você quer modificar.
Em Rede, no campo Provedor de DNS, clique em Editar provedor de DNS.
Clique em Cloud DNS.
Clique em Escopo da VPC.
Clique em Salvar alterações.

Verificar o Cloud DNS

Verifique se o Cloud DNS para GKE está funcionando corretamente no cluster:

Verifique se os nós estão usando o Cloud DNS conectando-se a um pod em um nó e executando o comando cat /etc/resolv.conf:
```
kubectl exec -it POD_NAME -- cat /etc/resolv.conf | grep nameserver
```
Substitua POD_NAME pelo nome do pod.

Com base no modo de cluster, a saída é semelhante a esta:

Cluster do Autopilot do GKE
```
nameserver 169.254.20.10
```
Como o NodeLocal DNSCache é ativado por padrão no GKE Autopilot, o pod está usando o NodeLocal DNSCache.

O NodeLocal DNSCache só encaminha a solicitação para o Cloud DNS quando o cache local não tem uma entrada para o nome que está sendo pesquisado.

Cluster do GKE Standard
```
nameserver 169.254.169.254
```
O pod está usando 169.254.169.254 como nameserver, que é o endereço IP do servidor de metadados em que o plano de dados do Cloud DNS detecta solicitações na porta 53. Os nós não usam mais o endereço de serviço do kube-dns para a resolução de DNS, e toda resolução de DNS ocorre no nó local.

Se a saída é um endereço IP semelhante a 10.x.y.10, o pod está usando o kube-dns. Consulte a seção Solução de problemas para entender por que seu pod ainda está usando o kube-dns.

Se a saída é 169.254.20.10, você ativou o NodeLocal DNSCache no cluster, portanto, o pod está usando o NodeLocal DNSCache.

Implante um aplicativo de amostra no cluster:

kubectl run dns-test --image us-docker.pkg.dev/google-samples/containers/gke/hello-app:2.0

Exponha o aplicativo de amostra com um serviço:

kubectl expose pod dns-test --name dns-test-svc --port 8080

Verifique se o serviço foi implantado com sucesso:
```
kubectl get svc dns-test-svc
```
O resultado será assim:
```
NAME           TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)    AGE
dns-test-svc   ClusterIP   10.47.255.11    <none>        8080/TCP   6m10s
```
O valor de CLUSTER-IP é o endereço IP virtual do cluster. Neste exemplo, o endereço IP virtual é 10.47.255.11.

Verifique se o nome do Serviço foi criado como um registro na zona de DNS particular do seu cluster:

gcloud dns record-sets list \
    --zone=PRIVATE_DNS_ZONE \
    --name=dns-test-svc.default.svc.cluster.local.

Substitua PRIVATE_DNS_ZONE pelo nome da zona de DNS gerenciada.

O resultado será assim:

NAME: dns-test-svc.default.svc.cluster.local.
TYPE: A
TTL: 30
DATA: 10.47.255.11

Desativar o Cloud DNS para GKE

Cluster do Autopilot do GKE

Não é possível desativar o Cloud DNS em um cluster do Autopilot do GKE criado por padrão com o Cloud DNS. Consulte os requisitos para mais informações sobre clusters do Autopilot do GKE que usam o Cloud DNS por padrão.

Cluster do GKE Standard

É possível desativar o escopo do cluster Cloud DNS usando a CLI gcloud ou o console do Google Cloud em um cluster do GKE Standard.

gcloud

Atualize o cluster para usar o kube-dns:

gcloud container clusters update CLUSTER_NAME \
    --cluster-dns=default

Console

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

Acessar o Google Kubernetes Engine
Clique no nome do cluster que você quer modificar.
Em Rede, no campo Provedor de DNS, clique em Editar provedor de DNS.
Clique em Kube-dns.
Clique em Salvar alterações.

Desativar o escopo aditivo da VPC do Cloud DNS

Quando você desativa o escopo aditivo da VPC do Cloud DNS para o cluster, apenas os registros DNS nas zonas particulares anexadas à rede VPC são excluídos. Os registros nas zonas de DNS particulares do cluster do GKE permanecerão, gerenciados pelo Cloud DNS para GKE, até que o serviço headless seja excluído do cluster.

Para desativar o escopo aditivo da VPC do Cloud DNS, execute o seguinte comando:

gcloud container clusters update CLUSTER_NAME \
    --disable-additive-vpc-scope

Substitua CLUSTER_NAME pelo nome do cluster.

Isso manterá seu cluster com o escopo do cluster do Cloud DNS ativado para fornecer a resolução de DNS pelo cluster.

Limpar

Depois de concluir os exercícios nesta página, siga estas etapas para remover os recursos e evitar cobranças indesejadas na conta:

Exclua o serviço:
```
kubectl delete service dns-test-svc
```
Exclua o pod:
```
kubectl delete Pod dns-test
```
Também é possível excluir o cluster.

Usar o Cloud DNS com VPC compartilhada

O Cloud DNS para GKE é compatível com a VPC compartilhada para o escopo da VPC e do cluster.

O controlador do GKE cria uma zona particular gerenciada no mesmo projeto que o cluster do GKE.

A conta de serviço do GKE para o cluster do GKE não exige gerenciamento de identidade e acesso (IAM) para DNS fora do próprio projeto, porque a zona gerenciada e o cluster do GKE residem no mesmo projeto.

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. Se você já tiver clusters que usam VPC compartilhada e escopo de VPC do Cloud DNS, será necessário migrá-los manualmente com as seguintes etapas:

Faça upgrade dos clusters atuais que têm a VPC compartilhada ativada para a versão 1.22.3-gke.700+ ou 1.21.6-gke.1500+ ou mais recente do GKE.
Migre a política de resposta do projeto de serviço para o projeto host. Você só precisa realizar essa migração uma vez por rede VPC compartilhada.

É possível migrar sua política de resposta usando o Console do Google Cloud.

Siga as etapas abaixo no seu projeto de serviço:

Acesse a página de zonas do Cloud DNS.

Acessar zonas do Cloud DNS
Clique na guia Zonas de política de resposta.
Clique na política de resposta da sua rede VPC. É possível identificar a política de resposta pela descrição, que é semelhante a "Política de resposta para clusters do GKE na rede NETWORK_NAME".
Clique na guia Em uso por.
Ao lado do nome do projeto host, clique em para remover a vinculação de rede.
Clique na guia Regras da política de resposta.
Selecione todas as entradas na tabela.
Clique em Remover regras de política de resposta.
Clique em Excluir política de resposta.

Depois que você exclui a política de resposta, o controlador DNS cria automaticamente a política de resposta no projeto host. Clusters de outros projetos de serviço compartilham essa política de resposta.

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.

Problemas conhecidos

O Terraform planeja 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 em execução nas versões 1.25.9-gke.400, 1.26.4-gke.500, 1.27.1-gke.400 ou posterior usam o Cloud DNS como um provedor de DNS em vez de kube-dns

Esse problema é 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 lifecycle.ignore_changes ao recurso para garantir que google_container_cluster ignore as mudanças em dns_config:

  lifecycle {
    ignore_changes = [
      dns_config,
    ]
  }

Solução de problemas

Para saber como ativar a geração de registros de DNS, consulte Como ativar e desativar a geração de registros para zonas gerenciadas particulares.

Para mais informações sobre como solucionar problemas de DNS, consulte Como solucionar problemas de DNS no GKE.

Não foi possível atualizar o cluster atual ou criar um com o Cloud DNS ativado

Verifique se você está usando a versão correta. O Cloud DNS para GKE exige a versão 1.19 ou posterior do GKE para clusters que usam o escopo da VPC ou a versão 1.24.7-gke.800, 1.25.3-gke.700 ou posterior do GKE para clusters que usam o escopo do cluster (em inglês).

Os pods usam o kube-dns mesmo após a ativação do Cloud DNS em um cluster atual.

Verifique se você fez upgrade ou recriou seus pools de nós depois de ativar o Cloud DNS no cluster. Até que esta etapa seja concluída, os pods continuam usando o kube-dns.

O pod não consegue resolver pesquisas DNS

Verifique se o pod está usando o Cloud DNS conectando-se a um pod e executando o comando cat /etc/resolv.conf:
```
kubectl exec -it POD_NAME -- cat /etc/resolv.conf | grep nameserver
```
Substitua POD_NAME pelo nome do pod.

O resultado será assim:
```
nameserver 169.254.169.254
```
Se a saída é um endereço IP semelhante a 10.x.y.10 ou 34.118.224.10 (somente em clusters do Autopilot do GKE com versões 1.27 e posteriores), o pod está usando o kube-dns. Se a saída é 169.254.20.10, o pod está usando o NodeLocal DNSCache.

Confirme se a zona gerenciada existe e contém a entrada DNS necessária:

gcloud dns managed-zones list --format list

A resposta será semelhante a:

 - creationTime: 2021-02-12T19:24:37.045Z
   description: Private zone for GKE cluster "cluster1" with cluster suffix "cluster.local" in project "project-243723"
   dnsName: cluster.local.
   id: 5887499284756055830
   kind: dns#managedZone
   name: gke-cluster1-aa94c1f9-dns
   nameServers: ['ns-gcp-private.googledomains.com.']
   privateVisibilityConfig: {'kind': 'dns#managedZonePrivateVisibilityConfig'}
   visibility: private

O valor de name na resposta mostra que o Google Cloud criou uma zona particular chamada gke-cluster1-aa94c1f9-dns.

Verifique se o Cloud DNS contém entradas para o cluster:
```
gcloud dns record-sets list --zone ZONE_NAME | grep SERVICE_NAME
```
Substitua:
- ZONE_NAME: o nome da zona particular.
- SERVICE_NAME: o nome do serviço.
A saída mostra que o Cloud DNS contém um registro A para o domínio dns-test.default.svc.cluster.local. e o endereço IP do cluster, 10.47.255.11:
```
dns-test.default.svc.cluster.local.                A     30     10.47.255.11
```
Ative a geração de registros do Cloud DNS para rastrear consultas. Cada entrada de registro contém informações sobre a consulta, incluindo a latência de DNS.

As buscas DNS nos nós falham após a ativação do Cloud DNS em um cluster

Se você ativar o escopo do cluster do Cloud DNS em um cluster do GKE que tem domínios de stub personalizados ou servidores de nomes upstream, a configuração personalizada será aplicada a nós e pods no cluster porque o Cloud DNS não conseguirá distinguir entre pod e nó Solicitações de DNS. As buscas DNS nos nós podem falhar se o servidor upstream personalizado não resolver as consultas.

Não foi possível atualizar o cluster já existente ou criar um cluster com o escopo aditivo da VPC do Cloud DNS ativado

Verifique se você está usando a versão correta. O escopo aditivo da VPC do Cloud DNS requer o GKE versão 1.28 ou mais recente.

O pod não consegue resolver pesquisas DNS

Verifique se o pod está usando o Cloud DNS conectando-se a um pod e executando o comando cat /etc/resolv.conf:
```
kubectl exec -it POD_NAME -- cat /etc/resolv.conf | grep nameserver
```
Substitua POD_NAME pelo nome do pod.

O resultado será assim:
```
nameserver 169.254.169.254
```
Se a saída é um endereço IP semelhante a 10.x.y.10 ou 34.118.224.10 (somente em clusters do Autopilot do GKE com versões 1.27 e posteriores), o pod está usando o kube-dns. Se a saída é 169.254.20.10, o pod está usando o NodeLocal DNSCache.

Confirme se a zona gerenciada existe e contém a entrada DNS necessária:

gcloud dns managed-zones list --format list

A resposta será semelhante a:

gke-cluster-1-cbdc0678-dns  cluster.local.   Private zone for GKE cluster "cluster-1" with cluster suffix "cluster.local." in project "PROJECT_NAME" with scope "CLUSTER_SCOPE"  private
gke-cluster-1-cbdc-dns-vpc  CLUSTER_DOMAIN.  Private zone for GKE cluster "cluster-1" with cluster suffix "CLUSTER_DOMAIN." in project "PROJECT_NAME" with scope "VPC_SCOPE"     private

O valor de name na resposta mostra que o Google Cloud criou uma zona particular chamada gke-cluster1-aa94c1f9-dns.

Verifique se o Cloud DNS contém entradas para o cluster nas duas zonas gerenciadas:
```
gcloud dns record-sets list --zone ZONE_NAME | grep SERVICE_NAME
```
Substitua:
- ZONE_NAME: o nome da zona particular.
- SERVICE_NAME: o nome do serviço.
O resultado será assim:
```
my-service.default.svc.cluster.local.                A     30     10.47.255.11
```
O valor de name na resposta mostra que o Google Cloud criou uma zona particular chamada gke-cluster1-aa94c1f9-dns.

Para buscas DNS reversas, verifique se o Cloud DNS contém entradas para o cluster nas políticas de resposta:

gcloud dns response-policies list --format="table(responsePolicyName, description)"

O resultado será assim:

  gke-NETWORK_HASH-rp        Response Policy for GKE clusters on network "VPC_NAME".
  gke-cluster-1-52c8f518-rp  Response Policy for GKE cluster "cluster-1" with cluster suffix "cluster.local." in project "khamed-gke-dev" with scope "CLUSTER_SCOPE".

O valor de name na resposta mostra que o Google Cloud criou uma zona particular chamada gke-cluster1-aa94c1f9-rp.

Para buscas DNS reversas, verifique se o Cloud DNS contém entradas para o cluster nas políticas de resposta:

  gcloud dns response-policies rules list ZONE_NAME --format="table(localData.localDatas[0].name, localData.localDatas[0].rrdatas[0])"

Substitua ZONE_NAME pelo nome da zona particular.

O resultado será assim:

  1.240.27.10.in-addr.arpa.    kubernetes.default.svc.cluster.local.
  52.252.27.10.in-addr.arpa.   default-http-backend.kube-system.svc.cluster.local.
  10.240.27.10.in-addr.arpa.   kube-dns.kube-system.svc.cluster.local.
  146.250.27.10.in-addr.arpa.  metrics-server.kube-system.svc.cluster.local.

A seguir

Leia uma visão geral de como o GKE fornece o DNS gerenciado.
Leia DNS para serviços e pods a fim de conferir uma visão geral de como o DNS é usado nos clusters do Kubernetes.
Saiba mais sobre Escopos e hierarquias no Cloud DNS.
Saiba mais sobre Como ativar e desativar a geração de registros para zonas gerenciadas particulares.

Como usar o Cloud DNS para GKE

Como funciona o Cloud DNS para GKE

Arquitetura

Escopos do DNS

Recursos do Cloud DNS

Zonas gerenciadas e zonas de encaminhamento

Preços

Requisitos

Restrições e limitações

Cotas

Limites de recursos

Antes de começar

Ativar o DNS do escopo do cluster

Ativar o DNS do escopo do cluster em um novo cluster

gcloud

Console

Ativar o DNS do escopo do cluster em um cluster existente

gcloud

Console

Ativar o escopo aditivo da VPC do Cloud DNS

Ativar o escopo aditivo da VPC do Cloud DNS em um novo cluster

Ativar o escopo aditivo da VPC do Cloud DNS em um cluster já existente

Ativar DNS do escopo da VPC

Ativar o DNS do escopo da VPC em um cluster existente

gcloud

Console

Verificar o Cloud DNS

Desativar o Cloud DNS para GKE

gcloud

Console

Desativar o escopo aditivo da VPC do Cloud DNS

Limpar

Usar o Cloud DNS com VPC compartilhada

Mais de um cluster por projeto de serviço

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

Problemas conhecidos

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

Solução de problemas

Não foi possível atualizar o cluster atual ou criar um com o Cloud DNS ativado

Os pods usam o kube-dns mesmo após a ativação do Cloud DNS em um cluster atual.

O pod não consegue resolver pesquisas DNS

As buscas DNS nos nós falham após a ativação do Cloud DNS em um cluster

Não foi possível atualizar o cluster já existente ou criar um cluster com o escopo aditivo da VPC do Cloud DNS ativado

O pod não consegue resolver pesquisas DNS

A seguir

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