다음을 통해 공유

Azure Kubernetes Service를 사용하여 CoreDNS 사용자 지정

AKS(Azure Kubernetes Service)는 모든 1.12.x 이상의 클러스터에서 클러스터 DNS 관리 및 확인 시 CoreDNS 프로젝트를 사용합니다. CoreDNS 사용자 지정 및 Kubernetes에 대한 자세한 내용은 공식 업스트림 설명서를 참조하세요.

AKS는 관리되는 서비스이므로, CoreDNS(CoreFile)에 대한 기본 구성을 수정할 수 없습니다. 대신 Kubernetes ConfigMap을 사용하여 기본 설정을 재정의합니다. 기본 AKS CoreDNS ConfigMaps를 보려면 kubectl get configmaps --namespace=kube-system coredns -o yaml 명령을 사용합니다.

이 문서에는 AKS에서 기본 CoreDNS 사용자 지정 옵션에 ConfigMaps를 사용하는 방법이 나와 있습니다. 이 방법은 CoreFile 등 다른 컨텍스트에서 CoreDNS를 구성하는 것과 다릅니다.

참고 항목

이전에는 kube-dns가 클러스터 DNS 관리 및 확인에 사용되었지만 지금은 사용되지 않습니다. kube-dns에서는 Kubernetes 구성 맵을 통해 다양한 사용자 지정 옵션을 제공했습니다. CoreDNS는 kube-dns를 사용하는 이전 버전과 호환되지 않습니다. 이전에 사용한 모든 사용자 지정 항목은 업데이트해야 CoreDNS에서 사용할 수 있습니다.

시작하기 전에

  • 이 문서에서는 기존 AKS 클러스터가 있다고 가정합니다. AKS 클러스터가 필요한 경우 Azure CLI, Azure PowerShell 또는 Azure Portal을 사용하여 만들 수 있습니다.
  • 실행 중인 CoreDNS 버전을 확인합니다. 구성 값은 버전 간에 변경 될 수 있습니다.
  • 아래의 예제와 같은 구성을 만들 때 데이터 섹션의 이름은 .server 또는 .override로 끝나야 합니다. 이 명명 규칙은 kubectl get configmaps --namespace=kube-system coredns -o yaml 명령을 사용하여 볼 수 있는 기본 AKS CoreDNS ConfigMap에 정의되어 있습니다.

플러그인 지원

기본 제공 CoreDNS 플러그인이 모두 지원됩니다. 추가 기능/타사 플러그인은 지원되지 않습니다.

DNS 다시 쓰기

AKS를 사용하여 CoreDNS를 사용자 지정하여 즉석 DNS 이름 다시 쓰기를 수행할 수 있습니다.

  1. corednsms.yaml이라는 파일을 만들고 다음 예제 구성을 붙여넣습니다. <domain to be rewritten>을 사용자 고유의 정규화된 도메인 이름으로 바꾸어야 합니다.

    apiVersion: v1
kind: ConfigMap
metadata:
  name: coredns-custom
  namespace: kube-system
data:
  test.server: |
    <domain to be rewritten>.com:53 {
    log
    errors
    rewrite stop {
      name regex (.*)\.<domain to be rewritten>\.com {1}.default.svc.cluster.local
      answer name (.*)\.default\.svc\.cluster\.local {1}.<domain to be rewritten>.com
    }
    forward . /etc/resolv.conf # you can redirect this to a specific DNS server such as 10.0.0.10, but that server must be able to resolve the rewritten domain name
    }

    중요합니다

    CoreDNS 서비스 IP와 같은 DNS 서버로 리디렉션하는 경우, 해당 DNS 서버에서 다시 쓴 도메인 이름을 확인할 수 있어야 합니다.

  2. kubectl apply configmap 명령을 사용하여 ConfigMap을 만들고 YAML 매니페스트의 이름을 지정합니다.

    kubectl apply -f corednsms.yaml

  3. kubectl get configmaps를 사용하여 사용자 지정이 적용되었는지 확인하고 coredns-custom ConfigMap을 지정합니다.

    kubectl get configmaps --namespace=kube-system coredns-custom -o yaml

  4. ConfigMap을 다시 로드하고 Kubernetes 스케줄러가 가동 중지 없이 CoreDNS를 다시 시작할 수 있도록 하려면 kubectl rollout restart를 사용하여 롤링 다시 시작을 수행합니다.

    kubectl -n kube-system rollout restart deployment coredns

