将可用区级 DNS 用于您的内部 DNS 类型

可用区级 DNS 可降低跨区域服务中断的风险，并提高项目在 Compute Engine 上的整体可靠性。使用可用区级 DNS 可降低使用全球 DNS 时可能出现的单点故障的影响。

准备工作

  • 设置身份验证（如果尚未设置）。身份验证是通过其进行身份验证以访问 Google Cloud 服务和 API 的过程。如需从本地开发环境运行代码或示例，您可以按如下方式向 Compute Engine 进行身份验证。

    选择标签页以了解您打算如何使用本页面上的示例：

    控制台

    当您使用 Google Cloud 控制台访问 Google Cloud 服务和 API 时，无需设置身份验证。

    gcloud

    1. 安装 Google Cloud CLI，然后通过运行以下命令初始化 Google Cloud CLI： 

      gcloud init
    2. 设置默认区域和可用区。

    REST

    如需在本地开发环境中使用本页面上的 REST API 示例，请使用您提供给 gcloud CLI 的凭据。

      安装 Google Cloud CLI，然后通过运行以下命令初始化 Google Cloud CLI： 

      gcloud init

所需的角色

如需获得迁移到可用区级 DNS 所需的权限，请让您的管理员为您授予以下 IAM 角色：

  • 创建或更新组织政策：针对文件夹或组织的 Organization Policy Administrator (roles/orgpolicy.policyAdmin)
  • 确定文件夹是否已准备好迁移到可用区级 DNS：针对文件夹或组织的 Browser (roles/browser)
  • 迁移项目以使用可用区级 DNS：针对项目的 Project Editor (roles/resourcemanager.projectEditor)
  • 将虚拟机迁移到项目中的可用区级 DNS：针对项目的 Compute Instance Admin (v1) (roles/compute.instanceAdmin.v1)
  • 如果您的虚拟机使用服务账号：针对服务账号或项目的 Service Account User (roles/iam.serviceAccountUser)

如需详细了解如何授予角色，请参阅管理访问权限。

这些预定义角色可提供迁移到可用区级 DNS 所需的权限。如需查看所需的确切权限，请展开所需权限部分：

所需权限

迁移到可用区级 DNS 需要以下权限：

  • 设置组织政策限制条件： orgpolicy.*
  • 确定文件夹是否已准备好迁移到可用区级 DNS：
    • resourcemanager.folders.get
    • resourcemanager.folders.list
    • resourcemanager.organizations.get
    • resourcemanager.projects.get
    • resourcemanager.projects.list
  • 检查全球 DNS 名称和虚拟机元数据： compute.projects.get
  • 在虚拟机上设置元数据： compute.instances.setMetadata
  • 设置项目范围的元数据： compute.projects.setCommonInstanceMetadata
  • 如果您的虚拟机使用服务账号： iam.serviceAccounts.actAs

您也可以使用自定义角色或其他预定义角色来获取这些权限。

关于 DNS 名称

可用区级 DNS 名称包括虚拟机的名称、虚拟机所在的可用区及拥有虚拟机的项目。全球 DNS 名称不包含虚拟机所在的可用区。

使用全球 DNS 名称调用虚拟机时：

  • 该名称会在全球级层解析。
  • 每个虚拟机都必须具有唯一的 DNS 名称。
  • 创建新虚拟机时，您必须对照在同一项目中注册的所有其他全球 DNS 名称检查虚拟机的 DNS 名称，以避免 DNS 名称冲突。

使用可用区级 DNS 名称调用虚拟机时：

  • 该名称会在可用区内解析。
  • 可用区级 DNS 名称在可用区内必须是唯一的。例如，my-vm.zone1.google.com 对于 zone1 来说必须是唯一的。但是，与全球 DNS 名称不同，使用可用区级 DNS 时，my-vm.zone2.google.com 也是有效的 DNS 名称。

对于 2018 年 9 月 6 日之后创建的组织，可用区级 DNS 是 Compute Engine 的默认内部 DNS 解析方法。一个可用区中的可用区级 DNS 名称是独立于其他可用区使用的，这使您可以构建更多可用性更好的容错型多区域级应用。可用区级 DNS 可免费使用。可用区级 DNS 与 Cloud DNS 是分开的。

2018 年 9 月 6 日之前创建的项目已默认配置为使用全球 DNS。这些项目可以继续使用全球 DNS，但 Google 强烈建议组织将这些项目迁移到可用区级 DNS，以防止其他区域的服务中断影响本地区域级资源。与全球 DNS 相比，使用可用区级 DNS 可将 DNS 注册过程中的故障隔离到单个可用区，从而提供更高的可靠性。这样可以降低单点故障的影响。如果 Google Cloud 发生服务中断，它会隔离到单个可用区，并且资源和费用不会受到显著影响。

从全球 DNS 迁移到可用区级 DNS

