Résoudre les problèmes liés à Cloud DNS dans GKE

Cette page explique comment résoudre les problèmes liés à Cloud DNS dans Google Kubernetes Engine (GKE).

Identifier la source des problèmes DNS dans Cloud DNS

Les erreurs telles que dial tcp: i/o timeout, no such host ou Could not resolve host signalent souvent des problèmes liés à la capacité de Cloud DNS à résoudre les requêtes.

Si l'un de ces messages d'erreur s'affiche, mais que vous ne savez pas pourquoi, consultez les sections suivantes pour trouver la cause. Les sections sont organisées de manière à commencer par les étapes les plus susceptibles de vous aider. Essayez donc chaque section dans l'ordre.

Vérifier les paramètres de base

Si votre pod ne parvient pas à résoudre les résolutions DNS, assurez-vous que Cloud DNS est configuré comme vous le souhaitez. Cette section vous aide à vérifier si vous utilisez Cloud DNS, à confirmer l'existence d'une zone DNS privée pour le cluster GKE et à vous assurer de l'exactitude des enregistrements DNS pour le service cible.

Pour vérifier ces paramètres, exécutez les commandes suivantes:

  1. Vérifiez le serveur DNS utilisé par votre pod:

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

    Remplacez POD_NAME par le nom du pod qui rencontre des problèmes de résolution DNS.

    Si vous utilisez Cloud DNS, la sortie est la suivante:

    nameserver 169.254.169.254

    Si une autre valeur s'affiche, vous n'utilisez pas Cloud DNS. Vérifiez que Cloud DNS a été correctement activé.

  2. Vérifiez que les zones gérées existent:

    gcloud dns managed-zones list --format list

    Le résultat ressemble à ce qui suit :

    - 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

    Ce résultat inclut les valeurs suivantes :

    • CLUSTER_DOMAIN: suffixe de domaine DNS attribué automatiquement à votre cluster.
    • PROJECT_ID : ID de votre projet.
    • CLUSTER_NAME: nom du cluster avec la zone privée.

    Dans cette sortie, la valeur du champ name indique queGoogle Cloud a créé une zone nommée gke-CLUSTER_NAME-aa94c1f9-dns.

    Si aucune zone gérée ne s'affiche, cela signifie qu'aucune zone privée n'a été créée pour votre cluster ou que vous n'êtes peut-être pas authentifié correctement. Pour résoudre le problème, consultez la section Zones privées dans la documentation de Cloud DNS.

  3. Vérifiez les enregistrements DNS de votre service:

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

    Remplacez les éléments suivants :

    • ZONE_NAME : nom de la zone privée.
    • SERVICE_NAME : nom du service.

    Le résultat ressemble à ce qui suit:

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

    Ce résultat indique que Cloud DNS contient un enregistrement A pour le domaine dns-test.default.svc.cluster.local. et que l'adresse IP de votre cluster est 10.47.255.11.

    Si les enregistrements semblent incorrects, consultez la section Mettre à jour un ensemble d'enregistrements de ressources dans la documentation Cloud DNS pour les modifier.

Vérifier les stratégies de réponse

Vérifiez que vos règles de réponse existent et sont correctement nommées:

  1. Affichez la liste de toutes vos stratégies de réponse:

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

    Le résultat ressemble à ce qui suit :

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

    Dans cette sortie, gke-CLUSTER_NAME-52c8f518-rp indique queGoogle Cloud a créé une zone privée nommée gke-CLUSTER_NAME-aa94c1f9-rp. Les règles de réponse créées parGoogle Cloud portent le préfixe gke-.

  2. Afficher les stratégies de réponse dans une zone privée spécifique:

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

    Remplacez ZONE_NAME par le nom de la zone privée présentant des problèmes.

    Le résultat ressemble à ce qui suit :

    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.

    La première colonne indique le format d'adresse IP ou de nom de domaine auquel la règle correspond. La deuxième colonne correspond au nom d'hôte associé à l'adresse IP.

Si vous remarquez des problèmes dans la sortie de ces commandes, consultez la section Mettre à jour une règle de stratégie de réponse dans la documentation Cloud DNS.