사용자 지정 전달 서버

네트워크 트래픽에 대한 전달 서버를 지정해야 하는 경우 ConfigMap을 만들어 DNS를 사용자 지정할 수 있습니다.

  1. corednsms.yaml이라는 파일을 만들고 다음 예제 구성을 붙여넣습니다. forward 이름 및 주소를 사용자 환경에 대한 값으로 바꿔야 합니다.

    apiVersion: v1
kind: ConfigMap
metadata:
  name: coredns-custom
  namespace: kube-system
data:
  test.server: | # you may select any name here, but it must end with the .server file extension
    <domain to be rewritten>.com:53 {
        forward foo.com 1.1.1.1
    }

  2. kubectl apply configmap 명령을 사용하여 ConfigMap을 만들고 YAML 매니페스트의 이름을 지정합니다.

    kubectl apply -f corednsms.yaml

  3. ConfigMap을 다시 로드하고 Kubernetes 스케줄러가 가동 중지 없이 CoreDNS를 다시 시작할 수 있도록 하려면 kubectl rollout restart를 사용하여 롤링 다시 시작을 수행합니다.

    kubectl -n kube-system rollout restart deployment coredns

사용자 지정 도메인 사용

내부적으로만 확인할 수 있는 사용자 지정 도메인을 구성할 수 있습니다. 예를 들면, 유효한 최상위 도메인이 아닌 사용자 지정 도메인 puglife.local을 확인할 수 있습니다. 사용자 지정 도메인 ConfigMap이 없으면 AKS 클러스터에서 주소를 확인할 수 없습니다.

  1. corednsms.yaml이라는 새 파일을 만들고 다음 예제 구성을 붙여넣습니다. 사용자 지정 도메인과 IP 주소를 사용자 고유의 환경 값으로 업데이트합니다.

    apiVersion: v1
kind: ConfigMap
metadata:
  name: coredns-custom
  namespace: kube-system
data:
  puglife.server: | # you may select any name here, but it must end with the .server file extension
    puglife.local:53 {
        errors
        cache 30
        forward . 192.11.0.1  # this is my test/dev DNS server
    }

  2. kubectl apply configmap 명령을 사용하여 ConfigMap을 만들고 YAML 매니페스트의 이름을 지정합니다.

    kubectl apply -f corednsms.yaml

  3. ConfigMap을 다시 로드하고 Kubernetes 스케줄러가 가동 중지 없이 CoreDNS를 다시 시작할 수 있도록 하려면 kubectl rollout restart를 사용하여 롤링 다시 시작을 수행합니다.

    kubectl -n kube-system rollout restart deployment coredns

스텁 도메인

CoreDNS를 사용하여 스텁 도메인도 구성할 수 있습니다.

  1. corednsms.yaml이라는 파일을 만들고 다음 예제 구성을 붙여넣습니다. 사용자 지정 도메인과 IP 주소를 사용자 고유의 환경 값으로 업데이트합니다.

    apiVersion: v1
kind: ConfigMap
metadata:
  name: coredns-custom
  namespace: kube-system
data:
  test.server: | # you may select any name here, but it must end with the .server file extension
    abc.com:53 {
     errors
     cache 30
     forward . 1.2.3.4
    }
    my.cluster.local:53 {
        errors
        cache 30
        forward . 2.3.4.5
    }

  2. kubectl apply configmap 명령을 사용하여 ConfigMap을 만들고 YAML 매니페스트의 이름을 지정합니다.

    kubectl apply -f corednsms.yaml

  3. ConfigMap을 다시 로드하고 Kubernetes 스케줄러가 가동 중지 없이 CoreDNS를 다시 시작할 수 있도록 하려면 kubectl rollout restart를 사용하여 롤링 다시 시작을 수행합니다.

    kubectl -n kube-system rollout restart deployment coredns

호스트 플러그인

모든 기본 제공 플러그 인이 지원되므로 CoreDNS 호스트 플러그 인을 사용하여 /etc/hosts도 사용자 지정할 수 있습니다.

  1. corednsms.yaml이라는 파일을 만들고 다음 예제 구성을 붙여넣습니다. 사용자 환경에 맞는 값으로 IP 주소와 호스트 이름을 업데이트해야 합니다.

    apiVersion: v1
