Usar o Cloud DNS para o GKE

Esta página explica como usar o Cloud DNS como um fornecedor de DNS do Kubernetes para o Google Kubernetes Engine (GKE).

A utilização do Cloud DNS como fornecedor de DNS não permite que os clientes fora de um cluster resolvam e alcancem diretamente os serviços Kubernetes. Continua a ter de expor os serviços externamente através de um equilibrador de carga e registar os respetivos endereços IP externos do cluster na sua infraestrutura DNS.

Para mais informações sobre a utilização do kube-dns como fornecedor de DNS, consulte o artigo Deteção de serviços e DNS.

Para saber como usar uma versão personalizada do kube-dns ou um fornecedor de DNS personalizado, consulte Configurar uma implementação do kube-dns personalizada.

Como funciona o Cloud DNS para GKE

O Cloud DNS pode ser usado como o fornecedor de DNS para o GKE, fornecendo resolução de DNS de pods e serviços com DNS gerido que não requer um fornecedor de DNS alojado no cluster. Os registos DNS para pods e serviços são aprovisionados automaticamente no Cloud DNS para o endereço IP do cluster, o serviço sem cabeçalho e o serviço de nome externo.

O Cloud DNS suporta a especificação de DNS do Kubernetes completa e oferece resolução para registos A, AAAA, SRV e PTR para serviços num cluster do GKE. Os registos PTR são implementados através de regras de políticas de resposta.

A utilização do Cloud DNS como fornecedor de DNS para o GKE oferece muitas vantagens em relação ao DNS alojado no cluster:

• Remove a sobrecarga da gestão do servidor DNS alojado no cluster. O Cloud DNS não requer dimensionamento, monitorização nem gestão de instâncias de DNS, uma vez que é um serviço totalmente gerido alojado na infraestrutura altamente escalável da Google.
• Resolução local de consultas DNS em cada nó do GKE. Semelhante à NodeLocal DNSCache, o Cloud DNS armazena em cache as respostas de DNS localmente, oferecendo uma resolução de DNS de baixa latência e elevada escalabilidade.
• Integração com o Google Cloud Observability para monitorização de DNS e registo. Para mais informações, consulte o artigo Ativar e desativar o registo para zonas geridas privadas.

Arquitetura

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

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

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

O pod frontend envia um pedido DNS para resolver o endereço IP do serviço denominado backend para o servidor de metadados local do Compute Engine em 169.254.169.254. O servidor de metadados é executado localmente no nó, enviando falhas de cache para o Cloud DNS.

O plano de dados do Cloud DNS é executado localmente em cada nó do GKE ou instância de máquina virtual (VM) do Compute Engine. Consoante o tipo de serviço do Kubernetes, o Cloud DNS resolve o nome do serviço para o respetivo endereço IP virtual, para serviços de IP do cluster, ou a lista de endereços IP de pontos finais, para serviços sem cabeça.

Depois de o Pod frontend resolver o endereço IP, o Pod pode enviar tráfego para o Serviço backend e quaisquer Pods atrás do Serviço.

Âmbitos de DNS

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

• Âmbito do cluster do GKE: os registos DNS só são 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ços. Por predefinição, os clusters têm nomes DNS que terminam em *.cluster.local. Estes nomes DNS só são visíveis no cluster e não se sobrepõem nem entram em conflito com os nomes DNS de outros clusters do GKE no mesmo projeto.*.cluster.local Este é o modo predefinido.

  • Âmbito da VPC aditiva do Cloud DNS:

    O âmbito da VPC aditivo do Cloud DNS é uma funcionalidade opcional que expande o âmbito do cluster do GKE para tornar os serviços sem cabeça resolvíveis a partir de outros recursos na VPC, como VMs do Compute Engine ou clientes no local ligados através do Cloud VPN ou do Cloud Interconnect. O âmbito de VPC aditivo é um modo adicional que é ativado juntamente com o âmbito do cluster, que pode ativar ou desativar no seu cluster sem afetar o tempo de atividade ou a capacidade do DNS (âmbito do cluster).

