Actualizar los proyectos para que usen DNS zonales

En este documento se explica cómo migrar un proyecto de DNS global a DNS zonal. El DNS zonal mejora la fiabilidad al aislar las interrupciones dentro de las zonas, lo que evita que se interrumpan servicios esenciales, como la creación de instancias y la reparación automática.

Antes de empezar

  • Si aún no lo has hecho, configura la autenticación. La autenticación verifica tu identidad para acceder a Google Cloud servicios y APIs. Para ejecutar código o ejemplos desde un entorno de desarrollo local, puedes autenticarte en Compute Engine seleccionando una de las siguientes opciones:

    Select the tab for how you plan to use the samples on this page:

    Console

    When you use the Google Cloud console to access Google Cloud services and APIs, you don't need to set up authentication.

    gcloud

    1. Instala Google Cloud CLI. Después de la instalación, inicializa la CLI de Google Cloud ejecutando el siguiente comando: 

      gcloud init

      Si utilizas un proveedor de identidades (IdP) externo, primero debes iniciar sesión en la CLI de gcloud con tu identidad federada.

    2. Set a default region and zone.

    REST

    Para usar las muestras de la API REST de esta página en un entorno de desarrollo local, debes usar las credenciales que proporciones a la CLI de gcloud.

      Instala Google Cloud CLI. Después de la instalación, inicializa la CLI de Google Cloud ejecutando el siguiente comando: 

      gcloud init

      Si utilizas un proveedor de identidades (IdP) externo, primero debes iniciar sesión en la CLI de gcloud con tu identidad federada.

    Para obtener más información, consulta el artículo Autenticarse para usar REST de la documentación sobre autenticación de Google Cloud .

Roles obligatorios

Para obtener los permisos que necesitas para migrar proyectos para que usen DNS zonales, pide a tu administrador que te conceda los siguientes roles de gestión de identidades y accesos:

Para obtener más información sobre cómo conceder roles, consulta el artículo Gestionar el acceso a proyectos, carpetas y organizaciones.

Estos roles predefinidos contienen los permisos necesarios para migrar proyectos para que usen DNS zonales. Para ver los permisos exactos que se necesitan, despliega la sección Permisos necesarios:

Permisos obligatorios

Para migrar proyectos para que usen DNS zonales, se necesitan los siguientes permisos:

  • Comprueba los nombres de DNS globales y los metadatos de la VM: compute.projects.get
  • Definir metadatos en una VM: compute.instances.setMetadata
  • Definir metadatos de todo el proyecto: compute.projects.setCommonInstanceMetadata
  • Si tus VMs usan cuentas de servicio: iam.serviceAccounts.actAs

También puedes obtener estos permisos con roles personalizados u otros roles predefinidos.

Migrar un proyecto a DNS zonal

Para migrar un proyecto para que use DNS zonales, completa las siguientes tareas:

  1. Comprobar si tu proyecto usa el DNS global de forma predeterminada
  2. Determinar si tus proyectos están listos para la migración mediante el análisis de consultas
  3. Migrar proyectos compatibles con DNS zonal
  4. Corregir consultas incompatibles
  5. Monitoriza los registros de DNS globales para confirmar que la migración está lista.
  6. Migrar los proyectos restantes a DNS zonal
  7. Comprobar si un cambio en el DNS zonal afecta a tu proyecto

Comprobar si tu proyecto usa DNS global de forma predeterminada

Comprueba tus proyectos para ver si es necesario migrar del DNS global al DNS de zona. Solo tienes que migrar los proyectos que estén configurados para usar el DNS global como predeterminado para los nombres de DNS internos creados en el proyecto.

