Usa el DNS zonal para tu tipo de DNS interno

El DNS zonal mitiga el riesgo de interrupciones interregionales y mejora la confiabilidad general de los 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 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.

    Selecciona la pestaña para saber cómo planeas usar las muestras en esta página:

    Consola

    Cuando usas la consola de Google Cloud para acceder a los servicios y las APIs de Google Cloud, no necesitas configurar la autenticación.

    gcloud

    1. Instala Google Cloud CLI y, luego, inicializa la ejecución del siguiente comando: 

      gcloud init
    2. Configura una región y una zona predeterminadas.

    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.

      Instala Google Cloud CLI y, luego, inicializa la ejecución del siguiente comando: 

      gcloud init

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:

Si quieres obtener más información sobre cómo otorgar roles, consulta Administra el acceso.

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 al 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 los metadatos en una VM: compute.instances.setMetadata
  • Establece metadatos para 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 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 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 DNS zonal.

El DNS zonal es el método de resolución de DNS interno predeterminado para Compute Engine para 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 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 DNS global, pero Google recomienda que las organizaciones migren estos proyectos a DNS zonal para evitar que las interrupciones del servicio en otra región afecten a 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 en una sola zona, y los recursos y los costos no se ven afectados de manera significativa.

Migra 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 DNS global es migrar a las zonas privadas de Cloud DNS. El uso de las zonas privadas de Cloud DNS quita la verificación de unicidad del nombre 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 de DNS zonal tiene dos niveles:

  • Nivel de organización o carpeta: determina la preparación de la organización o la carpeta para migrar al DNS zonal. Evita que los proyectos nuevos usen un DNS global. Lo realiza el administrador de la organización.
  • Nivel de proyecto: migra un solo proyecto del DNS global a DNS zonal. Por lo general, el propietario del proyecto lo realiza.

La imagen muestra un diagrama de flujo de los pasos que debes realizar para migrar a DNS zonal

Por lo general, el proceso implica los siguientes pasos:

  1. Verifica la preparación de la organización o la carpeta para la migración a DNS zonal.
  2. Si la organización o 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 del proyecto migran sus proyectos para usar DNS zonal.
  3. Si la organización o carpeta no está lista para migrar a DNS zonal:
    1. Los propietarios del proyecto migran los proyectos listos a DNS zonal.
    2. Los propietarios del proyecto investigan el uso global del DNS en proyectos que 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 es un reemplazo completo del 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 la preparación de la migración de las carpetas y proyectos de tu organización para asegurarte de que sean compatibles con DNS zonal antes de la migración.

  • El proceso de migración del DNS global a DNS zonal presenta 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 o superior de glibc. Los clientes DHCP con glibc 2.25 y versiones anteriores solo admiten hasta 6 dominios de búsqueda, por lo que podría haber un 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 posteriores
    • Fedora CoreOS (versión 27 o posterior)
    • Imágenes de RHEL 8 o posteriores
    • Imágenes de Ubuntu versión 18.04 o posteriores
    • Otras imágenes con glibc versión 2.26 o posterior

  • Habilitar la mejora de la ruta de búsqueda agrega 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 excede el límite de dominio de la ruta de búsqueda cuando se usa la versión 2.25 de glibc o una anterior.

  • 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, sigue estos pasos:

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

Comprueba 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. Comprueba 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, debes realizar las siguientes tareas:

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

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

Consola

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

    Ir a Identidad y organización

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

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

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

  3. Si tu organización usa DNS global de forma predeterminada, verifica si una restricción de política de la organización establece el tipo de DNS predeterminado para todos los proyectos recién creados 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 se establece la restricción, 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 Aplicada, el tipo de DNS interno predeterminado es DNS zonal para todos los proyectos nuevos creados en la organización.
      • De lo contrario, el tipo de DNS predeterminado para el proyecto aún se determina según 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 según 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, tu organización usa DNS zonal de forma predeterminada. En este caso, tu organización ya usa un DNS zonal y no es necesario que realices ninguna otra acción.
    • Si la organización se creó antes del 6 de septiembre de 2018, la organización usa DNS global de forma predeterminada y debe migrarse a DNS zonal.

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

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

    En el resultado, busca constraints/compute.setNewProjectDefaultToZonalDNSOnly.

    1. Si se establece la restricción 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 de una organización o carpeta usan un 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 de proyectos totales que usan DNS global.

  1. Crea un conjunto de datos de BigQuery.

  2. Exporta los metadatos del activo 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 los 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 un DNS zonal configurado. 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 a 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 la preparación de la migración de la carpeta.

  • La carpeta está lista si todos los proyectos no realizaron ninguna consulta que sea 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 DNS zonal y requieren una acción adicional.

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: la tabla que contiene los metadatos exportados
    • FOLDER_NUMBER: Es el número de ID de la carpeta.

  3. Copia la lista de ID de proyectos 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 ID del proyecto.

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

Aplica 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 cualquier falla en el registro DNS en zonas individuales, puedes aplicar la política de la organización constraints/compute.setNewProjectDefaultToZonalDNSOnly a nivel de organización o 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. La consola de Google Cloud 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 en la organización como 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.

Las carpetas exentas 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 la organización en la que solo una carpeta no está lista para migrar a 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 eximir de la política de la organización.

    La consola de Google Cloud muestra una lista de restricciones de las políticas 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 DNS zonal, ejecuta el siguiente comando:

    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, selecciona Desactivar para inhabilitar la aplicación de la restricción. Esto significa que el tipo de DNS interno predeterminado para todos los proyectos en la carpeta está determinado por el momento 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 para el propietario del proyecto

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

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

Verifica si tu proyecto usa DNS global de forma predeterminada

