Solucionar problemas de Cloud DNS en GKE

Si tus pods no pueden conectarse a los servicios y tu clúster de Google Kubernetes Engine (GKE) usa Cloud DNS como proveedor de DNS, es posible que se produzcan errores como dial tcp: i/o timeout o no such host. Estos errores suelen indicar que hay problemas con la configuración de Cloud DNS, como zonas privadas mal configuradas o un ámbito de Cloud DNS incorrecto.

Usa esta página para diagnosticar y resolver problemas habituales relacionados con el uso del servicio Cloud DNS gestionado con GKE, lo que te ayudará a asegurar una resolución de DNS fiable para tus cargas de trabajo.

Esta información es importante para los administradores y operadores de la plataforma, así como para los especialistas en redes que configuran y gestionan la integración entre GKE y Cloud DNS. También es útil para los desarrolladores de aplicaciones que tengan problemas con la detección de servicios. Para obtener más información sobre los roles habituales y las tareas de ejemplo a los que hacemos referencia en el contenido de Google Cloud , consulta Roles y tareas habituales de los usuarios de GKE.

Identificar el origen de los problemas de DNS en Cloud DNS

En las siguientes secciones se explica cómo diagnosticar por qué Cloud DNS tiene problemas para resolver consultas.

Verificar la configuración básica

Si tu pod no puede resolver las búsquedas de DNS, asegúrate de que Cloud DNS esté configurado de la forma que quieras. En esta sección se explica cómo verificar si estás usando Cloud DNS, confirmar la existencia de una zona DNS privada para el clúster de GKE y comprobar la precisión de los registros DNS del servicio de destino.

Para verificar estos ajustes, completa los siguientes comandos:

  1. Comprueba qué servidor DNS está usando tu Pod:

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

    Sustituye POD_NAME por el nombre del pod que tiene problemas con la resolución de DNS.

    Si usas Cloud DNS, el resultado es el siguiente:

    nameserver 169.254.169.254
    

    Si ves cualquier otro valor, significa que no estás usando Cloud DNS. Comprueba que Cloud DNS se haya habilitado correctamente.

  2. Verifica que las zonas gestionadas existen:

    gcloud dns managed-zones list --format list
    

    El resultado debería ser similar al siguiente:

    - 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 salida incluye los siguientes valores:

    • CLUSTER_DOMAIN: el sufijo de dominio DNS que se ha asignado automáticamente a tu clúster.
    • PROJECT_ID: tu ID de proyecto.
    • CLUSTER_NAME: el nombre del clúster con la zona privada.

    En este resultado, el valor del campo name muestra queGoogle Cloud ha creado una zona llamada gke-CLUSTER_NAME-aa94c1f9-dns.

    Si no ves ninguna zona gestionada, significa que no se ha creado ninguna zona privada para tu clúster o que puede que no te hayas autenticado correctamente. Para solucionar problemas, consulta la sección Zonas privadas de la documentación de Cloud DNS.

  3. Verifica los registros DNS de tu servicio:

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

    Haz los cambios siguientes:

    • ZONE_NAME: el nombre de la zona privada.
    • SERVICE_NAME: el nombre del Servicio.

    La salida será similar a la siguiente:

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

    En este resultado se muestra que Cloud DNS contiene un registro A del dominio dns-test.default.svc.cluster.local. y que la dirección IP de tu clúster es 10.47.255.11.

    Si los registros parecen incorrectos, consulta el artículo Aplicar un parche a un conjunto de registros de recursos de la documentación de Cloud DNS para actualizarlos.

Verificar las políticas de respuesta

Comprueba que tus políticas de respuesta existen y tienen el nombre correcto:

  1. Para ver una lista de todas tus políticas de respuesta, sigue estos pasos:

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

    El resultado debería ser similar al siguiente:

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

    En este resultado, gke-CLUSTER_NAME-52c8f518-rp muestra que Google Cloud ha creado una zona privada llamada gke-CLUSTER_NAME-aa94c1f9-rp. Las políticas de respuesta que creaGoogle Cloud tienen el prefijo gke-.

  2. Para ver las políticas de respuesta de una zona privada específica, sigue estos pasos:

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

    Sustituye ZONE_NAME por el nombre de la zona privada que tiene problemas.

    El resultado debería ser similar al siguiente:

    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.
    

    En la primera columna se muestra la dirección IP o el patrón de nombre de dominio que coincide con la regla. La segunda columna es el nombre de host asociado a la dirección IP.