• Âmbito da VPC: os registos DNS são resolvidos em toda a VPC. As VMs do Compute Engine e os clientes no local podem estabelecer ligação através do Cloud Interconnect ou da Cloud VPN e resolver diretamente os nomes dos serviços do GKE. Tem de definir um domínio personalizado exclusivo para cada cluster, o que significa que todos os registos DNS de serviços e pods são exclusivos na VPC. Este modo reduz o atrito de comunicação entre os recursos do GKE e os recursos não pertencentes ao GKE.

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

Recursos do Cloud DNS

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

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

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

Para saber como criar domínios de stub personalizados ou servidores de nomes upstream personalizados, consulte o artigo Adicionar resolvedores personalizados para domínios de stub.

Zonas geridas e zonas de encaminhamento

Para publicar tráfego DNS interno, o controlador do Cloud DNS cria uma zona DNS gerida em cada zona do Compute Engine à qual o cluster pertence.

Por exemplo, se implementar um cluster na zona us-central1-c, o controlador do Cloud DNS cria uma zona gerida em us-central1-a, us-central1-b, us-central1-c e us-central1-f.

Para cada DNS stubDomain, o controlador do Cloud DNS cria uma zona de encaminhamento.

O Cloud DNS processa cada DNS a montante através de uma zona gerida com o . nome DNS.

Requisitos

A API Cloud DNS tem de estar ativada no seu projeto.

O Cloud DNS para GKE tem os seguintes requisitos para o âmbito do cluster

• Para a versão 1.24.7-gke.800, 1.25.3-gke.700 ou posterior do GKE Standard.
• Para o Autopilot, versão 1.25.9-gke.400, 1.26.4-gke.500 ou posterior do GKE.
• Versão 411.0.0 ou posterior da CLI do Google Cloud.

O Cloud DNS para o GKE tem os seguintes requisitos para o âmbito do VPC aditivo:

• Versão 1.28.3-gke.1430000 ou posterior do GKE.
• Versão 503.0.0 ou posterior da CLI do Google Cloud.
• O cluster do GKE tem de usar o âmbito do cluster do Cloud DNS como fornecedor de DNS predefinido.

O Cloud DNS para o GKE tem os seguintes requisitos para o âmbito da VPC:

• Para o Standard, versão 1.19 ou posterior do GKE.
• Versão 364.0.0 ou posterior da Google Cloud CLI.
• A API Cloud DNS tem de estar ativada no seu projeto.

Restrições e limitações

Aplicam-se as seguintes limitações:

• O âmbito da VPC não é suportado em clusters do Autopilot. Apenas o âmbito do cluster é suportado. Se precisar de resolver nomes de serviços sem interface gráfica em execução em clusters do GKE Autopilot, tem de usar o âmbito da VPC aditivo.

• Só pode ativar o âmbito de VPC aditivo nos clusters do GKE Autopilot no momento da criação do cluster. Não é suportada a ativação ou a desativação do âmbito da VPC aditivo em clusters do Autopilot do GKE existentes.

• A criação de clusters de âmbito de VPC aditivos em projetos de serviço de redes de VPC partilhadas não é suportada.

• O Cloud DNS para GKE não está disponível para o Assured Workload com um regime de conformidade IL4. O kube-dns é forçado nesses ambientes regulamentados.

• As alterações manuais às zonas de DNS privado geridas não são suportadas e são substituídas pelo controlador do Cloud DNS. As modificações aos registos de DNS nessas zonas não persistem quando o controlador é reiniciado.

• Depois de ativar o Cloud DNS para GKE num cluster, o kube-dns continua a ser executado no cluster. Pode desativar o kube-dns reduzindo a implementação e o escalador automático do kube-dns para zero.

• Não pode alterar o âmbito do DNS num cluster depois de definir o âmbito com a flag --cluster-dns-scope. Se precisar de alterar o âmbito do DNS, recrie o cluster com um âmbito do DNS diferente.

• Aplicam-se limitações dos recursos do CloudDNS. Em particular, é possível associar, no máximo, uma zona de política de resposta a uma rede VPC de cada vez. Para os âmbitos de VPC e VPC aditiva, a criação do cluster falha se já existir uma zona de política de resposta que não siga a convenção de nomenclatura associada à rede VPC do cluster.

