Como usar o Cloud DNS para GKE

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.

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

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.

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

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

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.

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

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

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.

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

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

Restrições e limitações

Considere as seguintes limitações:

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

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

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

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:

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.

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

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.

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.

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.

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.

Verificar o Cloud DNS

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

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

2. Implante um aplicativo de amostra no cluster:

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

3. Exponha o aplicativo de amostra com um serviço:

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

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

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

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:

1. Exclua o serviço:

   kubectl delete service dns-test-svc
   

2. Exclua o pod:

   kubectl delete Pod dns-test
   

3. Também é possível excluir o cluster.

Usar o Cloud DNS com VPC compartilhada

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.

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

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

1. Acesse a página de zonas do Cloud DNS.

   Acessar zonas do Cloud DNS

2. Clique na guia Zonas de política de resposta.

3. 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".

4. Clique na guia Em uso por.

5. Ao lado do nome do projeto host, clique em delete para remover a vinculação de rede.

6. Clique na guia Regras da política de resposta.

7. Selecione todas as entradas na tabela.

8. Clique em Remover regras de política de resposta.

9. Clique em delete 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.

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

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.

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

Se você ativar o Cloud DNS no escopo de 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 solicitações de DNS de pods e nós. Talvez haja falha nas buscas DNS nos nós 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

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

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

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

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

5. 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 DNS gerenciado.
• Leia DNS para serviços e pods para 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.