Resolva problemas do Cloud DNS no GKE

Se os seus pods não conseguirem estabelecer ligação a serviços e o cluster do Google Kubernetes Engine (GKE) usar o Cloud DNS como fornecedor de DNS, pode encontrar erros como dial tcp: i/o timeout ou no such host. Estes erros indicam frequentemente problemas com a configuração do Cloud DNS, como zonas privadas configuradas incorretamente ou um âmbito do Cloud DNS incorreto.

Use esta página para diagnosticar e resolver problemas comuns relacionados com a utilização do serviço Cloud DNS gerido com o GKE, o que ajuda a garantir uma resolução de DNS fiável para as suas cargas de trabalho.

Estas informações são importantes para os administradores e os operadores da plataforma, bem como para os especialistas em rede que configuram e gerem a integração entre o GKE e o Cloud DNS. Também é útil para os programadores de aplicações cujas aplicações estão a ter problemas de deteção de serviços. Para mais informações sobre as funções comuns e as tarefas de exemplo a que fazemos referência no conteúdo, consulte o artigo Funções e tarefas comuns do utilizador do GKE. Trusted Cloud by S3NS

Identifique a origem dos problemas de DNS no Cloud DNS

As secções seguintes ajudam a diagnosticar o motivo pelo qual o Cloud DNS está a ter dificuldade em resolver consultas.

Valide as definições básicas

Se o seu Pod não conseguir resolver as pesquisas de DNS, certifique-se de que o Cloud DNS está configurado da forma que pretende. Esta secção ajuda a verificar se está a usar o Cloud DNS, confirmar a existência de uma zona DNS privada para o cluster do GKE e garantir a precisão dos registos de DNS para o serviço de destino.

Para validar estas definições, conclua os seguintes comandos:

  1. Verifique que servidor DNS o seu Pod está a usar:

    kubectl exec -it POD_NAME -- cat /etc/resolv.conf | grep nameserver

    Substitua POD_NAME pelo nome do pod que está a ter problemas com a resolução de DNS.

    Se estiver a usar o Cloud DNS, a saída é a seguinte:

    nameserver 169.254.169.254

    Se vir qualquer outro valor, significa que não está a usar o Cloud DNS. Verifique se o Cloud DNS foi ativado corretamente.

  2. Verifique se as zonas geridas existem:

    gcloud dns managed-zones list --format list

    O resultado é semelhante ao seguinte:

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

    Esta saída inclui os seguintes valores:

    • CLUSTER_DOMAIN: o sufixo de domínio DNS que foi atribuído automaticamente ao seu cluster.
    • PROJECT_ID: o ID do seu projeto.
    • CLUSTER_NAME: o nome do cluster com a zona privada.

    Neste resultado, o valor no campo name mostra que Trusted Cloud criou uma zona denominada gke-CLUSTER_NAME-aa94c1f9-dns.

    Se não vir uma zona gerida, significa que não foi criada uma zona privada para o seu cluster ou que a autenticação pode não ter sido feita corretamente. Para resolver problemas, consulte o artigo Zonas privadas na documentação do Cloud DNS.

  3. Valide os registos DNS do seu serviço:

    gcloud dns record-sets list --zone ZONE_NAME | grep SERVICE_NAME

    Substitua o seguinte:

    • ZONE_NAME: o nome da zona privada.
    • SERVICE_NAME: o nome do serviço.

    O resultado é semelhante ao seguinte:

    dns-test.default.svc.cluster.local.                A     30     10.47.255.11

    Este resultado mostra que o Cloud DNS contém um registo A para o domínio dns-test.default.svc.cluster.local. e o endereço IP do seu cluster é 10.47.255.11.

    Se os registos parecerem incorretos, consulte o artigo Corrija um conjunto de registos de recursos na documentação do Cloud DNS para os atualizar.

Valide as políticas de respostas

Verifique se as políticas de resposta existem e têm o nome correto:

  1. Veja uma lista de todas as suas políticas de resposta:

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

    O resultado é semelhante ao seguinte:

    RESPONSE_POLICY_NAME          DESCRIPTION
gke-CLUSTER_NAME-52c8f518-rp  Response Policy for GKE cluster "CLUSTER_NAME" with cluster suffix "cluster.local." in project "gke-dev" with scope "CLUSTER_SCOPE".

    Neste resultado, gke-CLUSTER_NAME-52c8f518-rp mostra que Trusted Cloud criou uma zona privada denominada gke-CLUSTER_NAME-aa94c1f9-rp. As políticas de resposta que oTrusted Cloud cria têm o prefixo gke-.

  2. Veja as políticas de resposta numa zona privada específica:

    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 privada com problemas.

    O resultado é semelhante ao seguinte:

    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 primeira coluna mostra o endereço IP ou o padrão do nome de domínio com o qual a regra corresponde. A segunda coluna é o nome do anfitrião associado ao endereço IP.

Se detetar problemas no resultado destes comandos, consulte o artigo atualize uma regra de política de resposta na documentação do Cloud DNS.

Investigue com registos, painéis de controlo e métricas