• Os domínios stub personalizados e as configurações do servidor DNS a montante aplicam-se às configurações de DNS de pods e nós. Os pods que usam a rede do anfitrião ou os processos que são executados diretamente no anfitrião também usam o domínio stub e as configurações do servidor de nomes a montante. Esta opção só é suportada no Standard.

• Os domínios stub personalizados e os servidores de nomes a montante configurados através do Configmap kube-dns são aplicados automaticamente ao Cloud DNS para o DNS ao nível do cluster. O DNS de âmbito da VPC ignora o ConfigMap kube-dns e tem de aplicar estas configurações diretamente no Cloud DNS. Esta opção só é suportada no Standard.

• Não existe um caminho de migração de kube-dns para o âmbito da VPC. A operação é disruptiva. Recrie o cluster quando mudar de kube-dns para o âmbito da VPC ou vice-versa.

• Para o âmbito da VPC, o intervalo de endereços IP secundários para os serviços não pode ser partilhado com outros clusters nessa sub-rede.

• Para o âmbito da VPC, a política de resposta associada a um registo PTR é anexada à rede VPC. Se existirem outras políticas de resposta associadas à rede de cluster, a resolução do registo PTR falha para os endereços IP do serviço Kubernetes.

• Se tentar criar um serviço sem interface com um número de pods que exceda a quota permitida, o Cloud DNS não cria conjuntos de registos nem registos para o serviço.

• Os nomes de serviços e portas estão limitados a 62 carateres, embora as etiquetas DNS tenham um limite máximo de 63 carateres. Isto deve-se ao facto de o GKE adicionar um prefixo de sublinhado aos registos de DNS.

Quotas

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

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

Limites de recursos

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

Para saber como os registos de DNS são criados para o Kubernetes, consulte o artigo Descoberta de serviços baseada em DNS do Kubernetes.

Antes de começar

Antes de começar, certifique-se de que realizou as seguintes tarefas:

• Ative a API Google Kubernetes Engine.
Ative a API Google Kubernetes Engine
• Se quiser usar a CLI gcloud para esta tarefa, instale-a e, em seguida, inicialize-a. Se instalou anteriormente a CLI gcloud, execute o comando gcloud components update para obter a versão mais recente. As versões anteriores da CLI gcloud podem não suportar a execução dos comandos neste documento.

• Ative a API Cloud DNS no seu projeto:

  Ative a Cloud DNS API

Ativar DNS ao nível do cluster

No DNS ao nível do cluster, apenas os nós em execução no cluster do GKE podem resolver nomes de serviços, e os nomes de serviços não entram em conflito entre clusters. Este comportamento é igual ao kube-dns nos clusters do GKE, o que significa que pode migrar clusters do kube-dns para o âmbito do cluster do Cloud DNS sem tempo de inatividade nem alterações às suas aplicações.

O diagrama seguinte mostra como o Cloud DNS cria uma zona DNS privada para um cluster do GKE. Apenas os processos e os pods executados nos nós no cluster podem resolver os registos DNS do cluster, porque apenas os nós estão no âmbito do DNS.

Ative o DNS ao nível do cluster num novo cluster

Cluster do GKE Autopilot

Os novos clusters do Autopilot na versão 1.25.9-gke.400, 1.26.4-gke.500 ou posterior usam o âmbito do cluster do Cloud DNS por predefinição.

Cluster padrão do GKE

Pode criar um cluster padrão do GKE com o âmbito do cluster do Cloud DNS ativado através da CLI gcloud ou da Cloud de Confiance consola:

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

Ative o DNS ao nível do cluster num cluster existente

Cluster do GKE Autopilot

Não pode migrar um cluster do GKE Autopilot existente de kube-dns para o âmbito do cluster do Cloud DNS. Para ativar o âmbito do 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 padrão do GKE

Pode migrar um cluster padrão do GKE existente de kube-dns para o âmbito do cluster do Cloud DNS através da CLI gcloud ou da consola num cluster padrão do GKE.Cloud de Confiance

Quando migra um cluster existente, os nós no cluster não usam o Cloud DNS como fornecedor de DNS até recriar os nós.