Consola

  1. En la consola, ve a la página Metadatos de Compute Engine. Google Cloud

    Ir a Metadatos

  2. En la pestaña Metadatos, consulta el ajuste vmdnssetting, si existe. El valor asignado indica si el proyecto usa el DNS global de forma predeterminada.

    • GlobalDefault: el proyecto tiene habilitado el DNS global.
    • ZonalOnly: el proyecto tiene habilitado el DNS zonal. No es necesario migrar este proyecto.

    Si no aparece el ajuste de metadatos vmdnssetting, comprueba si tu organización usa el DNS global de forma predeterminada.

gcloud

Ejecuta el siguiente comando de gcloud CLI para comprobar el valor de vmDnsSetting.

gcloud compute project-info describe --project=PROJECT_ID --flatten="vmDnsSetting"

Sustituye PROJECT_ID por el nombre del proyecto.

El valor devuelto indica si el proyecto usa el DNS global de forma predeterminada.

  • GLOBAL_DEFAULT: el proyecto tiene habilitado el DNS global.
  • ZONAL_ONLY: el proyecto tiene habilitado el DNS zonal. No es necesario migrar este proyecto.

REST

Comprueba el valor de vmDnsSetting con el método projects.get. En este ejemplo se usa el parámetro de consulta fields para incluir solo los campos que quieras ver.

GET https://compute.googleapis.com/compute/v1/projects/PROJECT_ID?fields=id,name,vmDnsSetting

Sustituye PROJECT_ID por el ID del proyecto.

El valor de vmDnsSetting indica si el proyecto usa el DNS global de forma predeterminada.

  • GLOBAL_DEFAULT: el proyecto tiene habilitado el DNS global.
  • ZONAL_ONLY: el proyecto tiene habilitado el DNS zonal. No es necesario migrar este proyecto.

Usar el análisis de consultas para determinar si un proyecto está listo para la migración

Para evaluar si un proyecto se puede migrar al DNS zonal sin cambiar el código ni la forma en que se usa el DNS global, Google Cloud analiza el historial de consultas de DNS. Este análisis proporciona las siguientes métricas que indican la compatibilidad del proyecto con el DNS zonal:

  • zonal_dns_ready (Consultas compatibles): esta métrica representa el número total de consultas de un periodo de 100 días que se pueden resolver correctamente mediante el DNS zonal.

  • zonal_dns_risky (Consultas incompatibles): esta métrica representa el número total de consultas que no se pueden resolver mediante el DNS zonal. Estas consultas suelen implicar la comunicación entre regiones u otras situaciones en las que falla la resolución zonal. Es fundamental que, si esta métrica tiene un valor distinto de cero, tu proyecto aún no esté listo para la migración. Debes solucionar estas consultas incompatibles antes de cambiar a DNS zonales.

Para ver estas métricas, usa el explorador de métricas en la consola de Google Cloud .

  1. En la Google Cloud consola, ve a la página  Explorador de métricas:

    Ve al explorador de métricas.

    Si usas la barra de búsqueda para encontrar esta página, selecciona el resultado cuya sección sea Monitorización.

  2. En la parte derecha de la barra de herramientas que contiene el campo Seleccionar una métrica, haga clic en Editor de código, MQL o PromQL.

  3. Si el campo de entrada de la consulta no se llama Consulta de PromQL, en Idioma, selecciona PromQL.

  4. En el campo de entrada de la consulta, introduce el siguiente texto exactamente como aparece:

    increase({"compute.googleapis.com/global_dns/request_count", monitored_resource="compute.googleapis.com/Location"}[1d])

  5. Haz clic en el botón Ejecutar consulta.

    La consola Google Cloud muestra un gráfico de las dos métricas (zonal_dns_ready y zonal_dns_risky) y el número correspondiente de consultas realizadas durante el periodo de cada métrica.

    Captura de pantalla del gráfico de métricas de uso de DNS global.

  6. Compruebe el valor de la métrica zonal_dns_risky.

    • Si el valor es 0, el proyecto está listo para migrarse al DNS de zona. Puedes migrar el proyecto, tal como se describe en Migrar proyectos que estén listos para el DNS zonal.
    • Si el valor es un número distinto de cero, como 0.02k, tal como se muestra en la captura de pantalla anterior, significa que hay algunas consultas que podrían no funcionar después de migrar al DNS zonal. El proyecto no está listo para la migración. Sigue los pasos que se indican en Corregir consultas incompatibles.