Effectuer des recherches à l'aide des journaux, des tableaux de bord et des métriques

Cloud DNS inclut plusieurs options de journalisation et de surveillance pour vous aider à examiner plus en détail vos problèmes DNS:

Rechercher de nouveaux enregistrements

Examinez les journaux pour voir si de nouveaux enregistrements ont été créés dans la zone privée Cloud DNS gérée. Cela peut être utile si vous rencontrez soudainement des échecs de résolution DNS dans le cluster.

Pour rechercher de nouveaux enregistrements, procédez comme suit:

  1. Dans la console Google Cloud , accédez à la page Explorateur de journaux.

    Accéder à l'explorateur de journaux

  2. Dans le volet de requête, saisissez la requête suivante:

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

  3. Cliquez sur Exécuter la requête.

  4. Examinez le résultat. Si vous trouvez des modifications qui correspondent à la date à laquelle vous avez remarqué les premières erreurs, envisagez de les annuler.

Valider les domaines de simulation et les serveurs de noms personnalisés

Si vous utilisez un cluster GKE Standard avec un domaine de bouchon personnalisé ou un serveur de noms en amont, examinez le ConfigMap et vérifiez que les valeurs sont correctes.

Cloud DNS traduit les valeurs stubDomains et upstreamNameservers en zones de transfert Cloud DNS. Google gère ces ressources. Si vous remarquez des erreurs, contactez le service client Cloud pour obtenir de l'aide.

Contacter Cloud Customer Care

Si vous avez suivi les sections précédentes, mais que vous ne parvenez toujours pas à diagnostiquer la cause du problème, contactez l'assistance Cloud Customer Care.

Résoudre des erreurs spécifiques

Si vous avez rencontré une erreur ou un problème spécifique, suivez les conseils des sections suivantes.

Problème: Impossible de résoudre le service de cluster GKE à partir d'une VM Compute Engine

Si vous ne parvenez pas à résoudre un service de cluster GKE à partir d'une VM Compute Engine, vérifiez le champ d'application Cloud DNS du cluster.

La portée que vous utilisez avec Cloud DNS détermine les ressources qui peuvent être résolues:

  • Étendue du cluster: la résolution DNS est limitée aux ressources du cluster Kubernetes (pods et services). Il s'agit du paramètre par défaut. Il est adapté lorsque vous n'avez pas besoin de résoudre des ressources externes en dehors du cluster Kubernetes ou du cloud privé virtuel (VPC) GKE.

  • Champ d'application du VPC: la résolution DNS s'étend à l'ensemble du VPC, y compris aux ressources telles que les VM Compute Engine. Cela permet au cluster de résoudre les enregistrements DNS internes pour les ressources situées en dehors du cluster GKE, mais dans le même VPC, comme les VM Google Cloud .

