Usa DNS zonal para tu tipo de DNS interno

El DNS zonal mitiga el riesgo de interrupciones interregionales y mejora la confiabilidad general de tus proyectos en Compute Engine. El uso de DNS zonal reduce el impacto de las fallas de un solo punto que pueden ocurrir cuando se usa el DNS global.

Antes de comenzar

  • Configura la autenticación si aún no lo hiciste. La autenticación es el proceso mediante el cual se verifica tu identidad para acceder a los servicios y las API de Google Cloud. Para ejecutar un código o muestras desde un entorno de desarrollo local, puedes autenticarte en Compute Engine de la siguiente manera.

    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. Install the Google Cloud CLI, then initialize it by running the following command: 

      gcloud init
    2. Set a default region and zone.

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

      Si deseas 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 a 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 al 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 a DNS zonal:

  • Establece una restricción de política de la organización: orgpolicy.*
  • Determina si una carpeta está lista para migrar a DNS zonal:
    • resourcemanager.folders.get
    • resourcemanager.folders.list
    • resourcemanager.organizations.get
    • resourcemanager.projects.get
    • resourcemanager.projects.list
  • 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

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

Acerca de los nombres de DNS

Los nombres DNS zonales incluyen el nombre de tu VM, la zona en la que se encuentra y el proyecto al que pertenece. Los nombres de DNS globales no incluyen la zona en la que se encuentra la VM.

Cuando realizas una llamada a una VM con un nombre de DNS global, sucede lo siguiente:

  • El nombre se resuelve a nivel global.
  • Cada VM debe tener un nombre de DNS único.
  • Cuando creas una VM nueva, se debe comparar el nombre de DNS para la VM con todos los demás nombres de DNS globales registrados en el mismo proyecto para evitar una colisión de nombres de DNS.

Cuando realizas una llamada a una VM con un nombre de DNS zonal, sucede lo siguiente:

  • El nombre se resuelve dentro de una zona.
  • Los nombres de DNS zonales deben ser únicos dentro de una zona. Por ejemplo, my-vm.zone1.google.com debe ser único para zone1. Sin embargo, a diferencia de los nombres de DNS globales, my-vm.zone2.google.com también es un nombre de DNS válido cuando se usa el DNS zonal.

El DNS zonal es el método de resolución de DNS interno predeterminado de Compute Engine para las organizaciones creadas después del 6 de septiembre de 2018. Los nombres DNS zonales en una zona funcionan de forma independiente de otras zonas, lo que te permite compilar apps multirregionales más tolerantes a errores con características de mejor disponibilidad. No se aplican cargos por usar el DNS zonal. El DNS zonal es independiente de Cloud DNS.

Los proyectos creados antes del 6 de septiembre de 2018 se configuraron para usar DNS global de forma predeterminada. Estos proyectos pueden seguir usando el DNS global, pero Google recomienda encarecidamente que las organizaciones migren estos proyectos al DNS zonal para evitar que las interrupciones del servicio en otra región afecten los recursos regionales locales. El uso de DNS zonal proporciona mayor confiabilidad en comparación con el DNS global a través del aislamiento de las fallas en el registro DNS en zonas individuales. Esto reduce el impacto de las fallas de un solo punto. Si se produce una interrupción en Google Cloud, se aísla a una sola zona, y los recursos y los costos no se ven afectados de manera significativa.

Cómo migrar de DNS global a DNS zonal

El DNS zonal reemplazó al DNS global como el tipo de DNS interno predeterminado para todas las organizaciones nuevas que se incorporaron a Google Cloud después del 6 de septiembre de 2018. Si tus proyectos existentes aún usan un DNS global, Google recomienda de manera enfática que cambies estos proyectos para usar nombres de DNS zonales. Si no migras a DNS zonal, corres el riesgo de encontrar los siguientes problemas:

  • No se pueden crear VMs nuevas en cualquier región que experimente fallas del plano de control, en la que tienes o tenías un proyecto con anterioridad.
  • La incapacidad de usar algunos servicios esenciales de Compute Engine para tus cargas de trabajo, como el ajuste de escala automático o la reparación automática para grupos de instancias administrados (MIG)

Un enfoque alternativo para mejorar la confiabilidad de tus cargas de trabajo que usan el DNS global es migrar a las zonas privadas de Cloud DNS. El uso de zonas privadas de Cloud DNS quita la verificación de unicidad de nombres que requiere el DNS global y aísla las fallas para permitir la resolución de nombres de DNS. Para obtener más información sobre esta opción, consulta la documentación de Cloud DNS o comunícate con el servicio de atención al cliente de Cloud o con el representante de tu equipo de cuentas. Para obtener información acerca de cómo Cloud DNS maneja las interrupciones zonales y regionales, consulta Arquitectura de recuperación ante desastres para interrupciones de infraestructura de nube.

Descripción general del proceso de migración

