내부 DNS 유형에 영역 DNS 사용

영역 DNS는 리전 간 서비스 중단 위험을 완화하고 Compute Engine 프로젝트의 전반적인 안정성을 개선합니다. 영역 DNS를 사용하면 전역 DNS를 사용할 때 발생할 수 있는 단일 지점 장애의 영향이 줄어듭니다.

시작하기 전에

  • 아직 인증을 설정하지 않았다면 설정합니다. 인증은 Google Cloud 서비스 및 API에 액세스하기 위해 ID를 확인하는 프로세스입니다. 로컬 개발 환경에서 코드 또는 샘플을 실행하려면 다음과 같이 Compute Engine에 인증하면 됩니다.

    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

      로컬 개발 환경에서 이 페이지의 REST API 샘플을 사용하려면 gcloud CLI에 제공하는 사용자 인증 정보를 사용합니다.

        Install the Google Cloud CLI, then initialize it by running the following command: 

        gcloud init

      자세한 내용은 Google Cloud 인증 문서의 REST 사용 인증을 참조하세요.

필요한 역할

영역 DNS로 마이그레이션하는 데 필요한 권한을 얻으려면 관리자에게 다음의 IAM 역할을 부여해 달라고 요청하세요.

  • 조직 정책 만들기 또는 업데이트: 폴더 또는 조직의 조직 정책 관리자(roles/orgpolicy.policyAdmin)
  • 폴더를 영역 DNS로 마이그레이션할 준비가 되었는지 판단: 폴더 또는 조직의 브라우저(roles/browser)
  • 영역 DNS를 사용하도록 프로젝트 마이그레이션: 프로젝트에 대한 프로젝트 편집자(roles/resourcemanager.projectEditor)
  • VM을 프로젝트 내의 영역 DNS로 마이그레이션: 프로젝트의 Compute 인스턴스 관리자(v1)(roles/compute.instanceAdmin.v1)
  • VM이 서비스 계정을 사용하는 경우: 서비스 계정 또는 프로젝트에 대한 서비스 계정 사용자(roles/iam.serviceAccountUser)

역할 부여에 대한 자세한 내용은 액세스 관리를 참조하세요.

이러한 사전 정의된 역할에는 영역 DNS로 마이그레이션하는 데 필요한 권한이 포함되어 있습니다. 필요한 정확한 권한을 보려면 필수 권한 섹션을 펼치세요.

필수 권한

영역 DNS로 마이그레이션하려면 다음 권한이 필요합니다.

  • 조직 정책 제약조건 설정: orgpolicy.*
  • 폴더를 영역 DNS로 마이그레이션할 준비가 되었는지 판단:
    • resourcemanager.folders.get
    • resourcemanager.folders.list
    • resourcemanager.organizations.get
    • resourcemanager.projects.get
    • resourcemanager.projects.list
  • 전역 DNS 이름과 VM 메타데이터 확인: compute.projects.get
  • VM에 메타데이터 설정: compute.instances.setMetadata
  • 프로젝트 차원의 메타데이터 설정: compute.projects.setCommonInstanceMetadata
  • VM이 서비스 계정을 사용하는 경우: iam.serviceAccounts.actAs

커스텀 역할이나 다른 사전 정의된 역할을 사용하여 이 권한을 부여받을 수도 있습니다.

DNS 이름 정보

영역 DNS 이름에는 VM의 이름, VM이 있는 영역, VM을 소유하는 프로젝트가 포함됩니다. 전역 DNS 이름에는 VM이 위치한 영역이 포함되지 않습니다.

전역 DNS 이름을 사용하여 VM을 호출하는 경우:

  • 이름은 전역 수준에서 확인됩니다.
  • 각 VM에는 고유한 DNS 이름이 있어야 합니다.
  • 새 VM을 생성할 때 DNS 이름 충돌을 방지하려면 VM의 DNS 이름을 동일한 프로젝트에 등록된 다른 모든 전역 DNS 이름과 비교하여 확인해야 합니다.

