GKE에서 kube-dns 문제 해결

이 페이지에서는 Google Kubernetes Engine(GKE)에서 kube-dns 관련 문제를 해결하는 방법을 설명합니다.

kube-dns에서 DNS 문제 원인 식별

dial tcp: i/o timeout, no such host 또는 Could not resolve host와 같은 오류는 kube-dns의 쿼리 확인 기능에 문제가 있음을 나타내는 경우가 많습니다.

이러한 오류 중 하나가 확인되었지만 원인을 모르는 경우 다음 섹션을 참고하여 원인을 찾으세요. 다음 섹션은 가장 도움이 될 수 있는 단계부터 시작되도록 정렬되어 있으므로 각 섹션을 순서대로 시도해 보세요.

kube-dns 포드가 실행 중인지 확인

kube-dns 포드는 클러스터 내에서 이름을 확인하는 데 중요합니다. 실행되지 않으면 DNS 확인에서 문제가 발생한 가능성이 있습니다.

kube-dns 포드가 최근에 다시 시작되지 않고 실행 중인지 확인하려면 다음 포드 상태를 봅니다.

kubectl get pods -l k8s-app=kube-dns -n kube-system

출력은 다음과 비슷합니다.

NAME                   READY          STATUS          RESTARTS       AGE
kube-dns-POD_ID_1      5/5            Running         0              16d
kube-dns-POD_ID_2      0/5            Terminating     0              16d

이 출력에서 POD_ID_1 및 POD_ID_2는 kube-dns 포드에 자동으로 추가되는 고유 식별자를 나타냅니다.

출력에 kube-dns 포드 중 상태가 Running이 아닌 포드가 표시되면 다음 단계를 수행합니다.

1. 관리자 활동 감사 로그를 사용하여 클러스터 또는 노드 풀 버전 업그레이드 또는 kube-dns ConfigMap 변경과 같은 최근 변경사항이 있는지 조사합니다. 감사 로그에 대한 자세한 내용은 GKE 감사 로깅 정보를 참조하세요. 변경사항이 있는 경우 되돌리고 포드 상태를 다시 봅니다.

2. 관련된 최근 변경사항이 없으면 kube-dns 포드가 실행되는 노드에서 OOM 오류가 발생하는지 조사합니다. Cloud Logging 로그 메시지에 다음과 유사한 오류가 표시되면 이러한 포드에서 OOM 오류가 발생한 것입니다.

   Warning: OOMKilling Memory cgroup out of memory
   

   이 메시지는 과도한 리소스 사용으로 인해 Kubernetes에서 프로세스를 종료했음을 나타냅니다. Kubernetes는 리소스 요청을 기반으로 포드를 예약하지만 포드가 리소스 한도까지 소비할 수 있게 합니다. 한도가 요청보다 높거나 한도가 없으면 포드 리소스 사용량이 시스템 리소스를 초과할 수 있습니다.

   이 오류를 해결하려면 문제가 있는 워크로드를 삭제하거나 메모리나 CPU 한도를 설정하면 됩니다. 한도 설정에 대한 자세한 내용은 Kubernetes 문서의 포드와 컨테이너의 리소스 관리를 참조하세요. OOM 이벤트에 대한 자세한 내용은 OOM 이벤트 문제 해결을 참조하세요.

3. OOM 오류 메시지가 표시되지 않으면 kube-dns 배포를 다시 시작합니다.

   kubectl rollout restart deployment/kube-dns --namespace=kube-system
   

   배포를 다시 시작한 후 kube-dns Pod가 실행 중인지 확인합니다.

이 단계를 수행해도 문제가 해결되지 않거나 모든 kube-dns 포드의 상태가 Running이지만 여전히 DNS 문제가 발생하는 경우 /etc/resolv.conf 파일이 올바르게 구성되어 있는지 확인합니다.

/etc/resolv.conf가 올바르게 구성되어 있는지 확인

DNS 문제가 발생한 포드의 /etc/resolv.conf 파일을 검토하고 포함된 항목이 올바른지 확인합니다.