2018 年 9 月 6 日之后，Google Cloud 上加入的所有新组织的默认内部 DNS 类型已从全球 DNS 更改为可用区级 DNS。如果现有项目仍在使用全球 DNS，Google 强烈建议将这些项目切换为使用可用区级 DNS 名称。如果不迁移到可用区级 DNS，您可能会遇到以下问题：

  • 无法在发生控制平面故障且已拥有或之前拥有项目资源的任何区域中创建新虚拟机。
  • 无法使用某些对工作负载至关重要的 Compute Engine 服务，例如代管式实例组 (MIG) 的自动扩缩或自动修复。

若要提高使用全球 DNS 的工作负载的可靠性，一种替代方法是迁移到 Cloud DNS 专用区域。如果使用 Cloud DNS 专用区域，则系统会移除全球 DNS 所需的名称唯一性检查，并隔离失败以允许进行 DNS 名称解析。如需详细了解此选项，请参阅 Cloud DNS 文档，或联系 Cloud Customer Care 或您的客户支持团队代表。如需了解 Cloud DNS 如何处理可用区级和区域级服务中断，请参阅设计针对云基础架构服务中断的灾难恢复架构。

迁移过程概览

可用区级 DNS 迁移过程有两个级：

  • 组织或文件夹级：确定文件夹或组织是否准备好迁移到可用区级 DNS。阻止新项目使用全球 DNS。由组织管理员执行。
  • 项目级：将单个项目从全球 DNS 迁移到可用区级 DNS。通常由项目所有者执行。

下图显示了迁移到可用区级 DNS 所涉及的步骤的流程图

通常，此过程包括以下步骤：

  1. 检查文件夹或组织是否已准备好迁移到可用区级 DNS。
  2. 如果文件夹或组织已准备好迁移到可用区级 DNS：
    1. 组织管理员为文件夹或组织设置组织政策，以防止将来使用全球 DNS。
    2. 项目所有者将其项目迁移到使用可用区级 DNS。
  3. 如果文件夹或组织尚未准备好迁移到可用区级 DNS：
    1. 项目所有者将已就绪的项目迁移到可用区级 DNS。
    2. 项目所有者调查全球 DNS 在尚未就绪的项目中的使用情况。
    3. 项目所有者应用搜索路径改进或其他更改，以使项目准备好迁移到可用区级 DNS。
    4. 组织管理员重新检查文件夹或组织就绪状态以进行可用区级 DNS 迁移。

限制

  • 可用区级 DNS 不能完全替代全球 DNS。某些查询类型（跨可用区）可能无法由可用区级 DNS 通过自动搜索路径查找进行解析。在迁移之前，请检查组织的文件夹和项目的迁移就绪情况，确保它们与可用区级 DNS 兼容。

  • 全球 DNS 到可用区级 DNS 的迁移过程在搜索路径中引入新网域 (ZONE.c.PROJECT_ID.internal)。如果运行 Linux 或 Unix 的虚拟机在搜索路径中已有 6 个网域，请确保该虚拟机使用 glibc 2.26 版或更高版本运行。glibc 2.25 及更早版本的 DHCP 客户端仅支持最多 6 个搜索网域，因此可能会舍弃现有搜索网域。此限制不适用于使用以下各项的虚拟机：

    • Windows 映像
    • Container-Optimized OS 映像
    • Debian 10 或更高版本的映像
    • Fedora CoreOS（27 版或更高版本）
    • RHEL 8 或更高版本的映像
    • Ubuntu 版本 18.04 或更高版本的映像
    • glibc 2.26 版或更高版本的其他映像

  • 如果启用搜索路径改进，则会添加更多搜索网域，例如 NEIGHBOR_ZONE.c.PROJECT_ID.internal。如前面限制中所述，如果在使用 glibc 2.25 版或更早版本时超出搜索路径网域限制，则搜索路径中的现有网域可能会被移除。

  • 如需将搜索路径改进与 Google Kubernetes Engine 搭配使用，您必须使用 Google Kubernetes Engine 1.26 或更高版本。

检查 glibc 的版本

如需检查虚拟机使用的 glibc 版本，请执行以下操作：

  1. 连接到您的 Linux 虚拟机。
  2. 运行 ldd --version 以获取 glibc 版本。

如果使用的是 glibc 2.25 或更早版本，请检查搜索网域的数量

  1. 连接到您的 Linux 虚拟机。

  2. 检查 Linux 虚拟机在搜索路径中是否已有 6 个网域。您可以运行 cat /etc/resolv.conf 来查看此信息。

组织管理员的步骤

作为组织管理员，您可以执行以下任务：

检查您的组织是否默认使用全球 DNS

组织的默认内部 DNS 名称类型取决于组织的创建日期以及是否强制执行了组织政策限制条件 constraints/compute.setNewProjectDefaultToZonalDNSOnly。