영역 DNS 이름을 사용하여 VM을 호출하는 경우:

  • 이름은 영역 내에서 확인됩니다.
  • 영역 DNS 이름은 영역 내에서 고유해야 합니다. 예를 들어 my-vm.zone1.google.com은 zone1에 대해 고유해야 합니다. 하지만 전역 DNS 이름과 달리 my-vm.zone2.google.com은 영역 DNS를 사용할 때도 유효한 DNS 이름입니다.

영역 DNS는 2018년 9월 6일 이후에 만든 조직의 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에서 Google Cloud로 대체되었습니다. 기존 프로젝트에 아직 전역 DNS가 사용되는 경우에는 영역 DNS 이름을 사용하도록 프로젝트를 전환하는 것이 가장 좋습니다. 영역 DNS로 마이그레이션하지 않으면 다음과 같은 문제가 발생할 위험이 있습니다.

  • 프로젝트가 있거나 이전에 있었던 제어 영역 오류가 발생하는 리전에 새 VM을 만들 수 없음
  • 관리형 인스턴스 그룹(MIG)의 자동 확장 또는 자동 복구와 같이 워크로드에 중요한 일부 Compute Engine 서비스를 사용할 수 없음

전역 DNS를 사용하는 워크로드의 안정성을 개선하는 또 다른 방법은 Cloud DNS 비공개 영역으로 마이그레이션하는 것입니다. Cloud DNS 비공개 영역을 사용하면 전역 DNS에 필요한 이름 고유성 확인이 삭제되고 DNS 이름을 확인할 수 있도록 오류가 격리됩니다. 이 옵션에 대한 자세한 내용은 Cloud DNS 문서를 참조하거나 클라우드 고객 관리 또는 계정팀 담당자에게 문의하세요. 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를 실행하는 VM의 검색 경로에 이미 6개의 도메인이 있는 경우 VM이 glibc 버전 2.26 이상으로 실행 중인지 확인합니다. glibc 2.25 및 이전 버전의 DHCP 클라이언트는 최대 6개의 검색 도메인만 지원하므로, 기존 검색 도메인을 삭제할 위험이 있습니다. 이 한도는 다음을 사용하는 VM에는 적용되지 않습니다.

    • 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 버전 확인

VM에서 사용하는 glibc 버전을 확인하려면 다음 안내를 따르세요.

  1. Linux VM에 연결합니다.
  2. ldd --version를 실행하여 glibc 버전을 가져옵니다.

glibc 2.25 이하를 사용하는 경우 검색 도메인 수 확인

  1. Linux VM에 연결합니다.

  2. Linux VM의 검색 경로에 이미 6개의 도메인이 있는지 확인하세요. cat /etc/resolv.conf를 실행하여 이 정보를 볼 수 있습니다.

조직 관리자 단계

조직 관리자는 다음 작업을 수행합니다.

조직에서 기본값으로 전역 DNS를 사용하는지 확인

조직의 기본 DNS 이름 유형은 조직이 생성된 날짜 및 조직 정책 제약조건 constraints/compute.setNewProjectDefaultToZonalDNSOnly 적용 여부에 따라 결정됩니다.

콘솔

  1. 콘솔에서 IAM 및 관리자 >ID 및 조직 페이지로 이동합니다.

    ID 및 조직으로 이동

  2. 조직 가입 날짜를 확인합니다.

    가입 완료 날짜가 표시된 ID 및 조직 콘솔 페이지의 스크린샷

    • 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 애셋 인벤토리 API가 사용 설정되어 있는지 확인합니다.
    2. Cloud 애셋 인벤토리 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. 저장을 클릭합니다.

조직 정책 변경을 검사하려면 폴더 또는 조직 아래에 새 프로젝트를 만들고, VM 인스턴스를 생성 및 시작하고, 영역 DNS에 대해 VM이 사용 설정되었는지 여부를 확인합니다.