Si detecta algún problema en el resultado de estos comandos, consulte el artículo sobre cómo actualizar una regla de política de respuesta en la documentación de Cloud DNS.

Investigar con registros, paneles de control y métricas

Cloud DNS incluye varias opciones de registro y monitorización para ayudarte a investigar más a fondo tus problemas de DNS:

Buscar registros nuevos

Revisa los registros para ver si se ha creado alguno en la zona privada de Cloud DNS gestionada. Esto puede ser útil si de repente se producen errores de resolución de DNS en el clúster.

Para comprobar si hay registros nuevos, sigue estos pasos:

  1. En la Google Cloud consola, ve a la página Explorador de registros.

    Ir a Explorador de registros

  2. En el panel de consultas, introduce la siguiente consulta:

    resource.type="dns_managed_zone"
    protoPayload.request.change.additions.name="headless-svc-stateful.default.svc.cluster.local."
    protoPayload.methodName="dns.changes.create"
    
  3. Haz clic en Realizar una consulta.

  4. Revisa el resultado. Si detecta cambios que coinciden con el momento en el que se percató de los errores, puede deshacerlos.

Verificar dominios de stub y servidores de nombres personalizados

Si utilizas un clúster estándar de GKE con un dominio stub personalizado o un servidor de nombres upstream, revisa el ConfigMap y comprueba que los valores sean correctos.

Cloud DNS traduce los valores stubDomains y upstreamNameservers en zonas de reenvío de Cloud DNS. Google gestiona estos recursos, por lo que, si detectas algún error, ponte en contacto con el equipo de Atención al Cliente de Cloud para obtener ayuda.

Contactar con Cloud Customer Care

Si has seguido los pasos de las secciones anteriores, pero sigues sin poder diagnosticar la causa del problema, ponte en contacto con el servicio de atención al cliente de Cloud.

Resolver errores específicos

Si has experimentado un error o un problema específico, sigue los consejos que se indican en las secciones siguientes.

Problema: No se puede resolver el servicio de clúster de GKE desde una máquina virtual de Compute Engine

Si no puedes resolver un servicio de clúster de GKE desde una VM de Compute Engine, verifica el ámbito de Cloud DNS del clúster.

El ámbito que uses con Cloud DNS determinará qué recursos se pueden resolver:

  • Ámbito del clúster: la resolución de DNS se limita a los recursos del clúster de Kubernetes (pods y servicios). Esta es la opción predeterminada y es adecuada cuando no necesitas resolver recursos externos fuera del clúster de Kubernetes o de la nube privada virtual (VPC) de GKE.

  • Ámbito de la VPC: la resolución de DNS se extiende a toda la VPC, incluidos los recursos, como las VMs de Compute Engine. Esto permite que el clúster resuelva registros DNS internos de recursos que están fuera del clúster de GKE, pero dentro de la misma VPC, como las Google Cloud VMs.

Para verificar el ámbito de Cloud DNS de tu clúster, sigue estos pasos:

  1. En la Google Cloud consola, ve a la página Clústeres de Kubernetes.

    Ir a clústeres de Kubernetes

  2. Haz clic en el nombre del clúster que tiene problemas con el DNS.

  3. En la sección Red del clúster de la página de detalles del clúster, consulta la información de la fila Proveedor de DNS.

  4. Si ves Cloud DNS (ámbito de clúster), significa que estás usando el ámbito de clúster. Para cambiar el ámbito de DNS, vuelve a crear el clúster con el ámbito de DNS adecuado.

Problema: los pods siguen usando kube-dns después de habilitar Cloud DNS

Si tus pods usan kube-dns incluso después de habilitar Cloud DNS en un clúster, asegúrate de haber actualizado o recreado tus grupos de nodos después de habilitar Cloud DNS en el clúster. Hasta que se complete este paso, los pods seguirán usando kube-dns.