Migrar proyectos compatibles con DNS zonal

Usa cualquiera de las siguientes opciones para migrar los proyectos que estén listos para cambiar al DNS zonal:

  • Haz clic en el botón Usar DNS de zona de la consola de Google Cloud .

    1. Cuando veas la página Instancias de VM de tu proyecto, si este está listo para la migración (es compatible con las consultas de DNS zonales), el banner incluirá una recomendación para usar DNS zonal. Esta recomendación se basa en el uso interno del DNS en el proyecto, pero se limita a los últimos 30 días.

      Captura de pantalla del banner que indica que se puede migrar al DNS zonal en la consola.

      Si haces clic en el botón Usar DNS zonal, los metadatos del proyecto se actualizarán para usar el DNS zonal.

    2. Opcional: consulta y busca metadatos de la VM para confirmar el cambio de metadatos.

  • Cambia manualmente los metadatos del proyecto para usar DNS zonales.

    1. Habilita el DNS zonal para tus instancias configurando la entrada de metadatos vmDnsSetting del proyecto. Una vez que hayas definido esta entrada de metadatos, solo se podrá acceder a tus instancias de proceso mediante sus nombres DNS zonales (VM_NAME.ZONE.c.PROJECT_ID.internal) al usar rutas de búsqueda. Las instancias conservan las rutas de búsqueda zonales y globales, pero sus nombres de DNS globales, que no incluyen ZONE como parte del nombre de DNS interno, ya no funcionan. Solo las instancias de la misma región y del mismo proyecto pueden acceder entre sí mediante el nombre global cuando se aplica este ajuste.

      Consola

      1. Para actualizar la configuración a nivel de proyecto, en la Google Cloud consola, vaya a la página Metadatos de Compute Engine.

        Ir a la página Metadatos personalizados

      2. Haz clic en Editar.

      3. Si existe una clave con el valor VmDnsSetting, cambia su valor a ZonalOnly.

      4. Si no existe ninguna clave con el valor VmDnsSetting, haga clic en Añadir elemento.

        • En el campo Key (Clave), introduce VmDnsSetting.
        • En el campo Valor, introduce ZonalOnly.

      5. Para terminar de modificar las entradas de metadatos personalizados, haz clic en Guardar.

      gcloud

      1. Para actualizar el ajuste de metadatos del proyecto actual, usa el comando project-info add-metadata.

        gcloud compute project-info add-metadata \
    --metadata vmDnsSetting=ZonalOnly

      2. Opcional: Para verificar la configuración de los metadatos de un proyecto, usa el siguiente comando:

        gcloud compute project-info describe --project=PROJECT_ID --flatten="vmDnsSetting"

        Sustituye PROJECT_ID por el nombre del proyecto que quieras consultar.

      REST

      Para actualizar la configuración de los metadatos a nivel de proyecto, crea una solicitud POST con el método projects.setCommonInstanceMetadata.

      1. Opcional: Para realizar un bloqueo optimista, puedes proporcionar una huella digital.

        Una huella digital es una cadena aleatoria de caracteres generada por Compute Engine. La huella digital cambia después de cada solicitud y, si proporcionas una huella digital que no coincide, se rechazará tu solicitud.

        Si no proporcionas una huella digital, no se realizará ninguna comprobación de coherencia y la solicitud projects.setCommonInstanceMetadata se completará correctamente. Si usas el método instances.setMetadata, siempre se requiere una huella digital.

        Para obtener la huella digital actual de un proyecto, llama al método project.get.

        GET https://compute.googleapis.com/compute/v1/projects/PROJECT_ID

        El resultado debería ser similar al siguiente:

        {
 "name": "myproject",
 "commonInstanceMetadata": {
   "kind": "compute#metadata",
   "fingerprint": "FikclA7UBC0=",
   ...
 }
}

      2. Crea una solicitud POST al método projects.setCommonInstanceMetadata para definir el par clave-valor de los metadatos:

        POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/setCommonInstanceMetadata