워크로드에 빌드된 DNS 이름 쿼리를 확인하기 위해 전역 DNS가 필요하면 조직 또는 폴더 수준에서 시행을 사용 중지하여 이 변경사항을 롤백할 수 있습니다.

영역 DNS로 마이그레이션할 준비가 되지 않은 폴더 제외

조직 내에서 영역 DNS로 마이그레이션할 준비가 되지 않은 폴더가 몇 개에 불과한 경우, 조직 수준에서 조직 정책을 설정하는 것을 권장하지만, 아직 마이그레이션할 준비가 되지 않은 폴더에 대해 예외를 부여하는 것이 좋습니다.

다음 예시에서는 폴더 1개만 영역 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를 사용하도록 구성된 프로젝트만 마이그레이션하면 됩니다.

콘솔

  1. Google Cloud 콘솔에서 메타데이터 페이지로 이동합니다.

    메타데이터로 이동

  2. 메타데이터 탭에서 vmdnssetting 설정을 확인합니다. 이 값은 프로젝트가 기본적으로 전역 DNS를 사용하는지 여부를 나타냅니다.

    • GlobalDefault: 프로젝트에 전역 DNS가 사용 설정되어 있음
    • ZonalOnly: 프로젝트에 영역 DNS가 사용 설정되어 있음. 이 프로젝트는 마이그레이션할 필요가 없습니다.

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. 다음 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 콘솔의 VM 인스턴스 페이지에서 프로젝트를 영역 DNS로 마이그레이션해야 하는 경우 영역 DNS 마이그레이션에 대한 알림 배너가 표시됩니다.

프로젝트의 VM 인스턴스 페이지를 열람할 때, 프로젝트를 마이그레이션할 준비가 된 경우(영역 DNS와 호환됨) 배너에 영역 DNS 사용을 권장하는 사항이 포함됩니다. 이 권장사항은 프로젝트의 내부 DNS 사용량을 기반으로 하지만 지난 100일로 제한됩니다.

콘솔의 영역 DNS로 마이그레이션할 준비가 된 스크린샷

프로젝트를 영역 DNS로 마이그레이션할 준비가 되지 않았으면 다른 배너가 표시됩니다.

콘솔의 영역 DNS로 마이그레이션할 준비가 되지 않은 스크린샷

전역 DNS 사용량을 보려면 전역 DNS 사용량 보기 버튼을 클릭합니다. 그러면 Google Cloud 콘솔의 로그 탐색기 페이지로 이동합니다. 이 페이지에서 지난 30일 동안의 마이그레이션 차단 쿼리 로그를 볼 수 있습니다. 배너에서 링크를 클릭하면 로그 이름 필터를 사용하여 전역 DNS 쿼리와 상대 로그 필드를 가져오도록 로그 탐색기 페이지가 구성됩니다.

배너의 버튼을 사용하지 않고 이 정보를 보려면 다음 단계를 따르세요.

  1. Google Cloud 콘솔에서 로그 탐색기 페이지로 이동합니다.

    로그 탐색기로 이동

  2. 프로젝트를 선택합니다.

  3. 리소스 및 로그 이름 필터를 적용합니다.

    1. 리소스를 클릭합니다.
    2. 리소스 선택 대화상자에서 VM 인스턴스를 선택한 후 적용을 클릭합니다.
    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 간격을 통해 영역 DNS를 사용하여 확인할 수 없는 집계된 쿼리 수입니다. 이러한 쿼리의 경우 Compute Engine이 현재 호스트 이름에서 상대 내부 IP 주소를 확인할 수 없습니다. 이 측정항목의 값이 0이 아니면 프로젝트를 마이그레이션할 준비가 되지 않은 것입니다.

이러한 측정항목에서 사용하는 시간 간격은 100일입니다.

이러한 측정항목을 보려면 Google Cloud 콘솔에서 측정항목 탐색기를 사용합니다.

  1. Google Cloud 콘솔의 탐색 패널에서 Monitoring을 선택한 후 측정항목 탐색기를 선택합니다.

    측정항목 탐색기로 이동

  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 측정항목 값을 확인합니다.