O Cloud DNS inclui várias opções de registo e monitorização para ajudar a investigar mais detalhadamente os seus problemas de DNS:

Verifique se existem novos registos

Reveja os registos para ver se foram criados novos registos na zona privada do Cloud DNS gerido. Isto pode ser útil se, de repente, tiver resoluções de DNS com falhas no cluster.

Para verificar se existem novos registos, conclua os seguintes passos:

  1. Na Trusted Cloud consola, aceda à página Explorador de registos.

    Aceda ao Explorador de registos

  2. No painel de consultas, introduza a seguinte consulta:

    resource.type="dns_managed_zone"
protoPayload.request.change.additions.name="headless-svc-stateful.default.svc.cluster.local."
protoPayload.methodName="dns.changes.create"

  3. Clique em Executar consulta.

  4. Reveja o resultado. Se encontrar alterações que correspondam ao momento em que reparou nos erros pela primeira vez, considere revertê-las.

Valide servidores de nomes e domínios stub personalizados

Se estiver a usar um cluster padrão do GKE com um domínio stub personalizado ou um servidor de nomes a montante, reveja o ConfigMap e verifique se os valores estão corretos.

O Cloud DNS traduz os valores stubDomains e upstreamNameservers em zonas de encaminhamento do Cloud DNS. A Google gere estes recursos. Por isso, se detetar erros, contacte o apoio ao cliente do Google Cloud para receber assistência.

Contacte o Cloud Customer Care

Se seguiu as secções anteriores, mas ainda não consegue diagnosticar a causa do problema, contacte o apoio ao cliente do Google Cloud.

Resolva erros específicos

Se tiver tido um erro ou um problema específico, use as sugestões nas secções seguintes.

Problema: não é possível resolver o serviço do cluster do GKE a partir de uma VM do Compute Engine

Se não conseguir resolver um serviço de cluster do GKE a partir de uma VM do Compute Engine, verifique o âmbito do Cloud DNS do cluster.

O âmbito que usa com o Cloud DNS determina os recursos que podem ser resolvidos:

  • Âmbito do cluster: a resolução de DNS está restrita a recursos no interior do cluster do Kubernetes (pods e serviços). Esta é a predefinição e é adequada quando não precisa de resolver recursos externos fora do cluster do Kubernetes ou da nuvem privada virtual (VPC) do GKE.

  • Âmbito da VPC: a resolução de DNS estende-se a toda a VPC, incluindo recursos como VMs do Compute Engine. Isto permite que o cluster resolva registos DNS internos para recursos fora do cluster do GKE, mas dentro da mesma VPC, como VMs. Trusted Cloud by S3NS

Para validar o âmbito do Cloud DNS do seu cluster, conclua os seguintes passos:

  1. Na Trusted Cloud consola, aceda à página Clusters do Kubernetes.

    Aceda aos clusters do Kubernetes

  2. Clique no nome do cluster que está a ter problemas com o DNS.

  3. Na secção Rede de clusters da página de detalhes do cluster, reveja as informações na linha Fornecedor de DNS.

  4. Se vir Cloud DNS (âmbito do cluster), está a usar o âmbito do cluster. Para alterar o âmbito do DNS, recrie o cluster com o âmbito do DNS adequado.

Problema: os pods continuam a usar o kube-dns depois de o Cloud DNS estar ativado

Se os seus pods usarem o kube-dns mesmo depois de o Cloud DNS ser ativado num cluster existente, certifique-se de que atualizou ou recriou os seus conjuntos de nós depois de ativar o Cloud DNS no cluster. Até este passo estar concluído, os pods continuam a usar o kube-dns.

Problema: não é possível atualizar um cluster existente nem criar um cluster com o Cloud DNS ativado

Certifique-se de que está a usar a versão correta. O Cloud DNS para GKE requer a versão 1.19 ou posterior do GKE para clusters que usam o âmbito 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 âmbito do cluster.

Problema: as procuras de DNS em nós falham após a ativação do Cloud DNS num cluster

Se ativar o Cloud DNS ao nível do cluster num cluster do GKE que tenha domínios stub personalizados ou servidores de nomes a montante, a configuração personalizada aplica-se aos nós e aos pods no cluster, uma vez que o Cloud DNS não consegue distinguir entre pedidos DNS de pods e de nós. As pesquisas DNS nos nós podem falhar se o servidor upstream personalizado não conseguir resolver as consultas.

Problema: não é possível atualizar nem criar um cluster com o âmbito de VPC aditivo do Cloud DNS ativado

Certifique-se de que está a usar a versão correta. O âmbito de VPC aditivo do Cloud DNS requer a versão 1.28 ou posterior do GKE.

Erro: Cloud DNS desativado

O seguinte evento ocorre quando a API Cloud DNS está desativada:

Warning   FailedPrecondition        service/default-http-backend
Failed to send requests to Cloud DNS: Cloud DNS API Disabled. Please enable the Cloud DNS API in your project PROJECT_NAME: Cloud DNS API has not been used in project PROJECT_NUMBER before or it is disabled. Enable it by visiting https://console.developers.google.com/apis/api/dns.googleapis.com/overview?project=PROJECT_NUMBER then retry. If you enabled this API recently, wait a few minutes for the action to propagate to our systems and retry.

