다음을 통해 공유

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
    }

    Important

    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 형식에 대한 자세한 내용은 업스트림 설명서를 참조하세요.

Important

클러스터당 최소 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: "..."

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

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