控制台

  1. 转到控制台中的 IAM 和管理>身份和组织页面。

    转到“身份和组织”

  2. 检查组织注册日期。

    “身份和组织”控制台页面的屏幕截图，其中显示了注册完成日期

    • 如果您的组织是在 2018 年 9 月 6 日之后创建的，则您的组织默认使用可用区级 DNS。在这种情况下，您不需要执行任何操作。
    • 如果您的组织是在 2018 年 9 月 6 日之前创建的，则您的组织默认使用全球 DNS，应迁移到可用区级 DNS。

  3. 如果您的组织默认使用全球 DNS，请检查组织政策限制条件是否将所有新创建的项目的默认 DNS 类型设置为可用区级 DNS。

    1. 转到 Google Cloud 控制台中的 IAM 和管理>组织政策页面。
    2. 在过滤条件字段中，输入 constraints/compute.setNewProjectDefaultToZonalDNSOnly。
    3. 如果配置了限制条件，请点击名称将新项目的内部 DNS 设置设为“仅限可用区级 DNS”。
    4. 在政策详情页面上，查看状态。
      • 如果状态为已强制执行，则组织内部创建的所有新项目的默认内部 DNS 类型都是可用区级 DNS。
      • 否则，项目的默认 DNS 类型仍由组织创建时间决定。
    5. 如果没有为组织配置限制条件，则项目的默认 DNS 类型由组织创建时间决定，如第一步中所述。

gcloud

使用 organizations describe 命令和 resource-manager org-policies list 命令确定组织的默认 DNS 类型。

  1. 检查组织 creationTime 元数据值。

    gcloud organizations describe ORGANIZATION_ID

    将 ORGANIZATION_ID 替换为组织 ID 编号或组织域名。

    • 如果您的组织是在 2018 年 9 月 6 日之后创建的，则您的组织默认使用可用区级 DNS。在这种情况下，您的组织已在使用可用区级 DNS，您无需执行进一步的操作。
    • 如果您的组织是在 2018 年 9 月 6 日之前创建的，则您的组织默认使用全球 DNS，应迁移到可用区级 DNS。

  2. 如果您的组织默认使用全球 DNS，请确定是否已将组织政策限制条件配置为将所有新创建的项目的默认 DNS 类型设置为可用区级 DNS。

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

    在输出中，查找 constraints/compute.setNewProjectDefaultToZonalDNSOnly。

    1. 如果配置了限制条件且 Status 为 Enforced，则组织中创建的所有新项目的默认内部 DNS 类型是可用区级 DNS。
    2. 如果没有为组织配置限制条件或未强制执行限制条件，则默认内部 DNS 类型由组织创建时间决定，如第一步中所述。

确定文件夹或组织中的哪些项目使用全球 DNS

如需确定有多少项目正在使用全球 DNS，我们建议使用 BigQuery 创建一个表，其中列出组织的相关项目及其元数据。然后，您可以使用此表来运行公开使用全球 DNS 的项目总数的查询。

  1. 创建 BigQuery 数据集。

  2. 将组织的资产元数据导出到 BigQuery 表。

    1. 确保已启用 Cloud Asset Inventory API。
    2. 配置使用 Cloud Asset Inventory API 所需的权限。

    3. 使用以下 gcloud CLI 命令导出 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

      替换以下内容：

      • ORGANIZATION_ID：组织 ID 编号
      • PROJECT_ID：项目 ID
      • DATASET_ID：BigQuery 数据集的名称
      • TABLE_NAME：要将元数据导出到的表。如果该表不存在，系统会创建一个。

  3. 在 Google Cloud 控制台中转到 BigQuery 页面。

  4. 选择 编写新查询。

  5. 在查询编辑器文本区域中，输入以下 GoogleSQL 查询，然后点击 运行。

    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

    替换以下内容：

    • PROJECT_ID：项目 ID
    • DATASET_ID：BigQuery 数据集的名称
    • TABLE_NAME：包含步骤 2 中导出的元数据的表。

    值为 vmDnsSetting 的 ZONAL_ONLY 项目配置了可用区级 DNS。否则，项目会设置为使用全球 DNS。

  6. 可选：如需查看每个项目的 vmDnsSetting 的详细视图，请输入以下 GoogleSQL 查询，然后点击 运行。

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

确定文件夹是否已准备好迁移到可用区级 DNS

此步骤使用 bash 脚本和上一部分中创建的 BigQuery 表来确定文件夹的迁移就绪情况。

  • 如果所有项目在过去 30 天内都没有发出任何与可用区级 DNS 不兼容的查询，则该文件夹已准备就绪。
  • 如果文件夹未准备好进行迁移，脚本会使用文件夹中的项目 ID 进行响应，导致文件夹未准备好进行迁移。此结果列表中的项目尚未与可用区级 DNS 兼容，需要执行其他操作。