Problema: no se puede actualizar un clúster o crear un clúster con Cloud DNS habilitado

Asegúrate de que estás usando la versión correcta. Cloud DNS para GKE requiere la versión 1.19 de GKE o una posterior para los clústeres que usan el ámbito de VPC, o la versión 1.24.7-gke.800, 1.25.3-gke.700 o una posterior para los clústeres que usan el ámbito de clúster.

Problema: las peticiones de DNS en los nodos fallan después de habilitar Cloud DNS en un clúster

Si habilitas Cloud DNS con ámbito de clúster en un clúster de GKE que tenga dominios stub personalizados o servidores de nombres upstream, la configuración personalizada se aplicará tanto a los nodos como a los pods del clúster, ya que Cloud DNS no puede distinguir entre las solicitudes de DNS de los pods y de los nodos. Es posible que las búsquedas de DNS en los nodos fallen si el servidor upstream personalizado no puede resolver las consultas.

Problema: No se puede actualizar ni crear un clúster con el ámbito de VPC adicional de Cloud DNS habilitado

Asegúrate de que estás usando la versión correcta. El ámbito de VPC aditivo de Cloud DNS requiere la versión 1.28 o posterior de GKE.

Error: Cloud DNS inhabilitado

El siguiente evento se produce cuando se inhabilita la API Cloud DNS:

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 error se produce porque la API Cloud DNS no está habilitada de forma predeterminada. Debes habilitar la API Cloud DNS manualmente.

Para solucionar el problema, habilita la API Cloud DNS.

Error: No se han podido enviar solicitudes a Cloud DNS. Se ha superado el límite de frecuencia de la API.

El siguiente evento se produce cuando un proyecto ha superado una cuota o un límite de 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 solucionar este problema, consulta las cuotas de Cloud DNS y las cuotas y los límites de Compute Engine. Puedes aumentar la cuota con la Google Cloud consola.

Error: No se han podido enviar solicitudes a Cloud DNS debido a un error anterior

El siguiente evento se produce cuando los errores provocan fallos en cascada:

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 solucionar este problema, comprueba los eventos del clúster para encontrar el origen del error original y sigue las instrucciones para resolverlo.

En el ejemplo anterior, el error InsufficientQuota de la zona gestionada ha provocado fallos en cascada. El segundo error de FailedPrecondition indica que se ha producido un error anterior, que era el problema inicial de cuota insuficiente. Para solucionar este problema, debes seguir las instrucciones relativas al error de cuota de Cloud DNS.

Error: Failed to bind response policy

El siguiente evento se produce cuando se vincula una política de respuestas a la red del clúster y Cloud DNS para GKE intenta vincular una política de respuestas a la red:

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 solucionar el problema, sigue estos pasos:

  1. Obtén la política de respuesta vinculada a la red:

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

    Sustituye NETWORK_URL por la URL de la red del error, como https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/networks/NETWORK_NAME.

    Si la salida está vacía, es posible que la política de respuesta no esté en el mismo proyecto. Ve al paso siguiente para buscar la política de respuesta.

    Si el resultado es similar al siguiente, ve al paso 4 para eliminar la política de respuestas.

    [
       {
          "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. Obtén una lista de proyectos con el permiso dns.networks.bindDNSResponsePolicy mediante el Analizador de políticas de gestión de identidades y accesos.

  3. Comprueba si cada proyecto tiene la política de respuesta vinculada a la red:

    gcloud dns response-policies list --filter='networks.networkUrl:NETWORK_URL' \
        --project=PROJECT_NAME
    
  4. Elimina la política de respuesta.

Error: Invalid configuration specified in kube-dns (Error: configuración no válida especificada en kube-dns)

El siguiente evento se produce cuando aplicas un ConfigMap de kube-dns personalizado que no es válido para 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 solucionar este problema, revise los detalles del error correspondiente a la parte no válida del ConfigMap. En el ejemplo anterior, 8.8.8.256 no es una dirección IP válida.

Siguientes pasos