kind: ConfigMap
metadata:
  name: coredns-custom # this is the name of the configmap you can overwrite with your changes
  namespace: kube-system
data:
    test.override: | # you may select any name here, but it must end with the .override file extension
          hosts { 
              10.0.0.1 example1.org
              10.0.0.2 example2.org
              10.0.0.3 example3.org
              fallthrough
          }

  2. kubectl apply configmap 명령을 사용하여 ConfigMap을 만들고 YAML 매니페스트의 이름을 지정합니다.

    kubectl apply -f corednsms.yaml

  3. ConfigMap을 다시 로드하고 Kubernetes 스케줄러가 가동 중지 없이 CoreDNS를 다시 시작할 수 있도록 하려면 kubectl rollout restart를 사용하여 롤링 다시 시작을 수행합니다.

    kubectl -n kube-system rollout restart deployment coredns

internal.cloudapp.net 및 reddog.microsoft.com 대한 검색 도메인이 잘못되었습니다.

Azure DNS는 Azure DNS를 사용하는 가상 네트워크의 기본 검색 도메인 <vnetId>.<region>.internal.cloudapp.net 과 사용자 지정 DNS 서버를 사용하는 가상 네트워크의 비기능 스텁 reddog.microsoft.com 을 구성합니다(자세한 내용은 리소스 설명서의 이름 확인 참조). Kubernetes는 클러스터 서비스 호스트 이름 확인을 제대로 지원하도록 Pod DNS 설정을 ndots: 5 구성합니다. 이러한 두 구성이 결합되어 시스템이 도메인 검색 목록을 통해 처리하는 동안 업스트림 이름 서버로 전송되지 않는 잘못된 검색 도메인 완성 쿼리가 생성됩니다. 이러한 잘못된 쿼리로 인해 이름 확인이 지연되고 업스트림 DNS 서버에 추가 부하가 발생할 수 있습니다.

v20241025 AKS 릴리스부터 AKS는 이러한 잘못된 검색 도메인 완성 쿼리가 업스트림 DNS로 전달되지 않도록 하기 위해 다음 두 경우에서 NXDOMAIN으로 응답하도록 CoreDNS를 구성합니다.

  • 루트 도메인 또는 의 하위 도메인 reddog.microsoft.com에 대한 모든 쿼리입니다.
  • 도메인 이름에 7개 이상의 레이블이 있는 하위 도메인 internal.cloudapp.net 에 대한 쿼리입니다.
    • 이 구성을 사용하면 호스트 이름별 가상 머신 확인이 계속 성공할 수 있습니다. 예를 들어 CoreDNS는 Azure DNS에 aks12345.myvnetid.myregion.internal.cloudapp.net (6개의 레이블)을 보내지만 거부 mcr.microsoft.com.myvnetid.myregion.internal.cloudapp.net (8개의 레이블)

이 블록은 클러스터에 대한 Corefile의 기본 서버 블록에서 구현됩니다. 필요한 경우 전달 플러그 인을 사용하도록 설정된 적절한 도메인에 대한 사용자 지정 서버 블록을 만들어 이 거부 구성을 사용하지 않도록 설정할 수 있습니다.

  1. corednsms.yaml이라는 파일을 만들고 다음 예제 구성을 붙여넣습니다. 사용자 환경에 맞는 값으로 IP 주소와 호스트 이름을 업데이트해야 합니다.

    apiVersion: v1
kind: ConfigMap
metadata:
  name: coredns-custom # this is the name of the configmap you can overwrite with your changes
  namespace: kube-system
data:
    override-block.server:
       internal.cloudapp.net:53 {
           errors
           cache 30
           forward . /etc/resolv.conf
       }
       reddog.microsoft.com:53 {
           errors
           cache 30
           forward . /etc/resolv.conf
       }

  2. kubectl apply configmap 명령을 사용하여 ConfigMap을 만들고 YAML 매니페스트의 이름을 지정합니다.

    kubectl apply -f corednsms.yaml

  3. ConfigMap을 다시 로드하고 Kubernetes 스케줄러가 가동 중지 없이 CoreDNS를 다시 시작할 수 있도록 하려면 kubectl rollout restart를 사용하여 롤링 다시 시작을 수행합니다.

    kubectl -n kube-system rollout restart deployment coredns

문제 해결

엔드포인트나 확인 검사와 같은 일반적인 CoreDNS 문제 해결 단계는 DNS 확인 디버깅을 참조하세요.