1. 포드의 /etc/resolv.conf 파일을 봅니다.

   kubectl exec -it POD_NAME -- cat /etc/resolv.conf
   

   POD_NAME을 DNS 문제가 발생한 포드의 이름으로 바꿉니다. 문제가 발생한 포드가 여러 개인 경우 포드마다 이 섹션의 단계를 반복합니다.

   포드 바이너리에서 kubectl exec 명령어를 지원하지 않으면 이 명령어가 실패할 수 있습니다. 이 경우 테스트 환경으로 사용할 간단한 포드를 만듭니다. 이 절차를 통해 문제가 있는 포드와 동일한 네임스페이스에서 테스트 포드를 실행할 수 있습니다.

2. /etc/resolv.conf 파일의 네임서버 IP 주소가 올바른지 확인합니다.

   • 호스트 네트워크를 사용하는 포드는 노드 /etc/resolv.conf 파일의 값을 사용해야 합니다. 네임서버 IP 주소는 169.254.169.254여야 합니다.

   • 호스트 네트워크를 사용하지 않는 포드의 경우 kube-dns 서비스 IP 주소는 네임서버 IP 주소와 동일해야 합니다. IP 주소를 비교하려면 다음 단계를 완료합니다.

     1. kube-dns 서비스 IP 주소를 가져옵니다.

        kubectl get svc kube-dns -n kube-system
        

        출력은 다음과 비슷합니다.

        NAME       TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)         AGE
        kube-dns   ClusterIP   192.0.2.10   <none>        53/UDP,53/TCP   64d
        

     2. 클러스터 IP 열의 값을 기록해 둡니다. 이 예시에서는 192.0.2.10입니다.

     3. kube-dns 서비스 IP 주소를 /etc/resolv.conf 파일의 IP 주소와 비교합니다.

        # cat /etc/resolv.conf
        
        search default.svc.cluster.local svc.cluster.local cluster.local c.PROJECT_NAME google.internal
        nameserver 192.0.2.10
        options ndots:5
        

        이 예시에서는 두 값이 일치하므로 잘못된 네임서버 IP 주소가 문제의 원인이 아닙니다.

        그러나 IP 주소가 일치하지 않으면 애플리케이션 포드 매니페스트에 dnsConfig 필드가 구성되어 있는 것입니다.

        dnsConfig.nameservers 필드 값이 올바르면 DNS 서버를 조사하여 올바르게 작동하는지 확인합니다.

        커스텀 네임서버를 사용하지 않으려면 필드를 삭제하고 포드 롤링을 다시 시작합니다.

        kubectl rollout restart deployment POD_NAME
        

        POD_NAME을 포드 이름으로 바꿉니다.

3. /etc/resolv.conf에서 search 및 ndots 항목을 확인합니다. 맞춤법 오류와 비활성 구성이 없고 실패한 요청이 올바른 네임스페이스의 기존 서비스를 가리키는지 확인합니다.

DNS 조회 수행

/etc/resolv.conf가 올바르게 구성되고 DNS 레코드가 올바른지 확인한 후 dig 명령줄 도구를 사용하여 DNS 오류를 보고하는 포드에서 DNS 조회를 수행합니다.

1. 포드 내에서 셸을 열어 포드를 직접 쿼리합니다.

   kubectl exec -it POD_NAME -n NAMESPACE_NAME -- SHELL_NAME
   

   다음을 바꿉니다.

   • POD_NAME: DNS 오류를 보고하는 포드의 이름입니다.
   • NAMESPACE_NAME: 포드가 속한 네임스페이스입니다.
   • SHELL_NAME: 열려고 하는 셸의 이름입니다. 예를 들면 sh 또는 /bin/bash입니다.

   포드에서 kubectl exec 명령어를 허용하지 않거나 포드에 dig 바이너리가 없으면 이 명령어가 실패할 수 있습니다. 이 경우 dig가 설치된 이미지로 테스트 포드를 만듭니다.

   kubectl run "test-$RANDOM" ti --restart=Never --image=thockin/dnsutils - bash
   

2. 포드가 클러스터의 내부 DNS 서비스를 올바르게 확인할 수 있는지 확인합니다.

   dig kubernetes
   

   /etc/resolv.conf 파일이 kube-dns 서비스 IP 주소를 가리키므로 이 명령어를 실행하면 DNS 서버가 kube-dns 서비스가 됩니다.

   Kubernetes API 서비스의 IP 주소(일반적으로 10.96.0.1)가 포함된 성공적인 DNS 응답이 표시됩니다. SERVFAIL이 표시되거나 응답이 없으면 일반적으로 kube-dns 포드에서 내부 서비스 이름을 확인할 수 없음을 나타냅니다.

