Actualiza tus proyectos para que usen DNS zonal

En este documento, se explica cómo migrar un proyecto existente del DNS global al DNS zonal. El DNS zonal mejora la confiabilidad, ya que aísla las interrupciones dentro de las zonas y evita las interrupciones de los servicios esenciales, como la creación de instancias y la reparación automática.

Antes de comenzar

• Si aún no lo hiciste, configura la autenticación. La autenticación verifica tu identidad para acceder a los servicios y las APIs de Cloud de Confiance by S3NS . Para ejecutar código o muestras 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 Cloud de Confiance console to access Cloud de Confiance by S3NS services and APIs, you don't need to set up authentication.

  gcloud

  1. Instala Google Cloud CLI y, luego, accede a gcloud CLI con tu identidad federada. Después de acceder, inicializa Google Cloud CLI ejecutando el siguiente comando:

     gcloud init

  2. Set a default region and zone.

  REST

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

  Instala Google Cloud CLI y, luego, accede a gcloud CLI con tu identidad federada. Después de acceder, inicializa Google Cloud CLI ejecutando el siguiente comando:

  gcloud init

  Para obtener más información, consulta Autentícate para usar REST en la documentación de autenticación de Cloud de Confiance .

Roles requeridos

Para obtener los permisos que necesitas para migrar proyectos para usar DNS zonal, pídele a tu administrador que te otorgue los siguientes roles de IAM:

• Migra un proyecto para usar DNS zonal: Editor del proyecto (roles/resourcemanager.projectEditor) en el proyecto
• Migra VMs a DNS zonal dentro de un proyecto: Administrador de instancias de Compute (v1) (roles/compute.instanceAdmin.v1) en el proyecto
• Si tu VM usa una cuenta de servicio: Usuario de cuenta de servicio (roles/iam.serviceAccountUser) en la cuenta de servicio o el proyecto

Para obtener más información sobre cómo otorgar roles, consulta Administra el acceso a proyectos, carpetas y organizaciones.

Estos roles predefinidos contienen los permisos necesarios para migrar proyectos para que usen el DNS zonal. Para ver los permisos exactos que son necesarios, expande la sección Permisos requeridos:

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

Migra tu proyecto al DNS zonal

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

1. Cómo verificar si tu proyecto usa DNS global de forma predeterminada
2. Determina la preparación para la migración de tus proyectos con el análisis de consultas
3. Migra proyectos que sean compatibles con DNS zonal
4. Cómo corregir búsquedas incompatibles
5. Supervisa los registros de DNS globales para confirmar que la migración esté lista.
6. Migra los proyectos restantes al DNS zonal
7. Cómo verificar si un cambio en el DNS zonal afecta tu proyecto

Comprueba si tu proyecto usa DNS global de forma predeterminada

Verifica tus proyectos para ver si deben migrar del uso de DNS global al DNS zonal. Solo debes migrar los proyectos que estén configurados para usar el DNS global como valor predeterminado para cualquier nombre de DNS interno creado dentro del proyecto.

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

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

Cómo 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 a DNS zonal sin cambiar el código ni alterar la forma en que se usa el DNS global, Cloud de Confiance by S3NS analiza tu 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 la cantidad total de consultas en un período de 100 días que se pueden resolver correctamente con el DNS zonal.

• zonal_dns_risky (Consultas incompatibles): Esta métrica representa la cantidad total de consultas que no se pueden resolver con el DNS zonal. Por lo general, estas consultas implican comunicación entre regiones o bien otros casos en los 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. Deberás solucionar estos problemas de incompatibilidad antes de cambiar al DNS zonal.

Para ver estas métricas, usa el Explorador de métricas en la consola de Cloud de Confiance .

1. En la consola de Cloud de Confiance , accede a la página leaderboard Explorador de métricas:

   Acceder al Explorador de métricas

   Si usas la barra de búsqueda para encontrar esta página, selecciona el resultado cuyo subtítulo es Monitoring.

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

3. Si el campo de entrada de la consulta no está titulado Consulta de PromQL, selecciona PromQL en Lenguaje.

4. En el campo de entrada de la consulta, ingresa 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 Cloud de Confiance muestra un gráfico de las dos métricas (zonal_dns_ready y zonal_dns_risky) y la cantidad correspondiente de búsquedas realizadas durante el período para cada métrica.

   

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

   • Si el valor es 0, el proyecto está listo para la migración al DNS zonal. Puedes migrar el proyecto, como se describe en Migra proyectos que estén listos para el DNS zonal.
   • Si el valor es un número distinto de cero, como 0.02k, como se muestra en la captura de pantalla anterior, es posible que algunas búsquedas no funcionen después de migrar al DNS zonal. El proyecto no está listo para la migración. Continúa con los pasos en Corrige las consultas incompatibles.