준비된 프로젝트를 영역 DNS에 마이그레이션

일반적으로 다음과 같은 마이그레이션 프로세스를 사용할 수 있습니다.

  1. 애플리케이션을 확인하고 업데이트해서 영역 전용 설정과의 호환성 문제를 해결합니다.
    • 하드 코딩된 전역 DNS 이름을 사용하는 애플리케이션이 있는 경우 영역 DNS 이름을 사용하도록 업데이트합니다.
    • 애플리케이션이 VM 이름을 사용하여 다른 영역의 VM에 액세스하는 경우 쿼리에 대상 영역 이름이 추가되는지 확인합니다(예: DESTINATION_VM_NAME.DESTINATION_ZONE_NAME).
    • 공유 VPC 네트워크를 사용하는 서비스 프로젝트에서 VM의 DNS 이름을 확인하려면 VM의 영역별 정규화된 도메인 이름(FQDN)을 사용해야 합니다.

  2. Google Cloud 콘솔의 VM 인스턴스 페이지에 있는 배너에서 영역 DNS 사용 버튼을 클릭합니다. 이렇게 하면 영역 DNS를 사용하도록 프로젝트 메타데이터가 변경됩니다.

    또는 영역 DNS를 사용하도록 프로젝트 및 VM 수동 업데이트 및 기본적으로 새 프로젝트가 전역 DNS를 사용하지 못하도록 방지에 설명된 것처럼 기본적으로 영역 DNS를 사용하도록 프로젝트를 수동으로 수정할 수 있습니다.

영역 DNS를 사용하도록 프로젝트 및 VM 수동 업데이트

프로젝트를 영역 DNS로 마이그레이션할 준비가 되었는지 확인한 후에는 메타데이터를 업데이트하여 프로젝트와 영역별 VM 이름만 사용하도록 구성할 수 있습니다. 프로젝트 또는 VM의 vmDnsSetting 메타데이터 항목을 설정하여 VM에 대해 영역 DNS를 사용 설정합니다. 특정 VM에 vmDnsSetting 메타데이터 항목을 설정하면 해당 VM의 프로젝트 메타데이터에서 상속된 모든 vmDnsSetting 설정이 재정의됩니다.

vmDnsSetting 변수는 다음 설정을 지원합니다.

  • 권장: 프로젝트 메타데이터에 vmDnsSetting=ZonalOnly를 설정합니다. 즉, 영역 DNS 이름(VM_NAME.ZONE.c.PROJECT_ID.internal)으로만 VM에 액세스할 수 있다는 의미입니다. VM의 영역 및 전역 검색 경로는 계속 유지되지만 전역 DNS 이름은 유지되며, 내부 DNS 이름의 일부로 포함되지 않은 ZONE은 더 이상 작동하지 않습니다. 다른 VM은 영역 DNS 이름만을 사용하여 vmDnsSetting을 ZonalOnly로 설정한 VM의 주소를 지정할 수 있으며, 해당 전역 DNS 이름 또는 검색 경로를 사용해서는 이러한 VM에 주소를 지정할 수 없습니다. 이는 애플리케이션에서 지원한다면 권장되는 안정적인 옵션입니다.

    2018년 9월 6일 이후에 Compute Engine API를 사용 설정한 조직에서 만든 프로젝트와 독립형 프로젝트의 VM에 이 설정 vmDnsSetting=ZonalOnly가 기본적으로 적용됩니다.

  • VM이 전역 DNS 이름과 영역 DNS 이름을 모두 등록하지만 전역 DNS 이름만 기본 도메인 이름 및 검색 경로 항목으로 사용하도록 vmDnsSetting=GlobalDefault를 설정합니다. 2018년 9월 6일 전에 Compute Engine API를 사용 설정한 조직에서 만든 프로젝트와 독립형 프로젝트의 VM에 이 설정이 기본적으로 적용됩니다.