CoreDNS 가로 Pod 크기 조정 구성

AKS 클러스터 내에서 DNS 트래픽이 갑자기 급증하는 것은 AKS가 워크로드에 제공하는 탄력성으로 인해 흔히 발생합니다. 이러한 급증으로 인해 CoreDNS Pod의 메모리 사용량이 증가할 수 있습니다. 어떤 경우에는 이러한 메모리 사용량 증가로 인해 Out of memory 문제가 발생할 수 있습니다. 이 문제를 선점하기 위해 AKS 클러스터는 CoreDNS Pod의 크기를 자동으로 조정하여 Pod당 메모리 사용량을 줄입니다. 이 자동 크기 조정 논리의 기본 설정은 coredns-autoscaler ConfigMap에 저장됩니다. 그러나 CoreDNS Pod의 기본 자동 크기 조정이 CoreDNS Pod의 Out of memory 문제를 방지할 만큼 항상 공격적이지는 않다는 것을 알 수 있습니다. 이 경우 coredns-autoscaler ConfigMap을 직접 수정할 수 있습니다. Out of memory 문제의 근본 원인을 해결하지 않고 CoreDNS Pod 수를 늘리는 것만으로는 일시적인 해결 방법만 제공할 수 있습니다. CoreDNS Pod가 실행 중인 노드 전체에 사용 가능한 메모리가 충분하지 않은 경우 CoreDNS Pod 수를 늘려도 도움이 되지 않습니다. 리소스 사용량 최적화, 리소스 요청 및 제한 조정, 노드에 메모리 추가 등 추가 조사를 하고 적절한 솔루션을 구현해야 할 수도 있습니다.

CoreDNS는 Pod 자동 크기 조정을 위해 수평 클러스터 비례 자동 크기 조정기를 사용합니다. coredns-autoscaler ConfigMap을 편집하여 CoreDNS Pod 수에 대한 크기 조정 논리를 구성할 수 있습니다. coredns-autoscaler ConfigMap은 현재 지원되는 두 가지 제어 모드에 해당하는 두 가지 ConfigMap 키 값(linear 및 ladder)을 지원합니다. linear 컨트롤러는 max( ceil( cores * 1/coresPerReplica ) , ceil( nodes * 1/nodesPerReplica ) )에 해당하는 [최소, 최대] 범위의 복제본 수를 생성합니다. ladder 컨트롤러는 두 개의 서로 다른 단계 함수(코어 크기 조정을 위한 함수와 노드 크기 조정을 위한 함수)를 참조하여 복제본 수를 계산하여 두 복제본 값의 최댓값을 산출합니다. 제어 모드 및 ConfigMap 형식에 대한 자세한 내용은 업스트림 설명서를 참조하세요.

중요합니다

클러스터당 최소 2개의 CoreDNS Pod 복제본이 권장됩니다. 최소 1개의 CoreDNS Pod 복제본을 구성하면 클러스터 업그레이드 작업과 같이 노드 드레이닝이 필요한 작업 중에 오류가 발생할 수 있습니다.

coredns-autoscaler ConfigMap을 검색하려면 다음을 반환하는 kubectl get configmap coredns-autoscaler -n kube-system -o yaml 명령을 실행하면 됩니다.

apiVersion: v1
data:
  ladder: '{"coresToReplicas":[[1,2],[512,3],[1024,4],[2048,5]],"nodesToReplicas":[[1,2],[8,3],[16,4],[32,5]]}'
kind: ConfigMap
metadata:
  name: coredns-autoscaler
  namespace: kube-system
  resourceVersion: "..."
  creationTimestamp: "..."

CoreDNS 세로 Pod 자동 크기 조정 동작

CoreDNS는 AKS에서 관리하고 기본적으로 사용하도록 설정하는 필수 추가 기능입니다. CoreDNS 서비스 가용성을 유지하기 위해 CoreDNS는 CoreDNS Pod 다시 시작 프로세스를 방지하기 위해 추가 기능 자동 크기 조정 기능을 사용하도록 설정할 때 원래 제공된 리소스 요청/제한을 사용하여 서비스를 사용할 수 없도록 유지합니다.