Migra 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 zonal en la consola de Cloud de Confiance .

  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 zonal), el banner incluirá una recomendación para usar el DNS zonal. Esta recomendación se basa en el uso interno de DNS en el proyecto, pero se limita a los últimos 30 días.

     

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

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

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

  1. Habilita el DNS zonal para tus instancias con la configuración de la entrada de metadatos vmDnsSetting para el proyecto. Después de establecer esta entrada de metadatos, solo se podrá acceder a tus instancias de procesamiento a través de sus nombres de DNS zonales (VM_NAME.ZONE.c.PROJECT_ID.internal) cuando se usen rutas de búsqueda. Las instancias aún conservarán 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 funcionarán. Solo las instancias de la misma región y el mismo proyecto pueden acceder entre sí con el nombre global cuando se aplica este parámetro de configuración.

     Console

     1. Para actualizar el parámetro de configuración a nivel del proyecto, en la consola deCloud de Confiance , ve a la página Metadatos de Compute Engine.

        Ir a la página Metadatos personalizados

     2. Haz clic en edit Editar.

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

     4. Si no existe una clave con el valor VmDnsSetting, haz clic en add_box Agregar elemento.

        • En el campo Clave, ingresa VmDnsSetting.
        • En el campo Valor, ingresa ZonalOnly.

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

     gcloud

     1. Para actualizar el parámetro de configuración 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 metadatos de un proyecto, usa el siguiente comando:

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

        Reemplaza PROJECT_ID por el nombre del proyecto que deseas consultar.

     REST

     Para actualizar el parámetro de configuración de metadatos a nivel del 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 string aleatoria de caracteres generada por Compute Engine. La huella digital cambia después de cada solicitud y, si proporcionas una huella digital que no coincida, se rechaza tu solicitud.

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

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

        GET https://compute.s3nsapis.fr/compute/v1/projects/PROJECT_ID
        

        El resultado es similar a este:

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

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

        POST https://compute.s3nsapis.fr/compute/v1/projects/PROJECT_ID/setCommonInstanceMetadata
        
        {
        "fingerprint": "FikclA7UBC0=",
        "items": [
          {
          "key": "vmDnsSetting",
          "value": "ZonalOnly"
          }
        ]
        }
        

        Reemplaza PROJECT_ID por el ID del proyecto.

  2. Después de configurar la entrada de metadatos vmDnsSetting para tu proyecto, actualiza la asignación de DHCP en cada instancia de ese proyecto. Puedes actualizar la asignación de tiempo si reinicias la instancia, si esperas que la asignación de tiempo caduque o si ejecutas uno de los siguientes comandos:

     Instancias de Linux

     sudo dhclient -v -r
     

     Instancias de Windows

     ipconfig /renew
     

  3. Verifica que tu proyecto use DNS zonal.

Cómo corregir las búsquedas incompatibles

Un proyecto que no está listo para migrar significa que se realizó al menos una consulta de DNS incompatible en un período determinado, como en los últimos 30 días. Las búsquedas incompatibles pueden tener los siguientes atributos:

• Cómo hacer una llamada a una instancia de procesamiento en otro proyecto
• Llama a una instancia de procesamiento 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 Cloud de Confiance :

Para corregir todas las consultas incompatibles, te recomendamos que uses el nombre de dominio completamente calificado (FQDN) zonal de la instancia de origen en la consulta. Este enfoque garantiza que la resolución de consultas no se interrumpa después de migrar el proyecto al DNS zonal.

Para resolver las consultas incompatibles, haz lo siguiente:

1. Usa el Explorador de registros para acceder y consultar el uso de DNS global para las instancias de procesamiento de tu proyecto.

   Ir al Explorador de registros

2. Selecciona el proyecto.

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

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

   4. En el diálogo Seleccionar nombres de registro, selecciona gdnsusage y, luego, haz clic en Aplicar.

   También puedes ingresar 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:

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

   • Un mensaje de depuración que proporciona información acerca de cómo actualizar la consulta de DNS global que no se puede resolver con nombres de DNS zonales Estas se consideran consultas que bloquean la migración y que debes depurar y corregir.

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

   • Es un recuento de consultas que muestra cuántas consultas de bloqueo de migración envían las VMs de origen a la VM de destino en ese día.

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

   

5. Usa la información del jsonPayload que obtuviste en el paso anterior para determinar qué FQDN usar para actualizar de forma manual tus consultas de DNS globales para usar DNS zonal y preparar el proyecto para la migración. Los casos de uso más comunes para actualizar el FQDN y resolver la compatibilidad son los siguientes:

   • Nombres DNS internos del servidor de metadatos: No se requiere ninguna acción, ya que el nombre DNS que se devuelve cambiará a un FQDN zonal de inmediato después de la migración a DNS zonal. Si el nombre de DNS está almacenado en caché, solo debes realizar una llamada más para actualizar el valor de la caché.
   • Nombres DNS internos que se usan para acceder a las VMs en otra región: Si tienes una aplicación que usa los nombres de DNS internos para las VMs en diferentes regiones, puedes modificar la política de DHCP o el archivo de configuración para incluir la zona en la otra región.
   • FQDN global hard-coded: si tienes una aplicación que usa nombres de FQDN globales hard-coded para las VMs, puedes actualizar la llamada dentro de la aplicación para usar el nombre de DNS interno o el FQDN zonal. Puedes realizar este cambio a través de 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 nombres de DNS de las VMs en proyectos de servicio que usan una red de VPC compartida, debes usar los FQDN zonales de las VMs.