Depois de ativar o Cloud DNS para um cluster, as definições só se aplicam se atualizar os conjuntos de nós existentes ou adicionar novos conjuntos de nós ao cluster. Quando atualiza um node pool, os nós são recriados.

Também pode migrar clusters com aplicações em execução sem interromper a comunicação do cluster ativando o Cloud DNS como fornecedor de DNS em cada conjunto de nós separadamente. Um subconjunto dos nós está operacional em todos os momentos, porque alguns conjuntos de nós usam o kube-dns e alguns conjuntos de nós usam o Cloud DNS.

Nos passos seguintes, ativa o Cloud DNS para um cluster e, em seguida, atualiza os pools de nós. A atualização dos node pools recria os nós. Em seguida, os nós usam o Cloud DNS para a resolução de DNS em vez do kube-dns.

Ative o âmbito de VPC aditivo do Cloud DNS

Esta secção descreve os passos para ativar ou desativar o âmbito da VPC aditivo do Cloud DNS, como um suplemento ao âmbito do cluster do Cloud DNS.

Ative o âmbito de VPC aditivo do Cloud DNS num novo cluster

Pode ativar o DNS ao nível da VPC num novo cluster do GKE usando a CLI gcloud ou a Cloud de Confiance consola.

Para o Autopilot

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

Substitua o seguinte:

• CLUSTER_NAME: o nome do cluster.
• UNIQUE_CLUSTER_DOMAIN: o nome de um domínio. Tem de garantir que este nome é exclusivo na VPC porque o GKE não confirma este valor. Não pode alterar este valor depois de o definir. Não pode usar um domínio que termine em ".local", caso contrário, pode ter falhas de resolução de DNS.

Para o Standard

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

A flag --cluster-dns-scope=cluster é opcional porque cluster é o valor predefinido.

Substitua o seguinte:

• CLUSTER_NAME: o nome do cluster.
• UNIQUE_CLUSTER_DOMAIN: o nome de um domínio. Tem de garantir que este nome é exclusivo na VPC porque o GKE não confirma este valor. Não pode alterar este valor depois de o definir. Não pode usar um domínio que termine em ".local", caso contrário, pode ter falhas de resolução de DNS.

Ative o âmbito de VPC aditivo do Cloud DNS num cluster existente

Para ativar o âmbito de VPC aditivo do Cloud DNS num cluster existente, primeiro, ative o Cloud DNS para um cluster e, em seguida, atualize os seus pools de nós. A atualização dos node pools recria os nós. Em seguida, os nós usam o Cloud DNS para a resolução de DNS em vez do kube-dns.

Para ativar o âmbito da VPC aditivo do Cloud DNS num cluster existente:

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

Substitua o seguinte:

• CLUSTER_NAME: o nome do cluster.
• UNIQUE_CLUSTER_DOMAIN: o nome de um domínio. Tem de garantir que este nome é exclusivo na VPC porque o GKE não confirma este valor. Não pode alterar este valor depois de definido. Não pode usar um domínio que termine em ".local", caso contrário, pode ter falhas de resolução de DNS.
• COMPUTE_LOCATION: a localização do Compute Engine para o cluster.

Ative o DNS ao nível da VPC

No DNS ao nível da VPC, os nomes DNS de um cluster são resolvidos em toda a VPC. Qualquer cliente na VPC pode resolver registos DNS do cluster.

O DNS com âmbito de VPC permite os seguintes exemplos de utilização:

• Descoberta de serviços sem interface para clientes não GKE na mesma VPC.
• Resolução de serviços do GKE a partir de clientes no local ou na nuvem de terceiros. Para mais informações, consulte a Política de Servidores de Entrada.
• Resolução de serviços em que um cliente pode decidir com que cluster quer comunicar através do domínio DNS do cluster personalizado.

No diagrama seguinte, dois clusters do GKE usam o DNS ao nível da VPC na mesma VPC. Ambos os clusters têm um domínio DNS personalizado, .cluster1 e .cluster2, em vez do domínio .cluster.local predefinido. Uma VM comunica com o serviço de back-end sem interface através da resolução de backend.default.svc.cluster1. O Cloud DNS resolve o serviço sem cabeça para os IPs dos pods individuais no serviço, e a VM comunica diretamente com os endereços IP dos pods.