El proceso de migración del DNS zonal tiene dos niveles:

  • A nivel de la organización o la carpeta: Determina si la organización o la carpeta están listas para migrar al DNS zonal. Evita que los proyectos nuevos usen el DNS global. La realiza el administrador de la organización.
  • A nivel del proyecto: Migra un solo proyecto del DNS global al DNS zonal. Por lo general, lo realiza el propietario del proyecto.

En la imagen, se muestra un diagrama de flujo de los pasos involucrados en la migración al DNS zonal.

Por lo general, el proceso incluye los siguientes pasos:

  1. Verifica la preparación de la organización o la carpeta para la migración al DNS zonal.
  2. Si la organización o la carpeta están listas para migrar al DNS zonal, haz lo siguiente:
    1. El administrador de la organización establece una política de la organización para la carpeta o la organización para evitar el uso futuro del DNS global.
    2. Los propietarios de los proyectos migran sus proyectos para usar DNS zonal.
  3. Si la carpeta o la organización no están listas para migrar a DNS zonal, haz lo siguiente:
    1. Los propietarios de los proyectos migran los proyectos listos al DNS zonal.
    2. Los propietarios de proyectos investigan el uso de DNS global en proyectos que aún no están listos.
    3. Los propietarios del proyecto aplican mejoras de ruta de búsqueda o distintos cambios para preparar el proyecto para migrar a DNS zonal.
    4. El administrador de la organización vuelve a verificar el estado de la preparación de la organización o la carpeta para la migración a DNS zonal.

Limitaciones

  • El DNS zonal no reemplaza por completo el DNS global. Hay algunos tipos de consultas (interzonales) que pueden no resolverse con el DNS zonal con la búsqueda automática de rutas de búsqueda. Verifica el nivel de preparación para la migración de las carpetas y los proyectos de tu organización para asegurarte de que sean compatibles con el DNS zonal antes de la migración.

  • El proceso de migración de DNS global a DNS zonal introduce un dominio nuevo (ZONE.c.PROJECT_ID.internal) en la ruta de búsqueda. Si una VM que ejecuta Linux o Unix ya tiene 6 dominios en la ruta de búsqueda, asegúrate de que la VM se ejecute con la versión 2.26 de glibc o una posterior. Los clientes DHCP con glibc 2.25 y versiones anteriores solo admiten hasta 6 dominios de búsqueda, por lo que existe el riesgo de descartar un dominio de búsqueda existente. No se aplica este límite a VMs que usen lo siguiente:

    • Imágenes de Windows
    • Imágenes de Container-Optimized OS
    • Imágenes de Debian 10 o versiones posteriores
    • Fedora CoreOS (versión 27 o posterior)
    • Imágenes de RHEL 8 o versiones posteriores
    • Imágenes de Ubuntu 18.04 o versiones posteriores
    • Otras imágenes con glibc versión 2.26 o superior

  • Si habilitas la mejora de la ruta de búsqueda, se agregarán algunos dominios de búsqueda más, como NEIGHBOR_ZONE.c.PROJECT_ID.internal. Como se mencionó en la limitación anterior, es posible que se quiten los dominios existentes en la ruta de búsqueda si se supera el límite de dominios de la ruta de búsqueda cuando se usa la versión 2.25 o anterior de glibc.

  • Para usar las mejoras de la ruta de búsqueda con Google Kubernetes Engine, debes usar la versión de Google Kubernetes Engine 1.26 o posterior.

Verifica la versión de glibc

Para verificar la versión de glibc que usa tu VM, haz lo siguiente:

  1. Conéctate a tu VM de Linux.
  2. Ejecuta ldd --version para obtener la versión glibc.

Verifica la cantidad de dominios de búsqueda si usas glibc 2.25 o una versión anterior

  1. Conéctate a tu VM de Linux.

  2. Verifica si tu VM de Linux ya tiene 6 dominios en la ruta de búsqueda. Puedes ejecutar cat /etc/resolv.conf para ver esta información.

Pasos del administrador de la organización

Como administrador de la organización, realizas las siguientes tareas:

Verifica si tu organización usa DNS global de forma predeterminada

El tipo predeterminado de nombre de DNS interno de tu organización se determina según la fecha en que se creó la organización y si se aplica la restricción constraints/compute.setNewProjectDefaultToZonalDNSOnly de la política de la organización.

