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 autorecuperación.
Antes de comenzar
-
Si aún no lo hiciste, configura la autenticación.
La autenticación es el proceso mediante el cual se verifica tu identidad para acceder a los servicios y las APIs de Google Cloud .
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 Google Cloud console to access Google Cloud services and APIs, you don't need to set up authentication.
gcloud
-
Install the Google Cloud CLI, then initialize it by running the following command:
gcloud init
- Set a default region and zone.
-
Migra un proyecto para usar DNS zonal: Editor de proyectos (
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 proyecto -
Verifica los nombres de DNS globales y los metadatos de la VM:
compute.projects.get
-
Configura metadatos en una VM:
compute.instances.setMetadata
-
Establece metadatos de todo el proyecto:
compute.projects.setCommonInstanceMetadata
-
Si tus VMs usan cuentas de servicio:
iam.serviceAccounts.actAs
- Cómo verificar si tu proyecto usa DNS global de forma predeterminada
- Determina el nivel de preparación de tus proyectos para la migración con el análisis de consultas
- Cómo migrar proyectos compatibles con DNS zonal
- Cómo corregir consultas incompatibles
- Supervisa los registros de DNS globales para confirmar que la migración esté lista.
- Migra los proyectos restantes al DNS zonal
- Cómo verificar si un cambio en el DNS zonal afecta a tu proyecto
En la consola de Google Cloud, ve a la página Metadatos de Compute Engine.
En la pestaña Metadata, consulta el parámetro de configuración
vmdnssetting
, si existe. El valor asignado indica si el proyecto usa 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 la configuración de metadatos
vmdnssetting
, verifica si tu organización 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.GLOBAL_DEFAULT
: El proyecto tiene habilitado el DNS global.ZONAL_ONLY
: El proyecto tiene habilitado el DNS zonal. No es necesario migrar este proyecto.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 alguna otra situación en la 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 abordar estas consultas incompatibles antes de cambiar al DNS zonal.-
En la consola de Google Cloud, ve a la página leaderboardExplorador de métricas:
Si usas la barra de búsqueda para encontrar esta página, selecciona el resultado cuyo subtítulo es Monitoring.
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.
Si el campo de entrada de la consulta no está títulado Consulta de MQL, entonces en la esquina inferior derecha del campo de entrada de la consulta para Lenguaje, selecciona MQL.
En el campo de entrada de la consulta, ingresa el siguiente texto exactamente como aparece:
fetch compute.googleapis.com/Location | metric 'compute.googleapis.com/global_dns/request_count' | every 1d | within 7d
Haga clic en el botón Ejecutar consulta.
En la consola de Google Cloud, se muestra un gráfico de las dos métricas (
zonal_dns_ready
yzonal_dns_risky
) y la cantidad correspondiente de consultas realizadas durante el período de cada métrica.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 Cómo migrar 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 consultas no funcionen después de migrar al DNS zonal. El proyecto no está listo para la migración. Continúa con los pasos que se indican en Cómo corregir consultas incompatibles.
- Si el valor es
Haz clic en el botón Usar DNS zonal en la consola de Google Cloud.
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 el DNS zonal. Esta recomendación se basa en el uso de DNS interno en el proyecto, pero se limita a los últimos 30 días.
Si haces clic en el botón Use Zonal DNS, los metadatos del proyecto se actualizarán para usar el DNS zonal.
Opcional: Consulta y visualiza los metadatos de la VM para confirmar el cambio de metadatos.
Cambia manualmente los metadatos del proyecto para usar el DNS zonal.
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 puede acceder a tus instancias de procesamiento a través de sus nombres de DNS zonales (VM_NAME.ZONE.c.PROJECT_ID.internal) cuando se usan rutas de búsqueda. Las instancias aún conservan las rutas de búsqueda zonal y global, pero sus nombres de DNS globales, que no incluyen ZONE como parte del nombre de DNS interno, ya no funcionan. Cuando se implementa este parámetro de configuración, solo las instancias de la misma región y el mismo proyecto pueden acceder unas a otras con el nombre global.Console
Para actualizar la configuración a nivel del proyecto, en la consola de Google Cloud, ve a la página Metadatos de Compute Engine.
Haz clic en
Editar.Si existe una clave con el valor
VmDnsSetting
, cámbialo aZonalOnly
.Si no existe una clave con el valor
VmDnsSetting
, haz clic en Agregar elemento.- En el campo Clave, ingresa
VmDnsSetting
. - En el campo Valor, ingresa
ZonalOnly
.
- En el campo Clave, ingresa
Para terminar de modificar las entradas de metadatos personalizados, haz clic en Guardar.
gcloud
Para actualizar la configuración de metadatos del proyecto actual, usa el comando
project-info add-metadata
.gcloud compute project-info add-metadata \ --metadata vmDnsSetting=ZonalOnly
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 la configuración de metadatos a nivel del proyecto, crea una solicitud
POST
con el método projects.setCommonInstanceMetadata.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 rechazará 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étodoinstances.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.googleapis.com/compute/v1/projects/PROJECT_ID
El resultado es similar a este:
{ "name": "myproject", "commonInstanceMetadata": { "kind": "compute#metadata", "fingerprint": "FikclA7UBC0=", ... } }
Crea una solicitud
POST
al métodoprojects.setCommonInstanceMetadata
para establecer el par clave-valor de metadatos:POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/setCommonInstanceMetadata { "fingerprint": "FikclA7UBC0=", "items": [ { "key": "vmDnsSetting", "value": "ZonalOnly" } ] }
Reemplaza
PROJECT_ID
por el ID del proyecto.
Después de configurar la entrada de metadatos
vmDnsSetting
para tu proyecto, actualiza la asignación de tiempo 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
- Cómo realizar una llamada a una instancia de procesamiento en otro proyecto
- Realiza una llamada a una instancia de procesamiento en una región diferente
Usa el Explorador de registros para acceder y consultar el uso de DNS global para las instancias de procesamiento de tu proyecto.
Selecciona el proyecto.
Aplica los filtros de recursos y nombres de registro:
- Haz clic en Recurso.
- En el diálogo Seleccionar recurso, selecciona Instancia de VM y, luego, haz clic en Aplicar.
- Haz clic en Nombre del registro.
En el diálogo Seleccionar nombres de registro, selecciona gdnsusage y, luego, haz clic en Aplicar.
Como alternativa, puedes ingresar lo siguiente en el campo de consulta:
resource.type="gce_instance" log_name="projects/PROJECT_ID/logs/compute.googleapis.com%2Fgdnsusage"
En el panel Resultados de la consulta, cada consulta tiene un campo
jsonPayload
. Cada campojsonPayload
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
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 de bloqueo de migración 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ía la VM de origen a la VM de destino 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.Usa la información de
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.
Después de actualizar las consultas de DNS globales para usar DNS zonal, haz lo siguiente:
Usa la página Explorador de registros para volver a consultar el uso del DNS global. Después de corregir todas las consultas de DNS globales de bloqueo, no debería haber registros de depuración en los resultados de la consulta.
Vuelve a verificar la métrica de supervisión para ver si se quitaron todas las consultas de DNS incompatibles.
- Crea paneles: Visualiza tus patrones de consulta de DNS globales incompatibles para obtener estadísticas sobre el comportamiento de comunicación de tu aplicación.
- Aggrega registros: Analiza los registros de DNS de toda tu organización para identificar tendencias más amplias y posibles áreas de mejora.
Comunicación de instancias de línea de comandos
Tarea: Intenta 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 pudo resolver el host”. Esto significa que
VM-A
no puede encontrar la dirección IP deVM-B
.Solución: Actualiza el nombre de host que usas para
VM-B
a su nombre de dominio completamente calificado (FQDN), que incluye el nombre de zona:INSTANCE_NAME.ZONE.c.PROJECT_ID.internal
Comunicación de instancias dentro de los servicios de Compute Engine
Tarea: Si usas verificaciones de estado para grupos de instancias administradas (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.
Solución: Asegúrate de que la verificación de estado use el FQDN de la instancia de destino, incluido el nombre de la zona.
Casos de uso específicos de la aplicación
Muchas aplicaciones dependen del DNS interno para realizar tareas como las siguientes:
- Conexión a bases de datos (por ejemplo, Cloud SQL)
Interactuar con filas de mensajes (por ejemplo, Pub/Sub)
Posibles errores: Estos varían según la aplicación, pero pueden incluir lo siguiente:
- "No se puede conectar a SERVICE_NAME"
- "Se agotó el tiempo de espera de la conexión"
- “No se conoce ningún host de este tipo”
Solución: Verifica la configuración de tu aplicación para asegurarte de que use el FQDN (incluido el nombre de zona) cuando haga referencia a los servicios.
Agrega lo siguiente a los metadatos del proyecto:
vmDnsSetting=GlobalDefault
.Consulta Configura y quita metadatos personalizados para aprender a establecer valores de metadatos de proyecto.
Verifica que ninguna de las instancias del proyecto tenga el valor de metadatos
vmDnsSetting
establecido enZonalOnly
.gcloud compute instances describe INSTANCE_NAME --flatten="metadata[]"
Reemplaza INSTANCE_NAME por el nombre de la instancia que deseas verificar.
Actualiza la asignación de tiempo 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
- Instancias de Linux:
Actualiza los metadatos de la instancia para incluir
vmDnsSetting=GlobalDefault
.Consulta Configura y quita metadatos personalizados para obtener información sobre cómo establecer valores de metadatos de instancias de procesamiento.
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 EL, 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
Establece la configuración de metadatos del proyecto
vmDnsSetting
enGlobalDefault
en los proyectos que poseen los contenedores y las VMs.Reinicia los contenedores para que su configuración de DNS vuelva al estado original.
- Revisa la jerarquía de recursos deGoogle Cloud 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.
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 proporcionas a la CLI de gcloud.
Install the Google Cloud CLI, then initialize it by running the following command:
gcloud init
Para obtener más información, consulta Autentica para usar REST en la documentación de autenticación de Google Cloud .
Roles obligatorios
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:
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 usar el DNS zonal. Para ver los permisos exactos que son necesarios, expande la sección Permisos requeridos:
Permisos necesarios
Se requieren los siguientes permisos para migrar proyectos para usar DNS zonal:
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 usar el DNS zonal, completa las siguientes tareas:
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 predeterminado para cualquier nombre de DNS interno creado dentro del proyecto.
Console
gcloud
Ejecuta el siguiente comando de gcloud CLI para verificar el valor de
vmDnsSetting
.gcloud compute project-info describe --project=PROJECT_ID --flatten="vmDnsSetting"
Reemplaza PROJECT_ID por el nombre del proyecto.
El valor que se muestra indica si el proyecto usa DNS global de forma predeterminada.
REST
Verifica el valor de
vmDnsSetting
con el métodoprojects.get
. En este ejemplo, se usa un parámetro de consultafields
para incluir solo los campos que deseas ver.GET https://compute.googleapis.com/compute/v1/projects/PROJECT_ID?fields=id,name,vmDnsSetting
Reemplaza PROJECT_ID por el ID del proyecto.
El valor de
vmDnsSetting
indica si el proyecto usa DNS global de forma predeterminada.Usa el análisis de consultas para determinar el nivel de preparación de un proyecto para la migración
Para evaluar si un proyecto se puede migrar al DNS zonal sin cambios de código ni alterar el uso del DNS global, Google Cloud 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:
Para ver estas métricas, usa el Explorador de métricas en la consola de Google Cloud.
Migra proyectos compatibles con el DNS zonal
Usa cualquiera de las siguientes opciones para migrar proyectos que estén listos para cambiar al DNS zonal:
Corrige las consultas 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 consultas incompatibles pueden tener los siguientes atributos:
Si tu proyecto tiene consultas incompatibles, aparecerá el siguiente banner en la página Instancias de VM de la consola de Google Cloud:
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 vea afectada después de migrar el proyecto al DNS zonal.
Para resolver las consultas incompatibles, haz lo siguiente:
Cómo ver registros de DNS globales en el Explorador de registros
El Explorador de registros muestra principalmente registros de DNS globales para proyectos con consultas que son incompatibles con el DNS zonal. Estos registros te ayudan a identificar y analizar esas consultas problemáticas antes de la migración.
También puedes usar el Explorador de registros para estas consultas incompatibles y hacer lo siguiente:
Verifica si un cambio en el DNS zonal afecta a 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, es posible que algunas aplicaciones tengan 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:
Vuelve a usar del DNS global
Para deshacer la migración al DNS zonal, vuelve a cambiar el tipo de DNS interno predeterminado al 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.
Vuelve a usar del DNS global para una instancia
Para revertir una instancia específica para usar DNS global, completa los siguientes pasos.
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.
Soluciona 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 de solución de problemas.
¿Qué sigue?
Salvo que se indique lo contrario, el contenido de esta página está sujeto a la licencia Atribución 4.0 de Creative Commons, y los ejemplos de código están sujetos a la licencia Apache 2.0. Para obtener más información, consulta las políticas del sitio de Google Developers. Java es una marca registrada de Oracle o sus afiliados.
Última actualización: 2025-02-20 (UTC)
-