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

      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.

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:

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

Console

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

    Acessar o Google Kubernetes Engine

  2. Clique em Criar.

  3. No painel de navegação, em Cluster, clique em Rede.

  4. Na seção Provedor de DNS, clique em Cloud DNS.

  5. Selecione Escopo do cluster.

  6. Configure o cluster conforme necessário.

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

  1. Atualize o cluster atual:

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

    Substitua:

    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.

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

    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.

    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

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

    Acessar o Google Kubernetes Engine

  2. Clique no nome do cluster que você quer modificar.

  3. Em Rede, no campo Provedor de DNS, clique em Editar provedor de DNS.

  4. Clique em Cloud DNS.

  5. Clique em Escopo do cluster.

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

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.

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

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

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

    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

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

    Acessar o Google Kubernetes Engine

  2. Clique no nome do cluster que você quer modificar.

  3. Em Rede, no campo Provedor de DNS, clique em Editar provedor de DNS.

  4. Clique em Cloud DNS.

  5. Clique em Escopo da VPC.

  6. Clique em Salvar alterações.

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.

    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.

  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.

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

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

    Acessar o Google Kubernetes Engine

  2. Clique no nome do cluster que você quer modificar.

  3. Em Rede, no campo Provedor de DNS, clique em Editar provedor de DNS.

  4. Clique em Kube-dns.

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

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

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

  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:

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

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

  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