{
"fingerprint": "FikclA7UBC0=",
"items": [
  {
  "key": "vmDnsSetting",
  "value": "ZonalOnly"
  }
]
}

        Sustituye PROJECT_ID por el ID de tu proyecto.

    2. Después de configurar la entrada de metadatos vmDnsSetting de tu proyecto, actualiza la concesión de DHCP en cada instancia de ese proyecto. Puedes actualizar la concesión reiniciando la instancia, esperando a que caduque o ejecutando uno de los siguientes comandos:

      Instancias de Linux 

      sudo dhclient -v -r

      Instancias de Windows 

      ipconfig /renew

    3. Comprueba que tu proyecto utilice DNS de zona.

Corregir consultas incompatibles

Si un proyecto no está listo para migrarse, significa que se ha realizado al menos una consulta de DNS incompatible en un periodo determinado, como los últimos 30 días. Las consultas incompatibles pueden tener los siguientes atributos:

  • Hacer una llamada a una instancia de proceso en otro proyecto
  • Llamar a una instancia de proceso en otra región

Si tu proyecto tiene consultas incompatibles, aparecerá el siguiente banner en la página Instancias de VM de la consola de Google Cloud :

Banner que indica que tu proyecto no está listo para migrar al DNS zonal.

Para corregir todas las consultas incompatibles, le recomendamos que utilice el nombre de dominio completo (FQDN) zonal de la instancia de origen en la consulta. De esta forma, la resolución de consultas no se interrumpe después de migrar el proyecto al DNS zonal.

Para resolver las consultas incompatibles, haga lo siguiente:

  1. Usa el Explorador de registros para acceder a la consulta del uso global de DNS de las instancias de cálculo de tu proyecto.

    Ir a Explorador de registros

  2. Selecciona el proyecto.

  3. Aplica los filtros de recursos y de nombres de registro:

    1. Haz clic en Recurso.
    2. En el cuadro de diálogo Seleccionar recurso, selecciona Instancia de VM y, a continuación, haz clic en Aplicar.
    3. Haz clic en Nombre del registro.

    4. En el cuadro de diálogo Seleccionar nombres de registro, selecciona gdnsusage y, a continuación, haz clic en Aplicar.

    También puedes introducir lo siguiente en el campo de consulta:

       resource.type="gce_instance"
   log_name="projects/PROJECT_ID/logs/compute.googleapis.com%2Fgdnsusage"

  4. En el panel Resultados de la consulta, cada consulta tiene un campo jsonPayload. Cada campo jsonPayload contiene la siguiente información:

    • El nombre de la VM de origen, su ID de proyecto y el nombre de la zona.
    • El nombre de la VM de destino, su ID de proyecto y el nombre de la zona.

    • Mensaje de depuración que proporciona información sobre cómo actualizar la consulta de DNS global que no se puede resolver mediante nombres de DNS zonales. Estas consultas se consideran bloqueantes de la migración, por lo que debes depurarlas y corregirlas.

      "To use Zonal DNS, update the Global DNS query sent from the source VM
