이 페이지에서는 Cloud DNS를 Google Kubernetes Engine(GKE)용 Kubernetes DNS 공급업체로 사용하는 방법을 설명합니다.
Cloud DNS를 DNS 공급업체로 사용하면 클러스터 외부의 클라이언트가 Kubernetes 서비스를 직접 확인하고 연결할 수 없습니다. 그래도 부하 분산기를 사용하여 서비스를 외부에 노출하고 DNS 인프라에 클러스터 외부 IP 주소를 등록해야 합니다.
kube-dns를 DNS 제공업체로 사용하는 방법에 대한 자세한 내용은 서비스 검색 및 DNS를 참조하세요.
커스텀 버전의 kube-dns 또는 커스텀 DNS 제공업체를 사용하는 방법은 커스텀 kube-dns 배포 설정을 참고하세요.
GKE용 Cloud DNS 작동 방식
Cloud DNS를 GKE의 DNS 제공업체로 사용하여, 포드 및 서비스 DNS 변환에 클러스터 호스팅되는 DNS 제공업체가 필요 없는 관리형 DNS를 제공할 수 있습니다. 포드 및 서비스의 DNS 레코드는 클러스터 IP 주소, 헤드리스, 외부 이름 서비스에 대해 Cloud DNS에서 자동으로 프로비저닝됩니다.
Cloud DNS는 전체 Kubernetes DNS 사양을 지원하고 GKE 클러스터 내 서비스에 A, AAAA, SRV, PTR 레코드 확인을 제공합니다. PTR 레코드는 응답 정책 규칙을 사용하여 구현됩니다.
Cloud DNS를 GKE의 DNS 제공업체로 사용하면 다음과 같이 클러스터 호스팅되는 DNS보다 다양한 이점이 있습니다.
- 클러스터 호스팅 DNS 서버 관리 오버헤드를 제거합니다. Cloud DNS는 확장성이 뛰어난 Google 인프라에서 호스팅되는 완전 관리형 서비스이므로 DNS 인스턴스를 확장, 모니터링 또는 관리할 필요가 없습니다.
- 각 GKE 노드에서 DNS 쿼리의 로컬 변환. NodeLocal DNSCache와 마찬가지로 Cloud DNS는 DNS 응답을 로컬로 캐시하므로 지연 시간이 짧고 확장성이 높은 DNS 변환을 제공합니다.
- DNS 모니터링 및 로깅을 위해 Google Cloud Observability과 통합. 자세한 내용은 비공개 관리 영역의 로깅 사용 설정 및 사용 중지를 참조하세요.
아키텍처
Cloud DNS가 GKE의 DNS 제공업체일 때 컨트롤러는 GKE 관리형 포드로 실행됩니다. 이 포드는 클러스터의 제어 영역 노드에서 실행되며 클러스터 DNS 레코드를 관리형 비공개 DNS 영역에 동기화합니다.
다음 다이어그램은 Cloud DNS 제어 영역과 데이터 영역이 클러스터 이름을 변환하는 방법을 보여줍니다.
다이어그램에서 서비스 backend
는 실행 중인 backend
포드를 선택합니다.
clouddns-controller
는 서비스 backend
의 DNS 레코드를 만듭니다.
포드 frontend
는 backend
라는 서비스의 IP 주소를 변환하기 위한 DNS 요청을 169.254.169.254
의 Compute Engine 로컬 메타데이터 서버로 전송합니다. 메타데이터 서버는 노드에서 로컬로 실행되어 캐시 부적중을 Cloud DNS로 전송합니다.
Cloud DNS 데이터 영역은 각 GKE 노드 또는 Compute Engine 가상 머신(VM) 인스턴스 내에서 로컬로 실행됩니다. Kubernetes 서비스 유형에 따라 Cloud DNS는 서비스 이름을 클러스터 IP 서비스의 경우 가상 IP 주소로, 헤드리스 서비스의 경우 엔드포인트 IP 주소 목록으로 변환합니다.
포드 frontend
가 IP 주소를 변환하면 포드는 서비스 backend
및 서비스 뒤에 있는 포드로 트래픽을 전송할 수 있습니다.
DNS 범위
Cloud DNS에는 다음과 같은 DNS 범위가 있습니다. 클러스터는 여러 모드에서 동시에 작동할 수 없습니다.
GKE 클러스터 범위: DNS 레코드는 클러스터 내에서만 확인할 수 있으며 kube-dns와 동일하게 동작합니다. GKE 클러스터에서 실행되는 노드만 서비스 이름을 확인할 수 있습니다. 기본적으로 클러스터에는
*.cluster.local
로 끝나는 DNS 이름이 있습니다. 이러한 DNS 이름은 클러스터 내에서만 표시되며 같은 프로젝트에 있는 다른 GKE 클러스터의*.cluster.local
DNS 이름과 겹치거나 충돌하지 않습니다. 이는 기본 모드입니다.VPC 범위: DNS 레코드를 전체 VPC 내에서 변환할 수 있습니다. Compute Engine VM 및 온프레미스 클라이언트는 Cloud Interconnect 또는 Cloud VPN을 사용하여 연결하고 GKE 서비스 이름을 직접 변환할 수 있습니다. 각 클러스터에 고유한 커스텀 도메인을 설정해야 합니다. 즉, 모든 서비스와 포드 DNS 레코드가 VPC 내에서 고유해야 합니다. 이 모드는 GKE 리소스와 GKE 이외 리소스 간의 통신 문제를 줄입니다.
다음 표에는 DNS 범위 간의 차이점이 나와 있습니다.
기능 | GKE 클러스터 범위 | Cloud DNS 추가 VPC 범위 | VPC 범위 |
---|---|---|---|
DNS 가시성 범위 | GKE 클러스터 내에서만 | 전체 VPC 네트워크로 확장 | 전체 VPC 네트워크 |
헤드리스 서비스 확인 | 클러스터 내에서 확인 가능 | `cluster.local`을 사용하여 클러스터 내에서, 클러스터 서픽스를 사용하여 VPC 전반에서 확인 가능 | 클러스터 내에서 그리고 VPC 전반에서 클러스터 서픽스를 사용하여 확인 가능 |
고유 도메인 요구사항 | 아니요. 기본 `*.cluster.local`을 사용합니다. | 예, 고유한 커스텀 도메인을 설정해야 합니다. | 예, 고유한 커스텀 도메인을 설정해야 합니다. |
설정 구성 | 기본값, 추가 단계 없음 | 클러스터 생성 시 선택사항 언제든지 사용 설정/사용 중지 가능 |
클러스터 생성 중에 구성해야 함 |
Cloud DNS 리소스
GKE 클러스터의 DNS 제공업체로 Cloud DNS를 사용하면 Cloud DNS 컨트롤러가 프로젝트의 Cloud DNS에 리소스를 만듭니다. GKE에서 만드는 리소스는 Cloud DNS 범위에 따라 달라집니다.
범위 | 정방향 조회 영역 | 역방향 조회 영역 |
---|---|---|
클러스터 범위 | (리전의) Compute Engine 영역별 클러스터당 비공개 영역 1개 | (리전의) Compute Engine 영역별 클러스터당 응답 정책 영역 1개 |
Cloud DNS 추가 VPC 범위 | 클러스터(전역 영역)당 Compute Engine 영역(리전)별 클러스터당 비공개 영역 1개, 클러스터(전역 영역)당 VPC 범위 비공개 영역 1개 |
클러스터(전역 영역)당 Compute Engine 영역(리전)별 클러스터당 응답 정책 영역 1개, 클러스터(전역 영역)당 VPC 범위 응답 정책 영역 1개 |
VPC 범위 | 클러스터(전역 영역)당 비공개 영역 1개 | 클러스터(전역 영역)당 응답 정책 영역 1개 |
이러한 Cloud DNS 리소스에 사용되는 명명 규칙은 다음과 같습니다.
범위 | 정방향 조회 영역 | 역방향 조회 영역 |
---|---|---|
클러스터 범위 | gke-CLUSTER_NAME-CLUSTER_HASH-dns |
gke-CLUSTER_NAME-CLUSTER_HASH-rp |
Cloud DNS 추가 VPC 범위 | gke-CLUSTER_NAME-CLUSTER_HASH-dns : 클러스터 범위 영역
gke-CLUSTER_NAME-CLUSTER_HASH-dns-vpc : VPC 범위 영역
|
클러스터 범위 영역의 경우 gke-CLUSTER_NAME-CLUSTER_HASH-rp
VPC 범위 영역의 경우 gke-NETWORK_NAME_HASH-rp |
VPC 범위 | gke-CLUSTER_NAME-CLUSTER_HASH-dns |
gke-NETWORK_NAME_HASH-rp |
이전 표에 나온 영역 외에도 Cloud DNS 컨트롤러가 구성에 따라 프로젝트에 다음 영역을 만듭니다.
맞춤 DNS 구성 | 영역 유형 | 영역 이름 지정 규칙 |
---|---|---|
스텁 도메인 | 전달(전역 영역) | gke-CLUSTER_NAME-CLUSTER_HASH-DOMAIN_NAME_HASH |
맞춤 업스트림 네임서버 | 전달(전역 영역) | gke-CLUSTER_NAME-CLUSTER_HASH-upstream |
커스텀 스텁 도메인이나 커스텀 업스트림 네임서버를 만드는 방법에 대한 자세한 내용은 스텁 도메인에 커스텀 리졸버 추가를 참조하세요.
관리형 영역 및 전달 영역
내부 DNS 트래픽을 서빙하기 위해 Cloud DNS 컨트롤러는 클러스터가 속한 리전의 각 Compute Engine 영역에 관리형 DNS 영역을 만듭니다.
예를 들어 클러스터를 us-central1-c
영역에 배포하면 Cloud DNS 컨트롤러가 us-central1-a
, us-central1-b
, us-central1-c
, us-central1-f
에 관리형 영역을 만듭니다.
Cloud DNS 컨트롤러는 DNS stubDomain
마다 전달 영역을 하나씩 만듭니다.
Cloud DNS는 .
DNS 이름을 사용하는 관리형 영역 한 개를 사용하여 각 DNS 업스트림을 처리합니다.
가격 책정
Cloud DNS가 GKE Standard 클러스터의 DNS 제공업체인 경우 GKE 클러스터 내 포드의 DNS 쿼리 요금은 Cloud DNS 가격 책정 기준에 따라 청구됩니다.
GKE에서 관리하는 VPC 범위 DNS 영역에 대한 쿼리에는 표준 Cloud DNS 가격 책정을 사용하여 요금을 청구합니다.
요구사항
프로젝트에 Cloud DNS API가 사용 설정되어 있어야 함
GKE용 Cloud DNS의 클러스터 범위 요구사항은 다음과 같습니다.
- 표준인 경우 GKE 버전 1.24.7-gke.800, 1.25.3-gke.700 이상
- Autopilot의 경우 GKE 버전 1.25.9-gke.400, 1.26.4-gke.500 이상
- Google Cloud CLI 버전 411.0.0 이상
GKE용 Cloud DNS의 추가 VPC 범위 요구사항은 다음과 같습니다.
- GKE 버전 1.28.3-gke.1430000 이상
- Google Cloud CLI 버전 503.0.0 이상
- GKE 클러스터는 Cloud DNS 클러스터 범위를 기본 DNS 제공업체로 사용해야 합니다.
GKE용 Cloud DNS의 VPC 범위 요구사항은 다음과 같습니다.
- 표준인 경우 GKE 버전 1.19 이상
- Google Cloud CLI 버전 364.0.0 이상
- 프로젝트에 Cloud DNS API가 사용 설정되어 있어야 함
제한 및 한도
다음과 같은 제한사항이 적용됩니다.
VPC 범위는 Autopilot 클러스터에서 지원되지 않으며 클러스터 범위만 지원됩니다. GKE Autopilot 클러스터에서 실행되는 헤드리스 서비스 이름을 확인해야 하는 경우 추가 VPC 범위를 사용해야 합니다.
추가 VPC 범위 GKE Autopilot 클러스터는 클러스터를 만들 때만 사용 설정할 수 있습니다. 기존 GKE Autopilot 클러스터에서 추가 VPC 범위를 사용 설정하거나 사용 중지하는 것은 지원되지 않습니다.
공유 VPC 네트워크의 서비스 프로젝트에서 추가 VPC 범위 클러스터를 만드는 것은 지원되지 않습니다.
IL4 규정 준수 체계가 있는 Assured Workload에서는 GKE용 Cloud DNS를 사용할 수 없습니다. 이러한 규제 환경에서는 kube-dns가 강제 적용됩니다.
관리형 비공개 DNS 영역에 대한 수동 변경은 지원되지 않으며 Cloud DNS 컨트롤러에서 덮어씁니다. 이러한 영역의 DNS 레코드 수정사항은 컨트롤러가 다시 시작될 때 유지되지 않습니다.
클러스터에서 GKE용 Cloud DNS를 사용 설정하면 kube-dns가 계속 클러스터에서 실행됩니다. 사용자는 kube-dns 배포 및 자동 확장 처리를 0으로 확장하여 kube-dns를 사용 중지할 수 있습니다.
--cluster-dns-scope
플래그로 범위를 설정하면 클러스터에서 DNS 범위를 변경할 수 없습니다. DNS 범위를 변경해야 하는 경우 다른 DNS 범위로 클러스터를 다시 만드세요.CloudDNS 리소스 제한사항이 적용됩니다. 특히 한 번에 하나의 응답 정책 영역만 VPC 네트워크에 바인드할 수 있습니다. VPC 및 부가 VPC 범위의 경우 클러스터의 VPC 네트워크에 바인딩된 명명 규칙을 따르지 않는 응답 정책 영역이 이미 있으면 클러스터 생성이 실패합니다.
커스텀 스텁 도메인과 업스트림 DNS 서버 구성이 포드와 노드의 DNS 구성에 적용됩니다. 호스트 네트워킹을 사용하는 포드 또는 호스트에서 직접 실행되는 프로세스는 스텁 도메인과 업스트림 네임서버 구성을 사용합니다. 이는 Standard에서만 지원됩니다.
kube-dns Configmap을 통해 구성된 커스텀 스텁 도메인과 업스트림 네임서버는 자동으로 클러스터 범위 DNS의 Cloud DNS에 적용됩니다. VPC 범위 DNS는 kube-dns ConfigMap을 무시하므로 직접 Cloud DNS에 이러한 구성을 적용해야 합니다. 이는 Standard에서만 지원됩니다.
kube-dns에서 VPC 범위로의 마이그레이션 경로는 없으며, 작업이 중단됩니다. kube-dns에서 VPC 범위로 전환하거나 그 반대로 전환할 때 클러스터를 다시 만듭니다.
VPC 범위의 경우 서비스의 보조 IP 주소 범위는 해당 서브네트워크의 다른 클러스터와 공유해서는 안 됩니다.
VPC 범위에서는 PTR 레코드와 연결된 응답 정책이 VPC 네트워크에 연결됩니다. 클러스터 네트워크에 결합된 다른 응답 정책이 있는 경우 Kubernetes 서비스 IP 주소에 대해 PTR 레코드 확인이 실패합니다.
포드 수가 허용된 할당량을 초과하는 헤드리스 서비스를 만들려고 하면 Cloud DNS에서 서비스의 레코드 세트 또는 레코드를 만들지 않습니다.
DNS 라벨의 최대 제한은 63자이지만 서비스 및 포트 이름은 62자로 제한됩니다. GKE가 DNS 레코드에 밑줄 접두사를 추가하기 때문입니다.
할당량
Cloud DNS는 할당량을 사용하여 GKE가 DNS 항목에 대해 만들 수 있는 리소스 수를 제한합니다. Cloud DNS의 할당량 및 한도는 프로젝트의 kube-dns 제한사항과 다를 수 있습니다.
GKE용 Cloud DNS를 사용할 때는 프로젝트의 각 관리형 영역에 다음 기본 할당량이 적용됩니다.
Kubernetes DNS 리소스 | 해당 Cloud DNS 리소스 | 할당량 |
---|---|---|
DNS 레코드 수 | 관리형 영역당 최대 바이트 | 2,000,000개(관리형 영역의 최대 50MB) |
헤드리스 서비스당 포드 수(IPv4/IPv6) | 리소스 레코드 세트당 레코드 수 | GKE 1.24~1.25: 1,000(IPv4/IPv6) GKE 1.26 이상: 3,500/2,000(IPv4/IPv6) |
프로젝트당 GKE 클러스터 수 | 프로젝트당 응답 정책 수 | 100 |
클러스터당 PTR 레코드 수 | 응답 정책당 규칙 수 | 100,000 |
리소스 한도
클러스터별로 만드는 Kubernetes 리소스는 다음 표에 설명된 대로 Cloud DNS 리소스 한도에 반영됩니다.
한도 | 한도에 반영 |
---|---|
관리형 영역당 리소스 레코드 세트 | 서비스 수 및 클러스터당 유효한 호스트 이름이 있는 헤드리스 서비스 엔드포인트 수 |
리소스 레코드 세트당 레코드 | 헤드리스 서비스당 엔드포인트 수. 다른 서비스 유형에는 영향을 미치지 않습니다. |
응답 정책당 규칙 수 | 클러스터 범위의 경우 서비스 수와 클러스터당 유효한 호스트 이름이 있는 헤드리스 서비스 엔드포인트 수의 합 VPC 범위의 경우 서비스 수와 VPC에 있는 모든 클러스터의 호스트 이름이 있는 헤드리스 엔드포인트 수의 합 |
Kubernetes에서 DNS 레코드가 생성되는 방법에 대한 자세한 내용은 Kubernetes DNS 기반 서비스 검색을 참조하세요.
시작하기 전에
시작하기 전에 다음 태스크를 수행했는지 확인합니다.
- Google Kubernetes Engine API를 사용 설정합니다. Google Kubernetes Engine API 사용 설정
- 이 태스크에 Google Cloud CLI를 사용하려면 gcloud CLI를 설치한 후 초기화합니다. 이전에 gcloud CLI를 설치한 경우
gcloud components update
명령어를 실행하여 최신 버전을 가져옵니다. 이전 gcloud CLI 버전에서는 이 문서의 명령어를 실행하지 못할 수 있습니다.
프로젝트에서 Cloud DNS API를 사용 설정합니다.
클러스터 범위 DNS 사용 설정
클러스터 범위 DNS에서는 GKE 클러스터에서 실행 중인 노드만 서비스 이름을 확인할 수 있으며 서비스 이름은 클러스터 간에 충돌하지 않습니다. 이 동작은 GKE 클러스터의 kube-dns와 동일합니다. 즉, 애플리케이션이 다운타임 또는 변경되지 않고 클러스터를 kube-dns에서 Cloud DNS 클러스터 범위로 마이그레이션할 수 있습니다.
다음 다이어그램에서는 Cloud DNS가 GKE 클러스터의 비공개 DNS 영역을 만드는 방법을 보여줍니다. DNS 범위에는 노드만 있으므로 클러스터의 노드에서 실행 중인 프로세스와 포드만 클러스터의 DNS 레코드를 확인할 수 있습니다.
새 클러스터에서 클러스터 범위 DNS 사용 설정
GKE Autopilot 클러스터
버전 1.25.9-gke.400, 1.26.4-gke.500 이상의 새 Autopilot 클러스터는 기본적으로 Cloud DNS 클러스터 범위로 설정됩니다.
GKE Standard 클러스터
gcloud CLI 또는 Google Cloud 콘솔을 사용하여 Cloud DNS 클러스터 범위가 사용 설정된 GKE Standard 클러스터를 만들 수 있습니다.
gcloud
--cluster-dns
플래그를 사용하여 클러스터를 만듭니다.
gcloud container clusters create CLUSTER_NAME \
--cluster-dns=clouddns \
--cluster-dns-scope=cluster \
--location=COMPUTE_LOCATION
다음을 바꿉니다.
CLUSTER_NAME
: 클러스터의 이름입니다.COMPUTE_LOCATION
: 클러스터의 Compute Engine 위치
cluster
가 기본값이기 때문에 --cluster-dns-scope=cluster
플래그는 명령어의 선택사항입니다.
콘솔
Google Cloud 콘솔에서 Kubernetes 클러스터 만들기 페이지로 이동합니다.
탐색창의 클러스터에서 네트워킹을 클릭합니다.
DNS 제공업체 섹션에서 Cloud DNS를 클릭합니다.
클러스터 범위를 선택합니다.
필요에 따라 클러스터를 구성합니다.
만들기를 클릭합니다.
기존 클러스터에서 클러스터 범위 DNS 사용 설정
GKE Autopilot 클러스터
기존 GKE Autopilot 클러스터를 kube-dns에서 Cloud DNS 클러스터 범위로 마이그레이션할 수 없습니다. Cloud DNS 클러스터 범위를 사용 설정하려면 버전 1.25.9-gke.400, 1.26.4-gke.500 이상에서 Autopilot 클러스터를 다시 만드세요.
GKE Standard 클러스터
GKE Standard 클러스터에서 gcloud CLI 또는Google Cloud 콘솔을 사용하여 기존 GKE Standard 클러스터를 kube-dns에서 Cloud DNS 클러스터 범위로 마이그레이션할 수 있습니다.
기존 클러스터를 마이그레이션하면 노드를 다시 만들 때까지 클러스터의 노드는 Cloud DNS를 DNS 제공업체로 사용하지 않습니다.
클러스터에 Cloud DNS를 사용 설정한 후에는 기존 노드 풀을 업그레이드하거나 새 노드 풀을 클러스터에 추가하는 경우에만 설정이 적용됩니다. 노드 풀을 업그레이드하면 노드가 다시 생성됩니다.
또한 각 노드 풀에서 개별적으로 Cloud DNS를 DNS 제공업체로 사용 설정하면 클러스터 통신을 중단하지 않고도 애플리케이션이 실행 중인 클러스터를 마이그레이션할 수 있습니다. 일부 노드 풀은 kube-dns를 사용하고 일부 노드 풀은 Cloud DNS를 사용하므로 노드 하위 집합이 항상 작동합니다.
다음 단계에서는 클러스터에 Cloud DNS를 사용 설정한 후 노드 풀을 업그레이드합니다. 노드 풀을 업그레이드하면 노드가 다시 생성됩니다. 그러면 노드가 DNS를 확인하는 데 kube-dns 대신 Cloud DNS를 사용합니다.
gcloud
기존 클러스터를 업데이트합니다.
gcloud container clusters update CLUSTER_NAME \ --cluster-dns=clouddns \ --cluster-dns-scope=cluster \ --location=COMPUTE_LOCATION
다음을 바꿉니다.
CLUSTER_NAME
: 클러스터의 이름COMPUTE_LOCATION
: 클러스터의 Compute Engine 위치
cluster
가 기본값이기 때문에--cluster-dns-scope=cluster
플래그는 명령어의 선택사항입니다.응답은 다음 예시와 유사합니다.
All the node-pools in the cluster need to be re-created by the user to start using Cloud DNS for DNS lookups. It is highly recommended to complete this step shortly after enabling Cloud DNS. Do you want to continue (Y/n)?
확인한 후에는 Cloud DNS 컨트롤러가 GKE 제어 영역에서 실행되지만, 노드 풀을 업그레이드하거나 새 노드 풀을 클러스터에 추가할 때까지 포드는 DNS 변환을 위해 Cloud DNS를 사용하지 않습니다.
Cloud DNS를 사용하도록 클러스터의 노드 풀을 업그레이드하세요.
gcloud container clusters upgrade CLUSTER_NAME \ --node-pool=POOL_NAME \ --location=COMPUTE_LOCATION
다음을 바꿉니다.
CLUSTER_NAME
: 클러스터의 이름POOL_NAME
: 업그레이드할 노드 풀의 이름
노드 풀과 제어 영역이 동일한 버전을 실행 중인 경우 먼저 제어 영역 수동 업그레이드에 설명된 대로 제어 영역을 업그레이드한 후 노드 풀 업그레이드를 수행합니다.
응답을 확인하고 클러스터의 각 노드 풀에 이 명령어를 반복하세요. 클러스터에 노드 풀이 한 개이면
--node-pool
플래그를 생략하세요.
콘솔
Google Cloud 콘솔에서 Google Kubernetes Engine 페이지로 이동합니다.
수정할 클러스터의 이름을 클릭합니다.
네트워킹의 DNS 제공업체 필드에서 edit DNS 제공업체 수정을 클릭합니다.
Cloud DNS를 클릭합니다.
클러스터 범위를 클릭합니다.
변경사항 저장을 클릭합니다.
Cloud DNS 추가 VPC 범위 사용 설정
이 섹션에서는 Cloud DNS 클러스터 범위 부가기능으로 Cloud DNS 추가 VPC 범위를 사용 설정하거나 사용 중지하는 단계를 설명합니다.
새 클러스터에서 Cloud DNS 추가 VPC 범위 사용 설정
gcloud CLI 또는 Google Cloud 콘솔을 사용하여 새 GKE 클러스터에서 VPC 범위 DNS를 사용 설정할 수 있습니다.
Autopilot의 경우
gcloud container clusters create-auto CLUSTER_NAME \
--additive-vpc-scope-dns-domain=UNIQUE_CLUSTER_DOMAIN
다음을 바꿉니다.
CLUSTER_NAME
: 클러스터의 이름입니다.UNIQUE_CLUSTER_DOMAIN
: 도메인 이름. GKE에서 이 값을 확인하지 않으므로 이 이름은 VPC 내에서 고유해야 합니다. 이 값을 설정한 후에는 변경할 수 없습니다. '.local'로 끝나는 도메인을 사용하면 안 됩니다. 사용하면 DNS 변환 오류가 발생할 수 있습니다.
Standard의 경우
gcloud container clusters create CLUSTER_NAME \
--cluster-dns=clouddns \
--cluster-dns-scope=cluster \
--additive-vpc-scope-dns-domain=UNIQUE_CLUSTER_DOMAIN
cluster
가 기본값이기 때문에 --cluster-dns-scope=cluster
플래그는 선택사항입니다.
다음을 바꿉니다.
CLUSTER_NAME
: 클러스터의 이름입니다.UNIQUE_CLUSTER_DOMAIN
: 도메인 이름. GKE에서 이 값을 확인하지 않으므로 이 이름은 VPC 내에서 고유해야 합니다. 이 값을 설정한 후에는 변경할 수 없습니다. '.local'로 끝나는 도메인을 사용하면 안 됩니다. 사용하면 DNS 변환 오류가 발생할 수 있습니다.
기존 클러스터에서 Cloud DNS 추가 VPC 범위 사용 설정
기존 클러스터에서 Cloud DNS 추가 VPC 범위를 사용 설정하려면 먼저 클러스터에 대해 Cloud DNS를 사용 설정한 후 노드 풀을 업그레이드합니다. 노드 풀을 업그레이드하면 노드가 다시 생성됩니다. 그러면 노드가 DNS를 확인하는 데 kube-dns 대신 Cloud DNS를 사용합니다.
기존 클러스터에서 Cloud DNS 추가 VPC 범위를 사용 설정하려면 다음 안내를 따르세요.
gcloud container clusters update CLUSTER_NAME \
--additive-vpc-scope-dns-domain=UNIQUE_CLUSTER_DOMAIN \
--location=COMPUTE_LOCATION
다음을 바꿉니다.
CLUSTER_NAME
: 클러스터의 이름입니다.UNIQUE_CLUSTER_DOMAIN
: 도메인 이름. GKE에서 이 값을 확인하지 않으므로 이 이름은 VPC 내에서 고유해야 합니다. 이 값을 설정한 후에는 변경할 수 없습니다. '.local'로 끝나는 도메인을 사용하면 안 됩니다. 사용하면 DNS 변환 오류가 발생할 수 있습니다.COMPUTE_LOCATION
: 클러스터의 Compute Engine 위치
VPC 범위 DNS 사용 설정
VPC 범위 DNS에서 클러스터의 DNS 이름은 전체 VPC 내에서 변환 가능합니다. VPC의 모든 클라이언트는 클러스터 DNS 레코드를 변환할 수 있습니다.
VPC 범위 DNS는 다음 사용 사례를 사용 설정합니다.
- 동일한 VPC 내의 비GKE 클라이언트에 대한 헤드리스 서비스 검색
- 온프레미스 또는 서드 파티 클라우드 클라이언트의 GKE 서비스 변환 자세한 내용은 인바운드 서버 정책을 참고하세요.
- 클라이언트가 커스텀 클러스터 DNS 도메인을 사용하여 통신할 클러스터를 결정할 수 있는 서비스 변환
다음 다이어그램에서 두 GKE 클러스터는 동일한 VPC에서 VPC 범위 DNS를 사용합니다. 두 클러스터에는 기본 .cluster.local
도메인 대신 커스텀 DNS 도메인 .cluster1
및 .cluster2
가 있습니다. VM은 backend.default.svc.cluster1
을 변환하여 헤드리스 백엔드 서비스와 통신합니다. Cloud DNS는 서비스의 개별 포드 IP로 헤드리스 서비스를 변환하고 VM이 포드 IP 주소와 직접 통신합니다.
Cloud Interconnect 또는 Cloud VPN을 통해 VPC에 연결되면 다른 네트워크에서 이러한 유형의 변환을 수행할 수도 있습니다. DNS 서버 정책을 사용하면 VPC에 연결된 네트워크의 클라이언트가 Cloud DNS의 이름을 변환할 수 있습니다. 여기에는 클러스터에 VPC 범위 DNS가 사용되는 경우 GKE 서비스가 포함됩니다.
기존 클러스터에서 VPC 범위 DNS 사용 설정
마이그레이션은 GKE Standard에서만 지원되며 GKE Autopilot에서는 지원되지 않습니다.
GKE Autopilot 클러스터
GKE Autopilot 클러스터를 kube-dns에서 Cloud DNS VPC 범위로 마이그레이션할 수 없습니다.
GKE Standard 클러스터
gcloud CLI 또는 Google Cloud 콘솔을 사용하여 기존 GKE 클러스터를 kube-dns에서 Cloud DNS VPC 범위로 마이그레이션할 수 있습니다.
클러스터에 Cloud DNS를 사용 설정한 후에는 기존 노드 풀을 업그레이드하거나 새 노드 풀을 클러스터에 추가하는 경우에만 설정이 적용됩니다. 노드 풀을 업그레이드하면 노드가 다시 생성됩니다.
다음 단계에서는 클러스터에 Cloud DNS를 사용 설정한 후 노드 풀을 업그레이드합니다. 노드 풀을 업그레이드하면 노드가 다시 생성됩니다. 그러면 노드가 DNS를 확인하는 데 kube-dns 대신 Cloud DNS를 사용합니다.
gcloud
기존 클러스터를 업데이트합니다.
gcloud container clusters update CLUSTER_NAME \ --cluster-dns=clouddns \ --cluster-dns-scope=vpc \ --cluster-dns-domain=CUSTOM_DOMAIN \ --location=COMPUTE_LOCATION
다음을 바꿉니다.
CLUSTER_NAME
: 클러스터의 이름입니다.COMPUTE_LOCATION
: 클러스터의 Compute Engine 위치CUSTOM_DOMAIN
: 도메인 이름. GKE에서 이 값을 확인하지 않으므로 이 이름은 VPC 내에서 고유해야 합니다. 이 값을 설정한 후에는 변경할 수 없습니다. '.local'로 끝나는 도메인을 사용하면 안 됩니다. 사용하면 DNS 변환 오류가 발생할 수 있습니다.
응답은 다음 예시와 유사합니다.
All the node-pools in the cluster need to be re-created by the user to start using Cloud DNS for DNS lookups. It is highly recommended to complete this step shortly after enabling Cloud DNS. Do you want to continue (Y/n)?
확인한 후에는 Cloud DNS 컨트롤러가 GKE 제어 영역에서 실행됩니다. 노드 풀을 업그레이드하거나 새 노드 풀을 클러스터에 추가할 때까지 포드는 DNS 변환을 위해 Cloud DNS를 사용하지 않습니다.
Cloud DNS를 사용하도록 클러스터의 노드 풀을 업그레이드하세요.
gcloud container clusters upgrade CLUSTER_NAME \ --node-pool=POOL_NAME
다음을 바꿉니다.
CLUSTER_NAME
: 클러스터의 이름POOL_NAME
: 업그레이드할 노드 풀의 이름
노드 풀과 제어 영역이 동일한 버전을 실행 중인 경우 먼저 제어 영역 수동 업그레이드에 설명된 대로 제어 영역을 업그레이드한 후 노드 풀 업그레이드를 수행합니다.
응답을 확인하고 클러스터의 각 노드 풀에 이 명령어를 반복하세요. 클러스터에 노드 풀이 한 개이면
--node-pool
플래그를 생략하세요.
콘솔
Google Cloud 콘솔에서 Google Kubernetes Engine 페이지로 이동합니다.
수정할 클러스터의 이름을 클릭합니다.
네트워킹의 DNS 제공업체 필드에서 edit DNS 제공업체 수정을 클릭합니다.
Cloud DNS를 클릭합니다.
VPC 범위를 클릭합니다.
변경사항 저장을 클릭합니다.
Cloud DNS 확인
GKE용 Cloud DNS가 클러스터에 대해 올바르게 작동하는지 확인하세요.
노드에서 포드에 연결하고
cat /etc/resolv.conf
명령어를 실행하여 노드가 Cloud DNS를 사용하고 있는지 확인합니다.kubectl exec -it POD_NAME -- cat /etc/resolv.conf | grep nameserver
POD_NAME
을 포드의 이름으로 바꿉니다.클러스터 모드에 따라 출력은 다음과 비슷합니다.
GKE Autopilot 클러스터
nameserver 169.254.20.10
GKE Autopilot에서는 NodeLocal DNSCache가 기본적으로 사용 설정되어 있으므로 포드에서 NodeLocal DNSCache를 사용합니다.
로컬 캐시에 조회 중인 이름의 항목이 없는 경우에만 NodeLocal DNSCache가 요청을 Cloud DNS로 전달합니다.
GKE Standard 클러스터
nameserver 169.254.169.254
포드는
169.254.169.254
을nameserver
로 사용하는데, 이는 Cloud DNS 데이터 영역이 포트 53에서 요청을 리슨하는 메타데이터 서버의 IP 주소입니다. 노드가 DNS 변환에 더 이상 kube-dns 서비스 주소를 사용하지 않으며 모든 DNS 변환이 로컬 노드에서 수행됩니다.출력이
10.x.y.10
과 유사한 IP 주소이면 포드가 kube-dns를 사용하고 있는 것입니다. 포드가 계속 kube-dns를 사용하는 이유는 문제 해결 섹션을 참조하세요.출력이
169.254.20.10
이면 클러스터에 NodeLocal DNSCache가 사용 설정되었으면 포드가 NodeLocal DNSCache를 사용하고 있다는 의미입니다.클러스터에 샘플 애플리케이션을 배포합니다.
kubectl run dns-test --image us-docker.pkg.dev/google-samples/containers/gke/hello-app:2.0
샘플 애플리케이션을 서비스와 함께 노출합니다.
kubectl expose pod dns-test --name dns-test-svc --port 8080
서비스가 성공적으로 배포되었는지 확인합니다.
kubectl get svc dns-test-svc
출력은 다음과 비슷합니다.
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE dns-test-svc ClusterIP 10.47.255.11 <none> 8080/TCP 6m10s
CLUSTER-IP
값은 클러스터의 가상 IP 주소입니다. 이 예시에서 가상 IP 주소는10.47.255.11
입니다.서비스 이름이 클러스터의 비공개 DNS 영역에 레코드로 생성되었는지 확인합니다.
gcloud dns record-sets list \ --zone=PRIVATE_DNS_ZONE \ --name=dns-test-svc.default.svc.cluster.local.
PRIVATE_DNS_ZONE
을 관리형 DNS 영역의 이름으로 바꿉니다.출력은 다음과 비슷합니다.
NAME: dns-test-svc.default.svc.cluster.local. TYPE: A TTL: 30 DATA: 10.47.255.11
GKE용 Cloud DNS 사용 중지
GKE Autopilot 클러스터
Cloud DNS가 기본적으로 사용 설정된 GKE Autopilot 클러스터에서는 Cloud DNS를 사용 중지할 수 없습니다. 기본적으로 Cloud DNS를 사용하는 GKE Autopilot 클러스터에 관한 자세한 내용은 요구사항을 참고하세요.
GKE Standard 클러스터
GKE Standard 클러스터에서 gcloud CLI 또는 Google Cloud 콘솔을 사용하여 Cloud DNS 클러스터 범위를 사용 중지할 수 있습니다.
gcloud
kube-dns를 사용하도록 클러스터를 업데이트합니다.
gcloud container clusters update CLUSTER_NAME \
--cluster-dns=default
콘솔
Google Cloud 콘솔에서 Google Kubernetes Engine 페이지로 이동합니다.
수정할 클러스터의 이름을 클릭합니다.
네트워킹의 DNS 제공업체 필드에서 edit DNS 제공업체 수정을 클릭합니다.
Kube-dns를 클릭합니다.
변경사항 저장을 클릭합니다.
Standard 클러스터의 Cloud DNS를 사용 중지한 후 클러스터와 연결된 노드 풀을 업데이트합니다. 또는 새 노드 풀을 만들고 워크로드를 예약할 수 있습니다. 노드 풀을 업데이트하지 않으면 DNS 네임스페이스가 kube-dns가 아닌 Cloud DNS를 계속 가리킵니다.
Cloud DNS 추가 VPC 범위 사용 중지
클러스터에 대해 Cloud DNS 추가 VPC 범위를 사용 중지하면 VPC 네트워크에 연결된 비공개 영역의 DNS 레코드만 삭제됩니다. GKE 클러스터의 비공개 DNS 영역에 있는 레코드는 클러스터에서 헤드리스 서비스가 삭제될 때까지 GKE용 Cloud DNS에서 관리됩니다.
Cloud DNS 추가 VPC 범위를 사용 중지하려면 다음 명령어를 실행합니다.
gcloud container clusters update CLUSTER_NAME \
--disable-additive-vpc-scope
CLUSTER_NAME
을 클러스터 이름으로 바꿉니다.
이렇게 하면 클러스터 내에서 DNS 변환을 제공하도록 Cloud DNS 클러스터 범위가 사용 설정된 클러스터를 유지할 수 있습니다.
삭제
이 페이지의 연습을 완료한 후에는 다음 단계에 따라 자신의 계정에 원치 않는 비용이 발생하지 않도록 리소스를 삭제합니다.
서비스를 삭제합니다.
kubectl delete service dns-test-svc
포드를 삭제합니다.
kubectl delete Pod dns-test
또한 클러스터를 삭제할 수도 있습니다.
공유 VPC에서 Cloud DNS 사용
GKE용 Cloud DNS는 VPC와 클러스터 범위 모두 공유 VPC를 지원합니다.
GKE 컨트롤러는 GKE 클러스터와 동일한 프로젝트에 관리형 비공개 영역을 만듭니다.
관리형 영역과 GKE 클러스터가 동일한 프로젝트에 있으므로 GKE 클러스터의 GKE 서비스 계정에는 자체 프로젝트 외부의 DNS에 Identity and Access Management(IAM)가 필요하지 않습니다.
서비스 프로젝트당 두 개 이상의 클러스터
GKE 버전 1.22.3-gke.700, 1.21.6-gke.1500부터는 동일한 호스트 프로젝트에서 VPC를 참조하는 여러 서비스 프로젝트에 클러스터를 만들 수 있습니다.
공유 VPC 및 Cloud DNS VPC 범위를 사용하는 클러스터가 이미 있는 경우 다음 단계에 따라 수동으로 마이그레이션해야 합니다.
- 공유 VPC가 GKE 버전 1.22.3-gke.700+ 또는 1.21.6-gke.1500+로 사용 설정된 기존 클러스터를 업그레이드합니다.
- 서비스 프로젝트에서 호스트 프로젝트로 응답 정책을 마이그레이션합니다. 이 마이그레이션은 공유 VPC 네트워크당 한 번만 수행하면 됩니다.
Google Cloud 콘솔을 사용하여 응답 정책을 마이그레이션할 수 있습니다.
서비스 프로젝트에서 다음 단계를 수행합니다.
Cloud DNS 영역 페이지로 이동합니다.
응답 정책 영역 탭을 클릭합니다.
VPC 네트워크의 응답 정책을 클릭합니다. 응답 정책은 'NETWORK_NAME 네트워크의 GKE 클러스터에 대한 응답 정책'과 비슷한 설명으로 식별할 수 있습니다.
다음에서 사용 중 탭을 클릭합니다.
호스트 프로젝트 이름 옆에 있는 delete를 클릭하여 네트워크 바인딩을 삭제합니다.
응답 정책 규칙 탭을 클릭합니다.
테이블의 모든 항목을 선택합니다.
응답 정책 규칙 삭제를 클릭합니다.
delete 응답 정책 삭제를 클릭합니다.
응답 정책을 삭제하면 DNS 컨트롤러가 호스트 프로젝트에 자동으로 응답 정책을 만듭니다. 다른 서비스 프로젝트의 클러스터가 이 응답 정책을 공유합니다.
커스텀 스텁 도메인 및 업스트림 네임서버 지원
GKE용 Cloud DNS는 kube-dns ConfigMap을 통해 구성된 커스텀 스텁 도메인과 업스트림 네임서버를 지원합니다. 이 지원은 GKE Standard 클러스터에만 제공됩니다.
Cloud DNS는 stubDomains
및 upstreamNameservers
값을 Cloud DNS 전달 영역으로 변환합니다.
사양 확장 프로그램
다양한 클라이언트 및 시스템과의 서비스 검색 및 호환성을 개선하기 위해 일반적인 Kubernetes DNS 사양 위에 추가 사항이 있습니다.
이름이 지정된 포트
이 섹션에서는 명명된 포트가 Kubernetes 클러스터에 대해 Cloud DNS에서 생성한 DNS 레코드에 미치는 영향을 설명합니다.
Kubernetes는 필수 DNS 레코드의 최소 집합을 정의하는 반면 Cloud DNS는 자체 작업을 위해 그리고 다양한 Kubernetes 기능을 지원하기 위해 추가 레코드를 만들 수 있습니다.
다음 표에서는 예상되는 최소 레코드 세트 수를 보여줍니다. 여기서 'E
'는 엔드포인트 수를 나타내고 'P
'는 포트 수를 나타냅니다.
Cloud DNS에서 추가 레코드를 만들 수 있습니다.
IP 스택 유형 | 서비스 유형 | 레코드 모음 |
---|---|---|
싱글 스택 | ClusterIP | $$2+P$$ |
Headless | $$2+P+2E$$ |
|
이중 스택 | ClusterIP | $$3+P$$ |
Headless | $$3+P+3E$$ |
|
단일 및 이중 스택 서비스에 관한 자세한 내용은 단일 및 이중 스택 서비스를 참고하세요. |
Cloud DNS에서 생성된 추가 DNS 레코드
Cloud DNS는 최소 레코드 세트 수 외에 추가 DNS 레코드를 만들 수 있습니다. 이러한 레코드는 다음과 같은 다양한 용도로 사용됩니다. SRV 레코드: 서비스 검색을 위해 Cloud DNS는 SRV 레코드를 자주 만듭니다. 이러한 레코드는 서비스의 포트 및 프로토콜에 관한 정보를 제공합니다. AAAA 레코드 (이중 스택용): 이중 스택 구성 (IPv4 및 IPv6)에서 Cloud DNS는 각 엔드포인트에 대해 A 레코드 (IPv4용)와 AAAA 레코드 (IPv6용)를 모두 만듭니다. 내부 레코드: Cloud DNS는 자체 관리 및 최적화를 위해 내부 레코드를 만들 수 있습니다. 이러한 기록은 일반적으로 사용자와 직접적인 관련이 없습니다. LoadBalancer 서비스: LoadBalancer 유형의 서비스의 경우 Cloud DNS는 외부 부하 분산기 IP 주소와 연결된 레코드를 만듭니다. 헤드리스 서비스: 헤드리스 서비스에는 고유한 DNS 구성이 있습니다. 각 포드는 자체 DNS 레코드를 가져 클라이언트가 포드에 직접 연결할 수 있습니다. 따라서 헤드리스 서비스 레코드 계산에서 포트 번호가 곱해지지 않습니다.
예:
backend
네임스페이스에 my-http-server
이라는 서비스가 있다고 가정해 보겠습니다. 이 서비스는 포드가 3개인 배포에 대해 포트 80과 8080을 노출합니다. 따라서 E = 3, P = 2입니다.
IP 스택 유형 | 서비스 유형 | 레코드 모음 |
---|---|---|
싱글 스택 | ClusterIP | $$2+2$$ |
Headless | $$2+2+2*3$$ |
|
이중 스택 | ClusterIP | $$3+2$$ |
Headless | $$3+2+3*3$$ |
이러한 최소 레코드 외에도 Cloud DNS는 SRV 레코드를 만들 수 있으며, 이중 스택의 경우 AAAA 레코드를 만들 수 있습니다. my-http-server
이 LoadBalancer 유형 서비스인 경우 부하 분산기 IP의 추가 레코드가 생성됩니다.
참고: Cloud DNS는 필요에 따라 보조 DNS 레코드를 추가합니다. 생성되는 구체적인 레코드는 서비스 유형 및 구성과 같은 요인에 따라 다릅니다.
알려진 문제
Terraform에서는 dns_config
변경으로 인해 Autopilot 클러스터를 다시 만들 계획입니다.
terraform-provider-google
또는 terraform-provider-google-beta
을 사용하는 경우 Terraform에서 Autopilot 클러스터를 다시 만들려고 하는 문제가 발생할 수 있습니다. 이 오류는 버전 1.25.9-gke.400, 1.26.4-gke.500, 1.27.1-gke.400 이상을 실행하는 새로 생성된 Autopilot 클러스터가 kube-dns 대신 DNS 제공업체로 Cloud DNS를 사용하기 때문에 발생합니다.
이 문제는 Terraform 제공업체 Google Cloud버전 4.80.0에서 해결되었습니다.
terraform-provider-google
또는 terraform-provider-google-beta
버전을 업데이트할 수 없는 경우 리소스에 lifecycle.ignore_changes
를 추가하여 google_container_cluster
가 dns_config
에 대한 변경사항을 무시하도록 할 수 있습니다.
lifecycle {
ignore_changes = [
dns_config,
]
}
NodeLocal DNSCache가 사용 설정된 상태에서 kube-dns에서 Cloud DNS로 마이그레이션한 후 DNS 확인 실패
이 섹션에서는 클러스터 범위의 NodeLocal DNSCache가 있는 Cloud DNS의 GKE 클러스터에 있는 알려진 문제를 설명합니다.
클러스터에서 NodeLocal DNSCache를 사용 설정한 상태로 kube-DNS에서 Cloud DNS로 마이그레이션한 후 클러스터에 간헐적인 변환 오류가 발생할 수 있습니다.
클러스터에서 NodeLocal DNSCache가 사용 설정된 상태로 kube-dns를 사용하는 동안 NodeLocal DNSCache는 두 주소 (NodeLocal DNSCache 주소 및 kube-dns 주소)를 모두 수신하도록 구성됩니다.
NodeLocal DNSCache의 상태를 확인하려면 다음 명령어를 실행하세요.
kubectl get cm -n kube-system node-local-dns -o json | jq .data.Corefile -r | grep bind
출력은 다음과 비슷합니다.
bind 169.254.20.10 x.x.x.10
bind 169.254.20.10 x.x.x.10
kube-dns를 사용하는 동안 클러스터에서 Dataplane V2를 사용 설정하면 NodeLocal DNSCache가 격리된 네트워크에서 실행되고 모든 Pod IP 주소 (0.0.0.0)에서 리슨하도록 구성됩니다. 출력은 다음과 비슷합니다.
bind 0.0.0.0
bind 0.0.0.0
클러스터를 Cloud DNS로 업데이트한 후 NodeLocal DNSCache 구성이 변경되면 NodeLocal DNSCache를 확인합니다.
kubectl get cm -n kube-system node-local-dns -o json | jq .data.Corefile -r | grep bind
출력은 다음과 비슷합니다.
bind 169.254.20.10
bind 169.254.20.10
다음 워크플로에서는 마이그레이션 및 노드 재생성 중에 resolv.conf 파일의 항목을 설명합니다.
마이그레이션 전
- 포드의 resolv.conf가 kube-dns-IP (예: x.x.x.10)로 구성되어 있습니다.
- 노드 로컬 캐시 포드는 포드의 DNS 요청을 인터섹션하고 다음에서 리슨합니다.
- (DPv1) 두 주소 모두 (바인드 169.254.20.10 x.x.x.10)
- (DPv2) 모든 포드 IP 주소 (0.0.0.0 바인딩)
- NodeLocal DNSCache는 캐시로 작동하며 kube-dns 포드에 가해지는 스트레스가 적습니다.
이전 후
- 제어 영역이 Cloud DNS를 사용하도록 업데이트된 후에도 포드에는 kube-dns-IP (예: x.x.x.10)가 구성된 resolv.conf가 있습니다. 이 구성은 GKE에서 169.254.20.10을 사용하려면 노드를 다시 만들어야 하기 때문에 유지됩니다. Cloud DNS 설정에는
169.254.20.10
이 필요합니다. - 노드 로컬 캐시 포드는 NodeLocal DNSCache 주소에서만 리슨합니다 (169.254.20.10 바인딩). 요청이 노드 로컬 캐시 포드로 이동하지 않습니다.
- 포드의 모든 요청은 kube-dns 포드로 직접 전송됩니다. 이 설정은 포드에서 높은 트래픽을 생성합니다.
노드 재생성 또는 노드 풀 업그레이드 후
- 포드에는 NodeLocal DNSCache IP 주소 (169.254.20.10)로 구성된
resolv.conf
가 있습니다. - 노드 로컬 캐시 포드는 NodeLocal DNSCache 주소에서만 리슨하고 (169.254.20.10 바인딩) 이 IP 주소의 포드에서 DNS 요청을 수신합니다.
노드 풀을 다시 만들기 전에 노드 풀이 resolv.conf에서 kube-dns IP를 사용하는 경우 DNS 쿼리 트래픽이 증가하면 kube-dns 포드의 트래픽도 증가하여 DNS 요청이 간헐적으로 실패합니다. 오류를 최소화하려면 다운타임 기간에 이 마이그레이션을 계획해야 합니다.
문제 해결
Cloud DNS 문제 해결에 대한 자세한 내용은 다음 페이지를 참고하세요.
- GKE의 Cloud DNS에 관한 도움말은 GKE에서 Cloud DNS 문제 해결을 참고하세요.
- Cloud DNS에 관한 구체적인 조언은 Cloud DNS 문제 해결을 참고하세요.
- Kubernetes DNS 문제 진단에 대한 일반적인 도움말은 DNS 변환 디버깅을 참고하세요.
다음 단계
- GKE가 관리형 DNS를 제공하는 방법에 대한 개요 읽기
- 서비스 및 포드의 DNS를 참조하여 Kubernetes 클러스터에서 DNS가 사용되는 방식에 대한 일반적인 개요 알아보기
- Cloud DNS의 범위 및 계층 구조 알아보기
- 비공개 관리 영역의 로깅 사용 설정 및 사용 중지 알아보기