请完成以下步骤：

  1. 获取文件夹 ID。如果您不知道文件夹 ID，请执行以下操作：
    1. 在 Google Cloud 控制台中，转到代管式资源页面。
    2. 应用过滤条件 Name:FOLDER_NAME 以获取文件夹 ID。

  2. 使用导出的 compute.Project assets 数据查询 BigQuery 表。

    如需了解如何创建 BigQuery 表，请参阅确定文件夹或组织中的哪些项目使用全球 DNS。

    输入以下 GoogleSQL 查询，然后点击 运行：

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

    替换以下内容：

    • PROJECT_ID：项目 ID
    • DATASET_ID：BigQuery 数据集的名称
    • TABLE_NAME：包含导出的元数据的表
    • FOLDER_NUMBER：文件夹 ID 编号

  3. 复制项目 ID 列表并将其保存到文件中。

  4. 运行以下 bash 脚本：脚本会遍历已保存的文件中的项目 ID，以确定文件夹是否已准备好迁移。

#!/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

将 FILENAME 替换为您用于保存项目 ID 列表的文件的名称。

向项目所有者传达迁移就绪性分析结果：

默认为新项目强制执行可用区级 DNS

如果在 2018 年 9 月 6 日之前创建的组织下创建了新项目，则该项目使用的内部 DNS 类型默认为全球 DNS。如需将 DNS 注册中的任何失败隔离到单个可用区，您可以在组织或文件夹级层强制执行组织政策 constraints/compute.setNewProjectDefaultToZonalDNSOnly。

如果将组织政策设置为替换默认的内部 DNS 类型，新创建的项目会默认使用可用区级 DNS。组织政策不会影响已启用 Compute Engine API 的现有项目。如需将现有项目切换为使用可用区级 DNS，请参阅将现有项目切换为可用区级 DNS。

要执行此政策更改，您必须拥有 IAM 角色 roles/orgpolicy.policyAdmin 的文件夹或组织级层访问权限。

按照以下步骤设置文件夹或组织的组织政策。

  1. 以 Google Workspace 或 Cloud Identity 超级用户身份登录 Google Cloud 控制台。

  2. 在控制台中，转到组织政策页面。

    转到“组织政策”

  3. 选择您要查看其组织政策的文件夹或组织。Google Cloud 控制台会显示可用的组织政策列表。该列表可能跨多个页面。

  4. 如需查找强制执行可用区级 DNS 的政策，请点击过滤条件并选择名称，然后将过滤条件名称设置为将新项目的内部 DNS 设置设为“仅限可用区级 DNS”。

  5. 点击政策名称以查看其详细信息。

    政策详情页面提供限制条件的相关信息以及限制条件的应用方式。

    默认情况下，系统不会为文件夹或组织定义强制执行。但是，如果父文件夹具有已定义的强制执行，则强制执行将从具有已定义强制执行的最近父文件夹继承。如需了解详情，请参阅了解层次结构评估。

  6. 要自定义组织政策，请点击修改。

  7. 在修改页面中，选择自定义。

  8. 在强制执行下，选择开启。

    这会将组织中所有新项目的默认内部 DNS 类型设置为可用区级 DNS。

  9. 点击保存。

如需验证组织政策更改，您可以在文件夹或组织下创建一个新项目，然后创建并启动虚拟机实例并检查是否已为虚拟机启用可用区级 DNS。

如果需要全球 DNS 来解析工作负载中内置的 DNS 名称查询，则可以停用强制执行，以在组织或文件夹级层回滚此更改。

豁免未准备好迁移到可用区级 DNS 的文件夹

如果组织内只有几个文件夹尚未准备好迁移到可用区级 DNS，我们建议您在组织级层设置组织政策，但为尚未准备好迁移的文件夹授予豁免。

以下示例展示了一个组织层次结构，其中只有一个文件夹尚未准备好迁移到可用区级 DNS。

organization/Example.com

  • folders/101
    • projects/301（准备好迁移）
    • folders/201
      • projects/303（尚未准备就绪）
      • projects/304（准备好迁移）
  • folders/102
    • projects/302（准备好迁移）

如需从组织政策中豁免某个文件夹，请完成以下步骤，在文件夹级层将政策的强制执行选项设置为 Off。

  1. 以 Google Workspace 或 Cloud Identity 超级用户身份登录 Google Cloud 控制台。

  2. 在控制台中，转到组织政策页面。

    转到“组织政策”

  3. 点击选择，然后选择要从组织政策中豁免的文件夹。

    Google Cloud 控制台会在一个或多个页面上显示该文件夹的组织政策限制条件列表。

  4. 如需查找强制执行可用区级 DNS 的组织政策限制条件，请执行以下操作：

    1. 点击过滤。
    2. 选择名称。
    3. 将过滤条件名称设置为将新项目的内部 DNS 设置设为“仅限可用区级 DNS”。

  5. 点击组织政策限制条件名称以打开政策详情页面。

  6. 点击修改。

  7. 在修改页面，选择自定义。

  8. 在强制执行下，选择关闭以停用限制条件的强制执行。也就是说，该文件夹中所有项目的默认内部 DNS 类型均由组织创建时间决定。

  9. 点击保存。

如需详细了解如何自定义组织政策限制条件，请参阅 Resource Manager 文档中的为布尔值限制条件自定义政策。

项目所有者的步骤