VM_NAME.c.PROJECT_ID.internal to the following zonal
FQDN: VM_NAME.ZONE.c.PROJECT_ID.internal"

    • Número de consultas que muestra cuántas consultas de bloqueo de migración envía la VM de origen a la de destino durante ese día.

    En la siguiente captura de pantalla se muestra la información del campo jsonPayload en la página de la consola Explorador de registros.

    Captura de pantalla de jsonPayload en los resultados de la consulta de registro gdnsusage.

  5. Utilice la información del jsonPayload que ha obtenido en el paso anterior para determinar qué FQDN debe usar para actualizar manualmente sus consultas de DNS globales para que usen el DNS zonal y prepare el proyecto para la migración. Estos son los casos prácticos más habituales en los que se actualiza el nombre de dominio completo y se resuelve la compatibilidad:

    • Nombres de DNS internos del servidor de metadatos: no es necesario hacer nada, ya que el nombre de DNS devuelto cambiará a un FQDN zonal inmediatamente después de la migración al DNS zonal. Si el nombre de DNS está almacenado en caché, solo tienes que hacer una llamada más para actualizar el valor de la caché.
    • Nombres de DNS internos que se usan para acceder a VMs de otra región: si tienes una aplicación que usa los nombres de DNS internos de VMs de otras regiones, puedes modificar la política de DHCP o el archivo de configuración para incluir la zona de la otra región.
    • Nombre de dominio completo global codificado: si tienes una aplicación que usa nombres de dominio completo globales codificados para las VMs, puedes actualizar la llamada en la aplicación para que use el nombre de DNS interno o el nombre de dominio completo zonal. Puedes hacer este cambio mediante un cambio de código o de configuración en Terraform.
    • VMs en proyectos de servicio que usan una red de VPC compartida: para resolver los nombres DNS de las VMs en proyectos de servicio que usan una red de VPC compartida, debes usar los FQDNs zonales de las VMs.

  6. Una vez que hayas actualizado las consultas de DNS globales para usar el DNS zonal, haz lo siguiente:

    1. Vuelve a consultar el uso global de DNS en la página Explorador de registros. Una vez que hayas corregido todas las consultas DNS globales de bloqueo, no debería aparecer ningún registro de depuración en los resultados de la consulta.

    2. Vuelve a comprobar la métrica de monitorización para ver si se han eliminado todas las consultas de DNS incompatibles.

Ver registros de DNS globales en el explorador de registros

El Explorador de registros muestra principalmente registros de DNS globales de proyectos con consultas que son incompatibles con el DNS zonal. Estos registros le ayudan a identificar y analizar esas consultas problemáticas antes de migrar.

También puedes usar el Explorador de registros para estas consultas incompatibles y hacer lo siguiente:

  • Crear paneles de control: visualiza tus patrones de consulta de DNS globales incompatibles para obtener información valiosa sobre el comportamiento de comunicación de tu aplicación.
  • Registros agregados: analiza los registros de DNS de toda tu organización para identificar tendencias generales y posibles áreas de mejora.

Comprobar si un cambio en el DNS de zona afecta a tu proyecto

Después de migrar al DNS zonal, es fundamental verificar que tus aplicaciones y servicios siguen funcionando correctamente. Como los cambios de DNS zonales modifican la forma en que se resuelven los nombres de DNS internos, es posible que algunas aplicaciones tengan problemas si dependen de nombres de DNS globales.

En la siguiente sección se describe cómo comprobar los posibles efectos y cómo resolverlos:

  1. Comunicación de instancias mediante línea de comandos

    Tarea: prueba a hacer ping a una instancia desde otra con la CLI de gcloud.

    gcloud compute ssh VM-A --command "ping VM-B"

    Posible error: "No se ha podido resolver el host". Esto significa que VM-A no puede encontrar la dirección IP de VM-B.

    Solución: Actualiza el nombre de host que estás usando para VM-B por su nombre de dominio completo (FQDN), que incluye el nombre de la zona: INSTANCE_NAME.ZONE.c.PROJECT_ID.internal

  2. Comunicación entre instancias en los servicios de Compute Engine

    Tarea: Si usas comprobaciones de estado en grupos de instancias gestionados (MIGs) que dependen de nombres de DNS internos, comprueba si las comprobaciones de estado se están realizando correctamente.

    Posible error: "Health check failed" (Comprobación del estado fallida): indica que la comprobación del estado no puede acceder a su destino debido a problemas de resolución de DNS.

    Resolución: Asegúrate de que la comprobación de estado utilice el FQDN de la instancia de destino, incluido el nombre de la zona.

  3. Casos prácticos específicos de la aplicación

    Muchas aplicaciones dependen del DNS interno para realizar tareas como las siguientes:

    • Conectarse a bases de datos (por ejemplo, Cloud SQL)

    • Interactuar con colas de mensajes (por ejemplo, Pub/Sub)

    • Posibles errores: varían en función de la aplicación, pero pueden incluir lo siguiente:

      • "No se puede conectar a SERVICE_NAME"
      • "Se ha agotado el tiempo de espera de la conexión"
      • "No se conoce ningún host de este tipo"

    • Resolución: Comprueba la configuración de tu aplicación para asegurarte de que utiliza el nombre de dominio completo (FQDN), incluido el nombre de la zona, al hacer referencia a los servicios.