프로젝트 메타데이터 또는 VM 메타데이터 값을 설정하는 방법에 대한 자세한 내용은 커스텀 메타데이터 설정을 참조하세요.

VM의 vmDnsSetting 메타데이터 항목을 구성한 후에는 VM에서 DHCP 임대를 새로 고칩니다. VM을 다시 시작하거나, 임대가 만료되기를 기다리거나, 다음 명령어 중 하나를 실행하여 임대를 새로 고칠 수 있습니다.

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

DHCP 임대를 새로 고친 후 VM이 영역 DNS에 대해 사용 설정되었는지 여부를 확인합니다.

마이그레이션할 준비가 되지 않은 프로젝트 수정

마이그레이션할 준비가 되지 않은 프로젝트는 하나 이상의 위험한 DNS 쿼리가 특정 기간(예: 지난 30일 또는 지난 100일) 내에 수행되었음을 의미합니다. 위험한 쿼리는 영역 DNS 이름(VM_NAME.c.PROJECT_ID.internal)을 사용하는 VM에 대한 호출로, 대신 영역 DNS 이름(VM_NAME.ZONE.c.PROJECT_ID.internal)을 사용하여 원활하게 확인할 수 없습니다. 위험한 쿼리에는 다음과 같은 속성이 있을 수 있습니다.

  • 다른 프로젝트에 있는 VM에 대한 호출
  • 다른 영역에 있는 VM에 대한 호출

위험한 쿼리가 포함된 프로젝트의 경우 마이그레이션 전에 위험한 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 레코드 일치가 발견될 때까지 차례로 검색 경로의 각 호스트 이름을 사용하여 쿼리를 해결하려고 시도합니다. 예를 들어 VM이 ping my-vm을 호출하면 검색 경로의 도메인이 원래 쿼리에 추가되어 정규화된 도메인 이름(FQDN)을 가져옵니다(예: my-vm.c.PROJECT_ID.internal 사용). 일치하는 항목이 있으면 DNS 리졸버는 응답에 내부 IP 주소를 반환합니다. 그렇지 않으면 검색 경로의 다음 도메인을 사용하여 DNS 이름을 확인하려고 시도합니다.

VM 검색 경로에 영역 도메인을 추가하면 일부 프로젝트를 마이그레이션할 수 있습니다. 예를 들어 VM이 us-west4-c 영역에 있다고 가정합니다. 이 VM은 us-west4-b 영역에 있는 myapp-vm이라는 또 다른 VM을 호출합니다.

  • VM을 myapp-vm으로 호출하면 Compute Engine은 myapp-vm.c.PROJECT_ID.internal과 같이 VM 이름에 검색 경로 중 하나를 추가하는 FQDN을 사용하여 DNS 이름을 확인하려 시도합니다.
  • 대상 VM이 영역 DNS를 사용하는 경우 대상 VM의 FQDN은 myapp-vm.us-west4-b.c.PROJECT_ID.internal로 등록됩니다. 따라서 DNS 이름을 확인할 수 없습니다.
  • 검색 목록에 us-west4-b.c.PROJECT_ID.internal을 추가한 경우 VM 이름에 us-west4-b.c.PROJECT_ID.internal이 추가되면 DNS 이름 myapp-vm을 확인할 수 있습니다.

Google은 VM과 동일한 리전에 있는 모든 영역에서 VM의 영역 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이면 이제 프로젝트를 마이그레이션할 준비가 완료된 것입니다.
    • 프로젝트가 0이 아닌 값을 반환하면 다음 섹션의 설명대로 모든 전역 DNS 쿼리 이름을 변경하여 영역 FQDN을 사용합니다.

영역 DNS 이름을 사용하도록 수동으로 쿼리 업데이트

검색 경로 개선 기능을 사용하여 DNS 이름 검색 경로에 영역 도메인을 추가해도 일부 교차 영역 쿼리가 전환되지 않는 경우 로그 탐색기를 사용하여 프로젝트 내의 전역 DNS 사용량을 확인할 수 있습니다.