作为项目所有者，您可以在从全球 DNS 迁移到可用区级 DNS 期间执行以下任务：

项目所有者还可以完成以下可选任务：

检查您的项目是否默认使用全球 DNS

检查您的项目，了解它们是否需要从使用全球 DNS 迁移到可用区级 DNS。您只需迁移配置为对项目内创建的任何内部 DNS 名称使用全球 DNS 作为默认 DNS 的项目。

控制台

  1. 在 Google Cloud 控制台中，转到元数据页面。

    转到元数据

  2. 在元数据标签页上，查看 vmdnssetting 设置。该值表示项目是否默认使用全球 DNS。

    • GlobalDefault：项目已启用全球 DNS。
    • ZonalOnly：项目已启用可用区级 DNS。 此项目不需要迁移。

gcloud

    在 Google Cloud 控制台中，激活 Cloud Shell。

    激活 Cloud Shell

    Cloud Shell 会话随即会在 Google Cloud 控制台的底部启动，并显示命令行提示符。Cloud Shell 是一个已安装 Google Cloud CLI 且已为当前项目设置值的 Shell 环境。该会话可能需要几秒钟时间来完成初始化。

  1. 运行以下 gcloud CLI 命令以检查 vmDnsSetting 的值。

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

    将 PROJECT_ID 替换为该项目的名称。

    返回的值表示项目是否默认使用全球 DNS。

    • GLOBAL_DEFAULT：项目已启用全球 DNS。
    • ZONAL_ONLY：项目已启用可用区级 DNS。此项目不需要迁移。

REST

使用 projects.get 方法检查 vmDnsSetting 的值。此示例使用 fields 查询参数来仅包含您要查看的字段。

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

将 PROJECT_ID 替换为项目 ID。

vmDnsSetting 的值表示项目是否默认使用全球 DNS。

  • GLOBAL_DEFAULT：项目已启用全球 DNS。
  • ZONAL_ONLY：项目已启用可用区级 DNS。此项目不需要迁移。

确定项目是否已准备好迁移

在 Google Cloud 控制台的虚拟机实例页面上，如果您的项目需要迁移到可用区级 DNS，您应该会看到有关可用区级 DNS 迁移的通知横幅。

当您查看项目的虚拟机实例页面时，如果项目已准备好迁移（与可用区级 DNS兼容），则横幅中会包含关于使用可用区级 DNS的建议。此建议基于项目中的内部 DNS 使用情况，但仅限于过去 100 天。

控制台中准备好迁移到可用区级 DNS 横幅的屏幕截图

如果您的项目尚未准备好迁移到可用区级 DNS，系统会显示其他横幅。

控制台中尚未准备好迁移到可用区级 DNS 横幅的屏幕截图

如需查看您的全球 DNS 使用情况，请点击查看全球 DNS 使用情况按钮。系统随即会转到 Google Cloud 控制台中的 Logs Explorer 页面。在此页面上，您可以查看过去 30 天的迁移阻塞查询日志。点击横幅中的链接时，Logs Explorer 页面会配置为使用 logName 过滤条件来拉取全球 DNS 查询和相对日志字段。

如需在不使用横幅中的按钮的情况下查看此信息，请执行以下操作：

  1. 在 Google Cloud 控制台中，转到 Logs Explorer 页面。

    转到 Logs Explorer

  2. 选择项目。

  3. 应用资源和日志名称过滤条件：

    1. 点击资源。
    2. 在选择资源对话框中，选择虚拟机实例，然后点击应用。
    3. 点击日志名称。

    4. 在选择日志名称对话框中，选择 gdnsusage，然后点击应用。

或者，您可以在查询字段中输入以下内容：

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

跟踪项目中的全球 DNS 使用情况

系统会创建两个指标来跟踪项目是否准备好迁移到可用区级 DNS：

  • zonal_dns_ready：在指定时间间隔内完成的可使用可用区级 DNS（而非全球 DNS）进行解析的查询总数。
  • zonal_dns_risky：在指定时间间隔内完成的无法使用可用区级 DNS 解析的查询总数。对于这些查询，Compute Engine 无法根据当前主机名确定相对内部 IP 地址。如果此指标具有非零值，则表示项目尚未准备好迁移。

这些指标使用的时间间隔为 100 天。

如需查看这些指标，请使用 Google Cloud 控制台中的 Metrics Explorer。

  1. 在 Google Cloud 控制台的导航面板中，选择 Monitoring，然后选择  Metrics Explorer：

    进入 Metrics Explorer

  2. 在包含选择指标字段的工具栏右侧，点击代码编辑器、MQL 或 PromQL。

  3. 如果查询输入字段的标题不是 MQL 查询，请在查询输入字段的右下角，选择 MQL作为语言。

  4. 在查询输入字段中，按原样输入以下文本：

    fetch compute.googleapis.com/Location