AKS 관리형 CoreDNS 추가 기능의 경우 기본 CPU 요청/제한은 100m/3 코어로 설정되고 메모리 요청/제한은 70Mi/500Mi로 설정됩니다. 이러한 기본값에 따라 CPU에 대한 요청 대 제한 비율은 약 1:30이며 메모리의 경우 약 1/7입니다. 권장 CPU 요청이 500m인 경우 VPA는 CPU 제한을 15로 조정하여 이 비율을 유지합니다. 마찬가지로 권장 메모리 요청이 700Mi인 경우 VPA는 메모리 제한을 5000Mi로 조정합니다.

VPA는 VPA 권장 CPU/Mem 요청 및 AKS 정의 요청-제한 비율에 따라 CoreDNS CPU 및 메모리 제한을 큰 값으로 설정합니다. 이러한 조정은 사용량이 많은 서비스 시간 동안 여러 요청을 처리하는 데 유용합니다. 단점은 CoreDNS가 최대 서비스 시간 때 노드에서 사용 가능한 모든 CPU 및 메모리 리소스를 사용할 수 있다는 것입니다.

단일 이상적인 CPU 및 메모리 요청/제한 값을 설정하여 대규모 클러스터와 작은 클러스터의 요구 사항을 동시에 충족하기는 어렵습니다. 최적화된 추가 기능 크기 조정을 사용하도록 설정하면 CoreDNS CPU 및 메모리 요청/제한을 사용자 지정하거나 VPA를 사용하여 특정 클러스터 요구 사항을 충족하기 위해 CoreDNS를 자동 크기 조정할 수 있습니다. 고려해야 할 몇 가지 시나리오는 다음과 같습니다.

  • VPA가 CoreDNS 서비스에 적합한지 여부를 고려하고 VPA 권장 사항만 보려고 합니다. VPA에서 Pod를 자동으로 업데이트하지 않으려면 재정의 VPA 업데이트 모드를 Off 로 설정하여 CoreDNS용 VPA를 사용하지 않도록 설정할 수 있습니다. 배포에서 리소스 구성을 사용자 지정 하여 CPU/메모리 요청/제한을 원하는 값으로 설정합니다.
  • VPA를 사용하는 것을 고려하고 있지만 VPA가 CPU 및 메모리 제한을 한 번에 큰 값으로 범프하지 않도록 요청 대 제한의 비율을 제한하려고 합니다. 배포에서 리소스를 사용자 지정하고 CPU 및 메모리 요청/제한 값을 업데이트하여 요청 대 제한 비율을 1/2 또는 1/3으로 유지할 수 있습니다.
  • VPA 컨테이너 정책이 maxAllowed CPU 및 메모리를 설정하는 경우 권장되는 리소스 요청은 이러한 제한을 초과하지 않습니다. 리소스 구성을 사용자 지정하면 maxAllowed 값을 늘리거나 줄이고 VPA의 권장 사항을 제어할 수 있습니다.

자세한 내용은 AKS 클러스터에서 추가 기능 자동 크기 조정 사용(미리 보기)을 참조하세요.

DNS 쿼리 로깅 사용

  1. coredns-custom ConfigMap에 다음 구성을 추가합니다.

    apiVersion: v1
kind: ConfigMap
metadata:
  name: coredns-custom
  namespace: kube-system
data:
  log.override: | # you may select any name here, but it must end with the .override file extension
        log

  2. 구성 변경 내용을 적용하고 CoreDNS에서 다음 명령을 사용하여 ConfigMap을 다시 로드하도록 합니다.

    # Apply configuration changes
kubectl apply -f corednsms.yaml

# Force CoreDNS to reload the ConfigMap
kubectl -n kube-system rollout restart deployment coredns

  3. kubectl logs 명령을 사용하여 CoreDNS 디버그 로깅을 봅니다.

    kubectl logs --namespace kube-system -l k8s-app=kube-dns

CoreDNS Pod 트래픽 불균형 문제 해결

AKS 클러스터에서 여러 CoreDNS Pod가 실행되고 있더라도 하나 또는 두 개의 CoreDNS Pod가 훨씬 더 높은 CPU 사용량을 표시하고 다른 쿼리보다 더 많은 DNS 쿼리를 처리하는 것을 관찰할 수 있습니다. 이는 Kubernetes에서 알려진 문제 이며 CoreDNS Pod 중 하나가 오버로드되고 충돌할 수 있습니다.