Também pode realizar este tipo de resolução a partir de outras redes quando estiver ligada à VPC através do Cloud Interconnect ou do Cloud VPN. As políticas do servidor DNS permitem que os clientes de redes ligadas à VPC resolvam nomes no Cloud DNS, o que inclui os serviços GKE se o cluster estiver a usar o DNS de âmbito da VPC.

Ative o DNS com âmbito de VPC num cluster existente

A migração só é suportada no GKE Standard e não no GKE Autopilot.

Cluster do GKE Autopilot

Não pode migrar um cluster do GKE Autopilot do kube-dns para o âmbito da VPC do Cloud DNS.

Cluster padrão do GKE

Pode migrar um cluster do GKE existente do kube-dns para o âmbito da VPC do Cloud DNS através da CLI gcloud ou da Cloud de Confiance consola.

Depois de ativar o Cloud DNS para um cluster, as definições só se aplicam se atualizar os conjuntos de nós existentes ou adicionar novos conjuntos de nós ao cluster. Quando atualiza um node pool, os nós são recriados.

Nos passos seguintes, ativa o Cloud DNS para um cluster e, em seguida, atualiza os pools de nós. A atualização dos node pools recria os nós. Em seguida, os nós usam o Cloud DNS para a resolução de DNS em vez do kube-dns.

Valide o Cloud DNS

Verifique se o Cloud DNS para GKE está a funcionar corretamente para o seu cluster:

1. Verifique se os seus nós estão a usar o Cloud DNS ligando-se a um pod num 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, o resultado é semelhante ao seguinte:

   Cluster do GKE Autopilot

   nameserver 169.254.20.10
   

   Uma vez que o NodeLocal DNSCache está ativado por predefinição no GKE Autopilot, o pod está a usar o NodeLocal DNSCache.

   Apenas quando a cache local não tem uma entrada para o nome que está a ser procurado, o NodeLocal DNSCache encaminha o pedido para o Cloud DNS.

   Cluster padrão do GKE

   nameserver 169.254.169.254
   

   O pod está a usar 169.254.169.254 como nameserver, que é o endereço IP do servidor de metadados onde o plano de dados do Cloud DNS escuta pedidos na porta 53. Os nós deixam de usar o endereço do serviço kube-dns para a resolução de DNS, e toda a resolução de DNS ocorre no nó local.

   Se o resultado for um endereço IP semelhante a 10.x.y.10, então o pod está a usar o kube-dns. Consulte a secção Resolução de problemas para compreender por que motivo o seu pod continua a usar o kube-dns.

   Se o resultado for 169.254.20.10, significa que ativou a opção NodeLocal DNSCache no cluster. O pod está a usar a opção NodeLocal DNSCache.

2. Implemente uma aplicação de exemplo no seu cluster:

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

3. Exponha a aplicação de exemplo com um serviço:

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

4. Verifique se o serviço foi implementado com êxito:

   kubectl get svc dns-test-svc
   

   O resultado é semelhante ao seguinte:

   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 seu cluster. Neste exemplo, o endereço IP virtual é 10.47.255.11.

5. Verifique se o nome do serviço foi criado como um registo na zona de DNS privado do 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 DNS gerida.

   O resultado é semelhante ao seguinte:

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

Desative o Cloud DNS para GKE

Cluster do GKE Autopilot

Não pode desativar o Cloud DNS num cluster do GKE Autopilot criado com o Cloud DNS por predefinição. Consulte os requisitos para mais informações sobre os clusters do GKE Autopilot que usam o Cloud DNS por predefinição.

Cluster padrão do GKE

Pode desativar o âmbito do cluster do Cloud DNS através da CLI gcloud ou da Cloud de Confiance consola num cluster padrão do GKE.

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

Depois de desativar o Cloud DNS para clusters padrão, atualize todos os conjuntos de nós associados aos seus clusters. Em alternativa, pode criar um novo conjunto de nós e agendar a sua carga de trabalho aí. Se não atualizar os conjuntos de nós, o espaço de nomes DNS continua a apontar para o Cloud DNS e não para o kube-dns.