Console

  1. Ve a la página IAM y administración>Identidad y organización en la consola.

    Ve a Identidad y organización.

  2. Verifica la fecha de registro de la organización.

    Captura de pantalla de la página Identidad y organización de la consola en la que se muestra la fecha de registro completada

    • Si tu organización se creó después del 6 de septiembre de 2018, esta usa DNS zonal de forma predeterminada. En ese caso, no deberá realizar ninguna acción.
    • Si tu organización se creó antes del 6 de septiembre de 2018, usa DNS global de forma predeterminada y se debe migrar al DNS zonal.

  3. Si tu organización usa DNS global de forma predeterminada, verifica si una restricción de la política de la organización establece el tipo de DNS predeterminado para todos los proyectos creados recientemente en DNS zonal.

    1. Ve a la página IAM y administración>Políticas de la organización en la consola de Google Cloud.
    2. En el campo Filtro, ingresa constraints/compute.setNewProjectDefaultToZonalDNSOnly.
    3. Si la restricción está configurada, haz clic en el nombre Establece la configuración de DNS interno para proyectos nuevos solo en DNS zonal.
    4. En la página Detalles de la política, verifica el Estado.
      • Si el estado es Forzado, el tipo de DNS interno predeterminado es DNS zonal para todos los proyectos nuevos que se crean en la organización.
      • De lo contrario, el tipo de DNS predeterminado del proyecto aún se determina mediante la hora de creación de la organización.
    5. Si la restricción no se configuró para la organización, el tipo de DNS predeterminado del proyecto se determina con la hora de creación de la organización, como se describe en el primer paso.

gcloud

Usa el comando organizations describe y el comando resource-manager org-policies list para determinar el tipo de DNS predeterminado para una organización.

  1. Verifica el valor de metadatos creationTime de la organización.

    gcloud organizations describe ORGANIZATION_ID

    Reemplaza ORGANIZATION_ID por el número de ID de la organización o el nombre de dominio de la organización.

    • Si tu organización se creó después del 6 de septiembre de 2018, esta usa DNS zonal de forma predeterminada. En este caso, tu organización ya usa DNS zonal y no es necesario realizar ninguna otra acción.
    • Si tu organización se creó antes del 6 de septiembre de 2018, usa el DNS global de forma predeterminada y se debe migrar al DNS zonal.

  2. Si tu organización usa DNS global de forma predeterminada, determina si se configuró una restricción de política de la organización para establecer el tipo de DNS predeterminado de todos los proyectos creados recientemente en DNS zonal.

    gcloud resource-manager org-policies list --organization=ORGANIZATION_ID \
   --filter="constraints/compute"

    En el resultado, busca constraints/compute.setNewProjectDefaultToZonalDNSOnly.

    1. Si la restricción está configurada y Status es Enforced, el tipo de DNS interno predeterminado es DNS zonal para todos los proyectos nuevos creados en la organización.
    2. Si la restricción no se configuró para la organización o no se aplica, el tipo de DNS interno predeterminado se determina con la hora de creación de la organización, como se describe en el primer paso.

Determina qué proyectos en una organización o carpeta usan el DNS global

Para determinar cuántos proyectos usan el DNS global, recomendamos usar BigQuery para crear una tabla que enumere los proyectos relativos para tu organización y sus metadatos. Luego, puedes usar esta tabla para ejecutar una consulta que exponga el recuento total de proyectos que usan DNS global.

  1. Crea un conjunto de datos de BigQuery.

  2. Exporta los metadatos de los recursos de tu organización a una tabla de BigQuery.

    1. Asegúrate de que la API de Cloud Asset Inventory esté habilitada.
    2. Configura los permisos necesarios para usar la API de Cloud Asset Inventory.

    3. Usa el siguiente comando de gcloud CLI para exportar el elemento compute.googleapis.com/Project:

      gcloud asset export \
   --content-type resource \
   --organization 'ORGANIZATION_ID' \
   --bigquery-table 'projects/PROJECT_ID/datasets/DATASET_ID/tables/TABLE_NAME' \
   --asset-types='compute.googleapis.com/Project' \
   --output-bigquery-force

      Reemplaza lo siguiente:

      • ORGANIZATION_ID: El número de ID de la organización
      • PROJECT_ID: el ID del proyecto
      • DATASET_ID: El nombre del conjunto de datos de BigQuery
      • TABLE_NAME: Es la tabla a la que exportarás tus metadatos. Si la tabla no existe, se creará.

  3. Ve a la página deBigQuery en la consola de Google Cloud.

  4. Selecciona Redactar una nueva consulta.

  5. En el área de texto del editor de consultas, ingresa la siguiente consulta de GoogleSQL y, luego, haz clic en Ejecutar.

    SELECT
  JSON_VALUE(SAFE.PARSE_JSON(resource.data).vmDnsSetting) AS vmDnsSetting,
  count(*) as project_count
FROM PROJECT_ID.DATASET_ID.TABLE_NAME
GROUP BY 1

    Reemplaza lo siguiente:

    • PROJECT_ID: el ID del proyecto
    • DATASET_ID: El nombre del conjunto de datos de BigQuery
    • TABLE_NAME: La tabla que contiene los metadatos exportados del paso 2.

    Los proyectos con el valor ZONAL_ONLY para vmDnsSetting tienen configurado el DNS zonal. De lo contrario, los proyectos se configuran para usar DNS global.

  6. Opcional: para obtener una vista detallada de vmDnsSetting en cada proyecto, ingresa la siguiente consulta de GoogleSQL y, luego, haz clic en Ejecutar.

    SELECT
  SUBSTR(name,35) as project_id,
  JSON_VALUE(SAFE.PARSE_JSON(resource.data).vmDnsSetting) AS vmDnsSetting