| metric 'compute.googleapis.com/global_dns/request_count'
| every 1d
| within 7d

  5. 点击运行查询按钮。

    Google Cloud 控制台会显示两个指标（zonal_dns_ready 和 zonal_dns_risky）的图表，以及每个指标在一段时间内的相应查询数。

    全球 DNS 使用情况指标的图表屏幕截图

  6. 查看 zonal_dns_risky 指标的值。

    • 如果该值为 0，则表示项目已准备好迁移到可用区级 DNS。您可以按照将准备好的项目迁移到可用区级 DNS 中所述迁移项目。
    • 如果该值为非零数字（例如上一屏幕截图中所示的 0.02k），则在迁移到可用区级 DNS 后，某些查询可能无法正常运行。项目尚未准备好进行迁移。继续执行修改未准备好迁移的项目中的步骤。

将准备好的项目迁移到可用区级 DNS

通常，您可以通过以下过程执行迁移：

  1. 检查您的应用并更新它们以解决与“仅限可用区级 DNS”设置的兼容性问题：
    • 如果您有任何应用使用硬编码的全球 DNS 名称，请将它们更新为使用可用区级 DNS 名称。
    • 如有任何应用使用虚拟机名称访问其他可用区中的虚拟机，请确保在查询中添加目标可用区名称，例如 DESTINATION_VM_NAME.DESTINATION_ZONE_NAME。
    • 对于使用共享 VPC 网络的服务项目，如需解析其中的虚拟机的 DNS 名称，您必须使用虚拟机的区域级完全限定域名 (FQDN)。

  2. 点击 Google Cloud 控制台虚拟机实例页面上横幅中的使用可用区级 DNS 按钮。这会将项目元数据更改为使用可用区级 DNS。

    或者，您也可以将项目手动修改为默认使用可用区级 DNS，如将项目和虚拟机手动更新为使用可用区级 DNS 和阻止新项目默认使用全球 DNS。

将项目和虚拟机手动更新为使用可用区级 DNS

在确定项目已准备好迁移到可用区级 DNS 后，您可以通过更新项目和虚拟机的元数据来将其配置为仅使用可用区级 DNS 名称。通过为项目或虚拟机设置 vmDnsSetting 元数据条目，为您的虚拟机启用可用区级 DNS。如果为特定虚拟机设置 vmDnsSetting 元数据条目，它将替换从该虚拟机的项目元数据继承的任何 vmDnsSetting 设置。

vmDnsSetting 变量支持以下设置：

  • 建议：在项目元数据中设置 vmDnsSetting=ZonalOnly。这意味着您的虚拟机只能通过其可用区级 DNS 名称 (VM_NAME.ZONE.c.PROJECT_ID.internal) 来进行访问。这些虚拟机仍会保留可用区级和全球搜索路径，但它们的全球 DNS 名称（不会将 ZONE 作为内部 DNS 名称的一部分包含）不再起作用。其他虚拟机只能使用可用区级 DNS 名称来访问 vmDnsSetting 设置为 ZonalOnly 的虚拟机，并且无法使用其全球 DNS 名称或搜索路径来访问这些虚拟机。只要您的应用可支持此设置，它就是更可靠的首选选项。

    2018 年 9 月 6 日之后启用 Compute Engine API 的独立项目及组织中创建的项目内的虚拟机均默认使用 vmDnsSetting=ZonalOnly 设置。

  • 设置 vmDnsSetting=GlobalDefault 以便虚拟机注册全球和可用区级 DNS 名称，但仅使用全球名称作为默认域名和搜索路径条目。2018 年 9 月 6 日之前启用 Compute Engine API 的独立项目及组织中创建的项目内的虚拟机均默认使用此设置。

如需了解如何设置项目元数据值或虚拟机元数据值，请参阅设置自定义元数据。

为虚拟机配置 vmDnsSetting 元数据条目后，刷新虚拟机上的 DHCP 租期。您可以通过重启虚拟机、等待租期到期或运行以下命令之一来刷新租期：

  • Linux 虚拟机：sudo dhclient -v -r
  • Windows Server 虚拟机：ipconfig /renew

刷新 DHCP 租期后，检查是否已为虚拟机启用可用区级 DNS。

修改尚未准备好迁移的项目

项目未准备好迁移意味着在特定时间段内（例如过去 30 天或过去 100 天）至少进行了一次有风险的 DNS 查询。有风险的查询是指使用无法改用可用区级 DNS 名称 (VM_NAME.ZONE.c.PROJECT_ID.internal) 无缝解析的全球 DNS 名称 (VM_NAME.c.PROJECT_ID.internal) 来调用虚拟机。风险查询可能具有以下属性：

  • 调用其他项目中的虚拟机
  • 调用其他可用区中的虚拟机

对于包含有风险查询的项目，通常需要一些额外的工作才能在迁移之前消除所有有风险的 DNS 查找。

对于尚未准备好迁移的项目，请完成以下步骤：

  1. 启用搜索路径改进功能以解析跨可用区级 DNS 名称查找。这样可以使项目做好迁移准备而不会影响资源。
  2. 如果搜索路径调整操作并未转换所有跨可用区的查询，您可以将查询手动更新使用可用区级 DNS 名称。