이러한 고르지 않은 DNS 쿼리 배포는 주로 Kubernetes의 UDP 부하 분산 제한으로 인해 발생합니다. 이 플랫폼은 5개의 튜플 해시(원본 IP, 원본 포트, 대상 IP, 대상 포트, 프로토콜)를 사용하여 UDP 트래픽을 분산하므로 애플리케이션이 DNS 쿼리에 동일한 원본 포트를 다시 사용하는 경우 해당 클라이언트의 모든 쿼리가 동일한 CoreDNS Pod로 라우팅되어 단일 Pod가 불균형한 양의 트래픽을 처리합니다.

또한 일부 애플리케이션은 연결 풀링을 사용하고 DNS 연결을 다시 사용합니다. 이 동작은 단일 CoreDNS Pod에 DNS 쿼리를 더 집중하여 불균형을 악화시키고 오버로드 및 잠재적인 충돌 위험을 높일 수 있습니다.

CoreDNS 파드 트래픽 분포 확인

시작하기 전에 위의 DNS 쿼리 로깅 사용 섹션의 단계에 따라 CoreDNS Pod에서 필요한 DNS 쿼리 로그를 캡처합니다. 사용하도록 설정되면 다음 명령을 실행합니다.

  1. 다음 명령을 실행하여 클러스터에 있는 모든 CoreDNS Pod의 이름을 가져옵니다.

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

  2. 각 CoreDNS Pod에 대한 로그를 검토하여 DNS 쿼리 패턴을 분석합니다.

    kubectl logs --namespace kube-system <coredns-pod1>
kubectl logs --namespace kube-system <coredns-pod2>
# Repeat on all CoreDNS pods

  3. 단일 CoreDNS Pod의 로그에만 표시되는 반복되는 클라이언트 IP 주소 및 포트를 찾습니다. 이는 특정 클라이언트의 DNS 쿼리가 균등하게 분산되지 않음을 나타냅니다.

    로그 항목 예제:

    [INFO] 10.244.0.247:5556 - 42621 "A IN myservice.default.svc.cluster.local. udp 28" NOERROR qr,aa,rd 106 0.000141s
    • 10.244.0.247: DNS 쿼리를 만드는 클라이언트 IP 주소
    • 5556: 클라이언트 원본 포트
    • 42621: 검색 ID

    하나의 Pod 로그에서만 동일한 클라이언트 IP 및 포트가 반복적으로 표시되는 경우 트래픽 불균형을 확인합니다.

이러한 불균형을 발견하면 애플리케이션이 UDP 원본 포트를 다시 사용하거나 연결을 풀링할 수 있습니다. 근본 원인에 따라 다음 완화 작업을 수행할 수 있습니다.

  • UDP 원본 포트 재사용으로 인해 발생합니다.

    UDP 원본 포트 재사용은 클라이언트 애플리케이션이 동일한 UDP 원본 포트에서 여러 DNS 쿼리를 보낼 때 발생합니다. 이 문제가 있는 경우 애플리케이션 또는 DNS 클라이언트를 업데이트하여 각 DNS 쿼리에 대한 원본 포트를 임의로 업데이트하여 요청을 Pod 간에 더 균등하게 분산하는 데 도움이 됩니다.

  • 연결 풀링으로 인해 발생:
    연결 풀은 각 요청에 대해 새 연결을 만드는 대신 애플리케이션에서 기존 네트워크 연결을 다시 사용하는 데 사용하는 메커니즘입니다. 이렇게 하면 효율성이 향상되지만 애플리케이션의 모든 DNS 쿼리가 동일한 연결을 통해 전송되어 동일한 CoreDNS Pod로 라우팅될 수 있습니다. 이를 완화하려면 연결 TTL(Time to Live)을 줄이거나 연결 생성을 임의로 지정하여 애플리케이션의 DNS 연결 처리를 조정하여 쿼리가 단일 CoreDNS Pod에 집중되지 않도록 합니다.

이러한 변경은 보다 균형 잡힌 DNS 쿼리 배포를 달성하고 개별 Pod를 오버로드할 위험을 줄이는 데 도움이 될 수 있습니다.

다음 단계

이 문서에서는 CoreDNS를 사용자 지정하기 위한 예제 시나리오를 몇 가지 살펴보았습니다. CoreDNS 프로젝트에 대한 자세한 내용은 CoreDNS 업스트림 프로젝트 페이지를 참조하세요.

핵심 네트워크 개념에 대해 자세히 알아보려면 AKS의 애플리케이션에 대한 네트워크 개념을 참조하세요.