3. kube-dns 서비스에서 외부 도메인 이름을 확인할 수 있는지 확인합니다.

   dig example.com
   

4. DNS 쿼리에 응답하는 특정 kube-dns 포드에 문제가 발생한 경우 해당 포드에서 외부 도메인 이름을 확인할 수 있는지 확인합니다.

    dig example.com @KUBE_DNS_POD_IP
   

   KUBE_DNS_POD_IP를 kube-dns 포드 IP 주소로 바꿉니다. 이 IP 주소 값을 모르면 다음 명령어를 실행합니다.

    kubectl get pods -n kube-system -l k8s-app=kube-dns -o wide
   

   IP 주소는 IP 열에 있습니다.

   명령어 확인이 성공하면 다음 예시와 같이 status: NOERROR 및 A 레코드의 세부정보가 표시됩니다.

    ; <<>> DiG 9.16.27 <<>> example.com
    ;; global options: +cmd
    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 31256
    ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
   
    ;; OPT PSEUDOSECTION:
    ; EDNS: version: 0, flags:; udp: 512
    ;; QUESTION SECTION:
    ;example.com.                   IN      A
   
    ;; ANSWER SECTION:
    example.com.            30      IN      A       93.184.215.14
   
    ;; Query time: 6 msec
    ;; SERVER: 10.76.0.10#53(10.76.0.10)
    ;; WHEN: Tue Oct 15 16:45:26 UTC 2024
    ;; MSG SIZE  rcvd: 56
   

5. 셸을 종료합니다.

   exit
   

이러한 명령어 중 하나라도 실패하면 kube-dns 배포 롤링을 다시 시작합니다.

kubectl rollout restart deployment/kube-dns --namespace=kube-system

다시 시작을 완료한 후 dig 명령어를 다시 시도하여 성공하는지 확인합니다. 여전히 실패하면 패킷 캡처를 진행합니다.

패킷 캡처 수행

패킷 캡처를 수행하여 DNS 쿼리가 kube-dns 포드에서 적절하게 수신되고 응답되는지 확인합니다.

1. SSH를 사용하여 kube-dns 포드를 실행하는 노드에 연결합니다. 예를 들면 다음과 같습니다.

   1. Google Cloud 콘솔에서 VM 인스턴스 페이지로 이동합니다.

      VM 인스턴스로 이동

   2. 연결하려는 노드를 찾습니다. kube-dns 포드의 노드 이름을 모르면 다음 명령어를 실행합니다.

      kubectl get pods -n kube-system -l k8s-app=kube-dns -o wide
      

      노드 이름은 노드 열에 표시됩니다.

   3. 연결 열에서 SSH를 클릭합니다.

2. 터미널에서 사전에 설치된 디버그 도구인 toolbox를 시작합니다.

   toolbox
   

3. 루트 프롬프트에서 tcpdump 패키지를 설치합니다.

   apt update -y && apt install -y tcpdump
   

4. tcpdump를 사용하여 DNS 트래픽 패킷 캡처를 수행합니다.

   tcpdump -i eth0 port 53" -w FILE_LOCATION
   

   FILE_LOCATION을 캡처를 저장할 위치의 경로로 바꿉니다.

5. 패킷 캡처를 검토합니다. 대상 IP 주소가 kube-dns 서비스 IP 주소와 일치하는 패킷이 있는지 확인합니다. 이렇게 하면 DNS 요청이 올바른 확인 대상에 도달합니다. 올바른 포드에 도착하는 DNS 트래픽이 표시되지 않으면 요청을 차단하는 네트워크 정책이 있음을 나타낼 수 있습니다.

네트워크 정책 확인

제한적인 네트워크 정책으로 인해 DNS 트래픽이 중단될 수 있습니다. kube-system 네임스페이스에 네트워크 정책이 있는지 확인하려면 다음 명령어를 실행합니다.

kubectl get networkpolicy -n kube-system

네트워크 정책을 찾으면 정책을 검토하고 정책에서 필요한 DNS 통신을 허용하는지 확인합니다. 예를 들어 모든 이그레스 트래픽을 차단하는 네트워크 정책이 있으면 이 정책은 DNS 요청도 차단합니다.