Pour vérifier la portée Cloud DNS de votre cluster, procédez comme suit:

  1. Dans la console Google Cloud , accédez à la page Clusters Kubernetes.

    Accéder à la page "Clusters Kubernetes"

  2. Cliquez sur le nom du cluster qui rencontre des problèmes avec le DNS.

  3. Dans la section Mise en réseau du cluster de la page d'informations du cluster, examinez les informations de la ligne Fournisseur DNS.

  4. Si Cloud DNS (champ d'application du cluster) s'affiche, vous utilisez le champ d'application du cluster. Pour modifier le champ d'application DNS, recréez le cluster avec le champ d'application DNS approprié.

Problème: les pods continuent d'utiliser kube-dns après l'activation de Cloud DNS

Si vos pods utilisent kube-dns même après l'activation de Cloud DNS sur un cluster existant, assurez-vous d'avoir mis à niveau ou recréé vos pools de nœuds après avoir activé Cloud DNS sur le cluster. Jusqu'à la fin de cette étape, les pods continuent à utiliser kube-dns.

Problème: impossible de mettre à jour un cluster existant ou de créer un cluster avec Cloud DNS activé

Vérifiez que vous utilisez la bonne version. Cloud DNS pour GKE nécessite la version 1.19 ou ultérieure de GKE pour les clusters utilisant le champ d'application VPC, ou GKE 1.24.7-gke.800, 1.25.3-gke.700 ou ultérieure pour les clusters utilisant le champ d'application de cluster.

Problème: les résolutions DNS sur les nœuds échouent après l'activation de Cloud DNS sur un cluster

Si vous activez Cloud DNS au niveau du cluster dans un cluster GKE comportant des serveurs de simulation personnalisés ou des serveurs de noms en amont, la configuration personnalisée s'applique à la fois aux nœuds et aux pods du cluster, car Cloud DNS ne peut pas faire la distinction entre les requêtes DNS de pod et de nœud. Les résolutions DNS sur les nœuds peuvent échouer si le serveur en amont personnalisé ne peut pas résoudre les requêtes.

Problème: impossible de mettre à jour ou de créer un cluster avec le champ d'application Cloud DNS additif à l'échelle du VPC activé

Assurez-vous d'utiliser la bonne version. Le champ d'application Cloud DNS additif à l'échelle du VPC nécessite la version 1.28 de GKE ou une version ultérieure.

Erreur: Cloud DNS désactivé

L'événement suivant se produit lorsque l'API Cloud DNS est désactivée :

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.

Cette erreur se produit, car l'API Cloud DNS n'est pas activée par défaut. Vous devez l'activer manuellement.

Pour résoudre le problème, activez l'API Cloud DNS.

Erreur: Échec de l'envoi de requêtes à Cloud DNS: limite de débit des API dépassée

L'événement suivant se produit lorsqu'un projet a dépassé un quota ou une limite 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.

Pour résoudre ce problème, vérifiez les quotas Cloud DNS et les quotas et limites de Compute Engine. Vous pouvez augmenter votre quota à l'aide de la console Google Cloud .

Erreur: Échec de l'envoi de requêtes à Cloud DNS en raison d'une erreur précédente

L'événement suivant se produit lorsque des erreurs entraînent des défaillances en cascade :

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.

Pour résoudre ce problème, recherchez la source de l'erreur d'origine dans les événements de cluster et suivez les instructions correspondantes.

Dans l'exemple précédent, l'erreur InsufficientQuota pour la zone gérée a déclenché des défaillances en cascade. La deuxième erreur pour FailedPrecondition indique qu'une erreur précédente s'est produite (problème de quota initial insuffisant). Pour résoudre cet exemple de problème, suivez les instructions concernant l'erreur de quota Cloud DNS.

Erreur: Échec de la liaison de la stratégie de réponse

L'événement suivant se produit lorsqu'une stratégie de réponse est liée au réseau du cluster et que Cloud DNS pour GKE tente de lier une stratégie de réponse au réseau :

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.

Pour résoudre ce problème, procédez comme suit :

  1. Obtenez la stratégie de réponse liée au réseau :

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

    Remplacez NETWORK_URL par l'URL du réseau obtenue à partir de l'erreur (par exemple, https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/networks/NETWORK_NAME).

    Si la sortie est vide, la règle de réponse ne se trouve peut-être pas dans le même projet. Passez à l'étape suivante pour rechercher la stratégie de réponse.

    Si le résultat ressemble à ce qui suit, passez à l'étape 4 pour supprimer la stratégie de réponse.

    [
   {
      "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. Obtenez une liste des projets avec l'autorisation dns.networks.bindDNSResponsePolicy à l'aide d'IAM Policy Analyzer.

  3. Vérifiez chaque projet pour voir s'il contient la stratégie de réponse liée au réseau :

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

  4. Supprimez la stratégie de réponse.

Erreur: Configuration non valide spécifiée dans kube-dns

L'événement suivant se produit lorsque vous appliquez un ConfigMap kube-dns personnalisé qui n'est pas valide pour Cloud DNS pour 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

Pour résoudre ce problème, examinez les détails de l'erreur concernant la partie non valide du ConfigMap. Dans l'exemple précédent, 8.8.8.256 n'est pas une adresse IP valide.

Étapes suivantes