영역 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
-
Install the Google Cloud CLI, then initialize it by running the following command:
gcloud init
- Set a default region and zone.
-
조직 정책 만들기 또는 업데이트: 폴더 또는 조직에 대한 조직 정책 관리자(
roles/orgpolicy.policyAdmin
) 권한 -
폴더를 영역 DNS로 마이그레이션할 준비가 되었는지 판단: 폴더 또는 조직에 대한 브라우저(
roles/browser
) 권한 -
영역 DNS를 사용하도록 프로젝트 마이그레이션: 프로젝트에 대한 프로젝트 편집자(
roles/resourcemanager.projectEditor
) 권한 -
VM을 프로젝트 내의 영역 DNS로 마이그레이션: 프로젝트에 대한 Compute 인스턴스 관리자(v1)(
roles/compute.instanceAdmin.v1
) 권한 -
VM에서 서비스 계정을 사용하는 경우: 서비스 계정 또는 프로젝트에 대한 서비스 계정 사용자(
roles/iam.serviceAccountUser
) 권한 -
조직 정책 제약조건 설정:
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
- 이름은 전역 수준에서 확인됩니다.
- 각 VM에는 고유한 DNS 이름이 있어야 합니다.
- 새 VM을 생성할 때 DNS 이름 충돌을 방지하려면 VM의 DNS 이름을 동일한 프로젝트에 등록된 다른 모든 전역 DNS 이름과 비교하여 확인해야 합니다.
- 이름은 영역 내에서 확인됩니다.
- 영역 DNS 이름은 영역 내에서 고유해야 합니다. 예를 들어
my-vm.zone1.google.com
은zone1
에 대해 고유해야 합니다. 그러나 전역 DNS 이름과 달리my-vm.zone2.google.com
은 영역 DNS를 사용할 때도 유효한 DNS 이름입니다. - 프로젝트가 있거나 이전에 있었던 컨트롤 플레인 오류가 발생하는 리전에는 새 VM을 만들 수 없음
- 관리형 인스턴스 그룹(MIG)의 자동 확장 또는 자동 복구와 같이 워크로드에 중요한 일부 Compute Engine 서비스를 사용할 수 없음
- 조직 또는 폴더 수준: 폴더나 조직을 영역 DNS로 마이그레이션할 준비가 되었는지 확인합니다. 새 프로젝트에서 전역 DNS를 사용하지 못하게 합니다. 조직 관리자가 수행합니다.
- 프로젝트 수준: 단일 프로젝트를 전역 DNS에서 영역 DNS로 마이그레이션합니다. 일반적으로 프로젝트 소유자가 수행합니다.
- 폴더나 조직을 영역 DNS로 마이그레이션할 준비가 되었는지 확인합니다.
- 폴더나 조직을 영역 DNS로 마이그레이션할 준비가 되었으면 다음 안내를 따르세요.
- 조직 관리자는 향후 전역 DNS가 사용되지 않도록 폴더나 조직에 대한 조직 정책을 설정합니다.
- 프로젝트 소유자는 영역 DNS를 사용하도록 프로젝트를 마이그레이션합니다.
- 폴더나 조직을 영역 DNS로 마이그레이션할 준비가 되지 않은 경우:
- 프로젝트 소유자가 준비된 프로젝트를 영역 DNS로 마이그레이션합니다.
- 프로젝트 소유자가 준비되지 않은 프로젝트에서 전역 DNS 사용량을 조사합니다.
- 프로젝트 소유자는 검색 경로 개선사항이나 기타 변경사항을 적용하여 프로젝트를 영역 DNS로 마이그레이션할 준비를 합니다.
- 조직 관리자는 영역 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 이상을 사용해야 합니다.
- Linux VM에 연결합니다.
ldd --version
을 실행하여glibc
버전을 가져옵니다.Linux VM의 검색 경로에 이미 도메인 6개가 있는지 확인합니다.
cat /etc/resolv.conf
를 실행하여 이 정보를 볼 수 있습니다.- 조직에서 기본값으로 전역 DNS를 사용하는지 확인
- 폴더 또는 조직에서 전역 DNS를 사용하는 프로젝트 결정
- 폴더를 영역 DNS로 마이그레이션할 준비가 되었는지 확인
- 영역 DNS를 새 프로젝트의 기본값으로 구성
- 조직 정책 제약조건에서 영역 DNS로 마이그레이션할 준비가 되지 않은 폴더 제외
콘솔에서 IAM 및 관리자>ID 및 조직 페이지로 이동합니다.
조직 가입 날짜를 확인합니다.
- 2018년 9월 6일 이후에 조직이 생성된 경우 기본적으로 조직은 영역 DNS를 사용합니다. 이 경우에는 별도의 조치가 필요하지 않습니다.
- 조직이 2018년 9월 6일 전에 생성된 경우 기본적으로 조직은 전역 DNS를 사용하며 영역 DNS로 마이그레이션되어야 합니다.
기본적으로 조직에서 전역 DNS를 사용하는 경우 조직 정책 제약조건이 새로 생성된 모든 프로젝트의 기본 DNS 유형을 영역 DNS로 설정하는지 확인합니다.
- Google Cloud 콘솔에서 IAM 및 관리자>조직 정책 페이지로 이동합니다.
- 필터 필드에
constraints/compute.setNewProjectDefaultToZonalDNSOnly
를 입력합니다. - 제약조건이 구성된 경우 새 프로젝트의 내부 DNS 설정을 영역 DNS 전용으로 설정 이름을 클릭합니다.
- 정책 세부정보 페이지에서 상태를 확인합니다.
- 상태가 적용됨이면 조직에 생성된 모든 새 프로젝트의 기본 내부 DNS 유형은 영역 DNS입니다.
- 그렇지 않으면 프로젝트의 기본 DNS 유형은 계속 조직 생성 시간에 따라 결정됩니다.
- 조직에 제약조건이 구성되지 않으면 프로젝트의 기본 DNS 유형은 첫 번째 단계의 설명대로 조직 생성 시간에 따라 결정됩니다.
조직
creationTime
메타데이터 값을 확인합니다.gcloud organizations describe ORGANIZATION_ID
ORGANIZATION_ID를 조직 ID 번호나 조직 도메인 이름으로 바꿉니다.
- 2018년 9월 6일 이후에 조직이 생성된 경우 기본적으로 조직은 영역 DNS를 사용합니다. 이 경우 조직에서 이미 영역 DNS를 사용하고 있으므로 별도의 작업이 필요하지 않습니다.
- 조직이 2018년 9월 6일 전에 생성된 경우 기본적으로 조직은 전역 DNS를 사용하며 영역 DNS로 마이그레이션되어야 합니다.
기본적으로 조직에서 전역 DNS를 사용하는 경우 조직 정책 제약조건은 새로 생성된 모든 프로젝트의 기본 DNS 유형을 영역 DNS로 설정하도록 구성됩니다.
gcloud resource-manager org-policies list --organization=ORGANIZATION_ID \ --filter="constraints/compute"
출력에서
constraints/compute.setNewProjectDefaultToZonalDNSOnly
를 찾습니다.- 제약조건이 구성되고
Status
가Enforced
이면 조직에서 생성된 모든 새 프로젝트의 기본 내부 DNS 유형은 영역 DNS입니다. - 조직에 제약조건이 구성되지 않았거나 적용되지 않으면 기본 내부 DNS 유형은 첫 번째 단계의 설명대로 조직 생성 시간에 따라 결정됩니다.
- 제약조건이 구성되고
- BigQuery 데이터세트 만들기
조직의 애셋 메타데이터를 BigQuery 테이블로 내보냅니다.
- Cloud Asset Inventory API가 사용 설정되어 있는지 확인합니다.
- Cloud Asset Inventory API를 사용하는 데 필요한 권한을 구성합니다.
다음 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: 메타데이터를 내보내는 테이블. 테이블이 없으면 생성됩니다.
Google Cloud 콘솔에서 BigQuery 페이지로 이동합니다.
새 쿼리 작성을 선택합니다.
쿼리 편집기 텍스트 영역에 다음 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를 사용하도록 설정됩니다.(선택사항) 각 프로젝트의
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
- 지난 30일 동안 모든 프로젝트에서 영역 DNS와 호환되지 않는 쿼리를 실행하지 않았으면 폴더가 준비된 것입니다.
- 폴더를 마이그레이션할 준비가 되지 않으면 스크립트는 폴더를 마이그레이션할 준비가 되지 않는 원인이 되는 폴더의 프로젝트 ID로 응답합니다. 이 결과 목록의 프로젝트는 여전히 영역 DNS와 호환되지 않으며 추가 작업이 필요합니다.
- 폴더 ID를 가져옵니다. 폴더 ID를 모르는 경우 다음 안내를 따르세요.
- Google Cloud 콘솔에서 관리형 리소스 페이지로 이동합니다.
Name:FOLDER_NAME
필터를 적용하여 폴더 ID를 가져옵니다.
내보낸
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 번호
프로젝트 ID 목록을 복사하여 파일에 저장합니다.
다음
bash
스크립트를 실행합니다. 스크립트는 저장된 파일의 프로젝트 ID를 반복하여 폴더를 마이그레이션할 준비가 되었는지 확인합니다.- 마이그레이션하기에 안전한 폴더와 프로젝트의 경우 프로젝트 소유자에게 준비된 프로젝트를 마이그레이션할 수 있다고 알립니다.
- 마이그레이션하기에 안전하지 않은 프로젝트가 포함된 폴더의 경우 프로젝트 소유자에게 마이그레이션할 준비가 되지 않은 프로젝트를 수정하라고 안내합니다.
Google Workspace 또는 Cloud Identity 최고 관리자로 Google Cloud 콘솔에 로그인합니다.
콘솔에서 조직 정책 페이지로 이동합니다.
조직 정책을 보려면 폴더 또는 조직을 선택합니다. Google Cloud 콘솔에 사용 가능한 조직 정책 제약조건 목록이 표시됩니다. 목록은 여러 페이지에 걸쳐 표시될 수 있습니다.
영역 DNS를 시행할 정책을 찾으려면 필터를 클릭하고, 이름을 선택한 후 필터 이름을 새 프로젝트의 내부 DNS 설정을 영역 DNS 전용으로 설정으로 지정합니다.
정책 이름을 클릭하여 세부정보를 확인합니다.
정책 세부정보 페이지에서는 제약조건 정보 및 제약조건 적용 방식을 보여줍니다.
기본적으로 시행은 폴더 또는 조직에 따라 정의되지 않습니다. 하지만 상위 폴더에 정의된 시행이 있으면 해당 시행이 정의된 시행이 포함된 가장 가까운 상위 폴더에서 상속됩니다. 자세한 내용은 계층 구조 평가 이해를 참조하세요.
조직 정책을 맞춤설정하려면 수정을 클릭합니다.
수정 페이지에서 맞춤설정을 선택합니다.
시행에서 사용을 선택합니다.
이렇게 하면 조직의 모든 새 프로젝트에 대한 기본 내부 DNS 유형이 영역 DNS로 설정됩니다.
저장을 클릭합니다.
folders/101
projects/301
(마이그레이션 준비됨)folders/201
projects/303
(준비되지 않음)projects/304
(마이그레이션 준비됨)
folders/102
projects/302
(마이그레이션 준비됨)
- Google Workspace 또는 Cloud Identity 최고 관리자로 Google Cloud 콘솔에 로그인합니다.
콘솔에서 조직 정책 페이지로 이동합니다.
선택을 클릭한 후 조직 정책에서 제외할 폴더를 선택합니다.
해당 폴더의 조직 정책 제약조건 목록이 Google Cloud 콘솔의 페이지 하나 이상에 표시됩니다.
영역 DNS를 적용하는 조직 정책 제약조건을 찾으려면 다음 안내를 따르세요.
- 필터를 클릭합니다.
- 이름을 선택합니다.
- 필터 이름을 새 프로젝트의 내부 DNS 설정을 영역 DNS 전용으로 설정으로 지정합니다.
조직 정책 제약조건 이름을 클릭하여 정책 세부정보 페이지를 엽니다.
수정을 클릭합니다.
수정 페이지에서 맞춤설정을 선택합니다.
적용에서 사용 안함을 선택하여 제약조건 적용을 중지합니다. 즉, 폴더의 모든 프로젝트에 대한 기본 내부 DNS 유형은 조직 생성 시간에 따라 결정됩니다.
저장을 클릭합니다.
- 프로젝트의 기본적인 내부 DNS 유형 확인
- 프로젝트를 영역 DNS로 마이그레이션할 준비가 되었는지 확인
- 영역 DNS를 사용하여 프로젝트 마이그레이션
- 프로젝트 내에서 전역 DNS 사용량 추적
- 영역 DNS로 마이그레이션할 준비가 되지 않은 프로젝트 수정
- 영역 DNS로의 프로젝트 마이그레이션 완료 확인
Google Cloud Console에서 메타데이터 페이지로 이동합니다.
메타데이터 탭에서
vmdnssetting
설정을 봅니다. 이 값은 프로젝트에서 기본적으로 전역 DNS를 사용하는지 여부를 나타냅니다.GlobalDefault
: 프로젝트에 전역 DNS가 사용 설정되어 있음ZonalOnly
: 프로젝트에 영역 DNS가 사용 설정되어 있음. 이 프로젝트를 마이그레이션할 필요가 없습니다.
다음 gcloud CLI 명령어를 실행하여
vmDnsSetting
값을 확인합니다.gcloud compute project-info describe --project=PROJECT_ID --flatten="vmDnsSetting"
PROJECT_ID를 파일 이름으로 바꿉니다.
반환된 값은 프로젝트에서 기본적으로 전역 DNS를 사용하는지 여부를 나타냅니다.
GLOBAL_DEFAULT
: 프로젝트에 전역 DNS가 사용 설정되어 있음ZONAL_ONLY
: 프로젝트에 영역 DNS가 사용 설정되어 있음. 이 프로젝트를 마이그레이션할 필요가 없습니다.
GLOBAL_DEFAULT
: 프로젝트에 전역 DNS가 사용 설정되어 있음ZONAL_ONLY
: 프로젝트에 영역 DNS가 사용 설정되어 있음. 이 프로젝트를 마이그레이션할 필요가 없습니다.Google Cloud 콘솔에서 로그 탐색기 페이지로 이동합니다.
프로젝트를 선택합니다.
리소스 및 로그 이름 필터를 적용합니다.
- 리소스를 클릭합니다.
- 리소스 선택 대화상자에서 VM 인스턴스를 선택한 후 적용을 클릭합니다.
- 로그 이름을 클릭합니다.
로그 이름 선택 대화상자에서 gdnsusage를 선택한 후 적용을 클릭합니다.
zonal_dns_ready
: 지정된 시간 간격 동안 완료되어 집계된 쿼리 수로, 전역 DNS 대신 영역 DNS를 사용하여 확인할 수 있습니다.zonal_dns_risky
: 지정된 시간 간격 동안 완료되어 집계된 쿼리 수로, 영역 DNS를 사용하여 확인할 수 없습니다. 이러한 쿼리의 경우 Compute Engine에서 현재 호스트 이름에서 상대 내부 IP 주소를 확인할 수 없었습니다. 이 측정항목 값이 0이 아니면 프로젝트를 마이그레이션할 준비가 되지 않은 것입니다.-
Google Cloud 콘솔에서 leaderboard 측정항목 탐색기 페이지로 이동합니다.
검색창을 사용하여 이 페이지를 찾은 경우 부제목이 Monitoring인 결과를 선택합니다.
측정항목 선택 필드가 있는 툴바 오른쪽에서 코드 편집기, MQL 또는 PromQL을 클릭합니다.
쿼리 입력란 제목이 MQL 쿼리가 아니면 쿼리 입력란 오른쪽 하단에 있는 언어에서 MQL을 선택합니다.
쿼리 입력란에 다음 텍스트를 표시된 그대로 정확하게 입력합니다.
fetch compute.googleapis.com/Location | metric 'compute.googleapis.com/global_dns/request_count' | every 1d | within 7d
쿼리 실행 버튼을 클릭합니다.
Google Cloud 콘솔에는 두 측정항목(
zonal_dns_ready
및zonal_dns_risky
)의 차트와 각 측정항목의 기간 동안 실행된 해당 쿼리 수가 표시됩니다.zonal_dns_risky
측정항목 값을 확인합니다.- 값이
0
이면 프로젝트를 영역 DNS로 마이그레이션할 준비가 완료된 것입니다. 준비된 프로젝트를 영역 DNS로 마이그레이션의 설명대로 프로젝트를 마이그레이션할 수 있습니다. - 이전 스크린샷에 표시된 것처럼 값이
0.02k
과 같이 0이 아닌 숫자인 경우 영역 DNS로 마이그레이션한 후에 작동하지 않을 수 있는 몇 가지 쿼리가 있습니다. 프로젝트를 마이그레이션할 준비가 되지 않았습니다. 마이그레이션할 준비가 되지 않은 프로젝트 수정의 단계를 계속 진행하세요.
- 값이
- 애플리케이션을 확인하고 업데이트해서 영역 전용 설정과의 호환성 문제를 해결합니다.
- 하드 코딩된 전역 DNS 이름을 사용하는 애플리케이션이 있으면 영역 DNS 이름을 사용하도록 업데이트합니다.
- 애플리케이션에서 VM 이름을 사용하여 다른 영역의 VM에 액세스하는 경우 대상 영역 이름이 쿼리에 추가되었는지 확인합니다(예:
DESTINATION_VM_NAME.DESTINATION_ZONE_NAME
). - 공유 VPC 네트워크를 사용하는 서비스 프로젝트에서 VM의 DNS 이름을 확인하려면 VM의 영역별 정규화된 도메인 이름(FQDN)을 사용해야 합니다.
Google Cloud 콘솔의 VM 인스턴스 페이지에 있는 배너에서 영역 DNS 사용 버튼을 클릭합니다. 이렇게 하면 영역 DNS를 사용하도록 프로젝트 메타데이터가 변경됩니다.
또는 영역 DNS를 사용하도록 프로젝트 및 VM 수동 업데이트 및 기본적으로 새 프로젝트가 전역 DNS를 사용하지 못하도록 방지에 설명된 것처럼 기본적으로 영역 DNS를 사용하도록 프로젝트를 수동으로 수정할 수 있습니다.
권장: 프로젝트 메타데이터에
vmDnsSetting=ZonalOnly
를 설정합니다. 즉, 검색 경로를 사용할 때는 영역 DNS 이름(VM_NAME.ZONE.c.PROJECT_ID.internal
)을 통해서만 VM에 액세스할 수 있습니다. VM은 영역 및 전역 검색 경로를 계속 보존하지만ZONE
이 내부 DNS 이름의 일부로 포함되지 않은 전역 DNS 이름은 더 이상 작동하지 않습니다. 이 설정이 적용되면 같은 영역과 같은 프로젝트에 있는 VM만 전역 이름을 사용하여 서로 액세스할 수 있습니다. 다른 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에 이 설정이 기본적으로 적용됩니다.- Linux VM:
sudo dhclient -v -r
- Windows Server VM:
ipconfig /renew
- 다른 프로젝트에 있는 VM에 대한 호출
- 다른 영역에 있는 VM에 대한 호출
- 검색 경로 개선을 사용 설정하여 영역 간 DNS 이름 조회를 수행합니다. 이렇게 하면 리소스에 영향을 주지 않고 프로젝트를 마이그레이션할 수 있습니다.
- 검색 경로 조정으로 모든 교차 영역 쿼리가 전환되지 않는 경우에는 영역 DNS 이름을 사용하도록 쿼리를 수동으로 업데이트할 수 있습니다.
- 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
을 확인할 수 있습니다. 다음과 같이
project-info add-metadata
명령어를 실행합니다.gcloud compute project-info add-metadata \ --metadata=enable-search-path-improvement=true
프로젝트에서 며칠 동안 이 설정을 사용하도록 허용한 후 모니터링 측정항목을 확인하여 아직도 위험하거나 교차 영역 전역 DNS 쿼리가 있는지 확인합니다.
- 프로젝트 값이
0
이면 이제 프로젝트를 마이그레이션할 준비가 완료된 것입니다. - 프로젝트가 0이 아닌 값을 반환하면 다음 섹션의 설명대로 모든 전역 DNS 쿼리 이름을 변경하여 영역 FQDN을 사용합니다.
- 프로젝트 값이
프로젝트를 마이그레이션할 준비가 되었는지 확인의 단계를 수행하여 프로젝트의 전역 DNS 사용량을 봅니다. 로그 탐색기를 사용하여 프로젝트의 VM에 대한 전역 DNS 사용량에 액세스하고 쿼리합니다.
쿼리 결과 창의 각 쿼리에는
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
필드 정보를 보여줍니다.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 쿼리를 수정한 후에는 쿼리 결과에 디버그 로그가 표시되지 않아야 합니다.
- 모니터링 측정항목을 다시 확인하여 위험한 DNS 쿼리가 모두 삭제되었는지 확인합니다.
프로젝트에서 기본적으로 전역 DNS를 사용하는지 확인의 단계를 반복합니다.
프로젝트 메타데이터가 업데이트되었는지 테스트하려면 다음 명령어를 실행하면 됩니다.
gcloud compute project-info describe --flatten="vmDnsSetting"
이 명령어는
ZONAL_ONLY
를 반환해야 합니다.VM의 내부 DNS 이름에서 영역 DNS 이름을 사용하는지 확인합니다.
constraints/compute.setNewProjectDefaultToZonalDNSOnly
조직 정책이 시행되고 있는지 확인하기 위해 다음을 수행할 수 있습니다.- 폴더 또는 조직 아래에 새 프로젝트를 만들기
- VM 인스턴스를 만들고 시작하기
- VM이 영역 DNS 이름을 사용하는지 확인하기
조직 또는 폴더 수준에서 조직 정책
constraints/compute.setNewProjectDefaultToZonalDNSOnly
를 사용 중지합니다. 이 정책을 수정하는 방법은 기본적으로 새 프로젝트에 영역 DNS 적용을 참조하세요.새 프로젝트의 내부 DNS 설정을 영역 DNS 전용으로 설정 적용을 사용 안함으로 설정합니다.
전체 조직에 전역 DNS 사용으로 되돌리려면 조직의 폴더 중에서 조직 정책
constraints/compute.setNewProjectDefaultToZonalDNSOnly
를 적용하는 폴더가 없는지 확인합니다.다음 섹션을 수행하여 프로젝트, VM, 컨테이너에 전역 DNS가 구성되어 있는지 확인합니다.
프로젝트 메타데이터에
vmDnsSetting=GlobalDefault
를 추가합니다.프로젝트 메타데이터 또는 VM 메타데이터 값을 설정하는 방법에 대한 자세한 내용은 커스텀 메타데이터 설정을 참조하세요.
프로젝트의 VM 중
vmDnsSetting
메타데이터 값이ZonalOnly
로 설정된 VM이 없는지 확인합니다.각 VM에서 DHCP 임대를 새로 고침합니다. VM을 다시 시작하거나, 임대가 만료되기를 기다리거나, 다음 명령어 중 하나를 실행하여 임대를 새로 고침할 수 있습니다.
- Linux VM:
sudo dhclient -v -r
- Windows Server VM:
ipconfig /renew
- Linux VM:
VM 메타데이터에
vmDnsSetting=GlobalDefault
를 추가합니다.VM 메타데이터 값을 설정하는 방법에 대한 자세한 내용은 커스텀 메타데이터 설정을 참조하세요.
DNS 구성을 강제로 적용하려면 다음 명령어 중 하나를 사용하여 VM 네트워크를 다시 시작합니다.
Container-Optimized OS 또는 Ubuntu의 경우:
sudo systemctl restart systemd-networkd
CentOS, RedHat EL, Fedora CoreOS 또는 Rocky Linux의 경우:
sudo systemctl restart network
또는
sudo systemctl restart NetworkManager.service
Debian의 경우:
sudo systemctl restart networking
nmcli
가 있는 Linux 시스템의 경우:sudo nmcli networking off sudo nmcli networking on
Windows:
ipconfig /renew
컨테이너와 VM을 소유한 프로젝트에서 프로젝트 메타데이터 설정
vmDnsSetting
을GlobalDefault
로 설정합니다.DNS 설정이 원래 상태로 되돌아가도록 컨테이너를 다시 시작합니다.
- 조직, 폴더, 프로젝트 간의 관계에 대한 자세한 내용은 Google Cloud 리소스 계층 구조 살펴보기
- Compute Engine의 내부 DNS 자세히 알아보기
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 역할을 부여해 달라고 요청하세요.
역할 부여에 대한 자세한 내용은 프로젝트, 폴더, 조직에 대한 액세스 관리를 참조하세요.
이러한 사전 정의된 역할에는 영역 DNS로 마이그레이션하는 데 필요한 권한이 포함되어 있습니다. 필요한 정확한 권한을 보려면 필수 권한 섹션을 펼치세요.
필수 권한
영역 DNS로 마이그레이션하려면 다음 권한이 필요합니다.
커스텀 역할이나 다른 사전 정의된 역할을 사용하여 이 권한을 부여받을 수도 있습니다.
DNS 이름 정보
영역 DNS 이름에는 VM의 이름, VM이 있는 영역, VM을 소유하는 프로젝트가 포함됩니다. 전역 DNS 이름에는 VM이 위치한 영역이 포함되지 않습니다.
전역 DNS 이름을 사용하여 VM을 호출하는 경우:
영역 DNS 이름을 사용하여 VM을 호출하는 경우:
영역 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에서 영역 DNS로 대체되었습니다. 기존 프로젝트에 아직 전역 DNS가 사용되는 경우에는 영역 DNS 이름을 사용하도록 프로젝트를 전환하는 것이 가장 좋습니다. 영역 DNS로 마이그레이션하지 않으면 다음과 같은 문제가 발생할 수 있습니다.
전역 DNS를 사용하는 워크로드의 신뢰성을 개선하는 다른 방법은 Cloud DNS 비공개 영역으로 마이그레이션하는 것입니다. Cloud DNS 비공개 영역을 사용하면 전역 DNS에 필요한 이름 고유성 검사가 삭제되고 DNS 이름을 변환할 수 있도록 오류가 격리됩니다. 이 옵션에 대한 자세한 내용은 Cloud DNS 문서를 참조하거나 Cloud Customer Care 또는 계정팀 담당자에게 문의하세요. Cloud DNS에서 영역 및 리전 서비스 중단을 처리하는 방법에 대한 자세한 내용은 클라우드 인프라 서비스 중단의 재해 복구 설계를 참조하세요.
마이그레이션 프로세스 개요
영역 DNS 마이그레이션 프로세스에는 두 가지 수준이 있습니다.
일반적으로 이 프로세스에는 다음 단계가 포함됩니다.
제한사항
glibc 버전 확인
VM에서 사용하는
glibc
버전을 확인하려면 다음 안내를 따르세요.glibc 2.25 이하를 사용하는 경우 검색 도메인 수 확인
조직 관리자 단계
조직 관리자는 다음 태스크를 수행합니다.
조직에서 기본값으로 전역 DNS를 사용하는지 확인
조직의 내부 DNS 이름 기본 유형은 조직이 생성된 날짜와 조직 정책 제약조건
constraints/compute.setNewProjectDefaultToZonalDNSOnly
가 적용되는지 여부에 따라 결정됩니다.콘솔
gcloud
organizations describe
명령어 및resource-manager org-policies list
명령어를 사용하여 조직의 기본 DNS 유형을 확인합니다.폴더 또는 조직에서 전역 DNS를 사용하는 프로젝트 결정
전역 DNS를 사용하는 프로젝트 수를 확인하려면 BigQuery를 사용하여 조직의 상대 프로젝트와 해당 메타데이터를 나열하는 테이블을 만드는 것이 좋습니다. 그런 다음 이 테이블을 사용하여 전역 DNS를 사용하는 프로젝트 총개수를 노출하는 쿼리를 실행할 수 있습니다.
폴더를 영역 DNS로 마이그레이션할 준비가 되었는지 확인
이 단계에서는
bash
스크립트와 이전 섹션에서 만든 BigQuery 테이블을 사용하여 폴더의 마이그레이션 준비 상태를 확인합니다.다음 단계를 완료합니다.
#!/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이 있는 폴더 또는 조직 수준 액세스 권한이 있어야 합니다.
다음 단계에 따라 폴더 또는 조직에 대해 조직 정책을 설정합니다.
조직 정책 변경을 검사하려면 폴더 또는 조직 아래에 새 프로젝트를 만들고, VM 인스턴스를 생성 및 시작하고, 영역 DNS에 대해 VM이 사용 설정되었는지 여부를 확인합니다.
워크로드에 빌드된 DNS 이름 쿼리를 확인하기 위해 전역 DNS가 필요하면 조직 또는 폴더 수준에서 시행을 사용 중지하여 이 변경사항을 롤백할 수 있습니다.
영역 DNS로 마이그레이션할 준비가 되지 않은 폴더 제외
조직 내에서 영역 DNS로 마이그레이션할 준비가 되지 않은 폴더가 몇 개에 불과한 경우, 조직 수준에서 조직 정책을 설정하는 것을 권장하지만, 아직 마이그레이션할 준비가 되지 않은 폴더에 대해 예외를 부여하는 것이 좋습니다.
다음 예시에서는 영역 DNS로 마이그레이션할 준비가 되지 않은 폴더가 하나만 있는 조직 계층 구조를 보여줍니다.
organization/Example.com
폴더를 조직 정책에서 제외하려면 다음 단계를 완료하여 폴더 수준에서 정책의 적용 옵션을
Off
로 설정합니다.조직 정책 제약조건 맞춤설정에 대한 자세한 내용은 Resource Manager 문서의 불리언 제약조건에 대한 정책 맞춤설정을 참조하세요.
프로젝트 소유자 단계
프로젝트 소유자는 전역 DNS에서 영역 DNS로 마이그레이션하는 동안 다음 태스크를 수행합니다.
프로젝트 소유자는 다음과 같은 선택적 태스크도 완료할 수 있습니다.
프로젝트에서 기본적으로 전역 DNS를 사용하는지 확인
프로젝트를 확인하여 전역 DNS 사용에서 영역 DNS 사용으로 마이그레이션해야 하는지 확인합니다. 프로젝트 내에서 생성된 내부 DNS 이름의 기본값으로 전역 DNS를 사용하도록 구성된 프로젝트만 마이그레이션해야 합니다.
콘솔
gcloud
In the Google Cloud console, 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.
REST
projects.get
메서드를 사용하여vmDnsSetting
값을 확인합니다. 이 예시에서는fields
쿼리 파라미터를 사용하여 보려는 필드만 포함합니다.GET https://compute.googleapis.com/compute/v1/projects/PROJECT_ID?fields=id,name,vmDnsSetting
PROJECT_ID를 프로젝트 ID로 바꿉니다.
vmDnsSetting
값은 프로젝트에서 기본적으로 전역 DNS를 사용하는지 여부를 나타냅니다.프로젝트를 마이그레이션할 준비가 되었는지 확인
Google Cloud 콘솔의 VM 인스턴스 페이지에서 프로젝트를 영역 DNS로 마이그레이션해야 하는 경우 영역 DNS 마이그레이션에 대한 알림 배너가 표시됩니다.
프로젝트의 VM 인스턴스 페이지를 열람할 때, 프로젝트를 마이그레이션할 준비가 된 경우(영역 DNS와 호환됨) 배너에 영역 DNS 사용을 권장하는 사항이 포함됩니다. 이 추천은 프로젝트의 내부 DNS 사용량을 기반으로 하지만 지난 100일로 제한됩니다.
프로젝트를 영역 DNS로 마이그레이션할 준비가 되지 않으면 다른 배너가 표시됩니다.
전역 DNS 사용량을 보려면 전역 DNS 사용량 보기 버튼을 클릭합니다. 그러면 Google Cloud 콘솔의 로그 탐색기 페이지로 이동합니다. 이 페이지에서는 지난 30일 동안의 마이그레이션 차단 쿼리 로그를 볼 수 있습니다. 배너의 링크를 클릭하면 로그 탐색기 페이지가 logName 필터를 사용하여 전역 DNS 쿼리와 상대 로그 필드를 가져오도록 구성됩니다.
배너의 버튼을 사용하지 않고 이 정보를 보려면 다음을 수행합니다.
또는 쿼리 필드에 다음을 입력:
resource.type="gce_instance" log_name="projects/PROJECT_ID/logs/compute.googleapis.com%2Fgdnsusage"
프로젝트 내에서 전역 DNS 사용량 추적
영역 DNS로 마이그레이션할 프로젝트 준비 상태를 추적할 수 있도록 두 가지 측정항목이 생성되었습니다.
이 측정항목에 사용되는 시간 간격은 100일입니다.
이러한 측정항목을 보려면 Google Cloud 콘솔에서 측정항목 탐색기를 사용합니다.
준비된 프로젝트를 영역 DNS에 마이그레이션
일반적으로 다음과 같은 마이그레이션 프로세스를 사용할 수 있습니다.
영역 DNS를 사용하도록 프로젝트 및 VM 수동 업데이트
프로젝트를 영역 DNS로 마이그레이션할 준비가 되었다고 판단되면 메타데이터를 업데이트하여 영역 DNS 이름만 사용하도록 프로젝트와 VM을 구성할 수 있습니다. 프로젝트나 VM의
vmDnsSetting
메타데이터 항목을 설정하여 VM에 영역 DNS를 사용 설정합니다. 특정 VM의vmDnsSetting
메타데이터 항목을 설정하면 해당 VM의 프로젝트 메타데이터에서 상속된 모든vmDnsSetting
설정이 재정의됩니다.vmDnsSetting
변수는 다음 설정을 지원합니다.프로젝트 메타데이터 또는 VM 메타데이터 값을 설정하는 방법에 대한 자세한 내용은 커스텀 메타데이터 설정을 참조하세요.
VM에
vmDnsSetting
메타데이터 항목을 구성한 후에는 VM에서 DHCP 임대 기간을 새로고침합니다. VM을 다시 시작하거나, 임대가 만료되기를 기다리거나, 다음 명령어 중 하나를 실행하여 임대를 새로 고칠 수 있습니다.DHCP 임대를 새로 고친 후 VM이 영역 DNS에 대해 사용 설정되었는지 여부를 확인합니다.
마이그레이션할 준비가 되지 않은 프로젝트 수정
마이그레이션할 준비가 되지 않은 프로젝트는 하나 이상의 위험한 DNS 쿼리가 특정 기간(예: 지난 30일 또는 지난 100일) 내에 수행되었음을 의미합니다. 위험한 쿼리는 영역 DNS 이름(
VM_NAME.c.PROJECT_ID.internal
)을 사용하는 VM에 대한 호출로, 대신 영역 DNS 이름(VM_NAME.ZONE.c.PROJECT_ID.internal
)을 사용하여 원활하게 확인할 수 없습니다. 위험한 쿼리에는 다음과 같은 속성이 있을 수 있습니다.위험한 쿼리가 포함된 프로젝트의 경우 마이그레이션 전에 위험한 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을 호출합니다.Google은 VM과 동일한 리전에 있는 모든 영역에서 VM의 영역 DNS 이름을 자동으로 검색하는 검색 경로 개선 기능을 제공합니다. 따라서
resolv.conf
파일 또는 DHCP 정책을 업데이트하지 않고도 교차 영역 쿼리를 확인할 수 있습니다. 검색 경로 개선을 통해 리전 내 교차 영역 쿼리를 최대 80%까지 확인할 수 있습니다. 이 기능은 위험한 쿼리가 있는 대부분의 프로젝트를 영역 DNS로 마이그레이션하도록 준비시키는 데 도움이 됩니다.검색 경로 개선을 사용 설정하여 교차 영역 DNS 이름 조회를 수행합니다.
다음 단계를 수행하여 검색 경로 개선 기능을 사용 설정합니다.
영역 DNS 이름을 사용하도록 수동으로 쿼리 업데이트
검색 경로 개선 기능을 사용하여 DNS 이름 검색 경로에 영역 도메인을 추가해도 일부 교차 영역 쿼리가 전환되지 않는 경우 로그 탐색기를 사용하여 프로젝트 내의 전역 DNS 사용량을 확인할 수 있습니다.
영역 정규화된 도메인 이름(FQDN)을 사용하도록 수동으로 변경해야 하는 전역 DNS 쿼리를 확인하려면 다음 단계를 완료합니다.
영역 DNS를 사용하도록 전역 DNS 쿼리를 업데이트한 후 다음 안내를 따르세요.
영역 DNS로의 프로젝트 마이그레이션 완료 확인
전역 DNS 사용으로 되돌리기
기본 내부 DNS 유형을 전역 DNS로 다시 변경하여 영역 DNS로의 마이그레이션을 실행취소할 수 있습니다. 조직, 프로젝트, VM 또는 컨테이너 수준에서 이 작업을 수행할 수 있습니다.
조직 또는 폴더에 전역 DNS 사용으로 되돌리기
전역 DNS를 사용하도록 조직이나 폴더를 되돌리려면 다음 단계를 완료합니다.
프로젝트에 전역 DNS 사용으로 되돌리기
전역 DNS를 사용하도록 프로젝트를 되돌리려면 다음 단계를 완료합니다.
VM에 전역 DNS 사용으로 되돌리기
전역 DNS를 사용하도록 특정 VM을 되돌리려면 다음 단계를 완료합니다.
컨테이너에 전역 DNS 사용으로 되돌리기
컨테이너, Google Kubernetes Engine, 또는 App Engine 가변형 환경에서 애플리케이션을 실행하는 경우 컨테이너를 다시 시작하기 전에는 컨테이너 설정의 DNS 구성이 자동으로 업데이트되지 않을 수 있습니다. 이러한 컨테이너 앱에서 영역 DNS를 사용 중지하려면 다음 단계를 완료합니다.
전역 DNS에서 영역 DNS로의 마이그레이션 프로세스 문제 해결
마이그레이션 프로세스에 문제가 있으면 문제 해결 가이드를 참조하세요.
Google Cloud 콘솔에서 영역 DNS 마이그레이션 배너 숨기기
Google Cloud 콘솔의 VM 인스턴스 페이지에 표시되는 영역 DNS 마이그레이션 알림 배너에서 닫기 버튼을 클릭할 수 있습니다. 이렇게 하면 배너가 프로젝트에 무기한으로 표시되지 않습니다.
배너를 닫았지만 다시 표시하려면 Cloud Customer Care에 문의하여 도움을 요청하세요.
다음 단계
달리 명시되지 않는 한 이 페이지의 콘텐츠에는 Creative Commons Attribution 4.0 라이선스에 따라 라이선스가 부여되며, 코드 샘플에는 Apache 2.0 라이선스에 따라 라이선스가 부여됩니다. 자세한 내용은 Google Developers 사이트 정책을 참조하세요. 자바는 Oracle 및/또는 Oracle 계열사의 등록 상표입니다.
최종 업데이트: 2024-11-25(UTC)
-