Este erro ocorre porque a API Cloud DNS não está ativada por predefinição. Tem de ativar a API Cloud DNS manualmente.

Para resolver o problema, ative a API Cloud DNS.

Erro: falha ao enviar pedidos para o Cloud DNS: limite de taxa da API excedido.

O evento seguinte ocorre quando um projeto excede uma quota ou um limite do Cloud DNS:

kube-system   27s         Warning   InsufficientQuota
managedzone/gke-cluster-quota-ee1bd2ca-dns     Failed to send requests to Cloud DNS: API rate limit exceeded. Contact Google Cloud support team to request a quota increase for your project PROJECT_NAME: Quota exceeded for quota metric 'Write requests' and limit 'Write limit for a minute for a region' of service 'dns.googleapis.com' for consumer 'project_number:PROJECT_NUMBER.

Para resolver este problema, reveja as quotas do Cloud DNS e os limites e as quotas do Compute Engine. Pode aumentar a quota através da Trusted Cloud consola.

Erro: não foi possível enviar pedidos para o Cloud DNS devido a um erro anterior

O seguinte evento ocorre quando os erros causam falhas em cascata:

kube-system   27s         Warning   InsufficientQuota
managedzone/gke-cluster-quota-ee1bd2ca-dns     Failed to send requests to Cloud DNS: API rate limit exceeded. Contact Google Cloud support team to request a quota increase for your project PROJECT_NAME: Quota exceeded for quota metric 'Write requests' and limit 'Write limit for a minute for a region' of service 'dns.googleapis.com' for consumer 'project_number:PROJECT_NUMBER.
kube-system   27s         Warning   FailedPrecondition               service/default-http-backend                         Failed to send requests to Cloud DNS due to a previous error. Please check the cluster events.

Para resolver este problema, verifique os eventos de cluster para encontrar a origem do erro original e siga as instruções para resolver esse problema principal.

No exemplo anterior, o erro InsufficientQuota para a zona gerida acionou falhas em cascata. O segundo erro para FailedPrecondition indica que ocorreu um erro anterior, que foi o problema inicial de quota insuficiente. Para resolver este problema de exemplo, deve seguir as orientações relativas ao erro de quota do Cloud DNS.

Erro: falha ao associar a política de resposta

O seguinte evento ocorre quando uma política de resposta está associada à rede do cluster e o Cloud DNS para GKE tenta associar uma política de resposta à rede:

kube-system   9s          Warning   FailedPrecondition               responsepolicy/gke-2949673445-rp
Failed to bind response policy gke-2949673445-rp to test. Please verify that another Response Policy is not already associated with the network: Network 'https://www.googleapis.com/compute/v1/projects/PROJECT_NAME/global/networks/NETWORK_NAME' cannot be bound to this response policy because it is already bound to another response policy.
kube-system   9s          Warning   FailedPrecondition               service/kube-dns
Failed to send requests to Cloud DNS due to a previous error. Please check the cluster events.

Para resolver o problema, conclua os seguintes passos:

  1. Obtenha a política de respostas associada à rede:

    gcloud dns response-policies list --filter='networks.networkUrl: NETWORK_URL'

    Substitua NETWORK_URL pelo URL da rede do erro, como https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/networks/NETWORK_NAME.

    Se o resultado estiver vazio, a política de resposta pode não estar no mesmo projeto. Avance para o passo seguinte para pesquisar a política de respostas.

    Se o resultado for semelhante ao seguinte, avance para o passo 4 para eliminar a política de resposta.

    [
   {
      "description": "Response Policy for GKE cluster \"CLUSTER_NAME\" with cluster suffix \"cluster.local.\" in project \"PROJECT_ID\" with scope \"CLUSTER_SCOPE\".",
      ...
      "kind": "dns#responsePolicy",
      "responsePolicyName": "gke-CLUSTER_NAME-POLICY_ID-rp"
   }
]

  2. Obtenha uma lista de projetos com a autorização dns.networks.bindDNSResponsePolicy através do analisador de políticas de IAM.

  3. Verifique se cada projeto tem a política de resposta associada à rede:

    gcloud dns response-policies list --filter='networks.networkUrl:NETWORK_URL' \
    --project=PROJECT_NAME

  4. Elimine a política de respostas.

Erro: configuração inválida especificada no kube-dns

O evento seguinte ocorre quando aplica um ConfigMap kube-dns personalizado que não é válido para o Cloud DNS para GKE:

kube-system   49s         Warning   FailedValidation                 configmap/kube-dns
Invalid configuration specified in kube-dns: error parsing stubDomains for ConfigMap kube-dns: dnsServer [8.8.8.256] validation: IP address "8.8.8.256" invalid

Para resolver este problema, reveja os detalhes no erro da parte inválida do ConfigMap. No exemplo anterior, 8.8.8.256 não é um endereço IP válido.

O que se segue?