Desative o âmbito da VPC aditivo do Cloud DNS

Quando desativa o âmbito de VPC aditivo do Cloud DNS para o cluster, apenas os registos de DNS nas zonas privadas anexadas à rede VPC são eliminados. Os registos nas zonas de DNS privado para o cluster do GKE permanecem, geridos pelo Cloud DNS para o GKE, até que o serviço sem cabeça seja eliminado do cluster.

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

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

Substitua CLUSTER_NAME pelo nome do cluster.

Isto mantém o cluster com o âmbito do cluster do Cloud DNS ativado para fornecer resolução de DNS a partir do cluster.

Limpar

Depois de concluir os exercícios nesta página, siga estes passos para remover recursos e evitar encargos indesejados na sua conta:

1. Elimine o serviço:

   kubectl delete service dns-test-svc
   

2. Elimine o Pod:

   kubectl delete Pod dns-test
   

3. Também pode eliminar o cluster.

Use o Cloud DNS com a VPC partilhada

O Cloud DNS para GKE suporta a VPC partilhada para o âmbito da VPC e do cluster.

O controlador do GKE cria uma zona privada gerida no mesmo projeto que o cluster do GKE.

A conta de serviço do GKE para o cluster do GKE não requer a gestão de identidade e acesso (IAM) para o DNS fora do seu próprio projeto, porque a zona gerida 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, pode criar clusters em vários projetos de serviço que referenciam uma VPC no mesmo projeto anfitrião.

Se já tiver clusters a usar a VPC partilhada e o âmbito da VPC do Cloud DNS, tem de os migrar manualmente com os seguintes passos:

• Atualize os clusters existentes com a VPC partilhada ativada para a versão do GKE 1.22.3-gke.700+ ou 1.21.6-gke.1500+.
• Migre a política de resposta do projeto de serviço para o projeto anfitrião. Só tem de fazer esta migração uma vez por rede VPC partilhada.

Pode migrar a sua política de respostas através da Cloud de Confiance consola.

Execute os seguintes passos no seu projeto de serviço:

1. Aceda à página Zonas do Cloud DNS.

   Aceda às zonas do Cloud DNS

2. Clique no separador Zonas de políticas de resposta.

3. Clique na política de resposta da sua rede de VPC. Pode 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 no separador Em utilização por.

5. Junto ao nome do projeto anfitrião, clique em delete para remover a associação de rede.

6. Clique no separador Regras da política de resposta.

7. Selecionar todas as entradas na tabela.

8. Clique em Remover regras da política de respostas.

9. Clique em delete Eliminar política de respostas.

Depois de eliminar a política de resposta, o controlador de DNS cria automaticamente a política de resposta no projeto de anfitrião. Os clusters de outros projetos de serviço partilham esta política de resposta.

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

O Cloud DNS para GKE suporta domínios stub personalizados e servidores de nomes upstream configurados através do ConfigMap kube-dns. Este apoio técnico só está disponível para clusters padrão do GKE.

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

Extensões de especificações

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

Portas com nome

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

Registos de DNS adicionais criados pelo Cloud DNS

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

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

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

Problemas conhecidos

O Terraform planeia recriar o cluster do Autopilot devido à alteração dns_config

Se usar o terraform-provider-google ou o terraform-provider-google-beta, pode ter um problema em que o Terraform tenta recriar um cluster do Autopilot. Este erro ocorre porque os clusters do Autopilot criados recentemente com a versão 1.25.9-gke.400, 1.26.4-gke.500, 1.27.1-gke.400 ou posterior usam o Cloud DNS como fornecedor de DNS em vez do kube-dns.

Este problema foi resolvido na versão 4.80.0 do fornecedor Terraform do Cloud de Confiance by S3NS.

Se não conseguir atualizar a versão de terraform-provider-google ou terraform-provider-google-beta, pode adicionar lifecycle.ignore_changes ao recurso para garantir que google_container_cluster ignora as alterações a dns_config:

  lifecycle {
    ignore_changes = [
      dns_config,
    ]
  }

Falha na resolução de DNS após a migração do kube-dns para o Cloud DNS com o NodeLocal DNSCache ativado