FROM PROJECT_ID.DATASET_ID.TABLE_NAME

Determina si una carpeta está lista para migrar al DNS zonal

En este paso, se usa una secuencia de comandos bash y la tabla de BigQuery creada en la sección anterior para determinar el nivel de preparación para la migración de la carpeta.

  • La carpeta está lista si todos los proyectos no realizaron ninguna consulta incompatible con el DNS zonal en los últimos 30 días.
  • Si una carpeta no está lista para la migración, la secuencia de comandos responde con los IDs del proyecto en la carpeta que hace que la carpeta no esté lista para la migración. Los proyectos de esta lista de resultados aún no son compatibles con el DNS zonal y requieren acciones adicionales.

Completa los siguientes pasos:

  1. Obtén el ID de la carpeta. Si no conoces el ID de la carpeta, haz lo siguiente:
    1. En la consola de Google Cloud, ve a la página Recursos administrados.
    2. Aplica el filtro Name:FOLDER_NAME para obtener el ID de la carpeta.

  2. Consulta la tabla de BigQuery con los datos de compute.Project assets exportados.

    Consulta Determina qué proyectos en una organización o carpeta usan el DNS global para obtener instrucciones acerca de cómo crear la tabla de BigQuery.

    Ingresa la siguiente consulta de GoogleSQL y, luego, haz clic en  Ejecutar:

    SELECT
  SUBSTR(name,35) AS project_id,
FROM PROJECT_ID.DATASET_ID.TABLE_NAME
WHERE CONTAINS_SUBSTR(ancestors, 'FOLDER_NUMBER')

    Reemplaza lo siguiente:

    • PROJECT_ID: el ID del proyecto
    • DATASET_ID: El nombre del conjunto de datos de BigQuery
    • TABLE_NAME: Es la tabla que contiene los metadatos exportados.
    • FOLDER_NUMBER: El número de ID de la carpeta

  3. Copia la lista de IDs de proyecto y guárdala en un archivo.

  4. Ejecuta la siguiente secuencia de comandos bash: La secuencia de comandos itera en los IDs del proyecto en el archivo guardado para determinar si una carpeta está lista para la migración.

#!/bin/bash
inaccessible_projects=()
unready_projects=()

for project in $(cat ~/FILENAME | tr '\n' ' '); do
  echo -e "Checking project $project..."
  ERROR=`curl -s --request POST "https://monitoring.googleapis.com/v3/projects/$project/timeSeries:query"   -H "Authorization: Bearer $(gcloud auth print-access-token)"   -H "Accept: application/json"   -H "Content-Type: application/json"   --data '{"query":"fetch compute.googleapis.com/Location | metric '"'"'compute.googleapis.com/global_dns/request_count'"'"' | filter metric.zonal_dns_readiness = '"'"'zonal_dns_risky'"'"' | every 30d | within 30d"}'   --compressed | jq --raw-output '.error'`
  if ! [[ "$ERROR" -eq "null" ]]; then
    inaccessible_projects+=($project)
    continue
  fi
  QUERY_COUNT=`curl -s --request POST "https://monitoring.googleapis.com/v3/projects/$project/timeSeries:query"   -H "Authorization: Bearer $(gcloud auth print-access-token)"   -H "Accept: application/json"   -H "Content-Type: application/json"   --data '{"query":"fetch compute.googleapis.com/Location | metric '"'"'compute.googleapis.com/global_dns/request_count'"'"' | filter metric.zonal_dns_readiness = '"'"'zonal_dns_risky'"'"' | every 30d | within 30d"}'   --compressed | jq --raw-output '.timeSeriesData[0].pointData[0].values[0].int64Value'`
  if [[ "$QUERY_COUNT" -ne "null" ]] && [[ "$QUERY_COUNT" -ne "0" ]]; then
    unready_projects+=($project)
  fi
done