영역 정규화된 도메인 이름(FQDN)을 사용하도록 수동으로 변경해야 하는 전역 DNS 쿼리를 확인하려면 다음 단계를 완료합니다.

  1. 프로젝트를 마이그레이션할 준비가 되었는지 확인의 단계를 따라 프로젝트의 전역 DNS 사용량을 확인합니다. 로그 탐색기를 사용하여 프로젝트에서 VM의 전역 DNS 사용량에 액세스하고 쿼리합니다.

  2. 쿼리 결과 창에서 각 쿼리에는 jsonPayload 필드가 있습니다. 각 jsonPayload 필드에는 다음 정보가 포함됩니다.

    • 소스 VM 이름, 프로젝트 ID, 영역 이름
    • 대상 VM 이름, 프로젝트 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"

    • 소스 VM이 해당 일의 대상 VM으로 전송하는 마이그레이션 차단 쿼리 수를 보여주는 쿼리 수입니다.

    다음 스크린샷은 로그 탐색기 콘솔 페이지의 jsonPayload 필드 정보를 보여줍니다.

    gdnsusage 로그 쿼리 결과의 jsonPayload 스크린샷

  3. jsonPayload의 정보를 사용하여 영역 DNS를 사용하도록 전역 DNS 쿼리를 수동으로 업데이트하고 사용할 프로젝트를 준비하기 위해 사용할 FQDN을 결정합니다. FQDN을 업데이트하고 호환성을 해결하는 가장 일반적인 사용 사례는 다음과 같습니다.

    • 메타데이터 서버의 내부 DNS 이름: 영역 DNS로 마이그레이션한 직후 반환된 DNS 이름이 영역 FQDN으로 변경되므로 별도의 작업이 필요하지 않습니다. DNS 이름이 캐시된 경우 한 번 더 호출하여 캐시 값을 업데이트하면 됩니다.
    • 다른 리전의 VM에 액세스하는 데 사용되는 내부 DNS 이름: 다른 리전의 VM에 내부 DNS 이름을 사용하는 애플리케이션이 있는 경우 DHCP 정책 또는 구성 파일을 수정하여 다른 리전의 영역을 포함할 수 있습니다.
    • 하드 코딩된 전역 FQDN: VM에 하드 코딩된 전역 FQDN 이름을 사용하는 애플리케이션이 있는 경우 대신 내부 DNS 이름 또는 영역 FQDN을 사용하도록 애플리케이션 내에서 호출을 업데이트할 수 있습니다. Terraform에서 코드 변경 또는 구성 변경을 통해 이를 변경할 수 있습니다.
    • 공유 VPC 네트워크를 사용하는 서비스 프로젝트의 VM: 공유 VPC 네트워크를 사용하는 서비스 프로젝트에서 VM의 DNS 이름을 확인하려면 VM의 영역 FQDN을 사용해야 합니다.

영역 DNS를 사용하도록 전역 DNS 쿼리를 업데이트한 후 다음을 수행합니다.

  1. 로그 탐색기 페이지를 사용하여 전역 DNS 사용량을 다시 쿼리합니다. 모든 차단 전역 DNS 쿼리를 수정한 후에는 쿼리 결과에 디버그 로그가 표시되지 않아야 합니다.
  2. 모니터링 측정항목을 다시 확인하여 위험한 DNS 쿼리가 삭제되었는지 확인합니다.

영역 DNS로의 프로젝트 마이그레이션이 완료되었는지 확인

  1. 프로젝트에서 기본적으로 전역 DNS를 사용하는지 확인의 단계를 반복합니다.

  2. 프로젝트 메타데이터가 업데이트되었는지 테스트하려면 다음 명령어를 실행합니다.

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

    이 명령어는 ZONAL_ONLY를 반환해야 합니다.

  3. VM의 내부 DNS 이름에 영역 DNS 이름이 사용되는지 확인합니다.

  4. constraints/compute.setNewProjectDefaultToZonalDNSOnly 조직 정책이 시행되고 있는지 확인하기 위해 다음을 수행할 수 있습니다.

    1. 폴더 또는 조직 아래에 새 프로젝트를 만들기
    2. VM 인스턴스를 만들고 시작하기
    3. VM이 영역 DNS 이름을 사용하는지 확인하기