关于搜索路径改进功能

默认情况下，大多数 Linux 发行版都将 DHCP 信息存储在 resolv.conf 中。以下是一个简单的全球 resolv.conf file：

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

search 配置选项用于列出执行 DNS 解析时使用的主机名。DNS 服务器会尝试依次使用搜索路径中的每个主机名来解析查询，直到找到 DNS 记录匹配项。例如，如果虚拟机调用 ping my-vm，则搜索路径中的网域会附加到原始查询，以获取完全限定域名 (FQDN)，例如使用 my-vm.c.PROJECT_ID.internal。 如果存在匹配项，DNS 解析器会在应答中返回内部 IP 地址。否则，它会尝试使用搜索路径中的下一个网域解析 DNS 名称。

在虚拟机搜索路径中添加额外的可用区级网域后，可以使某些项目做好迁移准备。例如，假设您的虚拟机位于 us-west4-c 可用区。此虚拟机调用了位于 us-west4-b 可用区的另一个名为 myapp-vm 的虚拟机。

  • 以 myapp-vm 身份调用虚拟机时，Compute Engine 会尝试使用将某个搜索路径附加到虚拟机名称的 FQDN（例如 myapp-vm.c.PROJECT_ID.internal）来解析 DNS 名称。
  • 如果目标虚拟机使用可用区级 DNS，则目标虚拟机的 FQDN 会注册为 myapp-vm.us-west4-b.c.PROJECT_ID.internal。因此，DNS 名称无法解析。
  • 如果您将 us-west4-b.c.PROJECT_ID.internal 添加到搜索列表中，则在虚拟机名称后面附加 us-west4-b.c.PROJECT_ID.internal 后，可以解析 DNS 名称 myapp-vm。

Google 提供了搜索路径改进功能，可自动在虚拟机所在区域的所有可用区中搜索虚拟机的可用区级 DNS 名称。因此，无需更新 resolv.conf 文件或 DHCP 政策即可解析跨可用区级查询。搜索路径改进功能可以在高达 80% 的时间里解析区域内跨可用区查询。此功能应该有助于大多数包含有风险查询的项目准备好迁移到可用区级 DNS。

启用搜索路径改进以解析跨可用区 DNS 名称查找

如需启用搜索路径改进功能，请按照以下步骤操作。

  1. 运行 project-info add-metadata 命令，如下所示。

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

  2. 允许项目使用此设置几天，然后检查监控指标，看看是否仍然存在任何有风险或跨可用区的全球 DNS 查询。

    • 如果项目的值为 0，则表示项目现在已准备好迁移。
    • 如果项目返回非零值，请将所有全球 DNS 查询名称更改为使用可用区级 FQDN，如下一部分所述。

将查询手动更新为使用可用区级 DNS 名称

如果使用搜索路径改进功能在 DNS 名称搜索路径中添加额外的可用区级网域并未转换所有跨可用区级查询，则可以使用 Logs Explorer 查看项目中的全球 DNS 使用情况。

如需确定需要手动更改为使用可用区级完全限定域名 (FQDN) 的全球 DNS 查询，请完成以下步骤：

  1. 请按照确定项目是否已准备好迁移中的步骤查看项目的全球 DNS 使用情况。使用 Logs Explorer 访问并查询项目中虚拟机的全球 DNS 使用情况。

  2. 在查询结果窗格中，每个查询都有一个 jsonPayload 字段。每个 jsonPayload 字段都包含以下信息：

    • 来源虚拟机名称、其项目 ID 和可用区名称。
    • 目标虚拟机名称、其项目 ID 和可用区名称。

    • 一条调试消息，它提供有关如何更新无法使用可用区级 DNS 名称解析的全球 DNS 查询的信息。这些查询是迁移阻塞查询，应进行调试和修复。

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

    • 查询计数，显示来源虚拟机在当天向目标虚拟机发送的迁移阻塞查询数量。

    以下屏幕截图显示了 Logs Explorer 控制台页面中的 jsonPayload 字段信息。

    gdnsusage 日志查询结果中的 jsonPayload 的屏幕截图

  3. 使用 jsonPayload 中的信息来确定用于将全球 DNS 查询手动更新为使用可用区级 DNS 的 FQDN，并使项目做好迁移准备。要更新 FQDN 和解决兼容性问题的最常见应用场景如下：

    • 来自元数据服务器的内部 DNS 名称：无需执行任何操作，因为返回的 DNS 名称会在迁移到可用区级 DNS 后立即更改为可用区级 FQDN。如果 DNS 名称已缓存，您只需再进行一次调用即可更新缓存值。
    • 用于访问其他区域中的虚拟机的内部 DNS 名称：如果您的应用为不同区域中的虚拟机使用内部 DNS 名称，您可以修改 DHCP 政策或配置文件以将该可用区包含在另一个区域中。
    • 硬编码的全球 FQDN：如果您有一个应用为虚拟机使用硬编码的全球 FQDN 名称，则可以更新应用中的调用以改用内部 DNS 名称或可用区级 FQDN。您可以通过 Terraform 中的代码更改或配置更改来进行此项更改。
    • 服务项目中使用共享 VPC 网络的虚拟机：如果服务项目中的虚拟机使用共享 VPC 网络且需要解析这些虚拟机的 DNS 名称，您必须使用虚拟机的可用区级 FQDN。