6. Después de actualizar las consultas de DNS globales para usar DNS zonal, haz lo siguiente:

   1. Usa la página del Explorador de registros para volver a consultar el uso del DNS global. Después de corregir todas las consultas de DNS globales que bloquean, no deberían aparecer registros de depuración en los resultados de la consulta.

   2. Vuelve a verificar la métrica de supervisión para ver si se quitaron todas las consultas de DNS incompatibles.

Visualiza registros de DNS global en el Explorador de registros

El Explorador de registros muestra principalmente los registros de DNS globales para los proyectos con consultas que son incompatibles con el DNS zonal. Estos registros te ayudan a identificar y analizar esas búsquedas problemáticas antes de la migración.

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

• Crea paneles: Visualiza tus patrones de consultas de DNS globales incompatibles para obtener estadísticas sobre el comportamiento de comunicación de tu aplicación.
• Registros agregados: Analiza los registros de DNS en toda tu organización para identificar tendencias más amplias y posibles áreas de mejora.

Comprueba si un cambio en el DNS zonal afecta tu proyecto

Después de migrar al DNS zonal, es fundamental verificar que tus aplicaciones y servicios sigan funcionando correctamente. Dado que el DNS zonal cambia la forma en que se resuelven los nombres de DNS internos, algunas aplicaciones pueden experimentar problemas si dependen de nombres de DNS globales.

En la siguiente sección, se describe cómo verificar los posibles impactos y cómo resolverlos:

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

   Tarea: Intenta hacer ping a una instancia desde otra con gcloud CLI.

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

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

   Resolución: Actualiza el nombre de host que usas para VM-B a su nombre de dominio completamente calificado (FQDN), que incluye el nombre de la zona: INSTANCE_NAME.ZONE.c.PROJECT_ID.internal

2. Comunicación de instancias dentro de los servicios de Compute Engine

   Tarea: Si usas verificaciones de estado para grupos de instancias administrados (MIG) que dependen de nombres de DNS internos, verifica si las verificaciones de estado se aprueban.

   Posible error: "Falló la verificación de estado". Esto indica que la verificación de estado no puede alcanzar su objetivo debido a problemas de resolución de DNS.

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

3. Casos de uso específicos de la aplicación

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

   • Conexión a bases de datos (por ejemplo, Cloud SQL)

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

   • Posibles errores: Varían según la aplicación, pero pueden incluir los siguientes:

     • "No se puede establecer conexión con SERVICE_NAME"
     • "Se agotó el tiempo de espera de la conexión"
     • "No se conoce ese host"

   • Resolución: Verifica la configuración de tu aplicación para asegurarte de que use el FQDN (incluido el nombre de la zona) cuando haga referencia a los servicios.

Vuelve a usar el DNS global

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

Vuelve a usar del DNS global para un proyecto

Para revertir un proyecto para que vuelva a usar DNS global, completa los siguientes pasos.

1. Agrega lo siguiente a los metadatos del proyecto: vmDnsSetting=GlobalDefault.

   Para obtener información sobre cómo establecer valores de metadatos del proyecto, consulta Configura y quita metadatos personalizados.

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

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

   Reemplaza INSTANCE_NAME por el nombre de la instancia que deseas verificar.

3. Actualiza la asignación de DHCP en cada instancia. Puedes actualizar la asignación de tiempo si reinicias la instancia, si esperas que la asignación de tiempo caduque o si ejecutas uno de los siguientes comandos en el sistema operativo invitado:

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

Vuelve a usar del DNS global para una instancia

Para revertir una instancia específica para usar el DNS global, completa los siguientes pasos.

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

   Para obtener información sobre cómo establecer valores de metadatos de instancias de procesamiento, consulta Configura y quita metadatos personalizados.

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

   • Para Container-Optimized OS o Ubuntu:

     sudo systemctl restart systemd-networkd
     

   • Para CentOS, Red Hat Enterprise Linux, Fedora CoreOS o Rocky Linux, haz lo siguiente:

     sudo systemctl restart network
     

     o

     sudo systemctl restart NetworkManager.service
     

   • Para Debian:

     sudo systemctl restart networking
     

   • Para sistemas Linux con nmcli, haz lo siguiente:

     sudo nmcli networking off
     sudo nmcli networking on
     

   • Para Windows:

     ipconfig /renew
     

Vuelve a usar del DNS global para 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 tu contenedor no se actualice de forma automática hasta que reinicies los contenedores. Para inhabilitar el DNS zonal en estas apps de contenedor, completa los siguientes pasos.

1. Establece la configuración de metadatos del proyecto vmDnsSetting en GlobalDefault en los proyectos que poseen los contenedores y las VMs.

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

Soluciona problemas del proceso de migración del DNS global al DNS zonal

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

¿Qué sigue?

• Revisa la jerarquía de recursos deCloud de Confiance by S3NS para obtener información sobre la relación entre organizaciones, carpetas y proyectos.
• Obtén más información sobre el DNS interno para Compute Engine.