전역 DNS 사용으로 되돌리기

기본 내부 DNS 유형을 전역 DNS로 다시 변경하여 영역 DNS로의 마이그레이션을 실행취소할 수 있습니다. 이 작업은 조직, 프로젝트, VM 또는 컨테이너 수준에서 수행할 수 있습니다.

조직 또는 폴더에 대해 전역 DNS 사용으로 되돌리기

조직 또는 폴더를 전역 DNS 사용으로 되돌리려면 다음 단계를 완료하세요.

  1. 조직 또는 폴더 수준에서 조직 정책 constraints/compute.setNewProjectDefaultToZonalDNSOnly를 사용 중지합니다. 이 정책을 수정하는 방법에 대한 안내는 새 프로젝트에 기본적으로 영역 DNS 적용을 참조하세요.

    새 프로젝트의 내부 DNS 설정을 영역 DNS 전용으로 설정을 사용 중지로 설정합니다.

  2. 전체 조직에 대해 전역 DNS 사용으로 되돌리려면 조직의 폴더에 조직 정책 constraints/compute.setNewProjectDefaultToZonalDNSOnly가 적용되지 않는지 확인합니다.

  3. 다음 섹션에서 프로젝트, VM, 컨테이너에 대해 전역 DNS가 구성되었는지 확인합니다.

프로젝트에 전역 DNS 사용으로 되돌리기

전역 DNS를 사용하도록 프로젝트를 되돌리려면 다음 단계를 완료합니다.

  1. 프로젝트 메타데이터에 vmDnsSetting=GlobalDefault를 추가합니다.

    프로젝트 메타데이터 또는 VM 메타데이터 값을 설정하는 방법에 대한 자세한 내용은 커스텀 메타데이터 설정을 참조하세요.

  2. 프로젝트에서 vmDnsSetting 메타데이터 값이 ZonalOnly로 설정된 VM이 없는지 확인합니다.

  3. 각 VM에서 DHCP 임대를 새로 고침합니다. VM을 다시 시작하거나, 임대가 만료되기를 기다리거나, 다음 명령어 중 하나를 실행하여 임대를 새로 고침할 수 있습니다.

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

VM에 전역 DNS 사용으로 되돌리기

특정 VM을 전역 DNS 사용으로 되돌리려면 다음 단계를 완료합니다.

  1. VM의 메타데이터에 vmDnsSetting=GlobalDefault를 추가합니다.

    VM 메타데이터 값을 설정하는 방법에 대한 자세한 내용은 커스텀 메타데이터 설정을 참조하세요.

  2. DNS 구성을 강제로 변경하려면 다음 명령어 중 하나를 사용하여 VM의 네트워크를 다시 시작합니다.

  • 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. 컨테이너 및 VM을 소유한 프로젝트에서 프로젝트 메타데이터 설정 vmDnsSetting을 GlobalDefault로 설정합니다.

  2. DNS 설정이 원래 상태로 되돌아가도록 컨테이너를 다시 시작합니다.

전역 DNS에서 영역 DNS로의 마이그레이션 프로세스 문제 해결

마이그레이션 프로세스에 문제가 있으면 문제 해결 가이드를 참조하세요.

Google Cloud 콘솔에서 영역 DNS 마이그레이션 배너 숨기기

Google Cloud 콘솔의 VM 인스턴스 페이지에 표시되는 영역 DNS 마이그레이션 알림 배너에서 닫기 버튼을 클릭할 수 있습니다. 이렇게 하면 프로젝트에 배너가 무기한 표시되지 않습니다.

배너를 닫았지만 다시 표시하려면 클라우드 고객 관리에 문의하여 도움을 받으세요.

다음 단계