将全球 DNS 查询更新为使用可用区级 DNS 后：

  1. 使用 Logs Explorer 页面再次查询全球 DNS 使用情况。修复所有阻塞的全球 DNS 查询后，查询结果中应该不会显示任何调试日志。
  2. 重新检查监控指标，了解是否已移除所有有风险的 DNS 查询。

验证项目是否已完成可用区级 DNS 的迁移

  1. 重复执行检查您的项目是否默认使用全球 DNS 中的步骤。

  2. 如需测试项目元数据是否已更新，您可以运行以下命令：

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

    该命令应返回 ZONAL_ONLY。

  3. 检查虚拟机的内部 DNS 名称是否使用可用区级 DNS 名称。

  4. 如需验证是否强制执行组织政策 constraints/compute.setNewProjectDefaultToZonalDNSOnly，您可以执行以下操作：

    1. 在文件夹或组织下创建一个新项目。
    2. 创建并启动虚拟机实例。
    3. 检查虚拟机是否使用可用区级 DNS 名称。

还原为使用全球 DNS

如需撤消迁移到可用区级 DNS 的操作，您可以将默认内部 DNS 类型更改回全球 DNS。您可以在组织、项目、虚拟机或容器级层执行此操作。

还原为对组织或文件夹使用全球 DNS

如需将组织或文件夹还原为使用全球 DNS，请完成以下步骤。

  1. 在组织或文件夹级层停用组织政策 constraints/compute.setNewProjectDefaultToZonalDNSOnly。如需了解如何修改此政策，请参阅默认为新项目强制执行可用区级 DNS。

    将将新项目的内部 DNS 设置设为“仅限可用区级 DNS”的强制执行设置为关闭。

  2. 如果您希望还原为对整个组织使用全球 DNS，请验证组织中没有任何文件夹强制执行组织政策 constraints/compute.setNewProjectDefaultToZonalDNSOnly。

  3. 使用以下部分检查是否已为项目、虚拟机和容器配置全球 DNS。

还原为对项目使用全球 DNS

如需将项目还原为使用全球 DNS，请完成以下步骤。

  1. 将以下内容添加到项目的元数据中：vmDnsSetting=GlobalDefault。

    如需了解如何设置项目元数据值或虚拟机元数据值，请参阅设置自定义元数据。

  2. 验证项目中没有任何虚拟机的 vmDnsSetting 元数据值设置为 ZonalOnly。

  3. 刷新每个虚拟机上的 DHCP 租期。您可以通过重启虚拟机、等待租期到期或运行以下命令之一来刷新租期：

    • Linux 虚拟机：sudo dhclient -v -r
    • Windows Server 虚拟机：ipconfig /renew

还原为对虚拟机使用全球 DNS

如需将特定虚拟机还原为使用全球 DNS，请完成以下步骤。

  1. 将以下内容添加到虚拟机的元数据中：vmDnsSetting=GlobalDefault。

    如需了解如何设置虚拟机元数据值，请参阅设置自定义元数据。

  2. 如需强制更改 DNS 配置，请使用以下命令之一重启虚拟机网络：

  • 对于 Container-Optimized OS 或 Ubuntu：

    sudo systemctl restart systemd-networkd

  • 对于 CentOS、RedHat EL、Fedora CoreOS 或 Rocky Linux：

    sudo systemctl restart network

  • 对于 Debian：

    sudo systemctl restart networking

  • 对于 Windows：

    ipconfig /renew

还原为对容器使用全球 DNS

如果您在容器、Google Kubernetes Engine 或 App Engine 柔性环境中运行应用或工作负载，容器设置中的 DNS 配置可能在您重启容器后才会自动更新。如需在这些容器应用上停用可用区级 DNS，请完成以下步骤。

  1. 在拥有容器和虚拟机的项目中，将项目元数据设置 vmDnsSetting 设为 GlobalDefault。

  2. 重启容器，使其 DNS 设置恢复到原始状态。

排查从全球 DNS 迁移到可用区级 DNS 过程中的问题

如果您在迁移过程中遇到问题，请参阅问题排查指南。

在 Google Cloud 控制台中隐藏可用区级 DNS 迁移横幅

您可以点击 Google Cloud 控制台虚拟机实例页面上显示的可用区级 DNS 迁移通知横幅中的忽略按钮。这样可以防止横幅无限期地显示在项目中。

如果您忽略横幅后希望它再次显示，请与 Cloud Customer Care 联系以获取帮助。

后续步骤