error_len=${#inaccessible_projects[@]}
unready_len=${#unready_projects[@]}

echo -e "$error_len projects were inaccessible"
echo -e "$unready_len projects were not ready for migration"

if [ $error_len -ne 0 ]; then
  echo "Unable to access the following projects:"
  for project in "${inaccessible_projects[@]}"; do
    echo "$project"
  done
fi
if [ $unready_len -ne 0 ]; then
  echo "The following projects are not ready for migration:"
  for project in "${unready_projects[@]}"; do
    echo "$project"
  done
fi

if (( $error_len + $unready_len > 0 )); then
  echo "This folder is NOT ready for gDNS -> zDNS migration."
else
  echo "This folder is ready for gDNS -> zDNS migration."
fi

Reemplaza FILENAME por el nombre del archivo en el que guardaste la lista de IDs de proyectos.

Comunica los resultados del análisis de preparación para la migración a los propietarios del proyecto:

Aplica el DNS zonal de forma predeterminada para proyectos nuevos

Si se crea un proyecto nuevo en una organización creada antes del 6 de septiembre de 2018, el tipo de DNS interno que usa el proyecto es DNS global de forma predeterminada. Para aislar las fallas del registro DNS en zonas individuales, puedes aplicar la política de la organización constraints/compute.setNewProjectDefaultToZonalDNSOnly a nivel de la organización o de la carpeta.

Cuando configuras una política de la organización para anular el tipo de DNS interno predeterminado, los proyectos recién creados usan DNS zonal de forma predeterminada. La política de la organización no afecta los proyectos existentes en los que la API de Compute Engine ya está habilitada. Para cambiar los proyectos existentes para usar DNS zonal, consulta Cambia proyectos existentes a DNS zonal.

Para aplicar este cambio en la política, debes tener acceso a nivel de carpeta o de organización con el rol de IAM roles/orgpolicy.policyAdmin.

Realiza los siguientes pasos para establecer la política de la organización de una organización o carpeta:

  1. Accede a la consola de Google Cloud como un administrador avanzado de Google Workspace o Cloud Identity.

  2. En la consola, ve a la página Políticas de la organización.

    Ir a Políticas de la organización

  3. Selecciona la organización o carpeta cuyas políticas de la organización deseas ver. En la consola de Google Cloud, se muestra una lista de las restricciones de la política de la organización que están disponibles. La lista puede abarcar varias páginas.

  4. Para buscar la política que aplica el DNS zonal, haz clic en Filtro y selecciona Nombre y, luego, configura el nombre del filtro como Establece la configuración de DNS interno para proyectos nuevos solo en DNS zonal.

  5. Haz clic en el nombre de la política para ver sus detalles.

    En la página de detalles de la política, se proporciona información de la limitación y cómo esta se aplica en este momento.

    De forma predeterminada, la aplicación no está definida para una organización o carpeta. Sin embargo, si una carpeta superior tiene una aplicación definida, la aplicación se hereda de la carpeta superior más cercana que tiene una aplicación definida. Para obtener más información, consulta Comprende la evaluación de jerarquías.

  6. Para personalizar la política de la organización, haz clic en Editar.

  7. En la página de edición, selecciona Personalizar.

  8. En Aplicación, selecciona Activado.

    Esto establece el tipo de DNS interno predeterminado para todos los proyectos nuevos de la organización en DNS zonal.

  9. Haz clic en Guardar.

Para validar el cambio de la política de la organización, puedes crear un nuevo proyecto en la organización o carpeta y, luego, crea y luego inicia una instancia de VM y verificar si tu VM está habilitada para el DNS zonal.

Si se necesita un DNS global interno para resolver una consulta de nombre de DNS integrada en tu carga de trabajo, puedes revertir este cambio a nivel de la organización o de la carpeta a través de la inhabilitación de la aplicación.

Carpetas exentas que no están listas para migrar a DNS zonal

Si solo hay algunas carpetas dentro de una organización que no están listas para migrar a DNS zonal, recomendamos configurar una política de la organización a nivel de la organización, pero otorgar una exención para carpetas que aún no están listas para migrar.

En el siguiente ejemplo, se muestra una jerarquía de organización en la que solo una carpeta no está lista para migrar al DNS zonal.

organización/Example.com

  • folders/101
    • projects/301 (lista para la migración)
    • folders/201
      • projects/303 (NO lista)
      • projects/304 (lista para la migración)
  • folders/102
    • projects/302 (lista para la migración)

Para eximir una carpeta de la política de la organización, completa los siguientes pasos para establecer la opción de aplicación de la política en el nivel de la carpeta en Off.

  1. Accede a la consola de Google Cloud como un administrador avanzado de Google Workspace o Cloud Identity.

  2. En la consola, ve a la página Políticas de la organización.

    Ir a Políticas de la organización

  3. Haz clic en Seleccionar y, luego, selecciona las carpetas que deseas exentar de la política de la organización.

    La consola de Google Cloud muestra una lista de las restricciones de la política de la organización para esa carpeta en una o más páginas.

  4. Para encontrar la restricción de la política de la organización que aplica el DNS zonal, haz lo siguiente:

    1. Haz clic en Filtrar.
    2. Selecciona Nombre.
    3. Establece el nombre del filtro en Establece la configuración de DNS interno para proyectos nuevos solo en DNS zonal.

  5. Haz clic en el nombre de la restricción de la política de la organización para abrir la página Detalles de la política.

  6. Haz clic en Editar.

  7. En la página Editar, selecciona Personalizar.

  8. En Aplicación forzosa, selecciona Desactivada para inhabilitar la aplicación forzosa de la restricción. Esto significa que el tipo de DNS interno predeterminado para todos los proyectos de la carpeta se determina según la hora de creación de la organización.

  9. Haz clic en Guardar.

Para obtener más información sobre cómo personalizar las restricciones de las políticas de la organización, consulta Personaliza políticas para restricciones booleanas en la documentación de Resource Manager.

Pasos del propietario del proyecto

Como propietario del proyecto, realizas las siguientes tareas durante la migración del DNS global al DNS zonal:

Los propietarios del proyecto también pueden completar estas tareas opcionales:

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 el predeterminado para cualquier nombre de DNS interno creado dentro del proyecto.

Console

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

    Ir a metadatos

  2. En la pestaña Metadata, consulta la configuración de vmdnssetting. El valor 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.

gcloud

    In the Google Cloud console, activate Cloud Shell.

    Activate Cloud Shell

    At the bottom of the Google Cloud console, a Cloud Shell session starts and displays a command-line prompt. Cloud Shell is a shell environment with the Google Cloud CLI already installed and with values already set for your current project. It can take a few seconds for the session to initialize.

  1. 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 devuelto indica si el proyecto usa 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

Verifica el valor de vmDnsSetting con el método projects.get. En este ejemplo, se usa un parámetro de consulta fields 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.

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

Determina si tu proyecto está listo para migrar

En la página Instancias de VM de la consola de Google Cloud, si tu proyecto necesita migrar a DNS zonal, deberías ver un banner de notificación sobre la migración de DNS zonal.

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

Captura de pantalla del banner listo para migrar al DNS zonal en la consola

Si tu proyecto no está listo para migrar a DNS zonal, aparecerá un banner diferente.

Captura de pantalla del banner que indica que no se puede migrar a DNS zonal en la consola

Para ver el uso de DNS global, haz clic en el botón Ver uso de DNS global. Esto te llevará a la página Explorador de registros en la consola de Google Cloud. En esta página, puedes ver los registros de consultas de bloqueo de migración de los últimos 30 días. Cuando haces clic en el vínculo en el banner, la página Explorador de registros se configura para usar el filtro logName para extraer consultas de DNS globales y campos de registro relativos.

Para ver esta información sin usar el botón del banner, haz lo siguiente:

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

    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.

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"

Realiza un seguimiento del uso de DNS global dentro del proyecto

Se crean dos métricas para realizar un seguimiento de la preparación del proyecto para migrar al DNS zonal:

  • zonal_dns_ready: La cantidad agregada de consultas completadas en el intervalo de tiempo especificado que se puede resolver con el DNS zonal en lugar de DNS global.
  • zonal_dns_risky: La cantidad total de consultas completadas durante el intervalo de tiempo especificado que no se pueden resolver con el DNS zonal. Para estas consultas, Compute Engine no pudo determinar la dirección IP interna relativa del nombre de host actual. Si esta métrica tiene un valor distinto de cero, el proyecto no está listo para la migración.

El intervalo de tiempo que usan estas métricas es de 100 días.

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

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

    Ir 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á títulado Consulta de MQL, entonces en la esquina inferior derecha del campo de entrada de la consulta para Lenguaje, selecciona MQL.

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

  5. 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 y zonal_dns_risky) y la cantidad correspondiente de consultas realizadas durante el período de cada métrica.

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

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

Migra proyectos que estén listos al DNS zonal

En general, puedes usar el siguiente proceso de migración:

  1. Verifica tus aplicaciones y actualízalas para resolver problemas de compatibilidad con la configuración zonal exclusiva:
    • Si tienes alguna aplicación que use nombres de DNS globales hard-coded, actualízala para que use nombres de DNS zonales.
    • Si alguna aplicación usa nombres de VM para acceder a las VMs en otra zona, asegúrate de agregar el nombre de la zona de destino en la consulta, por ejemplo: DESTINATION_VM_NAME.DESTINATION_ZONE_NAME.
    • Para resolver nombres de DNS de las VMs en proyectos de servicio que usan una red de VPC compartida, debes usar el nombre de dominio zonal completamente calificado (FQDN) de las VMs.

  2. Haz clic en el botón Usar DNS zonal en el banner de la página Instancias de VM de la consola de Google Cloud. Esto cambia los metadatos del proyecto para usar el DNS zonal.

    Como alternativa, puedes modificar de forma manual tus proyectos para que usen DNS zonal de forma predeterminada, como se describe en Actualiza proyectos y VMs de forma manual para que usen DNS zonal y Evita que proyectos nuevos usen DNS global de forma predeterminada.

Actualiza los proyectos y las VMs de forma manual para que usen DNS zonal

Cuando hayas determinado que tu proyecto está listo para migrar a DNS zonal, puedes configurar el proyecto y las VMs para usar solo nombres DNS zonales con la actualización de sus metadatos. Habilita el DNS zonal para tus VMs con la configuración de la entrada de metadatos vmDnsSetting para el proyecto o la VM. Si configuras la entrada de metadatos vmDnsSetting para una VM específica, se anulará cualquier configuración de vmDnsSetting heredada de los metadatos del proyecto de esa VM.

La variable vmDnsSetting admite la siguiente configuración:

  • Recomendado: Configura vmDnsSetting=ZonalOnly en los metadatos del proyecto. Esto significa que solo se puede acceder a tus VMs a través de sus nombres de DNS zonales (VM_NAME.ZONE.c.PROJECT_ID.internal) cuando se usan rutas de búsqueda. Las VMs aún 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 VMs de la misma zona y el mismo proyecto pueden acceder entre sí con el nombre global cuando se implementa este parámetro de configuración. Otras VMs solo pueden acceder a las VMs con vmDnsSetting configurado en ZonalOnly a través de sus nombres de DNS zonales y no pueden acceder a estas VMs con sus rutas de búsqueda o nombres de DNS globales. Esta es la opción preferida y más confiable, siempre que tus apps la admitan.

    La configuración vmDnsSetting=ZonalOnly es la predeterminada para VMs en proyectos independientes y proyectos creados en una organización que habilitó la API de Compute Engine después del 6 de septiembre de 2018.

  • Configura vmDnsSetting=GlobalDefault para que las VMs registren nombres DNS globales y zonales, pero solo usen nombres globales como nombres de dominio predeterminados y entradas de ruta de búsqueda. Esta es la configuración predeterminada para VMs en proyectos independientes y proyectos creados en una organización que habilitó la API de Compute Engine antes del 6 de septiembre de 2018.

Consulta Establece metadatos personalizados para aprender a establecer valores de metadatos de VM o metadatos de proyecto.

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

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

Después de actualizar la asignación de tiempo de DHCP, verifica si tu VM está habilitada para el DNS zonal.

Modifica los proyectos que no están listos para migrar

Un proyecto que no está listo para migrar significa que se realizó al menos una consulta de DNS riesgosa en un período determinado, como en los últimos 30 días o en los últimos 100 días. Una consulta riesgosa es una llamada a una VM con un nombre de DNS global (VM_NAME.c.PROJECT_ID.internal) que no se puede resolver sin problemas con un nombre de DNS zonal (VM_NAME.ZONE.c.PROJECT_ID.internal). Las consultas riesgosas pueden tener los siguientes atributos:

  • Cómo realizar una llamada a una VM en un proyecto diferente
  • Cómo realizar una llamada a una VM en una zona diferente

En el caso de los proyectos con consultas riesgosas, por lo general, se necesita un trabajo adicional para eliminar todas las búsquedas de DNS riesgosas antes de la migración.

Para los proyectos que aún no están listos para la migración, completa los siguientes pasos:

  1. Habilita la mejora de la ruta de búsqueda para resolver búsquedas de nombres de DNS entre zonas. Esto podría preparar tus proyectos para la migración sin afectar tus recursos.
  2. Si el ajuste de la ruta de búsqueda no realiza la transición de todas tus consultas entre zonas, puedes actualizarlas de forma manual para que usen nombres de DNS zonales.

Información acerca de la función de mejora de la ruta de búsqueda

De forma predeterminada, la mayoría de las distribuciones de Linux guardan información de DHCP en resolv.conf. El siguiente es un resolv.conf file global mínimo:

domain c.PROJECT_ID.internal
search c.PROJECT_ID.internal. google.internal.
nameserver 169.254.169.254

La opción de configuración search se usa para enumerar los nombres de host que se usarán cuando se realice la resolución de DNS. El servidor DNS intenta resolver la consulta con cada uno de los nombres de host de la ruta de búsqueda hasta que se encuentra una coincidencia de registro de DNS. Por ejemplo, si una VM llama a ping my-vm, los dominios en la ruta de búsqueda se agregan a la consulta original para obtener los nombres de dominio completamente calificados (FQDN), por ejemplo, mediante my-vm.c.PROJECT_ID.internal. Si hay una coincidencia, el solucionador de DNS muestra una dirección IP interna en la respuesta. De lo contrario, intenta resolver el nombre de DNS con el siguiente dominio en la ruta de búsqueda.

Agregar dominios zonales adicionales en la ruta de búsqueda de la VM puede preparar algunos proyectos para la migración. Por ejemplo, supongamos que tu VM se encuentra en la zona us-west4-c. Esta VM realiza una llamada a otra VM llamada myapp-vm, que se encuentra en la zona us-west4-b.

  • Cuando haces una llamada a la VM como myapp-vm, Compute Engine intenta resolver el nombre de DNS con un FQDN que agrega una de las rutas de búsqueda al nombre de la VM, como myapp-vm.c.PROJECT_ID.internal.
  • Si la VM de destino usa DNS zonal, el FQDN de la VM de destino se registra como myapp-vm.us-west4-b.c.PROJECT_ID.internal. Como resultado, no se puede resolver el nombre de DNS.
  • Si agregas us-west4-b.c.PROJECT_ID.internal a la lista de búsqueda, el nombre DNS myapp-vm se puede resolver cuando se agrega us-west4-b.c.PROJECT_ID.internal al nombre de la VM.

Google proporciona una función de mejora de la ruta de búsqueda que busca automáticamente el nombre de DNS zonal de una VM en todas las zonas de la misma región que la VM. Como resultado, las consultas entre zonas se pueden resolver sin necesidad de actualizar el archivo resolv.conf ni la política de DHCP. Las mejoras en la ruta de búsqueda pueden ayudar a resolver las consultas entre zonas dentro de la región hasta en un 80% de los casos. Esta función debería ayudar a que la mayoría de los proyectos con consultas riesgosas estén listos para migrar al DNS zonal.

Habilita la mejora de la ruta de búsqueda para resolver las búsquedas de nombres de DNS entre zonas

Sigue estos pasos para habilitar la función de mejora de la ruta de búsqueda.

  1. Ejecuta el comando project-info add-metadata de la siguiente manera.

    gcloud compute project-info add-metadata  \
    --metadata=enable-search-path-improvement=true

  2. Permite que el proyecto use esta configuración durante unos días y, luego, verifica la métrica de supervisión para ver si aún hay consultas de DNS globales riesgosas o interzonales.

    • Si el valor del proyecto es 0, significa que el proyecto está listo para la migración.
    • Si el proyecto devuelve un valor distinto de cero, cambia todos los nombres de consulta de DNS globales para que usen el FQDN zonal, como se describe en la siguiente sección.

Actualiza las consultas de forma manual para usar nombres de DNS zonales

Si usar la función de mejora de la ruta de búsqueda para agregar dominios zonales adicionales en la ruta de búsqueda de nombres de DNS no realiza la transición de todas tus consultas entre zonas, puedes usar el Explorador de registros para ver el uso de DNS global dentro del proyecto.

Para identificar las consultas de DNS globales que se deben cambiar de forma manual para usar nombres de dominio zonales completamente calificados (FQDN), completa los siguientes pasos:

  1. Sigue los pasos que se indican en Determina si tu proyecto está listo para migrar para ver el uso de DNS global para un proyecto. Usa el Explorador de registros para acceder y consultar el uso de DNS global para las VMs de tu proyecto.

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

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

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

  3. Usa la información de jsonPayload 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:

  1. 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.
  2. Vuelve a verificar la métrica de supervisión para ver si se quitaron todas las consultas de DNS peligrosas.

Verifica que se haya completado la migración del proyecto al DNS zonal

  1. Repite los pasos que se indican en Cómo verificar si tu proyecto usa DNS global de forma predeterminada.

  2. Para probar que los metadatos del proyecto se actualizaron, puedes ejecutar el siguiente comando:

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

    El comando debería devolver ZONAL_ONLY.

  3. Verifica que el nombre de DNS interno de una VM use un nombre de DNS zonal.

  4. Para verificar que se aplique la política de la organización constraints/compute.setNewProjectDefaultToZonalDNSOnly, puedes hacer lo siguiente:

    1. Crea un proyecto nuevo en la carpeta o la organización.
    2. Crea y después inicia una instancia de VM
    3. Verifica si la VM usa un nombre de DNS zonal.

Vuelve a usar el 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 VM o el contenedor.

Vuelve a usar del DNS global para una organización o carpeta

Para revertir una organización o carpeta para usar DNS global, completa los siguientes pasos.

  1. Inhabilita la política de la organización constraints/compute.setNewProjectDefaultToZonalDNSOnly a nivel de la organización o la carpeta. Si deseas obtener instrucciones para modificar esta política, consulta Aplica el DNS zonal de forma predeterminada para proyectos nuevos.

    Establece la aplicación forzosa de Establece la configuración de DNS interno para proyectos nuevos solo en DNS zonal en Desactivado.

  2. Si deseas volver a usar el DNS global para toda la organización, verifica que ninguna de las carpetas de la organización aplique la política de la organización constraints/compute.setNewProjectDefaultToZonalDNSOnly.

  3. Usa las siguientes secciones para verificar que el DNS global esté configurado para proyectos, VMs y contenedores.

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.

    Consulta Establece metadatos personalizados para aprender a establecer valores de metadatos de VM o metadatos de proyecto.

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

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

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

Vuelve a usar del DNS global para una VM

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

  1. Agrega lo siguiente a los metadatos de la VM: vmDnsSetting=GlobalDefault.

    Para obtener información acerca de cómo establecer valores de metadatos de VM, consulta Establece metadatos personalizados.

  2. Para forzar el cambio de configuración de DNS, reinicia la red de la VM a través de 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

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 de DNS global a DNS zonal

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

Cómo ocultar el banner de migración de DNS zonal en la consola de Google Cloud

Puedes hacer clic en el botón Descartar en el banner de notificación de migración de DNS zonal que aparece en la página Instancias de VM de la consola de Google Cloud. Esto evita que el banner aparezca en el proyecto de forma indefinida.

Si rechazaste el banner, pero quieres que vuelva a aparecer, comunícate con Atención al cliente de Cloud para obtener ayuda.

¿Qué sigue?