Revisa tus proyectos para ver si necesitan migrar de DNS global a DNS zonal. Solo debes migrar los proyectos configurados para usar DNS global como predeterminado para cualquier nombre de DNS interno creado dentro del proyecto.

Consola

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

    Ir a metadatos

  2. En la pestaña Metadatos, consulta la configuración de vmdnssetting. El valor indica si el proyecto usa DNS global de forma predeterminada.

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

gcloud

    En la consola de Google Cloud, activa Cloud Shell.

    Activar Cloud Shell

    En la parte inferior de la consola de Google Cloud, se inicia una sesión de Cloud Shell en la que se muestra una ventana de línea de comandos. Cloud Shell es un entorno de shell con Google Cloud CLI ya instalada y con valores ya establecidos para el proyecto actual. La sesión puede tardar unos segundos en inicializarse.

  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 DNS global.
    • ZONAL_ONLY: El proyecto tiene DNS zonal habilitado. 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 un DNS global.
  • ZONAL_ONLY: El proyecto tiene DNS zonal habilitado. 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 ves la página Instancias de VM de tu proyecto, si tu proyecto está listo para la migración (compatible con DNS zonal), el banner incluye un recomendación para usar DNS zonal. Esta recomendación se basa en el uso de DNS interno en el proyecto, pero se limita a los últimos 100 días.

Una 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, aparece un banner diferente.

Una captura de pantalla del banner no listo para la migración 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, se puede ver la migración que bloquea los registros de consulta 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 en el 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 nombre de recurso y 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"

Realizar un seguimiento del uso de DNS global en el 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 a partir del nombre de host actual. Si esta métrica tiene un valor distinto de cero, el proyecto no estará listo para la migración.

El intervalo 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 el panel de navegación de la consola de Google Cloud, selecciona Monitoring y, luego,  Explorador de métricas:

    Ir al Explorador de métricas

  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 tal 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 métricas de uso de DNS globales

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

Migra proyectos que estén listos para el 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 una aplicación que usa nombres de DNS globales hard-coded, actualízalos para que usen 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 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 anula cualquier configuración vmDnsSetting heredada de los metadatos del proyecto para esa VM.

La variable vmDnsSetting admite la siguiente configuración:

  • Recomendación: Configura vmDnsSetting=ZonalOnly en los metadatos del proyecto. Esto significa que solo se puede acceder a tus VMs a través de sus nombres DNS zonales (VM_NAME.ZONE.c.PROJECT_ID.internal). 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 funciona. 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 abordar 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 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 que usa un nombre DNS global (VM_NAME.c.PROJECT_ID.internal) que no se puede resolver sin problemas mediante un nombre DNS zonal (VM_NAME.ZONE.c.PROJECT_ID.internal). Las consultas riesgosas pueden tener los siguientes atributos:

  • Realiza una llamada a una VM en un proyecto diferente
  • Realiza una llamada a una VM en una zona diferente

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

En el caso de los proyectos que 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 puede hacer que tus proyectos estén listos 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 actualizar de forma manual las consultas para que usen nombres DNS zonales.

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. A continuación, se muestra un resolv.conf file global simple:

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 en la ruta de búsqueda hasta que se encuentra una coincidencia del registro 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 agente de resolución de DNS muestra una dirección IP interna en la respuesta. De lo contrario, intentará 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 VM puede preparar algunos proyectos para la migración. Por ejemplo, supongamos que tu VM está ubicada 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 realizas una llamada a la VM como myapp-vm, Compute Engine intenta resolver el nombre de DNS mediante 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.interno. Como resultado, el nombre de DNS no se puede resolver.
  • Si agregas us-west4-b.c.PROJECT_ID.internal a la lista de búsqueda, el nombre de DNS myapp-vm se puede resolver cuando us-west4-b.c.PROJECT_ID.internal se agrega al nombre de la VM.

Google proporciona una función de mejora de la ruta de búsqueda que busca de forma automática el nombre DNS zonal para 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 o la política de DHCP. Las mejoras en la ruta de búsqueda pueden funcionar para resolver consultas entre zonas dentro de la región hasta el 80% del tiempo. Esta característica debería ayudar a la mayoría de los proyectos con consultas riesgosas a estar listos para migrar a DNS zonal.

Habilita la mejora de la ruta de búsqueda para resolver 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, el proyecto ahora está listo para migrar.
    • 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 DNS zonales

Si usas 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 se realizan 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 del proyecto y el nombre de la zona
    • El 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 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"

    • Un recuento de consultas que muestra cuántas migraciones de bloqueo de migración envían consultas a la VM de origen a la VM de destino para ese día.

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

    Captura de pantalla de los resultados de la consulta de registro jsonPayload en el 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 en los que 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 del DNS se almacena en caché, solo tienes que hacer 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 mediante un cambio de código o de configuración en Terraform.
    • VMs en proyectos de servicio que usan una red de VPC compartida: para resolver 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 se deberían mostrar 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 riesgosas.

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

  1. Repite los pasos en Verifica 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 nuevo proyecto en la organización o carpeta.
    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 a DNS zonal, cambia el tipo de DNS interno predeterminado a DNS global. Puedes hacerlo a nivel de la organización, el proyecto, la VM o el contenedor.

Vuelve al uso 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 carpeta. Si deseas obtener instrucciones para modificar esta política, consulta Aplica un DNS zonal de forma predeterminada para proyectos nuevos.

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

  2. Si deseas volver a usar 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 al uso del DNS global para un proyecto

Para revertir un proyecto a 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 a 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:

    sudo systemctl restart network

  • Para Debian:

    sudo systemctl restart networking

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

Oculta 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 aparezca el banner para el proyecto de forma indefinida.

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

¿Qué sigue?