kubernetes · bluefriday · Jul 13, 2020
diff --git a/content/ko/docs/tasks/administer-cluster/dns-custom-nameservers.md b/content/ko/docs/tasks/administer-cluster/dns-custom-nameservers.md
@@ -0,0 +1,261 @@
+---
+title: DNS 서비스 사용자 정의하기
+content_type: task
+min-kubernetes-server-version: v1.12
+---
+
+<!-- overview -->
+이 페이지는 클러스터 안에서 사용자의 
+DNS {{< glossary_tooltip text="파드(Pod)" term_id="pod" >}} 를 설정하고 
+DNS 확인 절차를 사용자 정의 하는 방법을 설명한다.
+
+## {{% heading "prerequisites" %}}
+
+{{< include "task-tutorial-prereqs.md" >}}
+
+클러스터는 CoreDNS 애드온을 구동하고 있어야 한다. 
+[CoreDNS로 이관하기](https://kubernetes.io/ko/docs/tasks/administer-cluster/coredns/#coredns%EB%A1%9C-%EC%9D%B4%EA%B4%80%ED%95%98%EA%B8%B0) 
+에서 `kubeadm` 을 이용하여 `kube-dns` 로부터 이관하는 방법을 설명한다.  
+
+{{% version-check %}}
+
+<!-- steps -->
+
+## 소개
+
+DNS 는 _애드온 관리자_인 [클러스터 애드온](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/README.md)을 
+사용하여 자동으로 시작되는 쿠버네티스 
+내장 서비스이다.
+
+쿠버네티스 v1.12 부터, CoreDNS는 kube-dns를 대체하여 권장되는 DNS 서버이다. 만약 사용자의 클러스터가 원래 kube-dns를 사용하였을 경우, 
+CoreDNS 대신 `kube-dns` 를 계속 사용할 수도 있다.
+
+{{< note >}}
+CoreDNS와 kube-dns 서비스 모두 `metadata.name` 필드에 `kube-dns` 로 이름이 지정된다.
+이를 통해, 기존의 `kube-dns` 서비스 이름을 사용하여 클러스터 내부의 주소를 확인하는 워크로드에 대한 상호 운용성이 증가된다. `kube-dns` 로 서비스 이름을 사용하면, 해당 DNS 공급자가 어떤 공통 이름으로 실행되고 있는지에 대한 구현 세부 정보를 추상화 한다.
+{{< /note >}}
+
+CoreDNS를 디플로이먼트로 실행하고 있을 경우, 일반적으로 고정 IP 주소를 갖는 쿠버네티스 서비스로 노출 된다. 
+Kubelet 은 `--cluster-dns=<dns-service-ip>` 플래그를 사용하여 DNS 확인자 정보를 각 컨테이너에 전달한다.
+
+DNS 이름에도 도메인이 필요하다. 사용자는 kubelet 에 있는 `--cluster-domain=<default-local-domain>` 플래그를 
+통하여 로컬 도메인을 설정할 수 있다.
+
+DNS 서버는 정방향 조회 (A 및 AAAA 레코드), 포트 조회 (SRV 레코드), 역방향 IP 주소 조회 (PTR 레코드) 등을 지원한다.
+더 자세한 내용은 [서비스 및 파드용 DNS](/ko/docs/concepts/services-networking/dns-pod-service/)을 참조한다.
+
+만약 파드의 `dnsPolicy` 가 `default` 로 지정되어 있는 경우, 
+파드는 자신이 실행되는 노드의 이름 확인 구성을 상속한다.
+파드의 DNS 확인도 노드와 동일하게 작동해야 한다.
+그 외에는 [알려진 이슈(EN)](/docs/tasks/debug-application-cluster/dns-debugging-resolution/#known-issues)를 참조한다.
+
+만약 위와 같이 동작하기를 원하지 않거나, 파드를 위해 다른 DNS 설정이 필요한 경우,
+사용자는 kubelet 의 `--resolv-conf` 플래그를 사용할 수 있다.
+파드가 DNS를 상속받지 못하도록 하기 위해 이 플래그를 ""로 설정한다.
+DNS 상속을 위해 `/etc/resolv.conf` 이외의 파일을 지정할 경우 유효한 파일 경로를 설정한다.
+
+## CoreDNS
+
+CoreDNS는 [dns 명세](https://github.com/kubernetes/dns/blob/master/docs/specification.md)을 준수하며 클러스터 DNS 역할을 할 수 있는, 범용적인 권한을 갖는 DNS 서버이다.
+
+### CoreDNS 컨피그맵(ConfigMap) 옵션
+
+CoreDNS는 모듈형이며 플러그형인 DNS 서버이며, 각 플러그인들은 CoreDNS에 새로운 기능을 부가한다.
+이는 CoreDNS 구성 파일인 [코어파일](https://coredns.io/2017/07/23/corefile-explained/)을 관리하여 구성 할 수 있다.
+클러스터 관리자는 CoreDNS 코어파일에 대한 {{< glossary_tooltip text="컨피그맵" term_id="configmap" >}}을 수정하여
+해당 클러스터에 대한 DNS 서비스 검색 동작을 
+변경할 수 있다.
+
+쿠버네티스에서 CoreDNS는 아래의 기본 코어파일 구성으로 설치된다.
+
+```yaml
+apiVersion: v1
+kind: ConfigMap
+metadata:
+  name: coredns
+  namespace: kube-system
+data:
+  Corefile: |
+    .:53 {
+        errors
+        health {
+            lameduck 5s
+        }
+        ready
+        kubernetes cluster.local in-addr.arpa ip6.arpa {
+            pods insecure
+            fallthrough in-addr.arpa ip6.arpa
+            ttl 30
+        }
+        prometheus :9153
+        forward . /etc/resolv.conf
+        cache 30
+        loop
+        reload
+        loadbalance
+    }
+```
+
+코어파일의 구성은 CoreDNS의 아래 [플러그인](https://coredns.io/plugins) 을 포함한다.
+
+* [에러](https://coredns.io/plugins/errors/): 오류는 표준 출력(stdout)에 기록된다.
+* [헬스체크(health)](https://coredns.io/plugins/health/): CoreDNS의 상태는 `http://localhost:8080/health` 에 기록된다. 이 확장 구문에서 `lameduck` 은 프로세스를 비정상 상태로 만들고, 프로세스가 종료되기 전에 5초 동안 기다린다.
+* [준비(ready)](https://coredns.io/plugins/ready/): 8181 포트의 HTTP 엔드포인트는, 모든 플러그인이 준비되었다는 신호를 보내면 200 OK 를 반환한다.
+* [쿠버네티스](https://coredns.io/plugins/kubernetes/): CoreDNS는 쿠버네티스의 서비스 및 파드의 IP를 기반으로 DNS 쿼리에 대해 응답한다. 해당 플러그인에 대한 [세부 사항](https://coredns.io/plugins/kubernetes/) 은 CoreDNS 웹사이트에서 확인 가능하다. `ttl` 을 사용하면 응답에 대한 사용자 정의 TTL 을 지정할 수 있으며 기본값은 5초이다. 허용되는 최소 TTL 은 0초이며 최대값은 3600초이다. 레코드가 캐싱되지 않도록 할 경우, TTL을 0으로 설정한다.
+  `pods insecure` 옵션은 _kube-dns_와의 하위 호환성을 위해 제공된다. `pods verified` 옵션을 사용하여, 일치하는 IP의 동일 네임스페이스에 파드가 존재하는 경우에만 A 레코드를 반환하게 할 수 있다. `pods disabled` 옵션은 파드 레코드를 사용하지 않을 경우 사용 된다.
+* [프로메테우스](https://coredns.io/plugins/metrics/): CoreDNS의 메트릭은 [Prometheus](https://prometheus.io/)형식(OpenMetrics 라고도 알려진)의 `http://localhost:9153/metrics` 에서 사용 가능하다.
+* [포워드](https://coredns.io/plugins/forward/): 쿠버네티스 클러스터 도메인에 없는 쿼리들은 모두 사전에 정의된 리졸버(/etc/resolv.conf)로 전달된다.
+* [캐시](https://coredns.io/plugins/cache/): 프론트 엔드 캐시를 활성화한다.
+* [루프](https://coredns.io/plugins/loop/): 간단한 전달 루프를 감지하고, 루프가 발견되면 CoreDNS 프로세스를 중단한다.
+* [리로드(reload)](https://coredns.io/plugins/reload): 변경된 Corefile을 자동으로 다시 로드하도록 한다. 컨피그맵 설정을 변경한 후에 변경 사항이 적용되기 위하여 약 2분정도 소요된다.
+* [로드밸런싱(loadbalance)](https://coredns.io/plugins/loadbalance): 응답에 대하여 A, AAAA, MX 레코드의 순서를 무작위로 선정하는 라운드-로빈 DNS 로드밸런서이다.
+
+사용자는 컨피그맵을 변경하여 기본 CoreDNS 동작을 변경할 수 있다.
+
+### CoreDNS를 사용하는 스텁 도메인(Stub-domain)과 업스트림 네임서버(upstream nameserver)의 설정
+
+CoreDNS는 [포워드 플러그인](https://coredns.io/plugins/forward/)를 사용하여 스텁 도메인 및 업스트림 네임 서버를 구성할 수 있다.
+
+#### 예시
+만약 클러스터 운영자가 10.150.0.1 에 위치한 [Consul](https://www.consul.io/) 도메인 서버를 가지고 있고, 모든 Consul 이름의 접미사가 .consul.local 인 경우, CoreDNS에서 이를 구성하기 위해 클러스터 관리자는 CoreDNS 컨피그맵에서 다음 구문을 생성한다.
+
+```
+consul.local:53 {
+        errors
+        cache 30
+        forward . 10.150.0.1
+    }
+```
+
+모든 비 클러스터의 DNS 조회가 172.16.0.1 의 특정 네임 서버를 통과하도록 할 경우, `/etc/resolv.conf` 대신 `forward` 를 네임 서버로 지정한다.
+
+```
+forward .  172.16.0.1
+```
+
+기본 `Corefile` 구성에 따른 최종 컨피그맵은 다음과 같다.
+
+```yaml
+apiVersion: v1
+kind: ConfigMap
+metadata:
+  name: coredns
+  namespace: kube-system
+data:
+  Corefile: |
+    .:53 {
+        errors
+        health
+        kubernetes cluster.local in-addr.arpa ip6.arpa {
+           pods insecure
+           fallthrough in-addr.arpa ip6.arpa
+        }
+        prometheus :9153
+        forward . 172.16.0.1
+        cache 30
+        loop
+        reload
+        loadbalance
+    }
+    consul.local:53 {
+        errors
+        cache 30
+        forward . 10.150.0.1
+    }
+```
+
+`Kubeadm` 툴은 kube-dns 컨피그맵에서 동일한 설정의 CoreDNS 컨피그맵으로의 
+자동 변환을 지원한다.
+
+{{< note >}}
+kube-dns는 스텁 도메인 및 네임서버(예: ns.foo.com) 에 대한 FQDN을 허용하지만 CoreDNS에서는 이 기능을 지원하지 않는다.
+변환 과정에서, 모든 FQDN 네임서버는 CoreDNS 설정에서 생략된다.
+{{< /note >}}
+
+## kube-dns와 대응되는 CoreDNS 설정
+
+CoreDNS는 kube-dns 이상의 기능을 지원한다.
+`StubDomains` 과 `upstreamNameservers` 를 지원하도록 생성된 kube-dns의 컨피그맵은 CoreDNS의 `forward` 플러그인으로 변환된다.
+마찬가지로, kube-dns의 `Federations` 플러그인은 CoreDNS의 `federation` 플러그인으로 변환된다.
+
+### 예시
+
+kube-dns에 대한 이 컨피그맵 예제는 페더레이션, 스텁도메인 및 업스트림네임서버를 지정한다.
+
+```yaml
+apiVersion: v1
+data:
+  federations: |
+    {"foo" : "foo.feddomain.com"}
+  stubDomains: |
+    {"abc.com" : ["1.2.3.4"], "my.cluster.local" : ["2.3.4.5"]}
+  upstreamNameservers: |
+    ["8.8.8.8", "8.8.4.4"]
+kind: ConfigMap
+```
+
+CoreDNS에서는 동등한 설정으로 Corefile을 생성한다.
+
+* 페더레이션:
+```
+federation cluster.local {
+    foo foo.feddomain.com
+}
+```
+
+* 스텁도메인:
+```yaml
+abc.com:53 {
+    errors
+    cache 30
+    forward . 1.2.3.4
+}
+my.cluster.local:53 {
+    errors
+    cache 30
+    forward . 2.3.4.5
+}
+```
+
+기본 플러그인으로 구성된 완전한 Corefile.
+
+```
+.:53 {
+    errors
+    health
+    kubernetes cluster.local in-addr.arpa ip6.arpa {
+        pods insecure
+        fallthrough in-addr.arpa ip6.arpa
+    }
+    federation cluster.local {
+        foo foo.feddomain.com
+    }
+    prometheus :9153
+    forward . 8.8.8.8 8.8.4.4
+    cache 30
+}
+abc.com:53 {
+    errors
+    cache 30
+    forward . 1.2.3.4
+}
+my.cluster.local:53 {
+    errors
+    cache 30
+    forward . 2.3.4.5
+}
+```
+
+## CoreDNS로의 이관
+
+kube-dns에서 CoreDNS로 이관하기 위하여, 
+사용자가 kube-dns 대신 CoreDNS를 
+적용할 때 [블로그 기사](https://coredns.io/2018/05/21/migration-from-kube-dns-to-coredns/)를 참고한다.
+
+또한 공식적인 CoreDNS [배포 스크립트](https://github.com/coredns/deployment/blob/master/kubernetes/deploy.sh)를 
+사용하여 이관할 수도 있다.
+
+
+## {{% heading "whatsnext" %}}
+
+- [Debugging DNS Resolution](/docs/tasks/debug-application-cluster/dns-debugging-resolution/) 읽기