Esta secção descreve um problema conhecido presente nos clusters do GKE no Cloud DNS com NodeLocal DNSCache no âmbito do cluster.

Depois de migrar do kube-DNS para o Cloud DNS com a NodeLocal DNSCache ativada no cluster, o cluster pode ter erros de resolução intermitentes.

Ao usar o kube-dns com o NodeLocal DNSCache ativado no cluster, o NodeLocal DNSCache é configurado para ouvir em ambos os endereços (endereço do NodeLocal DNSCache e endereço do kube-dns).

Para verificar o estado do NodeLocal DNSCache, execute o seguinte comando:

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

O resultado é semelhante ao seguinte:

    bind 169.254.20.10 x.x.x.10
    bind 169.254.20.10 x.x.x.10

Se o Dataplane V2 estiver ativado no cluster enquanto usa o kube-dns, o NodeLocal DNSCache é executado numa rede isolada e está configurado para ouvir todos os endereços IP dos pods (0.0.0.0). O resultado é semelhante ao seguinte:

    bind 0.0.0.0
    bind 0.0.0.0

Depois de atualizar o cluster para o Cloud DNS, a configuração do NodeLocal DNSCache é alterada. Verifique o NodeLocal DNSCache:

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

O resultado é semelhante ao seguinte:

    bind 169.254.20.10
    bind 169.254.20.10

O fluxo de trabalho seguinte explica as entradas no ficheiro resolv.conf durante a migração e a recriação de nós:

Antes da migração

• Os pods têm o resolv.conf configurado para o kube-dns-IP (ou seja, x.x.x.10).
• Os pods node-local-cache intercetam pedidos DNS de pods e ouvem o seguinte:
  • (DPv1) ambos os endereços (bind 169.254.20.10 x.x.x.10).
  • (DPv2) todos os endereços IP de pods (bind 0.0.0.0).
• O NodeLocal DNSCache funciona como uma cache e é exercida pouca pressão sobre os pods kube-dns.

Após a migração

• Depois de o plano de controlo ser atualizado para usar o Cloud DNS, os pods continuam a ter o resolv.conf configurado para o IP kube-dns (ou seja, x.x.x.10). Esta configuração permanece porque o GKE requer a recriação de nós para usar 169.254.20.10 .A configuração do Cloud DNS requer 169.254.20.10
• Os pods node-local-cache ouvem apenas o endereço NodeLocal DNSCache (bind 169.254.20.10). O pedido não é encaminhado para os pods de cache local do nó.
• Todos os pedidos dos pods são enviados diretamente para os pods kube-dns. Esta configuração gera um tráfego elevado nos pods.

Após a recriação de nós ou a atualização do node pool

• Os pods têm o endereço IP do NodeLocal DNSCache (169.254.20.10) configurado como resolv.conf.
• Os pods node-local-cache ouvem apenas no endereço NodeLocal DNSCache (bind 169.254.20.10) e recebem pedidos DNS de pods neste endereço IP.

Quando os conjuntos de nós usam o IP kube-dns em resolv.conf antes da recriação do conjunto de nós, um aumento no tráfego de consultas DNS também aumenta o tráfego nos pods kube-dns, o que provoca falhas intermitentes de pedidos DNS. Para minimizar os erros, tem de planear esta migração durante os períodos de inatividade.

Resolução de problemas

Para obter informações sobre a resolução de problemas do Cloud DNS, consulte as seguintes páginas:

• Para obter aconselhamento sobre o Cloud DNS no GKE, consulte o artigo Resolva problemas do Cloud DNS no GKE.
• Para obter conselhos específicos sobre o Cloud DNS, consulte o artigo Resolva problemas do Cloud DNS.
• Para obter aconselhamento geral sobre o diagnóstico de problemas de DNS do Kubernetes, consulte o artigo Depurar a resolução de DNS.

O que se segue?

• Leia uma vista geral de como o GKE fornece DNS gerido.
• Leia o artigo DNS para serviços e pods para uma vista geral de como o DNS é usado em clusters do Kubernetes.
• Saiba mais sobre os âmbitos e as hierarquias no Cloud DNS.
• Saiba como ativar e desativar o registo para zonas geridas privadas.