Volver a usar el DNS global

Puedes deshacer la migración al DNS zonal cambiando el tipo de DNS interno predeterminado a DNS global. Puedes hacerlo a nivel de organización, proyecto, instancia o contenedor.

Volver a usar el DNS global en un proyecto

Para volver a usar el DNS global en un proyecto, sigue estos pasos.

  1. Añade lo siguiente a los metadatos del proyecto: vmDnsSetting=GlobalDefault.

    Para obtener información sobre cómo definir valores de metadatos de proyectos, consulta Definir y quitar metadatos personalizados.

  2. Verifica que ninguna de las instancias del proyecto tenga el valor de metadatos vmDnsSetting definido como ZonalOnly.

    gcloud compute instances describe INSTANCE_NAME --flatten="metadata[]"

    Sustituye INSTANCE_NAME por el nombre de la instancia que quieras comprobar.

  3. Actualiza la concesión de DHCP en cada instancia. Puedes renovar el arrendamiento reiniciando la instancia, esperando a que expire el arrendamiento o ejecutando uno de los siguientes comandos en el sistema operativo invitado:

    • Instancias de Linux: sudo dhclient -v -r
    • Instancia de Windows Server: ipconfig /renew

Volver a usar el DNS global de una instancia

Para volver a usar el DNS global en una instancia específica, sigue estos pasos.

  1. Actualiza los metadatos de la instancia para incluir vmDnsSetting=GlobalDefault.

    Para obtener información sobre cómo definir valores de metadatos de instancias de proceso, consulta Definir y quitar metadatos personalizados.

  2. Para forzar el cambio de configuración de DNS, reinicia la red de la instancia con uno de los siguientes comandos:

    • En Container-Optimized OS o Ubuntu:

      sudo systemctl restart systemd-networkd

    • En CentOS, Red Hat Enterprise Linux, Fedora CoreOS o Rocky Linux:

      sudo systemctl restart network

      o

      sudo systemctl restart NetworkManager.service

    • En Debian:

      sudo systemctl restart networking

    • En sistemas Linux con nmcli:

      sudo nmcli networking off
sudo nmcli networking on

    • Windows:

      ipconfig /renew

Volver a usar el DNS global de un contenedor

Si ejecutas tu aplicación o carga de trabajo en contenedores, en Google Kubernetes Engine o en el entorno flexible de App Engine, es posible que la configuración de DNS de los ajustes de tu contenedor no se actualice automáticamente hasta que reinicies los contenedores. Para inhabilitar el DNS zonal en estas aplicaciones de contenedor, sigue estos pasos.

  1. Define el ajuste de metadatos del proyecto vmDnsSetting en GlobalDefault en los proyectos que tengan los contenedores y las VMs.

  2. Reinicia los contenedores para que su configuración de DNS vuelva al estado original.

Solucionar problemas del proceso de migración de DNS global a DNS zonal

Si tienes problemas con el proceso de migración, consulta la guía para solucionar problemas.

Siguientes pasos