출력이 No resources found in kube-system namespace이면 네트워크 정책이 없으므로 문제 원인으로 배제할 수 있습니다. 로그를 조사하면 더 많은 오류 지점을 찾을 수 있습니다.

임시 DNS 쿼리 로깅 사용 설정

잘못된 DNS 응답과 같은 문제를 식별하는 데 도움이 되도록 DNS 쿼리의 디버그 로깅을 일시적으로 사용 설정합니다. 쿼리를 사용 설정하려면 기존 kube-dns 포드를 기반으로 포드를 만듭니다. kube-dns 배포 변경사항은 자동으로 되돌아갑니다.

임시 DNS 쿼리 로깅 사용 설정은 리소스 집약적인 절차이므로 적절한 로그 샘플을 수집하는 즉시 만든 포드를 삭제하는 것이 좋습니다.

임시 DNS 쿼리 로깅을 사용 설정하려면 다음 단계를 완료합니다.

1. kube-dns 포드를 검색하여 POD 변수에 저장합니다.

   POD=$(kubectl -n kube-system get pods --selector=k8s-app=kube-dns -o jsonpath="{.items[0].metadata.name}")
   

2. kube-dns-debug 포드를 만듭니다. 이 포드는 POD 변수에 저장된 포드의 복사본이지만 dnsmasq 로깅이 사용 설정되어 있습니다. 이 명령어는 원래 kube-dns 포드를 수정하지 않습니다.

   kubectl apply -f <(kubectl get pod -n kube-system ${POD} -o json | jq -e '
   
   (
   
   (.spec.containers[] | select(.name == "dnsmasq") | .args) += ["--log-queries"]
   
   )
   
   | (.metadata.name = "kube-dns-debug")
   
   | (del(.metadata.labels."pod-template-hash"))
   
   ')
   

3. 로그를 검사합니다.

   kubectl logs -f --tail 100 -c dnsmasq -n kube-system kube-dns-debug
   

   Cloud Logging에서도 쿼리를 확인할 수 있습니다.

4. DNS 쿼리 로그를 본 후에 kube-dns-debug 포드를 삭제합니다.

   kubectl -n kube-system delete pod kube-dns-debug
   

kube-dns 포드 조사

kube-dns 포드가 Cloud Logging을 사용하여 DNS 쿼리를 수신하고 확인하는 방법을 검토합니다.

kube-dns 포드와 관련된 로그 항목을 보려면 다음 단계를 완료합니다.

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

   로그 탐색기로 이동

2. 쿼리 창에 다음 필터를 입력하여 kube-dns 컨테이너와 관련된 이벤트를 봅니다.

   resource.type="k8s_container"
   resource.labels.namespace_name="kube-system"
   resource.labels.Pod_name:"kube-dns"
   resource.labels.cluster_name="CLUSTER_NAME"
   resource.labels.location="CLUSTER_LOCATION"
   

   다음을 바꿉니다.

   • CLUSTER_NAME: kube-dns 포드가 속한 클러스터의 이름입니다.
   • CLUSTER_LOCATION: 클러스터의 위치

3. 쿼리 실행을 클릭합니다.

4. 출력을 검토합니다. 다음 출력 예시에서는 표시될 수 있는 오류 중 하나를 보여줍니다.

   {
      "timestamp": "2024-10-10T15:32:16.789Z",
      "severity": "ERROR",
      "resource": {
         "type": "k8s_container",
         "labels": {
         "namespace_name": "kube-system",
         "Pod_name": "kube-dns",
         "cluster_name": "CLUSTER_NAME",
         "location": "CLUSTER_LOCATION"
         }
      },
      "message": "Failed to resolve 'example.com': Timeout."
   },
   

   이 예시에서 kube-dns는 적절한 시간 내에 example.com을 확인할 수 없습니다. 이 유형의 오류는 여러 문제로 인해 발생할 수 있습니다. 예를 들어 업스트림 서버가 kube-dns ConfigMap에서 잘못 구성되었거나 네트워크 트래픽이 많을 수 있습니다.

Cloud Logging을 사용 설정하지 않은 경우에는 대신 Kubernetes 로그를 봅니다.

Pod=$(kubectl get Pods -n kube-system -l k8s-app=kube-dns -o name | head -n1)
kubectl logs -n kube-system $Pod -c dnsmasq
kubectl logs -n kube-system $Pod -c kubedns
kubectl logs -n kube-system $Pod -c sidecar

kube-dns ConfigMap의 최근 변경사항 조사

클러스터에서 갑자기 DNS 확인이 실패하는 경우 한 가지 원인은 잘못된 kube-dns ConfigMap 구성 변경입니다. 특히 스텁 도메인 및 업스트림 서버 정의의 구성 변경으로 인해 문제가 발생할 수 있습니다.

스텁 도메인 설정 업데이트를 확인하려면 다음 단계를 완료합니다.

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

   로그 탐색기로 이동

2. 쿼리 창에 다음 쿼리를 입력합니다.

   resource.labels.cluster_name="clouddns"
   resource.type="k8s_container"
   resource.labels.namespace_name="kube-system"
   labels.k8s-pod/k8s-app="kube-dns" jsonPayload.message=~"Updated stubDomains to"
   

3. 쿼리 실행을 클릭합니다.

4. 출력을 검토합니다. 업데이트가 있으면 출력은 다음과 비슷합니다.

   Updated stubDomains to map[example.com: [8.8.8.8 8.8.4.4 1.1.3.3 1.0.8.111]]
   

   업데이트가 표시되면 결과를 펼쳐 변경사항을 자세히 알아봅니다. 스텁 도메인과 해당하는 업스트림 DNS 서버가 올바르게 정의되었는지 확인합니다. 잘못된 항목으로 인해 해당 도메인을 확인하지 못할 수 있습니다.

업스트림 서버 변경사항을 확인하려면 다음 단계를 완료합니다.

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

   로그 탐색기로 이동

2. 쿼리 창에 다음 쿼리를 입력합니다.

   resource.labels.cluster_name="clouddns"
   resource.type="k8s_container" resource.labels.namespace_name="kube-system"
   labels.k8s-pod/k8s-app="kube-dns" jsonPayload.message=~"Updated upstreamNameservers to"
   

3. 쿼리 실행을 클릭합니다.

4. 출력을 검토합니다. 변경사항이 있으면 출력은 다음과 비슷합니다.

   Updated upstreamNameservers to [8.8.8.8]
   

   결과를 펼쳐 변경사항을 자세히 알아봅니다. 업스트림 DNS 서버 목록이 정확하고 클러스터에서 이러한 서버에 연결할 수 있는지 확인합니다. 이러한 서버를 사용할 수 없거나 잘못 구성하면 일반적인 DNS 확인이 실패할 수 있습니다.

스텁 도메인과 업스트림 서버의 변경사항을 확인했지만 결과가 없으면 다음 필터로 모든 변경사항을 확인합니다.

resource.type="k8s_cluster"
protoPayload.resourceName:"namespaces/kube-system/configmaps/kube-dns"
protoPayload.methodName=~"io.k8s.core.v1.configmaps."

표시된 변경사항을 검토하여 변경사항으로 인해 오류가 발생했는지 확인합니다.

클라우드 고객 지원에 문의

이전 섹션을 진행했지만 문제 원인을 진단할 수 없으면 Cloud Customer Care에 문의하세요.

일반적인 문제 해결

특정 오류나 문제가 발생한 경우 다음 섹션의 안내를 따르세요.

문제: 간헐적인 DNS 제한 시간

DNS 트래픽이 증가하거나 영업 시간이 시작될 때 간헐적으로 DNS 확인 제한 시간이 발생하면 다음 솔루션을 사용하여 DNS 성능을 최적화해 보세요.

• 클러스터에서 실행 중인 kube-dns 포드 수를 확인하고 GKE 노드 총개수와 비교합니다. 리소스가 부족하면 kube-dns 포드를 수직 확장하는 것이 좋습니다.

• DNS 조회 평균 시간을 개선하려면 NodeLocal DNS Cache를 사용 설정합니다.

• 외부 이름에 대한 DNS 확인으로 인해 kube-dns 포드에 과부하가 발생할 수 있습니다. 쿼리 수를 줄이려면 /etc/resolv.conf 파일에서 ndots 설정을 조정합니다. ndots는 초기 절대 쿼리 전에 쿼리를 확인하기 위해 도메인 이름에 표시되어야 하는 점 수를 나타냅니다.

  다음 예시는 애플리케이션 포드 /etc/resolv.conf 파일입니다.

  search default.svc.cluster.local svc.cluster.local cluster.local c.PROJECT_ID.internal google.internal
  nameserver 10.52.16.10
  options ndots:5
  

  이 예시에서 kube-dns는 쿼리된 도메인에서 점 5개를 찾습니다. 포드가 example.com DNS 확인을 호출하면 로그는 다음 예시와 비슷합니다.

  "A IN example.com.default.svc.cluster.local." NXDOMAIN
  "A IN example.com.svc.cluster.local." NXDOMAIN
  "A IN example.com.cluster.local." NXDOMAIN
  "A IN example.com.google.internal." NXDOMAIN
  "A IN example.com.c.PROJECT_ID.internal." NXDOMAIN
  "A IN example.com." NOERROR
  

  이 문제를 해결하려면 ndots 값을 1로 변경하여 단일 점만 찾거나 쿼리하거나 사용하는 도메인의 끝에 점(.)을 추가합니다. 예를 들면 다음과 같습니다.

  dig example.com.
  

문제: 일부 노드에서 DNS 쿼리가 간헐적으로 실패함

일부 노드에서 DNS 쿼리가 간헐적으로 실패하면 다음과 같은 증상이 나타날 수 있습니다.

• kube-dns 서비스 IP 주소 또는 포드 IP 주소에 dig 명령어를 실행하면 DNS 쿼리가 제한 시간으로 인해 간헐적으로 실패합니다.
• kube-dns 포드와 동일한 노드의 포드에서 dig 명령어를 실행하면 실패합니다.

이 문제를 해결하려면 다음 단계를 완료하시기 바랍니다.

1. 연결 테스트를 수행합니다. 문제가 있는 포드나 노드를 소스로, 대상을 kube-dns 포드의 IP 주소로 설정합니다. 이렇게 하면 이 트래픽을 허용하는 데 필요한 방화벽 규칙이 있는지 확인할 수 있습니다.

2. 테스트가 실패하고 방화벽 규칙에서 트래픽을 차단하면 Cloud Logging을 사용하여 방화벽 규칙을 수동으로 변경한 사항을 표시합니다. 특정 종류의 트래픽을 차단하는 변경사항을 찾습니다.

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

      로그 탐색기로 이동

   2. 쿼리 창에 다음 쿼리를 입력합니다.

      logName="projects/project-name/logs/cloudaudit.googleapis.com/activity"
      resource.type="gce_firewall_rule"
      

   3. 쿼리 실행을 클릭합니다. 쿼리 출력을 사용하여 변경사항이 있는지 확인합니다. 오류가 발견되면 오류를 수정하고 방화벽 규칙을 다시 적용합니다.

      자동 방화벽 규칙을 변경하지 마세요.

3. 방화벽 규칙이 변경되지 않은 경우 노드 풀 버전을 확인하고 컨트롤 플레인 및 다른 작동하는 노드 풀과 호환되는지 확인합니다. 클러스터 노드 풀의 부버전이 컨트롤 플레인보다 두 버전 더 오래된 경우에 문제가 발생할 수 있습니다. 이 비호환성에 대한 자세한 내용은 노드 버전이 컨트롤 플레인 버전과 호환되지 않음을 참조하세요.

4. 요청이 올바른 kube-dns 서비스 IP로 전송되는지 확인하려면 문제가 있는 노드에서 네트워크 트래픽을 캡처하고 포트 53(DNS 트래픽)을 필터링합니다. kube-dns 포드 자체에서 트래픽을 캡처하여 요청이 의도한 포드에 도달하고 있고 성공적으로 확인되는지 확인합니다.

다음 단계

• Kubernetes DNS 문제 진단에 대한 일반적인 정보는 DNS 변환 디버깅을 참조하세요.

• 문서에서 문제 해결 방법을 찾을 수 없으면 지원 받기를 참조하여 다음 주제에 대한 조언을 포함한 추가 도움을 요청하세요.

  • Cloud Customer Care에 문의하여 지원 케이스를 엽니다.
  • StackOverflow에서 질문하고 google-kubernetes-engine 태그를 사용하여 유사한 문제를 검색해 커뮤니티의 지원을 받습니다. #kubernetes-engine Slack 채널에 조인하여 더 많은 커뮤니티 지원을 받을 수도 있습니다.
  • 공개 Issue Tracker를 사용하여 버그나 기능 요청을 엽니다.